The NYT's Bits section, which up until now I thought was doing a wonderful job of evolving technology reporting to a higher, "post-blog" level, has left me stunned with a bizarre editorial in which the author requests compensation for his contribution to Facebook's success.

Is it just a tongue-in-cheek opinion designed to attract eyeballs and -- yes -- goad bloggers into responding? Probably. But it inadvertently highlights how seriously people are taking the alien business of social networking -- so seriously, in fact, that as usual they appear unable to understand it at all.

Take, for example, this opinion:

“The idea that a business benefits from social interaction is not so strange or new. A lot of cafes and small restaurants will let people hang out because they attract other people,” said Yannis M. Ioannides, a professor of economics at Tufts University. “What is unusual and new is that Facebook takes access to information about these people to make its business more powerful.” He added: “The proprietor of a cafe doesn’t use personal information about me and my friends to make money.”

Really? Cafes don't use your personal information to make money? Find me a cafe that doesn't tailor its menu, prices, inventory, background music, specials, wifi, tables arrangement, etc. etc. based on the interests of its customers. Tell me that Starbucks has never once run a focus group (yes, Internet, there actually was A/B testing before there were computers). My preferred cafes in New York are those where the people behind the counter greet me by name and have my order ready before I have a chance to ask for it.

The difference between Facebook and your average cafe isn't that the experience (and more importantly, the key inventory) is tailored to the customer; it's that Facebook's inventory is virtual (unlimited) and their profit margins are insane. The fact that user-created content draws people in is no different than a cafe hanging paintings by local artists, or people being attracted to busy establishments. The social aspect, as the professor does point out, is not new. And therefore (among other reasons), the op-ed's entire point -- that because the author contributed to the social aspect, he deserves compensation -- is absolutely ridiculous.

It's been a while since we posted one of these, so here's Corning's latest peek at the future, "A Day Made of Glass 2:"

Click here to view the embedded video.

