Matthew Lang

A beautifully put together bike. Frames like this deserve only the best components.

via FGGT

I decided to lump these together in one post rather than drag them out into seperate posts. I'll also try and keep the reviews short and light. Watch out for more as I get more books read.

HMS Surprise & The Mauritius Command by Patrick O'Brian

These are books three and four in the Aubrey/Maturin series. I couldn't possibly summarise the plots of these two books in a few short sentences, but they were both terrific reads. Like the first two books in the series there is great attention to detail in not only the characters and the plot, but also on the naval aspect of the stories. If you like your books short and fast paced these might not be for you, but I do love the way Patrick O'Brian has written these. They do require a fair amount of time to get through, but they're definitely worth the time.

Don't be an idiot: Learn how to run a viable freelancing business by Curtis McHale

I am fairly new to freelancing as are many others I would imagine. Most of us might have taken the plunge to freelancing without a thought to planning your finances. I did this a few years ago and the result was a disaster. I was completely burnt out and I didn't even make that much money from it. Fast forward to now and despite a rocky start, I'm getting there and that's thanks to this book.

In the book Curtis explains what's needed to make that initial jump, setting the right payment terms, project goals and reviews and more. This book won't tell you everything you need to know, I've yet to read a book that does, but this is a great starting point for those either looking to freelance or are currently freelancing but want to take it to a more professional level.

I hope that Curtis writes more books on freelancing in the future. He definitely has the right experience to draw from and he's proof that setting the groundwork can make your freelancing career really prosper.

The Freelancer’s Guide to Long-Term Contracts by Eric Davis

When I decided to freelance at the start of the year, I was unsure about how many clients I should have and how often I should be advertising myself as being available. What I didn't know was that there are in fact long term opportunities out there for freelancers. It's sort of the happy balance between working for yourself and full time job security. This was a form of freelancing I hadn't read about before but was really interested in.

Eric's book however has been a great guide through the possibilities of long term contracts. Thanks to this book, I now see them as being the premium service in my freelancing career. If you're looking to start freelancing and want the security of long term contract work then I would recommend that you get this book. It's a different way of working than short term contracts and thankfully Eric has all the advice you'll need.

Next on the list are War of the Roses: Stormbird, Frictionless Freelancing, You Only Better and Crafting Rails 4 Applications. I'll be hoping to report on these at the start of next year.

Last night I posted to App.net an idea for a premium newsletter that aggregates and reports on activities and news happening within the App.net community. The response I got back from people was very positive. A lot of people expressed interest in the newsletter.

Why a newsletter?

It's a question I asked myself a few times while writing this blog post. App.net members can already find out this information on App.net itself, the only problem is that they might not know the correct hashtag or account to follow to get that information. The newsletter is not just a way of letting you know what's happening on App.net but also as a way of bringing App.net members together.

I'm trying to foster a better way of brining people together on App.net.
Since signing up for App.net I've enjoyed being here and I want to continue enjoying that experience. That's why I thought about introducing a newsletter for App.net members. A unified way of getting up to date information in one place. You can still use your own methods if you prefer, e.g. searching for the right hashtag for the book club or finding out when the next writers challenge is. The newsletter isn't compulsory, it's optional. It's your decision how you want to interact with App.net.

Why premium?

When I say premium, I mean a newsletter you pay for. Why would you pay for it? Well why wouldn't you? It takes time to collate, write and edit newsletters and while most free newsletters rely on ads, I don't think that ads are what people want to see in the newsletter, although I haven't validated this yet.

App.net started out as a premium service that indicated right from the start, no ads. I was hoping that the newsletter would follow the same path.

On the other hand I can appreciate those that wouldn't pay for such a newsletter and would want to receive it for free. If you're not paying for an App.net account then why would you pay for an App.net newsletter? Also we're trying to foster participation in this community and many people have free accounts. Why would they want to pay for information that they can get that information through other means?

Then there is those who are already paid members. Do they really want to pay for a monthly subscription on top of their membership? To bo honest, I would. The newsletter would have to deliver value though.

I've been thinking about this and while I can see the benefit of a free newsletter for one and all, I see little reward for those that could be contributing to the newsletter. That fluffy feeling you get from doing something for free for someone can only get you so far. What if the newsletter takes off and demands more of my time?

I started a poll last night (thanks @abraham), to get feedback on whether people would sign up for a premium newsletter on what's happening in App.net. For me the number of responses are too small to definitely say that yes most people would be interested in a paid newsletter. At 9am (GMT) this morning the responses were as follows:

• 61% (11 votes) of respondents indicated that they would be interested in a premium newsletter.
• 33% (6 votes) would be interested in a newsletter if it was free.
• 6% (1 vote) said they wouldn't be interested in a newsletter at all.

