This talk was one of the highlights of the conference. At the talk, they showed performance benchmarks that included running several things as much as 117x as fast as the default Ruby interpreter that is in use by most Rails installations today. The fact that it's built on this commercial-grade Gemstone platform that has been used for years for high-performance production Smalltalk applications just adds to its credibility.
One of the reasons this is exciting is that many Ruby/Rails programmers have suffered from the criticism that their platform is elegant and fast to develop in, but that it doesn't scale well. MagLev sure looked like it could go a long way toward addressing those concerns. And since it hits Ruby right at the VM level, it is potentially useful to anyone running any kind of Ruby app whether on Rails or not.
I went by the Apple Store in Valley Fair Mall, San Jose, CA at 8:50am on Friday to "see the line". It was reasonable (about 100 people), and fun (lots of Slashdot-types in line, with Steve Wozniak at the head of the line near his Segway), so I stayed for about an hour. Then I felt guilty about neglecting my work for a whole day, and left to get some work done. After dinner, I went back to the store to see how things were going, and whether I might still be able to buy a phone. I'm not sure how long the line got right at 6pm, but there were easily still 100 people ahead of me in the (new, outside) line when I got there at 7:30. Yet I waited just 30 minutes, as the line moved steadily along, and I easily made my purchase in the store at 8 (8GB model). The store manager and other employees did come out and told people in the line not to worry, that there would be plenty of phones available for all of us, and there were. When I left, there was no longer a line outside the building, so I guess they cleared it.
I was very impressed. I have purchased other products at the Apple store, and the fact that any employee can ring you up for a credit card purchase, take your signature on a Symbol handheld computer, and then email you your receipt is extremely efficient and impressive. This is what allowed Apple to process people so quickly; as many as 8 people buying phones in parallel, with the whole transaction taking just 1 minute.
The map injected into the page is an iframe which loads from my server at www.vinq.com; the iframe contains the Google Map. This is needed both due to the Google Maps API key restriction, and to let me locally geocode the addresses on my Vinq server.
By the way, we're looking for a few good LAMP programmers in the San Francisco Bay area (near San Jose), with a strong emphasis on Perl, to help us build more great sites like www.dataplace.org and www.knowledgeplex.org for Fannie Mae Foundation and other huge clients. Email resumes to jobs at vinq.com.
As I mentioned below, it's a Greasemonkey script which scans any web page for both addresses and geocode metatags in the GeoURL syntax, and if found, it injects a Google Map showing any/all such locations into the top of the page. You can choose whether it should show the map by default, or just a small bar indicating that addresses were found. My point in making it was to illustrate that the API can be used to add functionality to any site, not just to a particular site.
I find it useful on sites like whitepages.com, real estate sites, company location "about us" sites, and a bunch of other surprising places. It just makes the whole web more "mappy".
By the way, the site is back up, so if you got stuck before please try again now at www.vinq.com/greasemap. It's running on a single Xserve; we'll see how it creaks under the strain.
Sorry the server is slashdotted already. For people who asked "what's the point", it was to add maps to the many pages which contain addresses and/or Lat+Long geocoded coordinates but which don't yet have maps.
I agree that there is an apparent bias in the politics of the stories submitted by CmdrTaco, though I feel any individual contributor to Slashdot is certainly entitled to have a bias. That's the great thing about the availability of feedback; we can all express our opinions.
However, most of the rejected stories you listed have nothing to do with technology; they merely describe political news or events. I think the bias Slashdot has toward "news for nerds" is appropriate; we can get our pure political news from other sources.
When I'm reading slashdot, I'm looking for info about tech trends and social impacts therefrom, nothing more.
While in grad school at the MIT AI Lab in early 1992, Michael Frank (now faculty at UFL) and I wrote "pizza" and "xpizza", command line and GUI programs (respectively) to order pizza from a nearby delivery joint. It worked by sending a fax to the pizza place. Even had code to determine whether the pizza would arrive before or after they locked the doors to each floor of our building, to provide different delivery instructions in each case. I'd be interested to learn if anyone can cite an earlier example of online pizza ordering.
At StockMaster.com (now gone), we used Solaris x86 as our primary platform for web servers running Apache/mod_perl and custom multithreaded data servers for stock quotes and intraday charts. It was helpful for us to be able to move our apps between this platform and Sun boxes running Solaris 8, where we ran our databases and mail servers. The cost was reasonable, and we got excellent performance out of the Dell hardware by using Solaris x86. Not my business any more, but this architecture worked well while it lasted.
I think Solaris x86 is most helpful for this type of situation where companies are deploying in-house created custom apps, not looking for commercial software to target the platform.
Slashdot Mirror
This talk was one of the highlights of the conference. At the talk, they showed performance benchmarks that included running several things as much as 117x as fast as the default Ruby interpreter that is in use by most Rails installations today. The fact that it's built on this commercial-grade Gemstone platform that has been used for years for high-performance production Smalltalk applications just adds to its credibility.
One of the reasons this is exciting is that many Ruby/Rails programmers have suffered from the criticism that their platform is elegant and fast to develop in, but that it doesn't scale well. MagLev sure looked like it could go a long way toward addressing those concerns. And since it hits Ruby right at the VM level, it is potentially useful to anyone running any kind of Ruby app whether on Rails or not.
Of course, we'll see when it's done...
I went by the Apple Store in Valley Fair Mall, San Jose, CA at 8:50am on Friday to "see the line". It was reasonable (about 100 people), and fun (lots of Slashdot-types in line, with Steve Wozniak at the head of the line near his Segway), so I stayed for about an hour. Then I felt guilty about neglecting my work for a whole day, and left to get some work done. After dinner, I went back to the store to see how things were going, and whether I might still be able to buy a phone. I'm not sure how long the line got right at 6pm, but there were easily still 100 people ahead of me in the (new, outside) line when I got there at 7:30. Yet I waited just 30 minutes, as the line moved steadily along, and I easily made my purchase in the store at 8 (8GB model). The store manager and other employees did come out and told people in the line not to worry, that there would be plenty of phones available for all of us, and there were. When I left, there was no longer a line outside the building, so I guess they cleared it.
I was very impressed. I have purchased other products at the Apple store, and the fact that any employee can ring you up for a credit card purchase, take your signature on a Symbol handheld computer, and then email you your receipt is extremely efficient and impressive. This is what allowed Apple to process people so quickly; as many as 8 people buying phones in parallel, with the whole transaction taking just 1 minute.
By the way, we're looking for a few good LAMP programmers in the San Francisco Bay area (near San Jose), with a strong emphasis on Perl, to help us build more great sites like www.dataplace.org and www.knowledgeplex.org for Fannie Mae Foundation and other huge clients. Email resumes to jobs at vinq.com.
I find it useful on sites like whitepages.com, real estate sites, company location "about us" sites, and a bunch of other surprising places. It just makes the whole web more "mappy".
By the way, the site is back up, so if you got stuck before please try again now at www.vinq.com/greasemap. It's running on a single Xserve; we'll see how it creaks under the strain.
Sorry the server is slashdotted already. For people who asked "what's the point", it was to add maps to the many pages which contain addresses and/or Lat+Long geocoded coordinates but which don't yet have maps.
However, most of the rejected stories you listed have nothing to do with technology; they merely describe political news or events. I think the bias Slashdot has toward "news for nerds" is appropriate; we can get our pure political news from other sources.
When I'm reading slashdot, I'm looking for info about tech trends and social impacts therefrom, nothing more.
While in grad school at the MIT AI Lab in early 1992, Michael Frank (now faculty at UFL) and I wrote "pizza" and "xpizza", command line and GUI programs (respectively) to order pizza from a nearby delivery joint. It worked by sending a fax to the pizza place. Even had code to determine whether the pizza would arrive before or after they locked the doors to each floor of our building, to provide different delivery instructions in each case. I'd be interested to learn if anyone can cite an earlier example of online pizza ordering.
I think Solaris x86 is most helpful for this type of situation where companies are deploying in-house created custom apps, not looking for commercial software to target the platform.