Dan's Developing Days

Review of Blogsy

2011-09-28T21:39:00.001+10:00

I've never used Blogsy before, but now that I have my iPad I thought I'd give blogging through it a go. What better way to see how useful it is than to write a review for my blog using nothing but the tool itself.

The Keyboard

So this review doesn't just cover Blogsy, but the process of using the iPad to blog online. I have very large hands and often find it hard to type on small keyboards. I'm using the iPad on screen keyboard to write this blog, and although I'm making lots of mistakes, its actually quite good.

The biggest drawback I think is going to be around the fact that you can't rest your fingers on the keyboard. Over time this will definitely make my hands hurt, in fact I'm only a small way through and my wrists can already feel a little bit of strain. I do intend on getting a wireless keyboard for this thing at some point though if I do end up using it more, however iPad haters will probably have something to say about that.

Made for the Tech Savvy

This program, Blogsy, is clearly made for the tech savvy. The blog is written in markup instead of some GUI based editor and it's a breeze to use, even without a mouse. There are helpful buttons to enter in some basic markup commands, headings lists alignments, quotes etc.

Additional Content

It would be a pretty boring blog post if there wasn't some image or video content somewhere in there. The right hand side of Blogsy includes links to popular applications. These let you place media or links easily into your blog post from various locations.

This photo is of my two Aussie Eastern Long Neck Turtles when I first got them. Aren't they cute!? Content from Picasa, Flickr, You Tube and more can be placed as well as copying data directly from Safari. It's a great feature. My favourite part of the feature is that you can upload content from your own local photo album to your content provider. I really can't fault this feature. It is simple and it works well. Drop box support would be nice, but not necessary for me as I don't store media there.

Code

Sure I might not write much code any more, but I still imagine that posting code will be important to me.

int main (int args[])
{
int i = 0;
}

Clearly from this it is not going to be practical to post about code using Blogsy. Honestly even writing code on an iPad is just cumbersome, so I suppose even if it did have a code feature I wouldn't use it.

Anything Else?

Not really. Features are small and simple but this app has pretty much everything you need to make simple blog posts on the go. For only a few bucks I'd highly recommend it.

An End

2011-09-28T17:39:00.001+10:00

I haven't posted to this blog in some time because my job has become much more managerial and a lot less technical. I intend to start posting again soon but I'm not sure what the content is going to be like and whether or not I'll cover more technical content from my management position or management content or perhaps both.

I have a few projects outside work that are about to start also including a new hobby around home automation, I intend on using this blog to write some information about that, but I guess I'll have to wait and see. I'm also very interested in investing in setting up my own brand, starting with a relevant domain name and website containing this blog as well as any future blogs and work I'll be doing. I expect my future posts to cover some of this also.

Continuous Integration: Build and Deploy Websites with TFS 2010 – Part 1 Web Applications

2010-11-30T13:42:00.001+11:00

I thought it would be a good idea to split this up into two sections, Web Applications and Websites, as they are the two main projects types in Visual Studio for Web Development. Their building and deployment is a little different and probably not worth covering in one article. The process of deployment is quite different from previous versions of Visual Studio or other build environments as TFS uses Workflow Foundation to govern the build process. You can still use MSBuild xml files if you wish, just have your build process spawn MSBuild manually to do so, but I don’t think it’s necessarily a good idea to buck the technology like that.

The workflow system is really quite easy once you get the hang of it, so I suggest that you dig in from the start and quickly convert your MSBuild builds to Workflow Builds as soon as possible. In this case, this article talks about how to build, test and deploy a website in Continuous Integration mode to continually update your staging environment on check-in of source.

Firstly it’s worth noting that we’re using the Agile development methodology default with TFS, it works well for us and requires very little modification.

Creating a Build

Once you have your source in TFS you will need to create a build. This was previously done with xml scripts that run through MSBuild. This is still the case but you won’t need to do any editing of the xml directly, the project files in your solution are MSBuild xml files and already have everything you need. Our environment requires that on every check-in the staging environment is updated with the current trunk code.

To create a new build for your project, open up Team Explorer in VS2010. Right click the Builds entry and choose “New Build Definition”. Give your build definition a name, I use the prefix “CI – “ for all continuous integration builds to make it obvious. Under Trigger, choose Continuous Integration.

Under Workspace, make sure your workspace is pointing at your trunk.

You probably don’t need a drop folder, so turn that off under Build Defaults by unchecking the box. Under Process, in 2. Basic, make sure your set “Clean Workspace” to none so that only the files that are changed are uploaded to your IIS instance when you deploy. If you do not change this to none, the whole site will be deployed on each build which can be cumbersome for large sites with lots of images. Under 3. Advanced, set the Copy Outputs to Drop Folder to false (unless you want this of course, but it’s not necessary). If you’re using Agile, then the Default Template will probably do just fine, it will ensure all tests are run if they follow the test pattern.

Also set your MSBuild arguments to the following:

/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:MSDeployServiceURL=http://<RemoteServer> /p:DeployIISAppPath="<RemoteIISApp>" /p:CreatePackageOnPublish=False /p:MsDeployPublishMethod=RemoteAgent /p:AllowUntrustedCertificate=True /p:UserName=<yourusername> /p:Password=<yourpassword>

So your Process tab will look something like this:

You will need to have the Web Deployment Tool installed on both your build server and on your remote IIS staging server for this to work. I’m not covering this here because I’ve covered it in previous posts and there’s plenty of information around the web for that now. Hopefully someone finds this information useful. Unfortunately this does not work for Website Projects, only for Web Application Projects. I’ll cover Website Projects in my next post.