Archives

The dust has cleared from An Event Apart Chicago 2007. Now that I’ve gotten the basic reportage out of the way (here and here), on to the editorial page.

Three things I loved

• The wide range of topics: Despite increasing specialization in the web-development field, jacks of all trades still dominate our industry. An Event Apart offered sessions by and for designers, information architects, writers and developers alike. The most interesting sessions were often the ones that didn’t cover my own specialties. Dan Cederhom and Jason Santa Maria both tackled visual design. There was little overlap between their presentations, yet each offered up practical device for folks who have to wing it with graphical design without much formal training. Similar cross-functional advice dominated the agenda.
• The skepticism about rules: Presenter after presenter – most especially Liz Danzico – prioritized guidelines over rules, research over dogma, and attention to one’s own audience over one-size-fits-all solutions. One thing that usually distinguishes a great developer, or at least a mature one, is the ability to juggle a host of competing concerns without getting lost in the weeds. Accessibility vs. Ajax, beauty vs. usability, power users vs. Great Aunt Tilly – everything is a tradeoff. If there was on overriding message to An Event Apart, it was that we have to think deeply and often about our audience, our business and our objectives and make informed decisions.
• The focus on end users: It should surprise nobody that the ALA folks are usability nerds, standards geeks and champions of the end user. But it was inspiring to see how the speakers translated that well-worn agenda into series of discrete, actionable tips for everyday developers. As with any complex human endeavor, web development is all about picking your battles. With a potentially limitless number of improvements that could be made to any site or application, it’s easy to feel overwhelmed. Most speakers showed how simple steps could provide incremental improvements in usability, accessibility, compatibility and profitability – all without starting over at the ground level.

Three things I didn’t love so much

• The absence of concurrent sessions: Packing all 500 attendees into one room for the same 12 sessions (picture here) allowed ample cross-pollination. I’m an RIA developer, but I got the most out of the design, IA and BI sessions. Nevertheless, I longed for the ability to choose from multiple sessions, split off from my colleagues, and come back together during breaks to compare notes. It’s not that any of the sessions were completely worthless. It’s just that most were designed for intermediate skill levels in the same core technologies. I really didn’t need to spend 15 minutes having xmlHttpRequest and getElementByID explained to me. It would have been great if some content had been pitched to masters as well as journeymen. The only way to make that work is through careful scheduling of multiple concurrent sessions.
• The dearth of programming content: A List Apart calls itself a site "for people who make websites," but not for people who make webapps. The broad range of topics very rarely extended to the programming realm. Only one session directly tackled JavaScript, and it was at an extremely elementary level. There was nothing on Java, Ruby, Python or .Net, let alone RIAs, widgets, mash-ups, Flex, Silverlight, GWT or JavaScript libraries. I know, I know, plenty of conferences already cater to those crowds. But as a programmer, I felt shortchanged. Again, concurrent sessions could have solved this, but I’m not sure programming – client- or server-side – will ever be on the ALA crowd’s agenda.
• The lack of schmooze time: The schedule included some after-hours social events and a 90-minute lunch break each day, but I talked to lots of attendees who felt like they didn’t get enough time to chat with other attendees. Other than a lonely bulletin board – and a social-networking site opened a few weeks ahead of time – there weren’t a lot of structured opportunities to connect job-seekers and recruiters or peers from separate companies. Part of the problem was probably the cramped accommodations. When folks had breaks, they were too busy stretching their legs to schmooze. Still, I would have loved to see breakaway sessions aligned by job or industry categories.

Conclusions

For "people who make web sites," An Event Apart was probably a fantastic chance to hear practical advice and smart prognostication from industry leaders. For people who write client-side webapp code, it was a very good round-up of philosophies and techniques that too often get lost amidst the technical details. For pure software engineers, it probably would have been a waste of time and money.

The other day I was reviewing a statement of work for a potential project when the client came to  the line item allocating time for requirements. Oh, the client stated, we don’t need to gather requirements. We do Agile development.

*Sigh* This myth of no requirements needed seems to be prevalent lately.

Well I hate to break the myth, but projects still need requirements regardless of the method used for development. The reality is you can’t create something unless you know what it needs to do. In order to know what it needs to do, you need requirements (business, technical and user).

