A few months ago, I have reported about
getting the winmodem in my
hp compaq nc 8000 to work.
Aside from the abysmally slow performance, the dependency on out-of-tree, non-free modules has been cause of grief
since it has almost constantly forced me to keep an outdated kernel version around just in case that I would need the
modem.
Fortunately,
this is over now since more recent kernel versions (I suspect somewhere in the 2.6.16 era) support
my winmodem natively without out-of-tree modules. All I need to get only on a POTS line is sl-modem-daemon, which is
reasonably painless.
Back in the embarrassingly early part of this year, I wrote a blog entry on
music that I liked
to listen to whilst cutting code. I solicited feedback, and promised a
followup. Technically, I didn't say
when I'd be posting a
summary, so I don't feel quite so bad about leaving it for 9 months before
posting this followup.
Firstly,
Matthew Davidson
gave a lengthy treatise on
The Fall, whom
I'd never heard of before, and actually haven't gotten around to listening
to yet, either (shaaaaame!). It certainly must do the trick for him,
though, because he says:
I try to avoid programming wherever possible -- I know how it's done, and
really appreciate it when it's done well, but I generally find doing it as
much fun as a trip to the dentist. However, put a bit of the Fall on, and
I find myself settling into a pretty productive groove without much
trouble.
Next up, Decklin Foster pointed me to where I could do my own research --
the
Debian
Developers group on
last.fm.
Although I've glanced at last.fm now and then, I've never really gotten
into it much. I suppose I should harness the hive mind and find more
music similar to that I already like -- you can only listen to your old
favourites so many times in a row before they start to wear out.
Apparently, my tastes in coding tunes isn't unique --
Roger
Barnes shares my preference for the quick-paced abstract:
When I'm coding though, I prefer something fast and electronic. I think
this is for two reasons, one is the rhythm tends to get my mind going, and
the lack of vocals means that there are no words disrupting my thoughts.
As does
François Beausoleil,
who says:
I have the same need as you for loud, fast and driving music. Personally,
I've been listening to Born to be alive, the first Matrix's theme song,
Confusion from New Order of the Blade soundtrack.
Since the original Music To Hack To post, I've been listening primarily to
the
Chillits
2005 sets whilst coding. In the words of Boing Boing (where I
originally found out about Chillits), "Every fall in Northern California,
the Chillits music festival brings together a stunning line-up of DJs who
spin mesmerizing sets of ambient and downtempo music under the sun and
stars."
The key word there is "ambient"; I'm not looking for something to
listen
to so much as I want
backdrop to my other
activities. The collection of laid-back and thumping tunes keeps a nice
work/relax rhythm going while I'm coding.
There are some immensely funny bits in some of the mixes, too, like the
(hopefully) mock ad for speed ("The little blue diet pill you don't have to
be overweight to need!"). Sometimes the tracks go into some area that bugs
the shit out of me, which is when I exercise the skip feature of my music
player, but most of it is pretty good at blocking out the world and letting
you concentrate on the code at hand.
There are many question what needs to be resolved to allow the new python-defaults into etch.
There are some packages that would become uninstallable by that now, and the task is to just
check them and fix them:
ethereal-dev, gaby, gforge-plugin-scmsvn, gnome-tasksel, gnuradio-examples, gr-audio-alsa, gr-audio-jack, gr-audio-oss, gr-usrp, gr-wxgui, guml, hplip, ifrit, ldaptor-utils, ldaptor-webui, lfm, libghc6-missingpy-dev, mboxcheck-applet, med-bio, memaid-pyqt, mock, musiclibrarian, ocfs2console, omniidl4, omniidl4-python, plywood, positron, pydict, pyftpd, pykdeextensions, pymol, pyntor, pypanel, pyrad, pyslide, python-dispatch, python-gdal, python-gdchart, python-gdchart2, python-gdk-imlib-1.2, python-glade-1.2, python-gnome-1.2, python-gnuradio, python-gtk-1.2, python-ldaptor, python-mapscript, python-metakit, python-moinmoin, python-notify, python-numeric-tutorial, python-phidgets, python-protocols, python-sip-qt3, python-turbojson, python-usrp, python-zeroc-ice, pythoncad, pytone, releaseforge, rubrica, scalemail, scanerrlog, scigraphica, snappea, snappea-dev, spikeproxy, sql-editor, viewcvs, viewcvs-query, wireshark-dev, xen-ioemu-3.0, xen-utils-3.0, xkeysw-config, yum, zeroc-ice
For example, gforge-plugin-scmsvn depends on viewcvs which needs to be converted to the new policy.
Everyone can take his share - just choose any package, look why it becomes uninstallable (perhaps
via a dependency becoming uninstallable) and fix it. Oh, and please set the urgency to high and make
sure prior to upload that the package still works.
(This is only the list on i386, but experience has shown that once it's resolved for the first architecture,
it isn't too hard to resolve it for the other architectures also.)
Update:
Some packages are already in the progress, e.g. ethereal-dev depends on wireshark-dev which depends on omniidl4 which has been NMUed
already. Well, like always: Check what the issue is before fixing it. And if binNMUs help, please just tell us.
2. Update:
It would be really helpful if someone could take care of viewcvs.
3. Update:
The most important open issues are: viewcvs, mapserver, moin (whereas viewcvs has a good version in experimental, maintainer is contacted).
Also, these programs might need some love to get converted to the new standard or have otherwise real NMUs:
blogtk boa-constructor codeville drpython fnorb freeloader forg fvwm-crystal gco gdebi gdeskcal gnome-btdownload python-visual gaby guml ldaptor scalemail lfm missingpy mboxcheck-applet yum mock musiclibrarian ocfs2-tools plywood positron pyftpd pyntor pyrad pyslide python-gdchart pygdchart2 libmetakit2.4.9.3 moin pythoncad pytone rubrica scanerrlog snappea spkproxy
Ajax isn't progress, it's actually a step back.
Most people have been happy to actually use some sane advanced language for
doing web sites. There is Java, JSP, PHP, Ruby, Python, Perl, ...
And then there is Ajax. One of the main components is JavaScript. That
language most of us would have loved to forget. Forever.
Ajax brings you back into the dark ages of internet development, with browser
incompatibilities, it features
memory leaks,
and many Ajax apps (such as
live.com) will run
unbearably slow on older computers. Such as my 1.8 GHz P4M laptop. If they
work at all - live.com just shows "Loading..." for me right now.
Have you ever looked at some of the actual Ajax code?
This isn't the future, this is the dark ages coming back!
[
MJ Ray replies that
I didn't mention accessibility issues with Ajax. That's true; I'm aware of
them, but this post focuses on Ajax doing away with all the advances in
programming languages and software engineering... The in-accessibility of Ajax
stuff is worth an own blog post sometime]
My
experimental
SELinux for Debian sarge backports have been updated. The core libraries
and utilities are updated to the versions just uploaded to unstable.
Therefore, they may of course contain the same bugs as the unstable versions
and since I redid the packaging of libselinux and libsemanage - I didn't
understand Manojs packaging system, and these packages needed larger
modifications for sarge python support - they may also contain extra bugs.
But even users of unstable might be interested in grabbing the "refpolicy"
packages from this repository. These packages are now a modular policy. This
is possible since the just uploaded toolchain finally has working policy
module linking and results in a significantly smaller policy, since
you don't have to add rules for software not installed.
To support this, I've written a tool to resolve inter-module dependencies and
to automatically install modules matching the software packages you have
installed. Expect to see this in the unstable refpolicy packages sometime,
too. Maybe someone else will contribute a ncurses frontend to select policy
modules.
Please note that bug reports should be directed to the
Debian SELinux
Mailing Lists. Please use the mailing lists, instead of just contacting
me directly.
On a side note, I don't know if I'll be continuing these efforts.
12:48 #ubuntu-ph: < jsgotangco> zakame: bakit higante hackergotchi mo
...
zakame@revan:~/planet-ubuntu$ cp /home/zakame/Documents/Pictures/hackergotchi-small.png heads/zakame.png
zakame@revan:~/planet-ubuntu$ bzr commit -m "Shrink zakame's head, doh"
Those of you who follow such things may have noticed that I became
SPI
President today.
The cool part, though, is how I managed to participate in the special board
meeting to select officers today.
The meeting fell in the middle of the drive from our house up into the
mountains to the
Rocky Ridge Music Center
near
Estes Park, Colorado,
where my daughter is attending a
music camp.
About 15 minutes before the meeting was supposed to start,
we drove out of the edge of GSM phone coverage just beyond the town of
Lyons...
I turned the car around and drove back into town and parked adjacent to the
surprisingly interesting Sandstone Park, which is part of a
sculpture trail
in the middle of town. My wife and kids wandered around
the park while I fired up my new
HP nc2400 notebook
and established a GPRS connection through my aging
Ericsson T39
phone using
gprsec, which
sadly is not yet
packaged for Debian.
Two minor hacks due to my choice of phone.
I needed the flag_time=0 option on the ppp_async module command line to work
around a bug in the T39 as per the
GPRS-HOWTO,
and noauth in the ppp config emitted by gprsec.
Participating in the meeting was painless, other than delaying our lunch for
a half hour or so...
It's really nice when things work the way they're supposed to.
TNTnet, just uploaded to Debian, looks
interesting. Basically it offers JSP-/PHP-like embedding of C++ code into
web pages (or the other way round). Well, if you want to be precise, the
syntax is actually much closer to
HTML::Mason, a perl-based web application
framework I've used some years ago.
You can bet that these pages, compiled into native code, are hard to beat
speed-wise... Think of compiling your website into your webserver.
It's obviously not suited for wide audiences - you can have your users upload
PHP files, but you probably won't allow them to upload C++ code - but more for
high-performance sites with specialized applications.
I have, however, one major gripe with it: The syntax is not XML.
I wish they would have picked true XML as data format, instead on basically
using string processing. I hate how many people treat webpages as mere
character strings with some special characters instead of structured data
serialized in some way or another.
I don't want to be stuck using a line-based editor for structured data
forever. I'm still using vim, and I'll probably continue for a while, but
for XML I'm actually just waiting for an editor with a true understanding of
XML and the power and speed-of-use of vim...
KID remains my favourite way of
generating web pages. It's templating transparently embedded in a XHTML file
using a separate XML namespace. And it's actually compiling the templates
into python modules.
P.S. if your ever need the
Dummy 16 and
Dummy17 functions, get them from microsoft (excel) now! No need to
write them yourself anymore! (Dummy 1-15 are apparently discontinued.)
P.P.S. I just wanted to point out, that I'm convinced that
embedding much
code into a layout file is a bad idea (one of the reasons why I despise
PHP). Keep logics and layout separate. KID for example is quite good at that.
In my
DNSoupdate
tool for example, all the template contains is loop constructs and simple
case disinctions. This also brings me to my biggest gripe with KID: it depends
on python. I don't see a way of using the same template with a different
language. So maybe I'll actually go back to some TAL solution or so that is
a bit more portable templating-wise (and still perfectly reuseable XML).
I need a new TV. I've have my current one for 6 years now and it was
secondhand when I bought it. Plus it gets this little green patch now and
then (which it's been doing for a couple of years). Not hugely annoying,
but everything helps in justifying a new one.
My current TV is a normal 25" 4:3 set. I've worked out that if I go
widescreen I need a 31" set to get the same height, which seems
perfectly doable. The tricky bit comes in that I'd like HD, as hopefully
the new TV will last me at least as long as the old one has. HD's only
recently been launched in the UK -
Sky brought out
their
HD service just in time for the World Cup
(though I understand lots of people who'd pre-ordered didn't receive
their upgrades in time).
Telewest also have
a recent HD service. Of course
NTL, who I have,
don't yet (despite them having merged with Telewest) and the Freeview
DVB-T trials are only in Central London. Anyway, I won't have HD signal
for a while, but I want to be ready when for when I do (and I'll be
hooking a media PC up to the screen anyway, so will be able to take
advantage of it via that method).
Sky appear to have decided on using 2 HD formats; 720i (1280x720,
progressive) and 1080i (1920x1080, interlaced). So having support for
those would be nice. In addition I'd like 1080p (1920x1080,
progressive), for things like the media box and in case content becomes
available in that format (HD-DVD/BluRay?). This doesn't seem like a huge
request. Lots of TVs in the UK are marketed as
HD Ready. What does that mean?
Essentially it specifies that the minimum native resolution of the
screen is 720 lines and that there is a digital (DVI or HDMI) input that
can support 720p and 1080i input and copy protection (HDCP). There is no
minimum width; the set is allowed to scale the image to fit whatever it
has. I've seen HD Ready sets that have a 1024x1080i native resolution -
not wide enough for a native 720p image let alone 1080i. However most
HD Ready sets seem to do 1366x768 as the native res, so fine for 720p
but not 1080i/p. sigh
I managed to find a TV from
Philips, the
37PF9830/10,
which does native 1920x1080p.
Amazon even
sell it, though for an eye watering £2,248.28. What does this get
you? Integrated Freeview decoder? No. MPEG2/4 playing of movies from
flash media? No, just image viewing. A nice big monitor for your
computer? No, Philips' website only lists 1024x768 as the max computer
res and I've seen reports in forums that 1366x768 is possible, but no
higher. There's a 42PF9830/10 (42") that adds movie playing and ethernet,
which sounds good but adds who knows how much to the price (I couldn't
easily find a UK price). Plus it's probably too large for me even if it
was affordable.
My naive hope is that with the Sky push lots of people will have got
sorted for the World Cup, or will go HD for Christmas. Meaning that come
the new year I might have a better available choice of proper HDTVs and
the pricing might be sane. I can dream, right?
Does it make sense to use a wiki for issue tracking instead of using a
standalone BTS? Martin Krafft suggested this might be a useful addition to
ikiwiki.
It seems to me that this would mostly be worthwhile if it took advantage
of the free form, open nature of the wiki in useful ways. Reconciling that
with some of the more structured needs of a BTS is an interesting
challenge.
Surveying a few examples of using a wiki as a BTS:
- jspwiki tracks issues in a
BTS built using the wiki.
They have a bug report form with several fields, basic queries for open and
closed bugs, and wiki pages for each bug with a table of the fields at the
top.
- ikiwiki tracks todo items using
a blog. Metadata is currently limited to tagging an item as done. (All
I've felt the need for so far; other tags could be used for things like
severity, versions, etc.) Each todo item is its own wiki page. You can
subscribe to RSS feeds of new or fixed items and use ikiwiki's standard
subscription features to subscribe to diffs of changes to particular item(s).
- trac does not seems to actually use a wiki for its bug tracking component
- pmwiki has an issue tracker
integrated into the wiki. Fairly
similar to jspwiki though seems less refined. Includes a wacky voting
system.
There is a definite feeling about all of these of finding a vaguely
nail-shaped bit and pounding on it with the wiki-hammer, but I'm unsure
whether it's really a nail or just an obvious pointy bit sticking up out
of the main problem of issue tracking. On the other hand, the same could
probably be said about a BTS built using a relational database.
David, you
wrote
about
Class::DBI performance.
Even without benchmarking you could have
found out,
that Class::DBI is quite slow. Fortunately there are some alternative
object-relational mappers available in the perl universe. The best ones I found
so far are
Rose::DB::Object and
DBIx::Class. I took a closer
look at both and would like to share my experience.
As
this shows,
RDBO is faster than DBIC in most of the case. The generated SQL doesn't differ
too much and therefor it must be the perl side of things that makes the
difference.
Matt S Trout <dbix-class@trout.me.uk> says:
However, RDBO achieves its perl speed by aggressive inlining of stuff
etc. - for example the main object retrieval function in RDBO's manager
class is >3000 lines in a single sub. DBIC values extensibility over a
few extra sub calls, so methods are much more broken out and there are
many more ways to hook into the DBIC execution process to extend.
Also its idea of resultsets is something I really love. Here's a small example to illustrate that:
my $user_rs = $schema->resultset('User')->search( registered => 1 );
$user_rs = $user_rs->search(
comment.title => 'Foo' ,
join => 'article' => 'comment' ,
order_by => 'user.name',
,
);
# no sql executed yet.
# now you can use your resultset as an iterator or query a list of User
# objects from it or ..
while (my $user = $user_rs->next)
...
# or
my $count = $user_rs->count;
Using these resultset makes it extremely easy to built up queries piece by
piece and to work together well with, for example, a templating system. You
don't need to fetch all row-objects and give them to your template. You can
just pass the iterator to the template library.
There's a lot more to say about this two object-relational mappers (for example
RDBO supports prefetching of multiple one-to-many at once, which DBIC doesn't),
but maybe you just should take a look yourself. I personally prefer DBIx::Class
for its vast extensibility.
Another thing I've been wrong about in the past? JavaScript. I've always held that it was a cheap, lame, ugly knockoff language little better than a spreadsheet macro tool. I'm happy to say that my recent revisiting of JavaScript in the last 2 years has proved me wrong. JS is crazy, bizarre, and convoluted, true, but it's got a fundamental simplicity that I find appealing. The prototype-based inheritance is wacky, too. Anyways, I was interested to see that the
ECMAScript 4 working group has published some specs for the next version of the language. It looks pretty cool.
Well, I have just finished setting up my virtual machine in a
hosting provider which offers a very nice virtual machine plan called
VPS.
It’s very nice because they give you full root access so you can install whatever you want to install. Also, it’s
Debian based and even the control panel they provide is as I like things to be : minimalist and easy to use. Sure, it works like a charm also.
I’m tired because I was fighting the blog system I installed for a long time trying to convince it to get installed in a proper VirtualHost but it kept giving me trouble everytime I tried to access its root page. I gave up and installed it in a directory under my default page and then it worked as expected.
Someday I need to take a closer look at it and find out what really went wrong. Well, actually, I know what went wrong and I even knew how one could fix the issue as I already fixed issues like this one lots of time in the past, but this time my tricks didn’t helped.
Anyway, mail setup is already working, complete with SSL-based IMAP/POP, SMTP-AUTH through SASL and all the basic services I wanted to have are already working. Now I think I can have some sleep a it’s past 4:00AM.
Well, enough for a first post.
I am one of the unfortunate hundreds of thousands of Verizon customers who eagerly ran out to buy the Motorola v710 Bluetooth phone when it first came out a couple of years ago. (For a short period of time, I could really turn heads with my wireless earpiece—now you look like an antiquarian if you
don’t have a Bluetooth headset). It turns out that
Verizon disabled all of the most useful Bluetooth features on the phone, and
a class action lawsuit ensued, which predictably
settled on terms quite beneficial to counsel, but less so to the affected class. The
settlement provided several options for Verizon subscribers who had purchased the v710, only one of which had a substantial monetary value—namely, a $200 credit toward a new phone (or whatever the actual price we paid for the phone, assuming we still have receipts).
The settlement period expires at the end of the month, so tonight I finally got around to cashing in on the victory.
I was quickly reminded of how much I hate shopping for cell phone technology. Verizon provides more than a dozen options for cell phones, each of them mediocre in its own different way. (I should also mention that the Verizon Wireless website is, itself, mediocre in many different ways.) Cell phones have been around for long enough that it ought to be fairly mature technology; instead, you have to figure out which annoying shortcoming bothers you the least. The most expensive of the non-Pocket PC models, the Samsung SCH-a630, despite having a 2 megapixel built-in camera, has a lower image quality than the cheaper “LG the V” (better known as the LG VX9800), as well as crippled Bluetooth like the v710.
I ended up settling on “LG the V,” despite its silly name and hefty form factor, because it seems to be the one model that Verizon decided not to cripple Bluetooth on. Apparently, it has complete
OBEX support, and
works quite well with Linux.
It gets worse shopping for Bluetooth headsets. None of the
top headsets recommended by cnet are even offered by Verizon. So instead you’re stuck perusing endless message board postings for threads with names like
Which Bluetooth Headset is best for VX9800? trying to figure out which, in fact, is the best Bluetooth Headset for the VX9800. While some aspects of a Bluetooth headset are obviously personal preferences based on, for example, the shape of your earlobe, how often you drive in a convertible with the top down while talking on your cell, and whether you like to wear your headset to bed, I would really appreciate some objective metrics and brand uniformity. There’s no way to predict, for example, whether a particular model of Motorola, Jabra, or Logitech headset will be any good—some seem to be well received, while others have glaring design flaws.
As a trademark lawyer, I’m disappointed by this state of affairs. I’d like to be able to identify a brand that I can trust and just go with it. This is especially true where it’s difficult to evaluate the quality of an item on first inspection (or over the Internet) and it’s an item you’ll keep for at least a while (two or three years for cell equipment). As things stand, there seem to be few real winners, and the search costs are inordinately high. Hopefully the invisible hand will eventually fix this situation, but I’m not going to bet on it.
And what about
Java Server Faces (JSF) in Debian? We already have Struts and it seems JSF could replace it. While googling around, I found a lot of websites, tutorials, plugins and so. It seems the JSF community is growing and the API seems powerful. I already work with Struts, maybe I have to have a look at this promising technology too.
If we put JSF to Debian, maybe we should start with release 1.1 because of the lack of free J2SE50 at the moment (even if ecj, classpath-generic-branche, jamvm are very promising). We’ll need (
list of dependencies):
I signed up for a
ZoomIn API Key (not that it seems to be needed atm…) the other week and finally got a chance to have a play this past weekend.
My test case was to build a map of all the
CRCnet sites and the links between them to use as a plugin in the
CRCnet Configuration System. Either as a dynamic status display (colouring links to show traffic loads and status etc) or as a network planning tool to get a feel for the relationship between existing sites and potential new locations. Obviously the lack of topographical information makes the second case far less useful than it could be, but I think even in 2D it would still be a useful tool.
Getting the points onto the map was relatively straightforward, but adding any sort of hover event to them was another matter. The GEvent class currently only supports the click event and markers are not added with any other identifying attributes (such as an ID or Name) which could be used to hook an event into them. After a quick squiz at the Terms and Conditions, I grabbed a copy of the API javascript and after unobfuscating it (basically just adding back in line breaks and running in through indent(1)) started to have a squiz at what was happening. The API code is very nice and clean and it wasn’t at all hard to work out what was going on. Mozilla’s Venkman javascript debugger absolutely rocks for this sort of work. It allows you to step through all the scripts on the page line by line and quickly get a feel for the flow of the code.
Adding support for the hover (onmouseover) event doesn’t look like it would be too hard, but the T&C didn’t explicitly mention whether I was allowed to actually modify the API code, so I choose to simply create a CRCnetMarker class (see below) that creates GMarker object and then pokes id attributes onto the internal objects of that class before returning it. Then once you’ve called addOverlay you can use the basic DOM functions to hook in an onmouseover event handler on the ID of the marker.
var CRCnetMarker = function (sitename, point, icon)
var marker = new GMarker(point, icon);
marker.icon.id = "crcnet_container_" + sitename;
marker.icon.firstChild.id = "crcnet_icon_" + sitename;
marker.addEventListener = function (eventname, handler)
b = document.getElementById(marker.icon.firstChild.id);
b.addEventListener(eventname, handler, false);
return marker;
var marker = new CRCnetMarker(new GPoint(2704685.21,6367057.51), "mph");
map.addOverlay(marker);
marker.addEventListener('mouseover', hoverHandler);
That worked like a charm and I now have nice little info boxes popping up next to each node when you hover over them. I also discovered in the process of implementing this that
Prototype and ZoomIn do not play nicely together. It appears to be Prototype’s fault as it messes with the Array type by adding new methods (like each for enumeration) which break the builtin for (i in array) syntax when the array contains non-numeric keys (like each). This has been reported in the
prototype bug tracker as breaking Yahoo Maps but the comments don’t seem to offer much hope for Prototype’s behaviour changing anytime soon which is a pity.
The next roadblock was a lack of support for drawing lines! This put the kibosh on the whole animated network status idea. Trolling through the source again reveals a GPolyLine class that appears to be semi-implemented, so hopefully support for drawing lines is coming very soon.
The only other thing I found slightly annoying was having to supply all the co-ordinates in NZGD49 format. Most of our GPS information for CRCnet is stored in WGS84 format (as that’s what our older GPS unit puts out). NZGD49 has been deprecated in favour of NZGD2000 (which is near enough to identical to WGS84 for normal use) so I’m not really sure why ZoomIn is still using NZGD49. Maybe that’s all TerraLink can supply?
Some quick googling turned up the
proj library (apt-get install proj in Debian) which provides the cs2cs utility which can convert from WGS84 (aka NZGD2000) to NZGD49 to feed to ZoomIn. The magic peice of information is the transformation parameters which
LINZ helpfully provide. Punching those (I chose the 7 parameter version) into cs2cs via a command line like
echo "$lat $long" /usr/bin/cs2cs +proj=latlong +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0 +nodefs +to +proj=nzmg +datum=nzgd49 +ellps=intl +towgs84=59.47,-5.04,187.44,-0.47,0.10,-1.024,-4.5993 awk ' print $1" "$2 '
performs the magic conversion.
The conclusion?
Overall I think ZoomIn rocks and it’s really cool to see a small NZ company filling in where Google and friends have failed miserably.
The biggest weakness at the moment is definitely the API, which doesn’t really allow you to do much more than add points at this stage. Given that ZoomIn is still relatively young the leanness off the API is understandable. Given the API a few more months to mature and fill out and I think we’ll be able to create some really cool applications on top of the ZoomIn platform.
Screenshot: