permalink
Two days ago, I notified my business partners I would be resigning from the company we own. After tying up some loose ends for the next few weeks, I will be completely unemployed. I am scared but excited.
This is possibly one of the craziest things I’ve ever done. My job paid me well, and has been a stable source of income during what appears to be the worst recession of my lifetime. The business is doing well, and my partners are close friends with whom I’ve had a great working relationship. I think most people would be justifiably happy to be in my situation.
But over the last year I’ve found myself just going through the motions. As we adapted business priorities to match the changing economy, I’ve felt the value of my contributions to the business diminish, along with the technical challenges I face. I’ve been taking out more than I put in, and I stopped growing as a programmer. This was unfair to my partners, and to myself. So I decided to get out now before doing any further harm to our friendship or to the enthusiasm that I feel for my profession.
At the moment I have no job and I plan to keep it that way. I am fortunate that, between my wife’s job and our savings, I can afford to take 6 months to a year off if need be. My plan for the next year is to improve myself as a programmer by working on open source projects, studying and writing. I’ll consider taking jobs if the right opportunity presents itself, but my highest priority is to make the most of this sabbatical by working on the things that I love.
I’ve always been a firm believer that enthusiasm breeds success, and now it’s time to put that belief to the test. It’s going to be an interesting year!
By Norman Clarke, published Jul 01, 2009 in work and open source
permalink
GitHub is a great service, and a great company. Since they launched, I keep watching them roll out new features and products, and wonder when they are finally going to slip up. They seem to be as sharp on the business development front as they are on the coding front, and fully deserve the rich praise the community gives them.
But there’s one thing I hate about Github, and that is having to specify the username on the gems I install. This has always seemed like a totally ass-backwards, square-peg-in-a-round-hole workaround. The only reason I still register anything on Rubyforge is so people can more easily install my gems.
So since obviously I am the most qualified person to tell Github how their business should be run (ha!) here is how I think it should work.
Installing with no username
gem install my_gem_name
This should install from the owner’s repo. If there happen to be two non-fork repos with the same name, offer a choice, like gem already does when it can’t automatically detect which architecture to install for.
There are two gems named "my_gem_name." Please choose one:
(1) my_gem_name (created Nov 11, 2008 by joeschmoe)
A super duper gem to do way cool stuff
(2) my_gem_name (created Jan 12, 2009 by somerandomuser)
I couldn't think of a better title for my gem
The output would show you which repo was created first to help you determine which one is more likely to be the one you are looking for. Maybe it could also show how many followers it has.
In order to minimize the amount of gems with the same names, Github could also tell you when you create your repository how many other repositories have the same name, so that you can choose another if you want.
Installing with a user name
gem install joeschmoe-my_gem_name
This should always install from the user/repo combination, no interaction necessary – it will work just like now. This would allow you to make sure dependencies work correctly.
I’m pretty sure these changes can be made without patching the rubygems library, but if it were necessary, I see no reason why the maintainers of Rubygems shouldn’t accept patches to make it work more easily with Github.
So there you have it: unsolicited advice for a successful company from some random guy with a blog.
By Norman Clarke, published Jun 04, 2009 in Github
permalink
Formatting phone numbers is pretty easy in most high level programming languages using pattern matching and string replacement. But what if you want to actually access any meta information about the phone number, such as “where is it from?”, “which part is the area code?”, and “what’s the line number?”
This is reasonably easy with US phone numbers – but once you try to do this for phone numbers for most other countries – forget it. In Argentina, for example, area codes can be anywhere from 2 to 4 numbers long, and phone numbers vary in length depending on where they’re from.
For that reason I’ve been working on a phone number parser and formatter for Ruby. At the moment it supports North American and Argentine phone numbers, but provides a generic framework that makes it fairly simple to add support for more countries. Once I complete some more documentation I’ll be adding support for the UK, Brazil and any other countries that people bug me about.
Here’s an example of what you can currently do:
If you want to play around with it, take a peek at my project on Github, but be warned that it’s in a fairly early stage of development and not very well documented yet.
By Norman Clarke, published Feb 03, 2009 in Ruby, Phone Number Gem, and Argentina
permalink
- Read full post »
I’ve recently gotten the itch to play around with some different programming languages and after looking into it off an on for a few months, I’ve decided to plunge headfirst into working with Lua for web development. Why? I happen to think Lua has a bright future as a web development platform.
In this post I’ll show how easy it is to install Lua and set up a few useful packages on OS X. Later I’ll follow up with a tutorial on what you can actually do with Lua once you’ve got it installed.
By Norman Clarke, published Jan 28, 2009 in Lua, tutorials, OS X, and Mac
permalink
Matthew Burke recently announced on the Lua mailing list that mod_wombat, the embedded Lua interpreter for Apache, will be renamed to something less silly and included by default in the next stable release. This module is conceptually similar to mod_perl or mod_php5; it lets you easily create web pages using the Lua programming language.
This is very good news for Lua as a web development language. The avaialability of a high-quality deployment option for web applications will remove one of the primary obstacles to acceptance of Lua for web development. Lua’s small size could make it an appealing environment for use on small, cheap VPS systems from providers such as Dreamhost. Its performance should make it attractive for larger systems.
There are already libraries that enable the use Lua code in <? and <% tags, similar to PHP/Ruby/ASP/JSP/etc., which will make the barrier to entry lower even than PHP given that Lua’s syntax is very easy to learn and it will come with Apache by default.
While Lua is unlikely to supplant PHP any time soon (nor does it need to), I do expect to start seeing more programmers work with it for web applications.
By Norman Clarke, published Jan 27, 2009 in Lua and web development