Pathfinder Blog
Archive: August 2007

An Event Apart: Wrap-Up

Brian Dillard, Friday, August 31, 2007 @ 5:30 am

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.

Topics: , , , , , , ,

agile ajax Agile Ajax

We Don’t Need No Stinkin’ Requirements

Alice Toth, Thursday, August 30, 2007 @ 11:52 am

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

Topics: ,

user experience design User Experience Design

The Rails Edge: Notes

Noel Rappin, Thursday, August 30, 2007 @ 11:22 am

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).

Topics:

agile ajax Agile Ajax

BJAX: A Quick Hack for Using GWT with Bookmarklets

Dietrich Kappe, Thursday, August 30, 2007 @ 5:52 am

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: , , ,

Topics: ,

agile ajax Agile Ajax

An Event Apart Chicago: Day 2

Brian Dillard, Wednesday, August 29, 2007 @ 9:03 am

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.

Topics: , , , , , , , , , , , , , , , ,

agile ajax Agile Ajax

An Event Apart Chicago: Day 1

Brian Dillard, Tuesday, August 28, 2007 @ 7:42 am

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 16x16-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.

Topics: , , , , , , , , ,

agile ajax Agile Ajax

The Rails Edge: Quotes and Notes

Noel Rappin, Monday, August 27, 2007 @ 11:34 am

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.

Topics: ,

agile ajax Agile Ajax

Higher Order JavaScript

Dietrich Kappe, Monday, August 27, 2007 @ 5:52 am

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: , , ,

Topics:

agile ajax Agile Ajax

Developer’s Notebook: Useful OO JavaScript resources

Brian Dillard, Friday, August 24, 2007 @ 5:51 am

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

Closures, the Global Namespace and the Module Pattern

Singletons, Lazy Constructors and Memoization

Further Reading: DSLs, Aspect-Oriented Programming and More

Topics: , , , ,

agile ajax Agile Ajax

Aejaks 0.5 Integrates Echo2Extras

Dietrich Kappe, Thursday, August 23, 2007 @ 5:08 am

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: , , , ,

Topics: ,

agile ajax Agile Ajax

CSS considered harmful by Ajaxian commentators?

Brian Dillard, Wednesday, August 22, 2007 @ 5:23 am

There's a super-entertaining comment thread/flamewar going down at Ajaxian in response to Dion Almaer's recent editorial on The Future of CSS and the end of 3.0. Almaer has lots of interesting and perceptive things to say about the maddeningly erratic way in which new standards make their way into general use. But the vast majority of commentators jumped at the chance to sound off on some of his minor points:

CSS is great for simple web style. CSS is awful for layout. Rich Ajax apps need layout. You spend the majority of your time trying to get CSS working correctly!

Of those four assertations, there's not a single one I can fully endorse. IMHO, current implementations of CSS are _pretty good_ for simple web style, but they're not great. (See the comments for many examples: rounded corners, varied fonts, etc.) They're not great for layout, either, but if you take the time to learn the tricks - and account for spotty browser implementations - then you can develop attractive, robust and usable UIs using CSS. As for whether rich Ajax apps need layout, well, yes. But what kind of layout is open to considerable interpretation. Just because the first few generations of web designers kept trying to apply the same old print paradigms to the browser doesn't mean it was right. The same goes for the current wave Ajax frameworks and the desktop-app layout paradigms some of them attempt to implement.

The assertation that bothers me the most, though, is the one about the time it takes to get CSS working properly. As with any code executed in the browser, CSS is subject to the quirks and peccidillos of browser vendors, operating systems and ever-mutating standards. Still, once you account for the major differences in execution environment, it's not that hard to come up with a single global stylesheet that can zero out built-in styles and browser quirks to offers a more or less blank canvas for cross-browser CSS development. CSS authors may not release their design frameworks under open-source licences the way JavaScript authors do. But that doesn't mean they don't exist. Just peek under the hood at a big, forward-thinking consumer webapp or pick up a Jeffrey Zeldman book.

Regardless of what _I_ think, the thread at Ajaxian provides an interesting vox populi. As can be expected, comments range from wholehearted endorsements of Almaer's position to finger-wagging about the importance of web standards to chest-puffing from people who've mastered the tricky art of CSS layout and don't have much sympathy for those who haven't. I'm fascinated by the way participants in these conversations let their personal investment in a certain skill set lead them to make sweeping generalizations about entire swaths of the software-engineering world. Just because you know how to make a site look a certain way using tables, or floats, or XSLT, doesn't mean that that's the only way, or that the Internet won't eventually cough up a much better way than any of the above.

The fact is, any programming language or development framework can be improved, and there's lots to both love and hate about the CSS specs and the various imperfect implementations of them. It's _so_ far from the all-or-nothing proposition that many of the commentators would have you believe.

Dealing with client-side technology is frustrating for anybody who's used to having complete control over their execution environment, or a stable platform at all. The reason the pace of change is so glacial on the client side is that standards take time to develop; vendors take time to implement them; and a variety of market forces contribute to how well and how quickly they're implemented. Nobody said the Open Web was easy, but it's vastly preferable a host of closed-off, proprietary formats controlled by individual vendors and immune to grassroots innovation.

Any developer who's lived through successive generations of client-side technology knows that things have only gotten better with time. It's hard to imagine that standards won't continue to improve, no matter how painfully slow the process.

Topics: , , ,

agile ajax Agile Ajax

jQuery vs. Prototype: OO JavaScript with or without training wheels

Brian Dillard, Tuesday, August 21, 2007 @ 8:25 am

After brushing up on jQuery via a little light reading, I've started to play with the framework in code. I'm demoing a scrolling news ticker and decided to write it using jQuery and its Interface plug-in. Future iterations will probably include the history and easing plug-ins, too. In the meantime, though, it's been two steps forward, one step back. I really dig the elegance of the jQuery API and its concise method-chaining. But there's one integral element of the Prototype/Script.aculo.us framework that I miss: The Class object and the OOP training wheels it provides.

For developers like myself - long-time UI folks who have used JavaScript's Object datatype for years but lack significant experience writing in a strongly typed, truly object-oriented language like Java - Prototype has been a revelation. It doesn't enforce OOP principles, but it encourages them. And its source code is like a Rosetta Stone for how to implement them in the dynamically typed, prototype-based world of JavaScript.

There's been lots of discussion over the past year about the deficiencies of Prototype's inheritance scheme. A lot of the syntax is ugly, and Object.extend is easy to overuse or misuse. The new 1.6.0 release candidate appears to address some of those weaknesses by augmenting the Class object's API. Regardless of your position on this debate, though, it's hard to ignore the fact that Prototype has helped a lot of front-end folks improve their half-assed understanding of OOP. Personally, I wouldn't even be in a position to follow the discussion if I hadn't spent the last 18 months or so writing Prototype-backed JS classes. Thanks to the patterns to which this library has exposed me, my grasp of JavaScript - and of software engineering in general - has grown by leaps and bounds.

Once I started using a different library, though, Class.create was suddenly useless. I had to figure out different inheritance and encapsulation strategies. The training wheels were off, and I had to find my own of balance. My first hurdle was figuring out how to organize my jQuery procedures into reusable methods. I felt totally adrift without the built-in ability to bind functions to their execution environment; the this keyword was always assigned to a DOM node. I thought about simply porting Prototype's Function.bind and Function.bindAsEventListener methods, but that seemed at odds with the design of jQuery's own API. Finally, I turned to Douglas Crockford's module pattern for JavaScript. Now I had a new way to organize my objects and methods in a reusable way that worked well with jQuery. By defining private methods inside of a closure, I could access those methods with simple function calls, no binding necessary. As with Prototype, a whole new world opened up.
   

A lot of developers worry that Ajax frameworks make for lazy programmers, but in my experience the opposite is true. Each new design pattern or framework that I play with teaches me new approaches to JavaScript and OOP in general. Folks coming at UI development from, say, a C++ background may want a framework that enables a well-defined inheritance model. But OOP scaffolding is a separate concern from Ajax and DOM tools. Prototype provides both, while the base jQuery library provides only the latter. Still, somebody could easily write an OO plugin for jQuery - or several of them, each implementing a different inheritance model.

Simon Williamson's recent post on jQuery for JavaScript programmers does a good job of explaining how jQuery encourages good OOP techniques. The walled-off namespacing represents a different conceptual model from Prototype's. Until you understand both, it's difficult to see all the strenghts and weaknesses of either. As with other tool, the key to these frameworks is learning what tricks and tradeoffs each one supplies, and why. Up next: YUI and Ext.

Topics: , , , , ,

agile ajax Agile Ajax

Test-Driven Development As Part of the Process

Noel Rappin, Monday, August 20, 2007 @ 10:36 am

About a year ago, I wrote this post about test-driven development,
which has some tips for TDD from a developer point of view. I thought I’d
augment that a little bit by offering some thoughts about TDD from the larger
project perspective.

The Long Term Starts Tomorrow

There’s a general sense that automated testing is something you do that costs
you time in the short term for a long term benefit. This is probably true to
some extent, although I’d argue that if you are really seeing a short term
time loss from TDD, then you probably could improve your practice some.

The larger point is that referring to “the long term” makes the benefits seem
like something that will happen in the comfortably remote future, along with
flying cars and space elevators. Usually, though, the long term starts the
first time somebody asks you to add a feature or fix  a bug. Which means next
week. Or tomorrow. Or later today. The benefits accrue faster than you think.

