Matthew Lang

Over the weekend, I wanted to build something with Hanami. I wanted to build something with Hanami more as a learning exercise than anything else. I had a bookmark manager written in Rails that has been languishing on the side, so I thought I would build something a bit more functional using Hanami. I called it Laurel.

Bookmarks usually build up for me. I wanted to build a way to resurface bookmarks so they can be acted on. It’s something I didn’t have in the previous bookmark application. I also didn’t want to be distracted by using background processing. Any methods that calculate ranks or anything else like that will be handled during the request.

This isn’t my first Hanami project. I built a couple of smaller applications a couple of years ago, but I never kept them because they were just a way to see what Hanami can do.

Getting the project started was familiar. Typing bundle exec hanami new is almost the same as kicking off a new Rails project. Once I had a blank application set up, I started looking into the code. It has similarities to Rails, but also differences.

I’m not going to delve into the experience of using Hanami or compare it to Rails, but I enjoyed using it, and the developer experience is good.

As for the project’s goal, I eventually finished it on Sunday night. It includes the following features:

• Capture: add/edit, tag, import
• Curate: the digest page, Elo comparisons, evergreen marking, archiving, snoozing or ignoring bookmarks
• Decay: the HN-style ranking score

The digest page is the real workhorse of the application. Here you can decide which of the two bookmarks is more important and also action other bookmarks that appear on this page. Being able to action bookmarks over time with the archive, snooze or ignore buttons is more helpful to me and actively curates the collection.

The difficult part was deploying the application to Hatchbox. I originally had an error in the application that appeared only in the production environment, not the development environment. I eventually resolved this issue, but I still seem to have a deployment issue: it requires a restart after deployment, and I’m sure this is a mistake on my part when setting up the application.

I’m going to definitely keep using this, and over the next few weekends, I’ll be adding more features and hopefully resolving that deployment issue on Hatchbox as well.

I started working on a new bookmark manager tonight using the Hanakai toolset. It comprises the Hanami framework, Dry validation library and the Rom persistence toolkit.

This little project has two goals. The first is to learn Hanakai. Ruby on Rails is a reliable web framework, and I’ve used it for over 15 years, but I want to try something different. The second is to try something different with a bookmark manager. Instead of just saving bookmarks and forgetting about them, I’m going to try to build a bookmark manager that resurfaces bookmarks over time. It will do this on a schedule and based on bookmarks that fit the criteria for being resurfaced. The idea is that, over time, you’ll weed out anything that isn’t relevant and be left with only the bookmarks that matter.

I initially envisioned this as an email workflow, but I’m going to keep it simple and display the decision in the web app. Email would have meant building the sending infrastructure, but I didn’t want to deal with that this weekend.

The fundamentals are already in place. I will be dipping in and out of this over the weekend with a view to having something to deploy on Sunday night. The final decision screen will be for me only, but I’ll follow this blog post with more information on how I got on.

I’ve run my own bookmarking app for a few months now, and it has the same problem as every bookmark manager I’ve used. Nothing ever resurfaces. Save the bookmark, forget the bookmark.

That’s really two problems in one. First, bookmarks aren’t all the same. Some are evergreen and worth keeping forever. Others, like anything about a web framework, are stale within a year or two. I end up with two collections tangled into one. Second, managing bookmarks at scale is a chore. Bulk-editing helps — filter, select, update — but it doesn’t solve the deeper issue. I never revisit anything on purpose.

Over the weekend I sketched an app that tries to fix that with a daily email. Each one asks a simple question about these bookmarks. Which still matters? Whatever you pick gets a new lease of life. Whatever you skip goes back into the pool for another chance later. Miss a bookmark enough times in a row, and it’s archived for good — no more resurfacing, no more guilt.

I’ve also been itching for an excuse to build something real with the Hanakai toolset, and this feels like the right fit. I have no idea if it’ll become an actual product, but it’s a fun problem to build, and it should get me using my own bookmarks again.

It’s been quite a week for GitHub and not in a good way.

It’s no secret that GitHub outages have been more frequent recently. The Missing GitHub Status Page definitely paints a more accurate picture of the outages that GitHub have been experiencing.

This week, Kev Quirk shared his reasons for migrating his public repositories away from GitHub to Codeberg. While he acknowledged the significant downtime, Kev’s main reason for leaving GitHub is to reduce reliance on big tech.

Recently, Mitchell Hashimoto, author of Ghostty, also indicated that the Ghostty project will be moving away from GitHub. Mitchell cited the increasing outages of GitHub as being the main driver behind the project moving elsewhere.

My move away from GitHub stemmed from a sense of division between work and personal life. I use GitHub for work and for personal projects. Despite using separate laptops for work and personal, I actually have the same GitHub account for both. So while I changed my laptop, the GitHub account was still the same. GitHub was convenient, and that convenience blurred the line between work and personal. Eventually, I found myself tuning out more on my personal projects as I felt I was still in my work environment in GitHub. It was time to consider another place for my personal projects.

GitHub’s centralisation made it hard to consider leaving. Everything is already there. All the popular open source projects, lots of social features and thousands of developers that you can follow. I imagine it’s the Facebook for developers (even though I don’t have a Facebook account).

I started looking for an alternative platform to host my projects on and eventually settled on Sourcehut.

Yes, it lacks several features that are perhaps taken for granted in other platforms like GitLab and GitHub, but it was this minimalism that attracted me to the platform. It just had the essentials that I needed. Git hosting for my projects and the ability to track tickets for those projects. I can still manage my personal projects with ease, perhaps even easier now that I do everything through the terminal.

As for the social side of GitHub, I don’t feel I have missed out on anything by moving to SourceHut. I’m still keeping up to date with new open source projects and libraries through the different RSS feeds and newsletters I subscribe to. As for people, I subscribe to their blogs. If it’s important, they’ll write about it.

GitHub’s recent outages have sparked several conversations on websites like Hacker News and Lobsters. It would be easy to identify outages as the main reason people are moving away from GitHub, but clearly, it’s rarely the whole story.

I’ve been building a fair number of Rails applications using Claude Code recently. Here are a few things I have built in the last few weeks using agentic coding:

1. An application to support my Jekyll blog - This application replaces the Micro.blog features that I lost when I cancelled my subscription. I can now blog with just my phone if needed.
2. A bookmarking application - I’ve wanted this for a while, but it’s only been in the last few weeks that I’ve got round to this. It uses an algorithm to age bookmarks over time so I can keep an eye on the front page. If it falls off over time, then whatever. It beats the traditional bookmarking apps I have used in the past.
3. A dashboard of my projects - I use a slimmed-down version of Shape Up for my projects, but the hill chart feature in Basecamp is something that I find really useful. I’ve been implementing a similar tool for my own process.
4. An authentication portal for all of the above - This is a very recent addition, and while it’s not quite complete yet, it aims to remove the hindrance of having to remember different logins for different applications.

Agentic coding has made it much easier and quicker to iterate on personal applications. The productivity gains from this have been great, and the fact that these are just personal applications for me means I don’t need to worry too much about making the code understandable to others.

My recent adoption of SQLite3 as the database for these types of applications has made them much easier to manage and more cost-effective to run. As these applications are only for my use, I don’t need a dedicated database server; I can run the application on a server, and the SQLite database can sit in a shared folder for each application—a significant cost saver. Also, since each database is just a file, I can back up these files to another directory or copy them to my laptop as a backup.

What’s become clear from building these applications, though, is that I am trying to build some memory with these applications. The support application for my blog keeps me from losing the friction-free posting I had with Micro.blog. The bookmarking application provides an immediate picture of my recent bookmarks. The dashboard application provides context on where I am with my projects, and the authentication portal eliminates the need to remember multiple usernames and passwords. These applications not only help me on a technical level but also save me a lot of time by letting me avoid having to remember certain things.

Yes, these applications are built using agentic coding, tailored to what I need, and are most likely useless as open-source applications for others to use. Still, they work for me, and that’s enough—personal tools that fit my way of thinking, something that many SaaS applications can’t do.

As a relatively late adopter of AI tools, well, amongst software developers anyway, I am slowly coming round to the benefits of AI. Like most people, I started with the big-name AI tool, ChatGPT, but it didn’t take me long to discover Anthropic and their Claude and Claude Code tools.

Over the last six months, I’ve been a heavy user of Claude Code. It definitely provides serious productivity gains. Here are a few examples of where I have used Claude Code in the past few weeks.

• Upgrading a couple of Rails applications from 7.0 through to the latest 8.1 - The Rails upgrade process is fairly straightforward, and I’ve done quite a few upgrades over the years. Using Claude Code with this has sped up the upgrade process.
• Re-starting development on Dailymuse - work on this has been slow over the last couple of years, but the last few months have seen some big changes in my micro-product.
• Exploring Hugo and Jekyll themes - I had been working on a Hugo theme I planned to use on Micro.blog, but since moving to self-hosting, I have migrated this over to Jekyll.
• Built supporting tools for my blog - Self-hosting with Jekyll is easy, but I wanted to still have the option of hosting images and posting on the go as I used to with Micro.blog. I managed to build a number of these features to support my Jekyll blog over the course of a week.

The accelerated pace of development is probably the first thing software developers notice when using AI tools like Claude Code. You can build features and even applications at such a rapid pace, which is good, but it’s also been a red flag for me since I started using these tools.

With increased production rates, I am concerned about retaining the knowledge of what I am building. Will I know enough about the code base to support it in the future? When my code breaks, how will I know how to fix it?

I am exploring a few ways of ensuring that I know the code that I am shipping, including:

• Taking notes on code changes, especially in areas of the code base that are important and application or business-critical.
• Adding more comments to my code - this might serve the AI tools more than me, but having comments throughout the code does give me a quicker understanding of the code I am adding and where I am adding it to.
• Spending more time reviewing code — especially AI-generated code. What is this code doing? Do I understand it? Can I make this code better? Is this code even suitable?

There are other ways I can improve my retention of the codebase, and yes, AI tools can help with that. However, as good as the AI tools are, there still needs to be human understanding of the codebase to make the right decisions about future changes, and that begins with understanding the code and ensuring I retain enough knowledge about it.

After a few years of being on the Micro.blog platform, it’s time to host my own blog again. I’ve thoroughly enjoyed hosting my blog on Micro.blog, but I want to have more control over what my blog does for me.

Having my blog on Jekyll wasn’t enough, though. I needed to be able to blog from my phone if needed. So, over the last couple of days, I have been building a Rails app that helps me to do what Micro.blog offers. I’ve tried to do this in the past and failed miserably, but this time I’ve added enough knowledge to know what I need.

The Rails application handles two important steps that I need to continue blogging about when I have my phone.

Uploading and hosting images

The first is the uploading and hosting of images. I previously included all images in the blog itself when I last ran my blog using Jekyll. As expected, it led to some seriously long build times for Jekyll.

The new application allows me to upload and serve all the images for my blog. Each image is saved in different sizes, and I’m using an LLM to generate alt text as it’s uploaded.

This allows me to manage uploads separately from the blog itself and keeps the blog’s build time fast.

Posting on the go

The second is creating posts on the go. I previously did this using GitHub’s web interface, pasting the post directly into my repo. Not exactly straightforward, and it worked to an extent, but it became more of a chore than anything else.

The new application allows me to compose posts on a much friendlier web page. I can save the post as a draft and come back to it later. When it is ready to publish, it commits the post directly to my blog’s repository on SourceHut, where I have a build script to deploy the code to my server after each commit.

What I’ll miss

Yes, features are missing from my setup, like cross-posting, bookmarks, and bookshelves, and over time, I might replace them with my own take on these features. For the moment, though, I’m quite happy knowing that my blog is back to being something I have full control over, and I have more of a say in how it’s built and displayed.

And yes, this means I have parked the three-column theme I was building for Micro.blog. I doubt I will finish it. Apologies if you have been looking forward to it.

I will still be keeping my blog pointed at the Micro.blog community and I wish nothing but success for the platform. It’s a great community, and I hope it continues to grow.

I’ve been messing about with builds on SourceHut for the last couple of days.

Yesterday, I got a build script working that triggers a deploy for a Rails application over at Hatchbox. It’s the last part of a release script I have put together that automates deployments for me. I can see myself using this in other Rails applications as well.

This morning, I got a build script working to build and deploy a Bridgetown site using SourceHut’s built-in static hosting. I could have had a Jekyll site running probably in half the time, but I was curious to see what Bridgetown offers for static sites. It involved a bit more in the build script, but the site is working now. No idea yet, what I will do with the site, but it’s good to know I can use Bridgetown.

Most importantly, I feel I have rediscovered an interest in my side projects over the past week. Between using Zed, Claude Code and SourceHut, I have been hacking away at various little scripts and ideas just to automate a few things and broaden my programming knowledge a bit and dare I say it, thoroughly enjoying it.

Over the holidays, I gave my writing prompts website, Writeabout, a wee freshen up.

Previously, Writeabout was just a single page that displayed a random writing prompt on each page refresh. Simple, yes, but the design would not allow me to easily expand the website.

I started over with a simpler design. Display the most recent writing prompts in date order, with the added ability to explore other prompts through tags. A simple admin console on the backend lets me add and update writing prompts, and upload a batch of prompts so that future prompts are queued.

It might seem almost redundant to have a website with a collection of writing prompts that could easily be replaced by any popular AI tool. However, over time, my plan is to curate and build collections of writing prompts that retain an element of human touch in their creation.

Also, this new version of Writeabout uses Rails 8.1, my first venture into a Rails 8 codebase in production. It will also serve as a learning platform for me. I’ve already opted for a “no build” approach to Writeabout. So it’s out with Tailwind CSS and in with plain-old CSS and JavaScript.

Update: Writeabout was retired in Autumn 2026.

After my recent decision to scale back on GitHub issues and pull requests, I’ve found some traction again with plain-text files.

In a couple of Rails applications, I have a docs folder where I store several Markdown documents that serve as guides for some of the code. To this, I have added three files, FEATURES.md, BUGS.md and PLANNING.md. The features and bug files are self-explanatory, but the planning file might need some explanation.

GitHub has a feature called milestones that lets you set an end date for a milestone. You can also add issues to a milestone. I always thought it was a nice feature that mimicked a sprint from agile methodologies like Scrum.

The planning file contains the sprints I have set out for the next six months, with each sprint listing the planned features and bugs I will work on. It gives a nice top-level view of what’s ahead and is easy to update.

I’m still in the early days of this plain-text switch from GitHub’s own features, but I’m already seeing benefits. The files live in the application’s codebase, so updating them is easy in a text editor. Having these files in the code base reduces the amount of context switching I need to do. Features and bugs can be planned in one pane, with any related code being open in a neighbouring pane, side by side.

Finally, the files are plain text, so they can be manipulated by any scripts. I am considering an auto-generated HTML file that provides an overview of the project’s status. It would include the number of open issues, a roadmap for the next few sprints, and any open bugs.

The planning tools that cloud-based products like GitHub and GitLab provide are fine, but are definitely overkill for what I need. Making do with plain text files isn’t a step down; it’s just an easier way for me to manage these projects with minimal overhead.

All too often, I would start a new project on GitHub, only for it to gather dust. It’s one of the reasons I moved my personal projects to SourceHut: I don’t need the social interactions GitHub provides. I still have a couple of larger Rails applications that I host on GitHub, using a separate account.

A minor revelation struck me last night when I was trying to merge another pull request for one of these Rails applications. I probably don’t need to merge this pull request or any other pull request. Since I’m the only one with access to the repository, I can skip creating, monitoring, and merging pull requests and simply use git merge when I am ready to merge the branch into the main Git branch.

Why am I even using issues, projects and milestones in GitHub? Again, it’s just me on the repository, and I don’t need to collaborate in the sense that GitHub allows.

The only reason I am left with using GitHub is that the hosting provider my Rails application runs on uses Git to track changes and automatically deploys them to the server when changes are detected. I have it set up to use GitHub.

Suppose I can handle deploys on another Git service or even from my local laptop. In that case, I can switch away from GitHub for this account.

Still, when it’s just you and the repository, you probably don’t need several of GitHub’s features or even GitHub itself. Just a remote Git repo, and there’s plenty of other options out there.

Yesterday, I mentioned that I had created a Slack account just to send webhooks to and that perhaps there was a better way of doing this. After a few hours, I have managed to put together a tool for consuming and monitoring webhooks.

Hooknook (working title) allows me to create channels and send webhooks to different channels. I’ve still got some details to sort out, but the basic application works. Users and channels are made through the Rails console at the moment, and a single endpoint accepts all webhooks coming in. It’s the absolute minimum I could do to get it to work, and now it’s happily accepting webhooks from my Hatchbox deploys.

I used Anthropic’s Claude to flesh out the structure of the application to begin with, and once I had it working, I used Claude again to add some TailwindCSS styling to the screens. These screens are definitely going to get a once-over again, as the purple is a bit garish, but my wife seems to like it, so it might stay, but be a bit more subtle.

It’s been a welcome change of pace to be able to build something in a short space of time, and even better to be able to use it.

Over the next couple of weeks, I plan to explore adding more functionality for Hooknook and being able to handle more webhooks from different sources, including GitHub.

As part of my plan to learn React, I’ve been building single-page HTML applications that use local storage to persist any information between sessions. As a start, I built a roulette wheel for our team at work to determine who goes first during stand-up each morning.

I have since moved on and created applications for a technical log, a start page, and I have a few other ideas brewing. The persistence to local storage in the browser is common between all the applications, but I’m trying to build different ways to interact with these applications so that I can learn more about React.

Next week, I hope to develop a replacement for the Excel spreadsheet we use to track our OKR goals at work. The Excel spreadsheet is functional and certainly doesn’t win any prizes for looks. I thought this would be a good learning project to tackle in React, as the formulas we use would enable the page to be more dynamic.

There’s a difference between what to build and how to build. I hadn’t given it much thought until today, when I started to realise that I could improve the time it takes me to make an image template for a product of mine by automating the creation of the different classes and modules needed for each image template.

I spent an hour tonight working on a script that generates all the necessary code I needed. In addition to creating each code file, it also generated the absolute minimum amount of code required for each file to run successfully.

When building products, I’ve always prioritised what to build over how to make, but I need to start splitting my time more evenly between the two. Spending time on one can have some profound benefits for the other.

I’m pretty happy with the Hugo copy of my own Micro.blog theme I’ve been working on for the last couple of days. It will have a few customisation options for colour scheme and fonts.

I’ve been trying to clone the blank theme when creating this new theme in Micro.blog, but it appears to be using the Sumo theme from my current blog instead of pulling the blank theme from GitHub.

Hopefully by the weekend, I’ll have a working version for others to use.

In my foolish quest to build my own Micro.blog theme, I spent some of the evening learning about Hugo and how its theming works. It is not dissimilar to Jekyll in many respects, and I think I have enough to start working on my own theme.

Initially, I’m going with a really basic theme—no colours, frameworks, or complex layouts—just a single column with basic text elements. This will allow me to see what the minimum I can get away with for my theme is. That’s the easy part.

The hard part—it’s definitely not one of my strengths—is putting together a design for a second theme. Web design is not my strong point.

I want to make something that isn’t wildly unique, but has enough to stand out from the rest of the Micro.blog themes. I might let this one simmer away for a few days and check out a few other blogs I like and see what can be done.

This weekend though, the plan is just to have a basic working theme.

Today, during a major debugging session with a Rails application, I wanted to condense what was in the logs between two consecutive requests to understand what was happening. It was too much to read through everything. I just needed to scan through all these requests and flag whether they were successful or not.

So today, rather than scribbling down another Ruby script, which would have been easy, I started a log analyser using Rust. It’s early days for the script, but it already compiles a list of endpoints, which is a good start.

It’s a reminder to myself that there are plenty of development tools and aids I can build using a variety of languages and frameworks. And if I only use that tool a few times, that’s okay, too. At least I will have learned something.

I am in favour of Simon Willison’s “no build frontend” web development approach.

If you’ve found web development frustrating over the past 5-10 years, here’s something that has worked great for me: give yourself permission to avoid any form of frontend build system (so no npm / React / TypeScript / JSX / Babel / Vite / Tailwind etc) and code in HTML and JavaScript like it’s 2009.

I’ve been building Writeabout in Sinatra, and I’ve reached the point where I need to add a bit of JavaScript to allow the changing of the light, dark, and system themes. I already have these implemented in the original Rails code as Stimulus controllers, but I’m sure it won’t be too much work to rewrite them as plain old JavaScript.

I don’t have a favourable opinion of frontend web development. I’ve always found it unnecessarily complicated and constantly changing, but rarely for the better. For the last few years, I’ve used TailwindCSS because its build step in Rails applications is minimal—the productivity gains outweigh the added complexity. Beyond small learning projects, I’ve resisted adopting anything like React or TypeScript.

I migrated one of my two GitHub accounts to GitLab a few weeks ago. The move itself had nothing to do with missing features or pricing. It was primarily to try out something else that wasn’t GitHub.

At my job, I spend most of my days on GitHub. When working on my little projects, stepping back into GitHub feels like I am back at work again. With the lines blurring between work and personal coding, I started to think that when I spent time coding on my projects, it still felt like “work”.

So, for one GitHub account, I migrated that account to GitLab. It’s been a great move, and despite being on GitLab’s free tier, I can still match feature for feature what I was paying GitHub for. And when it comes to working with that account, I don’t feel like I am back at my desk.

After the move, I considered moving my other private repositories to GitLab, but GitLab would be more than I needed. It has many great tools for maintaining code bases, but I don’t need them for smaller projects.

I needed something other than GitHub or GitLab.

Enter SourceHut, created by Drew DeVault. SourceHut is a collection of open-source development tools that are a good alternative to GitHub and GitLab.

I’ve been considering using SourceHut for a while, but I have only started seriously considering it in the last couple of weeks.

Today, I created my account and initialised a single repository to get me started. A much more straightforward and basic user interface is strange, but it works. I have become accustomed to the feature-rich user interfaces of GitHub and GitLab. While SourceHut lacks many of the features found in the two bigger platforms, the simplicity of the SourceHut user interface makes it refreshing to use, with just the essentials.

Over the next few weeks, I will migrate more repositories, and then I can demote my GitHub account to be used only for work.

Over the weekend, I spent time getting my GitLab account, working with a single repository, and migrating the CI script from GitHub to GitLab.

The biggest issue was the CI script, and why shouldn’t it be? There’s rarely a “one script fits all” regarding CI scripts. When I started this project, I had issues getting the CI script working in GitHub. After a few pushes on the one branch, I eventually got there. Migrating this script to GitLab’s CI ways was more straightforward than I thought, but I still had a few issues I managed to resolve.

In addition to all the usual source code management goodies that GitLab offers, a few stood out.

Private repositories are available on GitLab’s free tier. Having used GitLab in the past, I already knew this, but it’s refreshing to see that GitLab is sticking with offering this feature on a free tier.

Feature flags are available on GitLab’s free tier. They are a means of configuring how your code behaves by using toggles and checks to ensure that it only carries out certain functionality. I have a number of feature flags in my application, but they are all based on a YML file in the source code. I will be migrating these to GitLab, though, so that I can toggle them without having to deploy any changes to the YML file that controls them.

Error tracking is available on GitLab’s free tier. Previously, I used Sentry for this, but GitLab also uses Sentry under the hood for their own error tracking feature. Yes, I can probably get more information by having a dedicated Sentry account, but at the moment, I am just checking to see if users raise any errors in the application.

For developers building on the side, these features on GitLab’s free tier are of great value and definitely swing my vote from GitHub to GitLab. Over the next few weeks, I hope to migrate the feature flags over, use more of GitLab’s platform, and see what it can help me with.

When I was freelancing, one of the things I did regularly was read the ThoughtWorks Technology Radar. It’s a snapshot of the different technologies that ThoughtWorks is considering and using. As a freelancer, I found it a good read as it provided a glimpse of what was happening in the web development industry. Once I started working full-time again, I stopped reading it and didn’t revisit it for a few years.

My current role is senior software engineer, but I am working towards the next role up from this one. This involves expanding my role in several ways, including learning and adopting new technologies and processes. One way I thought I could do this was to set up my own technology radar. ThoughtWorks does offer a means to run your own technology radar, but I wanted my own technology radar to be more straightforward.

Armed with my new knowledge of using SVG over the last couple of years, I decided to start building a technology radar of my own.

My technology radar comprises two layers of quadrants, the smaller quadrants on top of the bigger ones, to achieve the effect of having an outer trial quadrant and an inner adopt quadrant. I used the path element to do this.

<path d="M 10 45 A 40 40 0 0 1 45 10 L 45 25 A 30 30 0 0 0 25 45 Z" fill="#e3f2fd" stroke="#2196f3" stroke-width="0.5"/>
<path d="M 20 45 A 25 25 0 0 1 45 20 L 45 45 Z" fill="#e8f5e9" stroke="#4caf50" stroke-width="0.5"/>

The tokens representing the different individual items are simply circles and text elements nested under a group tag so that I can group all the items together.

<g transform="translate(40, 35)">
  <title>TDD</title>
  <circle cx="0" cy="0" r="2" fill="#4caf50"/>
  <text font-weight="bold" x="0" y="0.5" font-size="1.5" text-anchor="middle" fill="#fff" font-family="Arial, sans-serif">2</text>
</g>

I added a title tag to each token to achieve a hover effect with a text description of the token.

Finally, I added labels to the middle of the quadrant to indicate the two sections and each corner to indicate the type of technologies grouped in that quadrant.

I haven’t figured out how to programmatically group tokens in each quadrant with code, so for the moment, I am using SVG Viewer to place tokens in each quadrant by hand.

I have published a GitHub Gist of the technology radar with blank tokens filled in for one of the quadrants. Feel free to fork this technology radar for your own needs.

You can find my own technology radar here. I’ll be updating it as the year progresses.

Update: The radar has since become my Learning Log, a simpler record of what I am trying, using and have dropped.

This week, I spent most of my free time adding an NPC character to my ThreeJS game and have them walk towards me each time I move my own character.

I’m using the A* algorithm. Each time I move my own character, the NPC finds the shortest path to my character using this algorithm and then moves one step to my character.

As I’m already using a two-dimensional array to represent the game’s board, using the algorithm on this array helped me get it working. What I wasn’t prepared for was the amount of code needed to implement the algorithm and move the NPC across the board. Still, I managed to learn a thing or two more about TypeScript.

What’s next for my game? I’m not sure yet. There are so many things that I could be doing, such as adding attributes for my characters, both PC and NPC characters, and adding more elements for the map, like ancient ruins. My youngest is also designing skins for the playing character and the NPC, so they’re more than just coloured rectangles on the board.

Now that the golf season is down to me and the boys only getting out at the weekend, I can start spending more time on a few side projects. There are so many things I would like to learn, but I figure just limiting myself to a couple won’t take up too much of my time.

So, from now to March, I’ll spend a few hours each week on the following.

