tecznotes

Michal Migurski's notebook, listening post, and soapbox. Subscribe to this blog. Check out the rest of my site as well.

Feb 24, 2005 5:04pm

ajax, again

Ajax seems to be the new official term for remotely-scripted web applications, in the few days since JJG published his paper on the topic. Lots of predictably-acerbic commentary from slashdotters, pointing out that this is just new name for an old idea (and a fantabulous e-term to boot). The story with JJG's post is not that Ajax is new, but that there is now a two-syllable term that encompasses an emerging development pattern. In other words, this is news for business people, not developers.

In a narcissistic moment, I was curious whether anyone was finding my website on the search term "ajax", and found this instead:

Feb 24, 2005 4:59pm

new york, day 2

I'm starting my second day in New York today. This city is amazing - it feels like San Francisco did when I first showed up there in 1995. A surprise lurking on every street, a complete change in feel from neighborhood to neighborhood. I could live here, for sure. Yesterday I spent most of the day at Eyebeam's DUMBO space, with the 12th-floor view of the Brooklyn and Manhattan bridges. It was cold as hell. Visited Peter in Williamsburg ("Billburg... don't call it Billburg"), with the 6th-floor cell tower-studded warehouse roof view of Manhattan and Williamsburg bridges.

Feb 21, 2005 6:28pm

ajax: a new name for an approach to web applications

Jesse Jame Garrett of Adaptive Path just published an article about web applications development called Ajax: A New Approach To Web Applications:

Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path call Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in whats possible on the Web.

It's a nice recap explaining the interesting new possibilities allowed by XMLHTTPRequest in browsers such as Mozilla, Safari, and IE 6. We've been using it to add full keyboard navigation to an upcoming release of ReBlog. The X in the name may be a little presumptuous: often, generating and parsing XML is a pain. JSON is a nice alternative, using Javascript's native object representation syntax to send data that can be parsed by eval() in one step.

I'm not sure how I feel about the coining of a proper name such as "Ajax", and its use in contexts such as "Ajax engine." It's always helpful to identify and describe patterns in development, but this usage implies a brand identity and productization that just doesn't exist. In its defense, Ajax is way easier to type.

Still, it's amazing how much expressiveness has been introduced into web transactions with the introduction of a simple mechanism for in-flight HTTP requests. Writing applications in this style raises a few interesting questions, especially: where does it stop? With two methods for performing HTTP transactions, it's good to know where to use regular page reloads. Ajax introduces some confusion into traditional application designs: if you're using a pattern like MVC to design your server-side code, Ajax now gives you two views and two models, where the server's view is the client's model. This is weird. Flickr gets this right, using in-page requests for small, local tasks like updating image titles or descriptions.

Feb 20, 2005 9:17pm

heading for new york

I'm leaving for New York in two days. I'll be there for a week, working with Eyebeam, checking out The Gates, and visiting friends. I also want to see the new MOMA. Any advice on things to do?

Feb 19, 2005 12:14am

small update to json-php

I made some edits to JSON-PHP, with the gracious assistance of Matt Knapp. JSON-PHP is my implementation of JSON, a lightweight data-interchange format specially adapted for use with client-server javascript communications with XMLHTTPRequest. The change handles a few edge cases involving encoding mixed-index arrays, trading nominal type consistency for a less lossy representation of data.

Check it out here, or at PEAR.

Feb 17, 2005 5:57pm

tracking google maps

Mikel Maron has written a javascript extension to Firefox that allows arbitrary XML to be applied to Google Maps. Here's my trip into work this morning:

(Or here, if you've got Firefox and Greasemonkey)

Feb 16, 2005 7:39am

nietzsche on design

Via Thomas:

When one has finished building one's house, one suddenly realizes that in the process one has learned something that one really needed to know in the worst way -- before one began

...Kind of like how I spent a significant portion of 2004 building a room at my old warehouse, only to finish and decide that I was no longer interested in communal living. Oh man was it gorgeous, though - 3 stories up, balcony, right by floor-to-ceiling warehouse windows with roof access for tomato-growing on the edge of the ghetto. When Jack Dangers and Ben Stokes performed at the house last year, they called it "the treehouse."

Feb 14, 2005 8:07am

indie rock pete

From an essay on UltraGleeper, a Codecon presentation on web page recommendations, which I missed:

If you want best-sellers you can check the best-seller list. In my opinion, a good recommendation engine must have an element of anti-popularity. I implemented this in the Ultra Gleeper with something I call the Indie Rock Peter Principle, named after the comic strip character Indie Rock Pete, who has a kind of sadomasochistic relationship with popularity. The IRPP stipulates that beyond a certain point, additional recommendations (i.e. incoming links) decrease a page's score instead of increasing it. Not only does this clear the ground for real surprises, it acts as an additional, probabilistic filter for pages you've seen in casual browsing. Anything it misses will probably show up within a couple days in the weblogs you read.

Brilliant. (emphasis mine)

Feb 14, 2005 2:42am

codecon 2005 recap

We presented Mappr at Codecon 2005 yesterday, and I think it went pretty well. I wanted to go check out a few of today's sessions (notably Wheat and Incoherence), but circumstances prevailed against me, and I was only able to attend the Google reception Friday evening and most of Saturday's talks.

We were asked a few great questions, which I'll summarize here:

A few participants asked about the possibility of open-sourcing Mappr, or at the very least clarifying the licensing terms on the website, so decompilers would know what they were permitted to do, before doing it anyway. Clearly, we'll need to be more up-front about the terms for using the client-side map code, though this a question probably best asked of Tomas, who wrote it.

The open-source question is an interesting one, as it applies to web services. The GPL has addressed the licensing issues around machine-readable computer code, and Creative Commons has done the same for creative works, where derivative works and attribution are an issue. Web services are still a fairly major gray area, especially in the case of Mappr:

  • We don't actually own most of Mappr's data, since the photographs you see on the site are all there courtesy of the original photographer, subject to their terms, and served up via Flickr. If Flickr were to shut their doors, Mappr would disappear as well.
  • The geographical data we use to make our location guesses comes from US Government sources. It is public-domain, but it isn't "ours" in the strictest sense either.

The value Mappr has (and there must be value, for something to be licensable) is in the work it does, the service it performs. In a sense, a webservice is like the blue-collar worker of the 2.0 web, paid hourly for work done rather than salary for ideas generated; it's a role that resists easy intellectual property pigeonholing. What aspect of Mappr could be open-sourced? The client code, obviously, but this is in some ways the easiest part to reverse-engineer. The server-side location matching heuristics could be open sourced, but that wouldn't be worth much without the formatted place information culled from various sources. The photos themselves aren't ours to license.

One participant asked about explicitly geo-tagged images. This has been brought up before, and Flickr has just made this a lot easier by opening up EXIF data in their API. They still don't provide a way to search on EXIF, and I strongly suspect that not very many photos in the system have geo data in them.

I would approach the task of using explicit geo-data by merging it with existing place-name data: I would define a new type of relationship in Mappr ("Mappr believes this photo is near...") based on the closest named place to the photo's latitude and longitude. I would also allow for alternate ways to specify this information: EXIF is voodoo to a lot of users, and inaccessible once the image has been uploaded. It should be possible to expand our range of mappr-recognized tags to include something like "mappr:latitude:12.34". This has been brewing for a while, and Flickr's EXIF hooks are one additional fire under my ass to get it done.

Alon Salant's Photospace project, presented right after ours, handles the explicit geolocation issue nicely by providing for local maps and using RDF to link GPS tracklogs to terraserver maps. It's a little technically hardcore for Flickr users, I think, but definitely the approach of choice if you are interested in rigorously-specified locations for images. There were questions about our learning and feedback mechanisms. For example, if photos tagged with "Concrete" are consistently misplaced into Concrete, WA (ironically, the photo we currently have for that location is actually intended to be in Concrete. Try duck), how can the system learn to disassociate these tags? Right now it's a manual process: I mark placenames "Gary" or "Reading" as commons words or names that may not actually be placenames. Implementing any type of automated learning system is pretty far out of my reach right now, though I do have a copy of AIMA on my bookshelf that may help with this.

Er, that's it. Go Codecon!

Feb 11, 2005 10:52pm

flickr folder action

Neat idea from Mike:

A couple of months ago I had the idea that it would be possible to use the OSX Finder to automatically (or "automagically," as the old Sysadmin term went) upload photos to Flickr when my camera was attached to my Mac, with no involvement from me. The logic went like this: 1. Flickr can get uploads from a UNIX command line 2. AppleScript can issue UNIX commands 3. the Mac Finder can automatically execute AppleScripts when a new object appears in a folder (a Folder Action) 4. Folders are created in the /Volumes directory whenever a new volumesuch as my camerais mounted

Feb 10, 2005 7:55am

newsburst busted

Feb. 15: I just got a mail from CNet apologizing for the brief bugginess, and assuring me that Newsburst now works on a Mac. Sure enough, I'm logged in and trying it out.

Steve Rubel writes:

CNET News.com is launching a Web-based RSS news aggregator called Newsburst. The site, now in preview, will compete with Bloglines and Rojo. CNET's move comes on the heels of the LA Times and Guardian, which launched desktop RSS readers last week. This is the beginning of a trend where the big media launch branded RSS aggregators to make sure they retain reader loyalty.

It'd be a much more effective trend if the developers of newsburst had bothered to make the signup form work on a Mac. It doesn't even work in Firefox, so I wonder whether this is an MSIE-only thing. Come on guys, it's a couple of pull-down menus - get your act together and stop trying to be all javascript-crafty.

Feb 6, 2005 8:38pm

spy list leaked

from Slashdot:

"A list of 240,000 names of Polish secret agents, informers, secret service employees, and victims of persecution was leaked on the internet in the last days and became an instant hit. The search for "lista Wildsteina" (Wildstein's list) sky-rocketed to 300,000 per day in the second most popular search engine in Poland (onet.pl) outperforming "sex" (former top query) by more than 30 times. The list appeared on many web sites, p2p networks, and was made into a searchable database. There are worries the list might contain names of active security agents, still working abroad. Google news has more coverage."

Feb 2, 2005 4:05pm

mappr is under the gun

A string of links over the last few days have slowed mappr to a crawl, and I had to shut it down for a few hours last night so Eric could present it at Meetup in NYC.

Yahoo:

Mappr is quite literally a snapshot of the nation. Actually, it's lots and lots of snapshots. ... click on a photo and Mappr will tell you just how confident it is that it placed the pic in the right location. We're confident you'll find a surprise at every click.

USA Today:

Sometimes the best way to figure out where you are is to simply look around. Mappr lets you look at the U.S. and points nearby through the eyes of photographers kind enough to submit their snapshots to the site. The geographical interface to these casual (often very casual) snaps is wonderfully addictive if you let yourself worry less about the destination and more about your glimpses on your way there.

K10K:

If you're a fan of Flickr Check out Stamen's : Mappr - a visual mapping of flickr's photocoupage. (tipped by Tomas!)

So that's why it has been sluggish since yesterday morning. CPU load has been hovering at around 5.00, hitting highs of 10.00 yesterday. The default recent photos search takes days, but tag-specific searches like "sign" or "red" work pretty quickly, and are more interesting anyway. :)

March 2024
Su M Tu W Th F Sa
     
      

Recent Entries

  1. Mapping Remote Roads with OpenStreetMap, RapiD, and QGIS
  2. How It’s Made: A PlanScore Predictive Model for Partisan Elections
  3. Micromobility Data Policies: A Survey of City Needs
  4. Open Precinct Data
  5. Scoring Pennsylvania
  6. Coming To A Street Near You: Help Remix Create a New Tool for Street Designers
  7. planscore: a project to score gerrymandered district plans
  8. blog all dog-eared pages: human transit
  9. the levity of serverlessness
  10. three open data projects: openstreetmap, openaddresses, and who’s on first
  11. building up redistricting data for North Carolina
  12. district plans by the hundredweight
  13. baby steps towards measuring the efficiency gap
  14. things I’ve recently learned about legislative redistricting
  15. oh no
  16. landsat satellite imagery is easy to use
  17. openstreetmap: robots, crisis, and craft mappers
  18. quoted in the news
  19. dockering address data
  20. blog all dog-eared pages: the best and the brightest

Archives