Retrofitting for Tests Never Quite Works

There aren’t a whole lot of programming tasks in the agile world that are as
as annoying and frustrating as adding unit tests to existing code. The
existing code never has all the structure and hooks needed for good testing,
which means refactoring is needed to get any useful testing in. Of course, the
existing code doesn’t, by definition, have tests, so there’s danger involved.
Inevitably, there’s some monstrously hairy corner of the code that nobody
wants to touch and it just hangs there, untested. You’ll almost always also
see that design decisions that were not made with testing in mind are not
particularly amenable to allowing unit testing later on. The cost of
retrofitting accrues faster than you think, as well.

Refactoring is Just As Important

The test-driven development process is a three step process. Test, code,
refactor. The refactor step gets left off sometimes, but it’s just as
important as the other two in getting the full benefit of TDD. There is an
analogy to continuous integration, where the idea is by integrating in more
frequent, smaller chunks, the overall integration costs go way down.
Similarly, by doing frequent, small refactoring, overall cost of refactoring
to keep the code clean goes way down. It helps tremendously to do the
refactoring in the tight loop, when you are most familiar with the code and
the tests you’ve just written.

tech development Tech Development

IDE Watch: Echo2 Module for NetBeans

Dietrich Kappe, Monday, August 20, 2007 @ 5:48 am

We can see the beginnings of IDE support for Echo2 in NetBeans. This isn't close to the commercial plugin for Eclipse provided by NextApp, which, among other things, provides a widget tree and property editor that eases UI assembly. But the nbecho2support module does a couple of useful things for you. First, it will create an Echo2 webapp project for you with Echo2, Echo2Extras and the EchoPointNG libraries already included. Also, the web.xml file is already configured (though you will have to edit the default index.jsp to redirect to the /app url).

The one Echo2 specific filetype that can be created is the Echo2 style sheet, default to blank. So, definitely a useful module for those who want to work with NetBeans, with plenty of room for improvement.

Technorati Tags: , ,

Topics: ,

agile ajax Agile Ajax

The Ten Commandments for Technical Requirements: VII: Presentation: The Art of Gladness

Scot Witt, Sunday, August 19, 2007 @ 2:21 pm

I learned the first secret rule of technical writing in my first week. It floored me.

Content and organization are not the most important thing. Presentation is the most important thing.

Why?

Your readers assume you know more about the subject than you do right at the beginning! They need to be able to decode it and make the information their own as quickly as possible.

The first way of making it accessible is to make sure everything's properly and consistently spelled. You can't rely on spell check. Only 'Romantic' will show as an error in an unmodified spell checker:

And Honestly, what Is on the Rise that is taking the Reading world by storm, are these Romantic thug Books about the Boyfriend that lives the life of Crime and the girlfriend that is trying to deal with It. Or The Cheating man etc.

-My First Day

Here are the rules:

1. Make sure everything's spelled correctly- have at least one other set of eyes go over it before presenting it.

2. Keep the grammar gaffs to a minimum- if use a reader's pet grammar or word error, s/he will look much more closely at your work. Things that set me off include:

  • 'entitled' for ''titled' (a book or CD isn't entitled to anything).
  • Using a plural pronoun for a group (such as The City Council.... they voted against it, it should be it voted).
  • Your for You're (jeez people!)
  • Hidding behind or pompusly using big words- it's start- not initialize; it's end- not terminate; You know what the definition of orientate is? To orient; defer action means wait. Any writer has a bunch of favorites- just ask. 

3. Use color when it makes sense. Always use color if part of your audience includes executives. One time a little inconsequential bar graph using three colors saved one of my projects. Go figure.

4. Use graphics when it makes sense and when it aids in understanding. If the graphic doesn't speak for itself, don't use it.

5. In print- make sure you use the paper-wasting one inch margins and stick them. I know. It is stupid. I can't tell you how manyt times the word 'dense' came up with a moved it down to half inch margins. 

6. If you don't have a graphics designer:

  • Follow the old newspaper typology rule- make the header font san serif and the body serif or vice versa.
  • Use the serif font for captions in 8 point or less. 
  • Use the san serif for table headers in bold. 
  • Don't ever use more than two fonts- and be conservative in your selection. Times New Roman and Arial (Helvetica) are my friends in print. I go a little crazy and use Verdana is on-line publications when I have a choice.

7. Always use a title page.

8. Make sure the title page has all of the logos of companys involved.

    Powered by ScribeFire.

    tech development Tech Development

    About Pathfinder

    • We design and build extraordinary applications for companies looking to make the next great idea a reality.
    • learn more

    Topics