• Learning more about Rails 8 and Kamal — Dailymuse and Writeabout will each get a bump to Rails 8. Only Writeabout, though, will get the Kamal) treatment to begin with. When I have gained enough knowledge about Kamal, I’ll also look to deploy Dailymuse with Kamal.
• Learn TypeScript and ThreeJS — A work colleague showed me a hobby project he is working on using ThreeJS. It’s the perfect excuse to learn TypeScript and build something for the web that isn’t just another web application.

Update: Writeabout was retired in Autumn 2026.

Over the last few days, I’ve been writing more JavaScript than usual. The reason? I am using Stimulus a lot more in one of my Rails projects.

Enhancing the functionality of my Rails application with some HTML markup and a JavaScript controller is good, as Stimulus has a small learning curve and integrates well with Rails.

As I add more Stimulus to the application, though, I am learning some of its best practices the hard way. One criticism I have of my own controllers is that they are very page-specific. That’s fine for now, as the application is relatively small. Still, I plan to break these controllers into more generic behaviours that can be re-used more easily across the application in the future.

Over the last few weeks, I’ve been migrating several Rails applications to Hatchbox. I’ve still got a couple of applications to go. Still, one last thing I wanted to do was migrate my blog over to DigitalOcean’s Apps platform.

I’ve been using Render to host my blog for the last few months. While it’s free, and I have been okay with using it, I’ve wanted to minimize my digital footprint of the services I use. Over the weekend, I spent almost eight hours trying to get my blog to compile and run on DigitalOcean.

Sadly, my blog wouldn’t compile due to the Tailwind integration I am using. An error with the Jekyll PostCSS gem kept breaking the building of the website. I’m still digging into the actual issue, but it is getting parked until I have more time to look into it.

Tonight, I’ve been building HTML templates with Tailwind to integrate them into a CMS of sorts using Rails. Is it a product? No, it’s just me hacking about on a wee Rails app and trying to brush up my skills once more. The last time I genuinely enjoyed doing this was a good couple of years ago.

So what prompted this change?

Well, the main reason is that I’m enjoying my job now. It’s full-time, but I’m also fully remote, so cutting out the commute has been a big win. There’s something to be said about working from home. It definitely suits me better than being in an office. I don’t mind being in an office environment, but the distractions can put your focus off a bit, depending on where you work. Working from home means, I can get my head down and get on with the work.

I’m using Ruby on Rails again. It’s not the most recent version, but I’ll take working with any version of Rails over working with just about anything else at the moment.

While working remotely, I am in a close-knit team that regularly checks with each other throughout the day. Although being remote has its benefits, you do need some contact with others throughout the day. Although Slack isn’t the ideal medium for this as it is pretty distracting, being able to meet and discuss with your team members regularly throughout the day breaks up the day nicely.

As a result, I’m finding myself reaching for the laptop more at night and hacking on Rails or Laravel apps. Now, if you don’t mind, I need to finish this little bit of code before turning in for the night.

I’m posting a short post tonight as I’ve been spending the evening setting up a Hatchbox account and migrating the first of a handful of Rails applications to it. The setup was straightforward, and after 45 minutes of tinkering, I got my Writeabout app running on it. I’ll try to move a couple more applications over tomorrow.

Update: Writeabout was retired in Autumn 2026.

Over the last few weeks, I’ve been re-writing a small product that I spent sometime building before lockdown.

The product has been gathering dust since the start of lockdown. It does have a handful of customers and generally good feedback from those customers, but I wasn’t happy with my first pass at it. There were so many things that I would do differently if I could start it over again. So I decided to have another go at it.

I’ve made pretty good progress so far and will be able to launch it again in a few months.

I’m currently following through the hotrails.dev tutorial series so that I can build an admin section for the Writeabout website.

For too long, I’ve just updated Writeabout’s prompts using the Rails console, which is fine. Using a web interface, though, would make it a bit easier for me to add prompts.

Update: Writeabout was retired in Autumn 2026.

This morning I finally resovled an issue with a Rails application of mine.

After a couple of weeks, of getting an hour every other night to resovle this, I finally understood what the problem was and how it could be fixed. A bug? Not necessarily, it was more of a lack of understanding on my part. The issue is fixed now and I can now crack on with other elements of the application.

It’s always good to use good tools for the job. In my case, I’m back to using a Macbook Pro and macOS as my development machine and operating system. It’s also great that I am working with Ruby and Rails once again.

The downside to using the tools is that they are the same tools I use to write web applications in my spare time. I enjoy hacking on ideas for web applications and using them for my own use, but I’ve noticed that the lines have started to blur when I use other tools.

Take for instance, source code management. I’m now using the same source code management tool for both work and my own projects. With source code management being a big part of my workday, I don’t enjoy using it the same way now for my own projects.

If I’m to continue enjoying hacking on my code after then, I want it to be an enjoyable experience. While I have no complaints about my job, it’s not a part of the day I want reminded of when it’s the evening or the weekend. I’ve been exploring different options for source code management over the last couple of weeks. I have decided to try out Gitlab for this over the next few months. It’s free, has similar processes to my current source code management tool, and integrates well with the hosting company I use for my web apps.

I’m also looking into other ways of using different tools or using the same tools differently. iTerm and Visual Studio Code are two tools that I use both at work and at home but finding alternatives to these is tricky when I use these tools really well. So instead of changing these tools to something else, I’m just changing how these tools look.

For iTerm, I have different looking terminals for work and home. It’s not much of a change, but the look definitely changes the dynamic of being at work and being at home.

I’ve also done the same with Visual Studio Code. I’m not going to look for a new text editor when I already use this quite proficiently. Instead, I am using the toggle extension in Visual Studio Code to change the theme and font settings for when I am at work and when I am home. A simple keyboard shortcut is now all it takes for me to change my interface from work to home.

Setting these boundaries between these contexts is essential as it creates a space for both. While I use many of the same tools, I do like to feel that I am in the correct mindset at the right time. That means using the appropriate tools for each and being able to distinguish between each. If the same tool has to be used for both, then a simple change of how that tool looks is all it takes for me to determine which context I am in.

One thing I have wanted to do for a long-time is to have a single checklist for the day that I can check items off for and then reset it for the next day. It doesn’t sound too difficult to do, but it never works entirely the way I would like it to in the various task manager apps I have used.

Many task manager apps re-create the tasks as they are crossed off the list. Now, that sounds fine for a single task, but when you have a bunch of tasks that you want to do daily, it can start to look slightly chaotic depending on the app. You may end up with tasks not completed from the day before, tasks completed for today, and some already completed for tomorrow.

I would like my list of tasks to stay completed for the day but not re-create the tasks for the following day. When the next day does come around, I would simply like to reset the checklist to start over again. I suppose the behaviour here is not to re-create the tasks but reset the list into a state so that it can be used again.

I created a page on my website that I can visit that contains a list of tasks with checkbox input elements that, when checked, are saved in the browser’s localStorage. There’s also a button there that, when clicked, resets all checkbox input elements back to unchecked. This allows me to start the list all over again.

After a couple of passes, I finally have it working now.

This morning I put the final touches on a Rails application that I planned to move from DigitalOcean to Render whilst upgrading it from Rails 6 to Rails 7. The actual change of platforms wasn’t too much of a problem, but the upgrade to Rails 7, and the third one that I have done, still presented me with a few issues. These problems were not too difficult to fix, and after an hour or minor tweaks, I managed to get the application up and running on Rails 7.

With this being the third Rails 7 upgrade I have done, I’m gradually building up a checklist that uses the Rails document as a base and includes a few other steps when it comes to moving away from Webpacker as well. This checklist will prove invaluable for another couple of Rails 7 upgrades that I plan to do over the next couple of weeks.

With a checklist, you know where you are and the steps you need to take. It allows me to do these upgrades in sections as well, so that I can do a few steps, take a break and then pick up where I left off, knowing what the last step was and what the next step will be. It’s a wonder I don’t use checklists a bit more. I know a few tasks are coming up over the next few months where a couple of checklists will be invaluable once again.

More checklists, please.

At the start of the year, I chose “build” as my word for the year. The single word strategy is the idea that you choose a word that will direct what you do for the year. Having not done this for a couple of years I wanted to go back to doing this so that I could at least focus on something for the year.

It’s mid-way through January and now seems as good as any to review what I’ve been building over the last two weeks and what I will be building in the near future.

My Twitter List Banner Maker (a mouthful I know) is now public on my GitHub profile. It’s far from complete but it’s working and with a few tweaks here and there can be used by others for their own lists. While building this I did learn a couple of things. Mainly, authentication with the new Twitter API, and also I improved my knowledge of RMagick by learning how to merge images together to change how they look.

In the background, there’s also a number of other things I’ve been building up.

• I am continuing to post to my blog during the weekdays to build an audience up again. I’m not looking to build an audience of thousands, just more people that like what I am writing.
• I am building a single document that will act as my playbook if you like for the day. A template for the day if you like. It’s been working well for me but it still needs some refining.

Looking ahead, over the next few weeks I am going to start building an application using the Blitz.js framework. A fellow developer from Glasgow put me onto this framework a week ago and I’m intrigued by the comparison to Rails but also that it’s a JavaScript framework and that’s one language that I am keen to build up my knowledge of in 2022.

The application won’t be too complex, a single-page application with a form that does validation and uses an external resource to look up information based on the data provided by the form. It was the simplest idea I could think of at the time and could be done within the next few weeks.

I’ll also continue to tweak the Twitter List Banner Maker so that it formats avatar images into a layout that is determined by the number of members on the list.

That’s enough for this month’s update. The next one will drop in mid-February.

I’ve been looking at my GitHub profile over the last couple of days. It seems like a graveyard of half-finished or throwaway projects that do not show my best work.

While I’m not in the freelance market and not looking for any roles soon, I would like my GitHub profile to reflect some of my better work. There are a few things I am going to do from now on to achieve this.

I have a backlog of projects that I’ve used for exploring different parts of Ruby, Rails and JavaScript. These primarily reside on my laptop and be shared for others to use with a bit of a polish. These projects are not, by any means, world-changing ideas. They are just projects that I used to try something out.

What I plan to do, is publish one project/application a month on my GitHub account. I will provide some instructions on running the application and any updates that I may do on it in the future.

I also have several other repositories on GitHub that are quite frankly just sitting there doing nothing, and they’re not worth much, so I’ll delete these from my account. There’s not much sense in having on my account if they’re not doing anything.

This month I’ll be wrapping up and publishing a ruby script that generates an image for your Twitter lists. I’ve been trying to get my head around the Twitter API over the last week and the different authentication methods needed to access other endpoints. After working this out on Wednesday night, I’m now making good progress with this script. I may try this out as a web application later in the year. I’m not sure yet.

That’s the plan anyway for my GitHub profile. 

I’ve been trying to re-organise my Twitter following into a few different lists, but I wanted to see at a glance who’s on that list, so I put together a Ruby script that gets the profile pic for each user on a list and creates an image from it.

I finally got something working that offers a little bit of flexibility when putting the profile pics on the image. It looks pretty good, but it could still do with some improvements. At the moment, I have to pass in an array of the list member’s usernames for it to work.

Ideally, you would supply the list id on Twitter, and the script would look up the list members on its own. Still, I’m happy with the end result from tonight’s coding session.

You can see the end result on my All things analog Twitter list.

Michael Wade explains the sidewalk rule and why we should build paths first.

Keeping things simple and action-oriented is difficult and yet if that orientation is not present from the start, it may be too late. Territory may already have been seized and boundaries drawn.

— The Sidewalk Rule

In a recent project, I took the advice of another team when setting up a new project and categorising the work involved based on a template this team used. In doing so, I complicated the project before it even began. I should have built paths first before building sidewalks.

It was one of those Saturdays where everything through the day just fell into place.

A code and coffee session early this morning yielded another milestone met. I managed to close off another couple of widgets for my CMS product. There’s just one more to go to switch out the old widgets for my new ones that offer better flexibility when it comes to putting pages together.

It was then off to the hardware store to get a few things for the garden. We missed out on a few things last year as we left it too late to get a couple of things, so we were quicker off the mark this year.

Back home, I spent a couple of hours getting the back garden into some shape for the summer. The next few Saturday’s are going to be similar as we get a few more things done, but the hope is that we put in the work now, to enjoy the fruits of our labour when the sunshine and good weather really kicks in.

It not often a Saturday just falls into place like this, but its been great having a productive day. I can kick back a bit tomorrow knowing I’ve got a few things done today.

It’s been a while since I last posted here. I’ve been getting my head down and working on my CMS product, which has left not much time for blogging.

Over the last few weeks, I’ve been putting in place a feature that should allow for more flexible page designs so that customers can use a series of widgets to build up pages. It’s a three-level form with a page with many sections on it, and each section has a single widget. The thinking is that the sections can be re-ordered regardless of what type of widget it holds. It hasn’t been without its issues, though. It took several attempts to get this overall widget design with the page in place.

Thankfully, that part of the feature is done, but I’m still working out some issues with this.

The main issue is when I add a new section and widget to the page, it clears any input elements that I have changed on any other sections widgets on that same page. The merry-go-round of possible sources of the problem includes the usual areas when things like this go wrong on the front-end—namely Turbolinks and Javascript.

The biggest problem just now is that of time, though. I don’t get much more than a couple of hours at a time working on this, and when I do, I feel that I am problem-solving the same things over and over again. It’s just as well that we’re still in a national lockdown here in Scotland because it does afford me some extra time to work on this.

Hopefully, I can make progress with it this week.

Over the weekend, I decided to re-install Sublime Text to see If there have been any substantial updates to it. I haven’t used it in a few years now since moving to VS Code.

The text editor remains snappy and fast as I navigated through a large codebase and made a few changes. Sublime Text was never a slouch when it comes to performance. It was always fast for me, even on larger codebases.

Intrigued, I turned to Sublime Text’s package control to see if there were packages there for Ruby and Rails and general web development. While I don’t really need these, there are nice to have in the text editor. What I found was quite disappointing.

Most of the packages that I have used in the past on Sublime Text have not seen much in terms of updates, with a few packages listed as missing. Clearly, VS Code has impacted the number of actively maintained packages as developers migrated from Sublime Text to VS Code when it first hit the scenes.

Although I’m pretty much baked into the VS Code ecosystem thanks to its huge library of extensions, I wouldn’t be against going back to Sublime Text. Maybe one day I will. For the moment, I’ll leave it on my Macbook and see what I get from it as a wee change to VS Code.

I’m trying to build a bit more flexibility into a Rails application by adding the ability to have multiple widgets on the one page.

From a presentation perspective, the problem looks easy. Any number of widgets for a page can be modelled to be presented as a complete web page. It doesn’t matter how the data is put together, e.g. flat files, canned models, hard-coded HTML.

What complicates the problem is how the user creates and manipulates these widgets to their needs. I’ve seen enough back-end interfaces for various products to know it can be done. The Mailbrew interface, which has similar functionality, is how I want this feature to work.

Instead of sitting at the text editor and blindly coding my way out of this, I’ve been using my iPad to sketch out a few ideas of how widgets of different shapes will relate to the page, and how a page will assemble these widgets. The problem is starting to unravel now.

Might be time for another coffee.

With the basics of my blog now in place, I can focus on other parts of the blog that I would like to build.

I’ve been writing notes for an aggregator of sorts that would subscribe to content streams. These content streams can then be shown on my blog. RSS would be the initial type of stream that I would offer as these are open and simple to integrate into the blog. Other types of content streams may follow if I decided to incorporate them into my blog. This aggregator will then be displayed on its own page or on my blog’s sidebar if I choose to put it there.

One of the great blogging platforms that I miss the most is Posterous. The idea of this blogging platform was simple yet highly effective. Instead of writing your posts in a password-protected section of your blog, you write your posts with email and mail them to your blog. Starting small by being able to email posts without titles would be a good start. Posts with titles and attachments would then follow.

Cross-posting to Twitter is definitely something that I want to include in the blog. It’s more the shorter posts that I would post on Twitter, but not all of them. I think for this a simple checkbox would be sufficient.

Building my blog using Rails has been a great way of making something that I can experiment with more. It’s also something that I can create at my own pace. The blog is still using the CDN version of TailwindCSS, WebPacker hasn’t been set up, and no there aren’t any tests.

This isn’t a business system or a product, though, so I can afford to do these things in my own time. It just feels good to be writing code in Rails that I don’t need to worry about too much and can do in my own time.

In the last few months, I’ve been fairly quiet on the blog front. Just like everything else that went wrong in 2020, I could blame it on the global pandemic, but that’s not why I stopped blogging.

I started blogging on Micro.blog while it was in the Kickstarter phase. I liked the idea of not only having a new blogging platform, but one that focused back on RSS feeds. Now though, I feel like I have outgrown Micro.blog. It’s has a nice collection of features and themes, but I’m looking for more from my blog. I want it to do more than just display posts and pages. I’d like it to handle long-form articles that fall outside of the chronological order of the blog, handle bookmarks, and track other places where I am active on the web.

To get started, I decided to start moving some content over from my Micro.blog so that it’s now hosted here on my main domain. I’ve been putting everything together using my own blogging engine, which does just enough to display posts in chronological order, supports an RSS feed, and has an admin section to manage posts.

I’ve still got a lot to do in terms of development, but the main thing I’m taking from this is that I am working with Ruby on Rails again. It’s been a long time since I worked with Rails in a full-time capacity, and I do miss it. Rolling my own blog engine gives me the chance to get myself familiar with Ruby on Rails and try out a few different ideas.

Sad to see that Mike Gunderloy is bowing out from software development and the Internet. He was one of the first Ruby developers that I followed on Twitter and through there I subscribed to his blog, A Fresh Cup, where he posted his Double Shot posts.

Looking back, I’m also not super-happy with how the industry has evolved. There was a time when I could believe and hope that software was making the world a better place. Looking around, I’m not so sure any more. Money and power have seized pretty much everything related to software, and the rising tide of surveillance, manipulation, and generally rapacious behavior appears to be getting worse all the time. It’s become harder and harder to find any industry niche that I feel comfortable in working any longer. My sincere blessings to those of you who are still fighting the good fight, but as I said, I’m tired.

— End of the road

I can understand his reasons for bowing out from the world of software development. I’ve been feeling the itch to leave as well, but I still think I have a few years left before I completely think about trying something else for a career.

Over the last few days I’ve been assessing a number of projects that I have in the works.

The problem with each of these projects is that their largely untested product ideas that have stagnated for too long and will require more time to get back on track than I can afford. Most of these projects are getting killed. I can’t afford the time to explore them further. The remaining couple of projects will be re-written and released as open source so that others can run them on their own.

In a post-Covid world, maybe the time has come to go out on your own. Keep it simple initially: just you, no start-up capital and a desire to be beholden to nobody. Except you, of course.

— Agility Is The Big New Differentiator

Since the lockdown started, it’s clear to me that striking out on my own again is the best way to go.

I have a pull request that’s been sitting in Github for about two weeks now. It’s for a Rails app and the pull request includes some breaking changes. I’ve done my best to limit these breaking changes but there are some parts of the application that I need to update after the deploy.

I haven’t scheduled this into my day as I know it’s going to take a chunk out of my day so I’ve just let it lie there for the last two weeks.

I can’t put it off any longer. I’ve scheduled it in for this afternoon. I just need to get it done.

After a few weeks of not posting to my dev blog, I’ve decided that over the weekend I will delete this blog.

I don’t see the long term value in having this resource on a seperate domain or in collating the links for this blog. Instead of posting to a blog, I’m going to start collecting web development and Rails guides and resources on a number of pages on my personal website.

Don’t worry folks, I’ll keep posting here and any major changes in this web development content will be shared here as well.

On Sunday night, I migrated a couple of Rails apps to Ruby 2.7, including Writeabout. Last night, I did the same with another Rails app. By the end of the week, I hope to have Markcase moved over to Ruby 2.7 and Dailymuse upgraded to Ruby 2.7 and Rails 6.0.

Upgrading apps is a pain if they’re left alone for too long. I’ve left Dailymuse alone for such a long time that it’s still sitting on Rails 5. Markcase is on Rails 6 but requires a wee bit of maintenance regarding Webpack.

I’ve learned that leaving apps for such a long time between updates is not the best thing to do. Even upgrading an app regularly through its patch versions is better than just leaving them sitting gathering dust.

Last night I needed a much needed break from the usual Rails coding, so I worked through an example on the StimulusJS website so that I could add a “copy to clipboard” button for the displayed writing prompt on Writeabout.

For me, this is the ideal level of integration I need with JavaScript. A framework that does some of the heavy lifting on the user-interface without me having to re-write the whole front-end.

The end result is nice, but I don’t like the way the elements on the page move up and down when the copy button has been pressed. I’ve added a little div section with an indicator that the button has been pressed. It disappears after a few seconds, but it moves the elements on the page up and down when it changes its display state. I’ll fix it another day, but the first pass at this functionality is still good.

Update: Writeabout was retired in Autumn 2026.

David Heinemeier Hansson breaks down the cost of the operations at Basecamp with a spotlight on the cost of running a Ruby on Rails product.

Working with Ruby and Rails is a luxury, yes. Not every company pay their developers as well as we do at Basecamp, so maybe the rates would look a little different there. Maybe some companies are far more compute intensive to run their apps. But for most SaaS companies, they’re in exactly the same ballpark as we are. The slice of the total operations budget spent running the programming language and web framework that powers the app is a small minority of the overall cost.

Only 15% of the Basecamp operations budget is spent on Ruby

For years I’ve heard arguments that Ruby on Rails is too expensive to run, but I’ve never seen costs for anything as big as this. And to be honest, I was surprised that this was all it was.

Sure, every SAAS product is different in what it does, how it’s built and how it’s run. But, the fact is that Ruby on Rails is an ideal web framework for most SAAS products and has been for years.

I’ve watched the JavaScript hype train trundle on now for a couple of years and I can’t see any clear advantage of it over Ruby on Rails or any other non-JavaScript framework for that fact. And I think developers are starting to realise this.

Given the choice between Rails and any other framework for an application, I will keep going with Rails. It doesn’t have the big hype around it that it did ten years ago, but it’s still proving to be a developer-friendly and therefore business-friendly framework to build your SAAS product with.

A favourite saying of mine is Phil Karlton’s quote about hard things to do in computer science.

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton

I can’t say that cache invalidation has given me major issues in the past but naming things has always been a challenge. If I was to take this beyond the realms of programming though, I would say that naming anything is a difficult thing to do.

My portfolio of web applications include DailyMuse, Markcase and WriteAbout. I find it hard to get away from the compound naming theme. It’s just a way of naming things that I stick with. It’s easy to do, but it feels like it lacks imagination. I would love to come up wth alternatives that don’t follow this convention but everything I have come up with didn’t feel like a good fit.

The other thing I don’t like about compounded product names is deciding whether to upper-case the second word or leave it as lower-case. GitHub’s branding is clear that they favour upper-casing the second word, but there are examples of other brand names that are made of two words that just user a lower-case word for the second word. Take Feedbin for example.

For my bookmarking service, Markcase, I choose to use the lower-cased form instead of MarkCase, and I have to say I prefer it.

I’m working on something that is bigger than anything I’ve worked on in the past. I’d like it to become my full-time gig eventually so it’s quite important to get the naming of it right. I do have a name for it, but I’m torn between whether to use the upper-case form or the lower-case for.

I am edging towards the lower-case form. It reads easier and looks better in the different styles that I have for it.

I find all aspects of branding and marketing quite a challenge. I’m creative to an extent, but I’m definitely not well-versed enough to launch a huge marketing campaign. To get my product off the ground though, I’m taking little steps in executing it and learning as I go. I might not always get it right to begin with, but adapting the product and the marketing as I go, is better than not doing anything at all.

A while back, I started a little Rails app that would generate random writing prompts. After a few months, I decided to kill it. To be honest, I’m not entirely sure why I killed it. I just remember one day deciding that it wasn’t gaining any traction, so I decided to pull the plug on it. Now though I’m not so sure that killing it was such a good idea.

If I was making the application all over again, then there are a few things that I would do differently.

I would open-source it

The main reason I would be open-sourcing the application is so that I can provide a working Rails application on my Github profile. That old chestnut about your Github being your profile isn’t something that I put a lot of stock into. Still, it would be helpful if I have something on there that is working, live and provides a small sample of my work.

I would enforce some constraints

The last time I did PenMuse it ran away from me. I got hung up about too many things about the application that I ended up overthinking what should be a simple application. This time I would keep it simple.

There won’t be an admin section for it, and I would simply connect directly to the database to add new prompts. I would keep the application as minimal as possible, to begin with. One model, one controller, one page. At least I’ll do it this way, to start with.

I would track interest in it

I’m not a big fan of using analytics, but that was back in the day when Google Analytics was the only real option. Now though, there are plenty of great options out there, and a few are even GDPR friendly.

One such analytics service that I have been wanting to try is Fathom. I have earmarked for another application, but I thought PenMuse would be a good starting point to get myself familiar with Fathom.

So there we have it. PenMuse is back! Although not right now, I still need to build it! And it’s not going to have the same name, but more on that later.

I’ve been collecting a few ideas for Ruby and Rails apps to try a few things out.

In the past I’ve ended up simply building some form of task manager or blog engine. In order to explore some of the other parts of Rails though, I’m need to try and build something a bit different.

Here’s what I have so far.

• A live updating leaderboard for an event. The idea behind this is to explore ActionCable again. I haven’t used this in a project for a couple of years. It would be good to get familiar with it again.
• A command line tool for generating images with text. I had a template I used last year for creating images for the golf club’s junior section for competition announcements. Rather than using the existing template I have with Pixelmator, it would be good if I could generate the same image using the command line. A nice way of exploring what Ruby can do with a good image library.
• A Microblogging client. This would simply be a client for posting message instead of being able to read posts. The idea here is to see if I can deploy a Rails app with something like Vue.js or React built in.

The idea is to build out each of these over the next few months to understand a bit more about the different parts of Ruby, Ruby on Rails and JavaScript frameworks that I can use with them.

In my development work I usually find that the simple way works best and is also easier to maintain. However, the web development industry is still insistent on progress and not always for the better.

This comparison between AirPods and the headphone jack by Bastian Allgeier is a great way to describe the issue.

Modern web dev tools and services are like AirPods. It’s fantastic to get rid of the cable. The experience is far better 95% of the times. But they also have connection issues from time to time, they are massively over-engineered, expensive and you can easily loose them.

Bluetooth headphones are likely the future. But I still have more love for a set of standard headphone with a regular cable and headphone jack that has been working reliably for decades.

— Simplicity (II) by Bastian Allgeier

It’s why I use Rails as my go to framework for new projects. Sure it’s not as simple as editing files on a server but it’s as simple as a tool you can get for building web apps.

For the last few months, I’ve been building a content management system aimed at a particular industry.

I’m close to finishing the first working version of the product. There are still a few things to do, like account management and theme options, but these are trivial things that will not present any problems.

While reviewing the CMS source code this morning, I spotted a way that I can refactor a part of the CMS. The change involves simplifying the different content from multiple types of content to a single base content model that I can base other content on. This is a significant structural change to the product. It involves changes in how the CMS presents and manages the content.

