Discussions at work about Steve Job’s recently published thoughts on flash brought up an interesting question: is Jobs trying to tell us that there is no point in making Web sites any more, and that we should all be building apps for iPhone™? And… is he right?

Yes, and No.

The Web as an information ecosystem is not in danger.

Web technologies are not in danger. On the contrary: said Steve, in his thoughts about flash, raves about the open technologies built at W3C, like HTML5 or CSS. [for more on this, see my previous post about the iphone developer agreement.]

On the other hand, the paradigm of the web “site” as a space you travel to is, I believe, moribund. It is a major shift that finds its origin, among other things, in the development of mobiles.

Before the emergence of the mobile internet devices (laptops, smartphones, netbooks, tablets and so on) our perception was that the computer was transporting us (nay – teleporting?) to the internets. Hence the metaphor and the semantics used: site, navigator, compass, “go to Yahoo”. Said metaphor also spawned the first generations of virtual reality; said metaphor was acutely present in portals/platforms such as geocities, where all the sites were organised in virtual cities and neighbourhoods.

Photo (cc) mjmalone on flickr

With the arrival of wi-fi and reliable connectivity on cellular phone networks, the thinking is reversed. We are always mobile, always going somewhere, and the Web is following us around. And since the Web and its information ecosystem is always available, we are getting used to responding to immediate needs: here, and now.

Hence the emergence of a new metaphor and a new economy around it.

Exit Geocities (RIP, indeed, 1994 – 2009), exit the “web site”. Enter ubiquitous services, aimed at solving a particular problem or serving a particular need. Right now, this new metaphor is best served by proprietary apps and web widgets, but the shape of these services may change. The future will tell us if Apple (or someone else) wins the dominance game, or if the fragmentation in the “app stores” market will kill that model, as people such as PPK seem to believe.

My bet, regardless, is that the “paradigm shift” (buzzword alert!) from the web sites to the ubiquitous web services, is durable.

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Among cries of anger, especially from people who were looking forward to developing using Flash technology and porting to Apple’s devices using Adobe’s upcoming Unity tool, a few heavyweights such as John Gruber and Jean-Louis Gassé both chime in, claiming it is a strategic move by Apple to control the developer ecosystem.

This from JL Gassé:

Cross-platform tools dangle the old “write once, run everywhere” promise. But, by being cross-platform, they don’t use, they erase “uncommon” features. To Apple, this is anathema as it wants apps developers to use, to promote its differentiation. It’s that simple. Losing differentiation is death by low margins. It’s that simple. It’s business. Apple is right to keep control of its platform’s future.

I would almost agree with this, except that the following statement in the agreement-to-be makes Gassé’s point moot:

or JavaScript as executed by the iPhone OS WebKit engine

HTML5 and the javascript APIs, which the new apple developer agreement specifically approve of, is precisely the epitome of “write once build anywhere”:

1. HTML5 is an open standard
2. the javascript API giving Webkit access to device’s innards are being standardised at W3C, too
3. Webkit, the engine behind apple’s web capability, is open source, and widespread amongst most mobile platforms, including Google-driven Android phones… just one of the major competing platforms in the mobile market!

Is Apple really trying to stop developers following the lure of “write once, build anywhere”? Given how Android is gnawing at Apple’s share of several markets (especially in North America), and given how Apple and Google haven’t been particularly friendly of late, you’d think Apple would try to block developers from easily building for iPhone AND Android – something HTML5+JS does beautifully.

And yet, Apple is not only allowing apps to be built with HTML5+Javascript, they are actually promoting the use of these development technologies for their new iAds platform.

Two possibilities:

1. Apple’s strategy is not really to control the developers’ ecosystem. The point of the new terms for developers is, and only is, to give Adobe the finger. Childish and silly. I don’t believe that’s the case.
2. There are competing groups at apple, fighting for dominance. The Web geeks are scoring points with their “html5 everywhere” strategy of having the best implementation of open standards and bringing in the huge, creative mass of Web developers. On the other hand, the software geeks are trying hard to limit who can build applications for the iphone os devices: mac developers, and only mac developers. Old hands knowing the Apple HIG by heart, and early converts.

If my hunch is right, the second hypothesis is the right one, and the internal fight at Apple may turn nasty when the executives realize that the strategies of these two groups are completely at odds.

The real fight being fought is not one between Apple and Adobe. It is – within Apple’s ranks – between the Web and Software crowds.

(You know who I will root for).

mashed cauliflower, a photo by olgucz on flickr

Mashups were all the rage but a few years ago! Every Web developer and her dog were creating a “mashup application” – most often a few layers of points of interest applied onto google’s great map APIs. In that sense, it is true that a lot of the current applications of MAR are a new spawn of the mashup hype.

Fast forward a few years, and the world mashup is hardly ever uttered – or at least, very seldom without a hint of sarcasm. Most of those “mashup” applications have died, and google did a very smart move by not only allowing everyone to layer information over their maps – they actually let everyone integrate the rich maps and data on anyone’s web site.

Mashups are dead, but their progeny inherited a lot of the contemporary web landscape: only because of the mashup hype and the experimentation it prompted do we routinely think of the web not just as a collection of page, but as a large set of linked data that can be packed together into rich, cohesive units of information. Many of the “useful” tricks of the day, be it facebook connect, feed aggregation or the new portals (hah!) owe their existence to the stickiness of the mashup buzzword.

And now, for something completely different: my secret for a great veggie mash is a bit of butter, a dash of olive oils and a sprinkle of australian herb salt. That or a red wine stew sauce, actually…

A few weeks ago, Apple, a leader in sales of mobile devices, apparently started contacting selected developers with one message: stop assuming that you are building applications for 320x480px screens.

Score one for flexible design.

So, how can one create applications that would feel and work great in the current fragmented market of web devices? I’ve had, for a long time now, a hunch that web standard technologies such as HTML and CSS had the answer. HTML and CSS were made to meet this challenge, to build interfaces that scale, to cascade differently according to the media. The new CSS3 Media Queries pushes this capability quite far already, and I have been looking forward to experimenting more with it.

I was surprised, however, by a very interesting new trend: HTML+CSS+JS are being used not as the final UI layer for web applications, but instead as a programming language to be compiled into other languages (such as objectiveC, Java etc.) and the deployed, with native UI look and feel, onto a variety of devices.

This is the strategy currently followed by Nitobi’s PhoneGap and Appcelerator’s Titanium, both of which allow development using the basic Web technologies and JavaScript API, and package the result into “native apps” for iPhone, Android (and blackberry).

This could be a very exciting development for web standards as base layers for everything on the web… including applications that have very little to do with the Web paradigm. And for designers and developers, this could be the solution to the conundrum of flexible design and multi-platform development.

Score two for flexible design.

Any good reading you would recommend in this area?

The past months have seen me navigating in many ends of the Web spectrum, from the academic to the commercial, from the purely technical to community or business facets. Each time I have been considered an expert, a senior, a veteran. Which, as far as the Web is concerned, I am. I also happen to be in my early thirties…

Yesterday I realised how humbling it is to meet people with decades of experience in their field. We the websmiths too often forget that being a senior after 3 years and a veteran after 10 years is an anomaly. Let us never forget how young the Web is.

Bixi is the new community bike service here in Montreal. Lots of brewhaha around launchtime, but to me, the really annoying shortcoming of the system so far was not being able to check the status of stations on the go.

According to a message I read on the facebook group for bixi a few weeks ago, there is “no plan to provide an API, iphone app or mobile access to the map of bixi stations”. That’s rather silly, knowing that the users will want to know, in real time and on the go, whether they can get or return a bike nearby.

I’m too lazy to build a real iphone app over the week-end, but I wanted to prove that it doesn’t cost tens of thousands of dollars to provide bixi users mobile access to the status of the stations.

30 minutes and about as many lines of python later, I had a working hack to include a map of all stations in google earth, google maps or the map application on my iphone.

iPhone Instructions

Here’s how to use it on the iphone (or networked iPod Touch):

Disclaimer: I built this using only publicly available data – not a public, official API, though. If the powers-that-be at bixi decide they don’t like it, or change the way they organise their data, or any other silly move, I’ll have to pull the plug on this little hack. In the meantime, I intend to use it and provide it for free. Enjoy.

There does not seem to be a lot of existing resources or information on the Web about this role. “Web developer”, “Project manager” or “Software architect” all have their wikipedia entry. Search for “Web architect” in wikipedia and you will currently be redirected to a page on Web design. Wrong, wrong, wrong… There is indeed a page for Website architecture, but it still needs work.

