weblog.masukomi.org

mah-soo-koh-mee

Why I won't be backing Mou's crowdfunding Campaign
Kudos

October 09, 2014

Mou as your Markdown loving Mac geeks know, is a split pane Markdown editor. It's been around for years and it's really quite good. I even donated to its creator in the past to support it. Now he's put together an IndieGoGo campaign to pay for people to work on it full time, but I won't be contributing.

Some background first

Mou was never open source. I'm ok with that. I use a bunch of great proprietary apps. Unfortunately, that means that when its developer (Chen Lou) was busy with his life, Mou languished, and no-one could help improve it. Eventually he decided he couldn't give it the attention it deserved and tried to sell it. Sadly, I found out about this after the fact or damn would I have been trying to put together the money to buy it.

Life Moves On

During the process of trying to sell it Chen appears to have decided to try and put together a company to work on it full time, which is great, but when the sale was announced UranusJr (otherwise known as Tzu-Ping Chung) got a bit concerned.

It came as a great shock when Chen Luo announced that he felt he could not actively continue the development, and wished to sell the ownership of Mou. No suitable offers surfaced (I honestly do not think there will be, either), and I decided that instead of waiting for others to do something about this, I should act myself.

And act he did. UranusJr's been working like a madman on an MIT licensed clone of Mou called MacDown. He's been adding features on a regular basis, and is constanly asking for and listening to feedback from the community. He allows those of us who use it, but aren't skilled at Objective-C to feel that we are making some kind of worthwile contribution by trying out his beta code and discussing the ideas that he, and the community, come up with.

The crowdfunding

Meanwhile Chen Lou's IndieGoGo campaign is offering the following:

  • "We'll pick the most wanted features from our contributors, implement them in 1.0."
  • Free license to Mou when it hits 1.0
  • Jumping metal frog
  • Metal stand shaped like the Mou's "M" in various colors.
  • If we're really lucky and it reaches $100,000 ( 5 times it's goal ) he will open source it.

So, let's compare those perks to what MacDown is offering:

  • MacDown implements the most wanted features from the community, not just a select few, and if you want a feature badly enough you can write it and there's a good chance it'll get merged in. Also, he's regularly adding features just because he wants them himself.
  • MacDown accepts feature requests from everyone. Also, it's not like Mou would ignore a great feature request from a non-backer. So this is kinda BS anyway.
  • MacDown's already free so I don't need a license
  • Don't need a jumping metal frog
  • Don't need a metal stand shaped like an "M"
  • ALREADY open source.

Mou's campaign encourages us to "Forget the crappy clones, let's open source the original Mou!" But why should we? UranusJr's done a spectacular job with MacDown. It's true that it's not quite as polished as Mou yet. I does have a couple rough edges, but it's polishing up quickly, and the driving force behind it is incredibly responsive to community feedback. With MacDown I've got a great app that I'm using daily, and it's released under one of the most permissive licenses there is.

At this point I see no reason to back Mou. Not long ago I would have happily thrown Chen some more money to start working on it full time, but Mou missed its opportunity. Someone else stepped in to fill the need.

P.S

This post? Totally written with MacDown.


The Five Virtues of a Great Programmer
Kudos

October 03, 2014

In Programming Perl Larry Wall (in)famously suggested that programmers had three great virtues: Laziness, Impatience and Hubris. Over the years I've kept coming back to those because there's a real truth to the idea as he originally presented it, but it's limited, and his definition of "Hubris" has no relation to the actual word. I believe that those may be aspects of real programmers, a great programmer goes beyond that. Building on Larry's idea, I present you The Five Virtues of a Great Programmer:

Laziness

The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.

Impatience

The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.

Hubris

The belief that you can do a better job than the people who came before you.

Humility

The belief that despite your hubris, there are more talented coders than you, and anything you produce could be better. This leads to well tested code, because you might have screwed up.

Unselfishness

