Good computing practices frequently lead to easily reusable data and code. Reuse isn’t always a priority, and you can’t always see it coming, but it makes the work that’s done far more valuable than can be expressed in return on investment for a particular project.

I’ve spent a lot of this weekend writing unit test code for routines I wrote two years ago. I wrote the code to be reusable in a classic object-inheritance kind of way, but at the time I had very little clue about what I could do to make that code a solid foundation for other work. Sure, I’ve cut-and-pasted routines, adapted code to new needs, and done what I could to make the code readable years later, but creating code structures designed for modification was way beyond me. After a weekend writing a library of tests, I feel like I’m finally figuring how to write code that can be reused and repurposed without dire paranoia and dense fog.

At the same time, I’m planning to reuse some XML data I had created for one set of projects in a completely different area. Data points for an XSLT-generated SVG map are suddenly going to be fodder for statistical analysis in Excel. I didn’t spend an enormous amount of time building the structures early on, but maintaining the basic content/presentation divide was enough to keep the data reusable. (Relational databases offer many of the same advantages to developers who focus on how to normalize their data rather than thinking only about the task they want accomplished today.)

There may not be much initial benefit to spending time building unit tests and producing clear XML vocabularies (rather than just object or table dumps), but both of these practices make it much easier to deal with that programmer’s nightmare: change.

At the start of a project - or even at the end of a project - there’s no way to know how much value someone you may never meet will derive from the effort you put into making your code and your data robustly reusable. You or your organization may be the beneficiary, if you’re lucky. If you’re even luckier, you’ll benefit from the work someone else put in.

All this extra work… why can’t I just use undocumented one-letter variable and element names?

Related link: http://news.com.com/2100-1046-994258.html

