Matt Gauger

Introducing John December on How Does Wisconsin Get the Job Done?

2010-03-28T00:00:00-05:00

It’s been awhile, but I’ve got a brand new interview with John December on The WI Setup!

Introducing Jason Gessner on How Does Wisconsin Get the Job Done?

2010-02-14T00:00:00-06:00

Another week, another new interview with Jason Gessner on The WI Setup! Hot off the presses!

Web414 Feb 11, 2010

2010-02-11T00:00:00-06:00

These are my notes from the February 2010 Web414 meeting. I wrote them in Markdown as the meeting progressed, so there’s not a whole lot of explanation or context.

Part 1: Workflow

What do you use for bug tracking?

Mantis, Trac, Bugzilla, Pivotal Tracker, Intervals

Hacking OpenAtrium case tracker to support bug tracking

What do photographers use? (Photographer Workflow)

Lightroom, Photoscape (John December)
The DAM book: thedambook.com

Bandwidth, backups

There isn’t enough upload bandwidth to mirror all your content if you have a lot of data.
Everyone sign up for Google’s fiber program.
Amazon S3(Jungle Disk), Dropbox, Carbonite.

Then things went like this:

GIT GIT GIT GIT GIT GIT GIT Mercurial Microsoft GIT

IDEs:

Eclipse/Aptana: No longer supports PHP ** Eclipse just got git support
BBEdit
Netbeans has some PHP support
Textmate users? Quite a few.

Time trackers:

Harvest
Intervals
MacFreelance or iRachet.

Batch processing / hourly jobs:

Do all of your photoshop tasks for different projects at once. Who makes that part of their workflow? 5 Getting Things Done: lump actions together

Pomodoro

Study technique. Way of focusing.

File transfer:

Replacement for Cyberduck?

Transmit.app: costs money but it is included in Coda
Filezilla
Flow.app
FireFTP - Firefox plugin

Customer Relation Managements

Highrise - Manages people
Sugar CRM
CiviCRM
Kevron is building CRM into their OpenAtrium project.
Salesforce sucks!

Part 2: Frameworks versus CMSes

A web application framework has some things written, but things like delivering web pages is up to the coder. -> An incomplete web application, a framework that you hang your business logic on.

Arlen: “The future of the web is in frameworks, not in CMSes.”

Every CMS does things its own way. “one size fits all.”

Arlen: ”I’m fighting the CMS. The CMS has a way it wants to do things. I have to write the business logic in such a way that the CMS can do it. Every CMS brings in POV.”

The big three of CMSes:

Drupal
Joomla
Wordpress

Example web app frameworks: PHP:

CakePHP
Zend
CodeIgniter (behind ExpressionEngine)

Other languages:

Ruby on Rails for the Ruby language.
Django for Python
Catalyst for Perl
Seaside for Smalltalk
Lift for Scala.
ASP.NET MVC or .NET Webforms

Derek: “Are we arguing the semantic difference between being a developer and being an integrator?”

[ Discussion on integration and its worth. I’m not going to even try to record it all here. ]

Arlen: ”I’m worth more as a developer than an integrator.”

Steve Kleibel: “It’s about solving problems and delivering solutions. And most people don’t care about what’s going on under the cover.”

Curtis: “Most of the time it is about how fast can I get this up and running? I know that Drupal/Joomla/Wordpress are well tested and quick to set up.”

Arlen: “I think the future in web developers is in frameworks.”

Kevron: “He said bit-twiddling. That was amazing.”

Book Review — The Productive Programmer

2010-02-08T00:00:00-06:00

I recently finished Neal Ford’s The Productive Programmer, which was a fast read. It exists as a spiritual successor of The Pragmatic Programmer. But where The Pragmatic Programmer gave maxims, The Productive Programmer discusses recipe-type solutions to common problems the author perceived at the time of writing, 2008. There’s a slight bias towards Java, which was (mostly) king of the coding world at the time, and Java’s two main IDEs, Eclipse and Netbeans. Luckily, the book goes beyond those topics and in some sections covers Windows, Linux and Mac OS X and their respective IDEs and editors. After presenting some “recipes,” the book goes on to talk about the process of finding ways to be more productive as a programmer, which explains the title.