If I spend the time making the change now, it would be much easier to handle any created content and migrations of data in the future.

If I schedule the switch for later on after the release, I’ll always know that I have this change in the structure to make and will be presented with an increasing problem of migrating data.

Thinking on it, I like the idea of taking the hit now and getting this right before the product gets released. I’m just wondering now why I didn’t see this before when I was modeling the content for the CMS.

As part of a side-project I’m working on, I’ve been trying to build an informative weather widget that gives current and forecasted stats for the next few hours.

I’m using the card component from Bootstrap to structure the widget. The card component is excellent for this, as it allows me to structure the widget but will enable it to have different styles for different websites. I’m surprised by just how much I’ve been using the card component, as it’s quite versatile.

Dark Sky provides all the weather stats that I need. I have a background worker that fetches the stats from the Dark Sky API and saves it to the database. I can then query the database for the stats as well as cache the widget for a short period.

The Dark Sky API is excellent as the forecast request gives you minute by minute forecasted weather for the hour, as well as hourly and daily forecasts for the next seven days.

The Dark Sky API also includes descriptions for icons that you can use. These standard descriptions can then be used to map to whatever icon you want. I’m using Font Awesome for my weather widget’s icons. I have a helper method in my application that maps the icon description from the Dark Sky API to the correct Font Awesome icon.

So far I’m pretty happy with the results.

Feedbin was down again this morning, but thankfully it’s back up and running now. This is the first time that I remember Feedbin having a prolonged service outage ever since I started using it when it was first launched.

The thing about service outages though, is that despite their interruption to your day, they can be an indicator of how effective the service provider is at dealing with it. For a service like Feedbin, it shouldn’t cause too much of an impact on a person’s day. It’s a consumer product, but what if you are a service provider for other businesses and organisations?

I remember Gitlab’s database outage a couple of years ago. They had a severe disruption to their service, but they dealt with it in the best way possible. By being transparent with the world and letting everyone know what went wrong, what they’re doing to fix it and finally a retrospective of what they have learnt from it.

Basecamp also had a severe outage not that long ago. Again, they handled it in the same way Gitlab did. By being transparent and learning from the disruption so that it doesn’t happen again. If you really want a deep dive in Basecamp’s service interruption they did a whole podcast episode on it.

Platform interruptions are mostly just a nuisance. As a consumer of both free and paid for platforms, I know that these outages are not that important and eventually, the platform in question will be up and running again. But for the service provider, they’re a great indicator of how good they are at getting back on their feet, and more importantly, how informed they’ll keep everyone during the process.

So even if a service provider does have a significant outage, it’s how they handle it that will be a factor on whether I sign up for it or not.

Although I understand what technical debt is, I often find it difficult to explain it to others in simple terms. From now on though, I’ll just reference Martin Fowler’s brilliant explaination.

What most appeals to me about the debt metaphor is how it frames how I think about how to deal with this cruft. I could take five days to clean up the modular structure, removing that cruft, metaphorically paying off the principal. If I only do it for this one feature, that’s no gain, as I’d take nine days instead of six. But if I have two more similar features coming up, then I’ll end up faster by removing the cruft first.

— bliki: TechnicalDebt

Scott Hanselman nails it with his advice for a young university student attending the Microsoft BUILD conference.

For the young person I spoke to, yes .NET Core may be a little different from .NET Framework, and they might both be different from Ruby or JavaScript, but strings are strings, loops are loops, memory is memory, disk I/O is what it is, and we all share the same networks. Processes and threads, ports, TCP/IP, and DNS - understanding the basic building blocks are important.

— Systems Thinking as important as ever for new coders

It’s all just building blocks. Whatever the language or framework is, the building blocks are still the same. Great advice for those just starting their careers in software development, but also a reminder for the older or more experienced software developers who are struggling with the ever changing landscape of programming.

Last night I shipped the ability to search your bookmarks in Markcase. With over 1800 bookmarks in my collection, finding anything was beginning to get a bit frustrating.

The search query will match any term in a bookmark’s title, description or URL and will only search through your own bookmarks.

I want to be able to search over URLs as well, but the results for your search may yield more results than you would like depending on the term. URLs can be quite lengthy and therefore can be included in the search results when you might not expect them to be there. For now, I am going to leave searching over URLs in. I haven’t used it enough to see whether it will be useful in the long term or not.

The next step is the importing and exporting of bookmarks. I’ve put this off long enough, but it’s the next best feature to implement to entice a few more subscribers to the service.

Once importing and exporting is in place, then it’s on to billing. I’ve always said that Markcase will be a paid service, but for just now I’m happy to let people use it for free. I’m hoping to have billing in place by the summer which will then let me focus on performance and usability improvements for a few months.

I’ve been making quiet and steady progress with Markcase over the last couple of weeks. Just minor changes here and there.

One of the bigger changes is the addition of individual pages for each bookmark so that you can see related bookmarks. These are accessible by clicking on the bookmark’s timestamp.

At the moment it only returns a handful of bookmarks from the same domain, but I am going to add more sections to this page to include related bookmarks by tag and date.

In the last couple of weeks, I’ve been slowly getting back into using Vim as my default text editor.

Even though VS Code is really popular with developers at the moment, I’m not a big fan of using Electron-based apps. Also, VS Code’s popularity has been killing off some packages that I use on Sublime Text, which effectively kills that off as well. I did try to move back to Sublime Text, but I’m not finding it anymore productive than VS Code. Which brings me to Vim.

After many attempts at moving to Vim, I can still remember the keyboard shortcuts for many commands on Vim, so I haven’t been at a total loss in getting started again.

An advantage of a monolith code base that can go overlooked is the minimal entry barrier to getting up and running for junior developers or new members of the team.

Setting up a basic database and my application with a background process was a pretty defined process. I’d have the readme on Github, and often in an hour or maybe a few I’d be up and running when I started on a new project. Onboarding a new engineering, at least for an initial environment would be done in the first day. As we ventured into micro-services onboarding time skyrocketed. Yes, we have docker and orchestration such as K8s these days to help, but the time from start to up and running a K8s cluster just to onboard a new engineer is orders of magnitude larger than we saw a few years ago. For many junior engineers this is a burden that really is unnecessary complexity.

— Give me back my monolith by Craig Kerstiens

Even those in senior roles may struggle to hold in their head an entire stack composed of micro-services. Sure it becomes familiar over time, but it’s another learning curve that can be unnecessary. It’s why I love working in monoliths.

They are a one-stop stack that contains everything or at least most of the components that we need to know about. An engineer can get up and running in a matter of hours. Why make it more difficult to onboard engineers?

Maybe the hype-cycle for micro-services is finally passing.

A very detailed post over at NicePage about the changes in web design, the gap between site builders and designers and how you can design for the new 3.0 era.

My design skills as a web developer are definitely lacking, but I can do enough to get by and make a functional user-interface. I prefer to use Bootstrap, but I’ve also been using the Vuetify framework recently as well.

I think Bootstrap gets a lot of bad press for being the popular framework out there, and sure there are a lot of designs that look similar, but there are alternatives out there. The Themes For App site provides free themes based on Bootstrap and looking at them, you couldn’t say for definite that they are built using Bootstrap. They make good use of whitespace and visuals and lean towards NicePage’s 3.0 trend.

Another Bootstrap based theme I’ve been looking at is Material Kit. Take the Bootstrap framework and wrap it in a design influenced by Google’s Material Design.

I’m glad to see there is a new trend in web design. It keeps everyone in the industry on their toes and ensures that there is something else to work towards. It’s not for everyone, and I love minimal plain text designs just as much. It’s good though that we can have this choice as users of the internet.

I’ve been working on a little side-project for the last few weeks, and now I’m ready to reveal it in a soft opening kind of way. Say hi to my bookmarking app, Markcase.

I’ve been an ardent user of bookmarking apps right from the early days of Delicious. Since then I’ve been back and forward to Pinboard a few times and tried Pocket a couple of times. They’re all excellent apps for bookmarking, and they all have their pros and cons.

Delicious is now under the control of Pinboard, and Pinboard itself has been very quiet on the development front. It does what it promises, but after I struggled for a few weeks with bundle issues, I decided to close my account.

I like Pocket for its visual appearance, and it negates the need for a read-it-later service as well, but the last time I tried it, I found it challenging to organise all 1800 of my bookmarks.

I decided to roll my own bookmarking app. After a few weeks, I had a single-user version of Markcase up and running. A few weeks on and now I have Markcase running as a multi-user service. It’s still very early days for it, but I’m definitely keen to take it forward. There’s still lots of work to do, but it’s ready to go as a service for saving bookmarks and organising them.

It’s still in a state of beta though, but I would be interested in hearing from anyone who wants to give it a try. While in this beta phase, accounts will be given out as free, but once we leave the beta stage, accounts will be charged an annual fee for using Markcase. If you don’t feel like using Markcase beyond this point, then you can delete your account.

At the moment, you can log in, change some of your account details, save bookmarks with tags, organise them with tag bundles and use a private RSS feed for your bookmarks. I expect to add many features over the coming months including importing and exporting of bookmarks and integration with other apps and services.

As for native applications, Markcase is a web app first. It will work on mobile devices, without having to install an app. I will be providing an API in the future for those who want to build their own native app for Markcase, but it’s not something that I will be interested in doing for at least a year, maybe longer.

If you’re interested in taking Markcase for a spin, then please reply to this post on Micro.blog or email me at matthew [at] matthewlang [dot] net. I’ll be setting up account requests as and when they come in. It might not be right away as this step is manual at the moment. I will be adding a sign-up page after the beta has finished.

Markcase was previously called Commonmarks, but that was far too similar to Markdown specification of a same name. A name change was definitely needed.

Chrome’s continued dominance of the web now puts it in the same position as Internet Explorer all those years ago. “It works on Chrome” is the new “It work on IE”. I’d like to think though that most web developers out there don’t just build for the one browser.

Reda Lemeden’s post, “We Need Chrome No More”, sums up this change.

The dominance of Chrome has a major detrimental effect on the Web as an open platform: developers are increasingly shunning other browsers in their testing and bug-fixing routines. If it works as intended on Chrome, it’s ready to ship. This in turn results in more users flocking to the browser as their favorite Web sites and apps no longer work elsewhere, making developers less likely to spend time testing on other browsers. A vicious cycle that, if not broken, will result in most other browsers disappearing in the oblivion of irrelevance. And that’s exactly how you suffocate the open Web.

— We need Chrome no more

While I can see Reda’s point, I don’t think that the developer’s building for the one browser is as big a problem. I’ll be honest, it’s been a while since I visited a website that only worked in Chrome.

For me, the problem isn’t so much that Chrome is the most popular browser, it’s the organisation behind the browser and how they integrate features into that browser that support how they use data and ads to make profits.

Switching to another browser is one answer to this problem, but perhaps there’s also another answer.

For Google to change as an organisation.

That sounds like a pipedream, and even looking back at that sentence, it just seems ridiculous. I’ll leave it though because even the most ridiculous of ideas can still happen.

Even though we have bigger screens with more pixels available to use to view, Nick Janetakis makes a strong point for sticking to 80 characters per line when coding. And he even supported his argument up with a few screenshots as well.

1080p is still one of the most popular resolutions for monitors and it just so happens that with most code editors you can comfortably fit 2 code windows at 80 characters side by side, and even have room for a sidebar if you like that sort of thing.

— 80 Characters per Line Is a Standard Worth Sticking to Even Today

Well worth a read if coding is your thing.

I mostly stick to 80 characters per line when programming. I say mostly as it’s more a guideline than a rule for me. I find it easy to adhere to this guideline when working with Ruby and other programming languages, but where it falls apart for me is when I am writing HTML. In some cases, I just can’t get a line under the 80 characters.

There are things I can do get around this. I can extract segments of HTML into partials (I am using Rails anyway), but is this valid reason for doing so?

I’m not sure, but in most cases, separating out this HTML would definitely help project organisation, allowing me to work in a more component-based way with my HTML. I might just have to give this a try tonight.

When it comes to building ideas for applications, I will always choose the web first. It’s what I can I do best and it is where I can ship those ideas more efficiently. I can go from that first line of code to a shippable idea in hours. After that, I can just iterate on that idea when I want to.

There’s another benefit to building for the web though. You have access to a bigger market.

At a startup, engineering resources are scarce. It’s expensive to spread your engineering expertise across different platforms, so it’s better to focus on one in the beginning. Building for the web means that users on mobile, desktop, Chromebooks (which have become the most popular EDU hardware in the US), and any other internet-connected device can use your service, whereas a native app is specific to iOS or Android.

— Considering App vs. Website? It’s 2019: Build a Website.

I’ve toyed with learning Apple’s programming language, Swift. My goal is to learn how to build iOS apps. It’s not that I have some Candy Crush busting idea that will net me millions, it’s just something I would like to learn.

Even if I had the knowledge to build a native app in the same time that it would take build a web app, I think I would still go with making a web app. Native apps serve their purpose, but I think we’re seeing more viable alternatives through web apps.

After years of using Solarized Dark as my preferred colour theme for coding, I’m starting to find that I’m now preferring a lighter themes for when I’m writing code. Solarized Light for Sublime Text and Bluloco Light for VS Code.

Solarized Dark is still my preferred color theme for the terminal though.

The debate about the use of Javascript in the web industry and the role of the front-end developer continues after Chris Coyier’s post, The Great Divide and now a follow-up from Rachel Andrews.

There is something remarkable about the fact that, with everything we have created in the past 20 years or so, I can still take a complete beginner and teach them to build a simple webpage with HTML and CSS, in a day. We don’t need to talk about tools or frameworks, learn how to make a pull request or drag vast amounts of code onto our computer via npm to make that start. We just need a text editor and a few hours. This is how we make things show up on a webpage.

— HTML, CSS and our vanishing industry entry points by Rachel Andrews

Rachel’s post reminds us though that while Javascript frameworks might be all the rage at the moment, we’re neglecting the foundations of the web, HTML and CSS. And how they can still be used to educate those new to the process of creating websites.

Maybe as an industry, we should still be focusing on these fundamentals. Not just for those new to the industry, but for everyone in the industry.

Over the last couple of days, I put the finishing touches to the Commonmarks application so that others can deploy it easily to Heroku. The reason I went down this route is that self-hosting Commonmarks is a something I want people to be able to do, but I’m not at the stage yet where Commonmarks can be quickly deployed to any SAAS platform or even your own server. Going down the Heroku route was a short term solution.

If you take a look at the top of the README file on the Commonmarks Github repository you’ll see a Deploy To Heroku button that you can use to deploy. You’ll need a Heroku account to do this. The add-ons needed for the application to run are free including the dynos required to run the application. I’ve been running Commonmarks on a free dyno for over a month now without any problem.

This brings me to the next step. I’m now working on Commonmarks as a hosted bookmarking product that anyone can sign up for if they don’t want to run their own version of Commonmarks. I appreciate there are people on both sides of the fences, but there are probably more people who want to go with the hosted option than the self-hosted option. I’m not looking to have this running for another couple of weeks, and I’ll be initially opening up with a small beta to get feedback.

Updates will follow.

Just a little Commonmarks update for those interested. I’m working on the password reset over the next few days. By then I should have a working single-account version that people can deploy with a Heroku button.

After that I am going to then focus on a multi-account option for those who don’t want to host it themselves. The timeline for this is a couple of weeks, but I will have a limited set of invites for those interested. I’ll make the announcement on Micro.blog first.

With my day job taking me down the JavaScript route on a daily basis, it’s good to break out the text editor at night and write some Ruby code for Commonmarks. It might just be a simple Ruby on Rails bookmarking app but hopefully in time I can build a few more interesting features for it.

Over the last few days there has been some interest in my bookmarking web app that I’ve been working on.

Why another bookmarking solution though?

I used Pinboard and Pocket for a while, but I was never comfortable with either of them. Pinboard hasn’t seen much change in the last two years and Pocket is more akin to Instapaper (which I already use) than it is to Pinboard. I also wanted to work on something that I could pin to my GitHub repo as an example of work.

Features are light at the moment, with just the ability to add, edit and delete bookmarks as well as the ability to group tags into bundles. A basic web application, but it works. I’m using it on a subdomain of my own site .

I’ve had replies from people who are interested in a hosted solution rather than having to roll their own. I initially pushed back against the idea of starting a SAAS product. There’s a lot to do to make this happen as the open source version is for a single account only. There’s also all the other parts of a SAAS product to consider such as billing and privacy now that GDPR is a requirement. Also, my first attempt at a SAAS product is still ticking over but hardly a success in terms of revenue.

However, with growing interest, I am going to entertain the idea of making Commonmarks into a SAAS product. I won’t be abandoning the open source version, but the way ahead might lie in using the same model as Feedbin. They are an RSS reader service, but the source code is open source. I’m wondering if this would work for Commonmarks as a product as well?

There is a lot of other things to consider as well for this such as hosting, pricing and support. I won’t be entirely excluding the idea though until I can at least gauge some interest in the product.

The next step looks like it might be to set up a page to allow people to register their interest.

There’s no denying that JavaScript is an excellent language for the web, especially the front-end of any web application. Without it, we can’t enjoy a user experience that challenges native applications.

However, I am not convinced that JavaScript is a language that is suitable for all parts of an application’s stack, all the time. There are benefits to using JavaScript depending on the requirements, but it feels like JavaScript is becoming the go-to language for everything.

Heydon Pickering’s post is an excellent read about this issue and full stack development and how this role is changing with the larger set of JavaScript tools and frameworks available, but it’s his point about separation of concerns that resonated with me:

We need to revisit the separation of concerns principle. We simple can’t afford for people to have to know everything just to do something. It’s good that we conceptualize designs in terms of self-contained components now, but that can be a mental model without being a technology-specific land-grab.

— Reluctant Gatekeeping: The Problem With Full Stack by Heydon Pickering

It wasn’t that long ago when front-end developers and designers worked with back-end developers on applications. There was a separation of the two roles and their focus, and each side had the knowledge to carry out their role. Front-end developers would work on HTML, CSS and JavaScript, crafting functional yet beautiful user-interfaces. Back-end developers would work on business logic and background processing.

With the rise of JavaScript though, we’re seeing a convergence of tooling onto a single language, and the roles of front-end, back-end and full stack developers becoming less about knowing the respective field and more about knowing JavaScript.

The new world of web applications is moving to JavaScript, and that’s great for the web as a platform. We can now build applications that rival that of native apps using a single language.

However, when faced with programming language choices in the stack, should developers be quick to default to JavaScript?

My own bookmarking app is up and running.

It’s nothing fancy in terms of how bookmarking apps usually work, but I wanted this to look and act more like a blog than a collection of bookmarks. I opted for paginating results on the right with a sidebar on the left. In time the sidebar will include more filtering options.

I’ve had a couple of stabs at my own bookmarking apps over the years, but this one feels more right than wrong. The code is still rough around the edges, but I’m happy to open source it now on Github.

And the name? Well, think of it as a commonplace book for your bookmarks.

Update: Commonmarks has been renamed to Markcase and is still under active development. I’m hoping to open it up for registrations in spring 2020. Source code is available on Github.

Dan Abromov’s Things I don’t know as of 2018, is a refreshing take on the knowledge gaps of software developers. Even though Dan is the creator and maintainer of a widely used package used with React, his list of knowledge gaps in web development is quite an eye-opener. And he made them public too!

I’ve worked alongside a lot of great developers, and I’ve been amazed at both their spread of knowledge on web development but also their gaps. I rarely pay attention to the knowledge gaps though. It’s easy to be amazed at the breadth of one person’s knowledge and not focus on a person’s knowledge gaps. Perhaps they just didn’t get round to that gap, and focusing on their knowledge gaps feels wrong, but should that be the case?

As I’m approaching 20 years working in software development, I’m starting to know the excellent job descriptions from the bad ones. Merely listing a long list of tech experience that you would like in a candidate is a poor way of getting the right one. In my view, the best candidate can come in and use their soft skills to learn and get up to speed in a few months regardless of their experience. I think it comes down to the fact that more organisations want their candidates to hit the ground running from day one. No training or onboarding, just another cog in the big development machine.

Given the number of languages, frameworks and other techs in web development, it’s a near impossible task to keep up with everything, but I’m taking two things away from Dan’s post.

1. There’s no harm in not being up to speed with everything that a full stack web developer should do. Sure, I can deploy an app using Cloud66, Heroku and Dokku, but I can’t say the same for Docker and Kubernetes. I can deploy web applications, but only on the technology that I have chosen to learn.
2. I’m considering changing my job description to be more specific. Sure I can be a jack of all trades, and know a bit of everything in the web development stack, but I’m sure I would be better off describing myself as a backend web developer instead and focusing on the technologies around that.

With these points in mind, I’m renewing my focus on Ruby on Rails as well as adding to this the knowledge that I need for the gaps around it.

It’s good to know though that I am not alone in not understanding a few topics that have been popular in the last couple of years.

Trying to keep pace with most of the topics in the web development world is a task in itself, but there’s enough work to keep me marketable as a backend web developer even if I do focus on a single core skill.

Bloody typical.

I just spent a couple of hours adding a new field to a Rails application, built up the logic to use the new application, did a refactoring to clean it up and now realise that I don’t need the new field. I just need a small change in the application with an already existing field.

I don’t know whether to be happy that I don’t need the new field or annoyed in that I didn’t see how I could have done this without having to add the new field.

Either way, it’s a win, right?

Jonathon Snook has been sharing a few thoughts on imposter syndrome and what he’s doing to overcome it.

It seems that every once in a while I go through this same phase of self-doubt, but it’s never been as bad as it was a couple of months ago. Giving up on freelancing and returning to a full-time job required a series of significant changes that added to this phase.

I was no longer working for myself. I would be working for an employer and therefore also working with and for other people. When you’re freelancing, there’s an element of being a lone wolf. It’s not entirely isolating, but you don’t need to worry so much about other people. You deliver what the client wants. Working for an employer is different. You have to align yourself with the companies goals and those that you are working with.

Working from home for some years means that I was fortunate enough to find my own routine that worked for me. From the comfort of my house, I could play the music I wanted, take breaks when I wanted, plan my day how I wanted. Working for an employer means being in the office at certain times, aligning your work day with others, making yourself available when others require your time.

Adding to these were some routine changes at home and facing the possibility of a frequent commute. The whole experience led me to question whether I could do the job I was applying for. Not only that, but I was examining the worth of some side-projects I was working on as well as a career change that I am considering for the future. It’s was similar to Jonathon’s stage where at the point of execution, you freeze up.

Every time I get to the point of execution on anything, I start to freeze up. I hit a wall every time I want to put myself out there.

— Uneasy by Jonathon Snook

After a few months in full-time work, however, I’m starting to find that I can do the job although given it’s a new role, there are a few weeks of finding your feet.

Not only that, but I’m also reading more, writing more, coding more outside of work. I’m doing these things as they help me build myself back up out of a period of self-doubt. I’m now at the point where I am finding myself enjoying side-projects and returning to a stage where I can see myself executing again.

One of my big downfalls, when I start work on something, is wondering if I am going in the right direction with it technically.

Web development is always changing. It is getting better though. Javascript frameworks are starting to settle down, and fall in line with the regular releases of non-Javascript frameworks like Ruby on Rails and Django.

For the last few weeks, I’ve been reading about Javascript frameworks like Vue and React and what they can offer for web applications. I’ll be honest and say that I’m still not sold on the idea of creating single-page applications with these frameworks, but I can see where they become a benefit for complex web pages.

Then there are things like CSS frameworks, deployment options, containers and a whole ream of other things to consider for the right stack for the application. It’s then that I find myself in a state of “decision limbo”.

Ideally, I would use Rails and a CSS framework and start from there, however, I’m always questioning what should be considered as an alternative.

While reading Nick Janetakis’ article on growing into microservices, I happened across this little nugget of wisdom.

You get better by writing a lot of code with absolute and total intent to replace almost everything you write with better code once you start experiencing real problems first hand.

Microservices Are Something You Grow Into, Not Begin With by Nick Janetakis

I needn’t worry about the implications of my technical decisions until I come across some real technical problems. When I do come across those problems, I should only look at the options available to me then.

In other words, just write damn code Matthew.

On a final note, Nick Janetakis’ article is an excellent guide to those starting new development projects and looking to use microservices. In a nutshell, don’t.

With a new full-time role, I’m in the process of getting my head around some of the technology choices I’ll be working with and the benefits and drawbacks of each option.

One of those choices is building single-page applications (SPA) with a JavaScript framework for the front-end. I can see why this choice was made, but I’m now weighing up whether it is worth considering for my own projects. With that in mind, I’ve been doing a lot of reading about single-page applications.

I liked Jim Newbury’s article on single-page applications and his point about understanding what you are building.

We ask “What framework should we use for this whole app?” for new products up front, when we don’t even understand what we’re building yet. It’s far less wasteful to ask “What technical approach best supports this user need?” on a case-by-case basis as we learn more about those user needs during incremental product design and development.

— Create your own dysfunctional single-page app in five easy steps by Jim Newbury

Sure your team might be well versed in building single-page applications, but it’s not the best fit for all types of applications. It’s all about finding the right tool for the job.

Ruby on Rails is a good starting point for most of the projects that I work on, but I know it’s not a good fit for other types of projects. For other projects I know I would need to use another set of development tools.

I understand the benefits of using single-page applications, but it’s not a style of application that will yield immediate benefits in my own, smaller projects. I’ll stick with the tried and tested multiple-page application monoliths for now.

Six years ago I wrote a snippet about a portfolio career. This is still the end goal for my career.

Splitting my time into smaller part-time roles would be a great way of still keeping my programming skills but also being able to explore other roles in different industries. I have an idea for that other role, but it requires a few other things to be done before I can realistically make it happen.

Ruby is falling again on the TIOBE index.

It’s not a cause for alarm, but I will continue to look at alternatives to Ruby for the long term. Microsoft’s .NET is still something I would like to come back to and there are more opportunities for it as well.

While not directly related, I also did notice that Thoughtbot have made their learning platform, Upcase, free for all. An attempt to get more developers to use Ruby?

I’m in the process of moving back to full-time employment, but the step away from being self-employed doesn’t mean that I am abandoning any of the side projects that I have been working on. I’m putting a few ideas together for DailyMuse, and there’s another more significant project that is a work in progress. Working on these in my spare time can be difficult especially when I have to consider other important things in life.

In the last few weeks though, I’ve been making smaller sprints for my side project, and instead of scheduling big blocks of time, I’m picking up the work when I want to work on it.

Zach Holman’s post on staying productive as a solo founder puts it in a better way.

There’s something to be said for focus, of course, but life’s too short to constantly throw yourself at the wall day in and day out. If you really believe in your product and think that generally, it’s something that can get you stoked, then taking a break for a while is usually worth it, and is more productive in the long run. It’ll draw you back in again in the future; don’t worry about it too much.

— Staying Productive as a Solo Founder by Zach Holman

As a programmer I know I’ll always have the itch to be building stuff on the side. From experience, I’ve learnt that working on side projects when I want to is a much more effective way of working on them than consistently plugging away at them and getting depressed about them.

