Sunday Selection 2012-04-28

Around the Web

Minecraft, Scrolls, 0x10c: The past, present and future of Mojang as seen through Notch’s eyes. I’m not much of a gamer, but I do like making cool stuff and I love reading about people who are making amazing, beautiful things. Notch is the creator of Minecraft and the anticipated 0x10c and this interview is full of interesting tidbits.

The Terrifying Reality of Long-term Employment As a recent college graduate who has chosen the temporary sanctuary of the ivory tower, the job market is something I can afford to avoid, but it’s still something at the back of my mind. The state of the current market makes me wonder if we need to rethink jobs and value structures in an age where long-term stability is increasingly rare.

The Boston Marathon Bombing: Keep Calm and Carry On. I usually don’t write about current events, partially because I’m never quite sure what to say, and partially because I’d rather not add to the noise if I don’t have something useful to say. That being said, I’m all too happy to point in the direction of people who I think are actually making level-headed and rational comments about the current state of affairs. Bruce Schneier is certainly one of those people and I can’t help but wonder how different the world would be if people like him were in charge of our security.

Software

Capsule: The Developer’s Code Journal. I find that keeping a record of things I’ve done through the day is very useful. It’s a good estimator of where my time went through the day, and an empty log is a sign that things didn’t go quite right.  I normally have a text file on my phone that I just dump everything into. Capsule looks like an interesting solution for programmers (both teams and individuals) to keep a quick and dirty log of what they’ve been up to. I’m probably going to put it on my Linode for a week and give it a try.

Coding standards are communication tools

I’ve been writing a lot of C code over the past few months. It’s been fun and I’ve learned a good amount about writing solid, low-level, procedural code. While cranking out code I’ve also been developing a simple coding standard, mostly for my own use and based on on the K&R standard. I’m not working with a particularly large group (and probably won’t be anytime soon) so I won’t be asking anyone else to follow these standards anytime soon. They don’t follow the rest of the code 100% either. But even being essentially the lone hacker on the project, I’ve found sticking to a standard helpful.

C is a great language but often I want to say things as part of the program that I can’t put in the code. For example, there are often things about variables that aren’t captured by the type and even if they are, I don’t want to have to look up the type every time I see the variable to get that information. But by following simple rules about how my variables are named, I can pack in a lot of information. For example, a plural name is an array, a name prefixed with num_ indicates that it holds the number of something in the system, a name prefixed with rv_ means that it stores the return value from a function (probably for error handling). Outside of variables, function names are verbs, locally defined types meant to be private are CamelCased, exposed types have a _t suffix. Of course, these don’t apply in all cases and some amount of discretion is involved.

Following a standard like the above has a double benefit: first I can think less when it comes to naming things and it prevents casual naming conflicts. Secondly, as I hinted to above, it’s a communication aid. There’s a certain amount of information that is encoded into the language’s syntax and semantics. This layer is checked and enforced mechanically at compile time. But a coding standard allows for a secondary, optional layer that can convey more information without expanding the language standard (and allowing teams and individuals to develop their own, suited to the task at hand).

Note that I’ve mostly talked about naming conventions and I haven’t said anything about formatting. Personally I think formatting conventions are less important and helpful. It can be annoying to read code that is formatted differently across files (or in the same file), but I think the benefits to be gained from consistent formatting are less than that for consistent naming. In fact, I think that formatting issues should be eliminated by having a tool that will automatically reformat code to a single standard. I have the Go language’s gofmt tool in mind, but I’m sure there are others. (This is also one of the pet peeves I have with Haskell: it’s apparently really hard to write an auto-indentation tool for its syntax)

One caveat is that I have no personal experience as to what effect a coding standard has across a large group. I’ve found two articles arguing against coding standards on teams, but they’re both far too emotional and hand-wavy for me to take them seriously. Personally I would be wary of a developer who can’t adapt to a coding standard in a reasonable amount of time. That being said, there are definitely more important things than adhering to a standard (getting working code for one). However, I do think that coding standards fit into a larger culture and system of good coding practices. These include things like code review, appropriate use of version control and proper communication channels to talk about bugs and feature changes.

To conclude, a coding standard can be a great tool for personal uses. In some ways it frees up my limited mental RAM to think about more important things. It also allows me to pack more information into my code, outside of what the language syntax or semantics allow. I’m less certain of the benefits for large groups and as Emerson puts it, a foolish consistency is the hobgoblin of small minds. That being said, I’d like to believe that a good coding standard (with formatting mechanically enforced) along with practices like code review can lead to a higher code quality.

Sunday Selection 2012-12-09

Around the Web

A Funny Thing Happened on the Way to Academia

As my third semester as a PhD student draws to an end, I’m starting to think about what to do in the long term: what kind of a career I want to have, what kind of problems I want to focus on, etc. This piece is an interesting look at how research in computer science can coexist with making an impact in the real world today.

Trouble at Code School

I’ve been a Teaching Assistant for two semesters, but I haven’t really been on the front lines of teaching students. That being said, from what little experience I have introducing newcomers to programming that both teaching and learning beginning programming is no easy task. Luckily, with the growth of education-based startups and the resurgence in academic CS programs we’ll probably see interesting approaches in the near future.

GitHub vs Skyrim

Giles Bowkett manages to come up with interesting perspectives on a regular basis. This article talks about about GitHub and Skyrim and how the way they encourage team dynamics may lay the foundation for a new way of organizing companies and teams. Perhaps the most insightful idea is that the very definition of an office or workspace is not only changing, but gradually becoming irrelevant as work becomes increasingly distributed.

