RobG3D

Mike Bland has done a series of articles and presentations about the Apple SSL bug over on his blog. To be frank, it’s pretty much the only good coverage of the bug I’ve seen. He’s submitted an article to the ACM; crossing my fingers it gets printed, because it’s an excellent analysis. I’ve been frustrated it hasn’t gotten more traction.

Mike’s take is that this bug could have easily been caught with simple unit testing. It’s sad this has been so overlooked. We gobble up the explanations that do not force us to confront our bad habits. We can point and laugh at the goto fail (“hahaha, never use goto!”), or just shrug at the merge fail (“we’ve all mistakes merging”). It’s much more difficult to wrestle with the fact that this error- like most- is because we are lazy about duplicating code and writing tests.

I have no problem categorically saying anyone who doesn’t blame the SSL bug on lack of automated testing and engineering rigor is making excuses. Not for Apple but for his or herself.

In December, I spent some time polishing up a new fork of the old PlanetPlanet Python feed aggregator, named Planet Mars: https://github.com/rgalanakis/planet-mars . I chose the name to contrast it with Planet Venus, a successful PlanetPlanet fork. My goal for Planet Mars is to make it as simple as possible, to be the best aggregator for the very common use case. It’s based on my experience running a PlanetPlanet-based river at http://tech-artists.org/planet. That feed has been powered by Planet Mars for the last few months.

The main features are:

• Jinja2 templating, in addition to the original htmltmpl engine. Old templates still work, new templates can use a better language.
• Parallelization of feed updating, so things are many times faster.
• The code is stripped down and much easier to understand and improve.
• Planet Mars can be installed via pip, so instead of having to place your customizations in its package directory, you can pip install the GitHub repo and import it as a module into your own code (you can see the Planet TechArt repo as an example).
• Planet Mars otherwise very similar to PlanetPlanet, making switching to PlanetMars very easy :)

Please take a look and tell me what you think, especially if you are an original Planet user.I’m very open to improvements and suggestions. If there’s any demand, I can put this on PyPI as well.

I’ve been following John’s blog for about 9 months and it is one of my favorite blogs. Poignant, digestable posts, that usually get me thinking. The programming posts are the best around, though the math and statistics posts often go over my head (thankfully there aren’t a ton of those). He seems to read a new book every 3 days so a handful of his posts are just really interesting quotes from those books. He has an honesty and seriousness that is missing in some other bloggers I like (Scott Hanselman), but posts much more regularly and in more digestable chunks than some other bloggers I love (Eric Lippert, Jon Skeet). I’d highly suggest subscribing to John’s blog.

My favorite recent posts:

• http://www.johndcook.com/blog/2012/02/16/csharp-batch-file/
• http://www.johndcook.com/blog/2012/02/14/hard-soft/
• http://www.johndcook.com/blog/2012/02/09/programming-langauge-popularity/
• http://www.johndcook.com/blog/2012/02/06/ceiling-of-complexity/
• http://www.johndcook.com/blog/2012/02/03/limiting-your-options-creates-better-options/

http://www.johndcook.com/blog/

Adding feeds to Planet Tech Art, it became clear that not everyone studies great bloggers like Scott Hanselman or Dave Winer. Here are some rules:

• Your full name should appear somewhere on your main page. Prominently if you are advertising yourself, but at least somewhere in the footer or header. There were some blogs where even a first name was absolutely nowhere to be found. Unacceptable.
• A link to your feed should be somewhere on your main page. In order of preference- top/top of sidebar, sidebar, bottom. I visited several blogs that did not have an RSS feed anywhere. Again, unacceptable.
• Make your first few works count. Many more people will see an excerpt than read your entire post, make sure the first couple sentences don’t say ‘Sorry I haven’t posted for a while’ or something similar.
• Make sure your name is in your blog feed. Or something to identify you. For Planet, this is taken care of automatically, but subscribe to your own feed and make sure it is recognizable.
• Speaking of subscribing to your own feed- subscribe to your own feed and make sure your posts are formatted in RSS properly. I’ve seen more than a few with missed code samples and other plugin-dependent data.

Happy blogging.

If you read one long blog article this year, make it this one: Rands in Repose’s Bored People Quit.  It is one of the most important blog posts I’ve read in a long time, and right on the money.