Clearly there is demand for a newsletter, but a premium one? I'm not sure on that yet.

What's in it then?

Here's the good part. I've been able to get a lot of great feedback from people with very interesting ideas for content for the newsletter. Here's some of the suggestions so far:

• App.net meet ups across the world - Really just a list of where App.net members are meeting in the next couple of weeks. Usually I hear of these things through App.net itself, but having these delivered to your inbox is a better way of finding out when they are happening.
• Community calendar of events and activities happening on the network - Really what I think we have in mind here is dates for events like #thememonday, #wedc as well as book clubs or movie nights that are happening across App.net.
• New apps and services - Got a new app that you want everyone to know about? Then why not spread the word through the newsletter. We'll also let you know when apps and services get important updates as well.
• New interesting users - I'm not talking about celebs. I'm talking about writers, photographers, thought leaders, musicians. If anyone important joins App.net we can let you know through the newsletter.
• Tips and suggestions - Did you know that Alpha supports the Markdown syntax for embedding links in your post? Not a lot of people know that, but wouldn't it be great to see tips like this and getting more from App.net with other titbits like this.
• Featured photo - Every week a photo taken by an App.net user will be featured in the header of the newsletter with a link to credit that user.
• Member profiles - Every week we could feature a user in the newsletter and do a small Q&A session with them. This could include the ADN staff as well if people wanted this. The point to this is that everyone in the community is important so featuring users in the newsletters would be great to foster connections between people.

What's the next step?

Providing I get enough positive feedback from App.net members then I think a simple first edition of the newsletter is required. Something for everyone to enjoy. What I also need is actual content as well and a structure for that content that will make up the newsletter. I've created a patter room for the ADN newsletter as well as an account on App.net for the newsletter.

An amazing account of how an American photoreconnaissance team, in a battered B-17 called Old 666, carried out a mission to gather intelligence on a Japanese base on the island of Rabaul.

During the first fighter pass the plane was hit by hundreds of machine gun bullets and cannon shells. Five crewman of the B-17 were wounded and the plane badly damaged. All of the wounded men stayed at their stations and were still firing when the fighters came in for a second pass, which caused just as much damange as the first. Hydraulic cables were cut, holes the size of footballs appeared in the wings, and the front plexiglas canopy of the plane was shattered.

— The Most Honored Photograph by LensRentals

via Kotte.org

Even if you don't drink coffee, this is a must buy if you're a cycling fan.

via PedalConsumption

... from Adam Keys that you should reserve a place for work only.

The big idea from that article, burning a hole in my head, is that we should step away from our desks when we’re not working (for me, telling computers to do things). Thinking can happen on a walk, standing outside, or in the shower. Socializing can happen from the couch or mobile device. Procrastinating by reading, surfing, social networking, etc. can happen anywhere.

— Quit your desk by Adam Keys

A few weeks ago I mentioned that I would be rewriting the Journalong application complete with a new front end that would be more simplistic. I was hoping to do away with the current look of the journal entry page by trying to re-design it. After a few of getting nowhere I've decided to throw in the towel in on the facelift to Journalong. It's given me too many things to think about regarding the user interface. Basically, I'm over complicating a simple thing.

I'm hoping in the next couple of weeks to push the rewritten version of Journalong to Heroku without the facelift. There will be no change to the functionality of the site, there will however be one immediate change that will be visible on the site.

I'm going to do away with the blog for the website. As a replacement for communicating with Journalong users I'm going to create a newsletter. Not only will it be used for notifying users of updates to Journalong but there will be tips and stories from users of Journalong.

The problem with the blog. It's almost impossible to determine which of your customers are reading your blog. Other than subscribing to Feedburner, or a similar service, there's no way to determine how many people are actively subscribed to your blog and interested in using Journalong.

With a newsletter I'll have more of an idea about who's interested in Journalong. I can monitor the number of people who are subscribed and determine how many are actually Journalong customers and how many aren't.

Once this is done, I'll be working on a number of new features that will make Journalong even easier to use. I hope you can all bear with me for the next few weeks. Good things are coming, I promise.

... is such a bad move for a manager. Don't be that manager.

Read on at Execupundit to see the characteristics of a good manager.

For the last two weeks I've been using Trello instead of Taskpaper for managing projects like Journalong. It's really an experiment to see if I can get more things done with a visual system. Previously I was using lists in Taskpaper. It worked to an extent but anything that was at the bottom of list would frequently be forgotten.

So what is Trello?

Trello is a generic organisation and collaboration tool. Yes it sounds like a vague description, but Trello isn't tied to any one particular workflow. Basically Trello is a simple workflow and list manager.

