Matthew Lang avatar

Matthew Lang

Web developer with a preference for Ruby on Rails

Bad Assumptions

Assumptions about the Internet based services we use lead to the fact that only the more popular ones are catered to when it comes to subsequent tools being built.

Assumptions on the Internet are everywhere. It's in the networks that we can share articles to, the growing number of companies using Facebook as their sole Internet presence and in the ways that we can connect services together.

For someone like me it's pain in the backside.

There's a campaign at the moment to stop the development of greenbelt land in our town. The local council want to sell the land to developers to build a thousand more homes for our town. Trying to coordinate with other campaigners on this issue has proved difficult. The only point of contact I can find are on Facebook and even there they don't give an email address to contact them. The assumption here is that everyone has a Facebook account but that's just not the case.

Then there's the services that require you to register using an existing social network account without providing users with a chance to register with their email address. Assuming that we're all on once social network or another is a bad assumption to make and in the end it's only going to lose you potential users and money.

I make an assumption on this website with the sharing links at the bottom of each article. You can share to App.net or Twitter. I choose these because at the time I did have accounts on both, but now I only have an App.net account. Am I going to reduce the sharing options to just App.net? Definitely not, as I see that these are two of the quickest ways of sharing links now.

When compared to the assumptions that bigger companies and organisations have made about social network choice and prescence then my site doesn't seem so important, so I guess then that my assumptions are not too damaging to others. More of an inconvience really, but there are other ways of sharing my website.

Not everyone is connected in a way that we can be accessed on any of the more popular social networks. Some of us even choose to stay away from these in favour of reaching people directly through email or publishing updates to an RSS feed. The good thing about these is that they're the most open formats avaialble for the sharing and consumption of data. No one controls email or RSS feeds, they're free for everyone to use.

I'm more selective about the services and tools I use. I try to use services that provide open endpoints such as RSS so that I can connect services together. They don't depend soley on specific social networks and give me more of a choice. Choice is good, assumptions are bad.

Sticking with App.net

Many readers here will know of my support of the social platform, App.net, and how it has become a worthy alternative to other social platforms. It's a place where I hang out daily, watching conversations happening, taking part in them on the odd occasion and using the 256 character length posts to bash out my thoughts, opinions and ideas through out the day.

I wasn't particularly surprised by the news yesterday that the App.net team is having to scale back its number of employees and rely on contractors to maintain and support the App.net platform. The App.net team have been quiet of late and there hasn't been a visible enough uptake of new members for me to see that App.net platform is growing. It's not all bad news though, Dalton and Bryan have said they will continue running App.net indefinitely.

I've heard so many arguments that App.net doesn't have the user base to sustain growth and given the recent announcement from Dalton, it's hard to argue against this. The thing is though, it's still making enough money to sustain the platform, but this for me is the worrying part.

App.net started as a platform that required payment before you could create an account here. $36 per year is the cost. It's not much for many people, and there's even the option of paying monthly. It was this pay wall that guaranteed that there would be some sense of mediation of users coming onto the platform. If you were serious about joining you paid up. Dalton's recent post reads that hosting is covered by the renewal of paid accounts, but how much of the hosting costs are being used to support free accounts on the platform?

I want App.net to survive and continue to grow, but the free tier account has always been a sticking point. Accounts that don't contribute to the sustainability of the platform and their continued use of other features such as Broadcast means that they're using up part of the hosting of this platform while giving nothing in return.

I could be wrong about this and I don't have the numbers to prove my argument, but I would like to see the platform reducing the features that are on offer to free accounts and continue to add more value to paid and developer accounts. If these accounts are the ones that will sustain App.net in the future, then surely they must be the primary focus rather than building features for all in the hopes that some free tier accounts upgrade?

It's not all bad though, the App.net team have open sourced the Alpha client for the platform. It's from this point on that I hope that contributions made by the community will drive this social platform back into a more healthier state of sustainability and growth.

I love the community behind App.net. My timeline is a much more pleasant place for reading than any single day that I had when I was on Twitter. Interesting conversations and shared links provide a much better environment than being the one account in millions on Twitter.

