diego's weblog

As we wait with baited breath for the next move in the Microsoft/Yahoo saga, Marc just posted a must-read entry on what happens if microsoft goes fully hostile. Meanwhile techcrunch has some speculation.

Another interesting question is what exactly is Microsoft buying with this, given that many people would leave, many have already left, and there's nearly complete overlap on their technologies and products (see here) and in most cases full integration (rather than an orderly migration) would be a nightmare that anyone in their right mind would avoid. The easiest would be to just point yahoo.com to live.com, automatically migrate accounts, and you're done. Well, of course, not really, but you get what I'm saying.

If so, this would be the most expensive domain name acquisition ever. Business.com for $7.5 million during the bubble? Peanuts, I say. :)

An interesting interview with Professor Donald Knuth (via slashdot, where the slashdotter writes: "[Knuth] pitches his idea of "literate programming" which I must admit I've never heard of but find it intriguing" -- really never "heard" of that? I think it was one of the first things in programming I "heard" of... anyway...). Some interesting comments about various topics, including TeX, which continues to be nearly irreplaceable in some areas (academic papers in particular), but then drops a bomb:

I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and that they're trying to pass the blame for the future demise of Moore's Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won't be surprised at all if the whole multithreading idea turns out to be a flop, worse than the "Titanium" approach that was supposed to be so terrific--until it turned out that the wished-for compilers were basically impossible to write.

Let me put it this way: During the past 50 years, I've written well over a thousand programs, many of which have substantial size. I can't think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. Surely, for example, multiple processors are no help to TeX.

How many programmers do you know who are enthusiastic about these promised machines of the future? I hear almost nothing but grief from software people, although the hardware folks in our department assure me that I'm wrong.

I know that important applications for parallelism exist--rendering graphics, breaking codes, scanning images, simulating physical and biological processes, etc. But all these applications require dedicated code and special-purpose

Second, his statement

Surely, for example, multiple processors are no help to TeX.

"I hear almost nothing but grief from software people," Knuth says, but this is just because we haven't yet found clean, effective methods to write, test and debug multithreaded software at large scale. This doesn't mean it's bad, it just means we haven't figured out how to use it properly. And, worst case scenario, you can always write your software as services connected through a thin layer of communication (based on anything from IPC to RMI to REST) that can then run as multiple processes happily on a multicore machine.

He also rues that literate programming hasn't been embraced by the millions, but this is also only partly true. Java and other languages have been using Literate Programming concepts for years, and it has been a major advantage in productivity when using good IDEs like IDEA, Netbeans, or Eclipse.

Not that this invalidates anything that Knuth has done. :) The TeXbook and the Art of of Computer Programming are still gems that I end up perusing frequently. They may not be multicore-enabled, but they're still as relevant as ever.