The author describes the reason for creating the book as thus: When stuck in an airport terminal with a software engineer friend, they wondered “Did the world really need another book on regular expressions?” While regular expressions are powerful, there are a bunch of books on that topic that are already excellent. O’Reilly’s Mastering Regular Expressions comes to mind. Becoming fluent in regular expressions is just one way to increase your productivity as a programmer. This book sets out with a loftier goal of teaching you to find ways to be more productive.

Most of the recipes were things I already did on Mac OS X in developing software — the Windows tips didn’t really apply to anything I do. I already use Google Quick Search as a replacement for Quicksilver and Launchbar to keep myself from wasting too much time in the Finder. I try to make the most of my text editor of choice, Textmate, and its bundles. I keep data in plaintext (really a habit I picked up from The Pragmatic Programmer) and keep my files/code/etc much under little git repos. That isn’t to say that the book wasn’t interesting or helpful to me. Some of the things I picked up were in the Practice section (Chapters 6 to 16, so the bulk of the book) that covered coding, particularly object-oriented design, DRYing up documentation, and test-driven development.

There is an appendix of concepts in the bash shell, which will be useful those that aren’t familiar or comfortable with getting things done in the shell. Personally, I’ve been using bash for so long that many of the tricks involving grep and find they discussed in the book I’ve figured out in the past, sometimes with a wildly different solution.

Ultimately, at roughly 220 pages it was a quick read and fairly informative. I’ve been pushing friends to read it, especially people approaching coding from a web design/web app background rather than a Linux & Java background, to see how they like it. For those that have already read The Pragmatic Programmer more than twice, it’s probably worth the quick read, but you’re likely already doing and thinking similar things day-to-day. Recommended.

Introducing Pete Prodoehl on How Does Wisconsin Get the Job Done?

2010-02-05T00:00:00-06:00

A great interview with Pete Prodoehl has just been posted. Check it out!

Introducing Derek Dysart on How Does Wisconsin Get the Job Done?

2010-02-02T00:00:00-06:00

Head on over for a brand spankin’ new interview with Derek Dysart.

Continuous Integration for the Lone Programmer

2010-01-30T00:00:00-06:00

There’s a laundry list of tools and practices in my head that I consider part of modern software engineering (version control, unit testing, code reviews, etc.) These aren’t necessarily required on every project. Continuous integration seems to be a practice that many prominent developers are using. But continuous integration servers aren’t very glamorous, and therefore don’t get a lot of discussion.

If you’re working alone on a project, committing it to version control, and using unit testing, what does it matter whether you run the tests yourself or have a continuous integration server running them? True, there’s a level of immediate feedback with running the tests yourself. But unless you’re building all the various unit testing and integration testing frameworks into one rake task, you may forget to run them all. In the case where you do have a rake task, your CI server could be running that for you on every commit. A continuous integration server ensures that the tests get run, whether you remember or not.

The other plus to this setup is that you can choose how and when the CI server interrupts you. You may be in a flow state and not want to be bothered by stopping to run the unit tests every five minutes when you know you’re not breaking them. That could be dangerous, though. If you zone out for a half day and come back to find all the tests failing, you’ll need to go back through the builds to see when and what commit first broke it. Luckily, the CI server should tell you that.

I set up Integrity locally to run as my continuous integration system. Technically, Integrity could be hacked to build and test just about anything that gives a Unix return code, but I’m using it in its most common purpose: building Ruby projects that are hosted in git repos. While many developers are using GitHub, I’ve pointed Integrity at local git repos.

I did consider setting up a Campfire chat room to receive build status messages in, but it seemed overkill to sit alone in a chatroom to be updated by Integrity. So, I enabled the email functionality, and now Integrity is configured to email me with build status. If I keep a Firefox tab open to the Integrity server and choose whether to look at my email or not, I have a fairly effective barrier to decide when to let myself be interrupted. Meanwhile, the builds continue.

I’m hoping to optimize this and integrate it fully into my workflow, as TDD/BDD is a new thing to me and Integrity is already serving to reinforce writing good tests.

How Does Wisconsin Get the Job Done?

2010-01-25T00:00:00-06:00

The title is the question I asked myself after reading through the latest interview at UsesThis.com. I’d thought about using the Creative Commons-licensed stylesheets of Usesthis.com (aka TheSetup) for a nicer About Me page than I currently had on this blog. After tweaking the template a little, I realized I could use Jekyll and apply this template to any content I wanted.

