June 20, 2009
A few months ago, I had this idea, that I shared with a few people, for a cool iPhone app. The idea was roughly:
Take a photo. Use said app. Add a message. Pick an address (preferably out of your Address Book). And have it mailed out, without you having to look for a post office, a postcard or a stamp. And never have to worry about charges — it’ll just be billed via your account on file, either via PayPal or direct credit card debit.
The problem with this business model is that:
- I need to work out printers – there must be local printers in various locations, typically of the destination.
- I need to work out how postal services work, in general, and what’s the most profit-friendly option
The margins, I figured, will be low. The application will either work via (roaming – one would assume) 3G/EDGE, or a common WiFi network, which you tend to get pretty much everywhere these days. WiFi should be preferred, since you don’t want to be slapped with a large roaming data bill. 
Anyway, I purchased the iPhone 3.0 SDK about a month back, and started hacking. Finding a name was going to be interesting, since apps like iPostCard, already existed. Ha! Names are so important, I think.
Today, I read about how to Turn your iPhone photos into postcards with HazelMail. HazelMail does exactly what I was planning to do. They’ve worked out all the business aspects, too, and charge your account with HazelBucks (so 1 postcard = USD$1 basically).
The only problem I can see with this whole idea (HazelMail’s and mine)? Stamp collectors. Some people love stamps from foreign lands, and that is part of the appeal, of receiving a postcard. However, I don’t know that many stamp collectors these days, and I do want to send postcards, so this was really, just trying to scratch an itch, and I’m glad that HazelMail has done so. Time to give it a try, and work on my next app idea ;)
Posted on: June 20, 2009 11:58
June 19, 2009
Mike Ash:
RPRVT can be useful as a rough indicator for watching if the total amount of memory your program has allocated is going up or down. This is dangerous to rely on, however. Because this only tracks resident memory, if your program has started to swap then your RPRVT will no longer increase, even though you’re still allocating more and more memory. (To detect this, you can watch to see if VPRVT is going up, and the number of pageouts listed at the top of the screen is going up.) Conversely, the memory allocator doesn’t always give memory back to the system right away, so this number may not go down if your program is freeing memory.
Posted on: June 19, 2009 15:25
June 18, 2009
Excellent article about Parrot, by Allison Randal.
Parrot’s record for a language implementation was a conference session where the speaker implemented the basics of the LOLCODE language from scratch as a live demonstration. It was a 5-minute lighting talk.
I have to get the time to implement a DSL for something on top of Parrot, to see how it works. Right now I only compile Parrot to run Rakudo.
Posted on: June 18, 2009 14:57
Yesterday I saw a question by fREW Schmidt regarding where to place the validation code in your apps. I made a mental note to answer it, but as most of my mental notes, it was quickly forgotten.
Today, a new article describes the answer he got. In the end he decided to put the validation inside the model. I can only say: good for you.
But one of the reasons against the validation-inside-the-model that he received baffled me: Models don’t know about the current user (or other higher level information).
If your models don't know who is the person authenticated (and please read Yuval article about modelling identity to understand how complex it can become), then you are doing it wrong.
Models must know who is the authenticated user. They must know it because that is the only sane way to implement authorization inside your methods, and to generate a audit log of operations.
What I usually do is to create a Session class. For each request (be it Catalyst request, incoming email message, or XMPP request), I create a new Session instance initialized with the current user information plus some tidbits like channel (Web, email, XMPP) and IP address (if available).
Then all accesses to my API are either via the session object (create methods to access most important parts of your API), or by passing this session object to the API you are calling.
You should also use your Session as the access point to your logging and auditing capabilities.
The article mentions other issues like error messages. I haven't add the necessity of developing an application with multiple language support yet, but I think that the current throw-exception-objects strategy, with all the information (including the authorized user to figure our preferred language) will be able to deal with the problems that I can think of now.
In the end, I'm actually really curious about why would people think that putting your validation code in the controllers is a good idea.
Update: a lot of stuff in the comments if you care about this topic.
Posted on: June 18, 2009 14:20
June 17, 2009
Trusting Google with an even bigger part of my on-line life.
The background
For quite some time now I’ve been slowly handing my life over to Google.
In 2005 I started by entrusting it with the access stats of my site.
Then in 2007 I made the big move of having it handle my mail by way of supporting my domain in Google Apps. This also meant that I automatically gained XMPP accounts (or Google Talk accounts if you prefer) for the accounts on my own domain.
By early 2008 I tried (without success) to have Google support my calendars and contacts and by late 2008 even my feed reading needs were taken over by the big G.
The old setup
Thus far I’d been using a system based on my own server at home which basically consisted of using MAC OS X’s iCal for the calendar and Address Book for the contact management.
One of the most obvious and important features I absolutely had to have was full two-way integration (i.e. synchronization) with my phone which, with my recent acquisition of the HTC smartphone, meant that I had to install a program that provided an ActiveSync interface to the MAC OS X sync service. I found that “The Missing Sync” by mark/space was ideally suited to this end and I was a happy user for quite some time.
Apple’s products work great and are more than sufficient for my needs, and I grew ever more fond of the features they provided and which Google Calendar and Gmail contacts’ support sorely lacked.
Time passes… And since I’m not eaten by a Grue I keep looking around for alternatives.
Not that I dislike my old setup all that much, but I’d rather have something that automatically synchronizes over-the-air (thus releasing me from the need to dock my phone at home and only then have it synched-up) and that would let me edit my appointments even if I can’t use my phone at that particular time and I’m not home (I grew fed up with running VNC over my home ADSL line, especially since it’s reliability is less than stellar). Also I’ve grown way too tired of managing my own infrastructure. Life’s too short to waste it managing servers, connections and stuff. I’m old, I want things to “just work”. Preferably by magic. Or something undistinguishable from it.
Are we there yet?
It has been apparent for some time now that Google is starting to pay much more attention to the needs of the “enterprise users”. Indeed it has been wooing the corporate folks with increasingly better features in it’s Google Apps offering, for example, and quite recently I came across news of it offering nice ways for the suit-and-tie crowd to connect their Outlook clients to Gmail’s servers (or something to that effect).
This got me thinking that it was high time that I went over to the admin pages of my Google Apps account and looked around for new stuff that might have popped up in the mean time.
And lo-and-behold, we now have the ability to sync up a mobile device both with Google Calendar and Gmail (for the contacts). This sync service is provided for a number of platforms which I already new about, but what struck me the most was that they provided an ActiveSync server for the users to sync up with.
Woha! The announcement of this feature must have slipped by me some time ago, but this means that I can now sync my phone effortlessly with Google’s services. Over the air. “Magically”.
This together with the fact that Google Calendar’s been getting pretty decent lately (feature- and stability-wise) and that Gmail’s handling of the contact’s information got a really nice bump (feature-wise) some time ago means that it was indeed high time I gave it another go. And a rather serious one at that. Even with all the warnings that Google plasters in our face when we go through all the hoops of activating the sync service. What can I say, I like to live dangerously.
Well… No, not really, I’m just rather lazy and I’d much rather the good folk at Google deal with supporting the servers than having to do it myself. :-)
The new (currently under evaluation, but looking rather good) setup
So now the time has come to finally switch over my calendar and contact management system to Google’s care.
I then proceeded to subscribe my external calendars on my Google Calendar, exported my own calendars from my server at home and imported them into my own calendar at Google, cleaned-out the mess that was my contacts list at my main Gmail account (and did so by nuking it entirely, a move which, in hind-sight, was not all that smart, as it forced me to re-request the authorization for every XMPP contact on my pidgin roster, but I digress), exported my contacts from my address book at home and imported them, nice and clean, into my Gmail account.
I then proceeded to zero out my phone (first sync is always a bitch if you have information on both sides, I’d rather not risk it. Well, that’s not entirely true, I did risk it and ended up with loads of duplicate information, so the second time-around I just nuked the phone’s data and was done with it) and sync it with my Google Apps accounts.
And I found…
Bliss!
So far I’m rather impressed with the result. I’ve been toying around with changing things on the phone and on the web interface and so far all is smooth sailing. What small differences I’ve noticed from my previous experience with data synching are easily overlooked for the benefits I get from this setup.
As it would happen, just this morning the “sync” link on my Google Calendar page stopped working (which got me worried about the possibility that the service might be pulled off the air), but then this afternoon the link returned and, with it, a new calendar emerged automatically on the “My Calendars” list —the “Tasks” calendar— together with the “Tasks NEW!” link on the top of the page.
Now Google Calendar’s documentation on synching (the link which disappeared temporarily) clearly states that Google’s sync service only supports calendar and contact data, not tasks, but maybe this is up-and-coming soon? Not that I care really, I never used tasks all that much and for the really important stuff I’m perfectly happy with using Hiveminder anyway.
So now I’ve taken the plunge and switched to using Google’s services to manage my contacts and calendars and I’ll force myself to keep at it for a few days until I reach a final decision on whether I should keep it up or drop it and roll back to my previous solution.
Please, please, let it work! I really want to drop the home server and this is
a huge step in that direction!
Please note that I’ve enabled the testing of Beta(er?) features for my Google Apps, something that more sane (or less risk-inclined) people may not want to do and some of the stuff I described surely falls under this category.
Posted on: June 17, 2009 19:16
June 16, 2009
Last year I worked on NCIDpop, a network caller ID client originally written by Alexei Kosut. I spent a day or so hacking on NCIDpop last month to fix some problems I and others had noticed. My changes have now been incorporated in an official release.
What’s new:
- Address Book reverse lookup support: NCIDpop will display the caller’s name, phone number label (e.g., “mobile”) and picture instead of the caller ID if the information is available in the Mac OS X address book. Also, when you double-click a caller entry in the call log, it’ll open the corresponding Address Book card rather than doing a reverse lookup.
- Don’t reformat non-numeric 10-digit numbers (e.g., turning Vonage’s click2call into (cli) ck2-call).
- A few small memory leak fixes, thanks to the Clang Static Analyzer.
- Updated reverse lookup URL list (some providers had consolidated or changed their URL format).
- Bug fix: handle NCID servers specified by IP address instead of hostname.
- Bug fix: properly reconnect to the NCID server on wireless network changes (SCNetworkReachability behavior is…interesting, and I had only tested 0.9.14 with wired networks).
Once again, if you’re wondering “why use NCID when I already have caller ID?” If you have SIP service (e.g., Vonage) at home, NCID/NCIDpop gives you caller ID on the first ring on every computer display in the place, which can save a lot of unnecessary running around to try to find the phone.
Of course, it’s just in time for me to consider giving up phone service at home as I’ll be spending much less time there in the fall. I’m overdue for a new mobile phone, but I can’t decide between an iPhone 3G S, the Palm Pre or perhaps waiting for a future Android device. I haven’t played with the Palm Pre yet; that’s on my schedule for next week.
Also: Jython 2.5 (final) was released today! It’s been a long while coming. We’ve still got a lot of work to do, particularly on performance and Java integration.
Posted on: June 16, 2009 19:33
The Lifestream concept is one that appeals to me in a really strong way.
I have (like most people) loads of content I produce on-line almost every single day of my life —of which this weblog is the least part, actually— and (if only for my own sake) I’d really like to have the possibility of reviewing it in a time-line and aggregate fashion. This is a need I’ve felt for a long, long time, since before the “Lifestream” term was even coined.
Now this concept has been gaining some attention from many people (as it obviously would) and a few services have appeared that address this need in different ways.
My own forays into using these services have been somewhat limited. I’ve been using my FriendFeed account as a kind of content aggregator which can produce a kind of lifestream (which powers the side-bar mini-lifestream gadget that I currently —as of this writing— have on the weblog pages) and that has been going well for the most part.
More recently, however, the concept has been gaining even more traction (as demonstrated by the amount of content generated on the lifestream blog) and a few services have surfaced which are even better suited to this end.
After having messed around briefly with a couple-three of them I seem to have settled —for now at least— on the Storytlr one and I must say I’m quite impressed.
The design is not all there yet (and knowing me it will be a long, long time before it is), but you can take a peek at it at http://lifestream.nunonunes.org/. Neat, heh?
Posted on: June 16, 2009 10:55
AnyEvent and all of it’s associated modules are my new best friends. In particular AnyEvent::Mojo.
I’m running it over libev (by way of EV) and it seems pretty impressive so far.
There, I’ve blogged again. :-)
Posted on: June 16, 2009 10:34
June 15, 2009
Pierre Igot:
I must say that this discovery leaves me mightily impressed. There is just no comparison with how Safari 4 scales pages and how it used to be in previous versions of the browser, or how it still is with several other browsers.
Posted on: June 15, 2009 13:39
Jesper:
One of the most perplexing things about Snow Leopard has got to be what’s happening to QuickTime.
Sounds like a big improvement, but there’s some strangeness.
Posted on: June 15, 2009 13:12
June 14, 2009
This is an update to an item originally published on Tuesday, 3 January 2006.
Update: For those of you coming here via search engines, a year or so later most of this was re-visited independently by Doug Hellmann on an article on Python magazine, which included a comprehensive solution - a copy of which I include here for archival purposes. His solution does not use SINCE to do incremental updates, but if I ever need to re-visit this, I will try to merge his code and mine.
I am currently in the process of coding a couple of Python classes to handle IMAP accounts, and am in awe at both the arcane complexity of RFC:3501 (which has a great many number of wonderful and useful things to learn) and the utter stupidity of whoever designed the Exchange renderer for the Calendar folder.
Yes, I am trying to read my appointments via IMAP. Don't ask why. Honestly.
All you need to know is that the asinine way in which the Calendar IMAP view was implemented has no way whatsoever to permit you so much as guess at item's actual appointment date without slurping and parsing the whole of the fake RFC:2822 body and the internal vCalendar - the date you get on the headers is the date an item was added to the folder.
Which, incidentally, is driving me up the wall - I know how good MAPI is, how Exchange works internally (at least until version 2000) and can't for the life of me figure out why they didn't add a simple X-Appointment-Date: header - would save me a world of bother.
Fortunately, Exchange honors SINCE, which means I can do a full Calendar scan once and then check back for any updated items (I hope - I still haven't checked what happens if I for some reason update old items).
Obviously, there isn't any way to get at the actual event data beyond the stingy sample you get on the vCalendar (which, incidentally, seems to be mis-encoded if your location or names include accented characters).
I sure as hell hope they change this in Exchange 12. Exchange is still the best corporate e-mail server as far as I'm concerned (provided you know what you're doing with it - which includes being absolutely positive you need it), but it has some amazingly limited and short-sighted "features".
Or, should I say, "incentives" for you to use Microsoft clients.
☯ (comments allowed)
Posted on: June 14, 2009 21:30
Lukas Mathis:
The stop/reload button doesn’t immediately switch from one state to the other anymore. Instead, there is a quick fade between the two states. During the fade, clicks on the button are ignored, so when you want to stop loading right when the button switches from «stop» to «reload», the click is mercifully ignored.
Posted on: June 14, 2009 20:40
Over the past two years, posts on this blog have slowed to just a trickle, and a number of TextMate users have asked about TextMate’s status, or publicly worried about its future. This blog post, the first I’ve written here in a long time, is an attempt to assuage those concerns and answer some of the most frequent questions.
In short, TextMate development is going strong: TextMate 2 isn’t done yet, but progress is steady, it is starting to take shape, and the end is in sight. The rewrite has been a slow and careful process, but the ideas behind it are exciting. I hope to publicly describe some new abstractions in the coming weeks and months. Moreover, the community continues to churn out new bundles and features for TextMate 1.5, and I’ve been building up a backlog of posts describing them. While I am not writing to announce a release date for TextMate 2, I do hope that this post will be the first in a series showing a bit more transparency.
The requests for TextMate 1 have mostly been incremental additions such as split views, chunked undo, and editing over SFTP. But TextMate 2 is about more than new surface features. Every part has been completely rewritten to take advantage of the lessons learned from the years of version 1. Not only are the low-level data structures chosen for increased flexibility, but the abstractions on which TextMate is built—snippets, scope-based language grammars, context-dependent settings—have been rethought and are more powerful than ever. In the coming months, I’ll try to describe some of these new abstractions, but for now, know that I am excited about the new ideas involved.
So where does development stand for 2.0? It feels to me like most of the modules are getting close, say 90%. But as they say, on the horizon, mountains look small. While I use 2.0 for my own work, day-to-day, and the basic infrastructure is pretty solid, much of the front-end still needs work, and for now it’s all lacking the spit and polish of a finished app. Hopefully an alpha version will be ready before too long, but I can’t make any promises about dates.
And why haven’t I been better about keeping the world informed? It is a combination of many things really, but the main issue is that I am not good at writing for a large audience. I am more into informal conversations, for instance over mailing lists or on IRC. So while I started a lot of posts, I end up unhappy with them halfway through, and they don’t get finished or published. I am taking measures: I have enlisted a technical writer to help bring this blog back to life, and I’ll try to communicate more of TextMate’s status and direction through him.
Bigger than either of those problems though, as I mentioned, is that TextMate 2 is no minor facelift. It’s a major undertaking with a long timeline and its final form isn’t fully settled. I don’t want to hype vaporware, and I don’t want to get anyone’s hopes up before I know I can meet their expectations.
Furthermore, I haven’t wanted to throw ideas onto the internet without having a chance to implement them myself. I’m humbled that TextMate has served as inspiration for many other products, and I hope that it continues to be a model for other developers in the future, but I want to see my ideas done my way first, before I feed them to the competition.
I am trying to slowly turn this boat. With this post, I hopefully am showing that a hand is at the wheel. I know I’ve been quiet too long about my plans. I can’t make up for that, but going forward, I aim to do better.
Posted on: June 14, 2009 07:31
Marco Arment:
The majority of the audience was clearly there for the Q&A. As people lined up at the microphones around the room, the presenter abruptly showed a simple slide with only “WWDC” in plain lettering, thanked us for coming, and bolted off the stage. The Apple engineers, usually staying around the stage for one-on-one questions, were gone. The lights came up instantly, and it was the only session that didn’t end in music. The audience was stunned.
Posted on: June 14, 2009 01:12
