Old Style Fullscreen for Emacs in Homebrew

Emacs in Homebrew used to contain a patch to run in fullscreen on OS X.  When OS X Lion introduced a new fullscreen mode, Emacs upstream added support for said mode and Homebrew removed their patch.

However, until Mavericks, OS X’s fullscreen mode was rather unusable for multi-head setups, which I often use for development.  Even with Mavericks, I personally still find the native fullscreen mode somewhat annoying — specifically I frequently ?-tab between windows and am not fond of having to wait for the animation to drop things into place.

Mostly due to this frustration, I kept using an older version of Emacs up until a couple weeks ago.  However, Hemant Kumar’s recent excellent article on using Emacs for Rails development motivated me to update my Emacs to the most recent stable version and do a much needed cleanup to the cruft that I’ve been collecting around in my ~/.emacs.d for the last 15 years.

So, after a bit of Googling I realized that a non-native fullscreen mode has been added to Emacs’ Bazaar repository.  I’d rather not run Emacs from the development branch (on the day that I tried it had frequent problems with freezing whilst taking 100% CPU), so I ported the patches back to the current Emacs stable release (24.3).  The patch is here.

The good folks of Homebrew accepted my pull request, so now for all of us wishing for the older, non-native fullscreen mode, after building from current Homebrew, you just add the following to your init.el:

(setq ns-use-native-fullscreen nil)

The little fullscreen icon in the upper right goes away and you can now go into fullscreen mode by pushing F11.

Enjoy!

Read More

Bypassing ActiveResource objects in a MySQL query

So, over at Directed Edge we were having problems with some new goodies we’re working on that are trying to pull data out of a MySQL database and do some analysis on them in Ruby.

There seemed to be a few options:

  • Do the data analysis directly in SQL. SQL would have been sufficient for our needs, but it’s a bit cumbersome. After futzing with a couple of our critical analysis runs and trying to shoehorn them into SQL, after about an hour of trying (and getting close) it made it clear that we’d be stuck with SQL gymnastics for each and every analysis we needed to run.
  • Don’t do the analysis in Ruby at all. Write a simple plugin interface to drop down to C or C++ to do the analysis there.
  • Figure out the hottest part of the queries and see if we could get most of the benefit for the least amount of effort. Bonus points for being minimally invasive.

The last of those ended up being a working strategy, and surprisingly non-invasive.

We’re often pulling hundreds of thousands of rows across the ActiveRecord border, and doing that was dog slow. Most of the time was in ActiveRecord creating an object for each and every record. Working around that object creation turned out to be pretty easy. This is all the code that was needed:

module ActiveRecord
  module Structs
    def structs(&row_handler)
      results = connection.raw_connection.query(to_sql, :as => :array)
      klass = value_class(results.fields)
      results.each { |row| row_handler.call(klass.new(row)) }
    end

    private

    def value_class(fields)
      i = -1
      name = fields.map { |f| f.to_s.classify }.join + 'Values'
      constructor = 'def initialize(values) ; @values = values ; end'
      accessors = fields.map do |f|
        "def #{f} ; @values[#{i += 1}] ; end"
      end.join(" ; ")
      eval("class #{name} ; #{constructor} ; #{accessors} ; end ; #{name}")
    end
  end
end

What that does is drop down to the raw MySQL connection, which returns an array of values, and uses eval() to create a special purpose class with accessors in the same places as the ActiveRecord object would have. Since those methods are not dynamically invoked, they’re a good bit faster. Also since the object initialization is just one single reference copy (to the array of values), it’s pretty fast too.

All of the code that we had to change in the classes that were using those queries was from:

Foo.select(:bar, :baz).each { |f| ... }

To:

Foo.select(:bar, :baz).structs { |f| ... }

Using eval() in that way is a bit nasty, but for the 4x performance boost, and minimal invasiveness, we’ll take it!

Read More

Why Rails extensions always suggest putting extensions in the model:

Or, “Why using send doesn’t work as exptected”

So, I’ve been banging away at a Rails plugin the last few days.  One of the things that I initially did was to add an initializer that extended the models from the app to avoid needing to muck-up the model, e.g.:

[project root]/config/initializers/acts_as_foo.rb
SomeModel.send(:acts_as_foo, :bar)

It seemed so clean and elegant. But I noticed that my class variables were being trashed when I tried to access them and was befuddled for a day or so.

It turns out what happens is that Rails reloads all of your models (and, in fact, all classes) for every request while in debug mode. At some level in my brain I knew that, but it didn’t click that when that happens initializers aren’t fired as well, so anything that’s being fired from an initializer that will be trashed on reload won’t be there after the first request. (Though it works in production mode.)

