Matthew Lang

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

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

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

1. The True Agile Approach

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

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

2. The Solo Developer Approach

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

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

I'm still on the fence about this.

3. The Side Project Approach

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

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

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

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

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

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

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

Opening Projects

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

>> subl --project deathstar.sublime-project

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

>> sds

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

There are three sections to the project file:

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

Using Folders

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

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

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

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

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

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

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

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

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

Excluding files can be done like this:

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

And excluding folders can be done like this:

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

Switching Projects

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

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

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

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

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

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

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

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

Big title

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

Markdown based notes

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

Bookmarks from the same site

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

Bookmarks with the same tags

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

Nearby bookmarks

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

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

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

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

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

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

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

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

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

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

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

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

This has to be the goal of the season.

via kotte.org

... from Patrick Rhone.

via FGGT

A couple of days ago I wrote about what I perceived as a problem on App.net. Finding actual interesting people on App.net through recommendations. Over the next couple of days my timeline on App.net has exploded with people talking about this topic.

I was concerned about finding interesting people in App.net given that there appears to be a high number of bot and feed accounts recommended to you in the Recommended Friends section of the App.net Passport and on Alpha. I just want to find interesting people, not bots or feed accounts.

Having had a conversation with App.net's founder, Dalton Caldwell (@dalton), over the course of Tuesday and Wednesday on App.net, it is clear that this isn't so much a problem with App.net but a problem with all social networks.

I checked out the "People You May Know" block on my LinkedIn page. Initially it only showed me three people, but none of the people in that list were people I knew, worked with or even worked in the same company as them. It was only until I expanded the results further that I started to see people that I had recognised or work with previously. However, the results still showed that the majority of people there weren't people that I actually knew.

I remember the same widget also displayed on Twitter when I had an account there. Quite often, you could see that the people that Twitter recommended to you was based on your bio, your tweets and probably other information that Twitter graph internally. It wasn't completely accurate and often you wonder get a recommendation to which you would respond, why? Why is that person being recommended to me?

It's quite simple. Machines are not good at making relational decisions. My new friend on App.net, @novia, pretty much summed it up for me.

@matthewlang long ago my answer to a question about why computers can’t figure out simple things like this: computers suck at relational reasoning: Even if we create contextual awareness, it would take years of training & they’ll still make errors.
— App.net by @noviad https://alpha.app.net/noivad/post/12500139 App.net %}

So if machines suck at recommending other people for you to follow on any social network based on your own preferences, then how do you find the type of people that you want to follow?

The answer is simple.

Engage, take part, chat, converse, interact.

Be part of the social network rather than just a bystander.

Looking back at my Twitter days it took me a good couple of years to get my list of friends down to a list of mixed interests that suited me. Based on tweets, interests and location, I managed to get a nice timeline of like minded, interesting people to follow. I did this by tweeting to people, searching for hashtags in profiles and finding users or lived in my part of the world.

The same can be said for App.net, but there's a bonus with App.net. Conversations are indeed richer there, and that's where you find interesting people. By taking part. By contributing your ideas, opinions and thoughts to conversations. In order to find interesting people you have to seek them out. You have to intrude (in a nice way) in conversations and take part. It's through this action that I found a few more interesting people to follow last night.

Looking back, I'm actually glad that there isn't an all singing all dancing recommendation tool for people on App.net, because it would take the fun out of finding people on the service and connecting with others. I still think that there should search facilities for people on the service and that perhaps the recommendation feature in the App.net Passport have a filter that allows you to only see recommended people, but that would be all that others would need.

Thanks to Dalton and everyone that contributed to this post through their many conversations on App.net.