Instead of just post my own answers, why not interview everyone I know in the tech community here in Wisconsin? So that’s exactly what I’m doing. In the first round of interviews, we hear from Phil Gerbyshak, Ashe Dryden, and myself. The interviews can currently be viewed at http://blog.mattgauger.com/thesetup/

There’s more on the way, and I’ll be announcing new posts through my Twitter and on this blog. Oh, and please feel free to comment using the new Disqus commenting system!

Fonts Are Good

2010-01-23T00:00:00-06:00

I just started tweaking this blog’s design again. The first step was doing a font makeover with FontSquirrel’s @font-face kits. I chose Droid Sans Regular, which is a free font that Ascender and Google put out. I’m liking it a lot.

More changes to the blog design are likely. This initial design was a quick attempt at something I had in mind, but on reflection it doesn’t look finished.

Purpose, Part 2

2010-01-18T00:00:00-06:00

(Finishing a blog post originally drafted on 12/29/2009)

Now that I’ve established a purpose for this blog, I thought about my own purpose.

It seems to be part of human nature to question our purpose in life continuously. Even when we seem to have it figured out, the question sneaks up on us again. I’ve attended several places of higher education in the last few years, and my concept of what I want to do with my life has shifted during that time.

In the past 8 months or so, I had convinced myself that my interests didn’t align with working on web applications anymore. After thinking about the problem I had decided that some day I’d like to get a graduate degree in bioinformatics, which is one field where being a clever programmer and applying Computer Science theory are both good things. Web apps, in comparison, rarely use CS theory and felt like copy/pasting functionality together to please a client.

Bioinformatics also has the potential to do good in the world. Diseases could be cured, science and medicine could be advanced, and people’s lives could be made better with the suitable application of data, code, and computing power. Web apps rarely have the ability to change the world, much less do good in it. Sure, there’s websites like Kiva making a positive change in the world, but the majority of work to be had in developing web apps is not so altruistic.

The distinction for me is whether the problem space is interesting. Interesting stuff is far more likely to make me happy and hold my attention. Interestingness is intangible, of course, but certain topics lend themselves to be interesting for me.

In the past year I had a stint at a consulting shop doing Java Wicket/Hibernate development and a Rails project. The consulting shop promised interesting in-house projects using natural language processing and location based services towards creating some interesting tools. Sadly, I never got to work on them. I was the last in the door, and so I was the first out when money got tight.

There’s a certain amount of soul-searching to do after losing your job. I went on that journey after losing my job and ended up back in school, studying primarily mathematics. And I’m loving it. But I don’t see math as a viable career, either in applications (like economics/finance) or teaching it. Those just aren’t my strong points.

One of the problems I’ve run into is that I’ve felt like my coding skills have gone stagnant in the time since I lost my job. I stopped needing to code and be on top of things, and at the same time stopped learning. One of my goals for 2010 to correct this is to learn constantly. It’s not an easy task in the scope of everything I want to learn in my lifetime. For me, learning goes beyond just getting a college diploma, or knowing enough to squeeze by in your day job.

I was heavily influenced when I was younger by a book called How to Think Like Leonardo da Vinci (Amazon affiliate link), which explained the concept of a Renaissance (wo)man. While the book’s exercises didn’t stick, the concept of being a modern Renaissance man did. The result is that I’ve become an information sponge, especially on topics that seem useless to other people. Having a wide-ranging knowledge of the world doesn’t necessarily pay off in terms of a better salary, but it ultimately makes you a better citizen of the world, in my book.

Web414 January 2010

2010-01-14T00:00:00-06:00

Web414 is a monthly technology meetup here in Milwaukee, which is responsible for BarCampMilwaukee, MKE Devhouse, Milwaukee’s coworking meetups, photowalks, and many of our other events in Milwaukee.

Bucketworks is the usual host of Web414, but they’ve had some issues finding a new physical location in the past year. December was the first Web414 in their new location (fingers crossed!) near 5th & National. Bucketworks seems to be on track to open for business later this month at that location, but they didn’t have an internet connection + wifi in time for the January 2010 Web414.