The differences come in with the methods for gathering requirements. Some teams make requirements gathering the central activity, creating documentation detailing everything down to the nth degree before development begins. Other teams put less emphasis on knowing all beforehand and instead start with sketches or three sentence "stories", knowing that details will be filled in and added as the project progresses. Side note: make sure you have some way of documenting those hallway conversations because, yes, those are actually requirements gathering and it’s good to keep a record somewhere accessible by the project team.

At the most basic level, the purpose of requirements is to define the problem you’re trying to solve. Whether your team waits for a complete definition of the problem before starting development or starts with the basic outline depends on your development method. But you still need requirements. After all, if you don’t define the problem, how do you know when you’ve solved it.

Not sure how to write requirements? Check out my colleague’s post: Writing Requirements

Some thoughts and comments on the goings-on at Pragmatic Studio’s Rails Edge conference last week:

• There seemed to be a general sense among all the speakers that Rails is starting to mature — at least in the sense that nobody expects best practice style to keep changing every three months. There were a lot of semi-ironic asides from the speakers along the lines of “remember how we used to code this, like a year ago”, but the clear intent seems to be to tone down the waves, so to speak.

• There’s now a deployment story that everybody can get behind, as Mongrel clustering has gotten to the point where it can be easily set up as part of a powerful deployment stack. There do seem to be more improvements down the line, but Rails has finally gotten gotten to the point where a mere mortal with basic network admin skills can put something together that can run a decent-sized site.

• A lot of the speaker focus was on automated testing and coverage, which is great. Several of the speakers were explicit about taking the “if it’s not tested, it’s broken” line.

• If I had to guess, I’d say the next focus of improving Rails structure will be the view section. A lot of grumbling about ERB and how hard it is to test. There were a couple of suggestions for improvements, but this seems to be one area where nothing has coalesced yet.

• Rails core programmer Marcel Molina gave an interesting talk about factoring helper methods into smarter objects, but even he admitted he wasn’t quite sure what the best way to integrate the mechanism into Rails. Personally, I’d love to see a much more OO based than template based mechanism for views. Chad Fowler said that he thinks the best view system out there is in the Smalltalk Seaside framework.

• The single biggest “ooh, aah” moment from the crowd was when Dave Thomas pointed out that Rails evaluates (now..them).to_s(:db) as BETWEEN '2007-08-30 11:21:12' AND '2007-08-03 12:13:12'. Maybe you had to be there…

• I’m not sure to what extent this is meaningful, but the MacBook to all other laptop ratio was at least 4:1. Every single speaker used a MacBook, all but one used Keynote (one speaker had his talk on PDF), and all but one used TextMate (one speaker used Emacs).

BJAX = Browser Extensions + Ajax

I’ve continued my explorations on how to use GWT in unconventional ways, starting with how to load a GWT application through a bookmarklet. That’s been made much easier with GWT 1.4 through the introduction of a “cross site” feature:

Cross-site script inclusion is now supported. The compiler produces a “-xs” (meaning “cross-site”) version of your module’s startup script that can be included without being restricted by the same-origin policy. Be careful, though. Including scripts from other sites that you don’t fully trust is a big security risk.

There has been some confusion about this “option.” Some developers thought that “-xs” was a command-line flag you had to pass to the GWT compiler. In fact, the GWT compiler produceds a file with “-xs” in its name as a part of its normal workings — no special flags necessary. This file, when included in a page via a script tag, loads the GWT application as a Javascript (a “.js” file) into the current browser window. That’s opposed to the iframe/html way it’s been up to now.

Obviously iframe/html way is not suitable for things like bookmarklets, as the cross-domain thing gets in the way. With the pure Javascript approach, our problem is solved, right? Not so fast. If you try including the “-xs” Javascript file into a page via a bookmarklet, you get the dreaded hanging page with a perpetual “Loading…” message in the status bar. Why is that?

A little tour through an “-xs” file reveals that GWT assumes that the Javascript file is loaded during the normal loading/rendering of the page. Specifically, it uses document.write to insert script tags and uses an onload event handler to kick off the application code.

var $wnd = window, $doc = document, external = $wnd.external, gwtOnLoad, bodyDone, base = '',metaProps = {}, values = [], providers = [], answers = [], onLoadErrorFunc, propertyErrorFunc;[...]var oldOnLoad = $wnd.onload;$wnd.onload = function(evt){    if (oldOnLoad) {      $wnd.onload = oldOnLoad;      $wnd.onload(evt);    }    bodyDone = true;    maybeStartModule();}[...]$doc.write('<\/script>');