In the Web industry, the “architect” title has long been hogged by Information Architects, and the Web Architect is generally called “Tech Lead”. That name is problematic, however, because it implies that the lead has evident authority on the development team, when the reality is often one of much responsibility, little authority: the tech lead seldom has authority by virtue of being a manager, but gains authority through the building of trust and effective mentoring.

The good news is that the Info Arch world is reinventing itself as “User Experience”. This is an opportunity for web architects to reclaim a title that makes more sense: architecture is about knowledge of complex systems, design and technology, and nurturing a project from beginning to end.

Still, the fact is there aren’t a lot of good resources yet on the Web explaining the work we do. I decided to collect a list of resources for Web Architects, mostly for my own consumption, but if it benefits others, even better!

Know the Job

In a nutshell, my understanding of the job goes:

• Provide technical vision at every stage of the project, from feasibility to delivery.
• Build specifications and/or prototypes. Do it with a team, not alone.
• Participate in development and own responsibility of architectural consistency, quality, documentation, code reviews, testing.
• Know the methodologies and development processes and frameworks. Get teams to use the right ones for the right projects.
• Develop and maintain expertise in the team through research, exchange
• Communicate, communicate, communicate. Be a bridge between people who don’t speak the same language but need to work together.

One of the fairly good resources giving generic advice on being a Web architect / Tech lead is a tutorial by Daniel Pietraru called 36 steps to success as technical lead.

I don’t fully agree with all of them, but they all carry some wisdom if understood and applied well. Number 27 (Be sure you have authority along with responsibility) is a good summary of the Architect’s odd position, of responsibility but not always authority – the latter is earned, not given.

Number 7, too (Get your hands dirty and code) can be a great way to keep one’s skills sharp, earn some respect from other developers and help deliver projects on time, but they can also drag and confine you in a role that isn’t yours. An architect is not a developer – and there are responsibilities in the architect’s job that require a creative mindset.

There must be quite a few experienced tech leads/architects out there with worthy experience to share. Jeremy Miller has a good article on the Classic Technical Lead Blunder. I’m on the lookout for more.

Learn the Tech

Regardless of how much hands-on the architect role has on a given project, the need to know the stuff can not be underestimated. This doesn’t mean you have to know everything – it’s healthy to not know, even healthier to know when to ask, and know when to do your homework.

1. Spend time on the W3C’s Web site. No, really. Keep an eye on “best practices” on Accessibility, Internationalisation, mobile Web and of course Web Architecture.
2. Can one be an expert in every possible programming language? Probably not, but worth a try. On the Web today, you probably won’t be able to survive without php. Do keep an eye on python (the Python: Visual QuickStart and Beginning Python from APress come highly recommended, and I love Doug Hellmann’s python module of the week), django, Ruby on Rails…

Learn to think like your team mates

One of the most exciting parts of the job is that the architect works with almost everyone involved in a web project. This means we need to speak their language. We need to speak marketing and strategy when assessing the project, we need to speak project management with the PMs, we need to speak design with designers, UX with UX, speak code with developers, speak test with QA. Here are a few books and resources that help become polyglot in no time:

1. Read Boxes and Arrows on a regular basis, and infuse the vocabulary and mindset of User Experience. I also like infosthetics and GUUUI. Read Jakob Nielsen too – if you must.
2. A good architect needs to know about the different frameworks and methodologies for web project management. I found Mike Cohn’s Agile Estimating and Planning to be the best book on agile project management, period. Real Web Project Management is not bad, either, although obviously made for a more novice audience.

Know the process. Know when not to follow the process

One risk, as an architect, is to be dogmatic about architectural or process changes. We all have a favorite way of running a project or building an architecture, but not all projects would be better off as scrum, and not all development benefits from test-driven development. That said, one first has to know the tools, know them well, before knowing when not to use them.

Specifications: joelonsoftware has a piece on “Why bother with Functional Specifications”?

Tech specs, however, I remain conflicted about. Most of the time, the technical specification is a long, painful document that nobody will bother reading. Several agree, calling for the death of the web technical spec, but others still see value in it.

In my first weeks on the new job the most important problem I identified was that the team created specs that nobody could really use. We’re in the process of improving our specs with the help of User Stories. User stories are often seen only as a tool for agile teams to evaluate work, but even in non-agile environments, they provide a clear checklist that can be used by everyone: the client can validate a real list of scenarios, the project manager can keep track of work done and remaining, developers can reuse the User Stories within a test-driven or behavior-driven development method.