Kevin Ciesielski (Kevron on Twitter) hosted this month’s Web414 and moderated a panel on radio. His panelists were Ryan Schleicher of WMSE, Tarik Moody of 88.9 Radio Milwaukee, Jim Conigliaro of Journal Communications, and James Brust of online radio station Limbiq Frequencies. The panel discussed the technical difficulties of streaming radio on the web, and the issues surrounding licensing music for broadcast. Creative Commons licensing came up as a possible solution to the licensing issue. Unfortunately, the discussion didn’t include any musicians (vocal ones, at least) and I would have liked to hear what artists think about Creative Commons versus what broadcasters think.

At first, one might wonder why this topic was chosen for Web414. The panelists were not as involved (or prepared to talk about) the technical side of streaming radio online. In fact, I heard a few people whispering in the back questioning the relevance to to Web414 during the meeting.

But I’m going to go ahead and argue that the topic is entirely relevant to Web414. As a group, Web414 is exploring both the online realm and how to make a living working online. But Web414 is also concerned with the creation and publishing of content. That content could be writing, photography, code, art, interior design, music, etc. that just happens to live online. We’ve all staked our careers on the awesome capabilities of the web and the fact that we can make a living on the web. That’s why I think it is relevant to have a panel of radio folks or an interior designer or a singer-songwriter as the focus of a Web414 meeting.

I may come off as a curmudgeon, but I think Web414 has already covered technical topics & tools in detail and doesn’t need to go that route anymore. Often, these topics appeal to only a small subset of attendees, or the 1 hour time limit is too short to adequately cover the topic. An hour intro to Drupal or Joomla or even a web site like Flickr is barely enough time to cover the basics and will probably only appeal to people who are already interested in Drupal or Joomla or Flickr. When I spoke at Web414 on version control, I felt that I’d barely scratched the surface of the topic and my talk failed (my fault, I’ll admit) to interest the people it was aimed at: those not already using version control. Technical topics seem better served by a whole unconference event, like the very successful Drupal Camp Wisconsin which I’ve had the pleasure of attending.

So what topics would I personally like to see at Web414 in the future? I think we need to tap into our attendees and find interesting individuals to interview. I’m curious to hear what they do, how they do it, and how they pay the bills every month. I’m curious to hear what tools they use to stay productive and how they focus. And if we can draw in some interesting folks from Milwaukee and the surrounding area to interview along the same lines, I’d be interested. I’m not asking for a Lifehacker meet-up. I just think that the topic can now safely shift from specific technologies and websites and onto how to make ourselves better professionals.

I think we need to allow for Web414 to change, too. In the past year, we had The Web414 Show hosted by Gabe Wollenburg and Pete Prodoehl. They took Web414 in the direction of a late-night TV talk show, which was good, because Web414 was beginning to feel like an Twitter Anonymous member meeting before that change. We may need someone to shake things up again, though. Things change so fast on the web (and generally impact us so little) that I question whether we need a “this week on the web” news segment. The tools and technologies that people are using and making a living off of is such a huge list now that it would be an injustice to try and cover what is happening with everything. Similarly, the happenings of web bloggers and web personalities really don’t have any relevance to us as a group anymore, if they ever did. (John C. Dvorak and Kevin Rose come to mind.) I’d like to suggest instead that we try to cover local Wisconsin developments in the tech sector: new companies moving into town, new initiatives by the state or local governments in using the web (if they ever chose to) etc. Perhaps instead of covering “web news” we could devote that time to allowing meeting attendees to brag about neat projects they’re working on or have been involved in, even though we’ve discouraged this practice in the intros in the past. I’d like to stay plugged in to what local folks are doing and be able to congratulate them for their successes and their failures.

Milwaukee is noticeably lacking for particular technology users groups (such as Linux User Groups (LUGS), programming language user groups, etc), or they’re not as successful as Web414. I rarely hear about other groups in Milwaukee that I should check out. So Web414 does help to fill that niche where users groups don’t exist. But maybe Web414 can be a catalyst to letting people meet and spin off their own groups. Having a new permanent location would certainly help, if Bucketworks is game to open up their space in the future for other groups. I’m looking forward to seeing what happens with all these groups and awesome people (who I’m glad to call my friends) in the new year.

Pulled Thoughts

2010-01-07T00:00:00-06:00