(And here is a narrated version with additional details on what is -- and isn't -- currently possible.)

Mashable has a new standard for fact-checking rumors:

...While you should look at all of this information with a skeptical eye, a raised eyebrow and folded arms, the rumor sounds slightly more credible than the junk typically spewed out from Taiwan industry pub DigiTimes. For starters, reviewing various prototypes before deciding on the final production model is a standard practice in manufacturing, unlike many rumors that imply certainty about what something will look like.

Also, the overall vagueness of the rumor (no precise screen measurement, no photos, nothing about the insides) at least gives an appearance of authenticity. After all, if you were just going to make something up, why not be more detailed? There’s certainly no shortage of potential features to choose from.

To answer that last question: it's because desperate sites will apparently publish it anyway.

(via L)

I remember when the concept of "minimum system requirements" became important. It was during the late 90's, as 3dfx and Nvidia battled to own the nascent market for hardware-accelerated graphics. For the first time, you had software which simply wouldn't run on a computer unless it met certain criteria, namely the ability to perform certain types of linear algebra (though that wasn't part of the marketing, for some reason).

Over the next near-decade, the GPU would become a near-standard piece of equipment, 3dfx would disappear (bought, in fact, by Nvidia), and ATI (now AMD) and later Intel would arrive as new competitors. But the concept of "minimum system requirements" quietly disappeared. The binary outcome (will or won't your system run this software?) was replaced with a spectrum (how well will your system run this software?) as manufacturers found ways to gracefully degrade their products. It's been a while since I came across a product that simply wouldn't run, in one form or another, on a modern computer.

And that's why I was so surprised to discover this evening that "minimum system requirements" are not only back, but they're on the web! I'm not talking about some shadowy site that only a handful of people will stumble upon. I'm talking about one of the most widely-visited properties in the world: Google Maps.

Google announced that its more daring customers may enable an experimental WebGL mode in Google Maps, which allows smooth vector rendering and other visual niceties like 3D buildings with shadows that actually track the local sun. It also appears that Street View fully integrates the 3D data collected along with the imagery, to enhance the illusion of motion.

But this all comes with a catch -- unless your system is packing a modern browser AND a recent GPU, the experimental renderer will refuse to load. I have no problem with the browser requirement. Browsers are free; it astounds me that someone wouldn't run the latest available version of their preferred browser. But the GPU requirement bugs me. First of all, this technology is currently available on mobile phones; let's not pretend it requires significant hardware capabilities. Secondly... it runs on mobile phones. I constantly wonder at the fact that my iPhone is orders of magnitude more powerful than my first computer, but I've never considered for one second that it was more capable than my current machine.

I'm going to choose to believe that the "minimum system requirements" is an artificial gate akin to Google's infamous "beta" tags: a simple way to disclaim any bugs or errors without having to provide full support. What better way to test an experimental rendering engine than having your testers self-select based on a preference for high-end graphics work? I really can't argue with the logic.

In the meantime, I'll sit here and dream about exploring WebGL maps on my MBA. While I wait, maybe I'll play around with the Google Earth browser plugin. It's really kind of incredible: I can fly over a faithfully rendered 3D globe, filled with textured buildings and trees, without ever leaving my browser*, but if I want to see building shadows that update in realtime, I need to buy a new GPU. Something doesn't add up.

*I know, I know, it's a plugin. It doesn't count.

We have a new car and it has an American radio. That wouldn't be a problem except that in Israel, FM stations broadcast on even-numbered spectrum intervals (like 97.8), but American radios can only pick up odd-numbered intervals. And even that wouldn't be a problem if I hadn't grown to really like Israeli radio stations (especially the aforementioned 97.8, "Radio Gimel").

So, the new car has prohibited me from listening to the radio. It's not the end of the world -- after all, I'm a tech geek with an iPhone. If anything, the radio was a digression from my usual habits. The only trouble is -- brace yourself -- the car doesn't have an aux port. There's no way to get sound from the iPhone to the car.

This is bad. Driving a car without music is like writing an analogy without .

The car does have a CD player -- but when was the last time you used a CD to play music? My computer doesn't even know what a CD is, except in the abstract virtual sense that it can access remote drives on the same wireless network that identify themselves as such.

And so we come to the cassette player. Yes, there's a cassette player. And, at wit's end, I acquired a cassette adaptor for my iPhone. I plugged it in, inserted the tape, and was rewarded with a clicking, grinding noise that was almost, but not quite, utterly unlike music. Something was wrong. I took the tape out, looked at it, tried turning the little wheels. I noticed they would only go one way with any ease; rotating them the other direction resulted in the clicking noise. I decided that the tape was jammed, damaged, or both and gave up on the whole project. I was resigned to spending the rest of my car rides in silence.

That all happened one week ago.

One good thing about silent driving: you get an awful lot of thinking done. And so it was that this morning I suddenly remembered that cassette tapes -- those antiquated relics of an analog era -- had two sides. And when you reached the end of one side, you turned it over and listened to the other. Or, if you had a really fancy tape player, you just told the machine to switch sides and it handled the complexities. In The Future, one hoped, the machine would even figure that out on its own! Most importantly, you could tell if you were at the end of a side when the tape refused to advance any further.

I immediately knew: I was at the end of the tape.

I can't easily describe what this revelation felt like. It was such a little, stupid thing, but it provided massive relief. It was exactly the same feeling as solving a difficult data analytics problem -- you turn the issue over and over in your mind, trying to understand how it works and the various causalities it represents, until finally you intuit the system. In this case, the experience was almost archaeological: I had conquered the antique. I had unlocked its mysteries.

I went back to the car. I found the "switch sides" button. And there was much rejoicing.

Via my friend Will Gaybrick (@gaybrick), I discovered an excellent programming tutorial called Eloquent JavaScript. Not only is it extremely well-written, clear and friendly, but it features a completely interactive console allowing readers to run and experiment with every single example. You'll never have to struggle to decipher what a piece of code is doing -- just hit the arrow next to the code block, and it jumps into the console and prints its output.

Obviously, the guide is about JavaScript but the concepts apply almost universally to any language, making this by far the best interactive tutorial I've seen. (That's from a completeness standpoint -- for user-friendliness the hands-down winner is tryruby.org!)

I actually found myself enjoying reading the text despite covering topics I was intimately familiar with, and certainly learned a thing or two in some of the more advanced chapters. I can't recommend this enough for anyone looking for a gentle introduction to programming.

Also, I want to mention that Will will be teaching HackYale, a semester-long course at Yale focused on new web technologies like HTML5, JavaScript and Ruby. Unfortunately, it isn't an open enrollment like Stanford's new AI class, so the rest of us will have to watch enviously from afar.

It really comes as no surprise whatsoever that just weeks after I switched from TextMate to VIM, TextMate 2 has finally broken cover. From a post on the MacroMates blog:

There has been a lot of speculation and trepidation about the future of TextMate recently, mostly about whether there will be another major release. Work on 2.0 began and while we wish it could have been completed faster we are very pleased with how it is turning out. Development has reached a point finally where we can make an announcement:

There will be a public alpha release this year, before Christmas, for registered users.

That's all the information there is, at the moment...

It's amazing what you can see when you refuse to open your eyes -- or need to talk your book. Take, for example, Marc Andreessen's article in the WSJ titled "Why Software is Eating the World." I became skeptical when this line appeared in the introduction:

And, perhaps most telling, you can't have a bubble when people are constantly screaming "Bubble!"

It would seem this is what passes for conventional wisdom in Silicon Valley: utter denial of facts on that grounds that if people recognize them, they can't be true. It's cute, like they're really trying to understand finance but haven't quite got it right. Maybe someone told them that due to efficient markets, if everyone knows something it will be completely priced in. Like anyone with a vested interest, these people have decided that their markets qualify as efficient and so the axiom must hold (or, to the extent that markets are inefficient, it's in such a way that they will profit enormously). Unfortunately, the entire statement represents terrible investment logic, a perversion of the fact that we can not know the magnitude of a bubble except in retrospect. That says nothing about the existance of a bubble. It's critical to remember that we can -- and good investors, by definition, do -- know if there's a bubble before it bursts.

But Marc's statement itself isn't even true. Hardly anyone is screaming "Bubble!" In fact, methinks the technology investors doth protest too much. The most telling sign of all is that the bubble-apologists cry much louder than their accusers! For every journalist who dares write that there is a bubble, two write articles saying that the low current prices of 2011 IPO's prove the opposite.

But onto the real absurdity of the article. Specifically, the very next sentence:

But too much of the debate is still around financial valuation, as opposed to the underlying intrinsic value of the best of Silicon Valley's new companies.

I choked when I read that, having written a post a few weeks ago arguing exactly the opposite. There is no debate about financial valuation of software companies -- they have it. They have way too much of it. On the other hand, what justifies it? Most value investors -- who define holding periods in years, rather than seconds -- regard this industry with skepticism.

Don't worry, though, because Marc provides examples to support his idea.

The first "software company" he mentions is Amazon. This is a confusing choice because it has a P/E of close to 80, and would seem to run counter to his argument that there are "all-time low price/earnings ratios for major public technology companies." Also, it's not a software company. Software services are a growing fraction of their revenue, but Amazon ships physical products to physical people. They have a massive software architecture to support that, and major software projects like the Kindle, but this is not a software company. The recent news that ebook sales are surpassing those of physical books means they are closer to this definition, but still far from it. Not a software company.

Next up: Netflix. Another "software company" that ships physical products to physical people. Yes, they recently rolled out an on-demand service, but its selection remains limited when compared to the physical catalogue. Not a software company.

Next up: music companies. First, Apple's iTunes -- a software product completely devoid of value when not linked to the (only) mobile devices it supports. For all Marc's talk about how Apple is the most valuable company in the world, I wonder if he's thought about how much of that value comes from software. The answer is: very little. His other two examples, Spotify and Pandora, have both failed thus far to show a profit. That hasn't stopped the latter from IPO'ing, however.

Next up: video game companies Rovio and Zynga. No arguments here -- these companies successfully use software platforms to deliver content that people want. Neither of them pushes the state of the art or has any remotely defensible position because their products are commoditzed, but software companies they are.

Next up: Pixar. Pixar makes software, sure, but how can they be a "software company"? Their revenue is solely derived from me getting in my car and walking into a movie theatre. Is Toy Story a software product (not a product of software)? If it is, I have to take back what I said about video game companies, because Marc says that "traditional" game companies like EA are failing -- but their products are as much software as Pixar's if not more, since you don't have to leave home to use them!

Next up: Photography. Marc is really starting to reach here -- he's comparing revenue-lacking software sharing companies to a hundred year old photographic film and paper company (Kodak).

Next up: Local companies. Sorry, now he's stretching. Comparing Google to companies like Groupon and Foursquare, whose accounting practices of "earnings before costs" make them the laughingstock of the investment industry.

We're not done: Skype is next, and Marc uses the $8.5 billion price tag to justify his choice (despite earlier claiming that valuations are at an all time low). No mention that the next best bid was half that. Skype is followed by LinkedIn, another 2011 IPO that has a long way to go before demonstrating real success.

You get the idea. The balance of the article argues that because other physical industries like Wal-Mart and oil/gas use software, they represent the triumph of software over more traditional methods.

No one is arguing that software doesn't make things better, more efficient, cheaper. No one is arguing that software isn't growing tremendously as an integral part of modern corporations. But the bubble apologists continue to ignore the actual state of software. Merely mentioning Groupon, LinkedIn, Pandora, etc. doesn't make them successful -- and yet article after article continues to be written about them completely devoid of justifying arguments. Cloud companies like Salesforce trade at ratios of over five hundred times earnings! 

The companies Marc describes -- at least, the successful ones -- could be best described as software-aided companies, or software-centric companies. Most of his choices exhibit strong selection bias, or rose to prominence in hardware before moving to software. Google -- which he mentions as a competitor of the software companies! -- is one of the only good counterexamples.

So here's  my question: where does the hardware to support all this software come from? I'd like to see that company, because they must be doing unbelievably well. Who knows, maybe the next great "software company" will be an infrastructure firm in disguise. After all, if they have a website, they must be in software!

Despite a recent clean install, my faithful travel companion has pretty much had it. I guess I shouldn't be too surprised, since I dragged it out of deep storage just for this trip, but the good news is I'm upgrading to a shiny new MacBook Air later this week. I'm looking at this as an opportunity to tighten up some of my computing habits, including -- brace yourself -- switching to VIM.

Why? Because it feels like every single day I read another post on how amazing it is, and because Textmate, my trusty workhorse, is getting a little long in the tooth.

With no sign of Textmate 2.0, I have come to the sad realization that it's time to say farewell. This is a tough decision, because Textmate does just about everything I need. It's the most Mac-like editing experience I've ever seen (and that's a very good thing). It handles every type of file I work with, and the bundle system is so powerful that I can write interfaces for those random programs it doesn't work with, like IPython 0.11. Articles like Watts Martin's "Text Editor Intervention" calmly told me that it was ok to stay with Textmate.

And also, it's pretty.

This, I'm almost embarrassed to say, is the number one thing that keeps me attached to Textmate: I like looking at it. There, I said it. Interface is beyond important to me. If I don't enjoy looking at a program, I won't work in it. It's that simple. Say what you will, that's just how it is.

And here's the thing: VIM is ugly. Really ugly.

Most people try VIM and run screaming for the hills the first time they try switching modes and accidentally erase a line. Me, I can't even bring myself to type. What is this abomination of garish colors and contrasty highlights? I know vi dates to the 80's, but come on! 

Anyway, with the new computer on its way -- and it's not easy getting one of those things to Israel, my current location -- I decided to give VIM another shot. Encouraged by the combined experiences of Daniel Fischer and Henrik Nyh, I held my virtual breath and typed brew install macvim. In particular, I really appreciated that Daniel's post began with the following:

"I’m a visual person. The editor that I use must be visually appealing to me, and visually reflect sexy code. This is how I interact with my material, and if it doesn’t look pleasing then I am turned off and cannot be productive. This is one of the reasons why I picked Textmate from the beginning, the themes made the code look really attractive."

(Then, he decides the default icon is ugly and makes his own. I'm not quite that crazy... but I will use his icon.)

When the world failed to end, I began to load the Janus plugin bundle and while that was happening I followed the consensus  advice and fired up the vimtutor. I was pleasantly surprised as I worked through the tutorial -- the black on white colorscheme was acceptable and I could see the appeal of the key commands, even as I struggled to learn them. My initial frustrations ("This is a TEXT EDITOR -- why is it so impossible to EDIT TEXT?") melted into appreciation that maybe there was a better way.

But it's still ugly. I'm working on that, though.

I'll miss Textmate, with the sole exception of undo-ing one character at a time (I mean, really?!). I'll probably keep it around as a general purpose file editor -- I know, I know... but it's going to be a little while before I'm totally fluent in VIM, and I've got things to do! Plus, I did pay for it -- $30 and five years ago, but who's counting?

Anyone out there have some helpful suggestions for a VIM novice?

I decided to clear the cobwebs out of my  MacBook Pro (update 8/20/11: new MacBook Air in hand!) and start fresh with Lion, Python and all the other tools I regularly use (virtualenv, NumPy, SciPy, matplotlib and IPython). It was a lengthy process and I was unable to find a comprehensive walkthrough online, so I had to figure it out through trial and error (mostly error). I was surprised at the lack of available information; with such a major release I expected more complete documentation. So, once again quoting Tom Lehrer, I have a modest example here.

The important things we'll accomplish in this guide are (click any section to jump directly there):

1. A clean install of Mac OS 10.7 Lion
2. Installing Homebrew
3. Installing Python (and pip)
4. Installing virtualenv
5. Installing NumPy, SciPy and matplotlib
6. Installing IPython and the qtconsole

As you may recall, this has been a somewhat more-than-trivial process for Lion's early adopters, as enough was changed behind the scenes to mess up some of the current versions of these tools. I'll detail how to get around those issues by getting cutting-edge distributions. Note that today's cutting-edge works on my machine; tomorrow's may introduce new bugs. When stable Lion-compatible versions of these programs are available, I strongly encourage you to use those instead.

If you would rather skip my commentary, you should be able to simply execute every line of code in sequence.

As always, remember that some of these lines will take you off the beaten path and could cause serious irrevocable damage to your computer! In particular, typing sudo gives you root access and therefore the ability to erase everything with a single keystroke. Please do not execute any code without understanding exactly what it does. In the worst case, I suppose you could always jump back to square one by wiping your hard drive and running a Lion clean install, but use caution nonetheless. YMMV.

Lion Clean Install

To begin, there has been some concern that users can't perform a clean install of Mac OS X 10.7 (Lion) without quite a bit of hacking around with physical media. I'm happy to report that isn't true -- as long as you performed a standard Lion install first. The OSX installer (App Store link) automatically creates a "Recovery HD" partition on your hard drive, just in case something goes wrong. The partition contains just two things: Disk Utility  and the ability to run the Lion installer. To access this recovery mode, hold Command-R while your computer is starting up. Use Disk Utility to erase your hard drive, then run the installer to re-download and load Lion. When you're done, you'll have a clean install of Lion. Download your favorite browser and you're good to go. I have to say, discovering this feature was a pleasant surprise -- hats off to Apple for thinking ahead on this one.

Next, install Xcode 4 -- its bundled compilers have to be available for the next step to work. Here's a link to it in the App Store; it's a free (but large) download. Note that like Lion, the download does not actually install the application. Instead, it puts an "Install Xcode" icon in your applications folder, which you must run to complete the installation. I don't understand this behavior of installing the installer, but it is what it is.

Homebrew

Next up, one of my new favorite tools -- Homebrew. The homepage says it pretty well: "Homebrew is the easiest and most flexible way to install the UNIX tools Apple didn't include with OS X." If you've messed around with MacPorts (or tried to do this sort of stuff  -- gasp -- by yourself), you'll be shocked by the drop-dead simplicity of this tool. Even installing it is a no-brainer; just fire up Terminal and execute the following line:

/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

That's it -- now you have Homebrew. Try running brew update and brew doctor at the command line to make sure it's working properly.

You'll need to add the Homebrew directory to your system path, in order to make sure that Homebrew-installed software is given higher priority than any other version. To do so, open your .bash_profile in your user directory (that's the ~ directory or, more verbosely, /Users/[your_user_name]) and add the following line (if you don't have a .bash_profile, create one with your favorite text editor -- you may need to do this in order to see it, as it will be a hidden file):

export PATH=/usr/local/bin:$PATH

If you haven't already, restart Terminal so it picks up the new path. Homebrew is generally very good about alerting you to any action you need to take after it finishes running, including path modifications. Make sure to pay attention to its output.

Python

Now on to the main event: Python. Let's start by installing some prerequisites (the last one is a prerequisite for IPython, but we might as well get it with the others):

brew install readline sqlite gdbm pkg-config

And now Python itself. As of this writing, 2.7.2 is the most recent version. There are some version-specific references in the following instructions; change them as necessary. The --framework option tells it to build as a Framework, which has some downstream niceties, and --universal builds a universal (32/64 bit) version:

brew install python --framework --universal

This will install a version of disutils, but you must update your path in order to run it properly. Add the following to your .bash_profile (you may combine it with the previous .bash_profile edit, if you choose):

export PATH=/usr/local/share/python:$PATH

Once again, make sure you reload Terminal to update your path variable. Finally, you need to change Lion's symlink to point at your new Python install. Run the following three lines in sequence:

cd /System/Library/Frameworks/Python.framework/Versions
sudo rm Current
ln -s /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current

You will be prompted for your password after executing the sudo command.

To verify that your installation went as planned, type which python at the command line. You should see /usr/local/bin/python in response. Furthermore, if you type python, you should see Python 2.7.2 launch (type quit() to return to Terminal).

You already have easy_install available through Homebrew's version of disutils, but pip, in my opinion, is a much better package manager -- not least because it allows simple uninstalls. To get pip, simply execute:

easy_install pip

Note that depending on your permissions settings, you may have to prepend sudo to the front of many of these lines. Always remember that sudo gives you root access!! Therefore, in the interest of caution, I'm not going to include the sudo command here, but if your installs are failing because of permissions, you may have to add it.

virtualenv

Virtualenv is a tool that allows you to create isolated Python environments, each with its own set of packages and dependencies. This is useful for testing or managing package requirements (for example, if you build an application that is dependent on a certain version of a third-party package but another application requires a more recent version, you may break the first application by upgrading). This is not a required step, and all the commands below should work whether or not you are using virtualenv, so I'm listing it here for convenience only. The only difference will be that directories (such as that returned by which pip) will point to the virtualenv rather than /usr/local.

First, install virtualenv and virtualenvwrapper (a tool which makes working with virtualenv somewhat easier):

pip install virtualenv
pip install virtualenvwrapper

Next, source the virtualenvwrapper script:

source /usr/local/share/python/virtualenvwrapper.sh

This will create a hidden virtualenv directory at ~/.virtualenv. Now you can make your first virtual environment:

mkvirtualenv test1

Your new virtualenv test1 comes with a complete install of Python 2.7.2 and its own version of Pip. It is activated by default, so running any pip command will only impact this environment. Note that if you deactivate the virtualenv, you will lose access to any packages installed in it. You can switch between virtualenvs with the workon command.

In order to delete your test virtualenv, run rmvirtualenv test1. Also, to specify a different version of Python, just use mkvirtualenv -p python3.2 test1 (replacing python3.2 with the shell name of your preferred version).

NumPy

If pip installed properly (executing which pip should return /usr/local/share/python/pip), then you can install NumPy simply with:

pip install numpy

Check your work by executing:

python

followed by:

import numpy
print numpy.__version__
print numpy.__file__
quit()

The version should be 1.6.1 (as of this writing), and the file should be somewhere in /usr/local/Cellar/....

SciPy

SciPy requires a Fortran compiler, which Lion lacks. To acquire one, use Homebrew:

brew install gfortran

As of this writing, the stable version of SciPy (0.9) will not compile properly under Lion. If you try installing SciPy with pip, it will fail. Fortunately, a fix has already been committed to the dev version (0.10) and we can instruct pip to use that version:

pip install -e git+https://github.com/scipy/scipy#egg=scipy-dev

As with NumPy, make sure you have everything working by running:

python

and then:

import scipy
print scipy.__version__
print scipy.__file__
quit()

Technically speaking, it still isn't compiling properly -- but this should run well enough for most work. If you're a stickler for these things, then you can force SciPy to compile using gcc 4.2, rather than Lion's default llvm-gcc 4.2, by reassigning the CC shell variable to the appropriate compiler and building the package. Note that if you want to do this with Homebrew, you'll need to adjust the symlinks to cc, gcc, g++ and c++ in /usr/bin to point at gcc-4.2 (and its variants as appropriate) rather than their current targets, because the Homebrew script calls the symlink rather than the shell variable. I'm going to assume that if you choose to go this route, you also have the know-how to do so, but feel free to email me otherwise. Note that this method isn't necessarily "correct" and I'm not a SciPy developer. Most likely, this will all be handled automatically by the final 0.10 release.

matplotlib

Like SciPy, matplotlib doesn't play nicely with Lion (due to an incompatibility with libpng 1.5). By this point, you know the drill -- just point pip at the patched development version, and check its work when it finishes:

pip install -e git+https://github.com/matplotlib/matplotlib#egg=matplotlib-dev

IPython

Installing IPython itself is a fairly straightforward pip command:

pip install ipython

Getting the new qtconsole to run takes a little more work -- but it's well worth it. The qtconsole is like running IPython on steroids -- my favorite feature is that matplotlib output can be displayed inline.

To begin, you'll need Nokia's qt library, which is available here. Make sure you download the library, not the SDK.

Once that's done, begin installing the prerequisites:

brew install pyqt

Note that after installing pyqt, brew will prompt you to add the following to your pythonpath in .bash_profile:

export PYTHONPATH=/usr/local/lib/python:$PYTHONPATH

Continue installing:

brew install zmq
pip install pyzmq
pip install pygments

And that's it -- you should now be able to launch the qtconsole by executing ipython qtconsole. If you want to see the matplotlib output inline (and why wouldn't you?), then execute:

ipython qtconsole --pylab=inline

Fin.

Phew! I hope this works for everyone out there. Until the next software upgrade, anyway.

Updated 9/1/11 to include virtualenv.

I wrote about how much I loved BMW's Vision EfficientDynamics concept almost 2 years ago. This morning in Frankfurt, BMW took it one step closer to production as the second model in the new electric BMW i sub-brand: the i8. Looking like a hybrid 6/8-series that fell through a portal from 2050, the latest concept shares much of the original's DNA -- making me wonder why it took so long to reach production? The answer, of course, is the electric powertrain. Based on my interpretation, it looks like BMW has successfully implemented the "skateboard" concept that GM has been promising us for almost 10 years. The car should hit 60mph in less than 5 seconds, but only has a range of 35km in all-electric mode. It should be stressed that this is still a concept and the production model (due sometime after 2012) could still vary considerably.

Enough reading. Watch:

Click here to view the embedded video.

(More at Autoblog)

As some of you know, I am and will be travelling abroad for two months. Before I left, I purchased a Spotify subscription and have to say I love it. I won't even waste your time trying to review it -- David Pogue did a great job in today's NYT. I tried to talk myself out of buying it, questioning whether regularly I purchased ten songs a month (the apparant breakeven point for the most expensive subscription), but I now realize that the reason I didn't was simply because I'm cheap, not because I can't find enough songs to keep.

The fact that I'm advocating against an Apple product (iTunes, in this case) should speak volumes in itself.

I also want to share a TED talk about a project I've been following for some time, the SmartBird -- I really like any TED talk that includes an unscripted demonstration. If you'd like, you may draw a connection between the SmartBird's freedom of motion and my own vis a vis digital music. If you'd like.

Click here to view the embedded video.

Old and busted: insightful tech journalism for a general audience

New hotness: attacking brand new (prototype!) technologies that you don't understand

Update: this post is now completely obsolete. I've posted a much more comprehensive guide to installing Python, NumPy, SciPy, matplotlib and IPython on Lion here.

This post is meant as a public service announcement for an extremely small audience. If you don't think this is directed at you, then it almost certainly isn't. I'm happy to say you'll find much more interesting things to read here (I love this site -- it goes great with Instapaper).

Anyway...

I struggled all day to install Scipy on my new Lion machine. I'm running a Homebrew Python and tried using pip to install Scipy, but it turns out that the version of gfortran that Homebrew currently installs causes errors when compiling Scipy (having to do with a nonstandard complex float variable declaration).

Hopefully, in the next few days the kinks will be worked out. In the meantime, by partially following some of the advice on these two pages (one, two), I was able to build Scipy successfully. The crux is installing the latest gfortran build (4.2.4, build 5666), but even after following these instructions I could only get 4.2.1 (build 5664) to run via Homebrew, despite every appearance of 4.2.4 being installed. Ultimately, I gave up on the Homebrew approach and downloaded the 5666 build directly from the AT&T Research R repository. Additionally, I added an explicit complex float declaration to the top of three Scipy files as described in this comment, but because I did that prior to getting 5666 to run, I can't say with certainty whether it was necessary or not. After all that, Scipy compiled successfully.

I hope that this saves someone the hours it took for me to work it out -- but more than that I hope this information is obsolete within days.

Update: Here is a workaround for building Matplotlib in Lion

Speaking of Lion, I've been reading John Siracusa's review over on Ars Technica. Every few years (and lately, every year) John puts out a lengthy review of Apple's latest OS - and by lengthy, I mean you should set aside half an hour to read it. In fact, this year's version is available as a Kindle e-book. Nonetheless, I always find it worth reading if only to ensure my familiarity with every aspect of the new OS. To tell the truth, I usually wait until after I've upgraded to read it.

In any case, his introduction to the Launchpad feature intrigued me for a very different set of reasons. I reprint the beginning here, bold emphasis is mine:

For all its warts, the radical simplification of application management brought to Mac OS X by the Dock really has benefitted the platform. As I wrote in my ten year Mac OS X retrospective, "For every user who continuesto be frustrated by the Dock's limitations, there are thousands of others who are buoyed in their computing efforts by its reassuring simplicity and undemanding design."

But the Dock falls short, especially for novice users, as an application launcher. Or rather, it falls short if the application to be launched isn't actually in the Dock. Most novice users I know want to have every application they are likely to use available in the Dock at all times. As these users gain experience, the Dock can become a very crowded place. But why are these increasingly Mac-savvy users stuffing their Docks to the gills rather than limiting its contents to just the applications they use most frequently?

The answer lies in how applications not in the Dock are located and launched. Choices include the Finder,Spotlight, or (I suppose) a Terminal window. Moving from an always-visible line of colorful icons that's front and center on the screen to any one of those alternatives represents a huge increase in conceptual and mechanical complexity.

If you don't understand how typing the name of an application into a search box can be so much more difficult than clicking an icon in the Dock, I suggest that you have not spent enough time with novice users. Such users often don't even know the name of the application they want—or if they do, they don't know how to spell it. That's before considering the frequent disorientation caused by the rapid-fire search results refinement animation in the Spotlight menu, or the existence of multiple files whose contents or names contain the string being searched for. And this all assumes novices know (or remember) what Spotlight is and how to activate it in the first place.

The jump in complexity from the Dock to the Finder, I think, needs less explanation. As a general rule, novice users just don't understand the file system. They don't understand the hierarchy of machines, devices, and volumes; they don't grasp the concept of the current working directory; they don't know how to identify a file or folder's position within the hierarchy. Fear of the file system practically defines novice users; it is usually the last and biggest hurdle in the journey from timid experimentation to basic technical competence.

I think that last sentence is an interesting observation - is familiarity with the filesystem the digital "coming of age"? Certainly, by the time a user is interacting with the filesystem from the command line they are well beyond the novice stage (in fact, just launching the terminal intentionally is a rather advanced step).

I've been thinking about this for a little while and I don't have a strong opinion. I like the idea as a soft boundary for novice users, but is it a sufficient definition? I can think of some Photoshop wizards who couldn't tell their home directory from a hole in the ground; I'm not sure I'd call them novices, however. The iPhone is a device without a (user-accessible) filesystem; nonetheless, we clearly demarcate novices from power users. However, those users demonstrate their ability to navigate the idiosyncratic (filesystem-analogous?) mazes that the iOS presents. I think I'm coming down in agreement with John - what do you think?