Test early, test often. A good way to release software with fewer bugs and a quicker path to fix issues is to apply some level of Test-Driven development (and unit testing), or more recently Behavior-Driven development. For the architect the work of bringing TDD/BDD to a team will be as much technical as human, so you may want to read articles like this one and learn how to sell, and how not to sell, TDD to your team.

Tool-wise, look into rspec for ruby, junit for java and unittest for python. For php I quite liked the SimpleTest library.

Productive Tools

Doing this job well implies being good at managing people, knowledge, code and time. Patience and soft skills are the tool of choice for managing people. For the rest, a quick selection would include:

tracking ongoing work and todo lists – Things remains to this day my favourite in this area, though others will swear by iGTD or OmniFocus. If you’re hesitating, know that others have gone through this too, and see which choice they made, and why.

QuickSilver (or other similar launchers if you are not on Mac) can save tons of time on a daily basis. The real time-saver however, is to learn one’s text editor inside and out. I still love TextMate to bits and want to learn more tricks with it… even if my daily routines sees me use spreadsheets and text processors more.

For more suggestions of tools and methods, The Productive Programmer is a very decent read. It did not teach me anything I had no clue about, but it was a good validation of some simple, solid principles every developer, or anyone working closely with developers, should be reminded of on a regular basis.

Keep a sense of humour

Because it won’t be easy every day.

This list of resources will grow over time. If you have any suggestions, or disagreement, the comment box is right here ☟.

The “Renaissance Man” is an archetype personified by the likes of Leonardo Da Vinci: artists, craftsmen, engineers; polymaths, often polyglots. Men of the renaissance were exemplary to the people of our time, we who are often struggling with varied interests and skills in an education and professional context that often rewards extreme specialisation.

I already knew of extraordinary women of the renaissance. Catherine de’ Medici, for instance, was educated, intelligent, rich and powerful beyond the reach of any other man or woman of her time. Yet I would not call her a “Renaissance Woman”, for little of her known history points towards achievements in the arts and science. Undoubtedly Catherine was a patron to the arts and versed in the science of politics, but a worthy counterpart to Leonardo or Gallileo she was not. Neither was Anna Maria van Schurman, Isabel de Castilla or other great women of that age: none of them seem to ever get anywhere near science.

Hypatia as imagined by Raffaello Sanzio

I actually found one of the best examples of a Renaissance Woman in the age which the Renaissance was mimicking and rediscovering. Born around 350 AD, Hypatia of Alexandria was a scholar, philosopher, mathematician, and astronomer. Said to have been instrumental in the development of the hydrometer and the astrolabe, she ran her own school of philosophy, acted as one of the last librarians of Alexandria, and exerted immense political power over the region.

Hypatia’s extraordinary character, knowledge and freedom have inspired many romanticized accounts of her life. According to legend “she moved about freely, driving her own chariot, contrary to the norm for women’s public behavior”, and the Suda, the collected history of Byzantine Greece, tells how she rebuffed a suitor by showing him an unglamorous pile of rags stained during her periods.

It is because of her death, however, that she is still so well known today. Caught in a political feud between the imperial power and rising christianity, she perished at the hands of an angry christian mob in one of the most gruesome deaths since Hector’s fate at the hands of Achilles: dragging her from her carriage, they took her to the church called Caesareum, where they completely stripped her, and then murdered her with tiles.* After tearing her body in pieces, they took her mangled limbs to a place called Cinaron, and there burnt them. (dixit the Ecclesiastical History).

Her death in the midst of political and religious conflict, unfortunately, makes it difficult to know truth from fiction. To Voltaire and the deists of the 18th century, she was the “most beautiful, most vertuous, most learned, and every way accomplish’d lady”, as John Toland wrote. To others, she was “A most Impudent School-Mistress of Alexandria.”

This detour through history provided me an unexpected clue in understanding why the Renaissance had produced so few “Renaissance Women” that we would still know of them today. A biography of Hypatia by John, Bishop of Nikiu, reads: there appeared in Alexandria a female philosopher, a pagan named Hypatia, and she was devoted at all times to magic, astrolabes and instruments of music, and she beguiled many people through (her) Satanic wiles.