I'll continue to post on App.net until the lights go out, which I hope is years away from now.

Daily routines

The last two months have been something of a blur. Client work has taken up most of my day now and even into the night as well when I shouldn't really be working. A pattern, or lack of pattern has emerged.

It started a couple of months when I decided to scale back on my daily writing. I thought that not writing as much would let me focus on getting other chores and such done. Truth is, it was the start of a slow decline in what I had carefully built up over the best part of a year. The daily routine.

My work day pretty much had the same format for the most of last year and it worked for me. I had the same routine in the morning for preparing for the day ahead and the same routine at night for reviewing the day. It worked for me.

Once I stopped writing on a daily basis though the routines started to be skipped, and then the calendar was running empty, the task list built up and before you know it, my daily routine consisted of nothing more than simply putting out fires. I've been in that place before and it wasn't a good place to be.

I ended up reacting to problems rather than anticipating problems and setting time aside for them. I was context switching multiple times a day and losing focus. My inboxes and lists were stradily climbing with not view of the bottom of them.

No more. The routines are back in place, the daily writing will be started again and a plan of attack has been formalised. Let's see where this goes.

Moving to Linode

I've been reluctant to explore other services for hosting web applications, but with costs for even a small application on Heroku I've been considering other options.

Last week I successfully transferred the hosting of my blog from Heroku to Linode. Performance wise Heroku was ideal for this website and it handled the traffic well enough considering that I ran the site on one dyno. So if performance and uptime is satisfactory then why make the move?

I've got a number of other Rails applications that are sitting on Heroku. One is a production application, while the rest are simply prototypes and work in progresses. For the production application I've enabled a number of addons to ensure the application responds well to traffic but these addons come at a price. By the time I've added the minimum addons needed I'm looking at close to $100 dollars a month. That's expensive for just a small application.

The beauty of Heroku is that it requires little maintenance. Need more dynos? Add them on. Need more worker processes? Add them on. Everything is easy to maintain through the Heroku web interface. That maintainability comes at a price though and it's a price that I think is becoming too expensive. This is where the move to Linode comes in.

At $20 per month for their basic server it's much more cheaper than keeping a two dynos running on Heroku. This is only half the story though. The other half to this puzzle is Cloud 66. It's a fully configured application stack that sits on your Linode server. It's geared towards Rails and other Ruby based applications so it fits my criteria nicely. The nice thing about Cloud 66 is that it handles the setup and maintenance of your application stack giving you the choice to setup servers with different cloud providers if you need to.

I'm still in the early days of using Cloud 66 and Linode but so far I'm liking what I'm seeing. The end goal is to move all my main Rails applications over to Linode and with some running using Cloud 66 and some just running on a bare server without Cloud 66. Heroku is a great service for hosting Rails applications but it's price is far too expensive for me and when there's cheaper alternatives out there that don't require as too much maintenance.

The other benefit to this move is that I'm starting to learn more about the internals of hosting Rails applications again. I'll use Cloud 66 for most applications, but I will aim to have a Linode server for small Rails applications that are just ideas. Learning how to host Rails applications without all the Heroku magic can only make me a better developer as it broadens my knowledge as a developer. That's all I'm aiming to be, a better developer. And if this hosting move help me do that then I'm happy.

Are you a team player?

Carl Holscher is.

We all have strengths and interests. I have been the Mac Guy. But I need the Excel Guy and the Photoshop Woman to be successful. We all have our strengths. And when our knowledge falls short we use the teams’ knowledge.

Team by Carl Holscher

Breaking Habits for the Best

Even the best kept habits require a break. Regardless of how well you think it's working for you as a habit, it's only when you step back from it, breaking the habit, that you can see the true impact and value of it.

If you're like me, you'll have tried to introduce hundreds of habits in an effort to improve your health, your career, your finances or even your relationships with people. For me some of them have truly stuck over the years. Keeping a journal is one of them and something I do on an almost daily basis. Whether it's a family event, work or even a thought, it gets written down and saved for a future review or reflection. It took me a number of months to get this habit down on a daily basis and while I can see the benefit of it, I've never taken a break from it.