A Trello board consists of several lists like so:

You create cards that you move through the lists from left to right. The lists themselves can be called anything you want and can be modelled after any iterative workflow that you can think of.

The cards are used to represent individual items of work. It could be a task, a feature for a product, an article you want to write or even part of your wild scheme to take over the world.

The cards themselves contain a title and a description but can also contain a set of tasks, attachments and even comments from yourself and other users collaborating on the same board.

How I'm using Trello

I'm using Trello in two ways at the moment.

Primarily I am using it to get my finger out on moving some development projects along. Journalong was first to get the Trello treatment and work on it as picked up again since I started using it. I use it mainly to mimick the Kanban way of software development as you can see from the board below:

As well as using Trello as a way of managing software projects, I'm also using Trello to manage my blog. In particular, my weekday posts to the blog and the writing process involved for each post.

I have a backlog of ideas that I want to write about. It ranges from software development to personal reflective pieces. At the weekend I pick five ideas from the backlog for the coming week and assign each of them a day of the week. Then I stick them in the drafts column and start writing each one.

As they are completed they get moved on to editing and then they are ready to be published. While the Journalong board is fine, I might change the process for my blog posts. I don't want to get too bogged down in different steps for each post. I tend to write, edit and queues posts for my blog in the one sitting.

Great device support

What makes Trello great however is the support they have for different devices. It's one of the few applications that I have installed on by my iPad and iPhone. Initially I was hesitant of how Trello was going to be implemented in iOS. However since using it for the last few weeks, It's steadily becoming a favourite in my day to day apps category.

The iPhone UI is particularly nice as it lets you zoom in on a list within a board so that you can see all the cards for that list. Everything that you have available in the web UI is available here as well. Checklists, labels, attachment and comments are all there.

It's free!

One thing that you thought I may have skipped over is that Trello is a free for anyone to use. I had reservations about this until it was pointed out to me that the makers of Trello, Fog Creek Software, wanted Trello to be a free product from the start.

There is a business plan that allows organisations to use Google Apps for authentication and to get all their users across without any pain. There is also paid plan called Trello Gold that adds a number of nice touches like changeable board backgrounds and bigger file uploads. The free version of Trello is ideal for most people.

A great visual tool

I've enjoyed using Trello over the last few weeks and I've decided to stick with it for managing projects and my writing. Whether I'll use it for other things like sales leads, invoicing or anything else I can think of will be decided as and when I think I need something beyond a basic list to manage them.

I love the visual side of using a board. You get a clearer picture of where everything is and it means that you instantly know what you should be picking up next. Coming from a background of using mind mapping for a few years, I love systems that use visualisation to convey a message or intent. The nice thing about this tool is that it's visual, portable and adaptable to just about any process that you can think of. It isn't the silver bullet to everything, but if you're having problems getting projects organized and trying to determine where the bottlenecks are then Trello just might be worth checking out.

This post contains a referral link for Trello for which I receive a free month of their paid plan, Trello Gold, for each sign up. If you don't want to use the referral code, you can use this link to checkout Trello for yourself.

Eric Davis' book on long term contracts, recommends making long term contracts the top tier of your services pyramid. "What's a service pyramid?", I hear you say. Well, basically your pyramid comprises of three tiers of products and services. Your affordable products and services for the masses are on the bottom tier, products and services for specific markets go in the middle tier with your premium service at the top tier. It got me thinking about the tiers in my pyramid of services and products. Do I have services and products in each one?

The Top Tier

Currently the only premium service I offer in the top tier is myself as a Ruby on Rails developer. This fits in with Eric's idea that only your long term contracts should reside in here and that's currently what I have in the top tier. I have a couple of long term contracts for providing myself as a development resource to teams using Ruby on Rails.

The Middle Tier

There's nothing in my middle tier, but that's okay. My top tier provides me with nearly all of my income at the moment, but I shouldn't leave this tier empty for too long. As a freelancer I can't be dependent on any one stream of income. Each product or service should be generating some income for me, but at least for the moment I have a good premium service that I can depend on until I get other products and services in place.

The Bottom Tier

At the moment, the only product or service that I have in my bottom tier is Journalong, my free journaling service for Dropbox. I don't have any other products or services here. There's definitely room for another product in here. Something simple and easy to manage. As for services I'm not too sure. I don't currently provide any short term affordable services that others would want. Well at least I haven't been asked.

There's definitely room here for more products and services.

What Next?

What I have taken away from this exercise is that I need to start thinking about other products and services in the middle and bottom tiers of my pyramid. The gaping hole in the middle of my pyramid requires a product or service or even both. It shouldn't cost more than any micro products and services in the bottom tier but should still be cheaper than my rate as a freelance developer.