Macromedia announced an enhancement to Flash that will allow its content to operate independent of the browser on the desktop. Additionally, the company will be launching Flash Central, an associated marketplace that will allow Flash application developers to market and sell their applications. Macromedia will take a 20 percent fee on all sales — a model very similar to that being employed with mobile applications in the J2ME and i-Mode space. (For more thoughts on Macromedia Central see this entry on the weblog of Macromedia's Chief Software Architect, Kevin Lynch.

This is a very positive step in the evolution of SWF files (Flash's native format) as a platform for lightweight Internet applications or, as some call it, microcontent clients. As I asserted in my article Flash MX and The Big Picture, the document-centric browser is an awkward solution to a growing number of emerging needs. the browser still remains quite useful and will continue to do so, however it would benefit from an application-centric mate. (The topic is one of the main focuses of O'Reilly’s upcoming Emerging Technology Conference next month.) The Flash file format and runtime engine addresses these exact needs making itself an leading candidate. As I stated, In many ways Flash MX promises to do for Internet applications what Visual Basic did for Windows applications in the early '90s. It could also lay the groundwork for redefining the desktop. Based on this announcement that seems to be exactly where Macromedia is heading and I applaud their foresight.

Despite its continuing evolution, some issues have yet to be addressed to date.

Recently in response to a question posed by Kevin Werbach, former Macromedia CTO Jeremy Allaire posted to his weblog some thoughts as to why Flash applications have not been more broadly adopted by developers. As often the case, Jeremy is spot on. Awareness and cognitive dissonance (the negative association of Flash with the gaudy overuse of animation) leads his list. Efforts have been underway and will take some time and persistence to address. (Certainly issues such as the recent release of the company’s new website have not helped this cause.) Jeremy also lists Flash's ties to the browser that will be rectified in the near term. What's left outstanding is the fourth reason he lists — the programming model or more precisely in my opinion the programming tools. With Flash's impending freedom from the browser, the final point remains as the sticking point for myself and I suspect other programmers from buying in further.

Since reading Jeremy's post and follow-up by Kevin Lynch, I've been thinking about my ideal Flash development tool — or at least the one I think will marginalize the barriers to entry seasoned programmers perceive and really let the market flourish.

What I want is a lightweight command line tool that will let me build Flash applications from text files containing XML and ActionScript code. In other words, what I want is a Flash application compiler.

This tool would make extensive use of existing standards. ActionScript already complies with the ECMAScript standard. The XML formats would excluded standard formats such as SVG and XForms (or perhaps XUL) with the conservative introduction of extensions through XML namespaces. These XML files would be used to define things such as objects, screens, form layouts, and would be compiled into native Flash format constructs. (In my estimation this is a good compromise in addressing the uproar of standards advocates while keeping the player lightweight.)

There are several lessor-known third-party Flash development tools that address some of wishes — tools such as Lazlo, X-Wave, Swish and Screenweaver and DENG — though not entirely or to my satisfaction. To grossly generalize, these tools gravitate towards Flash's animation heritage amongst other shortcomings. The Lazlo Presentation Server comes closest, but is a server based.

What these tools lack most importantly is that they do not originate from Macromedia. Providing freely available baseline tool for Flash application development is crucial to its evolution and simply too important to come from anywhere else. Hopefully I’ll get my wish.

UPDATE: Seems my wish could be coming true sooner then I thought. Macromedia's Mike Chambers writes on the tantilizing Royale project that was shown a the FlashForward conference today.

What are your thoughts on Flash applications and microcontent clients?

Related link: http://wwws.sun.com/software/sunone/innercircle/newsletter/cto0303.html

In a Sun InnerCircle publication Sun Chief Technology Evangelist Simon Phipps writes:

Still, despite wide consensus, the technologies usually associated with Web services are not actually standards or recommendations of any open standards organization. To the surprise of many, Web services are not just about SOAP and things that start with WS-*, as some vendors would like you to believe. Some of the most widespread Web services today — for instance, those in use by the fast-growing Web-logging ('blogging') community — are based on other technologies like RSS and XML-RPC.

I'm glad to finally see a major technology vendor acknowledge SOAP etc. is not all there is to Web services and that RSS as a legitimate technology in that space. Given its emerging uses, RSS is not just a format for syndicating content. As I've written in the past and others have noted, RSS feeds do qualify under the principles of the REST architectural style that the Web was built on.

Simon's mention of weblogging raises a question I've been meaning to ask for some time. Are there any Sun employees blogging? Microsoft and IBM have a handful that I know of off the top of my head. Macromedia is the model corporate blogging citizen with some significant top brass (Kevin Lynch and, until recently, Jeremy Allaire) making regular posts.

If I haven't overlooked any Sun employees blogging, this is quite an oversight. Microsoft is not the only company that could use a human face.

UPDATE: In my original post I omitted that I think Apple's Safari developer extraordinaire David Hyatt weblogging his work and views is marvelous and another great example of bloggings potential in these firms. David's communications with his existing and potential user base not only interesting, but provide me with a sense of understanding and confidence in his (and Apple's) work.

Also, some Sun employee blog sightings are coming in via private email and the comments below. One of these sightings includes Simon Phipp's own personal weblog.

Lastly, you may have noticed that I ignored Simon's mention of XML-RPC. While it certainly has its uses today, the limtiations I've come to know leads me to not support its proliferation going forward. Its flaws are serious. Today, in randomly surfacing around, I happened upon this "rant" by Charles Cook on XML-RPC and weblogging APIs that covers some of the significant shortcomings quite well and figured I share the link and state my view.

Do you view RSS as a Web service? Do you know of any Sub bloggers?

Related link: http://mail.gnome.org/archives/desktop-devel-list/2003-March/msg00675.html

This post from Havoc Pennington contains some interesting musings on what it would take to make crypto with PGP or GPG user-friendly. It’s more than a nice GUI around the existing tools, says Havoc, it’s that it needs to be more task-centered.

I’m quite a keen user of PGP encryption, but it took me a long time to understand the concepts involved, and my use of it is still limited by the relative lack of integration of the current toolset.

Got any ideas about making crypto easier to use?

Kendall Clark's most recent XML-Deviant column highlights the debate of subsetting XML, JAXP and SAX in the J2ME Web Services Specification (JSR 172). At issue is the specification allowance of parsers to throw a SAXParseException when encountering a document type declaration, and to not support non-predefined entity references and interoperability with the full XML specification.

This is an excellent point. While I believe not all Web services should useful to a mobile device the current handling of such an occurrence is unacceptable.

In the article Michael Champion is quoted asking what's a cellphone supposed to do with an external entity reference, or a notation declaration? The answer is simply — nothing. In the tradition of the Web, I would suggest unknown data types be quietly ignored unless explicitly declared programmatically by the developer.

This recent debate has returned my attention to some comments I submitted to the JSR 172 group in December and another major failing of this specification that I have not seen discussed.

I've yet to completely review this draft, but I have scanned the change log and checked for what I thought was the one of the most crucial omissions the word asynchronous.

There are zero occurrences of the word in this draft. As I wrote in my comments to the JSR 172 group, if there is one place where asynchronous messaging is most needed its with the unreliable low-bandwidth mobile networks that mobile phone and PDAs operate.

One of WAP's leading failings (and there where so many) was that applications were useless if a connection was not available or lost. In the US we know how common this occurrence is. Sun lists J2ME's local execution of applications (MIDlets) as a key advantage over WAP applications on mobile devices. However without there will not be a standardize way in this specification for a developer to cope with a loss of connectivity. Without the ability to deal with the loss of connectivity Web service-enabled MIDlets will be useless as a WAP application. That's why I find it remarkable that this specification does not support this vision.

I'm sometimes taken aback as to how little we the developer community seem to understand the realities for developing for the mobile medium particularly resource constrained devices like mobile phones or common PDAs. It is not realistic to believe the solution is mobile phones become as powerful as laptops and bandwidth to become as plentiful as air. Social, economic and environmental factors make this difficult to address and unlikely to succeed in practice.

Sadly, it seems this has been lost on the JSR 172 group and we'll have a mobile Web services specification, and eventually implementations, that really aren't very useful or reliable in reality.

I am cautiously optimistic that some form of Web services will be achievable though its likely to be outside of this specification and subject to a different set of issues.

Consider this: J2ME supports HTTP communications down through MIDP and the recently released MIDP 2.0 specification supports a push communications facilities. (See my article on MIDP 2.0 for more.) RESTful J2ME Web services anyone?

The following is my email to the JSR 172 in its entirety including grammatical mistakes. ;)

Subject: JSR-172 v.03 Draft Comments.
Date: Sun, 15 Dec 2002 20:50:47 –0800 (PST)
From: Timothy Appnel
To: jsr-172-comments@sun.com

I've read the v0.3 draft of the J2ME Web services
specification and have these comments to submit for
consideration by the JSR 172 expert group.

First, I'd like to acknowledge and commend the group
on taking what is truly a difficult assignment. XML
and Web services specifications where not designed
with such resource constrained environments in mind,
however the loss of flexibility and openness to a
proprietary or binary would be unfortunate.

I think the JAXP subset, including restrictions of DTD
support, is reasonable though I feel 25KB is not
acceptable size in comparison to other J2ME XML
parsing packages such as kXML. I realize that this
packages are not JAXP compliant, however in my
experience in MIDP development, it is my belief that
file size and speed is more important then
compatibility with JAXP. Existing J2SE and J2EE code
is likely to be inappropriate for J2ME applications
and will require some refactoring regardless. Given
these circumstances I would choose to use kXML that
only has a file size of 9KB in its minimum package
form.

Likewise I think the JAX-RPC functionality is
reasonable however it is my opinion that RPC support
is not nearly as useful or relevant to providing Web
services through some simple form of asynchronous
messaging. The continued emphasis on RPC style Web
services remains my biggest criticism and
disappointment of the group's work so far. If there is
one place where asynchronous messaging is most needed
its with the unreliable low-bandwidth mobile networks
that mobile phone and PDAs operate. While the
specification does not preclude the implementation of
service QoS mechanisms that would provide the
infrastructure for dealing with unreliable
connections, a generic baseline should absolutely be
required. I strongly suggest the expert group
reconsider this decision.

A 50K file size is a bit larger then I would hope. I
had 35K-40K in mind. Related to file size, I
understand that the J2ME JAX-RPC package must be
independent of the JAXP package. The specification
does not clear state what (if any) ROM savings there
are if the two coexisted. If there were not any
savings to mention, I would question why this is since
clearly the JAX-RPC package must parse XML to
function.

The data types support in the JAX-RPC subset is
acceptable. In the tradition of the Web, I would
suggest unknown data types be quietly ignored[1]
unless explicitly declared programmatically by the
developer.

I think defining a recommended protocol would be
warrant if its allows the specification to assure a
standard and demonstrative means of reducing bandwidth
consumption. Given the verbosity of XML and Web
services protocols some form of compression is needed
in this specification.

Given the SOAP 1.2 protocol's release is likely to
occur before this specification's release, I would
suggest that more consideration and emphasis be placed
on SOAP 1.2 then what currently exists in this draft.

I hope that my comments have been helpful and
constructive. Please feel free to contact me if any
further questions exist or further discussion is
warranted.

<tim/>

[1] http://www.intertwingly.net/stories/2002/07/29/expectMore.html

What do you think of the JSR 172 specification and Web services place in mobile?

Related link: http://dubinko.info/writing/xforms/

The fine folks at O’Reilly have agreed with me to release pre-publication drafts of the book under a Creative Commons license. After publication, the text will be released under the GFDL.

Send any comments to mdubinko a@t yahoo d.o.t. com

Related link: http://xml.coverpages.org/

As long as XML has existed, perhaps longer, there have been visions of machine-readable registries and discovery systems which will let computers talk to each other automatically. While millions of dollars have been spent pursuing these dreams - and more are being spent every day - a much simpler system has been keeping the users and creators of XML vocabularies talking. XML has an incredibly powerful trick up its sleeve, a bibilographer named Robin Cover.

I’ve been using the Cover Pages since I started working with XML. When I arrived, it was still very much about SGML, with a convenient XML sub-section I could browse. Over time, the XML content has grown rapidly, and I can’t say I envy Robin his task of keeping up. He collects some of the information by scouring lists and sites, and some of it comes to him directly, but there’s pretty much a continuous flow of information - and a collection of nearly eight years’ worth of news entries! (He has been collecting bibilographic information on markup since 1986, for nearly seventeen years of total collection.)

The Cover Pages demonstrate a lot of things that I like about the Web. Its blog-like style - see 1995 for a taste of its early days - manages to collect huge volumes of information over time, conveniently accessible through a variety of search engines. While Cover’s site is a centralized source of information, the actual details of the many XML technologies he covers are stored at their original and very decentralized homes. And while Cover certainly filters his content to choose appropriate content, I’ve never heard a complaint about “that uppity Cover won’t publish my XML stuff”.

The Cover Pages also demonstrate that keeping humans in the loop isn’t a bad thing. Apart from Cover’s own hard work, the site’s readers are a critical interface between the information they find on the site and their code. Whether those readers are programmers, managers, or markup wonks, the Cover Pages is a good place to start. While glorious visions of XML schema registries (biztalk.org, xml.org) and Universal Description, Discovery, and Integration (UDDI) may have set off waves of hype and even led to some useful developments, I suspect the Cover Pages deserves lots of credit for connecting people and programs at many levels on a regular basis for nearly eight years.

In PR-speak, that might result in triumphal press releases about “enabling [millions | billions] of [dollars | euros] of [enterprise integration | document management | hacker twiddling] with XML and Web Services.” The Cover Pages prefers to describe itself as an “Online resource for markup language technologies” - no small achievement.

Have you used the Cover Pages?

I finally got to meet the “other” David Chappell last night at a trade show event I was at. I was in Santa Clara for the purpose of giving a presentation at XML Web Services One, and there was a Bay.NET user group meeting there last night that was hosted at the show. The other David http://www.davidchappell.com/
was there attending the meeting. Oddly enough, our paths have never crossed until last night even though we both do the industry public speaking circuit quite frequently. We do trade emails occassionally but never made a real effort to meet in person prior to last night’s chance meeting. Surely this must be one of the most exciting industry events to happen in this decade.

We don’t think that we’re closely related - my family is mostly from Maine (from the “Tom’s of Maine(R)” fame), and I think David said his family is from the midwest or something. If any of you recognize a family resemblence, let me know.

Its a small world, for sure. One of my co-authors, Richard Monson-Haefel, has been a friend of David for a few years now.

As an added bonus, Don Box (who has always been so amazed by this multi-Chappell phenomenon) decided to join in a photo with us. (Don is the guy in the XML T-Shirt). If you see a family resemblence there as well, then that’s really scary ;-)