Alexa just changed their ranking system, Techcrunch has details. (The Alexa page, in typical clueless fashion, is not a permalink, so I won't bother linking to it). This is good news, but it still doesn't fix the problem. Why?

Alexa, Compete, Quantcast, Comscore, all have measures of "Rankings" or "Popularity" that put sites relative to others. These rankings, in general are a more-or-less accurate relative description of how a site is doing.

The keyword here, though, is relative, and, more specifically, relative to how the service in question measures other sites. Comparing a Quantcast ranking to a Compete ranking to an Alexa ranking for any given site is useless, and no one even attempts that.

Rankings for each site are widely understood to be relative within its own index, and no one has a problem with that. So far so good.

The real problem start when we put their measures of Visitors (Alexa calls that "Reach" as far as I know) and Visits. So some news publication may take a comscore measurement and say "such and such a site has 1,000,000 visits", inevitably prompting discussion of whether it's true or not and (generally) silent fuming on the part of the site that sees in their logs, every day, different data.

This is the problem. The use of a heavily overloaded term like "Visitors" or "Visits" or "Pageviews" or even "Reach" causes the confusion. None of these sites claim that they have the ultimate truth at their disposal, but by using common terms, this is exactly what happens. After all, everyone knows what a 'Visitor' is, right? Well, maybe. Maybe everyone does know what a Visitor or a Visit is, but no one agrees on the definition.

Even if everyone did agree on the definition, you could still lose data unless you're looking at the logfiles for a service. Why? Several reasons, but the three key ones are:

1. The services extrapolate traffic based on measures they choose. Try a site that has low traffic, and the services give up. "Not enough data." Yep.
2. Not only that, the services extrapolate based on previously filtered data. The raw log data for a year for any of the top 1,000 sites can be counted in the petabytes, if not exabytes. None of these services have enough compute power or storage at their disposal to process that, clearly. So they are pre-filtering information, which is then extrapolated. The prefiltering presumably eliminates bots. What if a new bot shows up? How do they count it?
3. Domain mapping. Consider Ning. Suppose we agreed on what a pageview or a visit is. Would Alexa or Compete get the right numbers? No. Because they key on domains to define what is traffic to a service. In our case (as in many others) the service allows you to do domain mapping of your site, which means the services think that the traffic is going somewhere else, even though it's going to Ning. That's why I can assert without hesitation that the visits/visitors traffic reported by these services doesn't cover a good portion of the traffic Ning handles, and when on top of that you add uncertainty as to what is a visit, and what is a visitor (is it an IP? a cookie? A combination? What about internet cafes? and so on), then the actual absolute value for those things is pretty much meaningless.

Now, what the services do track correctly in a lot of cases is trends, especially over several months (again, in the case of Ning the fact that they miss domain-mapped networks is a big problem, but the data we have for non-domain mapped networks shows similar, and I say again, similar shapes and trajectories).

My take is that if these services stopped calling what they measure "visits" or "visitors" and just said these were some sort of generic "[servicename] traffic measure" or something, then they would get a lot more respect, something they deserve since they do provide a valuable service, and they should get credit for that.

Nothing like some breaking news to awake you from a blog slumber. Russ announced on his blog the end of Mowser.

Sad news, and I sympathize. Russ and Mike are buddies so I've followed the travails of Mowser closer than, well, almost anybody, so this also is a bit more personal for me. I've been there. My previous startup, clevercactus, also ran out of money after having put everything I had into it, and I experienced something similar (although a bit less drastic) in terms of financial impact. A lot of us are used to abundance and generally have absolutely no idea how stressful it is (to put it mildly) to have to choose what food to buy to avoid breaking the bank.

The good news in all this is that failure is a HUGE learning opportunity, something that isn't said enough. Throughout the process you're consumed by trying to make it work, but once it's done you can look back and find a lot of things to do differently in the future. Yes, in the future -- I don't believe that you can really say that you'd 'do things differently' since generally we make the best decisions we can with the information we have available at the time. Additionally, the next step (after a period of recovery) after having put everything into something that didn't work can actually be very refreshing and lead to amazing opportunities, like it did with me.

There is also some solace to be found in the online response. When you work with a team of a few people or more you can help each other, but when you work on your own or with a partner it's a harder situation, and the online response helps a lot. In the case of mowser, it's been at the top of techmeme for a while now and it's been covered and discussed all over the place, in part because of Russ' statement that 'the mobile web is dead.' (More on that later), but also due to comments of support.

As for Mowser, it's online for the time being and as Mike says they're looking to sell the site or code, which is in my mind a very possible outcome. It would be cool to see it live on in some form.

You wanted to hire Mike, didn't you? Well, too late! He's joined Mowser. Awesome! Btw, I took that picture. I demand royalties. Royalties, I say! Ok, maybe I didn't take the picture but I take credit anyway since it's in my house. :)

In celebration of this momentous occasion, I've added a link to the Mowser-powered mobile version of my blog to the left column. And there was much rejoicing.

Paraphrasing Kent Brockman: I, for one, welcome our new mobile overlords.

Mike is leaving AdMob, which means he's looking for the next cool mobile thing to do. Emphasis on cool. And mobile. In both cases, he knows what he's talking about. Just call him up. But hurry, there's only one of him! :-)

Okay, after some more time with the device, here's a few more thoughts (Prompted by Kyle, who started asking questions on IM. So it's really his fault :)). Again, in no particular order...

• The navigation buttons are really really well positioned. It's very natural to use one side or the other to navigate forward and back, even if when you first look at it (and even when you first use it) you think "this ain't gonna work." It does work. Very cool
• Newspapers are not good for the Kindle yet. Three big problems:
  1. Each day's edition shows up as a new "Book" in the main tab, which sounds great at first, but after the first week half the screen is New York Times editions. Then you have to go into the content manager and start deleting... not great. They should automatically go away, otherwise it's a pain.
  2. Another problem (less worrisome than the other one) is that with a lot of small articles you have to use the navigation more, which is less than ideal--and there's a dearth of pictures, which makes the newspaper be a little less interesting.
  3. Finally, the updates. It gets updated with the actual contents of the printed edition. At the beginning of the day. After that, no more updates. Come on! What's the point of the always-on EVDO if you don't get daily updates for the newspapers? Newspapers are real-time these days. This bad mix of digital and meatspace is not great.
  So, the newspaper subscription is not going to work, I may try it again in the future. On the plus side, you get a 14-day trial, so I can cancel it without harm done to my bank account. :)