As for the bottom tier, I am putting more time into Journalong with the goal of turning it around into a profitable micro-product. I've got a few ideas for other products and services in this bottom tier, but I need to be selective about those. There's only room for so much that I can do, and cramming too much into the bottom tier can take my focus away from the middle and top tiers. I will need to keep prioritising things over the next few months if I'm to have something in each tier of my pyramid.

During one of my capture sessions from my inbox, I came across this question in Eric Davis' newsletter from his book on long term contracting:

What's your end game?

It resonated with one of Stephen Covey's seven habits of highly effective people:

Begin with the end in mind

The idea is that in order to know what you want to do, you must first decide what your destination is going to be.

It got me thinking about what direction I am taking my freelancing business in and where I am going to end up. I certainly want to continue to be self-employed for the foreseeable future, but what exactly will I be doing in the future? More freelance work for clients? Consulting? Selling products? I'm not too sure.

I have had work experience with health organisations in the UK including some work in risk management for those organisations. I have prototyped a number of risk and decision management solutions in the past that did interest me. Could I apply this knowledge to building similar products now? Possibly.

Although maybe my destination lies more closer to home. Maybe I'll end up doing something outwith the world of web applications. One thing's for certain. If I'm to progress as self-employed for as long as I can, I need to work out what my end game is for my freelancing business.

Nice racing green also the bars are rather good as well.

via Pedal Consumption

When I first started freelancing, I thought I had the perfect job. Setting my own hours, working from home and no tiresome commute. These positives are what many people want from freelancing but there's a downside as well.

The downside

Working alone is hard for a number of reasons, but the main reason is that you are in fact alone. You're no longer part of a team, you're on your own trying to build a career with the resources you have available to you. It's not as dire as it sounds, but there's lots of little things you miss when you're working on your own.

The office banter is gone. I worked in a great team of developers a couple of years ago and I do miss the chatting before the stand up and pairing with other devs through the day. You can be the most connected person on Twitter, but it's no replacement for a face to face chat with people.

Then there's the resource part. Everything is on you, and I mean everything. No only do you have to deliver great work, but you also must communicate clearly with your clients, keep your skills up to date, market yourself and about a thousand other tasks that keeps your business running.

The upside

So you're working alone with big responsibilities on your shoulders, but there's an upside to working this way as well.

Having a balanced work life that doesn't eat into my time with my family is why I enjoy working from home so much. Not only do I no longer commute to and from work, but my hours are also dictated by the client work that I do. It's very rare now I work at night now. I fit all my client work in during the day, which leaves me time at night to do work on my own projects, get some reading done but best of all I actually get to spend time with my family.

The other big positive for me is I get work the way I want to work. I get to choose the hours I want to do. Having the flexibility to fit more in my day means that the weekend is left free for more important things like taking the kids to the park or getting myself out on the bike.

I also get to choose the the tools I want to use. It's very liberating to have this choice and not be confined to working with one tool or framework and be restricted by the equipment you can use. I've had my fair share of programming jobs in the past that wouldn't have been my first choice, but now I'm actually in a role where I'm enjoying what I am doing.

The verdict

I prefer this independent way of working. The positives really do outweigh the negatives for me. It's definitely not as easy or straight forward as I first thought it was going to be, but it is providing me with more opportunities to carve myself the career that I want.

Programmers have always got old code lying around. Forgotten applications, libraries, ideas and other files and folders. Remnants of days perhaps when ideas were rife and ambitions were high. I have those days as well. I have an idea for something, I mock up a quick test with some code and then most of the time decide that it's not simply worth my time investing in it further. What remains behind is a filing system littered with dead folders and files.

Today I started cleaning up those dead end projects.

I deleted old applications that I'm not hosting anymore, deleted ideas for applications and products that I know are not going to work and also deleted a few repositories from Github account. I cleared out a few forked repositories that I had high ambitions of working on but haven't contributed to them.

From there I then started to remove a few applications from my MacBook Pro. I only deleted a few applications, but better to remove them than to have them sitting idly doing nothing. More deadwood gone.

Then I moved onto the online tools and services I subscribe to and removed a couple of them also. A few more dollars back in my pocket each month and that great feeling of removing yourself from a service or subscription that might distract you with an email each week, but you quickly delete it.

Just like clearing your desk or work environment of deadwood files, folders and other junk on your desk, it's also important to remove the digital deadwood as well. Start with your laptop or tablet and remove the applications you don't use, the old folders and files that are no longer relevant. Once your immediate work environment is clear, move on to your work environment in the cloud and trim those services that you don't use anymore.