Eventually, after much debugging, it clicked what was happening. But I wasn’t quite content to just burden plugin users by modifying each model. I stumbled across this StackOverflow entry which suggested you could achieve the same by modifying environment.rb’s config block. But really, that just shifted the inelegance around. However, the to_prepare bit set me along the right path.

The elegant solution that I eventually found comes from using the dispatcher:

require 'dispatcher'
Dispatcher.to_prepare do
  SomeMode.send(:acts_as_foo, :bar)
end

And there friends we have it: a way to send something to a model from an initializer that will be reloaded every time classes are loaded, or only once during production mode, and every request in development mode.

Read More

Localghost 1.0 Released

I’d been looking for an excuse to create a Cocoa app for a while. Even though I still switch hit between Ubuntu and OS X, I spend most of my time on OS X these days. I’d gotten Cocoa Programming for Mac OS X a while back, but had been missing that real-but-simple app idea to give it a whirl on. Until Localghost.

You see, I edit my /etc/hosts litearlly a dozen+ times a day when I want to test things in their production configuration, but with my development version. Localghost adds / removes a set of selected hosts from /etc/hosts with a system tray applet. There’s more info here:

Localghost page.

Read More

Gitfeed, Git to RSS and the growing collection of small hacks

I’ve finally succumbed to the Github bug and have been slowly offloading small projects that I’ve created mostly for work stuff. The latest of these is a relatively small hack to produce an RSS fit from a Git repository, which I’d wanted to have posted in our intranet.

Usage is simple and includes a command line thinger so that uses sinatra, so you can get it all in one go.  The source and docs are here.

Additonal hacks that have now been thrown into the wild:

  • fooq — a little wrapper around GCC that lets you write C / C++ one-liners or small script like thingers, and automatically includes and links Qt, without having to futz about with a make file or a main function, etc.
  • QActiveResource — a hack for work since we make heavy usage of ActiveResource to pull data. This one’s a lot faster than ActiveResource for reading data — basically a C++ implementation of the find method. Details in the company blog, or naturally on Github.
  • ShoParTender — Greasemonkey script to make the Shopify partners panel less unweildy. Details in the Shopify developers forum.
  • Chuckery — A bunch of my utility classes and my preprocessor for the ChucK audio synthesis language. Finally got around to converting this old CVS repo to git.
  • Quebec — A graphical (Qt) frontend to the standard command line calculator, bc. Includes history copy-paste and all that jazz.

I’ve realized that slowly I’m becoming a Ruby-ist. I still feel mediocre at the language, but more and more I’m finding it my go-to language for quick hacks. Drinking the Github Kool-Aid just brings me one step closer to the fold.

Read More

Getting started starting up.

There’s one funny bit in the history of starting up Directed Edge: I have no idea when I decided to do it. I don’t really know when the idea first crept into my head seriously to start a company. I did a little reconnaissance on my e-mail and file archives and put together some of the critical moments:

  • October 25th, 2005: Mailed Paul Graham asking about books on startups
  • July 1st, 2006: Moved from working at the SAP LinuxLab in Walldorf, Germany to Native Instruments in Berlin
  • January 29th, 2008: Ordered “Competitive Strategy” and “Harvard Business Review on Entrepreneurship”
  • February 5th, 2008: Joined Hacker News
  • February 19th, 2008: Ordered “Founders at Work” and “Fundamentals of Database Systems”
  • February 28th, 2008: Last edit to list of 31 possible startup ideas
  • February 29th, 2008: Asked Valentin if he’d like to co-found
  • April 3rd, 2008: Notified boss at Native Instruments that I’d be leaving at the end of June
  • April 16th, 2008: Ordered “Art of the Start”
  • April 23rd, 2008: Went to first local founders event (Business & Beer)
  • March 4th, 2008: Started our intranet wiki to begin organizing thoughts
  • March 8th, 2008: Registered directededge.com
  • March 13th, 2008: Sent mail to LUG where I’d gone to college asking if any other alums had founded companies
  • March 13th, 2008: Got German permanent residence (meaning I didn’t need a normal job to continue living here)
  • May 23rd, 2008: Went to TechCrunch Meetup Prague
  • June 11th, 2008: Went to TechCrunch Meetup Berlin
  • June 20th, 2008: Attended Mini-Seedcamp Berlin with Valentin
  • June 27th, 2008: Full-time on Directed Edge

It was a little surprising to me that I’d apparently thought over starting a startup as early as 2005.  That was, notably, only a few months before I quit at SAP, and getting the itch to move on was presumably the trigger. That went into remission once I was settled in Berlin and working for Native Instruments.  I don’t remember when, exactly, I started entertaining the idea seriously. Certainly for most of my time at Native Instruments, I was not. It would appear that circa January 2008, with the prospect of German permanent residence at hand, that I began the motions of learning more about what it would take.