If you’ve ever worked a shitty professional job (especially programming), and you know you have, you’ll resonate with what’s written there.  I told my last job for well over a year that I was bored and actually tried to quit a number of times, and gave exact action items for how to fix my boredom and what my grievances were.  Not that any were ever addressed.  And in a place like that, they couldn’t realistically be addressed, with so much riding on such an expensive project- they couldn’t give a shit about almost any individual worker or what I perceive as the long term health of the studio.

Anyway, go read it, and pass it on to your managers!

I’ve talked a bit about my problems with OSS as an outsider.  Martijn Faassen wrote a great post about his problems with it from the inside: How to Handle Ideas.  It’s an informative, lucid post about improving the ways the open source community receives ideas and criticisms, written by an insider.

Even outside of the open source community, it is useful to read and remember his advice and ideas, as they’re useful ways to handle incoming suggestions and criticisms for any internal project you work on.

Ian Cooper, one of the contributing authors at CodeBetter.com, recently wrote an article called ‘Why CRUD might be what they want, but may not be what they need‘.  While this applies mostly to the world of applications, I’ve been saying the same things about tools and pipeline for a while now.  The basic argument goes, the people designing/requesting our apps have a history and understanding of the process, and when we build new systems, they ask for optimized versions of that same process.  But there are very likely ways we can rethink that legacy process in the context of much better technology and software, and change the experience profoundly for the better.  It is our job, as the people who sit between technology and content development, to do that.

And the good news, as always, is that if we fuck up, no one dies.

Go ahead and read the article and see what I mean.

Raymond Chen over at The Old New Thing had a few blog posts recently about debug/release build behavior.  I have never figured out why, but it seems an incredibly common standard practice to not run in debug because there are too many errors.

The danger of making the chk build stricter is that nobody will run it:  Here, Raymond mentions how a MSFT team didn’t support running its app in debug mode because it broke into the debugger too much.  Hey, let’s report errors only when nothing is at stake!:  Raymond talks about programming different behavior into debug and release builds- specifically, to crash in debug but swallow in release.

Perhaps because I haven’t been around too long, I just cannot understand how so many otherwise smart people can have such, such bad ideas.  And how common this particular issue is.

The issue was especially bad when I was forbidden to use exceptions.  I wanted to put in asserts since I wasn’t allowed to use exceptions, except that no one else used the debug build, so when people broke these asserts, they never knew.  And then when people’s changes broke some new (and pretty fundamental) asserts, I was told ‘oh, we don’t run in debug.’

Wait, what?  You have absolutely no way to ensure valid state, or even keep track of state at all, other than in logs that make debugging far more difficult than it should be (because the problem that should have asserted or crashed will only manifest itself much later and it is unlikely you can determine where the state got messed up by just looking through the log, at least without adding a bunch more logging).

Does your studio do this (not run in debug because there are too many exceptions or asserts)?  If so, you may need to smack sense into people.  This is a god awful and unforgivable practice when you are using any program- programs with persistent state can corrupt that persistent state, and programs without state can return unexpected results.  These sort of decisions are indicative of a myopic or insular culture that is in serious need of a rude exposure and shake up.

I’m on Google+, and it is the FIRST social networking site I’ve ever actively participated in. It seems pretty awesome so far, have I been missing this on Facebook all these years?

Fine me here: https://plus.google.com/u/0/112207898076601628221/posts//p/pub

Another awesome blog totally worth reading is by Joe Duffy, who is a Lead Architect at Microsoft, and an expert in concurrency, performance, and memory.  Calling it a blog is unfair to bloggers- he really doesn’t update it often.  But the articles he has on there are incredibly lucid and interesting, revealing information I’ve never read on any blog, anywhere (stuff you can generally only find in books and papers, except delivered much less formally and much easier to understand).

Definitely go and read these posts:

Why volatile is evil

Dense and pointer free (regarding memory performance)

The premature optimization is evil myth

Thoughts on immutability and concurrency

I could go on and on (and in fact, those are just his 4 most recent posts- they’re all gems), but almost every post is incredibly deep and worth reading.  So do what I do with all those inactive MSDN blogs: bookmark it, read through it in a weekend (or for Joe’s, a few weekends).