From the Bookshelf

Surely You’re Joking Mr. Feynman

I first read this book years ago in school and it was probably the first book to show me that you can fill a life with equal parts work and fun. This book probably played an important, though subconscious part in my decision to stay in academia for the time being. Even if you’re not a scientist or and academic, this book is worth reading and learning from. Life is supposed to be fun.

Sunday Selection 2012-10-21

Good afternoon everyone. It’s fall in my part of the world, the leaves are changing color, the weather is getting colder and the days are getting shorter. Things are moving and shaking in the tech world (as usual) and today’s Selection takes a look at Microsoft, Linux, Firefox and the intersection of technology and life.

Around the Web

The Story of the New Microsoft.com

Microsoft has a new website. No matter what you might think of the company and its products, I think you’d be hard pressed to say that the website wasn’t a job well done. It’s clean, effective and very modern.

UX Principles Behind Firefox for Windows 8

I’ve always had a soft spot for Firefox. Even though I mostly use Chrome nowadays, I keep coming back to Firefox. It was the first non-IE browser I used and I think the Mozilla team has done a lot to make the web a better place. It’s good see Firefox evolving and developing to stay in tune with the rest of modern technology.

Linus Torvalds Answers Your Questions

Linus isn’t the most public of technology superstars, but he doesn’t pull any punches either. In this recent Slashdot interview he talks about kernel development, what he might have done differently, patents and more.

Video

Creative Mornings with Jonathan Harris

CreativeMornings is a monthly breakfast lecture series for creative types. Each event is free of charge, and includes a 20 minute talk. This one is by Jonathan Harris creator of We Feel Fine and Cowbird (among others). It talks about his journey exploring technology, life and storytelling. If you’re looking for examples of a remarkable life well lived, this one’s a keeper.

Rules for Computing Happiness Revisited

About a year and half ago I wrote down some Rules for Computing Happiness. I based the list off of a similar list by Alex Payne. But in the year and half since then a lot has changed in my life. I graduated from college and finished a year as a graduate student at Cornell University’s computer science running experiments. I’ve also finally joined the world of smartphone users. I spend the greater part of the day writing programs and scripts and spend an increasing amount of time on remote machines. In the light of all those changes I think it’s a good idea for me to revisit the rules I laid down and see how much they’ve changed (or stayed the same). Here goes:

1. Use as few physical machines as possible

This one’s a keeper. I now use only two physical machines: my personal Macbook Air and my powerful Linux desktop at work. I use a combination of Git, Dropbox and Chrome tied to my Google account to keep things in sync between them. In reality the work I do on each doesn’t much overlap so there isn’t a pressing need to keep them in sync.

2. Keep work and play separate

Another keeper. I don’t have any social media apps on my work machine, I generally keep IM closed and I’m busy and in the flow enough that I don’t feel the need to randomly open up Reddit or Hacker News. I should be honest and say that this isn’t a purely (or even mostly) technical thing – in fact it probably has more to do with my shifting perspectives on what’s important. I have my phone near me if anyone really needs to get in touch with me. Since I’m a grad student I have a lot on my plate that is important but little that is urgent so my phone rarely gets used.

3. Get a Linux machine for programming. Use multiple monitors and a tiling window manager

I’m a bit less sure of this one and I’m partly afraid that I’m just plain biased. I do most of my programming on my Linux machine, but I do a decent amount on my Macbook Air too (especially experimental web stuff). I mostly use the UNIX in each so I’ve become fairly agnostic to what skin I’m running on top. I’ve never programmed on Windows so I don’t have anything to add on that matter.

However, I do use two monitors on a regular basis and going back to one can be annoying. I tried using Unity for a while and while it’s not bad, I keep going back to XMonad. It’s clean separation of physical monitors and virtual desktops makes using multiple monitors very flexible and efficient and I always find myself missing it when I’m on a different environment. By contrast, the way OS X does it is complete rubbish, especially if one of your windows is in fullscreen mode.

4. Get a Macbook for non-programming tasks

I’ve had my Macbook Air for over a year now and I love it. It’s the best laptop I’ve owned and probably the best computer ever. I only use a handful of userspace apps but they’re high quality ones like Reeder and OmniFocus. Homebrew is definitely the missing package manager for OS X and makes any programming I do a lot easier.

5. Keep a backup server, either physical or virtual

I’m still running a small Linode VPS that serves my personal website and acts as the syncpoint for my Git repos. I haven’t had any destructive crashes in the past year so I haven’t really felt the need for a backup, but it does offer peace of mind.

6. Learn and customize your tools

Yes, but do realize that it’s not the point.

7. Use public computers as little as you need to

Since I have both a great portable machine and a great workstation I haven’t had to use public computers at all. My desire to work in coffee shops and libraries has also been decresing steadily and I now prefer to work in a private office or a quiet shared workspace.

8. Pay for good software if you need it, but only after you’ve tried it out for a while

I’ve bought software like OmniFocus and Reeder and by and large I don’t regret it. I’m currently considering getting iA Writer. It’s cheap enough that I rarely think twice about gettting something that would make my job easier. However they “trying out” part is harder. My biggest gripe about the Mac App Store is no way to try out apps for a period of time (or stop using them and get a refund).

9. Keep information in open formats, preferably plain text

Yep. The only non-plain text format I interact with regularly is PDFs, only because that’s how most academic papers are distributed. I hold out hope that one day the academic community will move to publishing in hypertext.

10. Use version control on all projects

All my source code, my research data, my configs, my public and private writing are in version control. It not only makes it easy to go back and get something I may have overwritten, it also makes backup easier.