- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Going to the GWT “Voices that Matter” Conference, Dec 4-6
I'll be attending the GWT Conference in San Francisco from December 4-6. We've been pretty much alone in developing GWT-based applications here in Chicago, so it will be nice to rub elbows with some other practitioners.
Drop me a line if you'll be attending as well.
Technorati Tags: gwt, conference
Topics: GWT
Writemaps: A web based site map generating tool
Came across an interesting web tool today...Writemaps: A site map generating tool that allows you to build, edit and share site maps.
It's got limited features, but it has two big things going for it:
1 - It's web based, and you can share your files via url. So anyone with a web connection can view and edit what you've created.
2 - It creates presentable sitemaps. The page representations (nodes in the site map tree) have subtle gradients and drop shadows, and the tree diagram contains only right angles, giving your sitemap a polished professional touch.
A few other notes about this tool:
Can't print or save as image, but you can save as XML.
It's got an undo button! (how many web apps do that?)
You can zoom in/out on your map views.
It's dead easy to get started.
In summary, there's a lot of potential here, and I think I might give it a try on my next project.
Powered by ScribeFire.
Topics: Information Architecture, Task Flows, Web 2.0
JRails: Scriptaculous on top of JQuery
Prototype and Scriptaculous had their origins in Ruby on Rails before spinning off. There they went head to head with the lighter, leaner JQuery. Now the circle is complete, with Scriptaculous functionality on top of JQuery making its way back into RoR in the form of JRails.
jRails is a drop-in jQuery replacement for Prototype/script.aculo.us on Rails. Using jRails, you can get all of the same default Rails helpers for javascript functionality using the lighter jQuery library.
This is certainly good news for folks who do a fair bit of mashing up. Combining two sites or services, one of which uses Prototype and the other JQuery, can be a bit painful.
Technorati Tags: ajax, prototype, scriptaculous, jquery, ruby on rails
Topics: Ajax Frameworks, jQuery, Ruby on Rails, Scriptaculous
Echo Chamber Report: Web 2.0 is Done, Son
When the marketing folks say a trend or bubble has lost its bloom, it must be true. But the examples they give are telling:
Talk of a second dotcom bubble has been fuelled by a flurry of web 2.0 acquisitions in the past two years, with media owners jostling for supremacy in the digital space. Most recently, Microsoft announced its $240m (£117m) acquisition of a 1.6% stake in Facebook in a deal that values the social networking site at $15bn (£7.3bn).
In October last year, Google snapped up YouTube for $1.65bn, while Rupert Murdoch’s News Corp splashed out $580m on MySpace in July 2005. “Some of these valuations bear little or no resemblance to reality,” says Andy Hobsbawm, European chairman of Agency.com.
Hmmm, Facebook, MySpace (in 2005! Feel the churn!), YouTube? With the exception of YouTube, these are all Social Networking sites. Web 2.0 is more than social networking, and a bubble is more than three corporate behemoths staking out territory at overblow valuations.
For those of you toiling in the fields of Web 2.0, RIA applications, don't even break stride. This is nonsense.
Topics: Web 2.0
From the Grassy Knoll: Google Android Undermining Java ME
The dudes at Java Developers Journal (JDJ, for you acronym hipsters) has always had a hard-on for conspiracies involving Microsoft and Java. "Embrace and extend" is a mantra akin to the Dalek's "Exterminate!" in their editorial corridors. Now they see a conspiracy in Google Android.
To put it bluntly, Android as it is currently defined is a fork of the Java ME platform. Android is similar to the Java ME, but it's a non-conformant implementation. Android is not compliant with Java ME nor is it compliant with Java SE. In fact, it’s not really Java. Although it uses the Java programming language, the core APIs and the virtual machine are not consistent with the Java ME or SE platform - its a fork. This was first pointed out by Stefano Mazzocchi in his November 12th Blog entry entitled "Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME". Stefano missed the fact that Android does not properly implement the CDC or CLDC Java ME APIs ( a minimum requirement for Java ME conformance) - but kudos to him for being the first to report on the fork. The fork has since been picked up in the blogsphere by others here, here and elsewhere.
And this is a huge threat to Java ME, according to JDJ. I think the main takeaway from the article is "it's not really Java." The reasons why folks use J2EE, J2SE and J2ME are varied and don't necessarily overlap. If J2ME goes away, that won't really affect my decisions on whether to use J2EE.
Technorati Tags: ajax, android, j2me, google, microsoft, jdj
Plug: Designing Invisible Interfaces Webinar
My colleagues Matt Nolker and Shalom Sandalow have put together a nice little webinar entitled "This Won’t Hurt a Bit": Designing the Invisible Interface.. For those of us writing Web 2.0 applications, there are some key insights here, such as: "interacting with the software is not the primary goal or responsibility of the user." So when you use those nifty Ajax widgets, think about whether you are placing a usability burden on the user or are using the power of Ajax to make the interface disappear.
Technorati Tags: uxd, webinar, invisible interfaces, usability
Eating Some Crow on ThinWire
OK, so I was wrong in ThinWire. The issues around having to position and size components is obviated through the existence of two layout managers -- SplitLayout and TableLayout. These layout managers calculate size and positioning for you (and override any values you may have explicitly set). They certainly make developing in ThinWire much less tedious than I previously thought. For an excerpt of the ThinWire handbook that discusses the two layout managers, see here.
For more sophisticated or fine grained layouts, you'll likely want to develop your own layout managers. I'll officially remove ThinWire from my list of 2007 Ajax Turkeys.
Technorati Tags: ajax, thinwire
Topics: Ajax Frameworks, Editorial
Live Ruby: Testbed, part 1
In this series of posts, I’m going to walk through the implementation of an interesting Ruby problem, namely, using metaprogramming to create a small DSL-like syntax for specifying tests.
Here’s the problem as I notice it in my own unit testing: I tend not to go back and ensure that multiple input values for a method work — worse, I don’t often check for error conditions or possible corner cases.
The main reason for this, I think, is a) wanting to move on to the next thing, and b) not wanting to take the time to refactor the test to make adding another test call simple. What I really want is something where the test is essentially pre-factored, so that adding a new call is easy. The newest test frameworks on Java use function decorators to specify multiple sets of data over the same test.
In Ruby, we can achieve the same effect via metaprogramming, which allows a clean enough API to make specifying new tests easy.
I think I want the syntax to look like this:
testbed "call my test function" do |input|
subject = MyObject.new(input)
subject.method_to_test
end
verify_that(1).returns("fred")
verify_that(2).returns(3)
verify_that(0).raises(Exception)
In other words, using something similar to the way Rake matches descriptions to tasks. Define a testbed to perform some assertions on a given set of data, then assert any number of different instances of the test using verify_that. Each verify_that is automatically associated with the most recent testbed, and gets converted to an actual test method called when the test class is run.
So, how do you implement this, and how do you test it? Here’s the first test I wrote:
require 'test/unit'
require '../lib/testbed'
class TestbedTest < Test::Unit::TestCase
class FakeTestA < Test::Unit::TestCase
def test_something; true end
end
class FakeTestB < Test::Unit::TestCase
def test_something; true end
end
def test_creating_a_testbed
FakeTestA.testbed("this is a fake testbed"){ |a| a * 2 }
assert_equal("this is a fake testbed", FakeTestA.current_testbed.name)
assert_equal(4, FakeTestA.current_testbed.block.call(2))
FakeTestB.testbed("a different fake testbed") { |a| a * 3 }
assert_equal("a different fake testbed", FakeTestB.current_testbed.name)
assert_equal(6, FakeTestB.current_testbed.block.call(2))
assert_equal("this is a fake testbed", FakeTestA.current_testbed.name)
assert_equal(4, FakeTestA.current_testbed.block.call(2))
end
end
First off, I created a pair of fake test classes to use later on (I gave them a single test to prevent Test::Unit from complaining when I run the tests). The actual test method explicitly calls the testbed method on the fake classes, mimicking the actual usage shown earlier. What I’m testing here is that the testbed call places an object in a current_testbed slot so that it can be referenced by later calls to verify_that.
(I test it on both fake classes to verify that multiple classes can hold separate values in the class variable at the same time).
The first round of implementation looks like this:
module Test module Unit class TestCase class << self attr_accessor :current_testbed def testbed(string, &block) self.current_testbed = Testbed.new(string, block) end end end class Testbed attr_accessor :name, :block def initialize(name, block) @name = name @block = block end end end end
So far, this is pretty simple. I’ve created a Testbed class to hold a name and a block. I’ve also opened up the TestCase class to add the class method testbed. Right now, that method does nothing more than store the string and the block in a Testbed instance, and stores that instance in a class-level attribute called current_testbed.
The way in which the class method and class attribute are set up is very Ruby specific. Each object in Ruby has a special attribute called a singleton class. If filled, the singleton class can have it’s own methods and data, and that class is checked for method names before the object’s own class or any of it’s superclasses. This allows an individual Ruby instance have unique behavior — different from other instances of the same class — just by placing different methods in it’s singleton class.
To define a singleton class, you use the form:
class << obj end
Where obj is the instance whose singleton class you are defining. (An instance only has one singleton class. If you define multiple blocks for the same object, they are all added to the same singleton class.)
In this case the object in question is self, which when referenced outside a method definition refers to the class being defined. In Ruby, classes are objects just like anything else, and they can have singleton classes. This gets a little strange when dealing with instances of the class Class, but the basic idea is that adding methods to the singleton class is equivalent to adding instance methods to the class itself.
The testbed method, which is defined in the singleton block, becomes an instance method of the class TestCase, which means it can be invoked as a Class method as in:
FakeTestA.testbed("this is a fake testbed"){ |a| a * 2 }
The nice thing about using the singleton format, rather than using regularly defined class methods and attributes, is that each subclass of TestCase will get it’s own singleton class, and therefore each can have its own current_testbed attribute, which is the functionality we want.
That’s going to be it for Part 1. Next time, I’ll implement the verify_that method chain.
Topics: Ruby on Rails, Test Driven Development, Unit Tests
GWT Hyperlink and the Mouse That Went Over
It's Wednesday, and you have had it up to here with the weather. There's nothing on TV and you've gone out for so many walks, you can't even get your dog to look you in the eye without him hiding under the kitchen table. You have time on your hand, so you decide you want to see how easy it is to set the status bar text when hovering over a link in GWT (why? don't ask why, let's just pretend for a second). You settle on three possible approaches
1) Extend GWT's 'HyperLink' class. This first approach requires registering the 'mouseover' event and writing a bit of Javascript to be invoked when the event fires:
class MyHyperlink extends Hyperlink { public MyHyperlink { super(); // Register my interest in 'mouseover' events sinkEvents(Event.ONMOUSEOVER);
addClickListener(new ClickListener() { public void onClick(Widget sender) { // Some action... foo.submitSomething(); } }); } // Overrides base class method public void onBrowserEvent(Event event) { if (DOM.eventGetType(event) == Event.ONMOUSEOVER) { setStatusText("my custom text"); } else { // Make sure you invoke 'super', as mouse down events travel through here as well. super.onBrowserEvent(event); } }
// JSNI call required to execute whatever we're interested in.. // In this case, setting status text, but it could be anything else private static native void setStatusText(String text) /*-{ $wnd.status=text; }-*/;}
The problem with this option is that it doesn't exactly work as intended. 'setStatusText()' gets invoked at the right time, but if you look at the status bar in Firefox, the status bar text doesn't update. I'm not sure why exactly- it might just be my quick & dirty JavaScript, but even if everything worked as intended I'm still not happy with this solution. I mean, look at the code-- I have to pull in many ingredients just to complete a simple task-- DOM.eventGetType()? Writing a JSNI method definition? Registering the right Event type, overriding default behavior, etc.? Not the most readable code and not the kind of code I would lightly hand off to someone just getting their feet wet with GWT.
2) Another approach. Let's try to wrap Hyperlink in a FocusPanel. You still need a JSNI method to trigger the JavaScript code (see above), but the Hyperlink stays the same while the dynamic behavior is contained entirely in the FocusPanel. Now one good thing about FocusPanel is that it allows one to easily add a MouseListener to define the behavior you're interested in (in this case, 'onMouseEnter()'). This means we don't need to explicitly register the Event type we're interested in.
The only problem with the FocusPanel approach is... that it doesn't really give us what we want. The FocusPanel instance has dimensions around the link, so the area of interest can actually be larger than the link itself. Firebug verifies this. You can set or tweak widths to get the FocusPanel's area to match the link area, but I won't bother to include a code sample because, well, if you haven't been able to tell already, it just isn't worth it. Time is money. Moving on...
3) Hey I got an idea! How about we ditch 'Hyperlink' completely & roll our own? The dog just got up to scratch the front door and you don't have much time. C'mon, it'll be fun! As it turns out, the direct approach turns out to be both the most expedient, as well as the shortest to implement in code:
class MyHyperlink extends HTML { public MyHyperlink(String name) { setHTML( "<a onmouseover=\"status='';return true;\" href=\"#x\">" + name + "</a>" ); addClickListener(new ClickListener() { public void onClick(Widget sender) { // Whatever you would have done in Hyperlink's clickListener... foo.submitSomething(); } }); }}
Done. Everything works.
Why did GWT's Hyperlink let us down in this case? This is where things start to break down in usefulness for me as far as GWT is concerned. It's nice and seamless until it stops being so-- and then it will remind us of just how painful it is to step behind the velvet curtain-- you get lost in the abstractions. Now granted, I'm not crazy about any of these approaches, and as someone will probably suggest, there's nothing stopping me from taking option (1) or (2) and creating an abstract class on top of what GWT provides and inheriting that base class in my own custom Hyperlink instances... but how annoying would that be to debug in the event that my custom JavaScript stops working? No thanks. Option (3) tells me everything I need to know without traversing up and down an additional class hierarchy. It's also easier to communicate to others, even if it is a bit counterintuitive to extend 'HTML' instead of 'Hyperlink' just to make this particular link.
UPDATE (11/29)
There turns out to be a better alternative to (2), using a 'Label' and styling it to look like a Hyperlink. The benefit here is that, unlike Hyperlink, 'Label' allows you to capture MouseListener events. Still not great, but at least it avoids the issues with FocusPanel. You're still left using JSNI to actually implement your JS however..
Topics: GWT
The merits of alpha-geekdom
Jeff Atwood of Coding Horror recently picked up a thread from Ben Collins-Sussman (of SVN fame) about the distinction between alpha geeks and the majority of vocational programmers. According to Collins-Sussman:
There are two "classes" of programmers in the world of software development: I'm going to call them the 20% and the 80%.
The 20% folks are what many would call "alpha" programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with
hiring. These folks were the first ones to install Linux at home in the 90's; the people who write lisp compilers and learn Haskell on weekends "just for fun"; they actively participate in
open source projects; they're always aware of the latest, coolest new trends in programming and tools.The 80% folks make up the bulk of the software development industry. They're not stupid; they're merely vocational. They went to school, learned just enough Java/C#/C++, then got a job
writing internal apps for banks, governments, travel firms, law firms, etc. The world usually never sees their software. They use whatever tools Microsoft hands down to them -- usually
VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java development. They've never used Linux, and aren't very interested in it anyway. ... They know exactly enough to get their job
done, then go home on the weekend and forget about computers.
Say what you will about Collins-Sussman's generalizations; his original post, Atwood's response and Collins-Sussman's follow-up have generated hundreds of comments, many of them wildly entertaining. I think most people would agree that the two extremes exist but that there's a broad range of in-betweeners. Ignore the hyperbole and it's an interesting theory.
It's also a theory that can be applied to many different disciplines. Information architects and visual designers have their own spectrum between the vocational majority and the obsessive minority. So do project managers. Even within the programming field, nobody can be an alpha geek about every aspect of software development. A lot of people who fall into the 20% camp when it comes to writing, say, Java code fall into the 80% when it comes to the user interface. As for me, I'm far more vocational about server-side technologies than I am about Ajax. I'm obsessive about the things I find interesting and merely competent at the rest.
Software engineering is by its very nature multi-disciplinary. Even self-professed "20%-ers" can only master so many discrete technical and design skills. They key to building great software is to recognize the specific sub-disciplines that inspire you to alpha-geekdom. Then, search out opportunities that will reward you for obsessing over them.
Topics: Ajax Development
Thinking of alternatives to GWT-RPC
What would alternatives to GWT-RPC look like?, it would be interesting to see these come about, and I think it would be worthwhile to do some experimentation in this area.
I believe rather than tweaking what's there, we can see radically different approaches go different directions, either by building on top of GWT-RPC, or providing a drop-in replacement.
A few issues to consider: while we are working in a richer client-side environment, we still define and build our server-side interfaces in the same fashion as before: Remote interface, implementation, and server-side configuration. GWT requires an additional client-side (i.e. 'Async') interface, target definition & invocation code (casting the GWT-generated proxy to the async type), editing the module file definition for the service, making sure any data objects implement GWT's 'isSerializable' interface, and the server-side component extending GWT's RemoteServiceServlet.
The client/server contracts are generally the same-- "save this", "retrieve this",
"search for this", etc. So a a little bit of convention might go a long way
between what the client is likely to send and what the server generally
provides. Might this reduce the list above? How about putting the async behavior where it belongs on the GWT components rather than using the 'onSuccess/onFailure' callback mechanism? It would make the code clearer, and would probably be much more testable.
And then there's testing-- conventional wisdom suggests having a separate, 'mock' version of the server-side component when running in hosted mode. GWT provide a way of detecting 'hosted' mode from 'non-hosted' mode, effectively allowing your code to switch between server-side implementations.
Frameworks such as the GWT Server Library aid in the server-side configuration pain, allowing you to write POJO services while using Spring configuration to wire into GWT-RPC. But the net effect hasn't changed-- there's still all that configuration and, I put forth, intrusive code required even to get us there.
As Java developers, our pain points are generally high when it comes to this sort of thing-- and the tired and true aphorism generally surfaces: "well, I've seen worse..." Let's not settle our technology choices just for that reason alone.
Now, I know there's nothing in GWT that requires you to use GWT-RPC. Because any solution would require JS bindings for any Java code, it is not a trivial problem to solve, but not out of the question either. Alternatives could happy live side by side with GWT-RPC. Will an alternative surface? Can this be made better by using another paradigm?
Topics: Ajax Development
Faking the art of interrogation
Companies often ask their technical employees to interview job candidates, but they frequently fail to train them how to do so properly. I've working as a software engineer for more than a decade, but every interview technique I've been taught has revolved around how not to get sued. At a certain point in your career, your company probably figures that a previous employer taught you the ropes. That's unfortunate for both you and any potential hires who have misfortune to get stuck in a room with you.
How often have I been told to "just focus on the technical nitty-gritty and maybe talk a little bit about the culture?" I break out into a cold sweat when I hear these words. It's not that I've never participated in a polished, professional sit-down. It's just that whenever I have, it's usually been as the interviewee, not the interviewer.
Slowly, though, I've started to get a handle on the soft skills that come with a more senior role. I think I've finally figured out how a software engineer with little managerial background can fake it convincingly in the role of technical interviewer.
Start with the quiz
Even if you've been saddled with an ungodly long interview slot, you can fill most of it up with written or oral test materials. Of course, designing your questions so that they tease out intelligence rather than mere knowledge is itself a skill. Still, the straight-up technical grilling at least helps weed out the fakers from the folks with real programming chops. A thorough knowledge of relevant languages, trends and best practices isn't the only measure of a candidate, but it should give you a good baseline.
Ask for a self-appraisal
"Rate yourself on a scale of 1 to 10 on [insert name of technology here]."
This may seem like the cheesiest tactic in the book, but it can be useful if you use it as the starting point for a discussion about the candidate's skill portfolio. A colleague and I recently commiserated about rampant grade inflation; front-end candidates, for example, all tend to rate themselves as a 8 or above on JavaScript, CSS and markup. Compared to back-end programmers, that's probably accurate. But with UI development now finally accepted as its own discipline, the best candidates - or at least the most honest - will assess themselves against their own peers rather than against some mythical, DOM-fearing Java developer. Because you'll have conducted some form of test, you'll be able to compare the self-image with the reality. And because front-end work comprises so many different technologies, you'll quickly learn whether your candidate is a JavaScript geek who knows enough CSS to get by or a semantic-markup stickler who avoids the behavior layer like the plague.
You should also ask candidates to rate themselves on skills and technologies that fall outside their current specialization. This can help tease out their passions, their blind spots and the overall breadth of their resume. You'll learn whether they're at least aware of technologies they don't actually use. A .Net developer with a solid grasp of what's going on outside the ASP world may be a better fit for your J2EE shop than a long-time JSP-er whose horizon stops at Struts. Likewise, if you're an Agile shop with competencies on a number of platforms, then you want to know if your candidate is only dimly aware of this new thing called Rails.
Shut up as often as possible
At my old company in San Francisco, I had a colleague so taciturn that we'd ask him after each interview whether he'd made the candidate cry. You don't want to come off like some remote, remorseless hardass. But talking less will instantly raise your credibility - and the quality of the interview. For years, I would cover up my own nervousness as an interviewer by blathering when I should have been listening. If there's dead airtime, let the candidate fill it. You'll learn lots.
When in doubt, chat about the company and the team
Figuring out the "cultural fit" may seem like some esoteric human-resources pursuit, but general discussion about work habits, team dynamics and release cycles can give you more of a read on somebody than mere code talk. As the technical screener, you're better positioned than a manager or an HR rep to share information about the day-to-day reality of your company. Be honest but professional in talking about both the challenges and the rewards. Finally, don't wait until the last 60 seconds before asking if the candidate has questions for you. If they're not chomping at the bit to interview you, then they might lack the maturity and self-direction your company expects.
Have I missed anything?
For somebody who was just professing his lack of interview skills, I managed to spit out a lot of advice. Reluctant technical screeners of the world, what have I missed or misstated? Let me know in the comments.
Bonus question
In a future post, I want to tackle the best way to assemble the actual written or oral technical quiz for Ajax developers. If anyone has what they consider to be a killer question on JavaScript, CSS, XML, HTML or other related technologies, drop me a line at bdillard(at)pathf(dot)com. I promise to give you credit when I publish my post.
Technorati Tags
Topics: Javascript
Really Simple History and the compulsion to tinker
I committed several weeks ago to roll Really Simple History 0.6 RC1 over into a final release on Dec. 1. That's still the plan, but I'm having trouble resisting the urge to tinker. I'm starting to see how a project like this could remain in indefinite limbo if I don't just draw a line in the sand and release a final "hard" version that people can rely on for production code. The current SVN trunk includes a number of backwards-compatible enhancements. I'm working hard to test them all as comprehensively as possible, but I'm going to avoid adding risk to 0.6. Instead, I'll save them for 0.7, which will come out in beta before Christmas.
The enhancements targeted for 0.7, some of them already complete, include the following:
- Configurable location for the blank.html file: You'll be able to override the name and directory location of blank.html in case your server architecture demands that it be served from a different location.
- Automatic handling of history points whose keys contain spaces or other special characters; encodeURIComponent is my friend.
- Automatic title changes: You'll be able to pass a third argument to dhtmlHistory.add and update the document title with its value. You'll also be able to pass in a base document title through the options bundle so that each call to add just swaps out the subtitle.
- One-line initialization: You'll be able to pass your listener into the dhtmlHistory.initialize without having to call addListener separately.
- Private methods that are actually private: Methods that are currently marked "private" but are accessible to anyone will become inner functions with no public access.
- Better global namespacing: I was hesitant to change the API for the 0.6 version, but I'd like to follow the YUI model and group all of RSH's objects into a single global variable. Instead of dhtmlHistory and historyStorage, we'll end up with RSH.history and RSH.storage.
The roadmap for 1.0 includes the following:
- JSUnit and Selenium test suites.
- Adapters for major frameworks using the MooTools model.
- Customizable downloads.
- Serious tutorials and documentation.
In the meantime, downloads for 0.6 RC1 have crept to just under 350 almost 700. Look for me to "flip the switch" on Saturday, promote 0.6 to the stable production version, and deprecate 0.4 once and for all.
Technorati Tags
Bjax: Make it Play MP3’s
It's nice to know you've inspired someone and it was very nice of Chris Anderson to drop us a note on his own Bookmarklet: Make it Play. Basically, this bookmarklet will scan a page for mp3 links and then insert a little semi-transparent media player interface at the bottom of the page.
It's not SongBird, but it's a good demonstration of the power of Bjax -- injecting user interface to improve an existing web interface. Based on JQuery.
Technorati Tags: ajax, jquery, bookmarklets, bjax, mp3
Topics: Ajax Examples, BJAX, jQuery, Music
Ajax Turkeys for 2007
Every American school child has heard vague rumors that Ben Franklin once suggested that the Turkey would make a better national symbol than the Bald Eagle. What they haven't heard, of course, is that the Turkey is "though a little vain and silly, a Bird of Courage," compared to the Bald Eagle which was "a Bird of bad moral Character." I wouldn't put too much stock in old Ben's suggestions, though. After all, he once proposed that the Rattlesnake was the most appropriate symbol of America's temper and conduct.
So in the end it is still appropriate to use the Turkey as a symbol of failure or incompetence. So, without further ado, my Ajax Turkeys for 2007:
- GMail 2.0 - this puppy should be put back in the shed. It fries browsers from coast to coast. If there was ever and argument against the bloated Ajax beast, this is it.
- ECMAScript 4 - the bastard child of JavaScript, Java and Ruby, this beast tries to please everyone and instead falls between the chairs. If you want the advantages of both dynamically and statically-typed programming languages, make sure the browser can run more than one language (VM and compilers, anyone?).
- Thinwire - any framework that makes you specify position and calculate height and width of every widget is a productivity killer. Update: I was wrong on ThinWire. The Layout Managers simplify this. Mea culpa, mea maxima culpa.
- The Book of JavaScript, Second Edition - I didn't have the heart to review this one when it came out. Thau was "the man" back in the 90's when it came to JavaScript. If you wanted to validate a form or set a radio button, Thau's tutorial's were your first stop when it came to learning the ropes. Well, it's 2007, and if you want to learn how to validate a form or set a radio button, you've come to the right place. As far as OO JavaScript, DHTML and XHR? Sorry. The state of the art has passed him by.
- GWT wrappers for Rialto - if you and your widgets are going to jump on a bandwagon, make sure you get it right. These widget wrappers didn't subclass Widget. Please fix.
- Vista - nuff said. (OK, IE7 and Vista.)
- Framework fanatics - don't get me wrong, I love the frameworks, but the JQuery and Mootools fans can really get on your nerves. They remind me of Ron Paul supporters (also known as "Paulbots") -- someone mentions Ron Paul and immediately the post gets 500 "Ron Paul is great" comments.
Well, that wasn't so bad. I'm sure everyone has their favorites or may in fact disagree with some of my gobblers. Who made your Turkey list?
Technorati Tags: ajax, editorial
Topics: Editorial
About Pathfinder
Recent
- Roles Testing For Security
- Blackbird takes the pain out of JavaScript logging
- Making GWT JSON not Quite so Painful
- IDEA - preconference workshop 06 Oct 08
- HTML5, Ajax history management, and The Ajax Experience 2008 Boston
- A Look Back At Past Posts
- Flash Player on iPhone gossip
- Microsoft to Jump on Board EC2
- TAE Boston 2008: The Unsexy Presentations
- The Ajax Experience 2008: Hope to see you in Beantown
Archives
- 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
Topics
.NET
2d physics
3d
3D GPS
3D physics
37signals
Accessibility
actionscript
activerecord
Add new tag
Adium
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Amazon
amf
Analysis
Android
Announcement
Announcements
antennae
Apollo
Application Architecture
Application Development
AS3
ASP.NET
Asynchronous Processing
awards
Back Button
Benchmarking
Best Practices
BitmapData.draw
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business
Business Reasons for Ajax
Business Rules
C#
Canvas
Case Studies
chess
Chicago
Cloud Computing
CMS
COBOL
code art
Code Generation
Color
COMET
Conference
Consistency
Content Management
CRM
CruiseControl
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
Desktop
Desktop RIA
Developer's Notebook
Diagnose
Dojo
Domain Knowledge
Drools
EC2
Echo2
Echo3
Editorial
ERP
Ethnographic Research
events
externalinterface
Ext JS
Facebook
ferret
FileReference
Firefox
Firefox Extensions
Flash
flash awards
flash player
flash player 10
Flex
flexunit
Flock
Flow
Frameworks
front end
front end development
Games
Gauge Component
getting things done
Git
Google
Google calendar
Google Gears
Grails
Graphics
Greasemonkey
Groovy
GStreamer
GTD
Gwittir
GWT
Healthcare
Hibernate
Hudson
IDE
Ideation
IE
IE6
IE7
IE8
ILOG JRules
Information Architecture
Innovation
Instructional Design
Interaction Design
Interview
iPhone
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSR-94
JsUnit
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
logging
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
Meebo
MetaWidget
Methodology
Microformats
Microsoft
Mobile
Mootools
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
NetNewsWire
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
Open Source
Opera
Oracle
ORM
osx
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PHP
physics
physics engines
plugin
preloader
process
Web/Tech
Product Definition
productivity
Progressive Enhancement
Project Website
Prototype
Prototyping
PV3D
QA
qooxdoo
Radiant CMS
rails
Really Simple History
References
Requirements
Requirements
Alice Toth
Requirements Visualization
Restlet
RETE
Review
Rich Interactions
ruby
rubyamf
Ruby on Rails
SaaS
Safari
San Francisco
Scalability
Scenarios
Scriptaculous
SDLC
Search
Security
Selenium
Semantic web
SEO
Server Side
Silverlight
SOA
Social Networking
Software Processes
Songbird
SpiderMonkey
Sprajax
Spreadsheets
Standards
Startups
STI
Story Telling
Struts
Tamarin
Task Flows
Test Driven Development
Testing
The Ajax Experience
Tilt Component
Tools
TraceMonkey
Training
Trends
Tumblr
Tutorial
Tutorials
Unit Tests
Usability
Usability Testing
User Experience
user experience design
user interface
User Interface Standards
User Research
UXD
Venture Capital
Video
Vision
Visualization
VLC
Volta
Web/Tech
Web 2.0
Web Design
Web Development
Webkit
Weblogs
Web Services
Web Standards
Widgets
will_paginate
Windows
Wireframes
WordPress
workflow
work life balance
XML
XML Metadata
XUL
Yahoo Map AS3 API
YUI
Zeigarnik
Zeigarnik Effect
ZK