WordPress mobile
While blogs and some simple social networking-type sites have become commodity software, far too much of the web still faces low-level development challenges that lead to lots of frustration for both the owners of those web sites and for their users.
About six months ago I did a cursory check of a bunch of blogs thought to be SAS — such as WordPress and Blogger — to see if they were iPhone friendly. They were not. Then, yesterday, I found by chance that my WordPress-powered blog is iPhone friendly. My blog being iPhone-friendly is quite a nice surprise, because I’ve been thinking a lot lately about how web site creation is still far too low-level. Years ago I had a MovableType blog that I administered on my own, on a physical server that I owned. While I wanted to be blogging, sometimes I felt like what I was really doing was administering and customizing the blogging software, and not doing enough actual blogging. For non-technies, administration and customization tasks would have been insurmountable barriers to actually having a blog. And even as a techie, when I powered down the server, the blog disappeared forever.
This blog is different. I don’t do anything, and over time, its interface evolves with the changing web. In addition to being iPhone-friendly, WordPress also supports Google gears. The site I started for the Enterprise Rails online community is also SAS, and is powered by Ning. I don’t have to worry about either site, and they just run, letting me concentrate on the content in the sites and not their low-level implementation.
Expect to hear more from me on this topic soon.
blog.chak.org is iPhone friendly
ScoreCard
Pivotal Labs is the creator of Pivotal Tracker, a fantastic task management tool that I use every day. I visited their office in NYC on Thursday to share a project idea with them, which hopefully they’ll build into their tracker software. The idea is called ScoreCard. It takes some ideas from Pivotal’s agile/scrum focus, and some from GTD (Getting Things Done). ScoreCard provides high-level view of all your tasks, organized by project.
These days, people work on so many projects at once — both at work and in their personal lives — that managing everything can become daunting. I counted the tasks in my personal “ToDo” list in Pivotal and found that I had over 150 tasks ahead of me on about a dozen small projects. I don’t need to see all of these tasks at once, because there’s no way I can work on everything at once. What I do want to know is “What are all the projects I’m working on” and “What can I work on now?” I’d also like to know, at a glance, how my projects are doing. Are they getting the attention they need or am I falling behind? Scorecard shows you this information across all your projects in one screen, and hides everything else from view to let you concentrate on what’s most important.
The image below shows the overview screen of all the projects.
ScoreCard project list
Here’s a zoom in on a single project, with an explanation of each part of the interface:
One ScoreCard Project
Like Tracker, ScoreCard gives you info on project velocity via the color of each project summary. It also adds trending (the flag) and a measure of project staleness (the time since last action). For the GTD’er in you, ScoreCard shows you two items from the project’s task list. It shows you the next action you need to focus on (with Tracker-style workflow steps: start, finish). It also shows you the last action you just completed. The tracker notion of “Accept” is assumed (this item will disappear when you complete the next action), but there’s a button to reject the action if you need to for some reason.
So yes, keeping my fingers crossed that the great folks at Pivotal will grant me this wish. If not, maybe someone else will build it for me — any takers? This tool can certainly be built on top of tracker’s web-service API.
xml or plist?
My new company is building an product that is both a web site and an iPhone app. Both are backed by the same web-service, which returns either xml or plists based on who’s asking.
For the web site, we return xml created using ROXML. The iPhone app does best when we send back plists, because they can be read easily with Objective C 2.0’s built-in libraries.
The following bit of code, injected into the base class of our “Service Objects” (as per Enterprise Rails), allows classes marked as with ROXML attributes to be serialized either as xml or as plists. to_xml returns the ROXML version as usual, but now xml_attributes_as_hash.to_plist returns a plist. xml_attributes_to_hash recursively turns all XML attributes into hashes (whether the attribute is another ServiceObject, an array, a hash, or a discrete value).
Of course, you need to have installed the ruby plist gem in order for “to_plist” to have any meaning.
module NewsService
class ServiceObject
include ROXML
def as_hash(val)
case val.class.to_s
when "Array"
return val.collect{|e| as_hash(e)}
when "Hash"
h = Hash.new
val.each{|k,v| h[k] = as_hash(v)}
return h
else
val.kind_of?(ServiceObject) ? as_hash(val.xml_attributes_as_hash) : val
end
end
def xml_attributes_as_hash
h = Hash.new
attrs = self.class.roxml_attrs.collect{|a| a.accessor}
for tag in attrs do
val = self.send(tag)
h[tag] = as_hash(val) if val
end
return h
end
end
end
More on logical models differing from physical ones
On the topic of logical models and physical models different, I found the following short anecdote in Paul Oldfield’s Domain Modeling whitepaper:
Anecdote: One project for which I worked, and against my advice, chose to design an OO system based on a data model. They made no attempt to get the responsibilities in the right place, despite an explicit requirement from the customer that the system be flexible in response to changing requirements. After major redesigns in response to changing requirements, the plug was pulled on the project before it delivered any code at all to the customer. It had become clear that the design process being employed could not keep up with the rate of change of requirements, and never would.
I’m in the process of designing a new application. I can’t say what it is yet, but I can say that there is a difference between the physical and logical models. Roughly, the problem corresponds to the image below.
First, lots of external data is collected from some source. The data goes into the unshaded white tables.
Then, through some process, we translate data from those tables into another set of tables. We do this in the database both so that we can have before and after copies for sanity checking purposes, but also so that the rules and constraints in the database can act as checks on the transformation itself.
Only the shaded tables in the physical model end up being relevant for display to users on the front-end. However, those tables are highly normalized and may have a variety of peculiarities about them (from a domain modeler’s perspective); those peculiarities come from the necessary imposition of the the database constraints and heavy normalization we needed to guarantee the data’s integrity.
So the third step is to translate these physical tables into classes that more logically represent our problem. The logical model hides all of decisions of the data layer for the programmer who is creating the web front-end. The input tables disappear, and the other tables are recombined in ways that make sense for the application. Some normalization can be lost because it’s not meaningful here.
Certainly, I could create a front-end that functions perfectly well without this layer. But it will be much easier to create and modify the front-end in the future with this layer in place. Although it seems like “work” to create the new abstraction layer, it vastly simplifies the problem of creating the front-end once the translation layer exists. The act of “translation” happens in one place, not in every controller or view that needs to work directly with data from the database.
In fact, as I’ve been arguing already (though not on this blog), you are doing this step all the time already, because no matter how you think of it, you do have to somehow translate data from the data layer into the format it ultimately gets displayed as on the front-end. The difference is that this model recognizes this process and brings all of the code that accomplishes it together in one place. That makes adjusting to changing requirements, or keeping database changes hidden from consumers a much simpler task.
The rub is that one needs to learn how to design the “domain inspired logical model.” Right now that seems to be the biggest gap. ORMs like ActiveRecord trick you into thinking that the data model and the object-oriented logical model are the same, and that’s something we need to overcome.
Physical vs Logical Modeling in Rails
I gave a talk on Tuesday at the Boston Ruby User’s Group meeting. The talk was quite exciting, with about 60 people split rather evenly between skeptics and converts to my message. Although they are fairly sparse for consumption without having first heard the talk, the slides are attached. As I understand more and more of the initial objections folks have to splitting up domain and data modeling this way, I’ll be working toward a more comprehensive argument and set of examples. Yes, ideally for the next edition of my book. Here’s the
PDF.
Enterprise Rails available for Pre-order on Amazon
As the title suggests, you can now pre-order my book on Amazon.
Materialized Views in Postgres
I got a lot of great feedback on my tutorial at PGCon. The slides, as well as a sample chapter from my upcoming O’Reilly Book are posted on the PGCon web site. You can also grab them here:
- Slides from PGCon 2008: Materialized Views That Work.
- Sample Chapter: Materialized Views from Enterprise Rails (O’Reilly Media).
I highly recommend the sample chapter, as it takes you through an example in prose form. The slides from the talk are pretty content-heavy but some code slides may be difficult to grasp without commentary.
hash_extension updated for Rails 2.0.x
Thanks to Wayne E. Seguin for pointing out that extract_options_from_args is gone in Rails 2.0.x. hash_extension 0.0.3 now works in 1.x and 2.0.x. To upgrade:
sudo gem update hash_extension
To install for the first time:
sudo gem install hash_extension
For more info, check out the docs.
PGCon 2008
My presentation on materialized views in Postgres, and especially materialized views with time dependencies, has been accepted to PGCon 2008.
Abstract: Complex queries repeated in application code often are recast as views. This makes programming easier, but it does nothing to improve the performance of the underlying query. Materializing the view is the next logical step. Materialized views are stored in standard tables, so joins, procedure evaluation, and conditions from the original query are pre-computed before queries are run against the materialized view. Because the data is in a table, performance can be further improved by adding indexes.
Many developers shy away from materializing views in Postgres because the functionality is not built in, as it is in Oracle. In this talk, I will present a straightforward approach that can be applied to materialize any view, even those that Oracle cannot handle. Case in point: views that have a time-dependency (such as those based on the current time, now()) don’t have convenient trigger points (such as commits) to signal that the view should be refreshed, and are a major stumbling block for view materialization. This talk presents a technique to handles those cases as well, bringing materialized views even more powerful than those available in commercial products to Postgres.
Hope to see you in Ottawa!
Speeding up ActiveRecord with Hashes, Take 2
A few weeks ago, I posted about the release of my gem, hash_extension, which makes Ruby hashes act a little more like plain old objects. That’s a good thing, because ActiveRecord requests that return hashes instead of full-blown ActiveRecord objects are about 50% faster. 50% is not a performance tweak — it’s basically the best thing that’s ever happened to ActiveRecord.
In version 0.0.1, the only way to get back hashes from ActiveRecord for use with hash_extension was to use select_all:
Foo.connection.select_all("select * from foo")
In the docs for hash_extension I put out a call for someone to extend ActiveRecord itself to return hashes from more natural, ActiveRecord-esque methods. Elliot Laster answered that call, and now, in version 0.0.2, find_as_hashes and find_by_sql_as_hashes are now available:
Foo.find_as_hashes(:all)
Foo.find_as_hashes(:first)
Foo.find_as_hashes(:all, :conditions => "bar = 'baz'")
Foo.find_by_sql_as_hashes("complex sql goes here")
To learn more about the gem and to download, go here.
