Matthew Lang

... with Atoms.

Markdown. It's become so engrained in my workflow that I barely think about the syntax now. This post is being written in Markdown, as does most other things I write. To support this markup I need tools that are not just Markdown compatible, but champions of Markdown. Marked 2 is one such tool.

Marked 2 is an OS X markdown viewer. If it sounds like Marked 2 only does one thing, you're wrong. There's more to this app than simply viewing a file.

Many Markdown viewers and editors give just the basics of viewing Markdown. The markup formatted as HTML with your choice of theme to make it all pretty to look at it. Marked 2 does this too, but it also does so much more.

More Statistics

We've all the seen the word count feature on lots of editors. In fact I would say that almost all editors have this feature included in them. Marked 2 includes a word count for your document, but it also other statistics:

• Character count
• Paragraph count
• Sentence count
• Reading time
• Average words per sentence
• Average syllables per work
• Reading ease

That's not all of them as well, there's more, but you get the idea. The great thing about the statistics is that on Marked 2 you can leave this pane on the app open and it will update the statistics as you type.

Probably not a good idea to be continually looking at this as you type, but periodically I like to see how much progress I've made and whether my editing has improved my document.

Excellent Keyword Analysis

You can highlight repeated keywords from your writing, which will highlight those keywords in pink. Once you have done this you can also click those keywords to darken the rest of the document so that you can see only the keyword you clicked and where it is repeated in your document.

During this view you can also zoom out from your document and get an overall view of your document with those keywords still highlighted.

I've been using this to replace poor choices of words and replace them with better choices. The keyword analysis can also be customised so that you can include words that you want to avoid when writing.

Lots of Preferences

My blog is a static website that is regenerated each time I deploy it. However before I publish a post, I use Marked 2 to preview my post to check everything is where it should be and that it reads well enough.

Octopress posts are markdown files themselves, but they contain a section of YAML at the start that contains details like the title of the post, the published date and any categories I want the post to be assigned to. Marked 2 has a preference for striping YAML from your document before it converts it for you so that you can view the content of your post without the messy distraction of YAML.

There are tons of other peferences as well covering window behaviour, choice of Markdown library, style settings and even settings to adjust how the document will print.

Use Your Favourite Editor

I'm a Sublime Text user for both writing code and blog posts. I've tried a few other editors, but with shortcut keys that I have memorised, it's hard to use anything else but Sublime Text. Marked 2 is great in that if I am viewing a file, it has a shortcut key that you can change to switch to your preferred text editor, where it will open up your document, ready for you to edit it.

On the flip side there is also a plugin for Sublime Text that will preview your document in Marked 2.

Easy Publishing

Marked 2 also supports a number of file types that you can export too. These are the most common document formats like PDF, DOC and ODT. As nice as Markdown is to write with, sending a Markdown document to someone who isn't familiar with the markup might struggle a bit. So it's nice to have the choice to export your document to a more friendly file type for everyone.

I've yet to try this myself but Marked 2 also includes support for the Leanpub publishing platform. lets you publish your document to Leanpub. This is great as it makes the journey to self-publication that little bit easier.

A Power Tool

Marked 2 isn't just a Markdown viewer, it's a Markdown viewer on steroids. A power tool. This is why I have Marked 2 running all day long on my second screen.

I've been continually tweaking the preferences as I go along to get the right environment for me to write in. It also doubles up as a document viewer for some lookup documents that I use on a daily basis.

Marked 2 offers so much more than just being a viewer and for me it's been money well spent on a product that gets used on a daily basis.

Some suggestions for lists to keep. I actually have some of these as sub-lists within my master list.

The one question you must ask yourself when you let new technology into your life:

[What problem does this solve?](http://minimalmac.com/post/73277791743/what-problem-does-this-solve What problem does this solve?)


via FGGT photo by Father Tu

... a better business, with Nicholas Bate

Brett Terpstra released a new version of his Cheaters cheat sheet system. Brett recommends two options to get this running. The first is using the Automator application in OSX and the second is using the Fluid app.

The one change I wanted to make was to make Cheaters run as a local Rack web application with Pow rather than from the already installed Apache instance. It's easy to do.

1. Create a Gemfile

Create a Gemfile within the root of the Cheaters source and include the Rack gem:

gem 'rack'

Jump back to the command line and run the bundle command to install this gem.

2. Create the Rack App

Next create the Rack file that will serve all the pages and assets from the Cheaters source. I've used this same code for lots of Rack applications.

require 'rack'

$stdout.sync = true

use Rack::Static,
  :urls => ["/css", "/js", "/images", "/cheatsheets"],
  :root => "."

run lambda { |env|
[
  200,
  {
    'Content-Type'  => 'text/html',
    'Cache-Control' => 'public, max-age=86400'
  },
  File.open('index.html', File::RDONLY)
]}

Put this in the root of the Cheaters source.

3. Symlink Cheaters

Now I'm assuming that you have Pow installed already. With Pow installed, change to the pow directory and symlink your Cheaters directory:

cd ~/.pow && ln -s /path/to/cheaters

I also use an app called Anvil that gives me access to my running web applications in Pow from the menubar. This can also create the symlink for you if the terminal is too scary.

Done!

That's it. Now if you visit [cheaters.dev](http://cheaters.dev), you'll find the Cheaters page. The reason I prefer this is that I already have a number of application running locally that I like to use, so running it from the browser is fine with me.

As a freelance developer working for a client, I don't have the luxury of daily stand ups to get the outline for a new feature I have to work on. I also don't have the benefit of having another programmer sitting beside me or even in a remote location to talk about the feature further in a pair programming session. When you're on your own, you need to find other ways to kickstart the development process of envisioning a feature of a system.

I generally have a rough idea of the feature, but sometimes even getting a rough idea can be difficult. It pays to talk to the customer or even the product owner to get all the details you need, but sometimes even after that you might still be unsure. Where I usually falter is that I understand the feature but seeing it in code or as a set of objects can be difficult.

One technique I've been using is writing the sample code of how I would eventually interact with the feature once it is shipped. This isn't production code or code that's even going to be run. It's just me hammering out sample code on text file. The benefit of this technique is that I can identify simple objects such as classes and properties without too much code. It also lets me see if I'm starting to build dependencies on other objects. It might not be viewed as TDD friendly, but when you're working on your own, anything that helps should be considered.

The code itself consists of creating a couple of instance objects and setting the attributes needed for each one until I've satisfied the need to have a set of objects that could be read from a database. There's no fancy Rails code here, it's just plain old Ruby. I don't even bother to refactor it at all as I'm just looking to get an initial design from the code. Then I can start TDD'ing the feature with the my new found understanding.

I've no idea if this technique has a name or not, but it works well for me when I have problems envisioning the design for a feature.