• Magazines. Two types here: image-heavy, like Time, which don't really work given the screen and the fact that, well, there are almost no images in the "Kindle edition", and those like The Atlantic which have long articles and few images, which are perfect for the device. The Economist (if it was available) would be another great choice methinks.
• Blogs. No, I didn't even try subscribing to a blog. I will though, just to see what the UI is, but I'm not paying $2 a month to read rants. Sorry. 20 cents a month? Maybe. $2 is too much.
• Power. A final interesting point is that I normally, as I do with the Sony reader, I'd leave this on all the time, since the screen draws no power. However, Amazon has decided to put in a screensaver on the thing, so if you leave it on it does suck the amps, few as they may be. I suppose that it's inevitable given the always-on wireless, but a screensaver? Probably one of those things where you have to pretend that you have a screensaver to avoid support calls from people worried that the display would be "burned" with the current image (not possible with eInk). Anyway. As a result of the screensaver I find myself turning it on and off, which is a bit unnecessary. I haven't charged it in a week, and it still has about half the charge :).

• The display is clearly better than the one on the Sony Reader PRS-500 (first gen): faster refresh, better contrast. I imagine it is on par with that of the PRS-505.
• The navigation metaphor is really interesting, and quite unique. There's this metallic-looking strip on the side that identifies lines/paragraphs/sections (depending on context) and that provides visual feedback of operations that take time. In particular, it seems to draw the eye's attention while the page is "flipping" which as I mentioned before is slightly distracting at first (but then is not noticeable). The strip is probably quartz-based (like the liquid crystal in digital watches) since it updates too fast to be an eink variant.
• Specifically, the navigation metaphor mixes the physical with the virtual in a strange, but appealing way. There's the idea of "moving" this almost physical marker (in the form of the metallic strip) to select what you want and then click or press enter to "activate" it depending on context. This is in contrast to the navigation Sony did in their reader, which uses the ink itself to mark selection and is clunky and slow. I don't know yet if the Kindle's navigation is genius or folly yet, but it's definitely original, and it's worked well so far.
• The purchase system is so simple, it's evil. :) Just click, click, and you're done. The book is there in seconds and you've spent the money (they do have a link in the final page that lets you back out of the transaction if you want, which is great). Between this, the auto-configuration (the device came pre-configured with my account out of the box) and wireless connectivity included and working out of the box, Kindle sets a new bar for out-of-the-box experience, even going beyond iPod (and I don't say that lightly). Great job guys!
• Speaking of out-of-the-box experience -- Mike was wondering what happens if you buy the device for someone else. Well, by default it's tied to your account, but as soon as you buy it you get access to a page that lets you "unlink" the device and then you'd have to "link it" to the other Amazon account (not sure if "linking" and "unlinking" are the terms Amazon uses, I don't think so :)).
• Also cool is that you can link more than one Kindle to a single Amazon account, in effect sharing books across them, say for the whole family.
• Web navigation is decent, if limited. Russ came over and we geeked out with the device for a bit, looking at the user agent (Mozilla-Compatible, NetFront) and other headers it was sending. Amazon is proxying the content, which isn't a surprise. Net access is fairly fast (and free!), and Mowser works great on it! Faster even though in effect it's going through two proxies (Amazon, then Mowser).
• In Default Mode, the browser ignores CSS/styles, and it behaves more like a limited-capabilities mobile browser. But turning on Advanced Mode enables them. Oh, and you can turn on Javascript support too! (off by default).
• Emailing content in works really well: just send an email to your chosen email address for the kindle with an attachment that is the document/images you want to send, and after a few minutes it shows up in the device. It's also available, properly transcoded, in your Amazon online library. Really well done. There's a $0.10 (10 cent) charge to do that, but you can also do the transcoding for free and upload the file manually through USB.
• USB mode is simple: just plug it in, and it shows up as a disk, disabling any other functions in the device. You can dump PRC, MOBI, TXT, and Amazon's own AZW files (whatever those are). As a quick test I downloaded the PRC version of Cory Doctorow's "Down and Out in the Magic Kingdom" put it in the documents folder, and presto, there it was.
• You can also download the AZW files from Amazon's digital library to your PC and then manage them from there, adding them/removing them to the device through USB. Very interesting. Amazon is acting as a sort of automatic backup, but in theory you could do away with Amazon completely.
• Oh, and yeah, some of the navigation keys in the border tend to be pressed a bit too often by mistake. Probably something I'll snap out of, but if it was me, I'd make them not go all the way out to the edge, which exposes them more.

Lightning Quick Impressions

• The Packaging is cool, very Apple-like. It's like a book! Nicely done.
• The device has charge out of the box. Boot it up, and it already knows my name. Yes, some corner of my mind says that there's privacy concerns in there somewhere, but there's something incredibly cool about opening a box, turning on a device and having it know who you are. I'm sure I'll recover and think it's creepy later. Or maybe not.
• Flip pages. There's seemingly two dozen "next" and "previous" buttons and ways of navigating. I wonder if I'll be hitting them by mistake all the time. That's definitely very much not like Apple.
• A couple of excerpts and the NYT, which I had configured yesterday, are already in the device, synced. Nice.
• Finally, I go to the "Experimental" menu (the menu bar selector is weird, but cool!) and choose Basic Web Browser. Enter my blog's address. It loads it. Holy moly. Fast. No configuration. Nothing. I have to collect my jaw from the floor. There's something to be said for seamless, and this rivals apple.

More later after I play with it some more! In the meantime, check out the unboxing photos in a slideshow, including the browser pointed at this blog -- powered by a Ning Network i just created. :)