Below are several bits and pieces of my previous blog post which didn’t ultimately get included. I thought that there were some neat thoughts in here, so I included them, without rewriting to add context. Enjoy.

Research in artificial intelligence can trace its roots back to the father of the universal computer, Alan Turing. He famously concocted the Turing Test, whereby a computer might be able to prove itself sentient. But as we’ve found, being able to a fool a human and perhaps know how to respond in human language does not make a sentient computer.

While there are several approaches to artificial intelligence, the two relevant disciplines I’m going to discuss are top-down design and bottom-up design. Bottom-up can better be called behaviorism, or the emergent behavior approach. (note: these are my own classifications, not necessarily the academic definition, and blatantly stolen from Steve Grand’s explanations in his book.) Emergence is the topic of several interesting books that I’ve read over the years.

Grand suggests that a ‘cyberspace’ be created and a first-order of complexity be coded into it to jumpstart artificial life, rather than trying to model and perfect an a-life creature with no environment or need for survival. Artificial life would be a second order of complexity that would emerge from the simulation. (He asks, what does a translation program care about its survival? Can we really reward it for better translation or punish it and threaten its survival for messing up?)

Traditional software engineering is largely monolithic and still waterfall-based. Object orientation and various Agile/XP paradigms have changed that, but have not succeeded in breaking the monolithic concept. APIs and protocols are still brittle and lack the ability to adapt. I’ve yet to work out all the implications, but a method of software engineering based on these concepts of adaptation and feedback loops could be very powerful.

I’ll be curious to monitor the progress of Jeff Hawkins and others’ research with the HTM model. I think that they may have the best model for working on a general artificial intelligence, even if it does not ultimately lead to one. Neuroscience is still a field where there is a lot left to learn on many levels, and hopefully a feedback loop is established in which the field of artificial intelligence continues to benefit from neuroscience research. ;)

Hopefully some day Steve Grand will also get the recognition he deserves for the contribution the Creatures game made to a-life. Perhaps his work will inspire a different type of video game opponent AI that attempts to survive in its simulated world rather than just play against the human, but I have not seen that kind of complexity given to video game AI yet.

End signal.

Feedback Loops and Emergent Behavior

2010-01-05T00:00:00-06:00

This post started out as a review of two books. My friend Zac Witte introduced me to the work of Jeff Hawkins, previously of Palm and now working at a company called Numenta, which is working on a method of creating artificial intelligence. Hawkins wrote a book called On Intelligence in 2005 detailing his research into artificial intelligence up to that point. Zac recommended the book while we were hacking on code at a coffee shop here in Milwaukee.

I countered by recommending the work of Steve Grand, who is responsible for one of my childhood videogame addictions: Creatures. Creatures was an artificial life simulator that was deceptively simple and childlike. Yet behind the scenes, complex biological processes were being simulated and multi-lobed brains were allowing the Norns, the Creatures of the game, to think. At least, think in a rudimentary, simulated way.

Steve Grand wrote a book called Creation: Life and How to Make It detailing his experience in coding the game. It quickly runs through several thought experiments in how one might simulate physics, matter, and chemical reactions. (And indeed, what these simulations say about the real world.) Grand likes to link various disciplines together, and the book easily jumps from transistors and electrical engineering to neurons to chemical reactions and on to more abstract concepts. Grand’s work can be said to be of the field of artificial life, or A-life, and not necessarily artificial intelligence.

Emergent behavior theory suggests that complex behavior emerges from simple behavior. Or rather, that the whole is smarter than the sum of its parts. Think of an ant hill, which does not really have a leader yet manages to survive and adapt through simple actions of the ants. Emergent behavior found its popularity among the MIT Mobile Robot Lab, among other places. Simple behaviors telling a robot how to react to stimuli, for example, to back up its right wheel when the front left bumper is pressed or vice-versa, can produce seemingly intelligent behavior.

Jeff Hawkins began to study AI by reading as many scientific articles as possible. But, he was frustrated by the seeming lack of progress and unwillingness of the AI field to study real neuroscience. Hawkins wanted to study the human brain and use that for inspiration into how to create a general artificial intelligence. Traditional academic approaches to artificial intelligence at that point completely ignored neuroscience. Hawkins does not want to fully simulate the brain at some chemical level, either. Instead, Hawkins studied the neocortex, in his view the most important key to understanding the human brain. His research led him to an architecture he calls Hierarchical Temporal Memory, or HTM, based on how the brain processes patterns and fragments across time rather than whole memories instantaneously.