I’m winding down my freelancing business over the next few weeks to take on a permanent role. It’s been fun over the last six years, but I think I prefer the stability of regular hours and pay.

I haven’t given up on going solo though, I’m still considering running my own business in the future. It will have less of an emphasis on the selling of services though and more of an emphasis on selling a product.

Did I miss the heated and crazy developer debate that the new accepted line length is 120 characters?

Joking aside, I’d like to know if anyone else has changed their coding standards to allow for a bigger line length because of changes in source code management tools.

For a long time I’ve used 80 characters as a guideline as opposed to a set rule. Sometimes I’ll go over this but most of the time I don’t.

With bigger displays everywhere though, it appears that developers are switching to a larger line length when it comes to their coding standards.

Link rot is a problem on the Internet. When you find something great on the Internet, you bookmark the URL for later, and then you find out later that the URL no longer exists. It’s not so much of a problem if you have a copy of the web page you bookmarked, or you use something like Pinboard or Pocket’s premium plan or even the Wayback Machine. For many people though, I’ll bet that they have a few seconds of disappoint and then find alternatives to that same article.

This is what is called link rot. When a web page becomes permanently unavailable. The problem can stem from the web page’s URL being changed, whole websites being moved or closed down.

The same can be said for applications whether they are native or web-based.

The development of whole web applications that we use daily can stop. The application might still run and function correctly, but the ongoing development of the service has ground to a stop that it seems that the web application is no longer being worked on.

I’m guilty of this app rot as much as any web application owner.

While DailyMuse is still running, development on it has ground to a halt. I will resume work on it at some point, but to the careful observer, it might look like the application has stagnated and it isn’t clear if the web application is being worked on.

iOS apps have the advantage of including a version history in the App Store. I’m sure there’s a corresponding version history for Android apps as well.

What about web applications though? How do we see the version history for those?

Well, a version history page seems the obvious choice, however, not all web applications have such a page and there’s no standard for this either.

As a web app developer though, I am going to put more effort into making my web applications more transparent in when they are being updated and making it easy for others to see these changes. How I’ll do this I don’t know yet, but it will consist of a web page of some sort.

The automated delivery of daily writing prompts from my PenMuse website is stable enough now that I want to consider expanding on it.

Cross-posting to Twitter

I’d like to start cross-posting now from PenMuse’s Micro.blog account to a PenMuse Twitter account.

Cross-posting from Micro.blog to Twitter is the most straightforward and easy way of doing it. It’s nothing more than another way for people to get a daily writing prompt.

The drawback to this is that I’m not exactly the greatest Twitter fan although I do think it’s the lesser evil of the social media platforms.

While I am moving away from Twitter, it doesn’t seem right to set up an account there when I won’t be really using.

The benefit though is that I’m not doing this for myself, I’m doing it for others. Others who don’t use RSS feeds, Micro.blog or visit websites that often. Maybe they just want to use Twitter.

A random afternoon prompt

Each morning the newest writing prompt is published through the site’s main RSS and JSON feeds. I’d like to add another feed that publishes a random feed for the afternoon.

There is one problem with this though. Some of the writing prompts in the collection are seasonal, so I would need to exclude these off until at some point they could be considered based on the time of year.

Staying within the constraints

PenMuse is just a playground app. It’s place where I can experiment with a few coding ideas and techniques and see them working in a product environment. I also don’t spend more than a couple of hours a week on such a app.

To do this the playground app has a few constraints on it.

1. It needs to be free.
2. It needs to be something people will use.
3. It needs to only take up a couple of hours of my time a week.

These constraints take out of my hands decisions that would stop me using PenMuse what it is for. A place to experiment with some Rails code.

These two new features aren’t going to give me any problems coding wise, but it’s going to put PenMuse in more places.

Also these features are still small enough that I can do them within the confines of a couple of hours a week.

I’ve been re-reading this post on how to build an ERP sytem from scratch.

I’ll be honest and say that a 250 word post on the topic doesn’t even begin to scratch the surface. Such a topic is worthy of at least 5,000 words in order for the reader to actually takeaway something of substance about building their own ERP system from nothing.

Off the top of my head there’s the following:

• Methodology - Do you go with agile or a big upfront design? You might think I would advocate an agile approach but there are benefits and drawbacks to both.
• Architecture - How should the application be laid out? A brief outline of the system can save months of moving code about later on down the line.
• Application and database hosting - Should we host the application ourselves or use IAAS or PAAS? Self-hosting is big cost but IAAS and PAAS mean you have to sacrifice some control of the application.
• Performance - How do we scale such an application from a handful of customers to hundreds of customers? Performance is critical in an ERP application. Handling vast amounts of data between transactions mean you have to ensure that users aren’t kept waiting.
• Error handling - How do we handle errors to allow support staff to diagnose bugs efficiently? It’s not enough to report the errors, support staff of the system need tools to replicate and report errors.
• Code libraries - Should we use external code libraries or write our own? I’ve learned the hard way that some features are better implemented without an external code dependency.
• User-interface - Do we use a pre-built theme for the application or build our own? A pre-built theme will add the final polish but there will be constraints in what you can do with it.

This is just an outline but I think even just one of these items is a post in itself. Looking at this list, there could be at least 10,000 words here across seven different posts.

I may outline more of these over the course of the next few weeks.

I think I have gathered enough knowledge on this topic to put at least a few posts together.

I used to work for a company that specialised in installation and configuration of Microsoft’s own ERP software, Dynamics NAV and I’m currently working with a client to build a cash management and stock control system.

With this experience I think there’s definitely more to say on the topic of ERP systems and modern technology stacks, especially when it comes to how they can be built with Ruby on Rails.

At the moment I’m just thinking out loud about this but my micro-blog seemed like a good place to put this down / out.

Did a stupid thing today and deleted a checklist from Trello that I was using. As far as I am aware, there’s no way of undeleting it and also no backup of the Trello board to speak of.

Perhaps it’s not only the source code that’s a valuable asset of a project. The supporting project management material that drives the development should be at least backed up or even under version control as well.

It’s been a while since I dabbled in a bit of JavaScript. It’s not that I don’t like programming in JavaScript, it is growing on me, it’s just I’ve never found a real use case for it in a web application. The thing about JavaScript though is that there are so many great frameworks available that mean you often don’t have to write any of the curly bracket stuff.

Vue.js has been on my radar for a while but what has really grabbed my interest has been the release of Stimulus.

For a lot of web applications I work on, I don’t want to re-write a whole view for a particular framework, I just want to enhance a part of that view. Both the above mentioned frameworks do this, but I decided to try and use Stimulus with a web application of my own just for fun.

The copy to clipboard is a nice example to start from in the Stimulus handbook and so I started with this basic example by adding a copy to clipboard button when displaying a writing prompt in PenMuse. Not only was it good to broaden my reach beyond the Rails code that I am used to writing, I also got to experiment with WebPacker as well.

The final results are good and there was a few hiccups along the way in trying to copy the prompt from an input element that didn’t interfere with the user interface.

I did at one point create an input elemement on the fly to copy the prompt from when the button was pressed, but it jerked the screen up and down on tablet devices as it was copying the prompt. Horrible.

I decided to settle on using an input group so that you can partially see the prompt being copied. It’s not ideal, but it’s working and it doesn’t mess with the screen in anyway on different devices.

I’ve still got some adjustments to make for smaller devices like stacking the buttons on the home page so that they appear as a column but that will come later in the week.

Last night I finally pulled the trigger and moved my Ghost hosted blog to Jekyll. While the cost of running a managed blog was the most significant influence on the decision, there were other factors as well.

Easier writing

Ghost had been a promising idea when it started a few years back. A blog where the focus is on the act of writing. And it started well. The two-pane design with the plain text on the left and the rendered post on the right was great and allow you to see the post in real-time. In a recent change though, the Ghost decided that using a single pane with a WYSIWYG writing pane was more beneficial. The old two-pane environment was still there but just hidden away.

I’ve been looking to do more with my iPad Pro. I’m already using it for remote development work and a fair amount of writing, reading and listening. Unfortunately, a down-side of Ghost’s new writing pane made using the iPad Pro impossible. Characters were rendered twice with each keystroke, and I was unable to even copy and paste a blog post from another app such as Bear or Ulysses. In a recent update to Ghost this bug is fixed, but such a breaking change made me question why I was reliant on a product that prevented me from writing.

With Jekyll I can write anywhere with any app that I use daily. I can even write the post straight into my GitHub repo through my browser and save the changes which will automatically publish to my blog. The only thing that will stop me writing and publishing is whether I’ll have a connection to the Internet and in this day and age, that’s becoming such a rarity.

More control

With a move to Jekyll, I’m also able to make changes to the layout of my blog in a much easier way than if I was using Ghost. With Ghost, you need a local working environment first to make your theme changes. Setting up a local environment is reasonably straightforward, but keeping it up and running is not as simple as Jekyll. With just a single command I can have my blog up and running on my browser, and I can make any changes I need to the layout. There’s a small number of dependencies to getting my blog running, and it only requires some flat files for content.

I’ve also got more control over the photos I use on my blog and where I host them. I can either include the images in my blog directly or upload them to another hosting service like Amazon S3 where they’re still in their original format and I can export them if I need too.

Tried and trusted

My days of being wowed by-products such as Ghost are probably over. Tried and trusted products that are simple to manage and let you own your data are two significant factors for me. Ghost looked to be simple, to begin with, but even now there’s still a large number of features that many other bloggers take for granted from their chosen CMS. I’ve tried Jekyll in the past, and now I wonder why I didn’t stick with it.

Data is always a significant factor with me. The export facility of Ghost is excellent, and they were able to allow me to download all the images for my blog through a separate link as well, but I don’t think that’s enough. A single zip file containing all data including images would make things so much easier.

Manton Reece has an idea for this, and it looks promising, but getting the more prominent companies to adopt this is another matter.

With Jekyll though, I can always trust in the fact that my data is there in the purest form needed and that’s in plain text files.

I’m always on the lookout for something different to write about, but some days the nudge just isn’t there. I started using my daily themes as writing topics but this can be somewhat repetitive, and it still falls on me to narrow down the theme to a topic that I can write about.

I started looking for writing prompts that fell into the category of my daily themes, but this was another challenge in itself. Frequently it involved digging through the thousands of writing prompts available online across different websites. What the problem with these is that they not usually organised in a way that makes them easy to search through.

I needed a daily random writing prompt but one that was geared towards my daily themes for the day. So I started making one. Here’s how it looks so far.

The idea is simple. It displays a random writing prompt. If you don’t like it, you can generate another one. As a nice tie-in with DailyMuse and my preference towards analogue writing tools, I’ve called it PenMuse.

Product playground

PenMuse serves a dual-purpose for me. While it does take the guesswork out of what you are going to write about, it also helps a much more significant purpose. It’s a product playground.

The idea of this that you have a small service or product that you can use to flex your development skills. While this application doesn’t have the complexity of a more significant Rails application, it does allow me to try things out on a smaller scale and it’s proved to be helpful already. I’m going to re-design the DailyMuse website with a similar theme.

Plans for the future

There are a few things still missing that I hope to add shortly.

• Allow people to suggest a writing prompt and give them accreditation when it is displayed.
• Document the API for other developers to use.
• Allow people to link to individual writing prompts.
• Create a weekly PenMuse email that emails you the week’s writing prompts ahead of schedule.

One thing that I could do with help on though is writing prompts. There are thousands of writing prompts online, but I don’t want to copy these into PenMuse without thought. I want to curate these prompts so that they are easy to find and share.

What do you like to write about? What prompts would you like to see on PenMuse?

Contact me with your suggestions.

A few months ago I started a GitLab account out of curiosity. I wanted to see if there was anything that GitLab offered that GitHub didn’t.

In the last two weeks though, I’ve been moving my repositories back over to GitHub from GitLab.

There’s nothing wrong with GitLab, it’s an excellent source code management platform, and it has many great features. However, GitLab just didn’t make the grade that GitHub has set when it comes to source code management and hosting.

Heroku integration

Heroku’s pipeline integration is an excellent feature for managing the deployment process, but the only dependency for this to work is that you need to use GitHub for your source code management.

GitLab does offer their continuous integration tool, but it’s highly dependent on some different configurations and settings, all of which I don’t have the inclination to read up about or even research. To be honest, I would love to use GitLab’s tools, but the problem with them is that they require too much fussing.

GitHub, on the other hand, does one thing well and that’s host your source code for you. Sure you can also do pull requests, code reviews and many other great things but this is all nice to have besides being able to have one place to manage and host your source code.

Issue management

I have to say that GitLab’s issue management tools are very much on par with GitHub but where GitHub excels is their project, milestone and issue integration with pull requests. I find GitLab’s way of handling pull requests complex. I tried using them for a few months, but the whole process just didn’t feel as straightforward as GitHub’s.

Maybe it’s a familiarity with GitHub that stopped me from getting on with GitLab’s issue management tools. I’ve been using GitHub with some clients, and I have to say that managing their pull requests is a simple process.

A bigger community

There’s no doubt that GitHub has the more prominent community and despite attempts by others to create communities elsewhere it just isn’t possible to do so. It’s a bit like building another Twitter. There has been plenty of attempts, but nothing compare’s to Twitter when it comes to micro-blogging.

It would be nice if all GitHub, GitLab and Bitbucket could integrate with each other seeing as they all support using Git, but then what would be the incentive to pick one?

I’ve been hesitant about the number of businesses and organisations the use GitHub for their source code management, but as long as GitHub continues to support them and the rest of the GitHub community with great features and integration with others tools, then I don’t see a problem in sticking with GitHub.

More features for GitHub please

There’s no doubt that GitHub is a much bigger and better-suited source code management tool for me. I’ve used Bitbucket in the past, but even it can’t compare to the ease with which I can use GitHub. It’s time to hang up my projects on the GitHub website and start creating more projects there for people to see.

That doesn’t mean though that GitHub has all the features that I need. I would like to see a few more options and features on GitHub though.

A repository template for labels and project columns would be a good thing. I’ve managed to replicate the labels I used for my Trello boards in GitHub issues as labels.

Another thing I would like to see is the assignment of labels to issues as I move them across project columns.

I would like to see the addition of an avatar for repositories. GitLab is on to a winner with their avatars for repositories.

I would also love to see greater management of repositories. Being able to group repositories into folders would make my job a lot easier and would also let me create a showcase folder where I could highlight all my best work.

Between GitHub, GitLab and Bitbucket there’s plenty of options for developers of all types for their source code management and hosting. For me though, GitHub ticks all the rights boxes.

A week running Hyper as my terminal has been mostly without incident, but I’ll be switching back to Terminal.

Hyper is a good replacement for Terminal or iTerm but it’s not a great replacement and doesn’t bring anything extra that I didn’t already have.

Also, I would rather rely on scripts and dot files for my terminal configuration rather than relying on Hyper’s plugins.

One of many nuggets of advice for programmers who feel they are lagging behind.

The goal is become aware of the range of technologies available, and get a superficial understanding of theirs strengths (“React has a bigger community, but skimming the Vue tutorial was easier”, for example). This process can therefore be done over the course of a few hours, at most a day or two, during your work day in-between scheduled tasks.

— Your technical skills are obsolete: now what? by Itamar Turner-Trauring

Half of these ideas on making Slack less of a time suck are terrible suggestions. Just because you can make todo lists in a Slack, doesn’t mean that you should. Less is more with Slack. Use it for what it’s good at. Messaging. Anything else is a distraction.

While it was my intention to write about my web development workflow on my iPad Pro at a later date, one of my readers got in touch asking about how I use the iPad Pro in this capacity. Rather than hold off I thought it would be a good time to elaborate a bit on my workflow when using the iPad Pro for web development. What follows is still under review and isn’t my first attempt at using an iPad Pro for web development.

My first iteration on using the iPad Pro involved the Blink app and setting up a remote development environment on a DigitalOcean server. This took a while to setup but even then I found that using Vim as my text editor on a touch device didn’t work for me. So it was back to the drawing board and what follows is a second pass at putting together a web development environment for the iPad Pro. It certainly isn’t final but it’s working for me now.

Another point to consider is that this web development environment is tailored towards Ruby on Rails development. A similar setup will work for other languages and frameworks providing you can run your development environment locally in iOS or on a platform like Heroku or Engine Yard.

Remote services

I’m using a number of remote services not because I need too just to be able to work on an iPad Pro, but because they’re already part of my workflow on the desktop and I can use them on the iPad Pro as well.

Github

I’m using Github for source code management for a number of reasons like client familiarity, Heroku integration and a few other reasons. The main reason I’m using Github though is that it’s tried and tested. You can’t argue with that.

I’ve tried a number of source code management services like Gitlab and Bitbucket. While there are benefits and drawbacks to each service, Github is my preferred source code management service.

Heroku

Heroku has been my go to hosting platform for Rails applications for a long time now. I’ve tried other platforms and while they might be good fits for particular clients with specific needs I’ve found that Heroku has everything that I need for hosting most Rails applications.

I’ve already mentioned that github is good for Heroku in that it’s baked into the pipeline service that Heroku offers. Automated deploys are a great thing and using this in conjunction with Heroku’s CI tool is one less thing for me to configure.

Client side apps

With our remote services in place it’s time to focus on the client side apps. Apps that focus on developer productivity have largely revolved around other things that developers do like project management, issue tracking and documentation but there are more text editor apps becoming available on iOS and I’m confident that there will be even more apps like this overtime.

Working Copy

I’m using Working Copy as my local Git client. I’ve been using this for a few months now. It’s easy to setup and it works well in iOS 11 with split view and the drag and drop functionality. Working Copy also integrates well with GitHub, Bitbucket and Gitlab. So I’m not tied to using one particular Git source code hosting service.

Text Editors

And now the essential bit of kit for any developers toolbox, the text editor. I’m running two text editors at the moment with the hope of selecting just one of these when I’ve given each of them a thorough test.

Textastic

I’ve used Textastic in the past but only as a means to edit text files remotely. Using it now as a text editor means that it needs to tie in with Git, have the essential settings I need for editing source code and perhaps the most important feature of all, a nice colour scheme!

So far I’m pleased with its feature set and there’s been little in the way of blocks when it comes to workflow. Once I had Working Copy setup to track my Github repos, I was able to drag a branch into Textastic and start working. Changes to files are marked in Working Copy so that you can commit your changes as you normally would.

Textastic doesn’t have all the preferences of a desktop text editor like Sublime Text but the essentials are there. Editor themes, font selection and size, and tab size and type. There’s also find and replace and symbol listing which is handy for larger source code files.

Textastic is working well for me but the one thing that I would like to see a easier management of the files I’m working with. A command pallete like Sublime Text would be a nice addition.

GoCoEdit

GoCoEdit is a new addition to the test. While Textastic I have history with, GoCoEdit is fairly new and I’m still finding my feet with it. It shares many of the same features as Textastic though, so it’s easy to get started.

Like Textastic, you can drag and drop a repository from Working Copy into the app to get started working. Changes to files are marked in Working Copy for you to commit.

Editor themes, font selection and size and tab size and type are supported as well. There’s also find and replace functionality as well. I’ve also found that in GoCoEdit there is a command pallete with limited functionality. You can manipulate text, find and replace text and save a file using this but there’s not much else you can do with it.

I must admit, I do prefer working with GoCoEdit over Textastic. Saying that though there isn’t much between them and both are more than capable of being all-day text editors if you find you have to work on your iPad Pro for the full day.

There are many things missing from these editors that would be taken for granted in a desktop text editor like Sublime Text but apps like this are still relatively limited in what they can do on a iPad. The most essential features are there though.

Adapting

If there’s one thing I’ve learned from all this is that if you’re going to use an iPad Pro for web development or any other form of work then expect to adapt to a new range of apps. Sure you’re preferred apps might be available on iOS but the interface does require you to adapt to the new environment.

Thankfully iOS is getting there with better features like the split view and drag and drop. Features that we’ve taken for granted in desktop operating systems for years but are only starting to see in operating systems like iOS.

My web development workflow has required some changes for the iPad Pro but it’s nothing drastic and a bit of learning on a new device isn’t a bad thing.

Thanks to Curtis McHale for reaching out to ask about this and giving me that much needed nudge to write.

I’ve been using an iPad Pro as a web development device for a few months now. Overall I’ve been surprised at the ability of the device to handle this type of work. Apps like Working Copy, Textastic and GoCoEdit have certainly helped as has the split view on iOS and more recently the ability to drag and drop between apps.

One drawback amongst all this though is the browser I use. Safari has been my browser of choice for iOS for a long time. I’ve had brief dealings with Google Chrome and Firefox, but they’ve never lasted in terms of use. I keep coming back to Safari.

As browser’s go, there’s little to fault about Safari on all the devices it supports. It works well on my iPhone and the smaller iPads I’ve used over the years. With the iPad Pro though, it feels that Safari is short-changing me.

Pinned tabs

Right okay. Pinned tabs aren’t on everybody’s list of priority features for a browser but I’ve been using them for so long on other browsers it seems that they’ve been around forever. That’s not true in the case of Safari for macOS though. Pinned tabs have only been around for a couple of years with Safari which seems like a very short amount of time given that they have been available in other browsers for years.

So why pinned tabs on Safari for iOS?

Well, largely it’s an organisational thing. There’s a number of tabs that I keep open through the day and pinning these tabs in the browser allows me to quickly jump to them through the day.

Given the screen space on the iPad Pro models and even on the iPad Mini models, I’m surprised that the pinning of tabs hasn’t already been done.

Web inspector

I was surprised to find that the Web Inspector on Safari for iOS is only available when you connect your iPad to another Apple computer.

Now while a web inspector is probably a big ask on a device that probably wasn’t intended to be a web development device, I think it’s a fair request. People are turning to the iPad Pro and looking for a device that replaces their laptop or even their desktop. The inability to run the Web Inspector without connecting the iPad Pro to a MacBook or iMac doesn’t exactly

However, while you might not be able to use the Web Inspector for Safari iOS without connecting to another Mac, there is an app called Web Tools that replicates this need feature rather nicely.

Support for pinned extensions

I toyed with the idea of calling these starred extensions but pinned extensions might be a better idea, but first I have to explain what this is.

At the top right of the Safari app on the iPad is the share button. This button allows you to share the current URL with a number of other apps on your iPad or iPhone. I use it a number of times every day, mostly for sharing links to my Instapaper, Pinboard and Bear apps. I also use it quite a lot for opening 1Password. The share button on the iPad Pro is a quick and convenient way for me to share a link. It’s also one more press on the screen than I care to do.

If you take a look at the Safari interface on my iPad Pro, you’ll notice that there is some whitespace on either side of the address bar. What if this space could be utilised in a better way rather than just leaving it blank. What if (and only if your screen size can support it) you could pin a couple of your favourite share extensions to the Safari toolbar?

By pinning your share extensions to either the left or right of the address bar, you’re putting your share extensions in a more convenient place.

There are obvious restrictions to this like screen size and even the orientation of the device which governs how much space you have, but surely the developers at Apple could make this happen?

The expectations of a Pro device

When you name your device as ‘Pro’ there is a certain level of expectation of it. I must admit I eye-rolled when I first heard that the new iPad would be called an iPad Pro, but as I heard more about it and watched the first couple of iterations of the device, I could see where Apple was going with this.

To support this new family of devices I think that there needs to another level up of apps that are targeted at the Pro line of devices only or at least variations of the apps that support Pro features.

These apps might be specialised and target a specific market of people, but given that the iPad Pro is already being seen as a viable option to a laptop and even a desktop, I think it’s important for Apple to offer that extra bit of functionality that users may look for in an app.

These features that I’m looking for in Safari for iOS might not be a priority for the Safari team or even on the list of new features for Safari, but I’m sure that if Apple is looking to push the iPad Pro device to more professionals then there should be some distinction between the normal apps for iOS and those for Pro devices.

It’s been a long time since I stopped using Google Analytics to track the activity on my websites. In its place, I went with a product called Gauges.

On its own Gauges is fine but there hasn’t been any new major features for a while now. Sure I pay money for the serivce to continue but it would be nice to see something new in the way of features. It’s got me questioning though whether Gauges or even web analytics is still necessary.

Do I need web analytics?

I honestly think the answer to this question is no. Well, let me expand on that answer. I don’t need web analytics. I can’t speak for others, but let me explain using each of my different websites as examples.

Personal blog

For my personal blog, web analytics is nothing more than a vanity feature. I don’t need to see what people are reading on my blog, I don’t need to tailor content based on what people like or searching for.

My blog is an outlet for my writing, the topics that I am interested in writing about.

Whether people read it or not is not my main concern.

I write because I want to write. I don’t need web analytics here.

DigitalBothy blog

For my freelancing blog things get a bit trickier.

Sure it would be nice to see what people are reading and what is proving to be most popular but my freelancing blog isn’t just about giving people something to read. It’s about advertising my knowledge of web development.

My blog is also the first step in acquiring potential clients. If a potential client likes what I am writing about and they have a need for a web developer like myself, then what next?

At the moment they can contact me through a form but there needs to be more than just a contact form. I need to be able to contact them back on a regular basis and let them know what’s changing in the world of web development. This is where an email list comes in to play.

Despite listening to podcasts and reading many newsletters telling me for years that I need an emailing list for my business, I don’t have an emailing list for my business. Crazy I know.

With an email list though I can start to build a way of contacting potential clients and convert them to paying clients through a funnel of more specialised content that is only available through that email list.

Instead of using web analytics and learning nothing about my potential clients, I can use an email list to contact them directly and see what interests them in terms of clicked content within each email campaign.

My freelancing blog is the first step in acquiring a client. While it might be helpful to see which content is proving popular at this step, I don’t think that it warrants having web analytics. I’d rather see metrics of what people are clicking through to in the email campaigns that I send out.

DailyMuse

For DailyMuse, web analytics is not something that I want to measure.

Sure it’s nice that people visit DailyMuse and perhaps even sign up for an account, but the key metric here is whether people use DailyMuse on a daily basis and that means measuring when people login, how many people are signing up for the paid plan and how many people are receiving emails per day or week.

I’ve already got a minimal dashboard for this cobbled together from user data in DailyMuse, so again, web analytics isn’t necessary here.

There are also other plugins and solutions that offer user analytics for products like DailyMuse. This is more interesting because I get to see what user’s are doing in my product. I’m not at that level yet and so what I have at the moment will suffice for the time being.

Do I need web analytics then?

So perhaps I don’t need web analytics then.

Others might make the case that regardless of the type of website I am running, web analytics is better to have than not at all, but I think I can live without it.

I’ve justified in each case why I don’t need web analytics and what I would use instead. I think in each case it’s fair to say that I have alternatives in place that work for me and my own needs.

Web analytics isn’t dead then, but I think it has been superseded by other analytic products that offer customers more. It’s probably good to have in place if the content of your website is the only way of measuring activity on your website, but even then I would recommend that such a website have an email list as well.

I’ve used web analytics for a number of years but I think I’ve used it for so long that I’ve become complacent with it. It’s not the type of activity I need to be looking at. I need to be looking at different forms of activity for different sites and that perhaps is the most important lesson in all this.

There’s also the fact that Twitter already offers a sizeable amount of analytics that makes social media interaction much easier to see. If you share your website’s content on Twitter, then it’s worth looking at your account’s analytics dashboard on to see the traffic through your account’s recent tweets.

For me though, I’m going to stop using web analytics over the course of this week and instead focus on getting my analytics from elsewhere.

If you see me bashing away at text editor then you’ll know that I’m a die hard Solarized fan. In the last few weeks though I’ve been using the Dracula colour scheme as well just for a little change.

Colour schemes for text editors and other software tools are a personal choice. There are benefits to the carefully thought out schemes like Solarized where you get a balanced set of colours that works in most conditions. That works for me. For other people though, they might just use a set of colours because they like the colours in the scheme. Everyone is different and has their owns reasons for what they like working with.

Over the weekend I read about a new colour scheme called Monokai Pro, which is based on the popular Monokai colours and it’s availability as a colour scheme for Sublime Text 3. I installed the package and spent some time with it over the weekend. What’s interesting about this colour scheme is that while the package is freely available for Sublime Text 3 to evaluate, it does require a license to use. The license is 10 euros to buy.

I debated with paying the license fee for what is essentially a list of colours, but when you look beyond that you see that the Monokai Pro colour scheme has a lot more to it than a colour scheme for your code.

The colour scheme changes the interface of Sublime Text as well and there are a number of settings that allow you to customise how different parts of the Sublime Text user-interface look. A very professional finish.

In the end I decided that it was worth the money to buy a license for the package and bought one on Monday.

The most interesting part of this though is not the colour scheme itself but what it is. Yes it’s a package for Sublime Text that people can install, yes it’s a list of colours that you can change your interface too but other than that it’s also a product, a micro-product if you like. And it’s not the first product that I have seen that is marketed towards text editors like Sublime Text 3. A few years back I bought a license for the GitGutter package for Sublime Text and I’ve been using it ever since.

Just goes to show that products come in all shapes and sizes and shouldn’t be discounted because of their feature-set or size when compared with similar “free offerings”.

A while back, I read with disgruntlement about the change that Smile were introducing to their TextExpander product. It was the introduction of a cloud syncing change to their product which required a monthly subscription.

I wasn’t too keen on the idea. The reason I wasn’t too chuffed with the idea is that I only ever used TextExpander on my MacBook Pro and nowhere else. I decided to look for an alternative. I switched to aText and never looked back. Until now.

Last week I purchased an iPad Pro. I’ve spent the first couple of days getting the various apps I needed setup. Then I started working on getting together a usable development environment so that I could do everything on my iPad Pro that I can do on my MacBook Pro. Aside from some of the terminal hackery that I can do on my MacBook, I can do just about everything else on my iPad including web development work for clients.

With my new tablet of choice I started doing administration work last week. An invoice was outstanding so I started the process of gathering the work I did for the week and writing the invoice and email for the client. Invoice done, I moved to the email. After a couple of attempts at trying to generate my email template I then realised that I wasn’t using my Macbook Pro which is why the auto-expanding snippet I use for this particular email didn’t work. It was time to re-assess the auto-expanding snippet tool of choice.

So what’s a familiar auto-expanding tool that let’s me use a single library of snippets across multiple devices? Well, TextExpander of course!

Is the subscription price for this worth it now?

I think so.

It’s been a long time coming, but it’s finally here. A couple of weeks ago the first major update to the publishing platform Ghost was released.

I was on holiday at the time so I decided to leave upgrading until I got home. It’s been a few days now since I got back but this morning I decided to upgrade the two sites I have running on Ghost, this one and my DigitalBothy website. The upgrade process itself was straight-forward. Warnings were provided to indicate deprecated helpers in the themes for each site, but aside from that I didn’t have any trouble upgrading.

The new UI is a welcome change and includes a number of beneficial changes but perhaps the most important change is the editor itself. Gone is the side by side editing and preview panes (although you can still use this if you need to) and instead there’s a single pane for writing that is editable and displays your writing in a better format. Bigger, bold text for headings, links highlighted and many other improvements.

This is a welcome update to the publishing platform and I look forward to spending more time writing for my blog than I have done recently.

I’ve been a user of GitHub for a long time now. Ever since I started my career in Ruby on Rails I’ve had a GitHub account.

I’m looking again at alternatives to GitHub mainly out of curiosity. There’s been some improvements to GitHub over the last few years and new features are gradually coming out but there are other options out there.

I did move some private repos to BitBucket a few years ago, but due to the lack of any extra features I moved these repos back. BitBucket just didn’t have anything of added value that would keep me using it.

I tried GitLab a few months ago but I didn’t really give it a fair go. I spent a couple of weeks using but I didn’t really dig into it too much. I created my account there again to give it a try. I’ve been using it now for a week and I’ve moved a number of private repos over from GitHub. The nice thing is that as well as my repo GitLab has moved over my issue list for each repo. Another thing I don’t have to worry about moving it across.

It’s still early days to make a final decision on this but I’ve been impressed with not only what GitLab does at the moment, but the pace in which they are releasing new features.

The best thing and worst thing about GitHub is its community size. A lot of developers use only GitHub for source code hosting and although some people might see this as a good thing, it’s like saying that Facebook is the only social network platform out there. Yes, there are a lot of people using GitHub but there are alternatives to it and I’m always willing to explore the alternatives to any development tool that I use.

Once I’ve spent another few months using GitLab I’ll probably have a final decision on where I’ll be hosting the bulk of source code. I won’t be closing down my GitHub account if I do decide to use GitLab for hosting my source code. I still need a GitHub account for client work, but that’s all it will be used for.

I’ve been using Slack for a few years now. I use it more for work than anything else. I am part of a number of different client teams and it’s through these that we do most of the day to day communication. I have to be honest it has become something of a necessary evil to have, but it is an easy way to stay in contact with clients. For clients that have only a handful of employees then I recommend that we just stay in touch with phone calls, emails and of course whatever project management tool that works best for the client.

Benjamin Pollack’s post about his issues with Slack are good points and with more people turning to apps like Slack, it’s worth remembering that Slack isn’t a great tool and should only be used if there is a genuine need for it other than, “Hey I need this right now!”.

Perhaps the greatest argument against using Slack isn’t the filtering of communications or the notifications.

It’s the version of Markdown that Slack uses for it’s messages. It’s just not Markdown.

5. Its version of Markdown is just broken

I’m going to use up an entire heading purely to say that making *foo* be bold and _foo_ be italic is covered in Leviticus 64:128 and explicitly punishable by stoning until death.

— Why I Hate Slack and You Should Too by Benjamin Pollack

What grieves me more is that there isn’t a week goes by where I don’t end up sending a message formatted incorrectly because Slack has it’s own version of Markdown.

Slack isn’t a necessary evil but teams should consider Benjamin’s points before deciding if Slack is worth using.

Give me email and a phone any day of the week.

It’s been a while since I took another stab at learning Vim. If you don’t know what Vim is then all you need to know is that it’s a major geek out text editor. Savvy?

Each time I’ve tried to learn Vim though I’ve started with an existing Vim configuration file. Getting up and running from a blank file just never appealed to me. The problem starting with another person’s configuration though is that while everything is there that you need, there’s a huge number of commands and shortcuts configured that in the beginning seems a rather daunting task to remember.

This time I’ve started with a blank slate so that every time I need to customise something in Vim I make the change in my configuration file to fix the problem and move on. Needless to say it’s taken me a while to get the configuration file to a point where I would be happy doing client work with Vim as opposed to Sublime Text.

The surprising result though is that while I might be working a little slower than if I had been using Sublime Text, I’m actually learning more about Vim than I ever did before.

I’ll report back in 3 months with an update to see if using Vim has stuck this time. I’m optimistic that it will this time, although I have been caved in the past.

It’s often the case with me that I look for a big solution to what I perceive to be big problems rather than the small solution.

The client upgrade

Take for example an upgrade I’m doing for a client. There’s a number of steps that I always take when it comes to upgrading web applications for clients, but in this case the steps didn’t go as planned.

For a few hours I was banging my head against a wall because of an obscure error. Stepping back I decided to go through the application in more detail. After just a few minutes I finally found the problem and made the change to ensure the upgrade process was working. The error itself was a bit of a red herring, but the obscurity of it had me thinking that I had to do something more to get move forward with the upgrade.

The change to get the upgrade was to update an obsolete library to the latest version and then the client’s application was working again. I’ve updated my notes for further upgrades I do for clients so that the same thing doesn’t happen again.

The same thing happened with Ethan last week.

The golf swing

Last week, Ethan had an playing lesson with the club pro, Andy. For a couple of weeks now, Ethan’s game has been slipping. It was frustrating to watch as I don’t know what to look for in his swing when things go wrong other that what he has learned in the past from his coaching. Heading out to the first tee, Ethan got setup, did the usual pre-shot routine and then Andy chipped in with a little nugget of wisdom, “Stand back further”.

The change was instantaneous. The drive went right up the middle of the fairway. Through the lesson the recurring theme in Ethan’s swing was that he stood too close to the ball and needed to go back a few inches in order to get the ball going in the direction that he wanted. Whether it was a driver off the tee, a hybrid or iron from the fairway or even a wedge leading up to the green, Andy’s advice was always the same, stand back further from the ball.

The small (and effective) solutions

Ethan’s focus now is to start including a small check in his pre-shot routine that ensures he’s the right distance from the ball. Checking the distance between his belt buckle and the end of his club and making sure he can fit a hand span between them is enough to ensure that he’s the right distance from the ball.

In both cases the problem was significant, and yet the solution to each problem was the smallest change imaginable. I wouldn’t have thought for one second that an out of date library could have had such an effect on upgrading a web application. I also wouldn’t have thought that such a small change in Ethan’s swing would have such an effect on the resulting shot.

What this has taught me though is that the smaller solutions should be the ones that we look towards first. Using tried and tested approaches and notes on previous upgrades, I’ve managed to stream line the upgrade process for a clients web application so that in most cases it takes days rather than weeks. Eliminating the small problems ensures that I’m always working towards a functioning upgrade.

It doesn’t always work this way though. Every client upgrade is different and there are exceptions to the rule, although there shouldn’t be that many. Most of my clients have similar technology environments when it comes to their web applications so upgrades should fall into the timeline of taking a few days, a week at most. Any number of issues can stall an upgrade and due the technicalities of it, it’s not always the case that a simple solution can move it forward.

Keep notes on those solutions

It also doesn’t hurt to document your experiences. They’re all different but from the notes that I have built I have a process in place that eliminates most the of the problems I encounter when it comes to upgrading client’s web applications.

As for Ethan’s golf swing, he’s determined to use the time over the summer to practice more. Ethan has a full summer of lessons, competitions and medals to play for so that he can keep working towards lowering his handicap. To do that he’ll need to remember the small fixes that can have such a positive effect on his swing and resulting shot. He’s keeping a notebook of his yardage and his lessons so that he has something to go back to and review.

Over the weekend I closed my Highrise account.

In case your not familiar with the name, Highrise is a CRM product for small businesses. It started life as part of the 37signals range of products, but has since branched out onto it’s own.

The initial pull to using a CRM tool like Highrise is that I wanted to a tool that allowed me to store important emails from clients as well as track projects and work I was chasing with prospective clients. Highrise has great email integration that allows you to forward emails from clients to Highrise and it will store them for you. It also allows you to track deals which in my case represented prospective work with clients and creating proposals to win work.

I should mention that while Highrise is a great product, my decision to cancel my account with it isn’t anything to do with the performance and features of Highrise. It is a great product and under the right circumstances it is worth looking at if you need a CRM for your small business.

My main reason for moving away from Highrise was more to do with how I wasn’t using it to it’s full potential.

In the time that I’ve had to use Highrise, I’ve used the deals section rarely. It’s nothing to do with Highrise, it’s just that in the time that I have been freelancing, most correspondence takes place over email and I’ve rarely had to pitch for work. Most prospective clients like to discuss the work that they would like me to do and discuss my background and experience. After a few emails, most of these prospective clients then decide to exchange contracts to begin the work. I’ve rarely had to pitch for work and so the deals feature of Highrise has been left untouched.

The email integration with Highrise on the other hand though was used on a daily basis. Client emails went straight to Highrise as well as my replies to them. Although I used this feature daily, there were only a handful of different clients to deal with at anyone time so while the archiving of these emails in Highrise was nice to have, most of the emails involved discussions before work began. My email provider already offers a large amount of space to store emails and they’re filed away in a folder. I was starting to wonder if I needed Highrise to manage the storage of emails.

Finally there was the managing of contacts. Yes I do have all my clients contact details, but I rarely have to refer to them. I speak with clients daily when working with them, I use email to send weekly updates and invoices and for all other daily correspondence with clients I recommend Slack. All my clients details are saved on the appropriate devices I need to have them on and aside from that there’s no other special requirement to managing this data.

It was starting to look like I didn’t need Highrise at all.

After deliberating for a few days I finally decided to export all my data from Highrise and delete my account. Without a CRM though I needed something else. All my client details are already stored in my address book but I needed something else that acted as a more detailed version of their details and allowed me to find and filter contacts based on information I have recorded against each of them.

The answer lay in a document type that I rarely use. The spreadsheet.

After getting the contact columns in the spreadsheet in the right order, I imported the contact details in and started adding the necessary changes I need so that I could filter those contacts.

Right, so the spreadsheet doesn’t have all the bells and whistles of Highrise, but for the moment it will do. I’ve got all my contacts in one place. I can filter them based on the next date with which I need to contact them for a catch up and there’s enough flexibility in Numbers in that I can add more information if I need for each client.

If my client base was to increase over the next 12 months and work started to change on a monthly basis then I would definitely consider Highrise again. It is a great product, but I couldn’t justify it’s use as a simple address book and email archive.

For the moment though, the spreadsheet is enough for me.

The blogroll has been chirping about coffee shops. First it was Future Lawyer:

First, some of us refuse to pay 3 to 5 dollars for a cup of coffee, so we don’t spend a lot of time in Starbucks. But, we do have lunch at Panera Bread, and we don’t use the public WiFi there either. At least, we don’t use it without first tunneling through a VPN.

— Why Lawyers Should Never Use Starbucks WiFi by Future Lawyer

Then Cultural Offering.

I freely admit that I dislike Starbucks. On the few of occasions I have been in the chain - airports, a meeting or two, and when an employee needed to throw up (seemed the perfect spot) - I found myself wanting to tell the students to try the library and the adults to try a tie and a home office.

— The shoes bother me the most by Cultural Offering

Then Execupundit.

I like Starbucks. It is a convenient and comfortable meeting spot. I ignore the computer users who are tapping away at, no doubt, the next War and Peace. The Americano is a nice watered-down version of their strong coffee. When ordering I still use small, medium, and large rather than their menu lingo. That immediately signals “out of touch” to the staff and thus is desirable.

— The Starbucks Experience: In But Not Of by Execupundit

I’m fortunate enough to have a coffee shop in town that isn’t Starbucks, has plenty of seating and has some damn good coffee for those mornings when I need it to make the code flow.

And yes I also say small, medium or large.

Lately I’ve been thinking a lot about marketing.

While making my afternoon coffee I was running some editing changes through my head on a post I’m writing. And then it struck me.

If you’re not writing, you’re not marketing.

I’ve struggled with marketing my freelancing business in the past, but I certainly could start making a step in the right direction by writing more for my freelancing business.

I would love to see a return of some great quality and slim netbooks.

I’m in the middle of assessing a new iMac to replace my MacBook Pro which means I still need a device that I can take to client’s to do the odd bit of on site programming. Unfortunately the iPad Pro is a lousy programming device, which leaves a gap for an affordable netbook that I can run Linux on and take to clients.

Finally broke out the other stack of Field Notes notebooks I got with my Black Ice editions. Dedicating a notebook to sketching ideas for web based products like themes and web sites. First port of a call though is a new landing page for DigitalBothy.

There comes a point in your career when you can no longer coast along just punching in and out and doing a day’s work. Nobody tell’s when that time will come. It can be in the first few days of your job or after years of working for yourself.

When that time comes to level up, you can do two things.

1. Ignore the opportunity and keep coasting along doing the same thing you do every day. Eventually though the opportunity will reveal itself again.
2. Use the opportunity to level up and start making improvements in your career and your prospects.

While I’ve been doing client work for five days a week for the last two years, the chance to level up has presented itself on a number of occasions. Each time though I’ve used the excuse that I don’t have the time to make improvements or start learning something new, and while that is a poor excuse, it’s what I did.

I’m paying the price for it now though. I’m still busy working for clients and next year’s schedule is looking great. I can’t always bank on having the same clients though in the next five years. They may no longer be using the web frameworks that I specialise in, they be looking for alternatives that I am not well versed in. They might even want to take a look at something completely new.

When clients want to level up, you need to be ready to level up with them. Whether it’s technology, tools or processes, you need to be able to have enough knowledge to level up with them. To make this transition as easy as possible it helps if you can be the one that levels up first. Then your party of clients can follow.

So when the opportunity presents itself to learn something new, do yourself a favour. Don’t ignore it.

Over the last few weeks I’ve been looking at themes for Wordpress and Ghost.

Now it’s easy to say that Wordpress has a clear advantage over Ghost. It’s a CMS that’s used by millions of people all over the world. Wordpress has been around since the early days of the Internet and it’s still the goto CMS for many people and rightly so. It’s extensible, stable and has thousands of themes available for it.

The Wordpress marketplace for themes is huge. There are thousands of themes available for all different types of sites. From minimal themes for bloggers to highly customisable themes for organisation sites. There’s something for everyone.

Ghost is still relatively new when compared to Wordpress and while it is more specifically a blogging platform as opposed to a CMS like Wordpress, it’s still gathering a steady number of fans.

The Ghost marketplace for themes isn’t so big but that doesn’t mean there should be a shortage of themes.

There are a number of themes available but there’s two problems I see with most of the themes available for Ghost:

1. Image heavy themes - It seems that most themes for Ghost see having images as a neccessity in their theme. While looking for a theme for my own blog I found it difficult to find a theme that didn’t feature a full width banner and images for every post. Their themes probably do allow imageless posts but they never show that in their previews.
2. Out of date themes - Ghost is on version 0.11 but many of themes available are falling behind in terms of compatibility.

It seems there’s a gap in the market for Ghost themes that don’t need images everywhere and stay compatible with the latest versions of Ghost.

The number of people using Ghost isn’t in the same realms as Wordpress but I do find it much easier to use as a blogging platform. Ghost as a product is generating revenue and with an open source option available, there’s definitely a growing number of people using it.

With the right marketing a designer/developer could do well with a number of themes that focus on minimal blogging rather than images.

I released a new version of the Ghost theme I use for this blog last night.

In an effort to kickstart the blogging habit again, I looked at my blog and ways that I think it could be improved in terms of readability.

Improved readability

The previous version of Daring had a default font size that was far too small. Even on my MacBook Pro at 1280px wide the font size difficult to read. I’ve bumped the default size up to help.

I’ve also made the width of the content area slightly wider and reduced the padding of the content area. I’m trying to use as much width as I can without pushing the sidebar column and the content column too close together.

More themed elements

I’ve also included a number of themed elements for the blog. The bar at the top is nothing more than a bit of decoration on the page and there is additional styling for submit buttons you might have on a contact form.

This is just another step towards producing a quality Ghost theme for people that don’t want to use huge banners and images for their blogs.

After a week of considering closing this blog and starting afresh elsewhere I’ve decided against this move. I’m trying to kick-start the blogging habit for October and so this week is a spell of light blogging to get me started. Expect more frequent writing here from now on!

The world is going gaga for mobile apps. They are seen as the most accessible form of software and the market for them has moved at a considerable pace. The only problem with mobile applications is that only the bigger companies can usually afford to have their apps available on each of the different mobile platforms. This isn’t a problem for the web though.

For me the web is still the most accessible and reliable platform for applications there is. Using just a single interface (your browser) you can access millions of products and services. Here are a few I use every day to help with my web development work.

Github

Despite a flutter with BitBucket it’s hard to move away from Github. Their product is delivering features on a steady basis and just about every developer has a profile there. The Github community is growing and with more organisations making Github the home for their projects it has become the goto place for sharing code and projects.

Trello

For project management with clients, I like to use accessible and visual tools. Trello fits the bill in both respects. Their Kanban style boards are great for getting an over view of a project and the ability to include checklists, attachments and comments makes it a great collaboration platform for myself and my clients.

Heroku

In the last year I’ve reduced the number of SAAS platforms I’m using down to just Heroku. Gone is my Linode and Cloud66 accounts and replaced with Heroku. For my own projects it’s the ideal platform. I always recommend it to clients who are just starting out with a new project. I’ve moved a number of my own Rails applications to here and now use it exclusively for all my web app hosting needs.

Highrise

My CRM of choice. For a long time I got by on just using an address book, but in time I started to see the need for something more sophisticated than an address book. I needed a tool to record emails with clients, their details and important projects.

I use Highrise on a daily basis and find that it’s ability to send emails to Highrise means that I’m not only collecting my clients information there but also important emails communicating between myself and my clients.

Freeagent

Finally there’s FreeAgent. Still the best invoicing and time tracking solution for freelancers and although I’ve been using it for over three years now, I’m still learning more about it everyday. I’m not using it to it’s full potential at the moment but I am hoping to make better use of it as the year goes on.

Desktop apps are my main tools when it comes to web development. A browser, a terminal and an editor. That’s the absolute minimum applications that I would need to do a days work but there are a few more desktop apps that I also use to help get a good days work done.

iTerm2

My terminal of choice hasn’t changed but what has changed is that I’m now back to using iTerm built-in pane management rather than using tmux. Most days I tend to just have two terminals open side-by-side and that’s all I need. Tmux is a great option if you need more control over your terminals AND you run an editor like Vim but for me it was overkill.

Sublime Text 3

The last time I wrote a post like this Vim was my goto editor for coding. Despite sticking with it for over a year and I eventually switched back to using Sublime Text. I also had a brief spell as well with Atom but I prefer using Sublime Text. It’s what I’m most comfortable with.

Safari

I also switched browsers and moved back to using Safari for browsing and as my preferred browser for building and testing Rails applications. Open source it isn’t, but it’s a solid browser and the ability to sync tabs between different devices is a feature I use frequently. I still use Firefox but more as a secondary browser.

Dash

Not an essential tool but something I’ve come to rely on heavily over the last year. Dash is a document browser and code snippet manager. I don’t use the code snipper manager but the ability to lookup the docs for the different frameworks and programming languages I use makes my day a lot easier. It also negates the need to do frequent searches online.

1Password

Probably my most valuable piece of software. Secure, easy to use and makes handling your passwords a lot easier. I’m also using 1Password for families to allow my wife and son to handle their own passwords. So far it’s working well.

Slack

Last year I was a big HipChat user, but the pull to Slack and it’s growing set of features was difficult to ignore. Starting with a couple of clients, I gradually made the migration across and now use Slack exclusively as my online meeting point with clients.

For this week I’m going to focus on the different development tools I use and why I chose them. Today we’re going to look ay my hardware line up. It hasn’t changed since the last time I wrote about this in 2015.

MacBook Pro

I’m using the same MacBook Pro I bought in 2014. The only issue I’ve had in the last year is that I stupidly left it plugged in all the time. Over time the battery gradually degraded in performance and got to the point where I was only getting an hour or two out of it. An appointment at the Genius Bar and was able to get a replacement battery for my MacBook. Now my battery performance is back to a level where I can safely work away from my desk for longer.

The MacBook itself is still fast and responsive. The screen is probably the feature I like the most about it. The crystal-clear Retina screen is easy on the eye and makes reading articles and code easier with no blurring of pixels.

Dell U2414H Monitor

My Dell monitor is still clear and crisp and is my main screen for the day when I’m working. It’s not as clear as the Retina screen on my MacBook but it’s close enough that I can use it all day for coding.

Logitech K811

I love this keyboard. With it’s backlit keys and ability to switch to multiple devices I’m happy to keep this going for the foreseeable future.

If you’re thinking of buying one or are having problems with battery life then I suggest you turn off the backlit keys during the hours of the day where you can see the keys using natural light. I used to have the backlit keys on all day, and it drains the battery on the keyboard quickly.

I don’t see this version of the keyboard on the British Logitech website but it is still available on Amazon. There’s a new model, the K870 that has rounded keys. Not sure if it’s any better than the K811 but the multiple device support is there with a docking bay for your phone and tablet. Not sure I’m sold on the rounded keys though.

Mighty Mouse

Finally there’s the Mighty Mouse. I’ve persevered with this for over two years now and the problem of frequently disconnecting from my MacBook is still there. If anyone has any recommendations for alternatives to the Mighty Mouse then I would love to hear from you.

Seagate Backup Drive

I’m still using this Seagate drive for Time Machine backups. I haven’t had to do a restore from it for sometime so I think it might be due for replacement. I’m not sure on the lifespan of hard drives but I would like to move to something a little less bulky and faster. Perhaps an SSD drive would be a nice addition to my backup process.

Anymore Changes?

My hardware selection doesn’t get changed that often. I know developers that change their equipment on a yearly basis but if it works, why change it? I did consider the move to a MacBook Air in the past but the MacBook models have changed again and I don’t see me making the move to a MacBook or MacBook Air. It might be another year or two before I consider changing my laptop again for another MacBook Pro, but until that day I’m happy with what I have.

For many software developers, rolling your own version of a product is a tempting thing to do. You might want to add your own feature to the product or you might think that having more control over your data is important.

I recently questioned the value of FormKeep, a product that I was using. FormKeep allows you to create forms for any website and persist the information from the form without the need for your own database.

This isn’t a problem for a CMS like Wordpress as it already uses a database for persisting data. In the last few years though static websites have become popular. The simple action of generating the website for each change makes them ideal for people that have websites that require little maintenance. There is one drawback though. With the website being static, it can’t process information and store it anywhere. Static websites are a collection of files served by a web server with no backend database. So how do you add a form to your website?

For a while there’s been a number of products that allow you to embed a contact form in any page on your website, but the problem with this is that the embedded form is typically different in terms of style to the rest of your website and it can look out of place.

FormKeep does away with this drawback by providing just the endpoint that a form will submit too. The obvious benefit is that your form will still share the same look and feel as the rest of your website. Given the popularity of static websites, FormKeep definitely fills a need.

The trouble with FormKeep though is that while I do have a number of contact forms on different websites, there was always a niggle at the back of my mind that I was paying significantly more for a product that I could build on my own.

I’ve tried this in the past with a number of products and it doesn’t always work out. I created my own bookmarking site that included many of the feature that Pinboard offers, but there was still a number of features that I didn’t build. For the money though, it’s hard to argue with Pinboard’s pricing. $11 per year for hosting your bookmarks with a further $25 per year to keep copies of the original URL for each bookmark in your account. I could blow through twice that in a year for similar hosting on Heroku. Eventually I learned my lesson and gave up. I re-opened my Pinboard account the following day.