Dave comments a bit on OpenSocial, and mentions his concern about Google keeping data locked up. Marc Canter points out (correctly) that user account data would remain on each social network ('container') that implements opensocial.

I'd go a bit further to point out that very little about this announcement is about open data or not open data. I happen to agree with Dave (and Marc) that data should be open. Just to be clear, I'm not just saying this: at Ning, we've been open on that front (if not great about documenting it fully :)) from day one. Today, you can easily cook up a script to take your personal data and take it with you, re-analyze it, do whatever you want. It's your data after all. Part of the reason we could implement OpenSocial support so quickly is due to the fact that Ning is at the core a very large set of XML/JSON APIs -- the benefits of being open are not always obvious, but this is definitely one of them.

I think Dave was focused on the Data aspects because prior (incorrect) rumors about this announcement implied that Google was going to announce something to gather data from multiple social networks.

But I digress. What I wanted to add to the conversation was that Dave put a quote in there that struck me for how well it applies to OpenSocial.

Quote:

How much happier we would be if instead of crippling each other with fear, we competed to empower each others' creativity.

OpenSocial is much less about Google v. Facebook than the announcement makes it seem. Everyone focuses on the Facebook angle, but if Google just wanted to take on Facebook, they could have done that, no? Is the Facebook thing a factor? Sure. But instead of joining a Google v. Facebook API deathmatch, Google chose to create and gather support for a set of standards that benefit everyone. They have done a great job of catalyzing the effort and getting it going, but this is now bigger than just one company announcing some APIs.

The main reason this is true: market forces.

As I said in my previous post -- no doubt there will be extensions, but the nature of this market is such that if you deviate too much developers won't support your platform. Developers in this market (iLike, Flixster, RockYou, Slide) have little if any direct ties to the container providers (Ning, Orkut, LinkedIn, Facebook), so developers really have the power to maintain things sane, since they will certainly optimize to make as few changes as possible and maximize exposure of their apps. It's been a while since a wholly new, truly competitive market where the users have a lot of "say" in the distribution (which generally happens across notifications and Activity streams) has emerged.

It's one of those rare 'rising tide lifts all boats' situation. For developers, service providers, and, more importantly, users, who get more choice in terms of what site they use, without having to sacrifice on features.

And I think it's great news. :)

It's all over the wire: the NY Times and Techcrunch first, quickly followed by Om and many others have posted about the announcement that we at Ning were going to make with Google and other providers on Thursday of a new set of APIs that will be supported across all services to enable social applications.