Hawkins discusses some of the shortcomings of traditional neural network research. Most neural networks, from the 70’s to the present, were simply three stages of neurons: an input stage, a “black box” stage, and an output stage. Neural networks were trained with sample data, in which connections between neurons could strengthen or weaken. But after training, the neurons’ connections are “locked” and no further training occurs. Hawkins likens three stage neural network research to reverse engineering the transistors in a modern computer and being able to build simple amplifier circuits, or perhaps transistor radios. There is interesting behavior in an amplifier circuit, but it will never be a digital computer.

So why are these two books together in one review? Grand is an artifical life video game creator, and not at all interested in the same kind of artificial intelligence that Hawkins hopes to create. Their research seems to be opposed, or at least completely different.

The concept that these two differing authors agree on is the importance of feedback loops. Those traditional three stage neural networks rarely included simulating feedback loops in the neural connection, while the human brain’s neocortex is largely feedback loops. Further, the number of connections coming in from the senses to the brain is far outweighed by the number of connections going back out to the sensory organs, in a nearly 10-to-1 ratio. This is extraordinary if you think that the brain simply processes incoming data passively. It is actively responding and anticipating sensory data.

You remember music in bits and and fragments rather than whole songs. There is a time element to these memories. You can’t remember the whole song all at once, or hear every note at the same time. The same can be said for all memories. Hawkins points out that being able to predict the world led to the brain being organized this way. After all, prediction is a powerful survival skill.

Grand writes:

Living beings are high-order persistent phenomena, which endure through intelligent interaction with their environment. This intelligence is a product of multiple layers of feedback. An organism is therefore a localized network of feedback loops that ensures its own continuation.

We can find feedback loops around us everywhere in nature. One of my favorite examples comes from the book Sync. Fireflies in Thailand will swarm in tall grass, flashing randomly. But they synchronize with each flash, until the whole swarm flashes in unison. How do they do it? There is no leader or conductor telling the fireflies when to flash. They change the rate of their flashing slightly, faster or slower, until they all match and the flashing syncs. Surprising complexity and cooperation can therefore occur from simple, basic behavior.

One of the places where a feedback loop exists in technology is in the TCP/IP protocol. In a simplified view, one could say that the rate of packets being sent is regulated based on signal loss. The machines at both ends of a network connection don’t know anything about the connection between them or how good it is. They simply use the degradation of the signal - whether packets make it through and are responded to - to modulate whether to send more packets or the same packet over. This feedback loop has a speed regulating effect. The feedback loop ensures that the message will get delivered, even over a bad connection.

Feedback loops and emergent behavior are both fields of research that I’m actively interested in learning more about. These books have fueled my thoughts for further exploration of both concepts. While feedback loops and emergent behavior may not have applications in all endeavors, they can be powerful solutions to the right problem.

The research of both authors is interesting and their books are highly readable. They both provide interesting thinking on the brain and the natural world, and I’d like to follow up with more books in these areas. Both books are relatively short are definitely recommended reads. Too many ‘pop science’ books seem to fall to the side of including too little real science, or paraphrasing studies that don’t really have a neuroscience background. I’ve had that issue with recent books on the human brain and learning marketed towards computer programmers: much of it was based on nonscientific surveys or speculation, which was highly disappointing.

This is a Problem

2010-01-04T00:00:00-06:00

I’ve hit a snag in my workflow for writing blog posts. As I’ve written about before, I’m using Jekyll, which creates static HTML files for this blog when it is run. That should be fine, except for a few issues.

The first is how Jekyll is designed. Published posts go in a _posts/ directory, with a filename of the form

	YYYY-MM-DD-title.md

This presents me with two immediately problems. I have to finish the post in the day I start it. This rarely happens. Most of the time, I start a blog post with a few ideas that I’d like to flesh out. And the file sits, unfinished, until I come back to it. While I’d love to follow release early, release often as described in the inaugural post, a few notes to myself do not add up to something that anyone else can read. I’d like to occasionally draw a useful conclusion from my thoughts, even if it doesn’t result in a long essay.