Last week though I decided to drop the journal tools for a few days and just enjoy the time off I had with the family. It was a real eye opener. In that time I realized that although keeping a journal is a good thing for posterity and also for remembering where I was with some work, I was missing something.

Looking back at my journal entries over the years and months, there has been a subtle trend in my journal entries. In the past I would journal once a day with a review of the day, now though I'm logging journal entries multiple times a day. Whenever I complete a bit of work, whenever I have the inkling of an idea, or even when a link catches my eye but I want don't want to just read it later, I want to read it from a particular angle. Every day I'm working I'm writing multiple journal entries as I'm working. When the weekend rolls around, the context of my journal switches and I focus on one entry for the weekend if I did something with the family that was fun.

Before I didn't recognize the pattern of my journal activities and how I was switching between work and family journals. Having stepped back from the habit of keeping multiple journals, I can see that the shift in change is better for me. When I read the last month's worth of entries I found it so much easier to read the frequent updates per day rather than the single monolithic update done on a daily basis.

I also realized something else. I put too much emphasis on writing a journal entry every day when it wasn't necessary. Having not kept a journal for the best part of a week, I can see that it's okay to miss a few days here and there. It's taken a break in my habits to see the true value I'm getting from keeping a journal.

Sometimes we end up switching to automatic-pilot when we habituate processes that we think will make us better people. Truth is though, we need time away, a holiday from these habits so that we can properly evaluate and review their value. Only when we can do this can we see how that habit is truly working for us.

Software Isn't for Life

Software is a form of product that will deteriorate and expire with time. With this in mind, how easy would it be for you to switch software from your preferred tools set to a new one?

I try and not be too dependent on the software that I use on a daily basis. I do have a favourite set of tools that I use but I'm always conscious of the fact that whatever I'm using might not be around tomorrow.

Take for instance my to do list. I've been using Todoist for some time now. What would happen if Todoist stopped trading next month? Or even next week? Barring a natural disaster, I'm pretty confident that most services, including Todoist, will allow a small window of time for you to transfer your data across to another application of your choice before that company closes down.

The good thing about software as a product is that there's plenty of it. We're spoiled for choice when it comes to software and with the now common place app stores from various technology companies, there's an app store for most major hardware platforms.

What happens though when software becomes a dependency?

I've heard many people say that their preferred software product for a particular task is 'X' and that they just couldn't do their job without it. Perhaps that's true if you're in a specialist job working on the next wave of new technology and innovation, but for most of us this just shouldn't be the case. We should not be dependent on just one particular brand of software to get the job done. If you're so dependent on one particular software product then I'd say that you're narrowing your choices down too much.

The text editor is my daily tool for writing and cutting code. My preferred text editor is Sublime Text, but for any reason that Sublime Text was to stop being supported or even cease to exist, then what's my options?

We'll I've played with Vim enough over the years to make the jump to that, and there's a number of other text editors that I could pick up like Chocolat that would do the job just fine. Yes, I may have invested a considerable amount of time getting to know the shortcuts keys of Sublime Text but if I had to then I would comfortable picking up something else. We should always have options to fall back on for the selected tools that we use on a daily basis. In most cases this second set of software might be products we've tried in the past or something that we previously have experience with.

Investing time and effort into a particular software product is fine if it's something that you will use on a daily basis for about 8 hours a day, but anything else is simply a product or tool that could be replaced with alternatives already on the market or a custom made option if needed. Software isn't for life, it's simply a temporary means to an end until we find something better that works for us. With this in mind, are you to dependent on the software you use?

The Limits of Automation

The other day I experienced the limits of what automation can deliver and realized that not all tasks are best done in an automated fashion. Some tasks need that manual touch to get done properly.

At the start of the I got back on the writing bandwagon and published another of my muddled thoughts a couple of days ago. Being a lazy guy, I have App.net's Broadcast setup that takes my daily posts from the RSS feed and publishes them to App.net and to my email subscribers. One of the reasons I done this is that I would ordinarily forget to do it.