One of the things that is really significant about this is that it's not vaporware. While the announcement doesn't mean immediate availability, we do have, right now applications running on multiple test environments. What is also significant is that we're not inventing a new markup language or things of the sort: it's all standard XML, HTML, and Javascript. This is the key to bringing a high level of portability, which we will have right out of the gate.

For example, we have a great Flixster app that we will show, which runs on both Ning and Orkut, as well as others, unchanged. This is huge.

Let me say that again: as opposed to what some reports are suggesting (Mashable mentions some of these concerns for example), these apps can run unchanged or with fairly minor changes (if you've gone "off-road" from the base calls) in most if not all the supported containers. Will they all be able to run unchanged? Probably not, but it's possible and certainly something that we should all strive for.

At Ning we are committed to supporting as much cross-service behavior as possible.

Given what the APIs are, and that it will be straightforward to add support for them, I expect we'll see lots of sites getting behind this effort. Marc Canter just said that they will support OpenSocial as well and on a related point I agree with him: we need to make these APIs deeper.

Additionally, we should make an effort to make the APIs cleanly extensible and provide a mechanism to allow the extensions to become part of the standard. I mean, it's obvious that there will be *some* extensions, and it's also obvious that some of them will have wide applicability. And when they do, it's going to be great if everyone that wants to can jump on board.

There's still lots of details to work out, but this is very exciting. I'll post more after the formal announcement on Thursday.

PS: for the record, regarding the New York Times headline of people "gang[ing] up" on Facebook, I can say that I've never heard anything even remotely approaching that sentiment. I would certainly welcome Facebook's support for OpenSocial, and I imagine many others would, too. What Facebook has done is great -- this is going to be even better!

Here's a question I've heard a couple of times recently: how committed is Ning to the platform idea?

It's question that emerges from our need to focus right now, as a company, on building out the social network application on Ning and empowering Network Creators from the top-down, through simple but powerful tools, to customize and evolve their networks.

Given our limited resources, this creates sometimes the external impression that we're not paying much attention to Ning as a platform, or to the evolution of our APIs, or the support of them, but nothing could be further from the truth.

Without the platform, there is no Social Network application. Allow me to explain.

When you create a network on Ning today, you get to add features, customize its appearance, change profile questions, privacy options, and more, all through a straightforward drag-and-drop user interface.

Hidden in this process is the fact that the network itself, and every feature in it, uses the APIs of the Ning platform to do the job.

"But wait," I hear you say, "everyone and their pet has an API these days! How is Ning different?"

Here's the difference: Every single Web API out there, except for Ning's, is a parallel plug into the backend that runs the service, website, or application in question.

Every site has its databases and various server systems that compose the service they provide. Then (in most cases after the service has been launched) an API is added as a way to expose some of the data or services provided by that website/product. I am not aware of any API out there (except for Ning's, that is :)) that exposes all of the website's services in API form -- perhaps GData's comes closest. Most APIs allow you to read data, sometimes a lot of the available data, and a few let you perform several specific write operations--GData again being a good example of this.

So what is it with this exception I keep making for Ning? What's special about our APIs?

The answer is there when we look at it the other way: it's not so much that Ning's APIs are special, but that the Ning Social Network is built entirely using them. Every application on Ning written by Ning is built using the same APIs available to anyone else on the platform (and even for external remote calls).

Anyone could have built the Social Network application on Ning, starting from scratch. There are no special, high-privilege data paths. There are no hidden authentication systems. There are no datastores that are available only to Ning.

Layers in Ning

The Ning platform is one giant API that runs on what we call the core, a collection of hundreds of servers and dozens of server types that power the platform, presenting a homogeneous view of data and services through a variety of HTTP-based REST APIs.

The Ning APIs are built using REST, but PHP applications running on Ning have access to them through a thin layer of PHP code that simplifies their use from within PHP. However, it is possible to use the Ning REST APIs directly from PHP, it's just a little more cumbersome. In the future, when we add language wrappers, we will use the same APIs as the underlying mechanism to access the Ning services.

So going back to the question: how committed is Ning to the platform? The answer is simple: We are 100% committed to it -- if we were to remove features, or change them, or disable them, every network on Ning would be affected.

The reliability, performance, longevity, and availability of the Ning APIs is exactly the same for everyone modifying the Social Network code, or creating new apps from scratch.

The platform is our DNA. And that means it's going to be available, supported, and evolved, for a long, long time. :)

So I've been using whatever free time I have to play a bit more with Ruby and Rails. Here's some links that I've found useful for OS X:

• Fink. Not Ruby-related, but definitely one of the first things I install in a new Mac. Another thing you probably want to install is MySQL (I have that running separately under Linux already), particularly since the GUI Tools for it have become pretty decent, across all platforms.
• Netbeans 6. Currently still in beta (at Milestone 10) Netbeans is really the simplest way to play around with Ruby. It includes RubyGems integration -- but beware: since it's actually running JRuby, rather than Ruby, some things will not work and some gems may not be downloadable. To get started, though, it's an option that's hard to beat. Unless you're a TextMate fiend, that is (hey, don't get me wrong, I love TextMate, but it's hard to beat an integrated debugger :)). Check out this Netbeans 6 RoR tutorial for more.
• Ruby One-click Installer for OS X. Now, back in the "Pure Ruby" world, Ruby comes of course preinstalled in OS X but there are some things that aren't in there by default and others that are outdated -- the Ruby One-click Installer for OS X takes care of that. For a bare-bones getting started guide for Rails though, this one from the Apple Developer Connection fits quite well I think.
• Locomotive. I confess I haven't tried it (prefer to stick to the command line, just to understand all the rough edges better, or use Netbeans for trying out JRuby) but Locomotive definitely looks like a simple solution for getting Rails running on a Mac quickly.
• Hpricot. Now, one of the first things I wanted to try out in some depth was HTML parsing. Ruby has REXML (example), but no default HTML parsing I could find. Hpricot seemed to fit the bill. I'm sure there are others out there, but from what I could tell Hpricot is fairly good and stable. Adding JSON to that is also pretty straightforward with the json gem.
• ...and to finish it off, another list: Rui, at The Tao of Mac has a good set of Ruby-related links. Check the dates -- some of them are a bit stale.

So today I got new monitors, and I'm experimenting with a new setup, above (note: the picture is terrible, I'll update it tomorrow). The two on the left are 30" monitors--note the size of the keyboard in comparison, it's one of those huge MS natural keyboards--, the one on the left in portrait mode is 24". All of this is supported by the Mac Pro, which has two nVidia cards and four (!) DVI ports.

