My sweetie has been leading a group of talented Ottawa-area actors and crew members to create a new web series, Sweet Tarts Takeaway.
I’ll post again when the web series goes live in a couple of months. In the meantime, you can get updates by following @TartTweets on Twitter, or by joining the Sweet Tarts Facebook Group.
SQL is about tables and sets. Object-oriented programing is about types, subtypes, and polymorphism. There are nasty, nasty frameworks available to try to move between the two worlds (say, by serializing and deserializing Java objects) — this posting, however, is not about those. Instead, it’s about how to make SQL support the basic benefits of polymorphism in what we might call a SQL-y way, independent of any programming language.
Imagine that you want to deal with a set of geographical entities, similar to what I handle in OurAirports:
The normal object-oriented approach would be to create a base class such as “Location” with all the properties these have in common (unique id, latitude, longitude, elevation, name, description, etc.) and then create subclasses adding additional information for each one (such as frequencies for the navigation transmitters, or identifiers for the airport). The normal naive SQL approach, on the other hand, is to repeat the information in four separate tables.
SQL can, however, handle polymorphism in a fairly elegant way — I think database people call these “disjoint subtypes”, but feel free to ignore that term. Instead of a base class, we create a base table (I’m using the MySQL dialect, but most SQLs should have similar capabilities):
create table Locations (
id bigint primary key auto_increment,
type enum ('airport', 'city', 'poi', 'navaid') not null,
latitude_deg double not null,
longitude_deg double not null,
elevation_m int not null,
title varchar(128) not null,
description text not null,
# add indices as needed
);
(A purer implementation would use a separate LocationTypes table for flexibility, rather than the enum value — I’ll probably do that in OurAirports, but it would make these examples a bit more verbose.)
Next, create a table for each of your subtypes, where the primary key is also a foreign key pointing to the Locations table:
create table Airports ( id bigint primary key, iati_code char(3), icao_code char(4), local_code varchar(4), # etc. foreign key id references Locations(id) );
Using the same id for the base and derived table ensures that each entity has an id that is unique across all subtables, and simplifies SQL statements for accessing and modifying the tables.
Now, when you want to deal with locations in general, regardless of subtype, simply query the Locations table:
select L.* from Locations L where latitude_deg > 60;
You can update base information without even knowing the subtype:
update Locations set latitude_deg=45.5 where id=111;
When you want to deal with a specific kind of location, do a simple join:
select L.*, A.* from Locations L join Airports A on L.id=A.id where A.latitude_deg > 60;
To make this even easier, define a view containing the join:
drop view if exists AirportsView; create view AirportsView as select * from Locations L join Airports A on L.id=A.id;
Now you can simply query AirportsView as if it were a single table:
select * from AirportsView where latitude_deg>60;
Inserting is slightly more complex, because it involves two steps: first, create the base entry, then link to it from the derived entry:
insert into Locations (latitude_deg, longitude_deg, elevation_m, name) values (45.5, -75.5, 100, 'Sample Airport'); insert into Airports (id, iata_code) values (last_insert_id(), 'AAA');
Stored procedures and/or triggers can automate this fairly nicely, if you don’t want to have to embed too much database logic in application code. Deletion similarly requires two steps:
delete from Airports where id=111; delete from Locations where id=111;
A simple post-deletion trigger for Airports, though, could automate this and avoid the risk of mistakes in source code.
Unfortunately, I didn’t design OurAirports this way from the start, so I have a bit of refactoring to do. When I’m finished, however, I expect mapping to be much simpler, since I will no longer have to execute 5 or 6 separate queries to find all the icons to display on a map. If anyone has any better ideas, please let me know; otherwise, stay tuned.
A note in my inbox this morning announced that Amazon’s EC2 virtual computer hosting service now supports “micro instances” for $0.02/hour ($0.03/hour if you’re confused enough to want to host a web site using Windows):
Instances of this family provide a small amount of consistent CPU resources and allow you to burst CPU capacity when additional cycles are available. They are well suited for lower throughput applications and web sites that consume significant compute cycles periodically.
- Micro Instance 613 MB of memory, up to 2 ECUs (for short periodic bursts), EBS storage only, 32-bit or 64-bit platform.
$0.02/hour = $0.48/day =~ $14.50/month.
A small standard on-demand EC2 instance is $0.085/hour (~$61.50/month), so this is a huge price drop for web sites that don’t really need much computing power, who make up a very long tail). The most obvious target is ISPs who offer shared hosting for low-traffic web sites for $10-20/month.
A less obvious, but perhaps more important target for Amazon EC2 micro instances is Google App Engine. As I explained in a previous posting (Costing out Google App Engine, July 2009), Google can afford to offer free hosting up to about 5 million pageviews/month — enough traffic to pay a modest salary from ad revenue — because they know that most sites will use Google AdWords, and Google will get a cut of the advertising revenue. Amazon EC2 can’t offer free cloud hosting the same way, because it would still be Google getting the advertising revenue.
By offering such a low price tier, Amazon is probably gambling that people are willing to pay <$15/month for four freedoms that Google App Engine doesn’t deliver:
I suspect that for many users, the ability to just drop in an app without having to spend weeks messing around with JVM-limited language ports like JRuby will be outweigh the price of three beers each month. Of course, thousands of ISPs already offer that freedom through shared hosting accounts, often at a lower price and with decent personal technical support. What else does AWS offer this group that the ISPs don’t?
I installed the Google Chat Voice plugin today, and found that I was able to make free Google Voice calls from Canada to both a US and a Canadian POTS number. I’m still unable to register for Google Voice at google.com/voice, and I cannot use the Google Voice app on my Android phone, but at least I can initiate a call from inside GMail on my laptop now.
Does this mean that Google is about to roll out full Google Voice support for Canada, or just that they forgot to plug a hole in the code that that’s supposed to prevent non-US accounts from using the service?
Google Voice on my Android phone would be fantastic, because I could make unlimited North American phone calls on (say) a 6 GB, $30/month data plan instead of paying the world’s highest cell phone bills for (limited) voice and long distance. I’m sure Rogers and other mobile carriers won’t be happy about that, but I hope their lobbyists can’t stop it.
Java is dead.
A lot of developers have thought they were too hip for Java, but I still liked it. I implemented SAX in Java first of all, and have developed software in Java and encouraged my enterprise customers to use it for many years, sometimes in 9-figure projects at Fortune-500 companies — it’s a great, mature platform, with a lot of tools for managing large projects and development teams, and it has unit-testing and IDE support that is second to none.
But now, Oracle (which recently bought Sun) has decided to sue Google for using Java in Android, even though (a) Sun long ago open sourced Java, and (b) Google built its own VM anyway. I very much hope that Oracle will suffer the same humiliating, crushing, well-deserved defeat that the SCO group suffered when it went after Linux with its own bogus law suits, but it will take years for that to happen. The Android and Blackberry mobile operating systems will be fine, and Java (of a sort) will live on there (though I still recommend web apps instead of phone apps), but the days of Java and Eclipse in the enterprise are finished.
In the meantime, there are lots of open alternatives to Java, and the litigation risks of using Java have suddenly become far too high. In my consulting work, I’ll reluctantly have to advise customers not to use Java for any new projects, and to consider migrating older projects to a different platform. If you’re a big company or government, you just can’t afford the risk that Oracle will come after you, too.
I’m sorry the end was so sudden and messy, but still, it was a great 15 years. Thanks to James Gosling and all the other people in the Java community for the memories and opportunities.
Summary: Mobile web users’ needs differ by more than UI features (small touch screen): they may check information more often, and expect it to be fresher.
Last night, I finally got around to installing Google Analytics on ourairports.mobi, the mobile version (for pre-smartphones) of ourairports.com, and this morning, I got my first stats: all of 3 visits yesterday (vs. 1,677 for the non-mobile site).
I expect that number to climb when the site is collecting stats for a complete 24-hour day, but already, I’ve noticed a significant difference in use:
| Site | Visits | Page views | Pages/visit |
|---|---|---|---|
| Mobile | 3 | 93 | 31.00 |
| Desktop | 1,677 | 4,748 | 2.83 |
Of course, the mobile sample is too small to be statistically significant, but it still made me think about how a mobile user will use the site:
A closer look at the analytics confirms that hypothesis, with a small number of airports updated multiple times (there were four pageviews for Sunbury Airfield in Australia, for example).
Further hypothesis: timely data is important for all web users, but it may be disproportionately important for mobile users. If this is true, it’s probably worth spending less time trying to make your mobile site (or app) look like a fourth-year graphic design college project, and more time making sure that it has the best, and most recent information.
I’ll watch the analytics for ourairports.mobi over the next month to see if this trend continues.
So what happened last week? Did Google backtrack after getting caught trying to be evil about net neutrality and the mobile internet, or were they a victim of a misunderstanding (gleefully amplified by blood-thirsty Apple and RIM supporters)?
Net neutrality is a crucial issue for those of us who care about open information. We believe that the Internet is a public thoroughfare, where every information provider has the same access. Competing web sites shouldn’t have their traffic slowed down because Google or Microsoft paid more money to Verizon, Rogers, or Bell, any more than you should have to pull to the side of the road to let someone in a more expensive car pass you.
For obvious reasons, the Internet providers don’t see it that way. They’ve ended up stuck in the rut of commodity service, with the inevitable race to the bottom for price, and are desperate to find some new revenue. The mobile Internet providers are a little better off because they can at least lock customers into three-year contracts by giving them subsidized smartphones, but it’s still clear that someone like Verizon would be thrilled be able to take a big bag of money from Google in exchange for letting Google sites load a little faster than anyone else’s.
It turns out, though, that that’s not what Google was trying to do.
The Google-Verizon kerfuffle draws attention to a different, and trickier part of the debate. What if, instead of discriminating by provider (Google vs Facebook), carriers discriminated by traffic type? In other words, what if streaming audio and video got priority handling to avoid jerky playback, while e-mail was delayed an extra 2-4 seconds? All streaming video would get the same treatment, whether it comes from YouTube or a student’s dorm-room start-up, and all e-mail would get the same treatment, whether it’s from IBM or a LOL cats fan list.
According to Google’s CEO, Eric Schmidt, this is what Verizon and Google were talking about all along: not favouring one provider over another, but favouring one content type over another.
I expect that many people who support net neutrality for providers won’t feel so strongly about net neutrality for content types, because it doesn’t have the same appearance of unfairness.
Going back to the thoroughfare analogy, we have sidewalks where only pedestrians are allowed, paths where only cyclists are allowed, crossings that pedestrians aren’t allowed to use, and superhighways where only motor vehicles are allowed. Buses and carpoolers are sometimes allowed to use a faster lane, trucks are sometimes required to stay in the slower lanes, and so on. Why can’t we have different lanes for different kinds of network traffic, too?
There are, however, four compelling arguments in favour of net neutrality by content type as well as provider:
Google is a company that embraces failure, which, perhaps, is why it has so many successes: Google puts products out early, lets us play with them, then feeds the ones that succeed (e.g. Gmail) and kills the ones that don’t (e.g. Wave).
Perhaps Google is willing to try the same thing with ideas — they’re not necessarily evil for suggesting dropping net neutrality for content types, but they are wrong. Let’s treat the whole thing as a failed project and move on, concentrating on making the net (mobile or desktop) faster for all providers, and all content types.
The Balisage 2010 conference runs next week in beautiful Montreal, focusing on XML and other markup technologies. I cannot make it this year, unfortunately, but I gave some help (far too little) to Sam Wilmott to organize the silent auction.
The Balisage silent auction will raise money to help students and other young, up-and-coming markup stars to defray the cost of attending the conference: the auction includes O’Reilly books, various enterprise software licenses, and geeky memorabilia. We’re encouraging participants to splurge, and try to outdo each-other by overpaying for things. Most of us can’t afford to blow $20-50M on a bizjet, but we can certainly drop $50 on a $25 O’Reilly book and then brag about it to our friends.
Think of it this way — Montreal, with its Vegas-of-the-North attitude towards sin, offers far less savoury places to stick a few $20 bills. Why not put them somewhere that you won’t have to lie about when you get home?
Now that I’ve had a few weeks to play with my Nexus One, I’m starting to grok the gut-level experience of living with a smart phone. I understand why people download apps, how it feels to have the Internet with me everywhere, and what it’s like to experience the web by touch on a screen that’s only a few centimetres square.
Device-specific apps are sweet and shiny at first, but after a couple of weeks, it becomes obvious that many of them are the encore of the floppy-based PC shareware world of the 1980s and early 1990s (SEND $5 TO GET RID OF THE ANNOYING ADS! ONLY $10 FOR THE FULL VERSION!).
Discovering an interesting app through Apple’s or Android’s market (or taking a picture of a barcode on your computer screen) is surprisingly awkward compared to just following a link from one web site to another, and as we’ve learned from the postal service, the telegraph, the telephone, email, and the web, connectivity always wins in the end.
Web apps run everywhere and connect to each-other seamlessly, and HTML5 allows a well-written web app to do almost everything a closed, device-specific app can do on a smart phone — many of the mobile web sites I’ve used (hello, Google!) are as good as or better than the corresponding device-specific apps. There are some things, though, that make mobile web apps stand apart:
I don’t consider most of these to be a big deal, but they do point to the fact that no matter how much extra functionality HTML5 provides, web apps have a different world view: they’re nodes in a huge network, not standalone silos.
I’ll probably have to continue to use a device-specific app for anything related to playing music or capturing photos/video for a while longer, and I’ll hang onto the Android WiFi analyzer I’m running on my phone. Android has a lot of the same apps that show up in iPhone commercials (like Urban Spoon), but while they’re pretty, they’re limited in the end — there’s way more out there on the web than there will ever be an an app store.
If you’re an person or organization that wants to interact with people on mobile devices, you have two choices:
The first option lets you force an icon onto the users desktop, but the direct development costs and opportunity costs of losing inbound links and search-engine love just seem too high.
I left this comment on Simon St-Laurent’s interesting and thoughtful post How dare Apple … (which, in turn, was partly a response to Tim Bray’s post Nothing Creative).
I don’t believe that most things, including the iPad, are obviously right or wrong, but I do have serious concerns that go beyond simply not being able to code on an iPad (at least, until there’s an app for that). I’m copying my comment here to give it a more permanent home. If I hadn’t posted this yet, I’d edit it to tone down the emotional language 10% or so, but still, it’s a fair reflection of my thoughts and concerns, not about the iPad itself (it’s just another consumer device), but about the way people are starting to talk and think about issues that are very important to me, like software freedom:
The thing about creativity is that it responds poorly to central planning and central control. I have no problem with the fact that the iPad isn’t developer-friendly — I can buy a Netbook with twice the power for half the price and code on it (and, BTW, that netbook makes just as simple a consumer device).
My problem is the idea that a single Apple politburo controls everything that can appear on the device. Is that the future? Even in the bad old days of TV, before cable, there were 3 1/2 US networks to choose from, not just one – you had to watch TV outside the US to see just how bad things could get with a single, government-controlled broadcaster (I grew up in Canada, but close enough to watch the US stations, thank god).
Apple’s obsession with central control goes beyond software to hardware. There must be some kind of port for the optional keyboard to plug into, but no way it’s going to be USB or Firewire, because that might let someone use an *unplanned* creative device on the iPad, someone creative daring not to give Apple its cut (and veto). If I build something clever for creative people using a USB interface, it will work with desktop towers, notebooks, netbooks, and even some small portable devices, but *not* with the iPad.
Apple has some smart people working there, but they won’t always have the best ideas, and Apple has thrown up too many barriers to other people with smart ideas. The best apps in the future are going to come from a couple of students coding in a dorm room, and they might just be so annoyed by Apple censorship that they defect to a freer platform. It’s sad that things have gotten to the point that even Windows is a freer platform than Apple.
Quoderat 