Archive for the ‘blogging’ Category
Cough, Cough, Cough
Very sorry for the hiatus, everyone (all twenty-some of you, according to Feedburner — it was forty-plus until Oct 1, then Feedburner’s stats rolled over and HALF OF YOU DISAPPEARED!!!). I know I just blew my “every two weeks” rule. And my hoary old excuse — “I’ve been sick” — has only one redeeming quality: boy, is it ever true. Our two-year-old brought home a cold that went straight to my throat and destroyed my vocal cords on the way to my lungs, where it transformed into a baker of the worst cookies ever. EVER. Combine that with some epic work-related stress immediately prior, and you have the perfect off-the-air recipe.
I’m not 100% yet, but I’ve gotten well enough to be able to think about things other than child care and how sick I am. So, my apologies. I’m about to go into high gear to make up for it — I’ve actually got about a dozen posts saved up and they’re going to start hitting every few days for a couple of weeks. Stay tuned, there’s a veritable manifesto on the way!
Ultimately I’m shooting for more of a weekly rhythm (if not more often), since biweekly is just too seldom.
Anyway, thanks for your patience, and I’ll try to stay healthy for a good long while. (Though with a baby AND a toddler in the house, and winter coming, good health is a guaranteed impermanent condition….)
Go Energy
Dave Winer had a good post a while back about Stop Energy. He defines it as the drive to naysay, to oppose. He doesn’t use the opposite term Go Energy, but I will: Go Energy is what it takes to move forward, to make something happen.
Dave was characterising Stop Energy (and its converse) in terms of community dynamics, saying that some people in a community (software community especially) are driven by Go Energy, and others are driven by Stop Energy. Seems to me that’s a stretch; in any community there are differences of opinion about which direction to go, and one person’s Go Energy can be another person’s Stop Energy. But actually this post isn’t about communities at all.
I find that my own personal time is very driven by my own personal supply of Go Energy (“Go” for short). I’ve got a built-in pool of Go. When it’s fully charged up, I can hack like crazy on my own time — I had a whole lot of Go this spring when I did my GWT/Seam hacking.
More recently, my Go has had another focus altogether — my wife had a baby four weeks ago. Leading up to that, the subliminal anxiety of late pregnancy was definitely draining my pool. The odd part is that it wasn’t completely emptied — there was one particular work task that I really wanted to get done, and so even while taking three weeks of paternity leave, I had enough pre-existing, pre-baby Go to carry me through completing that work.
Now, though, my leave is over, I’m back at work, and my personal Go has got up and gone 🙂 It’s going to be a while before I build up enough Go to start doing some personal hacking. Blogging I can do on my hour-long train commute, and it also requires less Go than hacking, so I’ll be continuing that, but open source work is going to be on hold. Sorry, Jason E., Dan M., and others who were looking forward to having me back! The rest of 2007 is likely going to be fairly low-key.
Thanks for your patience, and I hope the blog tides you all over until the Hack is Back! I’ll try to stick to posting here every two weeks, now that the baby’s sleeping a bit better.
Every Two Weeks
[Crossposted to my other blog.]
Blogging’s still new to me. The only thing I really know about it so far is that while there’s an infinity of posts to make, there’s only finite time to make them. And that time is in high demand, mainly from family, but also from all the other great projects that aren’t blog-writing.
So I have to set some kind of deadline for myself. And that is: two weeks. I must, and will, post in both my blogs at least every two weeks.
I’m setting that deadline because I notice my reaction when going to other blogs: if I see the latest post is a month or more old, it’s a sign that the person’s really way too busy to blog, and that the blog’s an afterthought to them. It’s also a sign that who knows when the next post might be?
But if the last post was a week or so ago, that’s still timely. Two weeks is pushing it, but based on my experience so far, it’s the most I can commit myself to.
So, that’s my promise to you: I’ll update both my blogs every two weeks at most. Feel free to flame me if I don’t!
…Except for the next month, because we’re expecting my wife to go into labor sometime in the next three weeks, which means all bets are off 🙂
Hiatus
Sorry for the hiatus of the last few days. My parents are in town and there’s been lots of grandparental fun, and I’ve also been kind of blocked on posting here.
I’ve been in a quandary about this blog, which is that I have too many topics I want to blog about, and not all of them are actually software-related. Should a blog titled robjsoftware.org have posts about religion, or family, or whatever else I might want to say that isn’t really code-related?
After getting a lot of advice from various people (thanks Bill Harris, Francis Potter, Bob Lee, and my father Norman), I decided that no, it shouldn’t. Part of blogging is developing an audience, and I’m not (quite) egocentric enough to think that everyone who’s interested in my programming posts will share all my other interests. I’d rather have opt-in than opt-out, in other words.
So I’ve started another blog — blog.robjthoughts.org. That’s where all the non-software topics will go. I’ll occasionally crosspost, but it’ll be very much the exception. I’ve also cleaned up the labels on this blog to avoid the weirdness of a “non-software” label on a blog named “robjsoftware” 🙂
Thanks for your patience. Now that my definitional issues are sorted, content will resume flowing shortly. (And I promise I’m done making new blogs now!)
Blog dilemmas
- Many small posts or few large ones?
- Why does Blogger do such a terrible job of scaling your profile picture?
- Should I tell everyone on God’s green earth about my blog right away, or should I post a lot and then start spamming about it once I actually have some content?
- How many people actually read through your back posts anyhow?
- Given that there’s only so much spare time, how much of it should I spend programming, how much should I spend blogging, how much should I spend reading blogs, and how much should I play one of the dozens of computer games that stare at me longingly from the shelf, wondering where my love went?
- Is this template just too ugly for people to stand for even one minute?
- Why is Blogger’s edit window so d**n small?
- Can I say d**n without the asterisks in this blog?
- Is editing posts after they’re published bad form, even if you think of lots of things you forgot to say?
- Am I interested in — and liable to blog about — too wide a variety of topics to attract any readership whatsoever?
- Who is this blog for anyway, myself or everyone else? Is blogging like art — something that exists only in relationship to an audience?
Why Blogger Needs Offline Editing Support, and How To Build It With Google Gears
I’m writing this in Notepad while riding the BART train on my normal morning commute into San Francisco. This commute takes about forty minutes each way for me. Since there’s no Internet, I can’t connect to work at all. Hence this is dedicated time for reading, or writing, or hacking on things that don’t need a full development environment (my laptop is a bit too old to cope with our entire code base from work anymore).
So of course blogging would be a natural. And sure, writing in Notepad is not torture. But it’s also not the right thing. What I want is to be able to write blog posts, edit them, save drafts, etc., etc., and then the minute I get back online, upload ’em all to Blogger and worry no more about it.
To do that requires some kind of offline application with local storage. As my last post mentioned, I originally wanted to build such an offline app as a standalone Tomcat-based Seam webapp that would run in a local webserver. But Google Gears offers a much more direct route to the same destination.
So this post is a breakdown of how to construct such a client, based on conversations with various Googlers last week at Google’s Mountain View developer day.
The Requirements
Must-have requirements for an offline Blogger editor:
- be a web application running in the browser (duh!)
- support rich text editing at least at the level of Blogger’s own online editor
- support authentication to Blogger
- support local storage of some or all of the user’s blog posts
- support creating, viewing, drafting, and editing of posts whether online or offline
- allow synchronizing any offline edits to Blogger once back online
- allow synchronizing of any posts edited on Blogger down to local storage
- allow very minimal reconciliation of conflicting edits to posts on Blogger
- require minimal installation of plugins or other application-specific software
Nice-to-have requirements for an offline Blogger editor:
- support archiving / backing up of a user’s entire blog
- support re-importing some set of content to a new blog that supports the Blogger API
- support migrating content between blog services
- support deleting postings ahd handling synchronization of offline deletes
- provide a nicer browsing/reading UI (arguably Google Reader has this job sewn up already)
(Needless to say, the nice-to-haves don’t get done until all the must-haves are working!)
Explicit NON-requirements:
- No need for this application to render any static HTML (the blog can presumably still be viewed and searched through Blogger itself; this app can be *just* an editor)
The API Implementation
Clearly this is exactly the kind of application Google Gears was created to support. So let’s assume we’re using Gears. Further, since I like GWT a whole lot, let’s also assume we’re using GWT.
I originally thought that this app could be built as a GWT/Gears webapp connecting directly to the Blogger API. Dan Morrill of the GWT team set me straight on that. The Blogger API is very pure in its REST-fulness, meaning specifically that it uses all the HTTP verbs. However, XMLHTTPRequest, the entire foundation of AJAX, can’t do anything other than GET and POST. So whatever we do is going to have to involve some kind of servlet bridge to the Blogger API.
(Possible workarounds for this: 1) get the Blogger and GData API teams to make GET/POST-only variants of their PUT/DELETE API methods; 2) get the browser vendors to implement PUT/DELETE support in XMLHTTPRequest. Clearly #1 is a lot more doable than #2 given the dreaded words, “legacy support”. You listening, GData team???)
Once we’ve accepted the need for some kind of bridge servlet, we’d better make sure that bridge servlet is fairly scalable and generic. Whoever is hosting this bridge servlet is going to have potentially a lot of traffic. So the bridge servlet needs to be stateless, re-entrant, and as close to a simple pass-through as possible. It shouldn’t have per-session state; it should be just a message relay.
We’ll also need some GWT modules for communicating with the bridge servlet, including beans that map to the data objects defined in the Blogger API, and service interfaces that map to the Blogger API’s methods. And in fact, this suggests that the servlet itself should simply use the Java implementation of the Blogger client API, exporting a GWT-friendly version of it (via GWT RPC) to the GWT client application.
The persistence implementation
Gears has this lovely local SQL database. But how do we get things in and out of it? We could write to the JDBC-like Gears SQL API. But I have tasted Hibernate. And if I’m programming in GWT, then writing JDBC-like code by hand would be like going back to the pre-Hibernate days. And I can’t do it. I CAN’T DO IT, I TELL YOU! I can’t go back. I WON’T go back!
Now when I first started brainstorming this with Ray from timepedia.org at GDD07, we got wild-eyed and started contemplating porting Hibernate to GWT. Saner heads rapidly prevailed. It turns out that Bob Vawter of the GWT team is doing work on a GWT-generator framework for generating a variety of useful artifacts (starting with Javascript-library method exports) from GWT beans.
So let’s use his framework, only instead of exporting to Javascript libs, we’ll make it generate dead simple CRUD operations for our Blogger beans to the Gears data store.
It looks like some other folks on the Gears list have had similar thoughts. Check out this Gears ORM implementation. But since that’s not based on GWT, it’s not directly applicable. Still cool though! But let’s assume we’ll proceed with Bob’s stuff, just for fun. This is all still early days and all experiments still deserve love.
The todo list
So, what do we have?
- GWT beans mapping to Blogger API data objects.
- GWT service interface mapping to Blogger API methods.
- Bridge servlet implementing GWT service interface and using Blogger Java client API implementation to relay messages to Blogger.
- Simple persistence code generator (using a GWT compile-time generator implementation) to take the GWT beans and store them in the Gears local database.
- Business logic to implement the client-side synchronization to the Blogger server. (That’ll be another post, or maybe lots of them!)
- GWT UI code to let the user use all of this infrastructural goodness to meet the must-have requirements!
If we get it right, it hopefully lands in the Google GWT API project. And once Blogger does this, Calendar is next, and then some.
Sounds like a fun project, huh? Interested? Chime in in the comments. Or join this GWT-Contributors thread on the topic.
Onwards!