This is mirrored by a three-screen setup at home, but with 20-24-20 inch monitors, to save some space. :)

The biggest advantage is of course the sheer amount of information that you can have up there to support all that messy thinking. My previous setup was one 24" and one 20". I have the main work area in the center and communication (both asynchronous and real-time) to the sides. On the left is iChat (which, connected through Jabber gets me through to all the different transports, but that's a topic for another post) as well as the various chat windows open with ongoing conversations. Speaking of iChat: it sorely lacks window-blinking behavior. It's hard to tell which window has been activated when you've got a message waiting for you when you have that many open :).

I am still not sure if I'll keep this setup or try just with two 30". Believe it or not, I think I feel a little dizzy looking at so much stuff at once.

From XKCD, A webcomic of romance, sarcasm, math, and language.

Recently I wanted to play around with LISP again (as a way to relax!) and naturally I started looking for IDEs. Java has contributed many things to computer science, but surely one of its most important side effects of it has been the insertion into the popular consciousness of advanced IDEs, IntelliJ IDEA being at the front of this, closely followed by Eclipse and Netbeans.

Interestingly enough, even though LISP has deep roots in the academic community and has been around for decades, the best-known IDEs for LISP out there are not only closed-source, but also commercial, with hefty price tags. Some of the best-known are Allegro Common Lisp and LispWorks. Some of them don't even offer versions that you can download without contacting sales reps! These companies are apparently living in 1994 or thereabouts. Most of them are Crippleware -- they work only for a limited amount of time, or expire, or even generate executables that exit after a while. The fact that their websites also look like something out of 1994 is another clue as to the cluelessness of these companies. It was pretty depressing, really. And no, I don't like Emacs. Sorry. (You may wonder how on earth I can like LISP but not Emacs... well, I guess the Universe is full of mysteries :)).

Then today I found CUSP, a LISP plugin for Eclipse. Awesome! It's free, maintained. It supports autocompletion and Macros, and works well. Highly recommended. I can now proceed with LISP hacking in peace. :)

PS: the reasons for playing with LISP (or even trying to do something serious with it) are many, but they are hard to understand if you've never used it before. At a minimum, it's a great way to exercise the brain. LISP, after FORTRAN, is the second-oldest high-level programming language (dating back to 1958--it will be 50 years old next year!), and there are good reasons for both having such staying power. If you've never programmed in LISP, you should give it a try -- it will blow you away. :)