Ted Neward (who used to work with Don at Developmentor), took the photo and also blogged it at -
http://www.neward.net/ted/weblog/index.jsp

Don gave a great presentation at the meeting BTW. If you have never seen him present, you should make it a point to see him. The entertainment factor alone is worth the excursion. His presentation style is very colorful and energetic, and guaranteed to be informative as well.

Dave

Related link: http://www.audioscrobbler.com/index.php

Everyone thinks they’re weird. Especially in music: how can anyone know what I like to listen to? Switching between Bizet’s Carmen, and Waylon Jennings’ Mammas Don’t Let Your Babies Grow Up To Be Cowboys, is confusing even for my taste.

So when someone comes along with a system that tells you not only what you might listen to, but that there are others with similar tastes, well, then we jump at it.

And so it is with Audioscrobbler.com, with which Richard Jones, otherwise known as RJ, might have the answer. In his final year of a computer science degree at Southampton University, RJ is building a system that monitors what you’re listening to, and makes recommendations of new music.

It works like this: You install some software on your machine - currently there are Audioscrobbler plugins for Winamp (Windows), XMMS (Linux) and iTunes (Mac OS X) - and it monitors what you are listening to. This data is sent up to the Audioscrobbler server, which records it against your user name.

After some time, a pattern emerges. You really like bands A, B, C and D, and another user over there likes bands B, C, D and E. So, says the system, chances are you will like band E, and the other user will like band A. Now scale this up to thousands of users, and you have the potential for really good recommendations.