This morning I had the realization that I might just be missing an opportunity here. Automating this sharing process from blog to you the reader is all well and good, but what if at an earlier point I could let you decide whether you want to read this post or not?

A couple of weeks ago I started adding a summary to the beginning of each post. In it I try and condense the gist of the post into a couple of lines. If it's not for you, you can move on, if you're interested then you keep on reading.

There was another couple of places though where I could be doing this, and that's in the original broadcast message and the post to my timeline on App.net. I turned off the automatic posting and sharing of my blog and instead opted to use the intro to the blog post as a brief description on the broadcast. The post which was originally sent to my timeline, doesn't include the intro and it uses a shortened URL which I don't want. So as well as using the intro on the new broadcast, I'll rewrite the intro as a condensed version for posting to my timeline on App.net. I'll do both of these tasks myself rather than relying on the automation tools to do it for me.

Automation is great for when it's mundane tasks that can be repeated over and over without interruption, but when we want to tailor that task each time it happens, we need to step in and do the work ourselves. It's not a bad thing either. Now I get the chance to tweak the broadcast and post in the hopes that I can encourage you to keep reading as well as reaching out to more people.

To Kill a Project

Stopping a project isn't easy to do, especially when that project is based on an idea that seemed to be within your grasp. Sometimes though it's the best thing to do, but to ensure it's dead we need to kill the project.

I had an idea a few months ago for a service for users of App.net. It was a service that curated the most interesting or popular posts from your timeline when you weren't there to check it. For the most part this could be when you're in bed or at work. So if you wanted to see the best posts from your timeline in terms of highest replies or stars, it would filter out the best posts for you and email them to you in a summary on a daily basis.

I've spoke to a couple of people on App.net about the idea and they were favourable of the idea. After months of incubating the idea though I want to abandon the idea. I never wrote any code for it, registered any domains or even tested the idea. The idea might be a success, but given that the number of users on App.net isn't as much as Twitter, I'm making an educated guess that it won't be profitable as a service. I want it off my radar for good. It's too distracting having it sitting in my master list thinking I might do it one day.

I'm killing the project then. I'm not abandoning it, deleting it or putting it off. I'm killing it. Permanently.

With this action comes a sense of relief. No longer will it sit on my radar demanding another few minutes of contemplation. I can get rid of it permanently.

I've only done this a few times in the past and each time it was necessary to simply kill the project. For as long as it remains in a list or in your head, you'll always spend a bit of time thinking that you'll get round to it.

The first time I did this was when I killed my mind mapping blog, MindMapSwitch. I had gave up writing about mind mapping but I left the blog itself up in the hopes that one day I might go back and write about it. I didn't. In fact for about two years it just sat there as another dead blog on the internet. A couple of years ago I decided that the blog had to go. No longer would I need to the account to keep it running. I wouldn't be writing on that blog ever again. So I took it down. Gone was all the work that I put into it, but despite that, I felt great about the decision. Another little project that has been sitting on my radar is now gone forever. I don't need to worry about it, spend time on it or even get it started. It's gone for good.

That's why it necessary to kill a project. There's no sense in having a project or an idea sitting there on the shelf gathering dust. Yes, one day you might get round to it, but chances are you won't. Better to kill the project and move on then have it pecking away at your conscience. Once you've killed that project you'll feel a weight off your shoulders and you'll have rid yourself of a commitment.

Balance

Balance isn't something that comes up a lot when people are writing about productivity. Once you are aware of it though, it's a fundamental lesson to learn if you want keep focused and make progress.

I'm like a kid in a candy shop when I have a new idea. I tend to drop just about everything I'm working on new idea for a night or two and then get back to what I was doing before. Not a good practice to follow. When you stop working on something else and spend some time with an idea, it can take over. The idea snowballs and then before you know it, you've grand plans for it and it overtakes everything else you are doing. Inevitably my workload becomes so much that I need to try and prioritise and sort my work into a schedule that can't feasibly accommodate this new idea. What to do?