Keeping a clean digital environment is just as important as keeping your physical work environment clear. You might just end up saving yourself some money or even getting some space back on your laptop. Even better, you might just have rid yourself of a few unwanted notifications each month.

You don't get anything for free in life, and that is definitely true for hosting platforms. In exchange for often what is perceived as a great free hosting offer is in fact a very limited service.

Take Heroku's free plan. It can handle a fair amount of traffic but it comes with a very limited database and if your website suddenly attracts a flood of new traffic then you are pretty much screwed. Heroku's free plan is good for early days of development, but it's definitely not a good starting point for your actual product.

A common complaint I hear from those with product ideas is the cost of funding their startup. In particular, web hosting. I've seen too many examples of products trying to run on inadequate hosting plans, often free or very cheap hosting, that fits the budget of the startup in limiting costs, buts increases the risk of the product's site failing to respond should it suddenly find itself on the receiving end of a rush of traffic to the site.

Being a lean startup doesn't mean you should limit your hosting budget so that you only go for free hosting services. You should at least be aiming for a being able to deal with the odd rush of traffic here and there from blog posts and marketing that link to your product. Marketing campaigns through emails and social networks can generate a lot of traffic to your product. With the sudden rush of traffic is your product's hosting platform going to cope? An unresponsive product means lost customers which in turn means potentially lost revenue. Nobody likes to lose money like that.

I'm not saying there isn't a place for free or very cheap hosting. Heroku's free plan is ideal for small static websites and good for test and staging environments for web applications. However for your products, that you want to generate you money, you need to spend a bit of money on a well provisioned hosting platform. This is a professional product you're selling after all, so why not invest some money in ensuring that others see a stable well hosted product rather than a product that times out with even the smallest surge of visitors?

There's plenty of choices out there and they range from bare Linux servers that you require you to set them up to managed hosting like Heroku. The choice is down to the amount of technical know how you have and how far your prepared to roll your sleeves up.

Being lean doesn't mean being cheap, it means providing a stable product that can scale with a growing number of sign ups and customers. That doesn't happen on free or cheap hosting plans, so spend the extra money on your product's hosting to get a stable platform that will be a step to ensuring that you at least get customers signing up.

At any one time there are usually three devices sitting on my desk. A laptop, a phone and a tablet. They all have different apps running on them but some of the apps they use are for the same service. So for App.net I have an app running on my laptop, but a different app running on my phone and tablet.

Here's the problem. I haven't really paid too much attention to configuring notifications for each of the apps so sometimes I end up getting multiple notifications going off on the different devices for the same event. For example, in App.net when I get a new follower, I get an email notification in my phone as well as a notification from Felix, and also a notification on Felix on my tablet. Just little bit overkill if you ask me.

So here's my question to all of you. What's your strategy for dealing with notifications on multiple devices?

I sit in front of my laptop for most of the day, so ideally most of my notifications should come through there, but then what notifications should I enable for my phone? Are there any type of apps that you recommend I should completely silence?

If you've got any thoughts on this then please reply back to my original post on App.net or drop me an email here. I'd be really interested to hear your views on this.

... with our guide, Kurt Harden.

via PedalConsumption

My wife mentioned the other day that she was thinking about her New Year's resolution for 2014. I said to her, "Did you keep last year's resolution?". "No", was the reply. In fact she freely admitted to never keeping resolutions.

"What's stopping you from starting now?", was my next question. It got her thinking and she's decided to start making plans now to implement some positive changes to her health and fitness.

Why do we feel the need to wait for a milestone to pass before we start something? New Year's resolutions are never kept. I never kept mine. In fact, it was only a few of years ago when I abandoned the whole idea of starting and keeping a New Year's resolution. I do keep a theme for the year that I can group goals under, but that's all it is. A theme for the year.

Don't wait.

Start now.

Write down what you want to achieve next year now and start making a list of next actions towards making those achievements. Do it now.

What's the point in waiting for a holiday or birthday to roll by before you start taking action? Age is just a number and so is the year. There's nothing special about them that will make you achieve your goals.

Get the notepad and pen out and start that list now. Start working towards your goals now. Get the jumpstart on the year and start it knowing you've already achieved something before the this year is finished and that the next achievement is just around the corner and not 12 months away.

New Year's Day is just another day on the calendar. So is today. Don't wait for the end of the year. Start now.

I can't wait to get NB's latest book.

I've been building web applications in Ruby, on a full-time basis, for a couple of years now. During this time I've been exposed to a number of different testing strategies and approaches. Test-Unit, MiniTest, RSpec, Cucumber, Steak and many more. I've used many of these test frameworks to some extent, but despite the many choices I have in this area, I'm still befuddled by the right tools to building a web application in Ruby using test driven or behaviour driven development. The Rails framework has shipped with Test-Unit for years but the most popular testing framework is probably RSpec.

