Broken Rubygems Upgrades

2 04 2008

As mentioned in the last post, while I was on semi-vacation up north in Michigan, I didn’t really have any way to access the internet. Also, my family didn’t really seem to understand the concept of ‘the zone’, of which I was trying to enter to work on some code. Oh well.

When I finally did get a connection on my laptop and sat down to work on git-wiki, which I’ve been hacking on, I saw that a new version of Rubygems had been released (My laptop is frequently behind on software versions, as I only use it consistently while traveling.) I thought it’d be prudent to do a gem update --system while checking the changes other people have been making to git-wiki on GitHub. Unfortunately, gem has a major flaw right now, or rake’s creation of Makefiles does, or some combination of the above are responsible. I haven’t yet figured out the responsible party. As far as I can tell, both tools were never meant to care about code that is to be compiled, and therein lies a flaw.

It seems that whenever Ruby extensions written in C are compiled (in this case the http11.bundle compiled for Mongrel), the compiler is forced to assume the architecture is i386 (PC), despite the fact that it was building on my old PowerPC-based Powerbook. gcc tends to fail at this step, and even after the Makefile is corrected there are errors on the Mac with Ruby redefining GNU C library functions for itself (instead of coming up with new functions to call that are ruby-specific). Further, the error in compiling isn’t handled by either rake or gem and the installation continues. This means the user tends to get a confusing error message sent out by Mongrel or whatever framework they’re using that uses a Mongrel:

In retrospect, this failure to compile C extensions is also the reason I was unable compile Ruby on my Sun Cobalt Qube 3 (an x86 based microserver, but lacking a modern OS with a packaging system). The Ruby compile tended to die at the stage that it was creating the socket extension to Ruby.

Back home now, I’ve cloned my laptop’s git-wiki /wiki repo back onto my desktop and thought about how best to track down the source of the compile issues, or who even to take the errors up with. There are any number of mailing lists and places I could complain about this problem. I thought instead that a blog post, even on a lowly blog such as mine, is probably the best course of action. And viola! This post was formed. Now, does anyone know what’s going on, and more importantly, how to fix this?

Update: So, this issue seems to stem mostly from having XCode 2.4 or older. I upgrade to 2.5 and noticed that I no longer had issues in the linking stage (the tool is ld, and it has to do with processor architectures and finding libraries, both of which changed between XCode versions). So now it works, unless I want to build universal binaries. (when I build stuff for myself, that’s not really a priority)

So if you get this issue and want to fix it, either upgrade to XCode 2.5 or upgrade to Leopard, which comes with XCode 3.0. This also means that Leopard users probably never had this particular error.


Update: blog status

1 04 2008

I don’t really enjoy April 1st pranks. I can’t even come up with a good one; so I’ll just skip the matter.

I remember reading back in the early days of blogging a list of do’s and don’ts for bloggers, and the author listed apologizing was one of the things you should never do on your blog. I wish I could remember where I read that. I also caught on to the whole completely-transparent business ideas from the past few years. Add those two concepts together and I was confused about whether to apologize or explain things, so I thought I’d just throw out a simple update post.

Since last Thursday I’ve been visiting my parents in the rural portion of Michigan. What I didn’t count on was that I wouldn’t have much time to write more blog posts, but also the fact that I wouldn’t be able to find a reliable broadband connection, much less a coffee shop or rest station with wifi. So the posts about GitHub and git-wiki never got published.

Perhaps my own new maxim should be:

Don’t promise your readers any posts until you’ve written them.

git is full of win

23 03 2008

The blogosphere seems to be blowing up with regards to the SCM suite git. At least, the blogosphere I frequent.

git is an open source project started by Linus Torvalds and currently maintained by Junio Hamano, intended to replace the proprietary BitKeeper system that the Linux kernel project used. Like Monotone and Mercurial, git is a modern decentralized revision control system that makes use of cryptography. The ‘repo’ doesn’t live on one server, instead every local copy on a developer’s machine is a full repo, with full version history. Developers initially copy the repo from somewhere (also known as branching or creating a clone) and make changes locally, commiting changes to their local repo as they code.