Building my own FormKeep was simpler than building my own Pinboard though. All I needed was an endpoint that accepted form parameters and saved them to a database. I set aside a few hours one day and quickly had my own version of FormKeep up and running. It’s running on Heroku at a cost of $7 per month. Compare that to FormKeep’s $29 per month and already there’s a significant saving. I might not have the clean UI that FormKeep has but the UI I have works for me.

In this case rolling my own solution worked to my advantage. I still have the same functionality that I had in the past with FormKeep and I’ve made a significant reduction in my expenses for the year now with my own solution now requiring just $7 per month.

Rolling your own solution doesn’t always work. Products might have years of features behind them that you just can’t replicate with a few hours of work. Sure you could have the most important feature up and running but what else needs to be added before you can safely say that your own solution will fit all your needs?

In the case of FormKeep it’s still a fairly small product and can be duplicated. And that’s where I think products need to be wary.

I was a long time user of FormKeep and in that time it’s feature set didn’t change much. Don’t get me wrong though, FormKeep definitely is valuable to people that don’t have the knowledge to run their own endpoint for capturing forms. For a user like myself though, FormKeep doesn’t offer anything that can’t be duplicated in a few hours of coding and that’s something you should consider if your building your own product.

If your product has a small feature-set that can be easily duplicated in a few hours then is it providing value?

Give me a project any day of the week.

Projects are open-ended, chosen and ours. Working on a project opens the door to possibility. Projects are about better, about new frontiers, about making change happen. When in doubt, dare.

Your job vs your project by Seth Godin

Great advice for programmers and anyone building a product.

In this mindset, each day your task is to fight from failure to success. You no longer are so willing to compromise, or to sweep seemingly small challenges under the rug.

Instead, you aggressively seek out challenges and problems, and attempt to eliminate them in order to salvage the already failing project.

— Failing on Day One by Thoughtbot

Some months ago I’d decided to use Atom as my go to text editor for day to day programming. I had been hearing good things about Atom for a while and the popularity of its packages means that I could easily switch to Atom with no major interruption in my workflow. There was one thing I wasn’t counting on though.

Atom is slow. Not slow that it makes a huge impact on my day but slow enough that it leaves me hanging for a few seconds after certain operations. Even opening a project can have a lag of a few seconds.

Coming from Sublime Text this was a huge disappointment. Sublime Text has always been a fast text editor. Even the indexing of files within the project you are working on is fast. Opening files, creating panes, finding and replacing, all lightning quick. And much faster than Atom.

Speed isn’t a major factor when you’ve done a single days coding but adding all those little seconds up over a period of a year and you’ll have a significant amount of time.

Some suggestions for alternatives to the workplace social network.

Yesterday I wrote about the value of Twitter on a personal level. While I don’t place much value on my personal Twitter account, I have found that having a seperate social media presence can let me split my time online and have that time spent in a more focused way.

I operate as a sole trader in the UK which means I trade as a business under my own name. It also means that I can use a trading name for my freelancing work. The added benefit to this is that I can give myself a corner of the web dedicated to that aspect of my life. I could publish technical articles under my own name and on my own personal blog but as I already blog on a frequent basis on other topics then I would end up two different audiences on the one blog. To keep them separate I decided to start a separate blog for my web development writing.

This year I decided to apply the same tactic on Twitter and so I created a new account (@digitalbothy) for my freelancing business. The idea behind this is to act as a social media funnel for the web development blog I mentioned above to be able to found on at least one social media network. As I’m already on Twitter it made sense to start there.

There’s another benefit to this. Lately I’ve been trying to limit the amount of people I follow on Twitter, but it seems that no matter what I do I end up with more people on the list that I would like. Fear of missing out syndrome is hard though, and even though I unfollowed most of the occasional tweeters there’s too many people to follow.

Instead of cramming all these people under one account, why not bump the web developers, freelancers and other people that mainly tweet about this topic over to my Digitalbothy account? So that’s what I did. I started following most people related to web development and programming from my freelancing account and unfollowed them on my personal account.

Having two accounts running side by side isn’t much harder to manage than having two lists under the same account. In fact I would say that it’s probably easier.

Tweetbot’s multi-column feature on OS X means that I can see both timelines through the day when I’m working. As a rule I don’t check my freelancing account out with my usual business hours. If I’m checking Tweetbot on my phone it only has my personal account on it which removes the temptation to check on work related topics when I’m not at home.

I might not place much value on my own personal account, but at least now I have a place for the work aspect of my life online and it’s another way that I can be found by prospective clients.

Well done Scott Hanselman on reaching double-digits with his technology podcast, Hanselminutes.

Required reading for anyone looking to harness social media as a tool to connect your product with customers.

Conversations spark the success of products and ideas, helping them garner new fans and break into different markets.

— The Social Media Skinny by Steven Pressfield

I love this post from Adrian about what he’s learnt from his time as a developer and where he sees himself going next.

Take conscious decisions in your life. Be aware of your actions and their effect. Do not blush or be embarrased for changing your opinions. Say “I’m sorry” when required. Listen. Do not be a hotshot. Have integrity and self-respect.

— Being a Developer After 40 by Adrian Kosmaczewski

The big four-o for me is just around the corner. I can’t freelance for another twenty years, or can I?

Derek Siver’s latest post is the best business advice anyone needs before they start.

First you find real people whose problem you can solve. You listen deeply to find their dream scenario. You make sure they’re happy to pay you enough.

Don’t announce anything. Don’t choose a name. Don’t make a website. Don’t build a system. You need to be free to completely change or ditch your idea.

Then you get your first paying customer. Provide a one-on-one personal service.

Then you get another paying customer. Prove a real demand.

Then, as late as possible, you officially start your business.

— Don’t start a business until people are asking you to by Derek Sivers

For a moment there I thought I was reading the blog of Nicholas Bate. Similar styles of writing. Straight to the point.

John Gruber’s early notes on the beginning of Markdown.

Just another idea in a notebook.

via The Cramped

LinkedIn. The social network for the workplace.

I have something of a lax attitude towards it. I don’t share much on it and I rarely search for connections on it. I’ve even closed my account there, and then a couple of years later I setup my account again. Since then its use for me has gradually tapered off to the point where I’m once again considering deleting my account again.

As a freelancer though I wonder if I’m committing career suicide. I’ve looked at a number of other web development freelancers in the UK market and they don’t always have a LinkedIn profile. They certainly have their own website under their own name or a company name and usually a Twitter account too, but they don’t always have a LinkedIn profile. I can only speculate on the reasons for this, but I’d like to think they’re great in their field and don’t need to use LinkedIn. There could be other reasons though.

So I have a LinkedIn account at the moment but is it essential to have?

Before I decide on whether I should remove it or not I want to talk about why I’m not convinced that LinkedIn is right for me.

No Content Value

I’m not getting any content value from it. Based on the people I follow, few of them post to LinkedIn on a frequent basis. Only a small number of people in my network share content on a frequent basis at LinkedIn but it’s the same content I can find elsewhere.

Part of this problem is that I see LinkedIn as a secondary social network. I see Twitter, Facebook and Google Plus and a few others as being primary social networks. They are the first sources I would go to find content. I don’t see LinkedIn as being in the same league as these.

This also puts it in the stack of networks that I would question sharing content too. As a secondary social network, I don’t share anything there. I already have outlets where people can read my content and conversely where I can read the content of others through Twitter, email and RSS.

So if there’s no content on LinkedIn, then I see little need for me to share anything myself.

False Leads

I’m not getting the right leads from it. I often get offers of work for the wrong jobs.

For a number of years I worked as a Dynamics NAV developer. They’re a rare breed and are hard to find but even harder to find as being available for hire.

In the last five years I have done about six months of work with Dynamics NAV. So it’s fair to say that I’m fairly rusty on the platform and probably out of touch with it. Yet I still get messages in LinkedIn to connect with recruitment consultants to see if I have any interest in Dynamics NAV jobs.

This isn’t LinkedIn’s fault directly, but the platform they have built has now become a marketplace for recruitment consultants to find people that almost match their client’s needs. Often a keyword match will suffice, but based on my recent experience and job title on LinkedIn, I wouldn’t imagine that a freelance web developer would be interested in Dynamics NAV work again.

Too Complicated

I’m not a fan of the LinkedIn user interface. It is a busy and complicated website. There’s calls to action everywhere you look. Completing your profile, sharing content, connecting with others. It sounds a lot like any other social network, except for LinkedIn their aim is for you to connect with others and build your network. This doesn’t translate too well in terms of their user interface and rather than putting the focus on expanding your network they now have calls to action for other features such as sharing content and replying to or actioning content others have posted.

I usually log into LinkedIn on a fortnightly basis. I do a five minute check on messages and invitations and then I’m done. I’m everything that LinkedIn doesn’t want in a user. And for that reason I limit my time in using it.

There Are Benefits

So we’ve looked at concerns I have with LinkedIn but it does have it’s benefits.

Seeing recommendations from others is a great way for clients to see your value. It could be easily done on your own branded site by asking clients for recommendations though.

Then there’s the skills and endorsements. Now I admit that this is only a mouse click that others do for you. It shouldn’t be any kind of benchmark to measure a freelancer’s skill set against, but at a quick glance it can be useful to see who has recommended you for what. However the real value in a freelancer is seeing that knowledge first hand and that’s why I think it’s more important to see a freelancer writing about their experience in their field rather than just relying on this skills and endorsements feature from LinkedIn.

Finally, it is useful to have a network of people that you have worked with and more importantly to have that network separate from other social media accounts you might have. Mixing business and pleasure rarely pays off so it’s nice to have a separate network in the form of LinkedIn.

So why not use LinkedIn then?

I don’t use LinkedIn for searching for initial contacts for two reasons.

1. I find the invitations process to be too impersonal. Yes I have connections with others I have worked with but this is always with people that I have met in person or exchanged more than my fair share of phone calls or emails with. I don’t like the idea of blindly getting invitations to connect on LinkedIn so I don’t use them myself unless the person in question is someone I’ve met or someone I’ve chatted with on a frequent basis.
2. LinkedIn isn’t where I post content so I wouldn’t refer potential customers to there to begin with. Instead I would refer potential customers to websites I have worked on and to my own website.

For these two reasons I skip using LinkedIn to find clients. I favour direct contact with people using details from their website. Sure it might be a more manual process than searching for clients on LinkedIn and then inviting each one to connect, but tailoring each phone call and email to each potential clients shows a bit more effort to get to know that potential client.

What’s the replacement to LinkedIn then?

So I’ve filled you in about my opinions on LinkedIn, but if I’m not using LinkedIn, then how do I network? How do I market myself? How do I reach people?

Glad you asked.

When it comes to my freelance business I don’t measure it in terms of the number of connections I have, I measure it by how much work I have planned in the next six months. If the schedule is full, the business is doing well, if not then I need to find more business. It’s simple. There are a number of other reasons as well, but for the overall view of the business it’s easy for me to assess my position by how much work I have planned in the near future.

If I was going to close my LinkedIn account then I would need to find suitable replacements for each of the features that LinkedIn has. I already have a number of these setup .

Profile and Content

Right, let’s get the obvious one out of the way. You need a website for your profile and marketable content.

That’s easy. Get yourself a domain and a blog.

For a long time I has a single blog under my own name, but it was difficult to separate personal and work posts. So at the end of last year I decided to start trading under the name of DigitalBothy. I have a site for it now and a number of posts there that features the type of work I do. It’s early days for it and I wish I did this from the start but better late than never.

I have plans to make an about and contact page there so that I can easily separate leads from other messages to this site. I do get the odd question about programming and other topics on my personal website and I’m glad to help out and reply when I can but for freelance work I like to have a separate website for this.

Last year I got more referrals and work through the contact form on my own personal website than I did through LinkedIn. My LinkedIn profile might have helped but the fact that most leads came through my own website is hard to ignore.

Contacts

I need to manage my contacts. I don’t use the term network here as networking is the action of contacting people. As a freelancer I need to do more than just contact people.

I use phone, email, RSS and social networks to keep abreast of potential clients and industry news. I use phone calls and emails to find out about the position of clients and potential clients and whether they would be in need of my services. I also use email, RSS and social networks to monitor potential clients to see if there are opportunities potentially available or if their situation changes e.g. any recent investments or changes in company direction.

I use Highrise to manage contact with my clients and leads. It’s a relatively new addition to my list of freelancing tools, but I have had a CRM in one form or another but the decision to move to Highrise is because it has a number of features that I benefit from.

I keep all client notes, emails and documents in a feature that Highrise calls a “case”. I have one for each client. Keeping everything together makes it easier to search for client details, deliverables in an email or a deadline that a client has mentioned.

Highrise also has great integration with email which means that I can redirect client emails to Highrise by just including the dropbox email for each client. I also use Mail to redirect incoming email from clients to Highrise as well.

This is where LinkedIn falls short for me as a tool for my freelance business. LinkedIn has the tools to create and grow your network but that’s where it ends. I could use LinkedIn’s own tools to message clients, but LinkedIn isn’t a true CRM or an easily accessible platform to find my content.

With my own tools I can start building my profile, marketing myself with content and make connections with clients and leads to help keep my freelance business ticking over. And it’s working well for me.

So do I need LinkedIn as a freelancer?

Probably not. It offers little to me in terms of value other than being a network tool, but networking involves more than just clicking buttons. True networking is face to face meetings, phone calls, emails and going to events. Sure it’s nice to sit behind a desk and search for potential clients on LinkedIn but the true value comes from searching for those potential clients out in the field and tailoring your introduction to each of them. It comes from marketing your valuable skills in the best way possible and with case studies to back it up.

Still I can’t help but think that closing my LinkedIn account is wrong to do, but only because it has become commonplace to have one. For many it is necessary to have one, but LinkedIn’s value to me is questionable.

I’m still on the fence about closing my LinkedIn account, but in the meantime I will be tailoring it towards what I do now as a freelancer and relying on it less in the future.

There was me thinking I was absolutely bonkers for not falling head over heels in love with the current trend towards towards JS web frameworks.

The web (specifically the Javascript/Node community) has created some of the most complicated, convoluted, over engineered tools ever conceived.

— The Sad State of Web Development by Drew Hamlett

I do like Drew’s advice for web applications that have one or two pages with a complex user-interface.

So my advice is to use Rails Django, Play Framework, or Phoenix to develop most of the app, because they help you with most of the boilerplate stuff, and bring in the flavor of the month on a page that needs it. So when the next flavor of the month comes out you’re entire app is not knee deep in the last flavor of the month. You can just re write that one page.

— The Sad State of Web Development by Drew Hamlett

Curtis McHale continues his look into winning proposals with a look at four essentials for any proposal.

Real business owners who want to take their business to the next level aren’t interested in airy-fairy notions of how your work will help their company. They want tangible, concrete evidence by which they can measure the success of a project.

— Defining Deliverables, Outcomes, Metrics and Values by Curtis McHale

Still the best blog for freelancers in my book. It’s an essential every day read for me.

Photo by myself after an ice storm hit Toronto in 2013.

Aside from putting my family first and helping clients build great web products and services through DigitalBothy, here’s what I’m spending my time on:

• Documenting some API endpoints for PenMuse.
• Including only relevant writing prompts for the current time of year.
• A new re-design for DailyMuse.

Last Updated December 2017. Inspired by Derek Sivers.

Brett’s latest bookmarklet is great for programmer. Turns code blocks into plain text and make them ready for copying. Nice!

This blog has been gradually winding down in activity for the last few weeks. You’ve probably noticed. It’s been hard to watch as I used to be a frequent poster. Daily blog posts, links and other trivial things that might interest you the reader.

Truth of the matter is that client work has all but consumed my week. I’ve got two projects on at the moment and I’m splitting my time between them in fortnightly periods. The work is good and it looks like it will carry through to the new year which I’ve no complaints over.

The problem has been dividing my time so that I’m not always hunkered over my desk. My desk is where you’ll find me through the day, usually wrestling with some code, but sitting there outside of my client hours makes it difficult to ‘switch off’. Lately though, once the client work is finished you’ll usually find me playing with the kids until bedtime and then its television for an hour or two before the exhaustion kicks in.

A couple of years ago I had a good routine going. Writing in the morning, 3 periods of client work throughout the day, as well as time to work on new languages and frameworks and working on side-projects. I was getting things done. Not just that, but I was also getting out on the bike and keeping the weight off. Last time I was out on the bike was a few weeks ago with Ethan. I haven’t been out on the bike since.

Last night I took a look at the heat map on my Timepage app for December. Aside from the usual calendar functions, it shows your calendar as a heat map where you’re busy and not so busy. Almost nothing showed up. There’s a day where Ethan has golf coaching and a day for the Star Wars showing. Apart from that there was nothing. It seems I have lost sight of one of the fundamentals of any productivity system. Schedule it.

Client work has become such a big part of my day that I no longer plan for anything else getting done. Without the planning of the day most stuff falls through the cracks. It’s usually the little things like writing and side-projects. They’ve suffered the most.

Out of sight, out of mind. If you don’t see something often enough you tend to forget about it. Like my calendar. I didn’t plan for anything and therefore didn’t see the need to look at my calendar. Everyday was turning into the same work getting done so why bother scheduling anything?

I’ve just proven to myself that there’s nothing gained from an empty calendar. Time to change that.

… I’m breaking down the technical debt concept for product stakeholders.

Two words that fill me with dread. About me.

I don’t mind writing about a lot of things, but one topic I find difficult to write about is myself. In the past I’ve written about decisions, tools and experiences but the one topic I rarely write about is writing about myself in order to sell myself. Yes, the dreaded about me page.

I’ve managed so far to do well with my self-employed freelance career but things stagnated a bit over the summer. In order to keep the business ticking over, I’ve started treating my freelance business as a separate entity to my own personal website. I’ve relaunched my DigitalBothy blog and I’m in the process of writing a number of technical posts to showcase my expertise. A platform for people to see what I can do. I’m also writing a new about me page for the blog to sell myself as a freelance developer.

Technical writing isn’t a problem. I’ve found my voice (or tone) for that style of writing. An idea, an outline, a draft, a number of edits, a final proof and I’m usually fairly happen with what I have written. When it comes to writing my about me page though, that’s where it becomes tricky. Writing my about me page or even a resume is not something that comes as a naturally as the technical writing.

As a person I’m quiet. I’ve always been that way. And it comes through when I’m writing my about me page. I tend to overlook and downplay the achievements in my career. I can’t afford to be that person. I’m hoping that these few paragraphs can prompt me to be a bit more vocal when it comes to selling myself.

I’m off to grab a coffee and have another stab at the about me page. Thanks for reading.

New website but always the same great content.

In the last few months I’ve made an interesting discovery. I’m crap at building and marketing products. Really bad in fact. From now I’ll just build stuff, give it away for free and keep plugging away at the client work. I’m happy with that.

Pearls of wisdom from JavaScript laureate, Thomas Fuchs.

Don’t follow the hype

Use what works for you. If you’re productive in PHP, by all means, use PHP. Of course, sometimes technologies come along that actually measurably increase productivity or have other huge advantages, but it can’t be overstated how few and far between those are — perhaps one or two happen in a decade.

— How to actually ship software that actually works by Thomas Fuchs

Don’t be afraid to challenge prospective clients with goals. Make them work to prove that they’re really the right clients for you. Be bold.

— Curtis McHale by Curtis McHale

Read on for the full background story.

It’s a question that I’m seeing on an increasing basis as I venture through the Internet. I’ve seen it appear on a few forum sites and it has appeared in a couple of newsletters that I subscribe to.

Before we answer the question, let’s take a brief look at the history of Rails. 10 years ago the first version of Ruby on Rails dropped. It caused a stir due to the ease with which web applications could be made. In that time it’s moved on through four major versions, had hundreds of releases and has been the collective work of hundreds of software developers who have devoted their free time to making Ruby on Rails what it is today.

Since then there’s been a search for the next killer web framework that will replace Ruby on Rails. 10 years on I’d say we’re still waiting. No other web framework has had the impact that Ruby on Rails has.

So is Ruby on Rails still relevant?

Definitely yes. While a lot of developers have adopted and then moved onto other languages and frameworks, there is still a large amount of developers that specialise in Ruby on Rails. The market for Ruby on Rails developers for full-time and contract work is still healthy. There’s also still a large amount of companies and organisations that need Ruby on Rails developers to maintain web applications and there’s still a demand for these developers with Greenfield projects as well.

It’s not as highly a sought after as it was maybe five years ago, but it’s still a relevant technology as well as a mature technology. It’s been tried and tested by many developers and it’s benefits for building web applications is well known now. Given that companies would rather not risk building an application in a new and unfamiliar technology, Ruby on Rails is now seen as a mature web framework that has grown up over the years.

Ruby on Rails will be relevant for at least the next five years and possibly the next ten years. From there, who knows. As long as it is a low-risk technology for clients, I’ll keep recommending Rails for projects that it is a good fit for.

No sooner do I get settled with Monoid when I hear of another coding font. This time it’s the code-generated Iosevka.

Got me a new coding font.

About a year ago I made the jump to Vim. Having finally mastered enough of the keystrokes to muster through a single coding session, I made it my default text editor for programming. In the last couple of months though I’ve been using Atom for most of my programming. The reason for the move? Just for a change. Atom does have a number of niceties that encouraged the switch.

Good Looking

Vim is simple and productive but let’s be honest, it’s not exactly an eye-opener as development tools go. Sure you can cut and splice code like a keyboard armed ninja, but its look begins to get a little dull when you’re using the same development environment for most days of the week.

Atom, like Sublime Text is it’s own application and doesn’t run within your terminal. The plus side to this is that it isn’t restricted in the way the user-interface can give feedback to me through elements like auto-complete suggestions and notifications.

Atom is easier on the eye and maybe that’s a cop-out reason for making a change in your development tools, but my eyes start to strain staring at a two-pane terminal session for most of the day. Maybe it’s an age thing, but coding with Atom is much easier on the eyes than writing code within my terminal app.

Keyboard Friendly

Atom, just like every other development tool on the planet has a list of keyboard shortcuts that eliminate the need for a mouse. Not only that but there are some keyboard shortcuts from Vim that I can take with me to Atom. Also, like Sublime Text it includes a command palette to allow you to lookup and select the right command for the job.

Atom is keyboard friendly but more importantly for me, it’s familiar in that most of the keyboard shortcuts I use are either from Vim or similar to shortcuts that I previously used in Sublime Text.

Switching to Atom wasn’t prompted by it being a more productive editor, its growing community of packages or the fact that it’s made by Github. The reason for the switch was just for a change. Sure I’m just as productive with Atom as I was with Vim or Sublime Text but sometimes you just need a change of tools to keep things interesting. A simple change like this can stir things up for the next few months or even years. At least until they perfect a text editor in the browser.

A tweet by Brian P. Hogan sums up brilliantly what I’ve been doing in the last two weeks to stay sharp.

Whether you’re playing scales, shooting free-throws, or writing a web page, repeating the basics keeps you ready to perform.

— Twitter by Brian P. Hogan
I’ve started using this practice in the last two weeks to help me stay sharp both mentally and physcially.

Mental Practice

In the last couple of weeks I’ve started learning Python. To do this effectively I needed a list of problems and solutions in Ruby that I could compare with Python. I didn’t have anything so I started building Ruby implementations of basic data structures like lists, queues and stacks.

The solutions themselves are not complicated but that practice of writing simple classes and tests is something I’ve been doing almost every day for the last two weeks. What I’m hoping to do is to have a repository of code examples that are easy enough to do in thirty minutes, but can be used a starting point for other programming languages.

So far, I’ve been implementing similar data structures in Python and so far I’ve found the learning process to be much easier than if I had simply just started reading a book in Python.

Physical Practice

They say you never forget how to ride a bike, what they do forget to tell you though is that your body usually forgets rather quickly how much effort is needed to ride a bike.

Over the last twenty years I’ve had gaps in my riding that has sometimes amounted to months. Technically, I’m good on the bike. Shifting weight between the wheels, getting the right gear in place for tricky climbs and maintaining balance on the bike for when things almost grind to a complete halt. These little tips and tricks have been amassed over years of riding bikes. They never leave you. What does leave you though is the rest time that your body needs in between intervals of high intensity cycling.

To combat this physical forgetfulness, I’ve started doing intervals at my local trails to help get my recovery time down. The basics of bike riding are often seen as having the technical chops to guide the bike fast through obstacles on the trail, but you need more than this to keep the momentum of the ride going. The intervals help by reducing the rest time your body needs through periods of high and low intensity riding. After a couple of interval sessions I’m already starting to see improvements.

Repeating the basics can be applied to any profession or activity. Taking the basics of the activity and practicing them regularly help ensure you never go rusty or get out of shape. It’s a small investment in time and effort to stay sharp but it’s an investment I’m willing to make for the benefits in the long term.

It’s early days but I’m starting a new blog with a focus on web development. DigitalBothy will be the home for all the technical stuff that I don’t want to post here. Great to have an outlet for this. I’ll be writing there on a weekly basis.

Great to see the US government using leading engineers from Silicon Valley to work on their digital infrastructure.

Lisa had just spent time on the upper management teams at Hulu and BET. She decides, reluctantly, that she’ll go take the meeting, which includes this guy named Mikey as well as this other guy named Todd, and turns out to be in the Roosevelt Room in the West Wing. Then President Obama opens the door and surprises everyone, and over the course of 45 minutes gives the sales pitch to beat all sales pitches. They need to come work for him. They will need to take a pay cut, the president announces. But he doesn’t care what it takes—he will personally call their bosses, their spouses, their kids to convince them. The crowd laughs. But he gravely responds: I am completely serious. He needs them to overhaul the government’s digital infrastructure now.

— Inside Obama’s Stealth Startup by Fast Company

Not me, but my fellow Scot Matt Gemmell. His 15 minute guide to consulting is a wonderful guide to what consultants of any industry should aspire to. So good, I’ve added it to the playlist.

Learning tends to come from acquiring the knowledge of topics that we’re not familiar with. This is why as kids we all went to school. At a young age we have limited knowledge of how to read, write and count. Through years of education and study we eventually acquire enough knowledge to allow us to learn and understand each of these topics. We can specialise in this new found knowledge by going to college or university or moving into the workplace and getting a job.

What about what we already know?

There I was this morning setting up a new database for an application I’ve been working on for a client when I noticed that the application’s scripts to setup the database wouldn’t run due to a dependency on data in the database that was always assumed to be there. Simply put, I couldn’t create the database from these scripts.

So my knowledge of the application has changed and I have learned something new. What I have learned isn’t a new topic, just a tiny part of a topic I already know. My experience with the database scripts has taught me that basing the build process of the database on data that is already assumed to be there is wrong.

While we tend to seek out to learn from new topics, we forget that we can also learn from experiences. At time we might think that the knowledge we have is correct, but it’s only through experiences that we find out whether it is correct or not. In this case I have raised my concerns with the client about the build scripts for the database and proposed a solution to correct it in the future.

Always be learning. Whether it’s from new topics we know nothing of or by fine tuning the knowledge we have through experiences.