In order to quell my confusion, I thought I would expand on the three approaches that I have used most often in my time using Ruby.

1. The True Agile Approach

Perceived by some as the holy grail of testing, and in some cases with an equally preachy opinion, is the true agile approach. Being part of an agile team with a customer on hand to flesh out user stories, daily stand ups, retrospectives. Just about everything that embraces an agile approach to building software.

In this approach, test driven development and behaviour driven development tools reign supreme. If your approach is TDD, you'll most likely be using RSpec or Test::Unit for testing all aspects of your web application. If your approach is BDD, then it's Cucumber all the way. This is pretty much a no brainer really. With so many hands available for development, it makes sense to always write tests first.

2. The Solo Developer Approach

The true agile approach is fine when you're part of a team, especially when that team advocates pair programming and you have a customer on hand to flesh out user stories. What if you're a developer with your own product or service though? You understand the business domain enough to eschew the behaviour driven development approach but you still want to test your product?

I had this problem with the early iterations of Journalong. I understand the business domain, so is it really necessary to use a BDD approach? Can I simply just switch to a TDD approach with Test::Unit or MiniTest?

I'm still on the fence about this.

3. The Side Project Approach

This is simple, and I embrace this approach 100%. No testing framework or just enough tests to handle the complicated stuff. Hacking on your own ideas is a good time to really explore the frameworks and languages you are doing. Getting these setup correctly with all the proper test frameworks can be a chore though. If it's just an initial idea or throwaway solution you're working on then why bother investing the time in writing tests?

I want to be a good developer and develop solutions that are thoroughly tested but when was the last time you just hacked on a bit of software to try something out? If I know enough of the framework and language to get by then I don't bother writing tests. It might take me an hour to come up with something or half a day, but if that's all it takes then why bother getting all the correct bits in place to test it.

There's definitely a time and place for testing strategies in development, where you're part of a team building a product or building a revenue generating product or service on your own, testing strategies can give us the confidence we need to ship code on a frequent basis.

For my own ideas though I would rather roll my sleeves up and get into the parts of the code I know or even try new things with a part of the language or framework I haven't used. Kind of like code exploring, filling in the blank edges of the map if you like.

Curtis McHale has invited his readers to write about their blogging history, so here's mine.

My initial dip into blogging was about 5 years ago with the then rising star of blogging platforms, Posterous. I started a blog with the great intention of posting at least once a week. What I was going to write about I was unsure which in turn led me to actually posting to my blog very infrequently. A bit of a false start then.

MindMapSwitch

With no fixed topic in mind and a checkered past of a software career with no expert knowledge in any one programming language or framework, I looked back at the other skills and experience I earned from my career. One particular topic jumped out at me. Mind mapping. This was the moment when my mind mapping blog, MindMapSwitch, was born.

I ran the blog on Posterous and kept the blog going with frequent updates in the region of once a week. After 18 months of posts I got to the point where I simply couldn't write anymore about MindMapSwitch. Rather than struggle on with finding new content on a limited topic with a limited audience, I decided to cease writing anymore posts for MindMapSwitch. The blog itself was eventually removed from the Internet with the shutdown of Posterous but I do have a back up of MindMapSwitch's posts.

From that point I moved on to focusing my attention on my own two blogs. I kept a blog for short essay style posts and I kept another blog for link posts. Both were initially hosted on Posterous, but I did move the blogs to Octopress for a short time and then onto Squarespace for a while.

Back to Octopress

At the start of this year I decided to bring the two blogs together and migrate back to using Octopress again. The pull to writing in Markdown and having more control over my blog was what I actually wanted rather than trying to dissect the templating language of another blogging host.

Faced with the start of a career working independently, I wanted my blog to the first thing people would see when they searched for me. At the same time I committed to writing an article every week day. Since doing this I've been steadily churning out content that been increasing my audience on a monthly basis.

Time for the stats

I used Google Analytics for over four years for my blogs, but since deleting my Google account, I've had to move to a different service for collecting my web traffic stats. I settled with Github's Gauges service in April this year. Although I've lost the stats from my Google account, it hasn't been until this year that my traffic stats have started to get really interesting.

Since April I've managed to increase my visitors and page views each month and last month I broke the 1000 page views milestone in a month. I'm also using my stats to spot patterns in popular content that I should consider writing more about. Popular content over the last few months have included articles on productivity, text editors and using Octopress, but by far my most popular post is about switching to Feedbin.

Where to from here?