PS: I forgot to mention it, but the LISP I use is Steel Bank Common Lisp which seems to be the best out there.

Update: Colm O Mahony just wrote over email to tell me that he tried SBCL 1.0.6 (the latest SBCL version) on top of the older version which comes bundled in CUSP. I tried it as well and it works fine. Thanks Colm!
it seems to work fine.

A book that came out a week or so ago was Managing Humans: Biting and Humurous Tales of a Software Engineering Manager, written by Michael Lopp, aka Rands. Here's Rands' entry announcing on the book.

I've met Michael and read Rands, and they're both wonderful people :). I ordered the book as soon as it came out. I will confess that my schedule this week has prevented me from reading more than a couple of chapters but I know what's in there, and it's great (a lot of the book is based on entries from Rands in Repose). This one's a must-read, especially if you share with us that strange, high-speed, high-adrenaline, manic, fun space otherwise known as the internet/software industry.

One thing that is not in the book is the world renowned :) Rands Vegas System. So, that, you'll have to read on the weblog, and you should, because it's a riot.

Anyway, back to the book: go get it!

A couple of weeks ago I wrote about my macbook crashing (or rather, freezing) constantly. Sometimes it would freeze right after booting, sometimes later, sometimes when you left it alone for a while, sometimes when waking up from sleep.

At that point I reinstalled OS X from scratch and hoped that was it. Alas, it wasn't. Very soon afterwards the Mac started freezing again, with a vengeance. In fact, the next day after the fix (a Monday) my Mac Pro at the office also went out to lunch and the 10.4.8 update had to be reinstalled from scratch through SSH. I thought I was cursed!

Then the Mac Pro came to life and I continued with the Mac entertainment at home. The poor thing would lock up like there was no tomorrow. I started to be paranoid about saving files again, something I hadn't done since switching over from Windows a few months ago, and I was also getting more than annoyed.

Then it hit me: the Mac was only freezing at home. At the office, it had never frozen. Not once. It was only at home that this was happening.

I had already ruled out software: the Mac Pro had exactly the same config, and the freezes happened also on a different Macbook with the same disk. Disk checks showed the disk was fine.

So it had to be environmental.

And what was the only difference between home and the office? That's right the router. In February or so I got a Linksys WRT-350N to use 802.11n, which even if it's not "official" sounded (from reading the IEEE proceedings of meetings -- yeah, I do that sometimes, I'm that crazy) like it was not going to experience major changes and so was a relatively safe bet. I had been using 802.11n and all was well.

But that was the only difference with the office -- I've been using the same encryption, WPA-PSK, so that wasn't it. It had to be 802.11n.

But could a wireless protocol, however badly implemented or incompatible, irreparably hang the machine?

Apparently, yes.

To test the theory, last Sunday I changed the configuration of my router to 802.11g, and since then I've been running the Mac at home with no problems whatsoever, making it sleep, not sleep, disable the display after a while, and so on, with no problems at all.

Turn on Mixed mode in the router (802.11n+g) and the thing locks up again so fast it makes your head spin. Turn on pure 802.11n and OS X seems to whitstand it better, although I had one weird situation with it that I attribute to that as well.

OS X doesn't really let you choose the wireless protocol you're using, at least not in the base options that I've seen. So the Macbook must be going bananas when trying to decide what to do in Mixed Mode, as well as sometimes in pure 802.11n mode (perhaps, I have to confirm this fully).

Anyway, if you have a Macbook or Mac with 802.11n (and the software update for it installed) and you're experiencing weird lockups, take a look at your wireless router and see if it's on Mixed mode. That may be the source of the problems.

Phew!

A new thing I'm trying are what I'm calling miniposts. These are entries that generally don't even have title and are just a quick comment on something I see that is interesting but is not -- or hasn't yet -- developed into a full post. I've been wanting to do this for a long time, and now that I am it is as liberating as I thought.

This is of course not new at all -- people have been doing it one way or another since the start of blogging itself, most recently in the form of Twitter and related things. MT, with its structure of title and big boxes that seem to beg for a lot of text creates a strong pull into creating long posts, at least for me. And that sometimes can cramp my style. :)

There are three feeds -- one for all entries+miniposts, one for entries, and one for miniposts only. Take your pick! We'll see where this goes. :)