At any rate, if you wish to restore them, here are the directions to fix it:

OS X 10.6 Snow Leopard – OneSwarm Wiki.

Nice directions on how to enable 64-bit mode in Java 1.5 on Leopard.

Better late than never, I guess.  As much fun as people make of Ballmer for “Developers, Developers, Developers“, he has it right.  Your computer and Operating System is only going to be as good as the software that 3rd party vendors (i.e. developers) write for it.  This translates to you, the computer company and O/S creator, needing to provide things like Java 6 in a timely manner.  You want to be taken seriously in the enterprise, you gotta have the tools that enterprise developers want to build on, otherwise, forget it.

Hmmm, so I have been pondering this for a while and don’t quite know a good solution…  So help would be appreciated.

As an active developer of Lucene, we have pretty strict rules about Backwards Compatibility, as evidenced by the link given above.  For the most part, what this translates to, is the need to use Abstract base classes in Java, instead of Interfaces, since adding methods to interfaces in libraries  quickly causes downstream, unknown implementations to instantly be broken, whereas adding them to abstract classes does not b/c we can give a default implementation.

On the one hand, one might say to the user of the library, don’t upgrade unless you are prepared to handle the new code.  Naturally, the user’s pushback is, don’t break my code for minor releases.  This leads to having lots of deprecated methods and other gyrations to work around the backwards compatibility requirements.  For the most part, it isn’t a big deal once you adjust your thinking from the application developer mindset to the library developer mindset, yet I can’t help but wonder if there isn’t a better way.  Granted, I am not saying I know what it is, but just like @deprecated tells everyone a method or class is going away, I wish there was a way to tell everyone, via code, that new methods are coming.  Not sure what the semantics of this are, but for an Interface, I was thinking maybe you could introduce something like an @introducing annotation.  The interface would still work as is, but it lets the user know by some future version that this interface is going to change by giving a compiler warning and then, when the new version is met, it does break implementations.

Then, I think, one could provide both an Interface and an abstract base class implementation of the interface, which I often think is the best of both worlds.  This way, one can have the benefits of multiple implementations of the interface and the library can provide a basic implementation.

Am I crazy?  Does something like this exist in other languages?  Not sure what the right answer is here, but I do know I would like an effective way of communicating to Lucene’s users that an Interface is going to change, since Users really like interfaces and library developers really like abstract base classes and sometimes it feels like we never will meet.

I will be speaking November 19, 2007 at the Triangle Java Users Group on Lucene and Solr.   The talk will be an introduction to the features and capabilities of both Lucene and Solr, as well as some basic compare and contrast information.

I will post more on my new venture at some point in the future.

OK, so we keep hearing about all the new things Ask.com is up to (like Ask3D), but, in my opinion, they still are missing the key thing: quality results. I don’t care how pretty the look and feel is if I can’t rely on the results.

Try, for instance, a search on Ask.com for the single keyword “Lucene”. The first result in my browser is for a link to http://jakarta.apache.org/lucene/docs/index.html. A link to the Query Parser Syntax shows up as the second hit, before the actual Lucene home page.  The third hit is for the real Lucene URL: http://lucene.apache.org/.

A few points here:

1. Lucene hasn’t been a part of Apache Jakarta for a LONG time. The first link is a redirect to the real site.
2. There is no reason why the query parser syntax should show up as a higher ranking than the main site.

Now, compare that w/ Google’s results. The first hit is actually the Lucene Java implementation, which makes total sense because the Lucene Java project is the most well known of all the Lucene projects and is the “flagship”. However, there is a “sub” result to the first hit on Google which is a link to the top level Lucene project, just like Ask’s hit list. The Query Parser syntax doesn’t even show up in the top 10 for Google and I would agree that it wouldn’t be in my top 10 of results for such a generic search.

Now, a few positions may seem minor and all, but in my mind, these ones are quite obvious and if they don’t do well on the obvious things, then what about the tougher ones?

First off, the trip started off on a bad foot when our flight to Paris, France got canceled due to bad weather in Newark. Unfortunately, we didn’t get the message from the airline in the morning because we were out running errands, so we didn’t have time to get rerouted. Since we were only planning on being in Paris for 2.5 days, we ended up canceling that part of the trip and focused in on Amsterdam.

We arrived in Amsterdam at Schipol on Sunday, April 29th and proceeded to figure out how to get to Volendam, NL (about 20 k north of Amsterdam) via a combination of train and bus. We picked Volendam as a last minute replacement for Paris, so you can guess that it didn’t live up to our expectations! Not to say it wasn’t nice, just a bit touristy for our tastes. Add in the jet lag factor and a biting wind and you can guess that it wasn’t much fun. The Hotel Spaander was very nice, except for the actual bed and pillows, which were very lumpy.