As I move towards building up my GitHub profile with examples of work, I realised something about my side projects. They provided the perfect place to try new things and familiarise myself with new programming languages and frameworks.

Most web developers have probably at one time or another had a side project running alongside their day job. It could be an open source web application, a framework, a library or even a product or service that provides an extra bit of income. Regardless of what it is, having a side project is one of those things that web developers usually end up doing. It’s almost like a rite of passage.

Most developers are working on large applications in their day jobs. Some are more fortunate than others on the choice of technology they’re working with, but there will always be developers that are not using emerging technologies or languages at their day job. It just isn’t always feasible to do.

So what’s a developer to do?

Well, like most developers I usually turn to a book to pick up something new. I might read five or six development books in a year. Most of the time I won’t go beyond reading the book to exercise the knowledge that I’ve picked up. When I do though, I usually put together little scripts or programs to get familiar with the language that I’ve just read about. Beyond that I rarely do anything else.

The best place to exercise your new found knowledge thought is on a side project. When I hit on an idea for a side project, I’ll write a little spike for idea in Sinatra or Rails and see if it’s worth having around. If it is, I’ll keep it and use it for my own purposes. Rarely has anything made it past this point though.

With what I have been using on a daily basis though, I’m starting to tidy these bits of code up and put them on GitHub profile. I have one little side project called ClipPress that I run on a free Heroku instance. It’s just a single form that I can fill in a few details and it will create a post in my Jekyll blog on Dropbox. It then syncs back down to my MacBook where I can fix up the post and publish it.

A number of Javascript libraries like Ember, React and Backbone have recently caught my eye. In the past I haven’t gone beyond the basic demos with these, but having a side project like ClipPress means that I have a working environment to try out new things. I can plug in different JavaScript frameworks to see how they work. I can write the ClipPress application in a different language or framework just to see how they compare.

The benefit of a side project is that you have a working base to build upon. Building applications from scratch can be tedious work, and making something new for the sake of learning something else means that we might not see the end result in action. With a side project though you can build on the code base you have to see the results in a working environment.

Side projects are often cited as a way of generating extra revenue and they can be that if someone is willing to pay for it, but for most of us we just want to hack something together that removes a manual step we’ve had to do in the past. These side projects are a great place to try something new and learn from it.

I hope not.

Technically, it’s simple. The web cannot emulate native perfectly, and it never will. Native apps talk directly to the operating system, while web apps talk to the browser, which talks to the OS. Thus there’s an extra layer web apps have to pass, and that makes them slightly slower and coarser than native apps. This problem is unsolvable.

— Web vs Native: Let’s Concede Defeat by Peter-Paul Koch

It’s not all bad though. Peter-Paul does go on to say how web apps can still compete against native apps.

I’ve been searching through various contract opportunities over the last few weeks. Client work is slowing down and I have some availability over the next few months. Might be a good idea to look around then! One common feature of each ad is that most of them have included is this:

Include a link to your GitHub profile.

For the non-developers amongst you, GitHub is a web based source code repository service where developers and organisations can keep copies of the code they are working on and have worked on. To this end, it’s often referred to as a resume for developers. Not every developer has a GitHub account though (there are alternatives like BitBucket) and certainly not every developer has an active GitHub account.

Are recruiters (both agencies and companies) basing their candidate search on developers who have active GitHub accounts?

Does my GitHub account reflect the capabilities of myself as a developer?

I certainly hope not.

In the past I moved my repositories over to BitBucket to give it a try. I left my GitHub account open but there was little on it. Now, I’m back to using GitHub and I make use of it by keeping some projects I’m working on there. Most of them are private. They’re ideas that I would rather keep to myself. For little projects and other stuff, I throw them up on my GitHub account as public. Not as bragging rights to my capabilities as a developer but to share my code with other developers.

If most agencies were to look at my GitHub profile at the moment and make a decision based on that alone, they would skip right over my application. The problem is though that my GitHub profile is one facet of my career as a developer. I have a good history as a developer and a variety of experience. I have a couple of recommendations on LinkedIn and an up to date CV there. I’m running my second attempt at a product with DailyMuse after I killed the failed Journalong product.

I’m certainly not a developer that lives and breathes code. Once the work day is over, I might hit the trails on the mountain bike, take my son to the golf so he can practice, or just go for a walk with the family. And that’s just the tip of the iceberg. There’s so many other things I do outside of work that doesn’t involve writing code. Yes, I have a number of little side projects on the go. Most developers do, but they’re low on my priority list.

While my career is important, it’s also important to get the balance right between what you do for your career and what you do elsewhere. I do write code outside of work, but most of the time I’m doing other things like spending time with my family, riding one of my bikes or something else that isn’t writing code.

GitHub isn’t my resume though. It’s one aspect of my resume. It’s something to consider yes, but the real value in a software developer isn’t the amount of code they write. It’s in the way they approach problems, present solutions and communicate with others. And I think I do that rather well.

… are willing to pay for your product or service. You’d be surprised just how many.

I’ve been working with Ruby on Rails full-time now for close to 4 years. Two years as a full-time employee and two years as a freelancer. In that time I’ve worked with and built all manner of Rails applications. Content management systems, business support applications, healthcare service portals and my own little product, DailyMuse. It’s still my choice of web framework for new projects, but I feel that lately I’ve become too settled with Rails. Yes it’s a fine framework to work with and who could argue. It has a thriving community that offers great support and ensures the ongoing development of the framework, but there’s more than one web framework out there.

In the last few months I’ve been trying out the Rust systems programming language. It’s been a hit and a miss getting my head round the syntax but largely I feel that I am wasting my time with it. Why? Well Rust is still fairly new and at the time of writing this it’s just about to emerge from its 1.0 beta phase. Despite the immeninent release of the stable version of the language, I still think I arrived at the Rust party too early. I’ve never been an early adopter of technology. I like to sit on the fence longer than normal before making any decisions about investing in a language or a framework. I might re-visit Rust in six months time or even a year to see how popular it is and whether it’s worth investing my time in. So, putting Rust to the side has left a space for me to look at another language or framework.

Looking at the market today, there’s such a variety in the demand for different languages and frameworks. I’ve done .NET in the past and while I think there’s going to be a steady demand for it in the future, I do want to try something completely new. A language I’ve never used before. Enter Python.

Okay, it’s not completely different to Ruby. It has duck typing and It’s dynamic but it is also an established programming language. If I was going to learn a new language then it was going to be something that I could use in my career. Getting a Python contract with no experience might be tricky, but I’m prepared to tart up my Github page with a couple of projects done in Python that could add weight to my cause.

Also, if I’m going to pick a language that gives me extra tools to use then I want something that sits alongside it just like Ruby on Rails sits alongside Ruby. I not only want to learn a new programming language but a new web framework that is made with that programming language. Enter Django.

In the past I’ve tried to learn different programming languages and failed spectacularly but this feels different. Rather than picking an new cutting edge technology, I’ve picked an established programming language and an established web framework to go with it. They’re not completely different from Ruby and Rails, but that’s the idea. I’m a web developer, therefore it makes sense to learn another web framework. This might be a low risk investment, but that’s okay. There’s enough developers chasing the bleeding edge technology. How many are chasing established technology?

I wrote this on Friday’s post:

Building and marketing products isn’t for me. I prefer to be neck deep in code rather than marketing tools.

I’ve been thinking about it a lot over the weekend.

The pursuit to build something that people will want to use and buy is what many people want. To take an idea, build it, and turn it into a successful product. Everytime I see an app (usually based on a simple idea) rocket to the top of the App Store charts I wonder, “Why didn’t I think of that?”.

The thing is though, this usually isn’t the first idea for that person. It might be their tenth or even twentieth attempt at making a successful product. Yes, it might be their first attempt, but I don’t think there’s ever been a single attempt at a product that’s went on to sell millions. There’s always been a few failed attempts before that one successful product happens.

Rather than continually change the idea of Journalong into something that works I simply let it trudge along based on it’s same initial idea. If I was really serious about making Journalong into something better I might have changed how it recorded entries, or changed it’s target market to a more focused group, or even open sourced it after the first three months of inactivity. It’s taken me a couple of years to finally admit defeat.

A continually pivoting product isn’t something I have a whole lot of time for. lame excuse you might say. I would disagree. The ongoing testing and validating of a product until it starts to gain the traction of paying clients isn’t what I want to do. I want to write software, but I also want to be paid for writing that software. I’m exploring a few options such as open sourcing a few ideas to see what happens, but for the moment I’ll be keeping the focus on writing code rather than building products.

Given I’m a couple of years from this milestone, it’s a worrying prospect to think that my chances of being hired will continue to decline.

The unfortunate truth is that unlike other forms of discrimination that are more arbitrary and capricious, age discrimination can often be a result of objective and sound business justifications. I’m not trying to justify it as an acceptable practice, but just trying to describe the pickle it puts the manager in trying to make a sound business decision without compromising the ethical and legal obligations of the company.

— Programmers: Before You Turn 40, Get a Plan B by John Fuex

I suppose though I’m already working towards a plan B with my freelancing career, but is that enough?

The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.

— Choose Boring Technology by Dan McKinley

I’m always keeping an eye on the future for the next “best thing” in programming, but to be honest I’m finding it hard to justify picking up a new language on the basis that it might take off. Rails is seen as old hat now but it’s also tried and tested and perfectly suitable for building web applications and services. Yeah it’s not on the edge anymore but then I know what to do when something goes wrong.

A project plan should be built in partnership with your client. When they buy into the project plan you then start a scope and build a proposal/scope off of it.

— Components of a Good Project Plan by Curtis McHale

Quality stuff from Curtis.

I’ve been working on a new idea for a service for the last few weeks and I’m just about ready to take the wraps off it. While the core functionality of the service is happily working, I’ve been thinking a lot about the pricing strategy for it.

Freemium

I considered giving a basic level of functionality away for free, but the problem I have with this is that it is difficult to work out just what to include when you give a service away for free. Too much and you end up with more customers sitting pretty on the free service, too little and it’s hard to get customers just to sign up. There’s also a little bit more work involved in separating the free functionality from the premium functionality in a service. You have to ensure that the free tier of customers can use the application at the same time as paid customers who will have added features available to them.

Paid

Given that I prefer this pricing strategy for the services that I use, I found it strange that I didn’t sway towards this from the start. When you make a product or a service, you want people to use it and the easiest way to do that is to provide part of it for free. It’s certainly not the best strategy for getting lots of sign ups, but it is the easiest.

I hesitated on using a paid strategy to begin with because I wanted people to experience the service first in it’s entirety before deciding to pay for it. The only way to do this then is to give people a free trial period of the application in it’s entirety. No locked or restricted features, just a window of time to try the whole application before they decide whether it’s for them or not.

I’m Going Paid

And that’s what I am sticking with. A paid strategy with just a 30 day window to try out the application for free before the customer has to decide whether to subscribe to the service or not. I think it’s definitely the best strategy. Committing to a paid service or product means that you are more accountable for the success of it and therefore you are more likely to want to make it succeed.

I’ve had positive feedback on this already, but the only way to truly see if the service will be a success is by releasing it to the world and that will hopefully happen in the next couple of weeks. Stay tuned!

It’s a question I’ve been asking myself as I switch between different Rails applications for different clients. In my early days of working with Rails, I had a preferred selection of gems that I liked to use and that I stuck with for many Rails applications. After a few upgrade issues on a couple of applications I started to pay more attention to how I build applications with Rails. I questioned the gems that I was using and my testing practices. As I’ve gained more experience I’ve started to see that working closely to the Rails framework when building applications has some benefits that I previously overlooked.

What you’re about to read isn’t a silver bullet approach to building Rails applications. This is simply a guide to what I’ve find works for me.

Application Architecture

In the past most applications I worked on followed the old favourite of “fat model, skinny controller”. Most applications tightly followed the MVC pattern and very few classes or objects were located outside of these three folders of the application. It does work, otherwise Rails wouldn’t be as popular as it is, but following the MVC pattern did present one problem. Models became huge wells of code as they tried to contain the bulk of the application’s code. Now I try to follow some best practices when coding but I don’t strictly adhere to them, but you have to admit that a model with a 1000+ lines of code could probably be trimmed down a bit.

Since reading and watching a number of different ways in organising your Rails application, I’ve started to see the argument for extracting business logic into individual classes. You might be thinking of service objects or Hexagonal Rails when I say this. It’s the same idea. I’ve started to keep classes that contain business logic in the app folder, alongside the rest of the application’s objects. The reason for this is that I see the business logic as being part of the application, not a seperate layer or component of the application. I’m using Rails for my application, so I want to keep the business logic close to the rest of the application.

Gem Dependencies

Gems sure are handy. Just add to the Gemfile, install and your application has access to new functionality when it needs it. While adding gems is the easy way to add functionality to your application, you then have a dependency on that gem to stay maintained.

Before you even begin adding the gem to your Gemfile, ask yourself if it is truly necessary for your application?

In the past I would happily add a gem that I thought I needed, but now I take a different stance on it. If a gem provides just a small bit of functionality to the application, I take the time to spike a similar or better solution for the application on my own. The reason for this is that sometimes a gem won’t do everything you need it too. If it can provide everything you need then great, but if it only provide most of your needs, could you add the complete functionality that you need by yourself?

Building this functionality on your own isn’t always the best way to go, but if your application has specific requirements, then I say it’s definitely worth looking at. Rolling your own solution to your application’s requirements means that your solution could be a better fit for your application than anything else that’s out there. It also means that with your own solution, you are responsible for keeping it maintained. Lastly, it keeps your Gemfile lean and the dependencies for your Rails application lean. I don’t suggest you do this for everything, just the gems that you might question over their suitability for your application.

Testing

In the past I was a keen advocate of Cucumber and RSpec. That has changed over the last year. I’m finding that the testing tools that Rails provides are more than adequate for new Rails projects and sometimes better suited for smaller Rails projects.

Out of the box Rails provides Minitest through Ruby to write your tests and fixtures to organise the data you want to test against. Minitest is flexible in that you can write tests or specs depending on your preference, so I don’t have any issues there. Minitest in a new Rails application is straightforward and it doesn’t require any changes to your application’s setup to get it working. Why even bother changing?

The real benefit I’ve seen though is in doing testing the Rails way is by using fixtures. They do require some initial effort to put together, but they’re always there for subsequent tests runs and soon you’ll start re-using fixtures for different tests and rarely have to touch them.

Rails is a database backed web application framework. Now I’ve seen the arguments for isolating the database from your tests, but for a framework that persists its data to the database, I think it’s overkill to start stubbing out calls to the database and canning data using factories. This is why I like using fixtures. It’s real data you’re working with. A complete working set of test data.

Finally, an argument against using fixtures in the past was that tests took too long to run. I have to say that this is not a concern now. I have worked on a number of Rails projects using Minitest and fixtures and while their test and assertion counts run into the hundreds, I’ve yet to see a test suite take longer than 30 seconds. And even if your test suite is on the large side, it shouldn’t be a major concern as you should have your tests automated to run as you edit your code by using something like Guard or Spork.

So What is The Rails Way?

Since I’ve made a few changes in how I build Rails applications, I’m definitely a more productive developer and I’m able to build new features with minimal fuss. The Rails way for me is working with the tools that Rails provides and building an application as close to the application’s own models, controllers and views as you can. Simple patterns and designs are available to reduce complexity but aren’t always necessary. I don’t suggest you immediately think about re-writing your whole application to fit around these three suggestions, but bear them in mind for any future Rails projects that you have.

Even before I started freelancing, I always got confused by the almost interchangeable career titles of freelancers and the jobs that were available to them. Contractor, consultant and freelancer. Are they specific to the type of work freelancers do?

When I started freelancing, I decided to market myself as a “Freelance Web Developer”. I had thought about the different titles I could use but I paid more attention to the technology field rather than the type of work I would be doing. I stuck with the title of freelancer as I simply thought it best described who I was. This was almost right, I wanted to freelance but what I wanted to start work on was contract work.

Starting Out As A Contractor

To begin with I was keen to look for roles where I could gain a bit more experience working as part of a remote development team. I wanted to work in remote teams to see how they continue to progress with projects. In the past I worked in teams that shared the same physical space and therefore communication with other team members was easy. How does this affect remote teams?

I also wanted to gain more experience in my preferred choice of technology stack. I had a number of roles working with Ruby on Rails, but I was definitely far from being an expert on the framework. A few gigs working in different teams would quickly identify areas where I might be short on knowledge. Thankfully this wasn’t a problem.

Armed with these two goals, I found out that contracting would be the best work for me. As a contractor I can market myself as a development resource to clients. They might be looking for that extra programmer needed to finish a project or they might need a developer with experience in a technology stack that they are lacking in. Whatever the reason, my primary role as a freelancer so far is as a contractor.

Long Term Focus As A Freelancer

I don’t want to be a contractor forever though. In time I would like to gradually move across to being more than just another “butt in a seat”.

Contracting is good because it means the decisions are largely removed from your hands. Your clients decide the work for you and you as the contractor fulfil your client’s needs. While this type of work does pay the bills and keeps my career going, I don’t believe that this should be my long term goal.

Doing the work is one thing, but advising the client in the way in which they can best achieve their aims is the work of the consultant. While I could market myself exclusively as a contractor, I would in fact like to be more than just another programmer in the team. I would like to be more of mix between contractor and consultant.

What’s The Next Step?

This is where I believe the term freelancer applies to the type of business I want to have. I love programming, and being able to work with a client’s team and help fill a gap is where I’m comfortable and productive. It shouldn’t be my only selling point though. To do this, I’m going to need a web site that focuses on business and freelancing and nothing more. It’s going to need material such as test cases and examples of work that back up my abilities as both a contractor and a consultant. I’ll see what I can come up with.

Last weekend our son came home with the school quarterly bulletin. As always we familiarised ourselves with everything that was coming up in the next few months, asked him what events he would like to go to and made sure there was nothing else that needed our attention. One last thing caught me wife’s eye though as she read through the bulletin. The school are looking for volunteers to help re-vamp their school website.

The next day I phoned the school to let them know I would be willing to help out. I got a call back a few minutes later with a date and time to speak to the assistant head teacher at the school who will be handling the website. All good so far.

The school’s website is okay as an information portal but it definitely falls short in terms of how it looks. Well, when the site says that the school kids contribute to the look and content of the site, you’re not exactly going to be expecting something that wins web design awards. Looking at other web sites in the area, and it’s clear that the school web site isn’t a primary concern for some schools. There is more an emphasis on getting the school children involved and that’s not a bad thing.

Today’s school children though are far different in terms of technology exposure than school children have been in the past. In the last ten years, mobile technology has become so engrained in day to day life that homes often have two or more mobile devices with kids often having their own tablet or even smartphone.

It got me wondering about the approach to take in getting the school children involved in the new school website. Is it better for them to know how to edit and update web pages by hand or will the kids be more interested in maintaining the school website through something like Wordpress?

I might be jumping the gun here a bit, but I’ve been keeping a list of questions like this to ask at my meeting with the school this week.

The main good thing to come out of this though is the chance to do something for an organisation in my local community. Yes, I’ll be doing the work for the school for free but with our oldest already a pupil there and our youngest due to start there in a few years, the chance to contribute something to their school can’t be a bad thing.

I’m always reading about other topics in software development. Over the last few years I’ve read about web design, JavaScript, Ruby, agile methodologies and practices, Go and even Objective-C. Reading books on these topics has provided some insight into their respective topics but with the exception of Ruby and agile methodologies I haven’t been able to take what I’ve read and use it in a practical exercise.

A couple of years ago I read about the Go language from Google. So I started reading a couple of books about it. Since then I haven’t written more than one hundred lines of code in Go. Was that time spent reading about Go a waste? I think so.

More recently the Rust language has peaked my interest but I haven’t started reading about it yet. I’ve been asking myself if there’s something I can work towards using Rust that will let me learn the language. Using Rust in a practical use hasn’t been something I’ve been able to come up with until a couple of days ago. There I was reading Hacker News over the weekend when I seen an article about writing a shell in C. Well, why not write it in Rust?

Building a shell in Rust should give me the chance to explore and learn the language but also give me the chance to try out something other than web development. I’ve been working with Ruby on Rails for over four years now and while I enjoy the work, I have been looking at a systems programming language to learn. We’ll see how it goes.

Marco Arment provides a detailed breakdown of his sales figures for 2014 for his app Overcast. More interesting though is the benefits he mentions to being self-employed.

I can work in my nice home office, drink my fussy coffee, take a nap after lunch if I want to, and be present for my family as my kid grows up. That’s my definition of success.
— Overcast’s 2014 sales numbers by Marco Arment

Couldn’t agree more.

I forgot to do this last year. It completely went out of my head.

Hardware

Not much has changed since I last wrote about this.

• MacBook Pro - I’m still using the same MacBook Pro I wrote about over a year ago. It has served me well in that time, but in hindsight I think I might have been better off with a MacBook Air. The retina is nice, but I do find the Pro rather bulky when I compare it to my Dad’s Air. With all the hype of a new 12” MacBook Air circulating about, I am keen to see what new products have in line for the MacBook range.
• Mighty Mouse - It’s a great mouse but one annoying thing about it is that it frequently disconnects itself and has to be re-connected. A minor annoyance.
• Logitech K811 - Last year I made the switch to the Logitech K811 keyboard. With a Mac Mini on the desk for the family and my MBP for work, switching between these two using the keyboard is simple.
• Dell UltraSharp U2414H Monitor - Treated myself to a new Dell monitor at the end of last year. The thing I love about is the thin bevel around the edge and the screen is crisp and clear. Also it’s adjustable in terms of height and angle. If I just had a bit more room on my desk, I would definitely stretch to having two of these sitting side by side.
• External Hard Drive - I’m still using a Seagate external drive for Time Machine backups but I am considering a bigger external NAS for this.

Hardware nice to haves

As I mentioned above, the only change I would make at the moment is to replace my Pro with an Air, but with so many rumours flying around about changes to the MacBook line up, I prepared to wait a few months to see what emerges. Other than that, all my hardware is reliable and working well.

Software

This is the software that I use every day. These are the essential applications I need to work. If I had nothing else in terms of software, then these applications would be all I would need.

• Mail - I still haven’t found the need to switch to anything else. It handles all my email needs and it’s baked into OSX as well.
• Firefox - No complaints with Firefox and probably now the longest I have went without switching browsers. For a while it was almost a yearly thing. Chrome to Firefox to Safari to Chrome … you get the idea. The tab groups is a particularly nice feature as I frequently have different tabs open for different clients and projects.
• Todoist - Another type of tool that I used to do a lot of switching on. I must have tried over 20 different task apps in my time, but Todoist is the one I’m most comfortable with and it’s baked into my workflow now. Can’t recommend this product enough, especially their premium subscription.
• iTerm2 - Still my preferred terminal emulator although I no longer use the pane splitting feature of it and defer to tmux for managing my panes.
• Vim - I did it, I finally made the jump to Vim and I have stuck with it. Despite a few minor annoyances that could be fixed in the config, I am definitely more productive as a programmer in Vim.
• Dropbox - I re-assessed Dropbox my need for Dropbox a while back wondering if iCloud might better suit me, but having my a seperate service handle syncing my essential files made more sense than relying on iCloud.
• Facetime - Facetime, in particular the audio only calls, has become my main way of chatting to clients. I only defer to Skype now when I need to have a group conversation.
• HipChat - It’s probably not a good thing to be able to have clients get in touch with you at any moment of the day, but HipChat has become valuable as a portal where I can check-in with clients during the day. Also most of my work is done on Heroku, and I have a number of deployment hooks in place that feed back to client’s rooms on HipChat. This way they get to see when code is deployed and ready to be tested as well as seeing notifications from commits I’m making on Github and Bitbucket.
• 1Password - Probably my most valuable piece of software. Secure, easy to use and does make handling your passwords a lot easier. Also found their iOS app to be useful as well.

While I do use the following software every day, these are more like nice to haves rather than essential. Still, they make me more productive every day, so I’m glad I have them.

• Alfred - Despite Apple’s changes to Spotlight in Mavericks I’m still sticking with Alfred as my preferred application launcher.
• Fantastical - Scheduling and calender management made easy. I also use this on my iPhone as well.
• RSS Notifier - I still use this as a mini RSS reader for service updates from the likes of Dropbox, Cloud66, Heroku, Linode and other tech services.
• Divvy - Great little application for managing your windows. Shortcut keys for common layout patterns have been commited to memory for a long time so it makes setting up different apps on my screen easy to do.
• CleanMyMac 2 - Broom was great for identifying huge files and folders on my MBP but this goes one further and routinely cleans out junk and reclaims a great amount of wasted space. Usually run once a month now just to keep my MBP in good shape.

The Web

A web developer’s playground. Just a small selection of the many services and products that I use online.

• DuckDuckGo - Still my preferred search engine and I’m also finding that I use the Google bang operator a lot less.
• Github - My preferred source code management tool for client work only.
• Bitbucket - A solid source code management tool for my private repos. It’s a shame that so many people are automatically are drawn to Github. Bitbucket works well, but it does lack a number of features that Github has.
• Heroku - I mostly work with Heroku when I am working with clients. I no longer use it for my own projects and products though.
• Linode (Referral link) - This blogs runs on a small Linode server. Yes it is costing me money each month, but Heroku’s scale of pricing from one dyno to two dynos is simply too expensive.
• Cloud 66 - Despite many attempts at getting a bare server up and running with all the software I would need for a Rails application, I always found the maintenance and deployment of servers too much of a pain. Cloud 66 have an interesting solution in that they analyse your application and configure a server of your choice with all the correct components you need. Deployments can be done from the command line or the Cloud 66 website. So far I have two production applications running on Cloud 66. I’m happy with the setup so far.
• LinkedIn - Jury is still out on it’s usefulness. I get the odd request now and again, but most leads have come directly from email.
• FreeAgent (Referral link) - Still the best invoicing and time tracking solution for people like myself. Works flawlessly and the FreeAgent team do a great job of keeping you notified with tips and suggestions through their Monday Motivator email.
• Instapaper - Still the best ‘read it later’ service there is. Left it for a few months but quickly returned after realising how great it is.
• Feedbin - My preferred RSS reader and still delivering new features. I am pleased to say that Feedbin is still going strong.
• Gauges - I haven’t reviewed this recently but I’ll probably still stick with it. Which reminds me, I have another service in the pipeline that could be using this.

Backups

I haven’t had any major backup disasters in the last year, but that doesn’t mean I can stop backing up my data.

• Time Machine - I had a minor run in with Time Machine a while back trying to get some files from a folder that had synced to iCloud. I stick with it for the moment but I’m wondering if I should look at alternatives.
• Backblaze - I started using this at the recommendation of Curtis McHale. Good to know that if the worst happens I can get a copy of my data sent to my home asap.

So that’s the tools round up for this year. I might do a progress report in the summer with any changes that happened since then. Glad to see that small paid services such as Instapaper and Feedbin are still going strong. Also good to see that I’m not constantly switching tools like I have done in the past. I seem to be reaching a state of ‘tools zen’ where I know what works for me and what doesn’t.