The second snag in this system is usually the lack of a title. Or that I have a title and no content to go with it. I’ve had both problems. Sometimes, without a good title to go with a post, I’ve sat at the New File dialog box in Textmate and given up. And more than once on my old blog, I had a couple neat, catchy-sounding blog post titles that sat as drafts with no writing whatsoever. Because there wasn’t a blog post to go with them, just a catchy title.

Here’s what I’m talking about, a screenshot of my old blog’s Drafts folder:

Note that at one time, these all seemed like good blog post ideas. Now, they don’t, really.

I suppose I can always rename files, but that’s missing the point. The point is that there’s a speedbump to getting blog posts out there that I need to get over. Maybe it’s a mental block when I see that New file dialog box. Maybe I’m just making excuses. But I certainly feel like I’m failing at a simple task here.

Purpose

2009-12-28T00:00:00-06:00

Every blog has to have a purpose. For awhile, I had a blog hosted on Wordpress.com, The Byte Codex. I had told myself that it was my coding blog, and that all insights I gained in coding would end up there. Also, I’d blog about tech events I attended.

Unfortunately, I wasn’t coding enough and consistently at a level to produce world-changing “insights” on a regular basis. I got really wrapped up in trying to find something I could claim expertise on, and then blog about. But I wasn’t an expert on anything and wasn’t creating anything. The frustration and self-censorship about what I told myself I was supposed to be posting crippled my posting momentum. Further, the Midwest wasn’t providing many tech events for me to blog about, and the recaps all were more hazy memories surrounded by other people’s Creative Commons-licensed pictures of the event. (I usually am having a blast and forget to take notes or my own photos.)

All of my previous blogs had ‘rules’ in my head about what they were for and what could or couldn’t be posted on them. All of them failed. There’s something telling here. I think there’s plenty of reasons to have a specialized blog for different topics, possibly even trying to keep your life or your work separated out. But for me, I’m going to stick with a nice mix of personal anecdotes, book reviews, bike stuff (did I mention bikes yet on this blog?) and of course, little coding projects. I don’t want to wall myself in with rules that those are the only things that can get posted here, either. I have to take a deep breath, put away my inner quality control and publish everything.

A blog can have a purpose, but it shouldn’t be so narrowly defined that it never gets updated. After all, a blog with new posts is better than an insightful blog that has gone stagnant, in my book.

Appendix: A little history:

In the past, I’ve had several blogs:

xiphidae (archive.org link)
The Byte Codex
Livejournal
mathiasx.baywords.com/ - notable for the RFID microwaving video and a rant on Facebook, which are the only real posts.
and probably a few others that I’m forgetting.

Luckily, those blogs are not too terribly embarrassing to share.

The First 2500 Are the Hardest

2009-12-27T00:00:00-06:00

Seth Godin is a prolific blogger. He’s also a successful author. When he hit his 3000th post, I remember him writing

The hard part, as you can guess, is the first 2,500 posts. After that, momentum really starts to build.

Of course, I just started this blog. This is post number 3. And I’ve never really been able to develop a blogging habit. But maybe this time it’ll stick.

Onto the continuing adventures of tweaking this blog theme:

I was in the backseat of my parent’s van after to go to a family holiday get-together.

I had my laptop, and a vague problem of the nav buttons at the top right of the blog being fully rounded in Google Chrome on my macmini. But Firefox showed the nav buttons the way I wanted, with only the two lower corners rounded and a nice squarish block right up to the top brown border line. Luckily, I also had my awesome girlfriend with me. The offending piece of CSS looked like this:

	border-radius: 5px;

	border-bottom-right-radius: 5px;
	-moz-border-radius-bottomright: 5px;
	-webkit-border-bottom-right-radius: 5px;

	border-bottom-left-radius: 5px;
	-moz-border-radius-bottomleft: 5px;
	-webkit-border-bottom-left-radius: 5px;

She pointed out that I was using the generic CSS method of rounding the corners, border-radius, but also using the Mozilla (Firefox) and Webkit (Safari) specific methods as well for the lower corners. So, I commented out that bit about the border-radius and waited, as we were barreling down the highway at 60 MPH in the backseat of a van, and for some reason the Department of Transportation hasn’t started installing free wireless access points on the highway. Which limits my ability to update my blog from the road. Luckily, I don’t find myself in the backseats of vans on the highway very often. (City buses are a different story.) So I uploaded the changes when I got home and tested it. Success!