The next day we headed back to Amsterdam via taxi and bus due to the craziness of Queen’s Day. Word of warning, you had better be pretty savvy if you plan on traveling in or to Amsterdam on Queen’s Day. It is a zoo. Most public transportation is non-existent. Thus, we had to walk from Centraal Station to the Movenpick hotel (about 10 minutes) whereupon we settled in for an hour or so before heading out to investigate the city and enjoy Queen’s Day. Walking the town and enjoying the food and people was awesome. Picture 40-60 city blocks shut down to all non-foot traffic and filled with people partying (estimated # of people is 2-4 million). Unfortunately, I had to “work” the next day, doing my all day training in Lucene, so I couldn’t fully enjoy the day. Yet, the Westmalle beer never tasted better. I highly recommend visiting Amsterdam for Queen’s Day.

The Movenpick was quite nice, having all the amenities of a modern hotel, and the design to boot.  My only nit was that in some areas the design overshadowed comfort.  For instance, the bathroom door was this frosted glass.  Looks great, but when you have to be up early and your wife is trying to sleep, having light pouring out into the room isn’t exactly pleasant.  I did like the eco-sensibility built into the rooms, including dual-flush toilets and the requirement that you put your key into a receptacle  in order to turn on the power.  Thus, when you leave the room and take your key with you, you can be assured that all lights, etc. are turned off.  If only US hotels did these kinds of things.  Not only would it save them money, but it would reduce pollution too.

The next day was my all day training on Lucene at the actual conference. I had 22 or so attendees in the class. After some early morning glitches due to IDE setup, I think things went quite well, and I have already fixed the issues for future trainings (if you are interested in Lucene training, contact me at gsingers@syr.edu.  Wednesday brought my talk on Advanced Lucene, which I thought went pretty well (at least from my perspective, but hey, I’m biased.) Thursday I went to several talks, the two main ones I enjoyed being about Hadoop and Solr. Friday I attended some early morning talks while my wife got ready and then we headed to Lisse and the Keukenhof gardens. These gardens are pretty amazing and I would rate them as a must see if you are in the area in spring.

In the end, I love the bike culture in the Netherlands and I really enjoyed the city.  Wish I had more time to explore the outer parts of the city, beyond Jordaan area and the main tourist part of the city.  Getting around on the tram was a piece of cake, especially since everyone speaks English.  Also would have liked more time to visit some of the museums, but in the end, I feel I really got to know a good chunk of Amsterdam.  My favorite part was walking around the Jordaan district, taking in the sights and sounds and eating at a little hole-in-the-wall cafe called the Bolhoed.

Pictures of all this can be seen here.

1. Slide Number
2. Time expected for each slide
3. wall clock time, expressed as the function =TIME(HOUR($D1),MINUTE($D1),0) + TIME(0,$B2,0)

This approach, while working, is a bit clunky as I always have to go back and forth between PowerPoint and Excel.  So, if you know a better way of doing this, please let me know.

By the way, it is not too late to sign up for my all day Lucene training at ApacheCon Europe. If you want to get up to speed on Lucene in a hurry and are going to be in Amsterdam on May 1st (or want to be in Amsterdam on May 1st) then sign on up! The more the merrier.

Lately, I’ve been wishing I lived in Australia, because this guy seems to get it and Atlassian sounds like a great place to work (plus, he gets Open Source, and what makes it great.) Not that I am looking for a job, b/c I feel the Center meets a lot of the criteria outlined here for being a great place to work. Sometimes life is about knowing when you have a good thing and living it to the fullest, not always looking for the greener grass.

Needless to say, I am always baffled by managers who stare at resumes looking at keywords and want to know if you can do some specific programming task in the alloted 5 minutes, caring only about the end solution, not your thought process. Seriously, how many of your real business problems were ever solved in 5 minutes? Properly done interviews take time and are a real investment by your company. They require getting to know the candidate at many levels, both technically and personally.   Too often, I think companies hiring developers only look at the technical. I often find it important to know whether the candidate “gets” what the business is about.

No offense to the gods at Google or anything, but I once interviewed there and they asked me to solve a problem, in 2 minutes or so, that they said took them OVER 3 MONTHS TO SOLVE. Now, I suppose there are people that did solve it in that time frame, but I wasn’t one of them. I did, however, in my biased opinion, walk through the problem in an intelligent way and I believe I properly analyzed the various approaches (the first solution was brute force, the second used dynamic programming techniques and the last was a brilliant order(n) solution that knocked my socks off.) It was easily the hardest interview I’ve ever done.  No sour grapes intended, I very much respect Google and the fact that they most likely have to weed out thousands of candidates and this was a way of doing it, I just don’t always think that type of interview is all that effective.

Worse yet are the managers that obsess over your knowledge of a specific language, versus realizing that languages come and go, but knowing how to program never goes out of fashion. To me, the people you want to hire are those who know how to think, not those who are good at memorizing syntax. I can’t tell you how many people I’ve worked with who are great at syntax but no very little about solving real problems. And I can’t tell you how many people know the ins and outs of syntax, but never use all those years of “schoolin” to think about performance, maintenance, readability, etc. or real problem solving.  They just want to get “it” working ASAP and think it is job security to do it in a way only they understand.

By the way, if you are a candidate for a position, you may find these tips useful.