The process of combining two branched repos in SCM is known as merging. When developers are ready to share their changes, they can ‘merge’ their work back into other developers’ trees, or others could pull down changes from the developer’s local repo and work from there. Merging was previously a time-consuming and frustrating task with other SCM tools, but git needed to be able to merge the repos of the Linux kernel developers fast. In fact, git makes it so much easier than previous SCM tools to branch and merge both local and remote repos that developers can keep several branches around locally for various changes to live in.

The best image I found to represent this style of passing around changes has nothing to do with version control, but gives a good idea if you think of ‘messages’ as the changes:

Because all the cool developers hack on laptops now.
Usually while riding on bullet trains.

Subversion & CVS, on the other hand, use a centralized server that all changes must be downloaded from and uploaded to; making concurrent work possible. But a centralized server may be restrictive if a development team is scattered across the globe (as in the Linux kernel team & most open source projects) rather than scattered across the cube farm. (As a side note: git does allow for public repo servers, but that is a whole ‘nother topic.)

Best of all, git is fast. Faster than your filesystem, in some cases. You can throw data in its repo & 10 years later it ensures you get the exact same file out, due to cryptographic hash checking. SCM tools of years past couldn’t vouch for the integrity of your files, in fact checking in files was more likely to corrupt files at some future point, rather than protect them.

I’m not going to go into all the features of git or why it’s faster, there’s plenty of resources already. If you’ve used Subversion (svn) in the past, then this tutorial is probably your best bet.

Since this turned into more of an overview of git rather than covering the two topics I had in mind when I started, look forward to two more posts this week: one on GitHub, a git repository hosting service, and git-wiki, a wiki intended for personal use that checks its changes into a local git repo.

Milwaukee DevHouse1 Recap

19 03 2008

Pete Prodoehl has the scoop. I don’t really know what to say about it. We all met up at Bucketworks in Milwaukee with the intent to hack and hang out. I got there at 6PM and left at around 5:30AM on the next day. It was quite the party.

devhouse photo

(via my flickr)

4braham started a twitter-events mashup project, and I unfortunately wasn’t much help with it.. I guess I’m too easily distracted.  Other projects are detailed in Pete’s posts, I was actually out in the Bucketworks Flow room and so missed most of what went on in the smaller conference room.

The light table where we did our plotting:

light table at bucketworks

(via ashe’s flickr)

Fallacy: Startups don’t work in the Midwest.

4 12 2007

(aka I’ll let you know when the Midwest stops sucking)

Well, the title of this blog post is a little misleading: take for example, 37signals, which was the shining star of Web 2.0 a year or two ago, contributed to the further web 2.0 explosion by releasing the Ruby on Rails framework free, and now has become as ubiquitous and useful as internet infrastructure with their products Basecamp, Backpack, Highrise, etc. 37signals is, of course, from Chicago, Illinois. Further, there are dozens of smaller, successful Chicago startups that have carved out niches for themselves on the web, like Threadless, another Chicago startup that crowd-sources its products (successfully, I might add).

But the problem I’ve always had is hearing visionaries like Paul Graham or Joel Spolsky saying you can only make startups work in big cities that are “startup hubs,” like San Francisco (Silicon Valley) or New York City (where finance lives). They’re saying that the Midwest sucks too much to create successful startups. Add Chicago as a “big tech city where startups work” to the list, and you eliminate everyone in paragraph 1. Chicago is, after all, a vastly different place than the majority of the Midwest, both in attitude and population density.

The basic argument has become that some kid from a podunk town in Wisconsin or Iowa can’t start the next big thing. That’s complete and utter BS. Pardon the expression, but it’s worth repeating: It’s BS.

Clever heading about why it can work:

The internet is, by design, decentralized. Judging by the number of web-workers, co-workers, and freelancers out there today, one doesn’t need to be in the corporate headquarters to get the job done. The same goes for startups. You can get broadband pretty much anywhere, and that’s the only requirement for the startup these days. Everything else (hosting, support, infrastructure) is all distributed over the web, can happen anywhere, and is available to customers all over the world. You could work out of your cabana in the Caribbean as long as you have broadband, and no one would be the wiser. In connection with this is our next point:

Technology is cheap and readily available, too: laptops and servers (or even virtual hosting) is all the technology you really need. The cost of startups in this area has dropped to basically nothing. If you’re really cash-strapped, your hackers probably already have the desktop or laptop they’ll need to code, anyways. Virtual hosting is probably the killer app here for startup hosting, with services like Amazon’s AWS (Elastic Cloud 2 and S3) leading the pack. (not necessarily in terms of processing power, though.) You no longer have to spec out several $10K servers and more expensive colo space when you need to scale your web app these days, you just add more server instances for a higher monthly fee. (And btw, yes, Milwaukee and Chicago both have Apple stores to get your hackers their Macbooks.)

As a corollary, all the software your startup needs (programming languages, frameworks, databases, & editors) is available online as free, open source projects. If you’re an expert in the technology, and it lets you adapt quicker and innovate more than a big corporation could pull off, you’ve can create a better product no matter where you are geographically. As for your actual web app, you should probably write it yourself, not outsource it or hire a contractor.

You don’t need a big team. Have a good idea and a friend to help you? Good, you’ve got your team. You’re filling all the roles of developer, graphic designer, systems administrator, management, and tester. No need for giant developer teams or marketing department. You’ll hire a lawyer and accountant as needed, but otherwise you’re set. It’s also possible to outsource all your support in 4-Hour Workweek fashion, or otherwise, a FAQ on your site probably does an even better job.

Our cost of living is lower. If you’re familiar with Paul Graham’s essay on The Future of Web Startups, you’ll know that he’s already made the argument that all you need to create a startup is a shared space for hackers to hack in, and web hosting. He doesn’t emphasize having a fancy office, but instead starting in an apartment or house where bedrooms become offices and everyone lives together, working day and night towards a common goal of success. The problem of paying for expensive offices is then lowered. The difference is that in California (or New York City), the cost of rent is ridiculous. When success for your startup means just hanging on long enough, usually only a few more months to get profitable or sell out, your cost of living is important. So why pay for crazy-expensive living arrangements in a big Victorian or Brownstone or San Francisco’s apartment prices? (think $1800/month studio apartments) A team, in say Wisconsin, working from their cheap apartment can probably crank out the same kind of work as these startups, for a fraction of the cost. Also, everything else is cheaper out here, including food, so you can eat pretty decent if you’re willing to cook and still stay cheap. Then again, you can still eat only ramen and Redbull if you want to.

You only need an angel investor or two to start, or maybe no funding at all. While VCs (Vulture Capitalists) will probably be unlikely to fly out to see you in farmsville, you don’t need them to start out. As mentioned, startups are really cheap right now. So the amount you’d need from an initial angel investor is very low. And believe it or not, these potential angel investors are all over the place. They don’t all live in fancy mansions in Washington state or whatever. Even if you can’t find one, there’s a good chance you can bootstrap your startup yourself, and then get funding when you’ve already implemented your million dollar idea and can demo to potential investors, or direct interested parties to the working web app by handing them a card with the URL.

With the net, knowledge is hardly geographical. There’s no secret tricks known only to a few elite in Silicon Valley. You can have world class hackers living anywhere and collaborating online as experts in that knowledge domain. The Midwest can compete in expertise with anywhere else. We do have smart and extremely talented hackers living here.

You don’t have to take big risks, like moving across the country for something that might fail. While people just out of college, the typical startup founders, are capable of taking big risks like that, not everyone wants to. Further, it becomes very costly personally if you do end up failing and have to move back to Wisconsin with your tail between your legs. Why not just stay in Wisconsin, see your family on the weekends, and code just as hard as those guys in Silicon Valley?

The Problems:

Obviously, you miss out on the tech community if you’re trying to do a startup in the middle of nowhere. I’m often struck by how close and efficient the ‘web 2.0’ crowd is out in San Fran. For example, watching Leah Culver (of Pownce) give a presentation on OAuth at the office (despite the fact that we already have two startups collaborating in this sentence) last week, I realized that planning for OAuth that didn’t happen over mailing lists or by some big regulatory committee (cough, ICANN/W3C), but by going out to lunch together, stopping by offices, and generally sharing the problems they had and figuring out ways to solve them. You just can’t get that kind of concentrated knowledge and talent out here in Wisconsin, as awesome as our tech community is, there’s just not enough of us to make it work. The community out there is evident when you hear some startup founder twittering about dropping by another startup’s offices to see what they’re doing, or everyone is at the same party / conference / barcamp and the next week they’ve all created something new collectively.

Wisconsin educations are not geared towards creating hackers or entrepreneurs. A common argument for startup hubs is that the colleges there are pumping out lots of very talented kids that are eager to break into the startup scene. The inverse of this is that, in my experience, Computer Science students in Wisconsin are getting the exact same kind of courses, with probably the same level of quality (most likely better, as you’re unlikely to be getting taught by a TA at the smaller UW & private schools). But, I get the feeling when I talk to my CSCI classmates is that maybe they are smart and know ‘about computers,’ but they’re mostly just gamers or whatever that are in CSCI because they wouldn’t mind being tech support at a random company, or wouldn’t mind working on a cube farm for some corporation doing ‘computer stuff.’ They’re not in it because they’re necessarily passionate about programming or math or open source or changing the world. They just want the stable, healthy paycheck from those kinds of jobs. They’re the other 80% of programmers, if they end up programming at all after college. To make a PG-ish generalization: Serious hackers seem to value their time, and in Thoreau-ish fashion aren’t willing to trade it for a paycheck if the work isn’t interesting or fulfilling enough. I should stress that this is my perception the majority of CSCI students I know here in Wisconsin, but I know a few that are shining examples of Midwest geek hackerdom. Until we teach the same sort of attitude and expectations that create Sergey Brins and Joel Spolskys, we’re just making more miserable Office Space drones who are in it for the paycheck and not for passion.

Public transportation sucks (aka, distances increase and people are too spread out). When you’ve got to drive hours to cross state lines to get to a BarCamp or ride the train from Milwaukee into Chicago to catch the Reddit or Google party, you’re less likely to go. So the tech community is less likely to concentrate in one area for any period of time, even an evening. Just as a personal example, Milwaukee has a great professional group for web designers and developers, and their meetings are less than an hour away if I were to drive, but so far I haven’t been able to make it to any of their meetings. I’m even closer to downtown Chicago, but it’s not practical to drive and the train schedule is lousy at best. Even though San Francisco is a big sprawling region, their public transportation, neighborhoods concentrating the tech community, and constant tech events/conferences trumps what we can pull off in the midwest any day.

Time to prove them wrong.

Go out there and make the next big thing. It won’t cost you much, it’s not risky, and you’ll see your friends and the tech community every day on Twitter anyways. Work out of your apartment or on your free time on the weekends. Get cheap entry-level virtual hosting, and see if there’s interest in your idea.

This is sort of my plan, as I find moving out to California currently infeasible. It’s uncertain whether any idea will turn out to be the Next Great American Startup, but on the flip side, you’re just as likely to fail as your counterparts burning through cash in Silicon Valley.

Jogging the Memory with Shoes

29 11 2007


Today, I wanted to share my latest little one-night coding project. But first, a little back story. I’ve been looking for a new Mac OS X GUI text editor for the past couple of days because TextMate has once again passed its free 30 day period for me. I don’t mind editing text purely with keyboard commands in a terminal window, but sometimes it’s nice to have a mouse and menus when you’re working with chunks of code. I’ve read studies from Apple that while using only keyboard shortcuts seems faster, in truth the mouse is quicker at the same task.

On the command line, I’m more likely to use vi than emacs, although I know my way around both. So when I found MacVim, an “experimental” Cocoa interface to vim, I knew I’d found my new editor on the Mac. I’ve already tried all the free editors that worked on Mac OS X in the past, including jEdit (too slow), Eclipse (really an IDE, and even slower), Komodo/Smultron/etc., and even most of the for-pay editors (BBEdit, aforementioned TextMate, and SubEthaEdit). MacVim really takes the cake, as the vim core understands far more languages & markups than TextMate’s bundles; it’s as fast as one can perceive a program to be; and it adds a GUI (gooey!) layer of goodness on top, including tabs, mouse-based copy/paste/cursor positioning, and a full-screen editing mode to eliminate distractions.

