- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Agile Business, Microsoft and the Threat of Cloud Computing
Competition is the keen cutting edge of business, always shaving away at costs.
-- Henry Ford
I've been working with Java and Microsoft technologies -- .NET most recently -- in one form or another for quite some time. My company, now headquartered in Chicago with an office in NYC, was actually founded in Seattle by a group of four developers that had met around developing an Exchange-based bulk email system to replace the sendmail-based ones that Microsoft was using at the time. In that span, despite all of the food fights about total cost of ownership (TCO), etc., I haven't seen any evidence that Linux, Windows, Mac, Java, .NET, etc., puts you at a significant business advantage one way or the other. Until now.
Topics: Agile Development, Analysis, Editorial, Open Source
Save That Duck!
So, while most of you were off celebrating the holidays, Dietrich was off killing a duck, or at least Duck Typing. Personally, I always thought that the goose was the traditional holiday bird.. shows what I know.
Deitrich's argument is that Duck Typing does not allow "Dead Duck Typing", being able to restrict access to part of an object's state or functionality. The classic case here is keeping a display layer from getting at the persistence layer. (Maybe we can call this Stephen Colbert Typing, since you're declaring part of the object as "dead to me"...)
Dietrich closed his post with:
Some will argue this is a Java-ism creeping into Ruby. I say this is just plain old-fashioned good OO design.
Which I think is my cue.
I understand the theoretical argument for having strict (or stricter) access control in a system, and I certainly understand why having small, high cohesion classes is a good thing. My problem is that it's very rare for me to have a practical issue in a system because of loose access control or overly generous interfaces (granted, I've had a good run of working with smart people). On the other side, I commonly find that when I'm writing a program with access control I'd like to do something more flexible with an object, but I can't, because the original writer of the class did not anticipate the usage.
Specifically on the Ruby side, it's actually not hard at all to restrict access to an object. ActiveRecord objects can easily be made read only called before being passed to a view to protect from inadvertent changes.
In the more general case, it's not hard to do something like this, which only allows certain methods of an object to be called:
class ArbitraryProxy
def initialize(object, *methods)
@object = object
@methods = methods
end
def method_missing(method, *args)
if @methods.include? method
return @object.send(method, *args)
end
super
end
end
x = ArbitraryProxy.new("abcd", :size, :gsub)
p x.size
p x.gsub("b", "---")
p x.upcase
This returns:
4 "a---cd" NoMethodError: undefined method ‘upcase’
The interesting thing is that, by and large, Rails developers don't feel the need to do this. I don't think I've ever seen an authoritative source suggest that it's best practice to make ActiveRecord objects read only before passing them to the view.
There is a Rails plugin called Liquid that enforces the use of proxy objects before being passed to the view. It's not very widely used (in part because creating the proxies is kind of a pain).
I don't see that Ruby and Rails programmers see this issue as a practical problem facing them (it helps that Ruby tends to encourage small classes in other ways). That said, there are clearly cases where you need to be extra careful. Liquid is used as user-facing templating engine for a blog tool, which is clearly a case where you'd want to limit the damage that your template writers can do.
But I see that as the exception, not the rule. Long live the Duck!
Coming Soon: Professional Ruby on Rails -- available in bookstores Mid-Februrary.
Technorati Tags:
ruby, OOAD, Duck Typing
Topics: Analysis, Best Practices, Design Patterns, Ruby on Rails
2008: The Year In Advance…
Oh, we're doing predictions. Sure:
-
The blurring between desktop and web applications will continue. Especially watch for desktop applications specifically designed to enhance one specific web site (like the Mac applications Twitterrific and Mailplane). There are at least two other efforts to allow you to easily bundle an arbitrary web site into something that acts like a desktop app. I agree that Google Gears-like functionality has a strong place here.
-
On a related note, I'm kind of taken with the new Remember the Milk Firefox plugin, which adds GMail integration. It's a plugin that assumes a specfic browser and ties together two web apps. Using the browser as the clearinghouse for tying together disparate web data feels like something I expect to see more of.
-
GWT will make some headway in porting existing Java apps to the web, but much of this will be on internal networks, so it will kind of slide under the radar. I don't see it picking up vast numbers of new developers who aren't already committed to a Java/Swing structure.
-
One of the zillion or two desktop app suites will go under, prompting some panic for people who have stored documents there.
-
For the Rails community, I expect the big issue for 2008 will be dealing with success and growth (RailsConf 2008 has more proposals for speakers than RailsConf 2006 had participants...). The tension is along the axis of developer efficiency vs. enterprise-y performance. Look for more attention to fall on smaller, more specialized Ruby frameworks like Merb.
-
On a more technical level, I expect (or maybe more accurately, hope) that there will be some attention paid to improving the Rails view layer. Possibly a consensus on some kind of Presenter or Decorator pattern.
-
My book, Professional Ruby on Rails, will be released. You will buy a copy. (Hey, I can hope...)
Topics: Analysis, Ruby on Rails
Ajax Predictions for 2008
I'm a little early this year for my 2008 predictions. No matter. I seem to have been a bit early with my 2007 predictions as well, and as they say in the venture capital biz, "too early is the same thing as wrong." Some of my predictions did come true -- Ajax is no longer such a big buzzword; a number of framework specific books (GWT, jQuery) have been published at the end of 2007; Microsoft's Ajax stack continues to limp behind the rest. A few others did not, notably the ho-hum release of IE7 and the delay in FF3. So, let me try my hand at some more prognostication:
- Elegant, good looking frameworks like Ext and myGWT will gain traction. The more out-of-the-box good looks you can give them with CSS and bundle images and icons, the more acceptance they will gain.
- The JavaScript framework chaos will continue. The OpenAjax alliance will continue to be ineffectual in promoting things like widget interchangeability.
- Security will become a big headache, as less sophisticated developers start to venture into the wonderful world of Ajax, littering the web with state and control logic on the client side.
- Towards the end of 2008, FF4 and IE8 will start to change the landscape of Ajax and Web 2.0 with an update of JavaScript and new browser features.
- MS Volta will do nothing. It is just a FUD shot across the bow of GWT.
- Everyone except Craig's List will have some form of Ajax on their site.
- Desktop RIA's through Google Gears, Adobe AIR, etc., will start to make an impact in the second half of 2008. Look for desktop/web hybrids of the office productivity tools, such as word processors and Powerpoint clones, to see greater use in the corporate IT space.
- GWT's compiler will produce more efficient code than 98% of JavaScript developers can do by hand.
- With the new browsers, a cross platform Canvas/SVG will be a reality by the end of the year.
- IE8 will still leak memory like a sieve.
Have any of your own predictions? Feel free to add them in the comments.
Technorati Tags: ajax, 2008 predictions
Topics: Ajax Applications, Ajax Development, Ajax Frameworks, Analysis
The Desktop Application is Dead…Almost
The report of my death was an exaggeration.
-- Mark Twain
Why is the desktop GUI dead? Is it dead? Tell it to Microsoft, which still ships enough copies of Office each year to exhaust the capacity of all of the world's toxic waste dumps. So maybe its not totally dead. But in one important respect the desktop GUI is disappearing: the custom app developed for and by small to midsize businesses (SMB's).
Now I have worked in the IT industry as an employee, a contractor, a freelance consultant, and, for last decade, as a partner in a outsourced software product development firm. In that last role, I've had to turn down an unusually large number of projects recently. Why is that?
In a phrase, opportunity cost. Clients come to us with products, existing or new, and we usually agree to work on them for a fee. Sometimes you have to turn down project A because project B is much sexier and you can't do both projects. That has happened a lot of late and mostly with prospective clients looking to develop purely desktop applications. Unless there is a compelling reason, we just can't get excited about a desktop GUI project.
So, by way of eulogy, let me present a numbered list of compelling reasons for developing desktop GUI's instead of Desktop RIA's.
- It is unwise to expose the application to the outside world. Example: power plant management software.
- The application calls for integration with custom hardware or mobile devices. Example: scientific software that integrates with custom measurement devices.
- The application requires fine control of the underlying video/audio hardware. Example: first-person shooters.
That's a pretty short list. Note that there are a number of other applications you wouldn't do as a Desktop RIA, such as grep, but then you wouldn't do that as a Desktop GUI either (yes, yes, there are visual grep tools, but they don't function in quite the way that the easily piped command line grep does). Also, some of the examples above may have Internet integration (think XBox, etc.), but their architecture, runtime and user interface are pretty different from that of your typical Desktop GUI.
Note what isn't on that list: presentation software. I've argued in the past that Powerpoint was the one place in the office productivity universe where the Web 2.0 clones would fail. How many times have you been in a conference room without connectivity? No net? No presentation. But with the Desktop RIA runtimes, browser support and framework support coming out, online/off-line hybrids are becoming possible.
If you can add to the above list, great, but for the most part, I think the Desktop GUI is a vanishing breed.
Technorati Tags: ajax, desktop GUI, desktop RIA
Topics: Adobe AIR, Ajax Development, Analysis, Trends
The painful art of prognostication
They say science fiction is rarely actually about the future; it's really an exploration of present-day fears and anxieties, interrogated through a metaphor of the future. William Gibson himself - the father of cyberpunk - has given up the future in favor of exploring our technological present in compelling novels such as Pattern Recognition and the brand-new Spook Country.
I couldn't help but think about science fiction when I read this "strategy letter" by Joel Spolsky of "Joel on Software" fame. Spolsky looks at a number of current trends in the Ajax world, draws parallels between them and the original emergence of desktop computing, and concludes that the future looks a lot like Windows. In Spolsky's vision, one or two powerful Ajax toolkits will become the de facto new platform/operating system for the next era of application development.
I cry bullshit not because Spolsky's discussion is illogical or ill-informed, but because it's presented with such certitude. If my time in the blog echo chamber has taught me anything, it's that the guy who seems most sure of himself is probably the one blowing the most hot air. Folks have an insatiable appetite for strong opinions, repeated loudly. Everybody wants to know what the future will bring. But the best most commentators can hope for is to surf the currents of the present and catch of peek at what's beyond the next wave. Extrapolating a bunch of disparate trends 5 or 10 years into the future is just an exercise in rhetorical prowess. Joel's a great storyteller, but like most storytellers he's primarily interested in spinning a great yarn. By all means give his theories a whirl, but don't expect capital-T Truth. Nobody can tell the future. To believe otherwise is science fiction.
1984 is a powerful book precisely because Orwell didn't have to make a lot of shit up. He had Nazi Germany and the Soviet Union under Stalin as models for what he was doing. He only had to dress it up a little bit, sort of pile it up in a certain way to say, "this is the future." But the reason it's powerful is that it resonates of history. It doesn't resonate back from the future, it resonates out of modern history. And the power with which it resonates is directly contingent on the sort of point-for-point mimesis, like sort of point-for-point realism, in terms of what we know happened.
--William Gibson, via Boing Boing
Topics: Ajax Frameworks, Ajax Performance, Analysis
Ajax and Agile Trends for Q3 and Q4 of 2007
Over the last month or two I've noticed some definite trends in the sorts of questions that clients and prospective clients are asking my company (Pathfinder). Comparing notes with friends and competitors, it seems that the following technologies are really picking up steam towards the second half of 2007:
- Ruby on Rails as a replacement for PHP. Big, complicated applications are still being written using Java and C# and their related frameworks. For those apps where speed to market is key, however, Ruby is starting to supplant PHP.
- GWT for client-side Ajax apps. After an initial bit of nervousness ("Compiling to Javascript? Whah?"), the debugging capabilities and single language attraction of GWT seems to be winning out. People are still writing plenty of traditional web stack apps, with Prototype and its descendants leading the way, but look for more companies to make the jump to GWT.
- Agile development. While not technically a technology, this trend has some real consequences for web and RIA development. The tools and frameworks that are agile influenced will give the teams and companies that adopt them a competitive advantage. Mind you, I've see "agile" and "iterative" thrown around in corporate circles as far back as 1999, with little positive impact. Now, I think, we have a new generation of managers who have some sense of what an agile development process can yield; they aren't adopting it to be buzz-word compliant -- they actually want the benefits that come from an agile approach.
The one trend that really seems to be accelerating is the PHP->Ruby migration. There has been hand wringing about this threat in the Drupal community since 2005. Time to saddle up, fellas. This time it's really coming.
Topics: Analysis
Most Popular Ajax/Web 2.0 App?
I conducted an informal survey a while back on which Ajax-based apps people actually used. I got back a good number of responses and the results are in. With the exception of a smattering of applications such as GMail and Yahoo! Mail, far and away the most popular type of Ajax-based app was the RSS Reader. When you think about it, it is an online application designed to perform what is essentially an online activity: reading blogs. Mail, on the other hand, has lots of offline aspects to it (attachments, a history of offline reading, etc.).
I guess this result isn't too surprising, but I'm not sure what it says about the future of Web 2.0, all online apps. Do we all have to be weaned from our dependence on offline apps? Is this a thing "the kids" will be embracing, and not us elders? Or will we have to wait until there is truly robust online/offline functionality in Ajax/Web 2.0 apps, through platforms like Adobe's Apollo and the mysterious (does it even exist as more than an announcement and a slide show) Project Flair from Sun?
Topics: Ajax Applications, Analysis, Web 2.0
Ajax Among the Top 100 US Sites
With the announcement that Sourceforge had settled on JQuery as its framework of choice, I thought it would be useful to see what all of the big US sites (as defined by Alexa) were doing with regard to Ajax. I'm not sure whether the results should surprise me, but it turns out most of these sites weren't doing Ajax, and even fewer were making use of frameworks. Here is the tally:
- Use of Ajax: 15%
- Prototype: 7%
- Scriptaculous: 3%
- JQuery: 2%
- moo.fx: 1%
- YUI: 1%
- GWT: 1%
With the exception of Google and Yahoo, there's not that much heavy Ajax going on. I'll have some more results later in the week as I dig further into the data, but I think some basic patterns are emerging:
- The big sites are very conservative. With the exception of folks like Google, Yahoo, and Digg, most of the top 100 US sites are not originally startups that burst onto the scene through innovation. Most of them are the online extensions of offline companies. As such they are not technology companies and are followers when it comes to new technology.
- The photo sites are really ASP's (or SaaS, depending on what acronym you prefer), and are competing on usability, thus, as predicted in 10 Business Reasons to Use AJAX, are among the early adopters of Ajax.
Don't hold your breath for many of these "common carriers" to make widespread use of Ajax any time soon. When you're CNN and a large part of your audience stull uses IE5, you have to move slowly.
Disclaimer: many of these top sites are big and/or have many subsidiary properties. It is entirely possible that I have missed the use of Ajax or an Ajax framework among the broad reach of microsoft.com or msn.com.
Topics: Ajax Frameworks, Analysis
Application Development with Echo2 plus SOA
Mathew Brooks of RDF Group has published a summary of his experiences in developing mform -- an Ajax-enabled mortgage application -- using the Echo2 platform. Although fairly high level, the post is thought provoking and doesn't just focus just on Ajax. With regard to best practices in using Echo2, he writes:
Whilst using echo 2 we discovered that whilst it was the most advanced tool for the job (at least when we started, which was before GWTcame out) we did find that we had to undertake the following:
- Adjust some of the java script in widget peers where it was not quite performing as we expected
- Subclass the echo 2 servlet to ensure that:
- We can trap non java script type clients and present a "non javascript" type version of the page
- We can present a more polished start up page rather than the ||| presented as default by echo 2
- Some post back functionality does not work well with IE either under load or restricted bandwidth. Due to the way that IE polls for the post back other events on the browser were being missed.
- Develop our own widgets where necessary if there was no suitable one available from echo or echopointNG
Beyond Echo2, the application makes use of ServiceMix (the Open Source ESB), Spring, Hibernate and EJB3. It also integrates with a CMS -- Hippo -- for conetent management. I haven't used ServiceMix myself, but I have used the Mule ESB myself (it has much better docs and tutorials, IMHO), and beyond the SOA help it provides, I've found it's support for FutureTask very helpful for some of the asynchronous processing you see more of in Ajax apps.
Mathew's analysis goes well beyond just Ajax, of course, with some thoughts on how to avoid the Anaemic Data Model antipattern, among other things.
Excellent Overview of Ajax Competitors
Dion Hinchcliffe has published another trenchant article on Ajax's competitors in the world of Rich Internet Applications (RIA's).
But a host of companies and open source efforts are in the process of delivering
— in a seemingly endless series that began earlier this year — one RIA
solution after another. The majority of these succeed in making the
creation, management, and maintenance of Rich Internet Applications
(RIAs) not only easy, but far more cost-effective and with features
that Ajax might never be able to match.
There's Flash and OpenLaszlo and a few you might be less familiar with. Go and check it out.
Topics: Analysis
About Pathfinder
Recent
- Bandwidth profiling Flex projects and more with Charles
- iPhone SDK: UIViewController Testing & TDD
- Icons are evil; so are menus - unless you do them right
- The Truth About Designing For Security
- GWT, Gadgets and OpenSocial, Part 2
- Has Many has_many: A Refactoring Story
- The Hidden Power of Canvas
- Review of fixture_replacement2 plugin
- Chess Game Viewer in GWT
- From JSP to Ruby on Rails: First thoughts on front-end coding conventions
Archives
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006


