Ulysses – markdown editing

Before I tell you about Ulysses and why I think it’s a great piece of software, a quick primer on markdown.

What is markdown?

Markdown is an easy way to create rich documents using a plain text editor (with bold, italic, etc), and it is particularly useful to create HTML content. Markdown makes it easy to create blog posts without having to worry too much about the formatting, but you can still perform powerful formatting in a text editor. For example, you can create:

A headings

Or you can create

More headings

Or if you want a list it easy easy. Just use a *

Most modern text editors provide some sort of markdown support. But there is a single feature that Ulysses gets right. Even though markdown is simple, it is easy to get confused and mess up the formatting.

Ulysses shows you how your document is going to look in the plain text. You don’t need to switch to a markdown preview view. This makes it super-fast to write web content.

Simple markdown

If you look at the below screenshot, you can clearly see what I wrote, and this formatted blog post is of course how it appears. Screen Shot 2017 06 26 at 2 59 24 PM

Sample markdown screenshot

Commands

While markdown only requires you to learn a handful of formatting commands, you don’t even need that! Your traditional CMD-B will turn test into bold, or CMD-I for italic etc. Or you can use the simple dropdown pallet for a shortcut of the main commands.

Screen Shot 2017 06 26 at 2 59 50 PM

Command list

Word count

Ulysses gives a nice view of word coun,’ as well as an estimation of page reading time, and you can set goals and see your progress towards that goal.

Screen Shot 2017 06 26 at 2 59 58 PM

Read time

Screen Shot 2017 06 26 at 3 00 46 PM

Goal progress

Creating articles

Ulysses is good for creating ideas and draft articles; since everything is stored in a single notebook you don’t have to keep on creating and saving draft files; you just add a new page and start typing. This feature is very similar to Onenote and Evernote (except they don’t support markdown). In my workflow I create a group for articles, which is broken down into:

  • Ideas
  • Draft
  • Complete

Articles roughly move from ideas to draft then complete as they move through the writing and editing process.

Not just for web

While the main benefit of Ulysses is to rapidly creat HTML, since it is just rich text, you can easily use it for print formats as well. Ulysses allows you to export to docx (Microsoft Word), PDF, epub and text. You can also publish directly to a WordPress blog. Here’s a quick example of the PDF export (you can fully customize the PDF).

Screen Shot 2017 06 26 at 3 42 30 PM
PDF export

Other features

I have just touched on a few features of Ulysses, there are a ton of other features, including:

  • tagging
  • powerful search and filters
  • attachments
  • automatic sync across devices
  • automatic backups
  • Dropbox sync
  • Styling

Is Ulysses for you?

If you aren’t interesting in learning or using markdown, then no I wouldn’t bother using it. But if you already using markdown, or see it as a potential tool to create online content then I strongly recommend it. I have been using it for about a month now, and its great. It was easy to create markdown or HTML articles, the grouping and tagging allows you to use whatever workflow you want, and it has a powerful search capability.

Unfortunately for Windows users, it is Apple only (Mac and IOS) You can find out more on the Ulysses website.

Finally the disclosure. I was provided with a free copy of Ulysses for this review, and I used it to create this review. But I am finding myself using it more and more as a general note-taking application, and for creating and managing my blog posts.

Hackers: book review

Hackers: Heroes of the Computer Revolution – 25th Anniversary Edition Steven Levy

The book provides an interesting view of the history and growth of computers, seeing through the eyes of the hackers; the somewhat elusive group of people that have never cared much for contention, have pushed the limits of both computing hardware and software, and have at the same time engage in headed and headstrong arguments about computers, hardware and software.

The book discusses three main groups of hackers, representing the early era’s of modern computing. The first were the group of mainframe hackers bases at MIT in the 50’s an 60’s, using computing time on the hulking mainframes, trying to get the monolithic batch-processing machines to bend to their will.

The second group were the so-called hardware hackers; a group of hardware junkies at Berkeley, figuring out how to assemble pieces hardware to create their own working computers in the 70’s. This was the days of Alteir, the beginning of Intel and Steve Wozniak (who created the original Apple and Apple II).

The final group focuses largely on computer games; an industry which sprung up in the 80’s with the proliferation of arcade games, and the mass movement of computers into people’s homes.

While the book is not specifically written for computer junkies, it is far more interesting for the hackers (or at least want-to-be hackers) out there. Somebody without a passionate interest in computers or programming would probably get a little board with the level of detail.

However, for those like me who work the field, it is a fascinating story of some eccentric people that literally shaped the computing world as we know it today. While there is a strong focus on the development of Apple, and the gaming world for the Apple (at least in the second half), there is very little mention of the IBM/Microsoft route, and the development of applications and games for the so-called PC world. This almost reflects the modern Apple/PC divide.

While at times I find the book little verbose, it is nonetheless a fascinating story. The edition I read was a 25’th anniversary edition of the book, which was originally published in 1985, a testimony to the longevity of the book. Well worth reading.

Thanks to the folks at O’Reilly for the review copy.

The 10 Lies Software Developers Tell

Program_code1) My code is better that yours. Writing code is very much like writing a song or painting a picture. Artists and song-writers have different styles of painting or song writing. Writing code is similar, different software engineers have different coding styles. So, unless your code is really badly written, my code is no better than yours, it is simply different to yours. If my code works and does not require any enhancements, leave it alone, no matter how different to yours it is.

2) It works on my machine…well, if it works on your machine and not mine, then clearly it is not a robust application, or your installation procedure does not work very well. Remember that you wrote it on your machine, so of course it works on your machine. Now get it to work everywhere else.

3) I’ll comment the code at the end. The end of any development cycle is always chaotic, that is a simple fact of software engineering. So, if you have not got time to comment your code while you are writing it, how are you going to have the time at the end? Besides, if it is a large project with a long development time, are you going to remember what some of the earlier written (uncommented) code does!

4) I’ll add the error handing at the end. Error-handling is part of the basic design of a system, not something you slap on at the end when you have time.

5) The programme is complete – but I just need to quickly finish off…..This is a very common one. The development is not complete until you have finished writing all of the code. If you have a single line of code to write, it is not complete, and not ready for testing.

6) It is a small bug – it will only take 5 minutes to fix. By the time you have load the development environment, identified the bug, fixed, tested and rolled out the change to production, it will be much longer that 5 minutes. There is no such thing as a 5 minute to fix bug.

7) I only have to change one line of code to fix the bug. To the customer, it does not matter weather it is one line of code, or one hundred lines of  code. All the customer cares about is that the application is not working. Fix it!

8) It’s not my problem. If your application is not working – it is your problem. It does not matter if RightFax is down and you cannot print faxes, or you cannot connect to the FTP server. The fact is that if your application is not doing what it should be doing, you had better find out what the cause is, and resolve it.  While different people may have ownership of different portions of a software system, you are ALL responsible to ensure that everything is working.

9) The application works fine with my test data. Yes it might, work with the test data, but the live system does not run on test data. It runs on live data. Best you get your application to work with live data.

10) It’s a user error. If the user is clever (or stupid) enough to break your application, it is not robust enough. You need to anticipate all user inputs, and cater for them. If at a later stage you find another user error, modify your code and test cases to check for it.

And a bonus lie…

11) Of course I test my own code. Do you? Really? Promise? Ok, then let me try to break your application.