I’ve also been playing with Shoes, a framework for making GUI apps in Ruby. Shoes is the brainchild of Ruby super-hacker WhyTheLuckyStiff, and I wouldn’t have heard about it without Phil Crissman‘s twittering about his interest in using it.

The super simple syntax in Shoes lets you lay out GUI components like elements in a web page, and graphics/animations are easily added. Most apps are as simple as: do
     stack :margin => 10 do
          para "Chunky Bacon!"

But the real frustration is in the lack of documentation. There are a handle of sample apps on the project’s SVN web repo and roughly 4 tutorials. The full documentation is currently being printed up as a real-deal book by WhyTheLuckyStiff, and I didn’t feel coughing up the $8+shipping to get a copy. (& knowing Why, I wouldn’t understand anything in it anyways). So, I’ve been playing around and doing a lot of trial and error based on the sample apps to figure out functionality. Luckily, Quicksilver makes the run-test-repeat loop very tight. (For the interested, CMD-Space into QS, type “Shoes” TAB TAB, first three letters of my Shoes’ script’s filename, ENTER & it’s running. Having to launch the .app rather than calling from the CLI is a problem unique to the OSX version of Shoes. On Linux it’d be $ ./shoes App.rb )

My first little app was nothing more than adding file saving and opening functionality to the sample edit.rb script, added color and formatting, buttons, etc. and then modified it to catch a few more commands given via keypress. Nothing too fancy, but it was a good way to figure out the majority of Shoes’ internals. While it was a fun idea to entertain, Shoes is not the ideal platform to develop a text editor in. Luckily, I don’t have to, as I’ve got MacVim.

But maybe I could use a little tool to help me remember all the various vi commands?

Shoes cheatsheet widget

Introducing my cheatsheet widget for vim in Ruby Shoes. It’s based off the heavy cardstock “vi Quick Reference” sheet that everyone in my vi-specific CSCI classes was issued (I imagine there’s an emacs equivalent for classes where emacs is encouraged). Believe it or not, the longest part of creating this app in Shoes was typing in all the command hints off the physical copy & thinking up multiple ways to implement classes containing the data in Ruby. The reinforcement of forgotten vi command skills in developing this widget in MacVim should be obvious.

Using the drop-down allows you to access such diverse topics as:


It really does make a nice little app to have running off to the side, and I’d argue that it was far simpler to create than an Adobe AIR app or Apple Dashboard widget would have been with the same functionality.

Tomorrow, if suitably motivated I may extend it to read in any number of .yml files containing ‘cheat sheet’ definitions, and add definitions from any number of the PDF cheatsheets I’ve accumulated over the years and never bothered to print out (glancing in my PDF dir, I spy PHP, MySQL, sqlite3, microformats, and even, yes, Ruby & Ruby on Rails cheatsheets in there). Using graphics I’ll implement a simple ‘tab’ interface across the top and clean it up so it looks slick. (Red background when you click on the Rails tab? With little Ruby icon hovering there? Yes!)


Coding in Ruby is so much fun, it makes trivial things like this interesting, and Shoes follows in that tradition.

Until next time, happy hacking.

Not dead, just very busy.

21 11 2007

Quick update.

I know I never got beyond the initial Hello World post. It doesn’t make any sense to try and apologize for such a thing, but I thought that it was be best to let anyone who stops by know that I intend to start writing blog posts here at some future point. Unfortunately, things I have to be doing (classes, life in general) tend to be getting in the way of all the things that I want to be doing (coding, jet-setting around to conferences.)

Luckily, it’s probably the first few blog posts that are the hardest. At least that is what I’m led to believe. There are a couple posts in the buffer right now, incomplete, that I’d like to finish and share with you all. Since I’m not exactly jumping on hot news stories (what new Web 2.0 website is everyone talking about this week?) I’ll probably write them either as general technology discussions, or looking at new technologies that you can actually use (current interests include microformats for semantic data, OpenID, & OAuth and how that tech can be used in web apps) and projects I’m working on (of which there are several, but nothing really intended or ready for public consumption.)

Twitter seems to be a pretty good way to handle all my personal communication, so I don’t really see the need to post about what I ate for lunch or who I had lunch with here. In fact, my twitter feed is getting imported on the sidebar of this blog, so you don’t even have to click that link to see what I’m up to.

Stay tuned.