Of course this doesn’t work so well with a bookmarklet. For one, the onload event is already long gone by the time we run our code, and for another, document.write after a page has rendered will cause precisely the “hanging page” behavior we see when we try to load the GWT app via a bookmarklet. Really, this is less of a specific bookmarklet problem and more of a general “how do I get GWT to load after a page has already rendered” problem. So, what can we do to remedy this it?

First, we can simply use document.appendChild to insert the script tag, second, we can assume that the body has finished loading, and third, we will have to tell GWT where to find the application code. Why this last step? Because GWT uses a “marker script” to figure out the source URL of the GWT application:

function computeScriptBase(){    var thisScript, markerScript;    $doc.write('<\/script />');    markerScript = $doc.getElementById('__gwt_marker_MyApp');    if (markerScript) {      thisScript = markerScript.previousSibling;    }    function getDirectoryOfFile(path){      var eq = path.lastIndexOf('/');      return eq >= 0?path.substring(0, eq + 1):'';    }

    ;    if (thisScript && thisScript.src) {      base = getDirectoryOfFile(thisScript.src);    }    if (base == '') {      base = getDirectoryOfFile($doc.location.href);    }     else if (base.match(/^\w+:\/\//)) {    }     else {      var img = $doc.createElement('img');      img.src = base + 'clear.cache.gif';      base = getDirectoryOfFile(img.src);    }    if (markerScript) {      markerScript.parentNode.removeChild(markerScript);    }}

When you use document.appendChild, this code stops working. Now there’s probably a way to make this code work with appendChild, but I haven’t noodled about it enough. That’s why this post is termed a “Quick Hack.”  We do some simple surgery with the “-xs” file as follows:

function insertScript(src) {    var script = document.createElement("script");    script.type = "text/javascript";    script.src = src;    $doc.body.appendChild(script);}[...]function computeScriptBase(){    base = "http://labs.pathf.com/MyApp/";    bodyDone = true;}[...]insertScript(base + strongName);

With these changes, the GWT app can now be load via a bookmarklet.

Next week, I hope to demonstrate a few interesting hacks using GWT and bookmarklets. Maybe I’ll even give the dowdy Craig’s list a much needed overhaul. Stay tuned…

Technorati Tags: ajax, bjax, bookmarklet, gwt

Tuesday saw the conclusion of An Event Apart Chicago 2007, the two-day web-development conference from the folks at A List Apart. Here’s my sequel to yesterday’s day-one overview. I’ll be back Friday with analysis and afterthoughts.

Jeremy Keith, author of "Bulletproof Ajax" and "DOM Scripting," led the day. His topic? "Be Pure. Be Vigilant. Behave," wherein he outlined the concepts behind "Hijax," the application of progressive enhancement to Ajax functionality. A staunch proponent of unobtrusive JavaScript, Keith warned against throwing web standards out the door when developing Ajax functionality. His examples demonstrated how to separate behavior from content and presentation by abandoning such outmoded techniques as the javascript: URL pseudo-protocol. His most extensive example showed how to code a graphical widget for the assignment of star ratings so that it would degrade gracefully into a standard HTML select box in less capable browsers. After discussing the difficulty of making XHR functionality play nicely with bookmarks and the back button, Keith acknowledged that his parting message – when in doubt, leave XHR out – was a bit of a copout for the author of an Ajax manual.

Next up was Luke Wroblewski, a Yahoo product designer whose resume includes work on the original Mosaic web browser. Wroblewski covered "Best Practices for Form Design" using exhaustive research from his forthcoming book on the subject. In case study after case study, he demonstrated how simple choices in the design and deployment of HTML forms – from the widths and alignment of inputs and labels to the placement and visual differentiation of cancel and submit buttons – can cut the time it takes to complete them in half. Wroblewski’s most persuasive argument, however, was conceptual rather than technical. He made a powerful case that because forms are barriers between users and the things they want to do – buy your product, join your site or begin creating content – you should make them as easy to get through as possible. This central thesis added considerable weight to his many practical how-tos.

Accessibility advocate Derek Featherstone closed off the morning with "Accessibility: Lost in Translation." Featherstone looked at how markup choices can make a site transparent to assistive devices – or render it totally opaque. Using real-world examples from Amazon and other sites, he demonstrated how screen-reading software actually parses markup. His live examples proved that the lack of semantic markup and the absence of ostensibly optional HTML attributes can render a site worthless for disabled users. Featherstone then went beyond the basics, explaining how source order – the sequence in which nodes appear in your markup – can be used to enhance accessibility. By placing your central content first, then positioning chrome above it with CSS and providing jump navigation to skip past inessential modules, you can achieve the presentation you want for typical users without shortchanging disabled ones. In another example, Featherstone examined the ways in which meaning can be encoded in the color and position of elements on the page – and how to replicate that meta-data in a way that disabled users can understand. As with many of the other speakers, Featherstone’s examples argued persuasively for the continuing relevance of web standards.

After lunch, CSS expert Eric Meyer again took the stage, this time to explore "The State of CSS in an IE7 World." Using the recent release of Microsoft Internet Explorer 7 as a springboard, Meyer illustrated the concepts that have governed the changing of the browser guard for more than a decade. His overall premise was that developers need to use their own server logs to gauge when support for an older browser can safely be dropped for their site. For most of us, IE6 isn’t going away anytime soon, so we need to get creative if we want to harness advanced functionality. To that end, Meyer delved deeply into the details of IE7 techniques, filters and hacks. He praised the browser for the strides it makes over IE6′s CSS engine in such areas as child selectors, adjacent sibling selectors and attribute selectors. His real-world examples demonstrated how such functionality adds power and elegance to our code. To cope with IE6′s continuing market share, Meyer advocated the use of Dean Edwards’s IE7 compatibility script, a JavaScript library that adds IE7 capabilities to older versions of the browser. The take-home message was that older browsers may take a long time to die out, but creative programming techniques can harness the future of CSS now.

The final two sessions for AEA Chicago 2007 were a little offbeat, which was a relief after 10 technical sessions in the previous 32 hours. In the highly anecdotal "Selling Design," ALA publisher Jeffrey Zeldman used stories from his own long career to illustrate best practices for handling difficult clients. His thesis was that collaborative work requires us to deal with a wide range of other people, so we should hone our ability to influence our collaborators – and pick good clients to begin with. Agency owner Jim Coudal closed things off wittily with "Dealing With the Both of You," a slide-free presentation about the crossover between personal projects and professional work-for-hire. Coudal assembled a number of satirical short films to drive home his point: Because most web developers are curious and easily bored, we should strive to marry passion with professionalism whether our clients are external or ourselves.

The folks from A List Apart rolled into town yesterday for An Event Apart Chicago 2007, a two-day web-development conference. Around 500 programmers, designers and information architects flocked to the seventh floor of the downtown Mariott for a varied slate of talks by some of the biggest names in the industry. Today and tomorrow I’ll give high-level overviews of each day’s sessions. On Friday, I’ll provide some color commentary.

Stylesheet guru Eric Meyer‘s “Secrets of the CSS Jedi” kicked things off with an in-depth case study in which pure CSS 1 and 2 transformed tabular data into an Excel-style bar graph. Meyer’s presentation was interesting not only for what his techniques could accomplish, but also for what they couldn’t. It was inspiring to see that plain-vanilla data could be given a powerful visual makeover, yet still remain completely semantic and accessible to handicapped users. But it was disheartening to see that the simple addition of tick marks within the graph demanded the addition of hard-coded percentage values to a number of CSS classes. The lack of simple computational ability within CSS declarations has long been a drawback of the “not a programming language” language. CSS remains a powerful and flexible technology, but, as I discussed at length a few days ago, it’s got a lot of room for growth. For those who were already conversant with Meyer’s techniques, perhaps the most interesting digression in his talk was the chance to tear through Firefox’s built-in browser stylesheets and see how even the most fundamental rules of HTML presentation – such as the invisibility of meta tags and the entire <head> block – are controlled by CSS behind the scenes. Meyer also went over the basic building blocks of the kind “reset” stylesheet most jedis use.

Up next was Jeffrey Zeldman, publisher of A List Apart and therefore another another rock star to this crowd. A lot of recent ALA content has focused on the overlooked art of writing for the web, so it was no surprise that Zeldman tackled the topic “Writing the User Interface,” which packed in plenty of practical advice for writers and non-writers alike. His central thesis was that copy was the cheapest and easiest thing to improve on most sites. Using lots of witty real-world examples, he provided a useful paradigm for breaking textual content into discrete components – guide copy (a.k.a. instructional text), brand copy (taglines and other branding assets), copy copy (a.k.a. real content), labels and URLs – and applying different editing criteria to each. As befits the author of “Designing With Web Standards,” Zeldman was careful to demonstrate that the rules of good web writing and the rules of semantic markup are often one and the same. As with most of Zeldman’s advice over the years, he started with a compelling philosophy, then showed how to break it down into small, actionable steps.

Happy Cog designer Jason Santa Maria finished off the morning block with “Design Your Way Out of a Paper Bag,” a look at the process of rebranding and redesigning an existing site. An illustrated tour of Santa Maria’s own iterative design process, the presentation was, like the earlier sessions, a case study in how a series of small steps can have a big impact on the usefulness of a site. Using an amusing Flickr tour of real-life signage and the abuse and misuse of the poor apostrophe therein, the designer drove home his biggest advice: “Sweat the small stuff.” Along the way, he touched on typography, branding, logo development, grid-based layout, whitespace and other design concerns. As befits a designer, Santa Maria’s session was probably the most visual and the least easily captured in the PDF slides distributed to attendees. He did, however, suggest some excellent further reading, most notably “The Elements of Typographic Style,” “Thinking With Type,” “Grid Systems” and “Making and Breaking the Grid.”

After lunch, Lou Rosenfeld led with “Search Analytics For Fun and Profit.” In a series of painstaking real-world case studies – most notably of my alma mater Michigan State University – Rosenfeld explained how server logs and especially search engine logs offer the keys to a successful site redesign. It’s a simple idea that may seem elementary to many developers, but given how infrequently web-development teams actually use this feedback loop effectively, Rosenfeld’s techniques struck me as really powerful. You would expect a session like this to show you how users’ most popular search terms could serve as the springboard to an overhaul of your navigational systems. But Rosenfeld also delved several levels deeper, showing how much powerful business intelligence can be obtained from inexpensive tools with little or no custom code to support them. Site indices, metadata, search algorithms and the search interface itself – all can be tweaked based the subtle metrics that emerge from careful, detailed session analysis.

Perhaps the most inspiring session was Liz Danzico‘s “The Seven Lies of Information Architecture,” in which the Happy Cog information architect recast the high commandments of IA as guidelines rather than rules. Danzico used copious examples to demonstrate how the most successful sites often bend or break the supposedly unwavering rules of IA. The idea of the magic number – most users can only remember 7 +/- 2 items in their short-term memory at any given time – was the first concept to show cracks under Danzico’s microscope. She went on to debunk the holy status of such maxims as “consistency is good,” “navigation is necessary,” “the shortest path is the best path,” “experience must be seamless” and “users should always know where they are.” Sometimes, the idiosyncratic nature of her examples suggested that certain guidelines work for most sites and are best broken only for a specific purpose. Other times, especially in her examination of Amazon‘s and Apple‘s navigational systems, her case studies suggested that even mainstream sites do and should break the rules. It was Danzico’s last rule – the idea that only IAs should do IA work – that she most thoroughly debunked by the end of her session. She argued passionately that site owners, designers, programmers and end users can and should understand the guidelines of information architecture – but, like IAs themselves, they should apply those guidelines judiciously rather than rigidly.

Last up was designer Dan Cederholm, founder of SimpleBits and Cork’d. He constructed an elaborate site prototype, ToupeePal, to demonstrate “Interface Design Juggling,” his thesis that great design involves keeping lots of balls in the air at the same time. Delving deeply into typography, microformats and the development of favicons, Cederholm demonstrated that beautiful and useful interfaces can be constructed using the supposedly unsophisticated visual and informational tools already at our disposal. Cederholm cried foul on the idea that web typography sucks because too few cross-platform fonts are available. He argued that the single-font typography of the Itallian Renaissance is some of the most beautiful ever created, then he demonstrated practical techniques for getting similar mileage out of limited existing web fonts. Word-spacing, letter-spacing, line-spacing, color, weight, italicization and other simple tools can all elevate even the most familiar typefaces into the design stratosphere. Likewise, even a tiny 16×16-pixel favicon can provide a powerful branding tool when designed correctly. Cederholm closed with an in-depth look at the “accidental API” of microformats, demonstrating that a even a grassroots open-source movement can add power and value to the web without the support of standards bodies and browser vendors.

Check back tomorrow for coverage of today’s sessions, from Eric Meyer’s look at the post-IE7 world to Derek Featherstone’s talk on accessibility.

Last week I attended Pragmatic Studio’s “The Rails Edge” conference in
Skokie, IL.  I’m going to do a couple of posts on this. For the
first post, I thought I’d present some of the best quotes that I noted from the speakers
over the three days.

“Java is the blunt scissors of programming”
  — Dave Thomas, Pragmatic Dave himself, in a talk about Metaprogramming Ruby, and alluding to the way Java was explicitly designed to prevent a programmer from changing the program context..

But, if a Ruby programmer can change existing classes, can’t you shoot
yourself in the foot? That’s not a Ruby problem…

“That’s a people problem. It’s solved by four feet of rubber hose in the car park”
  — Dave Thomas, who presumably was kidding. Kind of.

Later…

“The key to metaprogramming is understanding self. Isn’t that the key to life”
  — Dave Thomas, exploring the parallels between metaprogramming and metaphysics.

Moving on…

“I hate using the words ‘best practice’”
  — Chad Fowler

“Unless you understand the SQL code that Rails produces, your app will suck.”
  — Chad Fowler

“Metaprogramming + DSLs is the Ruby equivalent of Design Patterns in the Java world”
  — Chad Fowler. Fowler’s point here was more about the buzz and hype, just like there was a time in the early 2000s when every Java programmer wanted Design Patterns whether or not they were needed, Fowler sees a similar rush to add DSLs to Ruby programs.

“Model/View/Controller apps are like GOTO for the web”
  — Avi Bryant, quoted by Fowler.

In general, the shortcomings of Rails view support were an ongoing theme,

“I think it’s sad that Rails is still using ERB”
  — Chad Fowler

One of the best talks was by Ezra Zygmuntowicz about Rails deployment. The
talk was introduced thusly:

“Rails deployment made you feel dumb. It was hard and then it still didn’t work”
  — Mike Clark. To be clear, Clark was emphasizing the past tense in that statement.

Zygmuntowicz, quickly moved to establish his credentials…

“I’m running, like 7000 Mongrels right now”
 
— Ezra Zygmuntowicz

Later, Justin Ghetland presented on JRuby, proclaiming that it has

“The elegance of Java, the speed of Ruby”
  — Justin Gehtland

“In order to win companies need to unleash the creativity of open source, without fetters”
 
— Justin Gehtland, discussing the difference between Sun’s handling of JRuby and Microsoft’s handling of IronRuby

“Any time you try to impose a hierarchical order on the world, you’re bound to be disappointed”
  — Dave Thomas, commenting from the stands during a later talk on REST and its strengths and weaknesses

One of my favorite talks was from Stuart Halloway about Agile, Enterprise,
Ruby, and Rails. A boatload of good quotes here, I’m going to skim off
my favorites.

“The right process is always ‘not quite enough process’”
  — Stuart Halloway

Stuart continued by saying that if you are using note cards for tasks and
everybody kind of things that maybe they should use an Excel spreadsheet,
then you’re probably in the right place, but if it’s causing real pain,
you need to change.

“Do the dumbest, simplest thing that almost works”
  — Stuart Halloway, on process

Dave Thomas chimed in from the cheap seats…

“The traditional view, with sixteen pounds of documentation, introduces a single point of failure in the process, understanding the problem domain”
  — Dave Thomas

“Getting a specification involves bullying the customer”
  — Dave Thomas

Halloway then talked about enterprise development:

“What makes something enterprise? My favorite definition is to add two zeros at the end of the price”
  — Stuart Halloway

Halloway went on to justify the increased cost because of the increased
amount of security and specification that an enterprise customer needs.

“What does scalable mean? [Pause. Nobody answers.] Ha. Ha. Rails programmers
  don’t know what scalable means”
  — Stuart Halloway

The definition of scalable Halloway used was a linear increase in complexity
as size increases. Therefore:

“Rails is slow. But it’s scalable.”
  — Stuart Halloway

Pragmatic Dave chimed in from the front row:

“Scalable is more important to a one-man shop than to an enterprise.
  An enterprise isn’t going to quadruple in size overnight”
  — Dave Thomas

Jumping ahead here, Halloway made the following observation

“If programmers, on average, were able to write parsers and compilers, Ruby on Rails would not have taken off”
  — Stuart Halloway

The point being that if programmers were able to write there own DSL’s, then
they wouldn’t need Rails’ support for doing so.

Halloway then continued to talk about Agile process, advocating 100% code
coverage all the time.

“I don’t worry about performance until I have accurate, customer-verified code”
  — Stuart Halloway

“Making something fast too early is a classic symptom of somebody who wants an opaque development process”
  — Stuart Halloway

Great talk. I’ll have more to say about it in a later post, I think.

Later on, there was a big focus on testing, especially testing Rails views.

“If you can’t test it, then it’s not a beautiful design. If you can’t test it, it doesn’t exist”
  — David Chelimsky, summing up the prevailing sentiment

“I’m pairing with 130 people. That’s promiscuous programming, that’s what that is”
  — Dave Thomas, in a talk about buried treasures in Rails, as the entire room is correcting his typos

“We have four levels of indirection. We should be able to solve everything”
  — Justin again, talking about the layers between RJS code and something actually happening in a browser.

That’s the best of the quotes. Next post will be about some of the themes
and discussions of the conference.

In computability theory the Church–Turing thesis (also known as Church’s thesis, Church’s conjecture and Turing’s thesis) is a hypothesis about the nature of computers, such as a digital computer or a human with a pencil and paper following a set of rules. The thesis claims that any calculation that is possible can be performed by an algorithm running on a computer, provided that sufficient time and storage space are available. The thesis cannot be mathematically proven; it is sometimes proposed as a physical law or as a definition.

Informally the Church–Turing thesis states that our notion of algorithm can be made precise and computers can run those algorithms. Furthermore, a computer can theoretically run any algorithm; in other words, all ordinary computers are equivalent to each other in terms of theoretical computational power, and it is not possible to build a calculation device that is more powerful than the simplest computer (a Turing machine). Note that this formulation of power disregards practical factors such as speed or memory capacity; it considers all that is theoretically possible, given unlimited time and memory.

The thesis, named after Alonzo Church and Alan Turing, was first proposed by Church in 1934, then referencing the class of λ-definable functions, but did not gain acceptance until Turing defined the equivalent but much more convincing Turing-computable functions. — From the Wikipedia

Back in college I took a graduate course in Recursive Function Theory. I studied Mathematics in college, am the son of two mathematician, and have a great love of complex problems with elegant solutions. So I enjoyed the heck out of this course. Lots of nifty little puzzles and mind benders. Translate these concepts, though, to practical software engineering through languages like ML and Haskell, and I break out in hives. It is too hard for most lunch pail  developers to understand, and it causes too many unnecessary problems in common software engineering scenarios. That’s my bias and I’m entitled to it.

Still, it is important to be exposed to these concepts as a developer, as some problems are definitely in functional programming’s power zone. Enter Higher Order Perl, a book by Mark Jason Dominus that aims to educate the reader on the use of Higher Order Functions in Perl.

Higher-Order Perl is about functional programming techniques in Perl. It’s about how to write functions that can modify and manufacture other functions.

Why would you want to do that? Because that way your code is more flexible and more reusable. Instead of writing ten similar functions, you write a general pattern or framework that can generate the functions you want; then you generate just the functions you need according to the pattern. The program doesn’t need to know in advance which functions are necessary; it can generate them as needed. Instead of writing the complete program yourself, you get the computer to write it for you.

If this sounds a bit like the proverbial "genetic, neural network, self-modifying code," hold on. Successful and productive software design is all about abstraction. Object orientation is just one kind of abstraction, functional programming provides another.

Inspired by the Perl title, others have written online works on Ruby and JavaScript. I highly recommend the JavaScript work by Sean Burke. As I said before, even if you don’t head down the road of functional programming in JavaScript, it is still a good thing to periodically expose yourself to some new and different ideas.

Technorati Tags: ajax, javascript, higher order functions, church’s thesis

My post about learning to organize classes without the semantic sugar of Prototype earned me some wide-ranging comments here and on Ajaxian. My favorite was Isaac Z. Schlueter Matthew Smith’s proposal of a new framework: JLJ (Just Learn JavaScript). To that end, I thought I’d compile some of the most useful sites and posts I’ve come across in my quest over the last couple of years to employ better inheritance strategies in my JavaScript.

Let’s face it, in the wide world of web development, for every
dedicated client-side developer with a real taste for JavaScript, there
are 10 Java middleware developers who believe that JavaScript isn’t a
"real" object-oriented language. Programmers with a broad range of
experience in a wide array of languages will argue that JavaScript’s
loose typing, dynamic nature and prototype-based inheritance scheme are
actually far more "object-oriented" than, say, Java or C++. That may be
true, but there are lots of folks out there writing production code who
have never written complex software using any language _but_
JavaScript. For these folks, myself included, JavaScript’s dynamism is
both a blessing and a curse. There’s a lot of freedom, but not a lot of
guidance. Languages that rely on good developer
behavior rather than the intrisic properties of the language themselves
can be dangerous. Just enough rope to hang yourself, and all that jazz. For those of us whose primary language is JavaScript, a little structural guidance can help a lot.

As the inestimable Douglas Crockford illustrates in Classical Inheritance in JavaScript, the main benefit to inheritance in a dynamic language is re-use. Most of us are interested in getting the most mileage possible out of every line of code we write. Many JavaScript frameworks enforce or encourage a particular method of doing this; most are modeled on the classical inheritance schemes of other languages. Every serious student of JavaScript should learn the strengths and weaknesses of these patterns – and how to implmenet them on the fly, without a framework to fall back on.

A note on this list: It’s a highly subjective smattering of articles I found useful. Some are high-level discussions of JS itself, or of inheritence strategies in general. Others grapple with the interitance models of specific libraries in ways that highlight the underlying issues. I could post a completely separate list of JS/Ajax frameworks and their various approaches to the topic. But that’s a different post for a different day.

On to the list:

Inheritance Strategies

• JavaScript: The World’s Most Misunderstood Programming Language: Another Crockford classic. Start with this, graduate to the aforementioned inheritance article, and then lose a few days in the wilds of his site.
• Private Members in JavaScript: While you’re there, check out this piece.
• Objectifying JavaScript: A strong tutorial from Digital Web.
• OOP in JS: An older but still-relevant multi-part case study in how to mimic class-based inheritance in JS.
• Correct OOP for Javascript: A didactic but persuasive look at classical inheritance models.
• Object Oriented Programming in JavaScript: A fairly dry but compelling paper examining a couple of different class-building strategies, based on an earlier 2003 paper.
• Prototype: Inheritance Madness: An examination of Prototype’s approach to classes.
• Base: A JavaScript inheritance framework.

Closures, the Global Namespace and the Module Pattern

• Global Domination: A seminal YUI blog post about the dangers of the global namespace.
• Javascript Closures for Dummies: The title says it all…
• JavaScript Closures … but this one says it more succinctly.
• A JavaScript Module Pattern: Another YUI blog post, this one annotating Crockford’s module pattern.
• YUI’s Module Pattern vs. Prototype’s Class Function: Isaac Z. Schlueter‘s interesting post on Crockford’s module pattern and how to extend it into a reusable constructor.
• Show love to the Module Pattern: More commentary on the module pattern.

Singletons, Lazy Constructors and Memoization

• JavaScript: The Singleton Design Pattern: A quick overview of singletons, with an interesting perspective on anonymous constructors.
• Lazy Function Definition Pattern: A blog entry from a functional-programming viewpoint.
• One-Line JavaScript Memoization: How to save overhead by doing the hard stuff once and saving it off.

Further Reading: DSLs, Aspect-Oriented Programming and More

• Metaprogramming JavaScript Presentation: Domain-specific languages and JavaScript.
• AspectJS: An AOP library for crosscutting concerns.
• Scope in JavaScript: Another piece from Digital Web, this time tackling how to master the this keyword, Function.apply and Function.call.
• Seven JavaScript Techniques You Should Be Using Today: Not specifically devoted to OOP, but a good roundup of best practices in general.

Aejaks, a Tcl/Tk style framework built on top of Echo2, has a new version out: 0.5, now considered Beta. What’s in the new release?

• Echo2 Extras widgets – MenuBar, Drag/Drop, TabPane, TransitionPane, etc.
• Echo2 Chart widget
• Echo2 FileTransfer widget & Download command
• TaskQueue command – update widgets asynchronously
• Nuvola icon set -3,700+ high quality icons ready to use
• Updated widget_tour demo to show off all new widgets
• Download packages now split between exe and src; separate war file can also be downloaded which runs the widget_tour demo.

Check out the project news page and the 0.5 CHANGELOG.

Technorati Tags: ajax, echo2, aejaks, tcl, tk