Well the answer is simple. From now on for every project I take on I need to drop something else. Realistically I can only manage one side project at a time on top of freelancing and family life. When I take on too much everything else suffers. It's a balancing act.

The monthly themes I am doing just now are good for balancing work as it means that in one month I can focus on a single idea or product for that time. Since the start of the year I've used broad themes to cover everything but this month I'll be focusing on a specific project. It's the first of four projects that I'll be working on this year. The goal is to clear the backlog of tasks for that project so that it can be left alone for another few months while I bring another few projects along.

This also means that I can schedule these ideas into the year so that I know what work lies ahead in my schedule. Not only is this good for scheduling purposes but the idea also gets a chance to incubate for a few weeks or months before I start on it. By then I might have discounted the idea will then pick something else to work on.

Complicated Software

Complicated software looks like hard work, but does that make simple software easier. I would say no. In fact I think it's harder to produce simpler software than complicated software.

At the weekend I got into a conversation with my Dad about complicated software. My Dad is a draughtsman. He puts together the drawings for piping installations such as refineries and oil rigs. He uses software on a daily basis for his piping designs, but it wasn't always done this way. When he started in his career nearly 40 years ago there wasn't a computer to be found near the desk of any draughtsman. Everything was done with pen and paper. Simple tools by today's new tool of choice, CAD software.

Over the last couple of decades the mouse has replaced the pencil as the draughtsman's main tool for work. In this time the market for CAD software has boomed and with it come some of the most complex software I have ever heard of. My Dad has made the gradual change to CAD over the years through a number of training programmes and plenty of on the job experience. His biggest bug bear though is the software. In his opinion it is too complicated.

For over a decade now I've heard many complaints against software being too complicated. Complicated software isn't the root of the problem though. Software starts with people and what those people want. These are the initial requirements of software, what we expect it to do. Given enough time, and no constraints, any software product can go from simple and easy to use to bloated and complicated. In the past it was thought that a software product rich in features was the way to sell it. What happens over time though is that the product continually grows and grows as it caters to more and more requests until it becomes just too big and complicated to use. Those original features that made the software a hit have become bogged down by other quick hit features that only cater to a small subset of users.

We software developers are a bit older and wiser now though and we've learned a lot from those first days of commercial software. The main thing I think many software developers have learned is that it is okay to say no to a request. This is perhaps the hardest thing to do, we want our software to be used by many, but that doesn't mean catering to every request. Saying no to nine features, but yes to one is our way of saying that we care about the software we produce. If a feature doesn't fall within the general mantra of the software then we should say no to it. Yes, we might gain a few more users, but in turn we could end up annoying half of our existing users.

The thought of complicated software has made me re-assess the projects that I am working on and how they can be simplified for the people that use them on a daily basis. It's also made me question requests from clients for changes to their products. I could simply take the money and add the new feature, but by questioning that feature I could be opening a new discussion with the client to find the exact source of the problem and deliver a solution that will simplify the software instead of complicating it.

Plain and Simple Bookmarking

I seem to have a love/hate relationship with bookmark managers. I like using them yet I find faults in each one and end up disliking them. Can I find plain and simple bookmarking service that let's me just search?

Bookmarking services. I've used a fair number of those in my time. Remember Delicious? Those were good days. I do and since then I've tried a number of different services including Google Bookmarks, Pinboard, and I even tried to roll my own bookmarking service a couple of times. Each time I tried something new though it felt like it was just over the top.

I never wanted to manage a collection of separate bookmarks, I just wanted a somewhere I could store them and find them. How they got there wasn't the problem, it was how I found them that mattered. Lots of bookmarking services tagging as a way of grouping your bookmarks, but do we need to tag our bookmarks if they can already be found with a good search facility?

You might have noticed a new addition to the blog in the last few weeks. At the top of the page beside the main navigation links there is a search box that you can use to search my blog. This isn't a feature of the blogging software I use, this is an external service called Searchpath. It indexes the content of your static site and gives you a plugin for your site that let's you search on your site's content. I've been using this for a couple of months now and the results of the searches have been good. Anytime I've needed to find something, I can using the simple JavaScript widget that sits at the too of my site.

