- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Microsoft to Jump on Board EC2
Hold on to your hats; Microsoft has just made a radical change in business model. A couple of months ago I wrote about the competitive advantage that firms using Linux and Amazon's EC2 cloud computing had over their competitors.
Server-on-demand providers like Amazon's EC2, Joyent,
and others have reduced the capital necessary to launch scalable,
server intensive businesses. Google has just launched a similar
on-demand service, and companies like RightScale and CohesiveFT are building mature businesses around managing EC2 configurations....
Facebook applications are just the most extreme example of business initiatives that can be scaled on demand from $70/month on one EC2 server to $10,000/month on many dozens of servers running web, application and database server clusters and farms. Compare that with the old school of investing in a large data center with a significant fraction of the hardware and bandwidth that you might need if your business is a success. What used to cost $100k in capital can now be done with just a few hundreds of dollars.
...
And it's all possible as long as you are using a unix variant - Linux for the most part - to power your apps. So there is a whole class of companies out there using Linux that can out compete their Windows-using rivals - again, the capital they need to launch is much smaller because of cloud computing. That means Linux will win among the class of young entrepreneurial businesses that are so vital to the US economy.
Ajax on Way Out? Slide Down Hype Curve Exaggerated
Aidan Henry over at MappingTheWeb asks whether Ajax is on the way out. Aside from observing that the "frenzy ways of web 2.0 are over," he opines that:
My quarrel lies in the fact that many web designers and developers choose to overuse this technology to the point of stupidity. It is meant to simplify the experience, not complicate it. Using AJAX for the sake of using AJAX isn’t valid reasoning. Some sites incorporate it in an elegant, intuitive way, while others saturate the experience with an absurd amount of on-page activity. A threshold needs to be established based on user intentions.
Yes, the froth may be off the Web 2.0 bubble because of the economy (venture-backed firms take their value from IPO's and acquisitions, which slow tremendously in a recession), but Web 2.0 entrants into the marketplace are here to stay, and O'Reilly's Web 2.0 principles have been vetted by the marketplace.
Topics: Editorial, Rich Interactions
Agile Business, Microsoft and the Threat of Cloud Computing
Competition is the keen cutting edge of business, always shaving away at costs.
-- Henry Ford
I've been working with Java and Microsoft technologies -- .NET most recently -- in one form or another for quite some time. My company, now headquartered in Chicago with an office in NYC, was actually founded in Seattle by a group of four developers that had met around developing an Exchange-based bulk email system to replace the sendmail-based ones that Microsoft was using at the time. In that span, despite all of the food fights about total cost of ownership (TCO), etc., I haven't seen any evidence that Linux, Windows, Mac, Java, .NET, etc., puts you at a significant business advantage one way or the other. Until now.
Topics: Agile Development, Analysis, Editorial, Open Source
Another Brain Fart on Why Open Source is Bad
Every so often, someone scrawls a manifesto about why closed source is good and open source is bad. Usually the parties involved are technical ignoramuses (like in this Economist article) or industry hatchet men. But Jaron Lanier should know better. He isn't a hatchet man and is far from a technical ignoramus, yet he engages in the same sort of sloppy thinking that characterizes those other brain-stain graffiti artists.
His article for Discover Magazine, entitled Long Live Closed-Source Software!, is a case study in bad examples in the service of a simple argument. His argument goes as follows:
- Open Source == Linux
- Linux is a derivative if qualitatively better version of the closed-source UNIX.
- Therefore the open source movement can only produce derivative works, and nothing as breathtakingly revolutionary as the iPhone.
He goes on to speculate about some of the causes for this failing, likening closed source to cell walls that help organisms differentiate and speciate. Open source, by contrast, is like the primordial goo.
Topics: Editorial, Open Source
Ajax and Browsers: Recapitulating the Early Days of Personal Computers
I guess its my turn to spin out historical analogies. Does anyone remember GEOS? That's right, a GUI OS for the Commodore 64. In those early days, everyone rolled their own GUI (character mode windowing...yum). Some were good, some were bad, some were downright ugly. GEOS was an attempt to bring the unifying influence of an OS that provided the basics of a GUI to the C64, something that Windows brought to the PC and the Mac OS brought from the beginning to the Macintosh. GEOS and the C64 faded away, but the days of the custom crafted GUI were numbered. All that stuff is and should be baked into the OS.
We're in a very similar situation when it comes to the browser and Ajax/Widget libraries and frameworks. Everyone is rolling their own widgets, developing their own DOM and Ajax utility libraries and frameworks. I think the next step should be obvious. Bake an Ajax library into the browser. Can you imagine having Ext already present and available in your JavaScript runtime? Imagine the boon this would be to standardization, code reuse, etc.?
Topics: Ajax Development, Editorial, GWT, Trends, Volta
Humor: Bubble Video
An amusing little video on the Web 2.0 bubble.
Eating Some Crow on ThinWire
OK, so I was wrong in ThinWire. The issues around having to position and size components is obviated through the existence of two layout managers -- SplitLayout and TableLayout. These layout managers calculate size and positioning for you (and override any values you may have explicitly set). They certainly make developing in ThinWire much less tedious than I previously thought. For an excerpt of the ThinWire handbook that discusses the two layout managers, see here.
For more sophisticated or fine grained layouts, you'll likely want to develop your own layout managers. I'll officially remove ThinWire from my list of 2007 Ajax Turkeys.
Technorati Tags: ajax, thinwire
Topics: Ajax Frameworks, Editorial
Ajax Turkeys for 2007
Every American school child has heard vague rumors that Ben Franklin once suggested that the Turkey would make a better national symbol than the Bald Eagle. What they haven't heard, of course, is that the Turkey is "though a little vain and silly, a Bird of Courage," compared to the Bald Eagle which was "a Bird of bad moral Character." I wouldn't put too much stock in old Ben's suggestions, though. After all, he once proposed that the Rattlesnake was the most appropriate symbol of America's temper and conduct.
So in the end it is still appropriate to use the Turkey as a symbol of failure or incompetence. So, without further ado, my Ajax Turkeys for 2007:
- GMail 2.0 - this puppy should be put back in the shed. It fries browsers from coast to coast. If there was ever and argument against the bloated Ajax beast, this is it.
- ECMAScript 4 - the bastard child of JavaScript, Java and Ruby, this beast tries to please everyone and instead falls between the chairs. If you want the advantages of both dynamically and statically-typed programming languages, make sure the browser can run more than one language (VM and compilers, anyone?).
- Thinwire - any framework that makes you specify position and calculate height and width of every widget is a productivity killer. Update: I was wrong on ThinWire. The Layout Managers simplify this. Mea culpa, mea maxima culpa.
- The Book of JavaScript, Second Edition - I didn't have the heart to review this one when it came out. Thau was "the man" back in the 90's when it came to JavaScript. If you wanted to validate a form or set a radio button, Thau's tutorial's were your first stop when it came to learning the ropes. Well, it's 2007, and if you want to learn how to validate a form or set a radio button, you've come to the right place. As far as OO JavaScript, DHTML and XHR? Sorry. The state of the art has passed him by.
- GWT wrappers for Rialto - if you and your widgets are going to jump on a bandwagon, make sure you get it right. These widget wrappers didn't subclass Widget. Please fix.
- Vista - nuff said. (OK, IE7 and Vista.)
- Framework fanatics - don't get me wrong, I love the frameworks, but the JQuery and Mootools fans can really get on your nerves. They remind me of Ron Paul supporters (also known as "Paulbots") -- someone mentions Ron Paul and immediately the post gets 500 "Ron Paul is great" comments.
Well, that wasn't so bad. I'm sure everyone has their favorites or may in fact disagree with some of my gobblers. Who made your Turkey list?
Technorati Tags: ajax, editorial
Topics: Editorial
Ajax, Browsers, Running Out of Time
History repeats itself, first as tragedy, second as farce. -- Karl Marx
I can remember the day, back in 1994, when I abandoned the Mac for Windows. It was a gloomy, overcast day when I made that bittersweet decision -- I was a Mac and Unix nerd all through college -- but after my twelfth or thirteenth crash of the day, I had had enough. Photoshop, Netscape, Secure Shell and Word were just not meant to run more than one at a time on Mac OS 7. Had I stayed with Apple through that rough patch I'm sure I would have been slimmer, sexier and happier, but NT 3.51 only crashed twice a day, so my hand was forced. I ran out and bought a PC that very day.
Now I fear history may be repeating itself. Yesterday, I had Firefox 2 for linux crash 5 times, and IE7 for XP crash 7 times. The cause? Too many fat Ajax applications. Zimbra, the whole Google bestiary of applications, Yahoo Mail, etc.. These are all long running applications that I keep open for most of the day. Then all of a sudden the Browser is gone and I have to relaunch and login all over again.
I'm not alone in this. Colleagues and friends report similar problems with Safari/Mac, IE7/Vista, Firefox/Mac. I've even checked with a friend that runs the helpdesk for a large firm: reported problems with browsers are up. The only one who seems blissfully unaffected is the lone Opera nerd in my office. He just keeps chugging along with what seem like 200 open tabs.
The cause should be evident to everyone. We've taken what was first called LiveScript -- a crufty embedding just good enough to validate a form or two -- and we've abused it into being the foundation for a whole new kind of application platform. The browsers have just not kept up and the situation will only get worse with the accelerated proliferation of Web 2.0 apps.
Help is on the way, in the form of bytecode interpreters and vm's for Safari and Mozilla, though the future of IE is still cloudy (still, there is a plan to bring Tamarin to IE). But if the new Browser version don't arrive quickly enough, or if they don't fully solve the problem of browsers crashing once an hour, then a mass migration to Opera may be the best we can hope for. At worst, content and application producers will opt for more stable non-Ajax alternatives such as Flash or Silverlight.
Ajax and the browsers it depends on are running out of time. If the notion spreads that it isn't reliable, it will be as dead as the Java Applet, never to be heard from again.
Topics: Ajax Applications, Browsers, Editorial, Firefox, IE, IE6, IE7, Javascript
The Importance of Pair Programming
It turns out I've been following agile principles for longer than I realized. Back in the early 90's, I was living in a grad student coop at the University of Chicago. The house manager -- a 50-year-old physics Ph.D. who handled all of the plumbing, electrical and other assorted house maintenance -- had decided to leave. In a house populated with humanists and social scientists, all eyes turned to me, the lone "scientist." I didn't bother telling them that computer "science" isn't really a science, and to top it all off, I was studying mathematical comp. sci., which meant I was a fair hand at Combinatorics, but I couldn't tell the business end of a soldering iron from a ground wire. Still, I had helped my dad install some drywall back when I was in junior high (mostly I held the drywall in place, while my dad did all the work), so I agreed to be the new house manager.
I set two conditions, however. First, I was not going to live in the house until I was 50, and second, we would have two house managers, whose terms would overlap by 6 months. An early form of pairing. As a result, I and my pair house manager did not feel as overwhelmed as we might have if each of us had been on our own. Further, we shared information, documented it and now, over 15 years after I introduced pair house managing, the coop still uses the practice to good effect.
I know I have mentioned my 4 commandments of Agile development: iterative development; pair programming; test driven development; continuous improvement. It is hard to point to a "most important" one of the commandments -- as far as I'm concerned this is really the bare minimum of what is necessary to practice good agile development -- but pair programming seems to be the one that is most often left on the cutting room floor. The excuses are endless: "we don't have enough people," "we have an odd number of developers," "we have too many tasks to pair." The list goes on and on. For anyone that has practiced pair programming, the only objection that holds water is the "odd number" one. It is hard to pair with 3 developers, and rotating pairs or three-somes don't work so well -- someone is always the odd man out. 
So what does pair programming give you and why and how does it work? In their hilarious article All I really need to know about pair programming I learned in kindergarten (May 2000, Communications of the ACM, Volume 43 Issue 5), Laurie Williams and Robert Kessler describe some of the reasons for its success. First, in a survey of developers they found that overwhelming majorities of developers were more confident of their solutions and enjoyed their jobs more. Happier programmers produced better solutions, no surprise there. But the fact that stereotypically introverted developers would enjoy a more social, collaborative work environment seems counterintuitive.
According to the article, another key benefit of pair programming is the constant code review that it provides. As it turns out, developers working in pairs think of twice as many solutions and work more than twice as fast as two developers on their own. Anyone who has seen the parabola of bug fix expense in action, i.e. bugs are much more expensive to fix the further you get toward deployment, will appreciate how valuable this constant code review is.
The article goes on to describe some best practices for pair programming, couched in kindergarten term -- "share everything," "clean up your mess," "play fair," "don't hit people." One principle that I adhere to, and that the article mentions, is that it is permissible to work alone for up to 50% of the time -- "nap time." I'm not really an advocate of the "one monitor, keyboard and mouse approach," but rather prefer the shared desk model. That way you can collaborate, but are not exhausted by the constant engagement that the shared terminal forces on you.
One additional benefits of pair programming that I've observed is that developers reach their potential more quickly, i.e. they move from junior to senior to architects or leads more quickly. They learn from others (got to keep switching the pairs from iteration to iteration), they get to make decisions on design and architecture instead of taking dictation from a tech lead, and they feel empowered. No wonder they progress and learn more quickly than developers working along.
Back in the mid to late 90's when I first tried to introduce agile methods on Wall Street, pair programming was the practice that garnered the most pushback. I usually convinced skeptical managers by convincing them that developers would spend less time surfing the web. They nodded knowingly and agreed to give it a try. I got my way, but for the wrong reasons -- managers didn't trust their developers. That points out another agile principle that fits hand in glove with pair programming: trust your people. Or, as the Agile Manifesto puts it
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
These days, I have a much easier time of selling pair programming to clients, which is all to the good.
Technorati Tags: agile, pair programming
Topics: Agile Development, Best Practices, Editorial
Joel Spolsky and the Perils of Reasoning by Historical Analogy
Reasoning by historical analogy can be dangerous, especially if such reasoning is untempered by recognition that no two historical events are identical and that the future is more than a linear extension of the past. The instructiveness of historical events tends to diminish the greater their distance in time and space from the day and place they occurred.
-- PERILS OF REASONING BY HISTORICAL ANALOGY: MUNICH, VIETNAM, AND AMERICAN USE OF FORCE SINCE 1945 by Jeffrey Record
It may seem a little hyperbolic to quote from a paper published by the Air War College in advance of a critique of Joel Spolsky's latest strategy letter, but lessons about historical reasoning can apply just as well when the question is the future of software as it does when the question is war and peace. So, how exactly did Joel screw up in his analysis of the future of Ajax? Well, first to what he got right:
- He got the bit about the Forms-based interfacre (Green Screen, etc.) right. Web 1.0 was like the mainframe apps, Web 2.0 is like the desktop GUI. Welcome to the club, Joel, over a year and a half later.
- Large JavaScript apps will download faster over bigger pipes (or "tubes" or "trucks") and run faster in newer browsers with better JavaScript runtimes. So nobody cares about the 3k do everything library anymore, just like features are more important that memory footprint and performance in Desktop UI's. Again, welcome to the club.
- The portable programming language is not likely to be Javascript in the long run. Think VM, like Tamarin or Silverlight. The same developments that make JavaScript run faster in the browser will ultimately make it irrelevant.
So where did Joel go wrong?
- For one, he confuses the categories of Hardware Platforms, Operating Systems, UI Toolkits and Application Software. Anyone remember the RogueWave GUI libraries, circa 1994, or Think's Lightspeed C for the Mac from way back when? Where are they now? (RogueWave is still around, as is Symantec which acquired Think C, but you wouldn't exactly say they were the "winners" when it came to GUI SDK's.)
- What are the applications, the 1-2-3's of the web age? Well, everyone who publishes a web site is an ISV. Some make very basic use of the platform's (browser's) features. Some who publish full on webapps make fairly sophisticated use of them. As a group they have more leverage over the OS/Browser than Lotus 1-2-3 and company ever had. That's why IE can't make crazy extensions W3C standards, just incremental ones.
- Compilers and languages have come a long way since C showed the way. The norm now is for runtimes to support multiple languages with a common API (see .NET, etc.). So no "single" language will need to be invented.
- NewSDK looks a lot like GWT. Sorry, Joel, Google isn't snoozing. They may still get overtaken, but your narrative is a little off the mark.
What is the hardware, the OS, the GUI SDK and the Application? You could take the naive approach and say that Intel is still the hardware, Windows XP/Vista is the OS, but that doesn't quite square with how I see things. I think that the browser is the OS, DOM and Javascript are the GUI foundation library, and Dojo, Ext JS, etc. are the RogueWave and ThinkC SDK's of the Ajax age. As the OS/GUI library changes (new features/standards in the browser, etc.), so these SDK's will have to scramble to keep up. They will be influential, but eventually more and more of core GUI functionality will make its way into the browser. The browser calls the tune, everyone else just dances along.
Technorati Tags: ajax, spolsky
Topics: Ajax Development, Editorial, GWT
Desktop Applications Dying, Dying…
My post the other day on the death of desktop applications got me a large volume of hate mail. I was alternately an ignoramus or a hater. One common refrain was that Web UI's still sucked and would never replace Desktop apps in terms of the user experience (OK, it was usually not phrased so elegantly). I guess many readers missed my point. My point was that it rarely makes sense to develop a pure Desktop app anymore, not that everything should be a webapp. Why is that?
- In many cases and for many uses, Web UI's are as good as Desktop UI's. Look at all of the Ajax photoshop knockoffs (here and here), the various word processor or spreadsheet apps, and the direct manipulation interfaces such as Yahoo Pipes.
- The choice is no longer between the Desktop app and the Webapp, but between just doing a webapp or using something like Adobe AIR or Google Gears to do a Desktop RIA and a webapp at the same time.
- As the capabilities of browsers increase, with faster and more efficient Javascript engines, offline features, etc., and the maturity of Ajax frameworks evolve, the reasons for writing Desktop RIA's that can also work as webapps become more compelling.
Those that persist in yammering about how kludgey webapps are live in the distant past, confusing the Green Screen nature of the pre-Ajax (as I observed here in 2006, and Joel Spolsky did here over a year and a half later -- more on what Joel got right and wrong in a later post) with the current ability to develop Component GUI applications just like those Desktop apps.
My point remains unchanged: spending significant resources to develop a purely desktop app only makes sense in specific circumstances, and unless you have tons of money to write your own network integration systems, you are best off using the already available Desktop RIA frameworks.
Technorati Tags: ajax, desktop RIA
An Event Apart: Wrap-Up
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.
An Event Apart Chicago: Day 2
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
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.
Bubble 2.0?
The sky is falling! Every publication has to have it's resident curmudgeon. It's a franchise, and PC Magazine's is held down by John Dvorak. Now he's moaning about a dot-com bubble redux involving Web 2.0 based companies.
Each of these bubbles had a distinctive theme. For the dot-com bubble, it was e-commerce—it really should have been called the e-commerce bubble. Everything was focused on how the Internet was going to destroy all existing brick-and-mortar operations. We were told that you'd be buying sandwiches over the Internet and having them delivered the next day by FedEx. Everything was about "eyeballs" and finding ways to attract customers, whether they bought anything or not. Every article in every newspaper in the country parroted the litany as to how you'd be out of business in a year or two if you were not present on the Web in a big way. Of course, this was all crap.
The current bubble, already called Bubble 2.0 to mock the Web 2.0 moniker, is harder to pin down insofar as a primary destructive theme is concerned.
He goes on to scoff at the various concepts that are in vogue in the Web 2.0 space, all of which could come tumbling down in a crash.
- Neo-social networking
- Video mania
- User-generated content
- Mobile everything
- Ad-leveraged search
- Widgets and toolbars
An economic bubble is defined as “trade in high volumes at prices that are considerably at variance from intrinsic values”. Is that really where we are? I don't see all that many "me too" or momentum investments in Web 2.0 companies -- just a $10 million investment here or there by some VC's. Facebook has a large valuation because they actually generate lots of advertising income (shoot, 1% of all online time is spent on Facebook), and online advertising it here to stay.
Most of the Ajax/Web 2.0 activity I see right now is existing companies retooling their online presence to take advantage of some of the new technologies and ideas.
Sorry Dvorak, no bubble here yet.
About Pathfinder
Recent
- Bandwidth profiling Flex projects and more with Charles
- iPhone SDK: UIViewController Testing & TDD
- Icons are evil; so are menus - unless you do them right
- The Truth About Designing For Security
- GWT, Gadgets and OpenSocial, Part 2
- Has Many has_many: A Refactoring Story
- The Hidden Power of Canvas
- Review of fixture_replacement2 plugin
- Chess Game Viewer in GWT
- From JSP to Ruby on Rails: First thoughts on front-end coding conventions
Archives
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Topics
.NET
2d physics
3d
3D GPS
3D physics
37signals
Accessibility
actionscript
activerecord
acts_as_ferret
Add new tag
Adium
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Amazon
amf
Analysis
Android
Announcement
Announcements
antennae
Apollo
apple
Application Architecture
Application Development
architecture
AS3
ASP.NET
Asynchronous Processing
awards
Azure
Back Button
bandwidth
bandwidth profiling
Benchmarking
Best Practices
BitmapData.draw
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business
Business Reasons for Ajax
Business Rules
C#
caching
Canvas
Case Studies
Charles
chess
Chesspresso
Chicago
Cloud Computing
CMS
COBOL
code
code art
Code Generation
Color
COMET
Conference
Confluence
Consistency
Content Management
CRM
CruiseControl
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
design thinking
Desktop
Desktop RIA
Developer's Notebook
DHTML
Diagnose
Dojo
Domain Knowledge
Drools
EC2
Echo2
Echo3
Editorial
ERP
Ethnographic Research
events
externalinterface
Ext JS
Facebook
ferret
FileReference
Firefox
Firefox Extensions
fixtures
Flash
flash awards
flash player
flash player 10
Flex
flex css
flex skins
flexunit
Flickr
Flock
Flow
Frameworks
FriendFeed
front end
front end development
fulltext search
Games
Gauge Component
getting things done
Git
Google
Google calendar
Google Gadgets
Google Gears
g phone
Grails
Graphics
Greasemonkey
Groovy
GStreamer
GTD
Gwittir
GWT
hardware
Healthcare
Hibernate
HTML
Hudson
IDE
Ideation
IE
IE6
IE7
IE8
iGoogle
illustrator cs3
ILOG JRules
importing graphics to flex
Information Architecture
Innovation
Instructional Design
Interaction Design
interaction patterns design
Interview
iPhone
iPod
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSP
JSR-94
JsUnit
laptop
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
logging
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
Meebo
MetaWidget
Methodology
Microformats
Microsoft
minimalism
Mobile
Mootools
mouse
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
NetNewsWire
notebook
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
OpenSocial
Open Source
Opera
Oracle
ORM
osx
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PGN
PHP
physics
physics engines
plugin
preloader
process
Web/Tech
Product Definition
productivity
Progressive Enhancement
project management
Project Website
Prototype
Prototyping
PV3D
QA
qooxdoo
Radiant CMS
rails
Really Simple History
References
Requirements
Requirements
Alice Toth
Requirements Visualization
resesign
Restlet
RETE
Review
ria
Rich Interactions
ruby
rubyamf
Ruby on Rails
Ruby on Rails testing role
S3
SaaS
Safari
San Francisco
Scalability
Scenarios
Scriptaculous
SDLC
Search
Security
Selenium
Semantic web
SEO
Server Side
Silverlight
skins
SOA
Social Networking
Software Processes
Songbird
SpiderMonkey
Sprajax
Spreadsheets
Standards
Startups
STI
Story Telling