Now to move onto some minor jQuery effects I want to implement. Nothing flashy, just the Javascript equivalent of hover effects, I’m thinking.

Passion, Absurdity, and Creativity

2009-12-27T00:00:00-06:00

Lately I’ve been reminiscing about _whytheluckystiff. He disappeared from the internet earlier this year, taking all of his code, writings, and other creations with him. There’s more info on the Wikipedia article and there are several eulogies to _why. His writings have been mirrored online, luckily, and his code put back on http://whymirror.github.com/.

One of _why’s passions was teaching programming to children, as evidenced by The Little Coder’s Predicament, Hackety Hack, and the Try Ruby website. (These are all links to the current versions of these projects, as _why’s versions are all gone.)

Hackety Hack was the modern self-contained equivilent of programming BASIC on a Commodore, full of simple functionality and even a component to send code to friends over the internet. Hackety Hack ran in Shoes, which I’d used in the past and enjoyed. I’ve been trying to get the resurrected Hackety Hack project to build as a standalone application because I have a few young cousins that I’d like to give it to.

In a blog post about _why, shack_a_nerd wrote

When I was sad I would often return to the Poignant Guide and reread it, just pick it up from any chapter and start reading, and it would never fail to cheer me up, to remind me that there are wonderful things out there, and to inspire me to try to contribute something of my own.

Once I commented on the poignant-stiffs mailing list that I thought it was less of a useful programming guide for people who didn’t know how to program already, and more like a novel for computer programmers.

I thought a lot about what I was contributing and what I was coding. For months, I haven’t touched any code. I was contributing nothing to the world. Before his disappearance, _why created a wealth of amazing things. His creativity and ability to be nonsensical set him apart from the mindless programmer drones out there.

I pulled up Why’s Poignant Guide and blew the dust off. I haven’t read it in years, abandoning it after deciding I wanted to be a serious Ruby programmer and that the level of silliness was a barrier to actually teaching me Ruby. But now I want to be inspired, want to steal some of that creativity. I want to create things that other people will delight in using. I’ve got a lot to learn from _why yet.

Shiny, Captain!

2009-12-26T00:00:00-06:00

Today I decided I wanted to start blogging again. I thought about my options on my hosting, and didn’t particularly feel like running a full-blown blog engine like Wordpress or Drupal. I knew I wanted a nice custom theme but I didn’t want to waste time trying to wrap my head around another theming engine.

In the very far past, I had a blog run on a friend’s server that was generated as static html files (and an RSS feed) by a perl script. It’s still available on archive.org. There are several Ruby-based projects that do the same thing. I chose Jekyll, which is what Github Pages runs on. I grabbed the gem off the Github gem server and set up the basic directory structure. The whole setup is extremely simple:

	.
	|-- _config.yml
	|-- _layouts
	|   |-- default.html
	|   `-- post.html
	|-- _posts
	|   `-- 2009-12-26-shiny-captain.md
	|-- _site
	`-- index.html

After creating those files, I was off and running with creating a theme from scratch. I’ve had my eye on HTML5 for awhile, and recently read an article on Smashing Mag that inspired me. I used their method of defining the HTML5 tags as blocks in CSS to allow me to write HTML5 now and render it in today’s browsers.

After a few hours, while my girlfriend watched Law & Order SVU on Netflix next to me, I coded up the theme for this blog. I stole the template for the Atom feed from mbleigh. There’s still plenty of room for tweaks and improvements I want to make. But I’m trying not to be a perfectionist, and instead follow the maxim of release early, release often.

Below is the “Hello World” post I whipped up initially to help with theming:

This is the first post!

this is a block quote!

This isn’t a block quote!

	(Hpricot(open url)/:enclosure).map {|x| x.attributes["url"]}.uniq.each do |vid|
	# File.exist?(vid.split("/").last) ? next : `curl #{vid}`
	filename = vid.gsub(/http:.+\//, '')
	filename.gsub!(/-/, "_")
	next if File.exist?(filename)

	puts "Downloading #{vid}"
	puts filename
	`curl -L #{vid} > #{filename}`