It’s also hard to self-evaluate and say if I moved slowly or quickly — obviously I’d been toying with the idea for 3 years by the time I went full-time, but from starting real research to giving notice at work was only two months.

Having done the research, I thought I’d make it here, both to preserve it for memory-lane and on the odd chance that it’s interesting for anyone else.

Read More

What I Hate About Booking Travel Online

I’ve traveled a good bit in my day; I’ve been to some 20-odd countries, 4 continents, you know, the works.  And if there’s one thing that I hate more than airports, it’s booking travel online.

The problem is this:  my goal is not to book flights at specific airlines, at specific airports, with specific ticket classes — it’s to book a trip.  Trips have different goals.  For example:

“I want to visit Albany and New York City next week.  I have to be in Albany on these days; NYC is flexible.”

or

“I want to go to central London next week, and need to be there for at least 3 days.”

I don’t care about the details.  I want to know:

  • What are the options?
  • How much do they cost?
  • How long do they take?

I don’t want to have to know that Airport X is actually 30 miles from London, so I’m going to have to get a bus that costs me another £30 and takes an hour.  That should be worked into the equation.  I don’t care that renting cars is twice as expensive in Manhatten as it is upstate.  If it turns out that a high-speed train is almost as fast as a plane, I want to know that.

See, travel sites create the illusion of providing the information that I cite above, which is what makes them so infuriating.  In practice, it almost invariably takes me several hours of looking at options just to figure out how I effectively can get from point A to point B, and what the costs and logistics involved will be.

In my dream world:

Here’s how it works in my dream world:  I pick two places on a map, just like I do on Google Maps, and I get back options for how to get from point A to point B, with all variable covered.  I get nearly exact amounts of time, total costs and when I can get started.  I can chose to optimize for speed, comfort or price.

Read More

Only 6 of the 20 largest software companies are in Silicon Valley

So after Fred’s post caused a little bit of a stir in the blogosphere by downplaying some of the advantages for startups being in Silicon Valley, and being from a Berlin-based startup that’s out exploring the Silicon Valley vibe this month it set me to wondering — just where have most of the “great” software companies been started?

Forbes has a list of the 2000 largest public companies, so I went through and picked out the top 20 and noted their locations.  Here’s the list:

  1. IBM, New York
  2. Microsoft, Washington
  3. Oracle, California
  4. Google, California
  5. Softbank, Japan
  6. SAP, Germany
  7. Accenture, Bermuda
  8. Computer Sciences Corporation, Virginia
  9. Yahoo, California
  10. Capgemini, France
  11. Computer Associates, New York
  12. Tata Consultancy Services, India
  13. Infosys Technologies, India
  14. Fiserv, Wisconson
  15. Wipro, India
  16. Symantec, California
  17. Adobe Systems, California
  18. Affiliated Computer Services, Texas
  19. Activision Blizzard, California (non-Valley)
  20. Intuit, California

Notably, 7 are based in California (all but one in the Bay Area).  On the one hand, it certainly is far and away ahead of any other location (Bangalore, interestingly, being its closest competitor); on the other it shows a wider distribution of companies than one might assume.  I’ll leave further conclusions as an exercise for the reader.

Update:

I realized after publishing this that I’d used the 2007 numbers rather than those from 2009.  The number of companies in Silicon Valley remained the same.

2007 Numbers:

1. IBM, New York
2. Microsoft, Washington
3. Oracle, California
4. Google, California
5. SAP, Germany
6. First Data, Colorado
7. Electronic Data Systems, Texas
8. Softbank, Japan
9. Yahoo, California
10. Symantec, California
11. Computer Sciences Corporation, Virginia
12. Capgemini, France
13. Tata Consultancy Services, India
14. Fiserv, Wisconson
15. Adobe Systems, California
16. Infosys Technologies, India
17. Computer Associates, New York
18. Wipro, India
19. Affiliated Computer Services, Texas
20. VeriSign, California
  1. IBM, New York
  2. Microsoft, Washington
  3. Oracle, California
  4. Google, California
  5. SAP, Germany
  6. First Data, Colorado
  7. Electronic Data Systems, Texas
  8. Softbank, Japan
  9. Yahoo, California
  10. Symantec, California
  11. Computer Sciences Corporation, Virginia
  12. Capgemini, France
  13. Tata Consultancy Services, India
  14. Fiserv, Wisconson
  15. Adobe Systems, California
  16. Infosys Technologies, India
  17. Computer Associates, New York
  18. Wipro, India
  19. Affiliated Computer Services, Texas
  20. VeriSign, California

Read More