After a couple of weeks of using this I wondered if it could also index other pages. Pages of bookmarks perhaps?

So last week I finally got my collection of bookmarks out of a database and converted them to markdown files grouped by the month they were created in. From here I then set up a page on my site that listed each months worth if bookmarks. You can find this new archive here.

How I add to this collection is simple. In my toolbar I have a couple of bookmarklets. One coverts the URL to the page to a markdown link and the other converts the entire page to markdown. I use the link bookmarklet to get the link for the page I want to bookmark and copy it to the clipboard.

I keep the this months file open on my desktop using the wonderful Marked application. If I need to add a bookmark, I simply press the edit shortcut key in Marked and my markdown file appears in my editor. Once I have my bookmark file open I simply append the new bookmark to the bottom, add any notes and save it.

The last part is the indexing of these bookmarks. Searchpath looks for links in site and follows them through to find pages to index. I'm interested to see how this change to my bookmarking routine works out. It's taken me to now to realise that I don't need things like tags, favourite bookmarks or even grouping bookmarks by a collection. I just need a place that allows me to search through them when I want to.

Back on the Course

Yesterday was such a glorious day in terms of weather. An ideal day to get Ethan back out on the golf course. Unfortunately the course is still a bit damp from the last couple of weeks of rain but hopefully it will dry out soon.

Teeing off at Lexwell

Logitech K811: A Review

It's been a month now since I started using the Logitech K811 keyboard. The reason I made the switch was that my old Apple keyboard was getting rather old. Five years is a long time for a keyboard, in fact it's probably the longest time I've ever owned a keyboard. As a result the keys on the keyboard were sticking and one of the keys needed a fair amount of beating before it would register the key press. I needed a new keyboard.

Two things the new keyboard had to do. Be OS X compatible and wireless. Anything else after that is a bonus. After looking at a number of different keyboards I filtered this down to a number of keyboards from Logitech. In the past I had a Logitech keyboard when I worked as an ERP developer. This was a great keyboard, so I started to look at the rest of Logitech's range. The K811 stood out for a number of reasons.

My Logitech K811

The keyboard itself is light and while it doesn't exactly match the build quality of my Apple keyboard, it has been sturdy enough for every day use. The top of the keyboard has a plastic backing while the rest of the keyboard has a nice aluminium finish. It's a shame the aluminium finish doesn't extend to the whole of the keyboard. There is also a greater degree of flex in the K811, but then that it would take a great amount of pressure to snap the keyboard this way.consists of an has a small profile. The K811 is thin and doesn't have as steep an angle as the Apple keyboard. Looks wise it's definitely up there with my old keyboard.

The keyboard can be charged using a USB cable. This is good but in the last month I've had to charge the keyboard three times. This maybe partly because I've left the keyboard on when I leave my desk. If I turned it off when I wasn't using it then it would probably extend the life of the battery between charges. I'm not going to worry too much over this though as it does mean that I don't need to replace the batteries for it.

Another nice feature of the K811 is that you switch between multiple devices at the touch of a button. With my iPad almost unusable (long story), I haven't used this feature although when it comes to getting a new iPad, it's good to know that I'll be able to switch between my iPad and my MacBook if I need to.

The last thing that I like about the keyboard is the backlit keys. My hours of work can vary from day to day and during these dark winter nights it's been good to know that my keyboard is easier to see when I'm working late with just my desk light on.

The only real gripe I have with the K811 is that the connection to my MacBook cuts out about once a day. I've searched the support forums on Logictech for a resolution to this but I've yet to find one. The connection does come back after a few seconds, so I'm not going mark this as a big drawback to the keyboard.

Other than that the K811 has been a great keyboard to use so far and is definitely a worthy replacement to my old Apple keyboard. It's more expensive than an Apple keyboard and maybe not worthy of the price difference but I was happy to fork out the money to get something that would work for me on a daily basis and offer a little bit more than other keyboards do.