The terms used are strangely reminiscent of another age, that of witch hunts. Our collective psyche would generally place those shameful, dark times during the middle age, and I had to double check that my hunch was correct: coincidentally, witch hunts happened during the exact same period as the civilised renaissance, between the 15th and 18th century AD. If Renaissance men dabbling in engineering and alchemy were considered the pinnacle of civilisation while their female equivalents got burnt at the stake, is it surprising that we have no history of smart women of arts and science during that period?

In the past 25 years since the launch of the Free Software Movement, we have made great progress in convincing the world, in particular the business world, that Open Source software could, and should be taken seriously. A lot of the software powering businesses today are the same free software that CXOs would never want to hear about a decade ago, and people like Bruce Perens deserve a lot of credit for that. However, all these years of advocacy have also created a noxious myth of a free lunch: that free software just builds itself through flowery good will and smooth collaborations. And all that without any money involved.

(Image by joanplanas on flickr)

The truth is a little more complex. In my humble observation, the large majority of FLOSS is either a small personal project (the “scratching my own itch type”) with little or no collaboration going on, and all done on a single person’s copious free time, or a larger project with financial backing for development and community management from governments, corporations or other organisations. Large, well organised open-source projects with no-one on the payroll are extremely rare exceptions.

Because of my new status as consultant to W3C, I have to track very closely how much time I spend on each of my projects. Far from being a hassle, this has provided me with fascinating data on how much it actually costs to run those projects.

For example, I recently worked on a new feature for the markup validator, which I believe could have a significant impact on how usable the tool is. For most end-users, the change will be almost invisible, yet making their life easier. I counted how much time I spent on the feature, and when adding up the research, code, discussions (including handling of feedback and ideas from users) and testing, I end up with a gross cost somewhere between 500 and 800 USD. And that is not counting the “donated” time of the people who contributed ideas and feedback. It could have been cheaper, if someone had worked on their free time on a patch, but even then, the community and QA work would likely have been done by people on a payroll.

Friend and ex-W3C colleague Karl Dubost often suggested that I should put a price on each bug and feature that would be submitted by the community. The idea would be that if someone submitted a patch, it would of course get in for free, but if the community cared about getting the bug fixed or new feature in without the wait, then everyone interested would chip in.

Maybe he was up to something.

Using subversion for the theme code itself did help us test changes to the theme scripts and style before pushing them to production, but the content itself was not duplicated: the development instance of the blog had some fairly antiquated content, while the production instance had all the latest article.

Synchronising the content from the production to the development server was not as easy as simply dumping and reimporting the whole SQL database. Be aware that if you import a whole WordPress database, you also import some field setup that will cause unwanted redirects.

Suppose you dump the wordpress database for http://www.myblog.example.com/ into a duplicate instance at http://dev.myblog.example.com/. Try accessing http://dev.myblog.example.com/ and wordpress will automatically redirect you to http://www.myblog.example.com/, which it thinks is the right URI for your blog. What to do? Go to the WordPress Dashboard and edit the settings? Not going to happen, since trying to access http://dev.myblog.example.com/wp-admin/ will also redirect you to http://www.myblog.example.com/.

The solution I found was to:

1. Make sure you use separate databases for your production and development blog. This is much safer, anyway. Also, make sure your databases and files are properly backed up before attempting the following hack.

   Disable all plugins before the sync. Especially if you are using wp-cache, disable it. You’ve been warned.

2. Dump the database from your production blog into the separate database for your development blog. With mysql, this will look like:

   mysqldump PROD_DATABASE_NAME -h PROD_DATABASE_HOST -u PROD_DATABASE_USER -p > wordpress_dump.sql

   then

   mysql DEV_DATABASE_NAME -h DEV_DATABASE_HOST -u DEV_DATABASE_USER -p < wordpress_dump.sql

   (You will be prompted for the database password both times. Make sure to replace the placeholders PROD_DATABASE_HOST with actual values for your setup.

3. Edit the development database to tell wordpress the location of the dev blog. With MySQL again:

   echo 'update wp_options set option_value="http://staging.address.com/" where option_name="home";' | mysql DEV_DATABASE_NAME -h DEV_DATABASE_HOST -u DEV_DATABASE_USER -p

   and

   echo 'update wp_options set option_value="http://staging.address.com/wordpress" where option_name="siteurl";' | mysql DEV_DATABASE_NAME -h DEV_DATABASE_HOST -u DEV_DATABASE_USER -p

This worked for me, in two very distinct configurations last week. Any way this could have been done in a less hack-ish way? Tell me in the comments.