The quality that makes you document your code, and leave helpful comments and commit messages, so that others don't have to puzzle out what you've done. It makes you take the time to help coworkers understand things, and change your code to take their needs into consideration.


Vampire Bug [Definition]
Kudos

October 01, 2014

n. something that worked when you went to bed at 2AM, but when exposed to the light of the next day dies horribly. Typically the exposure proves that it couldn't possibly have been working at 2AM either.


How to enable GitHub 2 factor Authentication on new device / app
Kudos

September 30, 2014

( as of Sept 30th 2014 )

These are the instructions for how to do it if you've already got it configured and need to add a new app / device. If you don't have it set up already, GitHub's docs are... probably passable.

  1. Go to Settings
  2. Click on Security
  3. In the "Two-factor authentication" section click "Edit"
    • Yes, even though you don't want to edit it.
  4. Under "Delivery options" click "Reconfigure two-factor authentication
    • Yes, even though you don't want to reconfigure it.
  5. Click "Set up using an app" or "Set up using SMS"

What would you want to do?
Kudos

July 23, 2014

This afternoon my intern asked me this simple question. She's a new developer, and a friend of hers is working in a fresh codebase, with best practices. Everything is nice, and he can keep the entirety of it in his head. She's working with my team, Support Engineering. We're the front-line bug squashers at our company. We've got a legacy codebase with no tests and brain melting insanity around every bend.

So she asked me which environment I'd want to be working in if I was her. The question, and the answer speak a lot to what it takes to become a great programmer.

What I would want if I was her is simple. I'd want to be working in the new codebase. There's no question. A new codebase is always more enjoyable to work on. But, what I would want is not what I would recommend with 19 years of professional programming experience.

My suggestion was that right now she was in the best place she could be: debugging a bad codebase with good instincts and helpful mentors, and that's why I'm writing this.

I firmly believe that the most important skill you can learn as a programmer is how to debug: how to debug well, and how to debug fast.

New codebases are great, but they're like kittens. One day they're cute and fun, and the next thing you know they've grown into a tom cat who's running around spraying your furniture. It'll be too big to hold it all in your head, and large swaths of it will have been written by other people. Even if you're really lucky, and people have written great tests, and some god has smiled down upon you and granted you the only significant codebase with no bugs, you'll still need to use your debugging skills.

In the typical case you'll need debugging skills to figure out where the problem is, and then what exactly is going wrong. In our mythical perfect codebase you'll need to figure out where a feature is implemented and how it works in order to build on it. There's really very little difference: hunt something down, understand it, make some changes, write some tests, move on.

People with bad-ass debugging skills get things done faster, in any industry.

That's just the start of why our situation is a better one for her than the happy-fun-land her friend is in. New developers haven't experienced pain yet. They've seen the patterns books but they haven't internalized the problems that resulted in those patterns. They won't know what problems those patterns were designed to avoid, so they won't know when they're about to create that problem. I think that even if they were to go read the best pattern book for their situation they wouldn't be able to truly appreciate it because they don't know the classes of problems they've got to deal with.

Debugging a legacy codebase though... If you've got good instincts, or good mentors (preferably both) you'll be able to see all the ways to not do something. You'll encounter things that just feel wrong, and have people who can explain to you why they're wrong, or what piece of the puzzle you're missing. Once you've found the bad, you'll have to figure out how to make it good, and you'll learn about tradeoffs, because professional coders rarely have the luxury of refactoring everything to be the best it could be, especially in crufty old legacy codebases. No, you have to find the balance. You have to figure out what you can do to improve the situation without spending so much time that the other bugs pile up. It's a lesson I'm still learning nearly 20 years in.

When she eventually moves on from her job as a professional bug slayer she may not know the right way to write good code, but she'll definitely know how to not write bad code, how to make code that other people can understand (because she had to wade through so much incomprehensible stuff), and why you don't violate encapsulation.

A year from now her friend will just be starting to experience the consequences of his inexperienced decisions. A year from now she will be ready to tackle anything.