Skipping the TDD cycle isn’t always a bad thing to do. After all, sometimes you just want to write code.

Over the holidays I had some free time. An idea has been in my head for most of the year, but I never got round to scheduling anytime to work on it. I decided now was the chance to throw something together to see if this idea was worth exploring. To change things up a bit I decided to not follow my usual practice of TDD. Some might call that laziness and that might have been a minor factor, after all it was the holidays and this was just me trying something out, but the major factor in skipping TDD was that I had the knowledge to build the application quickly. Over the course of a couple of days I put together the first attempt at implementing this idea.

Aside from a couple of typos and minor bugs, the application is working fine and doing its job. The bugs were just oversights made by myself during those two days and they were easy to fix once found. I’m not surprised by the this as it is a simple application comprising of some basic CRUD operations and a single Rake task. Once everything was looking good, I deployed the application so that I could see it running for a few days. After a week it was clear that all was in working order. I’ve shared the idea with a couple of people who have so far been positive about it.

Now being a good developer I mostly write tests before I write code. It’s the TDD way. This time though I skipped the tests in favour of getting something basic up and running. I had the knowledge and I ran with it. It was supposed to be just a prototype after all.

In the past I’ve stuck with using TDD when building even the smallest of products. At that point in my career however I was a less experienced developer. I was still figuring things out. The tests made sure that everything was working as I stumbled through different parts of the product. Now though, I have the knowledge and confidence to throw small web applications together without writing tests to in order to explore simple ideas for web applications.

Is it still a prototype then now that it has been shipped and is being used daily? Yes and no. The line between prototype and product is definitely blurred here. I would have to say that until the code itself was backed by a test suite, it’s still just a prototype, an idea. So why not trash the code I have at the moment and start again from scratch using TDD?

I could, but I already know what code I need to write. Do I really want to scrap the whole thing knowing that I’m just going to write similar code again? In an ideal world I would probably do this but I knew it would be a while before I got free time like this again. The next obvious step then would be to add tests to the prototype and gradually refactor this code into something more stable. Something ready for the masses.

TDD is still a great practice to follow when writing software, but I think there’s a time and a place for it. When writing software as part of your job, for a client, or as a contribution to an open source project, then yes, TDD should be used in these cases, especially if they are expected of you. However, when you are exploring code, ideas and simply playing around then I think it’s down to yourself to decide. And if you decided not to TDD, don’t sweat it.

TDD might be advantageous when learning a new language or framework but when you have the knowledge to build something quickly then why not. If it’s worth pursuing further then start writing tests for the code that you have before things start to get more complicated.

I’ve been thinking for a couple of week now about learning Rust, but something that’s been bugging me has been what to build with it. Rather than focusing on what to build first, I should really be focusing on learning Rust first.

This sketchbook of implemented ideas isn’t a paper book, but a collection of small programs. It could be as simple as a folder full of Python scripts or Erlang modules. It’s not about being right or wrong; many ideas won’t work out, and you’ll learn from them. It’s about exploring your interests on a smaller scale. It’s about playing with code. It’s about having fun. And you might just become an expert in the process.

— A Developer’s Sketchbook for the Twenty-First Century by James Hague

I haven’t been reading the Dr Dobb’s site for a while but back in my days as a .NET developer, it was a regular place to visit. Still, it’s a shame to see there won’t be any new content after the end of the year.

No amount of analysis and explanation can mask the deep, personal sadness I feel at writing about this decision. Like many of you, I grew up reading Dr. Dobb’s. For me, as I suspect it was for many of you, Dr. Dobb’s Journal was the lifeline to a thorough understanding of programming. I recall that when the magazine appeared in my mailbox, all other activity for the day came to a sudden stop and the remaining hours were spent blissfully poring over article after article, soaking in the information. I learned C from Allen Holub’s C Chest column, operating systems from the 18-part series on 386BSD, video programming from Michael Abrash’s Black Book, and data compression from Mark Nelson. And so on — each month brought new, enabling insights and explanations of often arcane topics.

— Farewell, Dr. Dobb’s by Dr Dobb’s

In the last few weeks I’ve been working on a Rails 3 application for a client. The test suite doesn’t cover the whole application, so along with features being added for the client, I’ve been gradually expanding the test suite to cover the entire application.

The test suite itself uses Minitest and the test syntax. So far I’ve had an enjoyable experience in adding tests for each part of the application. This week though I faced an issue of duplication in my tests. The application includes a number of mailers. Each mailer has an erb and plain text template. In my first pass at testing this mailer I had some duplication going on with the different templates for each mailer.

assert_match(/Hi there #{person.first_name}/, mail.text_part.to_s)
assert_match(/Hi there #{person.first_name}/, mail.html_part.to_s)

This is just one of many lines in the tests that assert that the two mailer types include the right content. Wouldn’t it be nice to wrap these two assertions into one?

Minitest allows you to define your own assertions but up until this time I made do with Minitest and Rails’ own assertions. Turns out that adding your own assertions to Minitest is easily done. I included the following assertion in my test_helper file but you can include your own assertions in a seperate file if you want to and then include that in your test_helper file using require.

module Minitest::Assertions
  def assert_mail_match(expected, actual)
    ["text","html"].each do |mail_part|
      assert_match(expected, actual.send("#{mail_part}_part").to_s)
    end
  end
end

What we’re doing is adding a wrapper around Mintest’s assert_match method and pass in our expected value and the actual value. The method will iterate over the two mail parts in the mailer and assert that each format has the correct corresponding content.

We can now call the new assertion in our tests:

assert_mail_match(/Hi there #{person.first_name}/, mail)

Wrapping these two assertions into one makes sense. The template formats for the mailers is unlikely to change and the two different formats have the same content albeit with different formatting.

After a couple of years of using RSpec, Minitest has been a nice change to how I test the Rails applications I’m working on. Its syntax and single way of doing things means that I find it easier to write tests. Hopefully, I’ll be able to share more insights into using Minitest in the future.

Curtis McHale talks about his change from solo freelancer to business owner and why it’s necessary.

As their leader, it’s now your job to make sure your team members do their jobs well. Coders stay up-to-date on code and technology. Designers continue to hone their skills. And you’re responsible for knowing enough about your entire organization that you can have good conversations with your clients without sounding like an idiot. This is how you earn trust and credibility.

— Evolving into a Business Owner by Curtis McHale

I’m still comfortable with my solo freelance career, but I do know that in the future that next natural step is to lead.

When it comes to working with clients, there’s a shared responsibility to ensure that both parties are using the right tools to work together.

For the last few weeks I’ve become increasingly uncomfortable in how I work with a client. In the past we’ve used a particular collaboration tool to manage projects and communicate through, but in the last few weeks this tool has been abandoned in favour for development requests through a chat room. At first it was minor requests like tweaks to the UI and changes to the messages that were displayed to the user when a form was incorrect. Steadily though it’s increased to bigger changes and feature requests. Instant Messaging Driven Development if you wanted to put a label on it.

After explaining an issue in the code with the client I took the chance to talk to them about the increasing use of the chat room for requests rather than the collaboration tool that we originally used. I explained my worries about the trend towards this and the drawbacks that the client will inherit as a result of the continued use of the chat room for sending requests for software changes.

The issue was heard loud and clear from the client and for the next hour of the call we discussed plans to move back to the collaboration tool as well as guidelines for using the tool and what we can do to reinforce its place as the go to point for projects. It was a successful discussion.

When you and your client agree on a particular tool to use for collaborating on projects, then it is important that you stick to this. These tools are initially picked for a reason and that’s because both you and the client are happy to use the tool and it will serve both your needs. When either side of this arrangement doesn’t use the tool then that’s where things can go wrong.

Collaboration tools such as Trello, Basecamp and other tools are there to ease the burden of remote parties working together. Parties can share information, assign tasks, check overall progress and much more. Other tools for communicating like IM, phone, text and email are best at communicating but they’re a bad choice as collaboration tools.

Who’s to blame? Well, in this case both myself and the client. On one hand the client should be adhereing to the agreement of using the collaboration tool. On the other hand, I could have mentioned this to the client sooner rather than let it continue for the few weeks that it did. I admit I was hesistant about bringing this issue to the client, but they were understanding about my concerns and promised to start using the collaboration tool again.

The next time a client deviates from the collaboration tool we’ve chosen, I’ll politely remind them of our preferred place for such things. And yes, I would expect them to do the same to me.

Despite my efforts to simplify my tools, there are some that I just need to keep using. They’re just too important.

Yesterday I wrote about simplifying the tools I use in an effort to minimize the amount of data that I push around. I was all of sudden concious of having data spread across different services and the number of tools I was using to do this. Some things though require specialist software, like your accounting and invoicing aspect of your business. You can’t simplify book-keeping and accounting without it having an impact on your business and career. Which is why the business critical software is the exception to simplifying the data and tools I use.

For a number of years I worked as an ERP developer for a company that provided development and consultancy services on a Microsoft ERP solution for small to medium size businesses. This one solution could meet most of the software requirements for your business. It has modules for accounting, inventory, customers, invoicing, purchasing and much more. That all encompassing ability run multiple aspects of a single business came at a cost though. It is a fairly complicated solution to run and maintain correctly. When used correctly though it becomes a critical part of the business.

My needs aren’t so great that I need a solution like this, but I still need software to help me run my business. I require help with invoicing, accounting, time-tracking and expenses. Tracking all of these on my own just wouldn’t make any sense. I have customers to invoice, projects to track, taxes to pay and more. I could do this on my own with a number of spreadsheets, an address book and some software cobbled together by myself, but that would require time to implement and it’s not a valuable use of my time.

I use FreeAgent for all the requirements I just mentioned. It works, it’s affordable and it doesn’t require a steep learning curve to use. It does require some time to find out how to use effectively as a business tool, but that’s why it’s so great. I can use the parts of FreeAgent that I need to begin with and then gradually start looking into other features it offers to help me run my business. It then becomes a business critical tool. I need it to run my business. It’s not complicated to use, but then it’s not also so simple that I can switch over to something else if I wanted too.

Business critical tools are the exception to the rule when it came to cutting back on the tools I use. The trade off between using something simpler would have a negative impact on my time. I would end up spending more time managing my business data than I would delivering value to clients. It’s not wise to cut corners when it comes to business critical tools.

Continuing my series on reading Redmine, we’ll take a look at commenting.

Next to tool choice, comments is another topic that can cause heated debates amongst developers. As a rule, I rarely comment my own code. I just don’t see the need to comment it. I try to be as expressive as possible in the code I write and although it usually is more verbose than other developers who I have worked beside, I know that by expressing my code, it becomes easier to read and understand.

Having worked on a number of different code bases for clients I’ve started to look at commenting in a different light. In the past I would rarely comment but now that I am working on code bases for different clients, it can be advantageous to comment your code. When I started reading the Redmine code I noticed a similar use of comments in the Redmine code to what I had in mind for commenting on my client’s code. Here’s what I found out.

Open Source License Everywhere

Having not worked on any major open source applications (yes I should rectify this), I was surprised to see the open source license located on each file within the Redmine source. Yes, within each file. Every model, controller, helper and almost all Ruby source files that I could see included a copy of the GNU General Public License (version 2).

My only critique against this is that if the license was to change then it could be something of a task to update the license on each file within the application, however in order to ensure that the license for Redmine is fully understood, then it does make sense to include the license in each source file.

The reason I have included this is that I do view the license as a sort of comment. It’s not code but it’s also not expressing the intent of the code in the typical way that a comment does. It does describe how the source code can be used so could be viewed as a comment.

Comments on Controller Methods

One thing that stood out from the source code was the use of comments on controller methods. This makes senses in the cases I seen, as some controller methods didn’t follow the traditional RESTful verbs and some required an explanation of the intent of the method. It was good to see that a single or double line comment was frequently used to explain the controller’s intent.

# Loads the default configuration</h1>
# (roles, trackers, statuses, workflow, enumerations)
def default_configuration
  # ...
end

This is good from a documentation point of view as it means that other developers working on the same method will immediately see what this method does. Most controller methods were fairly straight forward to read but there were a number that required just a single line to explain the method further.

Comments on Model Methods

Putting aside the argument of where the business logic in a Rails application should reside, let’s just assume that in Redmine’s case it is in the correct place, mostly within the ActiveRecord models. I say most as there is also a fair degree of code spread out into controller, helpers and in the lib folder too.

So if most of the business logic for Redmine resides within the ActiveRecord classes then where’s the documentation for each method? It was something I found unusual given that the controllers were documented well. From scanning the models it was clear that only about half the model methods were commented. It should be mentioned that there were a number of methods that didn’t require comments, but then there were a few places where a comment might have been advantageous.

To Comment or Not?

The Redmine source itself is a typical Rails applications without any architectural surprises. It shouldn’t surprise most developers familiar with Rails that it is indeed straight-forward to follow. Given my history with commenting in Rails applications, I was surprised to see such a wide use of commenting within Redmine but without using RDoc.

It has given me food for thought on commenting on the Rails applications that I working on at the moment including my own. I’ve always just viewed my code as code the I alone will read but that may not be the case. If someone else was to read it, what would they think? That’s an exercise for another day, but this look at commenting with Redmine has shown some good examples of where commenting can be an advantage.

In an effort to brush up my development skills I’ve been reading the Redmine source code this week. I’ve been curious to find out about examples of Rails applications that use Minitest.

Ever since I suggested a move away from RSpec for projects with my clients, I’ve been curious about real world examples of using Test::Unit/Minitest to test a Rails application. It was clear from a search of Rails applications on Github that RSpec was the preferred choice for many applications. However, after reading an email newsletter from developer Eric Davis, the RedMine project sprung to mind so I decided to check it out. Sure enough, it was the sort of application I was looking for. A mature code base using Minitest as the test framework. A few interesting points stood out which I’ll cover over the next few weeks, but for today I’ll talk about Redmine’s multiple assertions per test.

I was always led to believe that tests ahould only contain one assertion per test. It was ingrained into me from reading countless books on TDD and hundreds of blog posts on the topic. The thing is I never questioned why this was so. It was clear from seeing the RSpec syntax why it was a benefit.

before do
  get :index
end

it "must respond with a success code" do
  assert_response :success
end

it "must render the index view" do
  assert_template :index
end

it "must assign the users journal" do
  assert_not_nil assigns(:journal)
end

If your test (or ‘spec’ in this case) has one assertion and it fails then you know exactly what went wrong. Multiple assertions in a single test have always been frowned upon.

When I started using MiniTest as the test framework for a couple of Rails applications of my own, I started to write multiple asserts per test.

def test_index
  get :index

  assert_response :success
  assert_template 'index'
  assert_not_nil assigns(:journal)
end

It was discomforting to do but only from the view point that I had believed for so long that multiple assertions per test was wrong. However when I read the Redmine source code I was pleased to see that not only was the application not using the RSpec, it was also using multiple assertions in a single test. After an hour of reading through other tests in the code base I could see why it was done. The layout of the tests in Redmine are flat. Often there’s just a single setup and teardown method and a list of tests. It makes it much easier to read.

RSpec has a number of advantages in that tests can be nested in different contexts and within each context you can define a before block to setup anything needed for the tests that follow. This can result in heavily indented code and with the practice of one assertion per test it can lead to a lot of tests relying on a number of different setup methods higher up in the test file. This can be difficult to read if a test file has a number of contexts within it.

It’s re-assuring to see that while many developers might point out the benefits or reasons why we do one assertion per test, it’s not a rule that is set in stone. You can include more than one assertion in a test, as long as it’s a reasonable number of assertions.

Is it worth writing seperate tests for each of these or is it better to simply bundle them into a single test?

I’ll leave that for you to decide. There’s no right or wrong answer in my eyes. If I was still using RSpec I probably would still write one assertion per test out of habit, but having a flat layout using Minitest does make it easier to read and having multiple assertions isn’t going to make it any harder for me to test my code and debug any problems.

In this post I’m going to try and briefly describe how I built the popular content section working on my Octopress blog using data from Gauges.

I’m using Gauges as the traffic and analytics service for my blog. I have done for over a year now. It’s simple and very easy to use which is why I like it so much. One of the great things about it though is that it also provides an API for people who want to do more with the data that they have accumulated. One feature I wanted to include on my blog has been a link to what most people have been reading in the last few days. I thought that this would be extremely easy to add given that Gauges already has all the data that I need for it.

The Leaderboard

What we essentially want to build is a leaderboard comprising of the most popular articles sorted by the number of page views they have with the most popular article at the top. With this analogy in mind I just needed to populate the leaderboard with page titles, URLs and views for popular articles from my Gauges data.

In adding this feature to my Octopress blog, I started thinking about how I would interact with this feature. That was easy. A Rake task. Adding this as a Rake task means that I can add this to another Rake task that could pull in the popular content during the generate stage. For now though I run it as a separate Rake task on its own as I might generate the site a couple of times before publishing it.

Here’s how I envisioned this popular content section to run:

PopularContent.top_content(3)

So, all we’re doing here is passing in the number of days that we want to look back on but there’s a number of things that need to happen here:

1. We need to connect to the Gauges API.
2. We need to ask for the content stats we need.
3. We need to calculate the most popular article over the time period that we pass in.
4. We need to return the most popular article as an object with a title and a URL.

Get Connected

When we initialise this object we need to do two things:

1. Connect to the Gauges API
2. Create our leaderboard

This is done quite easily. When we initialise the TopContent class we pass in our Gauges ID and API key so that we can connect to our own data. In order to make this process even easier, we’re going to use the Gauges gem rather than working directly with the Gauges API.

Once this is done we create a blank array that will serve as our leaderboard for compiling the top viewed articles over the last few days.

def initialize(gauges_id, api_key, days = 3)
  @gauges_id = gauges_id
  @api_key = api_key
  @client = Gauges.new(token: api_key)
  @leaderboard = []
end

Building the Leaderboard

Gauges doesn’t group popular content data. Instead it serves the data you need on a date basis. So we need to ask for each date that falls in the date range we specified:

def build_popular_posts(days)
  end_date = Date.today
  start_date = end_date - days

  while start_date <= end_date do
    content = @client.content(@gauges_id, date: start_date)
    content["content"].each { |c| update_leaderboard(c["title"], c["views"], c["url"]) if valid_content_page?(c) }
    start_date  = 1
  end

  @leaderboard = @leaderboard.sort! { |x,y| y[:views] <=> x[:views] }
end

There’s a lot going on here, so let’s take it one step at a time. First of all we initialize some variables for our start and end date using the number of days variable that pass in.

end_date = Date.today
start_date = end_date - days

Next, we iterate over these dates beginning with the start date.

while start_date <= end_date do
  # ...
end

For each date we’re going to pull the data we need from Gauges. This is a list of top content for the date we are on.

content = @client.content(@gauges_id, date: start_date)

Next we update our leaderboard by iterating over the content that has been viewed for the current date.

content["content"].each { |c| update_leaderboard(c["title"], c["views"], c["url"]) if valid_content_page?(c) }

This is the point where we start accumulating page views for each page. The update_leaderboard method takes the page title, URL and number of views and uses them to create or update an existing entry on the leaderboard.

def update_leaderboard(title, views, url)
  position = @leaderboard.index { |a| a[:title] == title }
  if position
    @leaderboard[position][:views]  = views
  else
    @leaderboard << { title: title, views: views, url: url }
  end
end

Finally we sort the leaderboard according with the highest number of page views at the top.

@leaderboard = @leaderboard.sort! { |x,y| y[:views] <=> x[:views] }

Display the Results

Once this is done, it’s a simple matter of writing the popular content to a config file using the Rake task so that we can use it in the generating of our Octopress blog. Accessing these from an html file is straight forward enough if you’re familiar with working with Octopress layouts. I have the following code located in my post layout just after the post section:

<div class="related">
  <h2>Popular Posts</h2>
  <ul class="related-posts">
    <li>
      <h3><a href="{{ site.popular_post_first_url }}">{{ site.popular_post_first_title }}</a></h3>
    </li>
    <li>
      <h3><a href="{{ site.popular_post_second_url }}">{{ site.popular_post_second_title }}</a></h3>
    </li>
    <li>
      <h3><a href="{{ site.popular_post_third_url }}">{{ site.popular_post_third_title }}</a></h3>
    </li>
  </ul>
</div>

That’s it really.

If you look at the code, you’ll see a few other methods that are used to filter out data. I intentionally filter out the home page views and other pages that I don’t want to include in the list. This is done just by checking page titles or paths.

I’ve been running this code on my blog for quite a while now. Previously it only returned a single page URL and title, but I wanted to include a list of posts so I added methods to pull the second and third most popular posts.

The code itself is quite straight forward to read and follow. It might not use all the latest Ruby idioms and tricks that many Ruby developers know and love but for me it’s straight forward code that works.

The fully listed code to accompany this post can be found on Github.

There’s a time and a place for client work. Rushing out the door on a Saturday morning isn’t one of them.

Over the weekend I made mistake in some code I had changed for a client. After pushing the quick change to Github and then to the test environment for the client, I then realised the mistake I had made. With no time to correct the change, I decided to leave it until Monday morning. After seeing my mistake in all it’s glory this morning, I admitted my mistake to my client and then proceeded to fix the code correctly.

There’s no excuse for the mistake that I made but making the change on a Saturday morning when I was due to leave the house probably wasn’t the best time to do it. Also I didn’t read the message fully from my client that prompted the change. In my haste I missed the last sentence which would have changed the way I updated the code. A hard lesson learned.

Freelancing is definitely a learning experience and with each mistake you make you see the correct process you should be following. In this case it’s client work. It should be reserved exclusively for your typical working day. In my case it’s during the week at my normal office hours and only when I have at least 30 minutes to carry out the work and review it accordingly. The only exception should be for emergencies and when carrying out that work it should receive your complete focus.

It can be tempting to be the ever accommodating freelancer and provide help on your client’s every request and wish, but going down that path will only degrade the quality of your work. Your clients will come to expect fully working changes when they demand them regardless of the hour of the day. Responding in this way isn’t in the best interests for you or your client. Instead, defer fixes for client work for first thing the next morning or even before your main day begins if you have the time.

There’s a time and a place for client work. It’s during the agreed times that you already have with your client. Keep it that way to ensure your clients get the complete attention and focus they paid you for.

Big decisions are often fraught with risk. Sometimes though the only way to make the right decision though is to test the options first.

For the last few months I’ve been working on a CMS application for a client that has been steadily growing in size. We both agree that there will come a time where we will need to make some decisions about the design of the application so that it remains easy enough to maintain and develop but also scales up with the client’s expected growth for the next few years.

It’s something we’ve both been putting off for some time now, but with more projects and clients appearing in the client’s pipeline, we’ve decided that now is the right time to start making these decisions.

The problem has always been though that if we make the wrong decision we end up too far down a path that we don’t want to be. Backtracking might not be an option and working towards a different solution is something that we don’t want to end up doing either.

The answer to this dilemma has been surprising simple. For each technical decision we have to make, we have a number of options that we can consider. Rather than analysing and committing to the most attractive option (in theory anyway), we have decided to take a day and implement that option in a single day to see where we get to. If by the end of the day, we’re still happy that we’ve made the right decision, then we continue on with this option. If we’re starting to have doubts, we abandon the option and try something else.

Software developers will recognise this concept as a spike. This is the idea that you carry out enough work to recognise the risks and knowledge that are associated with change in design or functionality. The spike gives the developer the chance to find out the risk and complexity involved in such a change. With the information, developers can provide better estimates for these changes or completely rule out a change.

The spike is a great way to ensure that you limit risk from a decision without committing to that decision. It will involve some time to determine if the option you are spiking is worth pursuing, there’s no getting around it. However it is better to invest some time in pursuing the right decision rather than blindly committing to the wrong decision is it not?

Love American Football? Love writing code?

Here’s a quick run down of American Football related terms in the context of software development.

I watched DHH’s keynote from RailsConf 2014 and it re-iterated a few things for me but what stood out was the similarities between writers and programmers.

There’s been a lot of talk in the Rails community about architectures, design patterns and testing recently. DHH touched on this in his keynote but one thing I wanted to mention here was the idea of drafts.

When it comes to writing code, your first attempt is never your last. Unless you have all the knowledge and time under the sun to get it right first time, there’s always going to be scope to improve that code you just wrote.

I tell my clients when I think that a section of code could be improved by re-writing it. I’ll pick the smaller sections of code to re-write as they offer the greater awards for the smallest investment in time. This suits my clients as they usually want features over improved code, but if I can improve the code base in anyway, then I’ll aim for those bits of code that can be improved with just a small amount of time.

The same goes for writing. Your first draft is never your final piece. It might just flow from your pen but reading it back it might not sound as good as you first thought. Unfortunately re-writing my blog posts is something that I don’t usually do. I’m just so busy at the moment that the most I can do is a first draft, a read through to correct mistakes, a quick couple of improvements and then publish it. It’s hardly the process that I should be working towards.

Rather than worrying about the re-writing of these blog posts though, I’m looking at larger bits of writing that I have done. I have a first draft of my grass roots productivity series that I have compiled together for an e-book. I should make some time to go through this and re-write it. It’s been a while since I looked at it and perhaps the unfamiliarity of it might reveal the places where I could improve it.

I know now though that regardless of whether it’s source code for an application or words for a book, the first draft should never be your final attempt. Maybe there is more in common between writers and programmers than I first thought.

Continuing with the book, Book Yourself Solid, I’ve identified what my ideal client is, but what’s my target market?

18 months ago if you asked me who my target market is then I would have to answer, “I haven’t a clue”. Fast forward to today and the answer is still pretty much the same. The reason for this is that I have two types of clients. My major clients are clients I work with in what I see as my target market, the healthcare sector, they’re organisations and businesses that require deliver software for the NHS, GP’s and other healthcare organisations in the UK. The minor clients are clients I do work for on a rare occasion. I might have provided a website or application for them and they never require much work to either fix or upgrade what they have. They usually require a single week’s work every six months or so.

I’ll be honest, I still don’t know for definite what my target market should be. I’m still getting a feel for the kind of work I want to do and whether there’s a long term future for me in that market. Ideally I would like to do consulting work for healthcare software providers or even straight to the healthcare businesses themselves, providing myself as a development consultant and resource, but I don’t want to do this forever. There’s two options I see ahead.

The first is looking into another target market. I have a few in mind but nothing concrete. The reason I am exploring other options is that while I have firm background in healthcare I also have some experience in other sectors. One area of work I did that was interesting was risk management solutions. I certainly wouldn’t be adverse to working in this market again.

The second is building a revenue stream from a number of products that will provide a steady income over the next few years. It has to be years as anything short lived like a book or a screencast is only going to generate so much revenue over a short time frame. If I went down this road I would need to continue releasing books or screencasts every six months and I’m not sure that this plan is for me. Something more long term like a software product or service would definitely be something worth looking at however, getting the right product is a challenge to begin with.

I know what my target market should be and maybe that’s enough for me to be going on with for the next few years. There’s no rules to say I have to stay with that market. If it doesn’t work out then I can always change.