So where do I go from here? My posting schedule of short essay style posts on the weekdays is working well for me, so I'm not going to change that anytime soon. I also usually post short link posts on a Monday and Friday which I will continue to do. I've got plans to include popular content pages for my blog and also write more technical posts around programming and software development.

I suppose the key thing is that I have found something that works. I'm happy with my posting schedule, my content and my choice of blogging tools.

I'm just another person trying to carve out a niche on the Internet really with their blog. As long as I'm gaining more and more interested readers, I'll keep posting.

When I started using Sublime Text 2, I didn't use Sublime's projects feature. This year though, I've started to really get to know my preferred text editor and since then I now save all my code as a project in Sublime. It really does have some great advantages and with a little time it can make working in Sublime a better experience for you.

Sublime's projects are typical of projects in other text editors and IDE's. You open the folder that contains your source code with Sublime and then you can save that source code as a project.

When you save your code as a project you end up with two files. The first is the project file which contains references to folders for your project, project based settings and build commands for your project. The second file is the workspace. This is simply a file that tracks what layout you're currently using and what files you have open in each pane. Using the workspace file means that you can switch to another project, do some work and then switchback to your original project knowing that the layout and files you had open will be restored back to the state you left them in. Handy.

Opening Projects

Let's start with opening projects. You can open a project from the command line by using the project switch from Sublime's executable.

>> subl --project deathstar.sublime-project

Nice, but a tad too much to type. Rather than keying this out when I need to open Sublime, I prefer to alias the opening of a project file into a command that I can remember.

>> sds

Typing these three letters into my terminal to open a project is much easier than trying to remember where the project is and the correct switch for opening a project in Sublime. Now that we have our project open we can start tweaking the project file itself to make suit our needs.

There are three sections to the project file:

1. Folders - You can define a single location for your project or multiple folders that make up a project. This also include filters on files and folders you might want to apply to each folder in this section.
2. Settings - The settings in the editor can be changed on a project basis. If a particular language for your project requires different settings, e.g. tab size, you can define these here and the changes will take affect when you open the project.
3. Build Systems - I tend not to use this, but you can keep a number of different terminal commands here that you can tell Sublime to execute without having to switch to the terminal.

Using Folders

Let's take a look at the most important section which is folders. Although this section is only small it can make a big difference to the way you work with your project and with Sublime.

The project file is just JSON and is fairly easy to follow even if you don't have that much experience with JSON.

{
  "folders":
  [
    {
      "path": "/Users/darthvader/code/deathstar-reactor"
    }
  ]
}

The path setting points to the folder that contains the files for your project. Most of the time you might just have one instance of this in your project file, but Sublime does allow you to have more than one folder in your project file.

{
  "folders":
  [
    {
      "path": "/Users/darthvader/code/deathstar-reactor"
    },
    {
      "path": "/Users/darthvader/code/deathstar-superlaser"
    }
  ]
}

I've been using multiple folders for a couple of projects now. I'm rewriting an application just now that uses multiple folders. For that project I included the old source code and the new source code in the same project so that I can refer back to the old code to lookup any old code.

Which leads us nicely onto names. Having multiple folders in your project can be confusing, especially when projects might have similar folder names or even the same name. To get round this, you can also define a name for each path in your project that will appear in the sidebar. This makes navigating code in your sidebar much easier.

{
  "folders":
  [
    {
      "name": "DeathStar - New & Improved Reactor",
      "path": "/Users/darthvader/code/deathstar-reactor"
    },
    {
      "name": "DeathStar - Superlaser x10",
      "path": "/Users/darthvader/code/deathstar-superlaser"
    }
  ]
}

Perhaps the most useful feature of the projects file though is the ability to exclude files and folders from your project. You are not going to need to see all the files and folders in Sublime when you are coding, so these filters are a great for excluding logs, temp files and other automatically generated files that are not typically needed in Sublime.

Excluding files can be done like this:

{
  "folders":
  [
    {
      "name": "DeathStar - New & Improved Reactor",
      "path": "/Users/darthvader/code/deathstar-reactor",
      "file_exclude_patterns": [
        "*.log",
        "*.pid",
        "*.tmp"
      ]
    }
  ]
}

And excluding folders can be done like this:

{
  "folders":
  [
    {
      "name": "DeathStar - New & Improved Reactor",
      "path": "/Users/darthvader/code/deathstar-reactor",
      "folder_exclude_patterns": [
        "tmp",
        "log",
        "solr"
      ]
    }
  ]
}

Switching Projects

Now that we have our project file setup we can get on with using it.