It’s a little more complicated than that, though, says RJ: “People tend to listen to a few artists frequently, and lots of artists occasionally. Seemingly, people have a handful of favourite artists and a load of other ones they like as well. [The system] allows for calculating which songs are most popular in a more ‘natural’ way. For example, three people listening to the same song five times each makes it more popular than one person listening to it 100 times.”

This technique, known as collaborative filtering, is not new. The most well-known project to use this idea was called FireFly. The brainchild of Professor Pattie Maes, from the Massachusetts Institute of Technology, FireFly was also designed to suggest new music. But it asked the users to “rate” different songs or bands. This wasn’t really a weakness at the time - FireFly was launched when dial-up access was the norm, and people couldn’t be expected to be online all the time. But it did mean that their data could be skewed by sociological pressure. People might rate the band by what they think is cool, rather than what they actually listen to.

Audioscrobbler, on the other hand, infers people’s tastes by monitoring what they actually listen to, and not what they say. It is, it must be said, much easier to let the system run in the background, connecting to the net when it needs to, than have to go online specifically, and answer questions.

Amazon, the online retailer, also has a similar system, but it also has limitations. “It is based on what you buy or view online, but I sometimes buy CDs from Amazon as gifts for people, and sometimes buy CDs that I end up not listening to much,” says RJ.

“The Amazon data is a good guideline but I wouldn’t feel comfortable choosing a new CD to buy based on that alone. I hope I’ll be able to trust Audioscrobbler enough to help in my CD-buying decisions in the near future.”

With his final report due in to his supervisor in May, RJ is excited about the potential of the project after graduation. “I’m looking into ways of ‘acoustically fingerprinting’ songs, so that songs can still be identified, even if they are not named correctly_ hopefully Audioscrobbler will become the way to discover and promote new music.”

Meanwhile, however, the popularity of the service - almost 2,000 users - means RJ is looking for help with the hosting.