Because I now have a projects file for each project I work on in Sublime, I find it much easier now to simply switch to the project I need to work on, do the work, and then switch to another project. Switching between projects is as easy as Cmd+Ctrl+P if you're working on a Mac or Ctrl+Alt+P if you're working in Windows or Linux. This brings up a list of projects that Sublime nows about and lets you switch projects without leaving the application or returning to the terminal.

The benefit of this is that I only have one window open for Sublime and I can stay focused on the code that I am writing for that particular project. Having multiple projects open is distracting to me and puts me off my work.

I'm not currently using the settings or build systems for a project, but I am looking into running tests from within Sublime and adding these to my project files as build systems.

Getting to know how your tools work and making them work better for you is the key to getting the most out of them. Investing a bit of time in organising your code with Sublime's project files make organsing and working with even multiple folder projects a breeze.

I mentioned previously that I was interested in building a replacement bookmarking application for my bookmark collection on Pinboard. I wanted something a little more than just lists of bookmarks, I wanted more information when viewing an individual bookmark. Here's some things I wanted to see:

• What else have I bookmarked from this site?
• What else have I bookmarked with similar tags?
• What did I bookmark before and after this?

In the last few weeks, I've been putting together my own private bookmarking application. So far I have enough functionality that I can use it on a day to day basis and it also includes some end points so that I can integrate it with other apps and services. So without further ado, here's a sneak peak of the sections that make up a bookmark page in my private bookmarking application, Linkalong.

Big title

There's no getting away from the title. It's big and bold. Lately I have been building web sites and applications with bigger text in them. A lot of websites have very small text which I am finding increasingly difficult to read. For this bookmarking application I wanted a big and bold title.

Markdown based notes

I love writing notes in Markdown. Even if my notes in my notebook sometimes have the Markdown markup in them. Crazy, right? Markdown's markup is just second nature now when I am writing. It makes sense then for the notes for my bookmarks to be written in Markdown and rendered as HTML.

Bookmarks from the same site

When I used Pinboard, I had tags for bookmarks from the same site. It allowed me to view all bookmarks from the same site. Although it would be easy to do with tags in my own application, I wanted to list bookmarks from the same site without having to tag all relevant bookmarks with the same tag.

Bookmarks with the same tags

Just like seeing bookmarks from the same site, I wanted to see bookmarks with similar tags.

Nearby bookmarks

Finally I wanted to see the bookmarks that I saved before and after this one. So at the bottom of the page I added links to those respective bookmarks.

Building Linkalong has been fun and it's definitely by no means finished. It's served two purposes for me. It's my replacement for Pinboard and it is a place where I can try out new things with an application that I use everyday. If you're looking for the whole page, you can view a screenshot of that here.

Thanks to Patrick Rhone for his initial indirect nudge to building this.

I'm halfway through Curtis McHale's book on turning your freelance career into a viable business and one thing that has become clear through reading it is my lack of progress on products and projects. Given that I only use a single list for everything, sometimes projects and ideas get skipped at the bottom of the list. It's the out of sight, out of mind thing. If I'm not reminded of something on a regular basis, I usually forget about it.

In order to make better progress, I'm going to start using Trello for managing projects and future products. I'll still stick a high level task on my master list relating to the project, but all the details for it will reside in Trello.

The reason I picked Trello for this was my familiarity with Kanban boards and some experience I picked up working in an agile team a couple of years ago. Basically the idea of Trello is that you move cards (or tasks) across the board from left to right until the card is complete. In my case my this will be features, bugs, marketing and admin tasks.

Cards move through the following lanes that are typical of Kanban boards:

• Backlog - All cards start here. Cards are prioritised on a weekly basis with the next card to be done located at the top.
• Analysis - We do some background work on the card. What does it involve?
• Development - Let's implement this thing with some nice tests and code.
• Testing - We test it out in a secure environment.
• Deployed - Once it's tested and ready, we ship the code for the rest of the world.

Moving cards across the board is a great way to see progress being made, and also with work-in-progress limits, I can stay focused on one or two tasks at a time.

Also I'm currently using Trello with a couple of clients for project management, so the switch from their projects to my own when things are quiet is easy to do and I'll already be familiar with the Trello environment. Seamlessly moving from client work to my own work is important. I don't want to have to adjust too much to a different workflow.

My grass roots approach to work still stands with just a master list for capturing everything and scheduling actions in my calendar. I'll capture a high level description of the project in my master list and defer the details down to cards on the Trello board. Any work I do will be blocked off in my calendar as just "Project X Work" and then when it comes to actually doing that work, I can pick up where I left off on the Trello board. When time runs out, I can leave a note on the card where I left off and move on without losing my place.

It all sounds well and good in theory, but putting it into practice over the next few weeks might not yield the positive results I'm hoping for. Still, I've got to give a try though, right?