ning!

About an hour ago tonight we took the covers off ning: a playground for building and using social applications on the web (how's that for a brief description?). A super simple way of getting personalized social apps up and running, or a way to experiment without having to worry about all the stuff that's usually, well, way too hard (like, say, DB setup--look ma! no DB!).

It's been an incredible year so far, lots of work but lots of fun too, working with a fantastic team. The last few weeks have been... intense. A million of things I want to write about, which for obvious reasons have been sidetracked.

Anyway, you can bet I'll be writing more about this later! :-)

php's simplexml

One of my favorite features of PHP 5 is SimpleXML. In brief, it maps the structure of an XML document to as variables within PHP, with subnodes as variables within the root object (recursively) and the text value of a node (as you'd expect) to the value of the variable. For example, the code in PHP 5 to parse RSS 2.0 and Atom 0.3 feeds (maintaining a relatively clean structure, and just parsing for the basics) is super straightforward.

Observe!

<?php

  //each individual entry in the feed
  class FeedEntry {
    public $title;
    public $summary;
    public $content;
    public $created;
    public $modified;
    public $issued;
    public $id;
    public $link;
  	
    final function __construct() {
    }
  }

  //the feed (including simpleXML parsing)
  class Feed {
    public $xmlContent;
    //the resulting parsed entries
    public $entries = array();
	
    //the document information
    public $title;
    public $link;
    public $description;
    public $author;
    public $created;
    public $modified;
    public $issued;
		 
    final function __construct($xmlcontent) {
      $this->xmlContent = $xmlcontent;
    }
		 
    function parse()
    {
      $xml = simplexml_load_string($this->xmlContent);
      if ($xml['version'] == '2.0') { //rss 2.0
        $this->parseRSSFeed($xml);
      }
      else if ($xml['version'] == '0.3') { //atom  0.3
        $this->parseAtomFeed($xml);
      }
    }
		 
    function parseRSSFeed($xml) {
      $this->created = $xml->channel->lastBuildDate;
      $this->issued = $xml->channel->lastBuildDate;
      $this->modified = $xml->channel->lastBuildDate;
      $this->title = $xml->channel->title;
      $this->description = $xml->channel->description;
      $this->link = $xml->channel->link;
      foreach ($xml->channel->item as $item) {
       $this->parseRSSEntry($item);
      }
    }
		 
    function parseRSSEntry($entryToParse) {
      $entry = new FeedEntry();
      if ($entryToParse->description == '' &&
                  $entryToParse->title == '') {
        return;
      }
      if ($entryToParse->description !== '' &&
            $entryToParse->title == '') {
        $title = substr(strip_tags($entryToParse->description), 0, 50) . '...';
      }
      else { 
        $title = $entryToParse->title;
      }

      $entry->title = $title;
      $entry->summary = $entryToParse->description;
      $entry->content = $entryToParse->description;
	      
      $entry->created = $entryToParse->pubDate;
      $entry->issued = $entryToParse->pubDate;
      $entry->modified = $entryToParse->pubDate;
	      
      $entry->link =  $entryToParse->link;
      $entry->id = $entryToParse->guid;
		 		
      array_push($this->entries, $entry);
    }
		 
    function parseAtomFeed($xml) {
      $this->created = $xml->created;
      $this->issued = $xml->issued;
      $this->modified = $xml->modified;
      $this->title = $xml->title;
      $this->link = $xml->link;
      $this->description = $xml->tagline;
		 		
      foreach ($xml->entry as $entry) {
        $this->parseAtomEntry($entry);
      }
    }


    function parseAtomEntry($entryToParse) {
      $entry = new FeedEntry();

      $entry->title = $entryToParse->title;
      $entry->summary = $entryToParse->summary;
      $entry->content = $entryToParse->content;
	      
      $entry->created = $entryToParse->created;
      $entry->issued = $entryToParse->issued;
      $entry->modified = $entryToParse->modified;
	      
      $entry->link =  $entryToParse->link;
      $entry->id = $entryToParse->id;
		 		
      array_push($this->entries, $entry);
    }
  }

?>

This code can then be used as follows:

  $feed = new Feed($xmlcontent);
  $feed->parse();

  //print the title of each feed entry
  foreach ($feed->entries as $entry) {
    echo $entry->title;
  }

Where $xmlcontent is obtained through, say, a curl call:

  $ch = curl_init();

  curl_setopt($ch, CURLOPT_HTTPGET, 1);
  curl_setopt($ch, CURLOPT_URL,"http://www.dynamicobjects.com/d2r/index.xml");
  curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
  $xmlcontent = curl_exec ($ch);

  curl_close($ch);

All of which amounts to quite a lot of interesting functionality in a small set of easy-to-understand code.

Does it have limitations? Sure. Is it enough for many XML parsing jobs? Yes.

This is why, btw, PHP is so appropriate for building web stuff where there's so many user-driven elements and "point solutions" (taken to the extreme, one per page in a website).

Who needs reuse when (re)coding is so easy? :)

PS: I would like to read the following statement which I am making of my own free will and without being coerced in any (ouch!) way: Reuse is good, particularly with Java, and no one should ever say that it's not, lest they find themselves in the depths of hell, or possibly a Standards Body terminology & rules meeting. In summary: Java, good. PHP, bad. (Ruby, great.)

PS2: Those that can quote something else from the Simpsons episode which the previous PS is spoofing get extra credit.

PS3: Those who react to PS1 above without knowing the context of the Simpsons episode should refrain from commenting. There's a fine line between good and bad references, a fine line indeed, and while it's never hard to know when it's been crossed, I'd rather not be made aware of the distance traveled since.

css + javascript = behaviour

Behaviour: "the missing link for your ajax apps", aka "use CSS selectors to specify elements to add javascript events to". Great! [via O'Reilly Radar]

The one thing that keeps bothering me a bit about AJAX and DHTML applications is that MVC tends to create fairly deep abstractions. Debugging, and, more importantly, maintaining this code, will become more and more difficult since the only way to navigate it efficiently (that I know of) is to use, well, grep, Ctrl+F, and such. Hard to refactor. Hard to analyze. Hard to validate. Full Javascript+DHTML Eclipse module anyone? I mean, one that goes beyond autocomplete. I've got that already. :)

atomflow redux

Mark Paschal has just published a cool perl module that continues along the atomflow idea:

To help myself build atomflow style tools, I wrote XML::Atom::Filter, a Perl module to build command line Atom processing tools around the XML::Atom library.

Fantastic!

I've been slowly (ever so slowly) adding bits and pieces to the atomflow tools over the last few months. This is just what I needed to definitely get me off my slumber and pull together another release.

Ideas I want to explore in this space are not only related to more command-line tools (and Mark has some great ideas there in his post!), but also to creating pipes directly from server to server (that the network is the disk drive again) and do straight flows that can be tied together without ever settling down. For command line my thing is Java, but for the web I'd like to try some PHP, which is simple, fast, and flexible enough. Anyway, I'll try to make a couple of hours within the next few days to do this. Not right now. Too busy. Lots going on. :)

24 hour laundry: the view from inside

Well, well, well. :)

There's been a lot of discussion recently about a certain new startup called 24 Hour Laundry. It pretty much got started with this CNET article, then as highlights we've got Om, Mark. Even (perhaps predictably) Slashdot.

24HL, as it happens, is where I work. Remember this?

Yep. It's true. Aaaaaall this time and I didn't say anything. Outrageous! How could I?

Well, that's kinda the point.

You see, we didn't want to make any noise. CNET decided that they wanted to "scoop" a story that didn't exist (and is still not all that exciting at this point). We didn't have anything to do with that article.

Then, in the process of not asking for any press and minding our own business, we get branded a certain way, and told we are doing something wrong by focusing on our product.

What is confusing to me is that some of the comments out there begin with "Well, I don't know what they're doing but [insert your thought about why it's wrong here]".

It is one thing to speculate (which we all do a lot of, don't we) and draw tentative conclusions based on that, but it's another to take those assumptions and then categorically "paint a picture". I know: to a certain degree, these are the rules of the game. But there is a difference between saying "If X is doing W, then here are the problems I see" and saying "X appears to be doing W. They're crazy!" This was partially Russ's point with his great post yesterday. (Update 6/23: Jeff Clavier also makes good points on the topic).

For example, Mark Fletcher said:

[...] But creating a new web service is not rocket science and does not take a lot of time or money. My rule of thumb is that it should take no more than 3 months to go from conception to launch of a new web service. And that's being generous. I'm speaking from experience here. I developed the first version of ONEList over a period of 3 months, and that was while working a full-time job. I developed the first version of Bloglines in 3 months.

In other words: "whatever it is you're doing, you should be able to do it in three months."

Ah, those pesky generalizations--but this is actually an interesting point to bring up. Last year, it took me about 3 months to write the first version of clevercactus share, which didn't just include a website/webservice, but also an identity server, a relay server (to circumvent firewalls) as well as a peer to peer client app that ran on Windows, Mac and Linux.

One person, three months. Webservice, servers, clients, deployment systems, UI/design, architecture, code, even support.

Which proves... absolutely nothing.

You have to fit the strategy to the company and not the other way around. In our case, we're doing something a little different (not better, just different) than the next web service, so we're just trying to keep our heads down until we have something that makes sense.

Of course we want to release as quickly as we can. Of course we know that when we launch there will be dozens of features we wanted to add but didn't have time for. Of course we keep in mind that we can't release a "perfect" product.

We absolutely want to involve users in the product's eventual evolution. We just want to make sure that we have a few things figured out before we start sending out press releases to announce our video-blogging social scooter company.

We appreciate the patience, and the interest (even if in some cases it's a bit misguided!). We are working as hard as we can, as fast as we can, to come up with a good product.

Sounds reasonable? :-)

PS: this may be a good time to add "This is my personal website and blog. The views expressed here are mine alone and do not necessarily reflect those of my employer."

subclassing enums in Java 5

[via Erik]: Beyond the basics of enumerated types: how to use more than simple enums with subclassing and method overrides. Very interesting. While my favorite Java 5 change is the enhanced for loop, generics (i.e. templates) and enums are a close second.

the problem with scoble's linkblog

While I enjoy perusing Scoble's linkblog when I have time (there's pointers to a ton of interesting stuff in there) I have not been so thrilled about his full-republishing technique. In my opinion, the question who exactly created the content is going to be slightly confusing for someone arriving there from a search engine (this in particular for people that don't yet know what blogs are, much less linkblogs).

Even if it was obvious though, the fact that he is republishing articles/posts wholesale without explicit permission means that a reader that would otherwise end up in my blog suddenly has no reason to do so. I have avoided commenting publicly on this, waiting to see if it changed, but it hasn't.

For example, check out his reposting of my take on AJAX. It's a long post (something relatively common for me) and by the time you scroll down to the second paragraph, you have forgotten that URL at the top. Many people will just get to the end, and move on to the next linkblog post.

Republishing content wholesale without permission is a bad idea. And a linkblog is supposed to be made of links, not full posts.

Robert, I suggest you simply post links and titles, rather than full posts---at most, a 50-word snippet or comment would do (similar to what Kottke does for his linkblog posts). If you think that's unreasonable, I'd ask you to remove any posts of mine that you may have republished over there and to avoid republishing other posts in the future. Thanks. :)

more on ajax

Don talks about his POV on AJAX, and brings up something that (to keep things simple) I neglected to mention in my post.

For a long time I have been deeply ambivalent about using DHTML and Javascript for serious apps. I really like the reach these apps create, the ease of distribution, and all the good stuff that comes from that. But aside from the problems that Don mentions in terms of pushing the browser "platform" beyond its design limits, I keep wondering about what writing complex applications using these technologies would do to software engineering in general. We have advanced quite a lot, and it's taken a lot of effort, to get away from error-prone techniques and tools that we used as recently as 5 years ago. Thanks to advanced IDEs, we are no longer bound by pre-existing structures and we're much more free to refactor, analyze, and reuse code in new ways. Java has been crucial in that (and in finally establishing how sensible memory-managed languages were), but now we're onto Python, PHP, Ruby, and other languages.

Going to DHTML and Javascript would put us back a bit in this evolution. Javascript and DHTML IDEs are basically non-existent or too basic. Debugging apps in a browser environment is a nightmare. Software maintenance becomes another nightmare. And so on.

But assumming that AJAX apps prosper, I think that we'll just circle back, realize that we're facing the same problems, and then find solutions based on our previous turn on this particular loop. Maybe this will another step towards what Marc Andreessen hoped (almost ten years ago, and I still remembering reading that article!): "A secure, truly mobile agent language -- way beyond Java -- will eliminate the Tower of Babel that prevents us from harvesting more of the benefits of computing and communications today."

Amen.

on ajax

One of the latest buzzwords to make its way around the web is AJAX (short for Asynchronous Javascript and XML, is that a "buzzcronym" then, rather than a buzzword?), which strikes me, as well as others, as one of those there and back again technologies, old ideas reborn in a different form. Recent weeks have seen the appearance of various AJAX toolkits, from SAJAX (for PHP) to JSonRPC (for Java). JPSpan, another PHP toolkit, is a little older.

But first, what is AJAX? Here's a good intro article on it. The basic concept is a simple one: turn a web browser into a more responsive client by making asynchronous requests to the server on another thread, handled by Javascript (there's nothing that says that this couldn't be done with, say, Flash or Java, but Javascript is a more universal platform on which to implement this). This separate thread can create the appearance of a more responsive UI by managing the requests in a manner transparent to the browser's default navigation mechanisms (e.g., Back, Forward, etc.).

Why do I say that AJAX is an old idea reborn in a different form? To answer that, allow me to take a little detour.

How web apps (used to) keep state, or the thin client way

Originally, a browser+HTTP+server combo was a stateless content-retrieval system. As more complex logic was added, browsers remained "thin" in that held very little state information. Cookies (on the client side) and Sessions (on the server side) were created to address that as more complex applications were brought online. But the limitations of cookies for data storage mean that they are used primarily for two things: initialization information (e.g., automatic login to websites) and historical or subscription data (although even in this case cookies are largely used as browser-held keys that point to more complete server-side DB records). Sessions, therefore, have remained the primary method to maintain state through the lifecycle of a web application (Some data can be held in the web pages themselves, e.g., hidden form fields, but that data has to be passed back to the server on each request). The problem with keeping sessions in the server is that, for nearly all significant operations, the client has to go back to the server to present a result, and it has to do it through the core UI thread, leading to a diminished user experience.

The problem this creates is that as long as we're not all accessing the Internet over low-latency T3 lines, and as long as servers experience load spikes, unexpected loads, etc., the user experience of web applications (via thin clients) differs significantly from that of client-side applications (fat clients). AJAX bridges this gap by creating what amounts to (cue reference to Douglas Coupland's Microserfs) a "thin-fat client."

AJAX: web client/server, or the rise of the "thin-fat client"

In the early 90's, the buzzwords du jour were "client/server systems". These were systems where PCs actually performed a certain amount of processing on data obtained and passed back through tightly coupled connections (typically TCP). As important as servers were in that scheme, one of the keys of client/server computing was that the client maintained most of its state. True, the server did maintain a certain amount of state and logic (just keeping state on a TCP connection would count, for instance), but it was the client that drove the interaction, that kept information on a user's location in the dataflow, etc. The web, however, changed all that.

If the web thin client model decoupled UI from processing (at least relative to client/server), AJAX allows for a flexible "free form coupling" when necessary. By pulling more data-management logic back into the client, AJAX goes back to a more traditional client-server model. True, the server could maintain state if necessary, and undoubtedly some AJAX-powered applications, such as Gmail, do so to some extent. But consider the difference between Google maps and, say, Mapquest. Mapquest stores the current view's data in hidden fields in the page, which have to be sent back to the server on each request. While this is, speaking strictly, stateless operation, the server has to re-create the state of the client for every request, modify it as necessary, and then send it back. Google maps, on the other hand, can keep the state on the client, requesting new data from the server as the user moves around the map, zooms, etc. The result? The server is freed from creating/keeping/updating state and goes back to doing what it does really well, which is serve data.

So does this mean that we're going back to client/server? Doubtful. There is no silver bullet. As cool as AJAX apps (like Google Suggest, Google maps, or A9) are, I suspect that AJAX's greater value will be to add another tool to the toolset, allowing for hybrid thin client/fat client applications that improve web UI interactions and bring us to the next level of distributed applications.

a9's opensearch

Werner blogs about A9's new OpenSearch. From the site:

OpenSearch is a collection of technologies, all built on top of popular open standards, to allow content providers to publish their search results in a format suitable for syndication. [...]

Many sites today return search results as an tightly integrated part of the website itself. Unfortunately, those search results can't be easily reused or made available elsewhere, as they are usually wrapped in HTML and don't follow any one convention. OpenSearch offers an alternative: an open format that will enable those search results to be displayed anywhere, anytime. Rather than introduce yet another proprietary or closed protocol, OpenSearch is a straightforward and backward-compatible extension of RSS 2.0, the widely adopted XML-based format for content syndication.

Cool!

First Yahoo and now A9 are now pushing the boundaries of Search APIs. Google's API, sadly, remains in its usual we-don't-seem-to-know-what-to-do-with-this-or-want-to-support-it state. Maybe all of these announcements will spur Google to crank it up.

there and back again

The objectives of [this software] are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently.

Hm. Where did I get that from? Gnutella? Freenet? Some other fancier P2P app?

Nope. It's from RFC 959, circa 1985, which defines the FTP protocol (RFC 765, which it obsoletes, dates from 1980). "To promote sharing of files (computer programs and/or data)". Ain't that a riot?

One of the points I made in my thesis was that initially the Internet was truly a P2P system, and only later it moved into the client/server direction, only to slowly creep back into decentralized mode. FTP, which we hardly think about anymore, was a great example of this that I didn't use.

Consider that the original mode in which FTP worked was one where the client was actually a server as well. How so? Well, these days most FTP connections are "passive mode" connections. The "passive" there is talking about the ftp client. Normally, an FTP server accepts connections along with a port specification on the client. The server then opens connections to the client, which must have its own server for that. Passive mode enabled clients to open all connections themselves, a clear necessity as systems started to find themselves behind firewalls, NATs, and such.

The point is that even FTP, which we tend to think of as one of the prototypical client/server applications, was actually one of the prototypical peer-to-peer applications. The client and server divided the load, clients being responsible for serving transfer connections, and servers for the serving control channel connections.

There are many "loops" of this sort, sometimes repeated decade from decade. A lot of computing has been about making the same things easier, faster, or more scalable. And what's important about this is that, hard as it might be, it's always useful to know what happened before, from the 60s onward. Revisiting ideas is fun, as long as we avoid revisiting the mistakes: we should be trying to make new mistakes, not repeat the ones from the past. :)

PS: let's see how long it takes someone to note the title of the book from which the title of this entry was, er, "downloaded". :)

new mobibot, new GoogleME

Erik has released a new version of GoogleME and a new version of mobibot. Very cool. I still don't have a local phone, but once I do I'll actually be able to use the local features of GoogleME (which weren't very useful in Ireland :)). Also, mobibot is now uploading directly to del.icio.us, which is a great example of the use of the delicious API. I still have to make some time to play with that myself!

yahoo! wakes up

Yahoo does webservices!! Jeremy has a good roundup of pointers, and Yahoo search now has an excellent Developer site which includes information on their API and other things. Cool!

I keep saying that Yahoo! doesn't get enough credit for the stuff they do (probably because they have so many services and systems that it's difficult to see a "simple narrative"). Maybe this will start to change things.

wsss

Today I'm at the web spam squashing summit at Yahoo! HQ. I got here late, the result of a semi-crazy sequence of early-morning events that I will talk about later. Yes. More delayed posting. :)

myeclipse: wow

As it happens sometimes, I've now come full-circle on MyEclipse. To recap, I started thinking that, while nice, it was too slow for my needs. Then several comments on the entry pointed out that they were not seeing those problems. So after a few days, I decided to give it another try, and discovered that with the proper configuration it was actually not noticeably slower than Eclipse on its own.

Now, after about 5 days of using it constantly, I have to correct myself and say that it is truly a fantastic addition to Eclipse. The hot deployment feature is the key to it all. Once all the proper deployment features are configured, you can be editing a file, make a change, save it, and then go to the browser and reload, and the changes are there, and this applies to both JSPs and servlets. Sometimes the hot deploy fails (usually when modifying static members or persistent classes) but that's not a big deal, and restarting the server is a span in those cases anyway. This, across pretty much every major application server that's out there, "out of the box". Other cool features include autocomplete on JSPs, support for JSTL and other JSP tag libraries.

Anyway, if you use Eclipse and develop web apps and haven't tried MyEclipse yet, give it a try. Just make sure you configure it properly. :)

add(E), but remove(Object)?

Martin notes that in Java 5, the new-super-shiny-generics-enabled Collection interface has some inconsistencies. Most notably, the add method is dependent on the specific type for the collection, while remove and contains (most notably) are not. Here are the method contracts:

boolean add(E o)
boolean remove(Object o)
boolean contains(Object o)

Martin wonders why the discrepancy. I see two options.

Option one is a hilarious story that involves a monkey, a pantsuit, and a cherry cake interfering with the programmer's work and making her/him commit the grievous error for which she/he will feel regret the rest of her/his days. Let's call this the low-probability option.

Option two is that the Architecture Astronauts involved in the spec were carried away by the following definition of the remove method :

Removes a single instance of the specified element from this collection, if it is present (optional operation). More formally, removes an element e such that (o==null ? e==null : o.equals(e)), if this collection contains one or more such elements. Returns true if this collection contained the specified element (or equivalently, if this collection changed as a result of the call).

and this one from the contains method:

Returns true if this collection contains the specified element. More formally, returns true if and only if this collection contains at least one element e such that (o==null ? e==null : o.equals(e)).

My theory (and hoyven mayven, this is a theory only!) is that because the formal definition involves the use of the equals method and the method specifies an Object (and cannot, given that is the class at the top of the Java object hierarchy, know anything about "E") then the contract for contains and remove also follows with Object rather than E.

Sounds reasonable?

If anyone has the skinny on this, please pass it on. Alternative theories will also be appreciated. Especially if they involve monkeys (monkey-butlers are also accepted).

myeclipse: it's all about the config

I got several comments to my myeclipse: slow post a few days ago, from others that said, basically, that they didn't see any of those performance problems in their daily usage of Eclipse. Additionally, there was a comment from Riyad (from MyEclipse support) which mentioned a few things to look at, etc. Thanks to everyone for their comments, they definitely made a difference in making me take a second look at the product.

Okay, now the problem was that I had uninstalled, reinstalled a "clean" eclipse, and didn't have time to try everything again, until this morning. I set out with patience early today. I installed a clean copy of tomcat (5.0.30), a clean copy of MyEclipse 3.8.4 (for Eclipse 3.0.x), and tried again.

Initially, I saw the same problems as before. JSPs would appear to have syntax errors (ie. I couldn't get myEclipse to find the JSTL files, etc). I tried adding on the JSTL config myself but couldn't make it work either. Riyad's instructions did not help.

Ah, but then I thought, wait a minute, maybe the problem is that I'm trying to use a pre-existing project with the web development features.

So I created a new project with J2EE/Web Development, and, sure enough, things worked. I selected JSTL right from the start, along with the proper directory configuration, and a few minutes later the "hot deploy" feature was working.

Additionally, I haven't (yet) experienced any slowdown related to all the features that myEclipse provides.

So, take note: if myEclipse is running slowly, it's possible that the problem is that your configuration is wrong somewhere. Try creating a new project from scratch (and when it's working, removing the old ones) and properly specifying libraries, features you're using (such as JSTL or Hibernate), etc.

Conclusion: much better now that everything seems to work. The hot deploy feature is pretty good, although I've already seen it get confused a few times, the integration is definitely a plus. More later when I've had more time to play with it!

quack!

Martin on duck typing which is not, as you might expect, a discussion involving Daffy Duck and keyboards, but rather the differences between the Java and Ruby object systems. He's been working up his Ruby-ness recently, coming from Java, and has already posted a bunch of cool stuff on the topic. Most excellent.

software as sound

via Slashdot, The Sound of iPod, or how to extract software by sound. A really cool hack (as if dual-booting an iPod wasn't cool enough!). Reminded me off Matt's body-chemistry-based iPod music.

myEclipse: slow

And continuing with the "Eclipse" theme this morning... :)

In contrast to PHPEclipse, myEclipse actually has a nice, straightforward installer, and at the beginning everything seems to be fine. But eventually things st-art-to-slow-down. The pages I was editing include JSP tags, that seemed to confuse the JSP editor to no end, and over about two days things started to get slower. The only reason I can think of for why this started happening is that the JSP pages I was editing got progressively bigger, with more tags and commands to verify. Restarting Eclipse didn't help. Changing the memory settings (giving Eclipse 384, 512 megs of RAM) didn't help either.

The "hot deploy" feature of myEclipse is nice: it allows you to specify a variety of app servers and hot deploy to them. But. But. It severly constrains you from actually tailoring what is deployed and how, pretty much forcing you to create a certain structure in your source tree so that the deployment process works well. If you do that, however, you get some pretty good functionality.

Slow though, very slow. At least on my P4 with 1 gig of RAM. It was slo slow in fact, and I was getting so little benefit from it (I couldn't use the hot deploy, etc) that I just had to uninstall it and go back to just Eclipse.

Btw, when I say "go back to Eclipse" I mean that I had to reinstall Eclipse, since myEclipse left trash everywhere in the .metadata and .plugin directories and was making certain things fail (e.g., the Ant build) in Eclipse after the uninstall. In particular, the Ant build problem had to do with invalid settings under the workspace removing the directory workspace/.metadata/.plugins/org.eclipse.debug.core/.launches solved that.

Next up to try: Eclipse Web Tools project. For now, though, back to work.

Bonus: Over at the PHPEclipse site I learned about the "-clean" Eclipse launch option (There's also "-initialize"). Good for when you change install directories, etc., and it is not documented in the page I generally end up at when looking for Eclipse command line options (is is mentioned here though).

Update (a week later): Here's a follow-up to this entry, where I finally got myEclipse to run properly.

PHPEclipse: a good start

In my recent post about Zend Studio, Gerd mentioned PHPEclipse, a PHP development plugin for Eclipse 3.x. I didn't know about it, and it is pretty good.

The setup is still pretty rough around the edges, particularly when going beyond just PHP and into the MySQL/Apache/Debugger stuff (basically you need separate plugins for each). I wasn't able to actually make the debugger work, but then again I didn't have a lot of time to spend on that.

In comparison, Zend Studio is well integrated and works really well, and at this point it blows PHPEclipse out of the water (Zend also has a built-in advantage since it's not only a company, but the founders are the creators of PHP). Zend does cost $249, as Gerd noted, so it's nice to see that in PHPEclipse there's a good option in the pipeline.

protected does what?

Okay, quick, what's the effect of adding the protected qualifier to a class variable in Java?

If you're like me (and many others) you'd say: "protected allows only subclasses to access the variable".

Wrong!

At least according to Java 1.4 and Java 5...

We discovered this a few months back while chatting with Erik and I forgot to blog about it. Today I remembered it in a conversation with Martin.

Let's look at the Java Language Spec section for protected access, 6.6.2.1 "Access to a protected Member", it states:

"Let C be the class in which a protected member m is declared. Access is permitted only within the body of a subclass S of C."

Hm. That sounds like only subclasses should be able to access it, doesn't it. But try this code. Create package "x". Then create two classes in there, test1 and test2, with the following contents:

test1.java

package x;

public class test1
{
protected String hello = "TEST";
}

test2.java

package x;

public class test2
{
public static void main(String[] args){
test1 xx = new test1();
System.out.println(xx.hello);
}
}

Not only that will compile, but also running java x.test2 will print "HELLO". Which means that protected is giving package-wide access, not just subclass access. If you read the first definition in the spec:

A protected member or constructor of an object may be accessed from outside the package in which it is declared only by code that is responsible for the implementation of that object.

It seems to be loose in specifying only access-denied for non-package classes that do not inherit (a "negative right"), rather than only for inheriting classes (a "positive right", or is it the other way around? nevermind).

Okay, so what do you think? Does the Java Lang Spec contradict itself by not spec'ing out completely access in the first paragraph? Or is section 6.6.2.1 enough to say that this is a bug? (And I have confirmed this behavior in JDK 1.4.x and Java 5 as well).

Update: Juha, in the comments, notes that section 6.6.1 (a little before the section I referenced) makes the package-distinction clear. Martin agrees. Me? I agree that putting sections 6.6.1 together with 6.6.2 gives us the behavior we're seeing. I might be wrong in reading the text like I am (eu mentioned that in the comments), but I can't quite see it that way. I still think that Section 6.6.2 reads as if it's an all-inclusive rule, particularly since it doesn't reference section 6.6.1, only two paragraphs above, and thus sec. 6.6.2 appears to contradict both the spec from Section 6.6.1 and language behavior.

In any case, there's no mystery. At most, I'd say that section 6.6.2 has to be clarified to avoid appearing to contradict 6.6.1. Or rather, the whole section might be rewritten for clarity...

Or, I should change the grammar/parser in my head and read the spec differently (admit it, that's what you think we really needed, don't you!). Then all problems would be solved. I'll see if I can call the factory and get an upgrade or something. :-)

tomcat & Java 5 rant

So I go over to Jakarta this morning to get the latest stable Tomcat. Spend some time, as usual, browsing through the bewildering array of choices, until I find that the latest stable version if 5.5.4. But wait! There's also 5.0.30! Both seem to be parts of branches that are currently maintained. So what's the difference?

5.5.4 is compiled against Java 5. So to run it under JDK 1.4.x, you need a special "binary compatibility package". Do you want to bet that the 5.0.x branch is going to get less attention now that the 5.5.x branch allows Tomcat devs to play with the latest language toys?

This is not just a Jakarta issue, btw. Java 5 naturally breaks compatibility in several areas. Yeah, yeah, I know. Evolution of the language and all that. But, I don't know, I'd much prefer it if I could choose when to migrate, rather than have the choice eventually forced on me because good open-source projects start to migrate as well. Bleh.

Zend Studio: PHP for Java developers

Well, almost. :) I've been learning PHP recently and while at first I was a bit lost (what with coming from an all-encompassing IDE like Eclipse and all), fortunately I quickly switched to Zend Studio, which completely rocks.

Ted recently had a cool post on the IDE issue related to Python and Java, and I think that his comments (and some of the underlying discussion linked from his post) also apply to PHP.

Zend is really great as an environment in that regard (plus the environment is written in Java, using Swing. The first clue was the menu-border bug in WinXP, they should be using winlaf for an easy fix!). Because of its integrated debugging and execution environment (even installs Apache & PHP and allows you to work against that), and things like autocomplete, it feels very close to what Java people (read: me) are used to, and it surely makes things easier for newbies as well.

Anyway, if you use PHP or are interested in working with it, give Zend a try if you haven't yet, you will surely find it useful.

PS: I've been using their Zend Studio 4.0 Beta. I can't speak for 3.5 but I don't think it's that far in terms of functionality from 4.0. And, even though 4.0 is beta, I haven't had any problems with it , it's been pretty solid so far.

the daily wtf

I was just introduced to this site: The Daily WTF "Curious Perversions in Information Technology." I would start pointing to each good entry but I can't, they're all hilarious (or sad, depending on which side of the fence you're on). The main page is (as far as I can see) a blog-like rendering of the Daily WTF Forum from the forums on the site (check out the other forums too). Most excellent--subscribed.

update: setting up apache, tomcat, and mysql

One of the most visited entries from last year was my configuring apache 2 + tomcat 5 + mysql + jdbc access on linux and windows post. However, after a few months there was a change in the default Tomcat configuration (as well as changes in the connectors) that rendered the Tomcat/Apache connection part nearly useless. That is, it does apply to those specific versions, but no version of Tomcat after 5.0.18 (which is the one I used there) matches the description in the post, even though the Tomcat major version --5.x-- hasn't changed. Sigh. Those are the problems that open source creates sometimes, constant changes in tiny things, config or code, that break a lot of stuff without a clear reason (maybe there is a reason, but it's usually not communicated properly, or at all).

Anyway, I've recently done a new configuration using the latest tomcat, so here's an update to that post on that section. The other sections (that deal with Apache installation, MySQL and so on) have remained largely relevant.

The tomcat config

As far as tomcat itself is concerned, the main change was the configuration for the Context. My post says that you should look for the line "<Context path="" docBase="ROOT" debug="0">" which in the newer default server.xml config files doesn't exist anymore. So where does the context line go? It turns out that the new server.xml includes a default config for a Host. Within the host there's a Logger element set up. After that is where I've now included the context path. Similarly, I've added a Resource tag after the Context for the JDBC connection. Summarizing, After the Logger tag in the Host I've added the following:
<Context path="/appPath" docBase="APACHE_DIR/htdocs" debug="0" reloadable="true" crossContext="true"/>
<Resource name="jdbc/mysql"
auth="Container"
type="javax.sql.DataSource"/>


The connector config

I'm still using JK2. The main difference is that instead of adding the connection point in workers2.properties I am now adding it in jk.conf (which I think is a new file in the recent versions of jk2). I added the following line at the end of jk.conf

JkMount /appPath/*.jsp ajp13

Note that "appPath" is the context that was defined above.

So, I think that's it as an update. It's not a huge difference, but judging from my experience (and from emails I keep getting on the topic) this was more than enough to complicate usage of the old instructions.

Configurations are always a problem, no matter how many HOWTOs you've got, but I hope this makes things at least a bit easier!

web technologies: a first step towards biomimetism?

Reading Jon Udell's comments on his recent conversation with Adam Bosworth (and Jon's own musings on Alchemy and related ideas: a next-gen client that would include an XML store and the means to manipulate it) I suddenly remembered a conversation I had with Russ last weekend about the usage of tags: Flickr's, Technorati's, Del.icio.us', everyone's. And I started to think about how all of this stuff is emerging at about the same time, and not by coincidence. This is all related.

It seems that I'm pulling the connection out of thin air, but not really. Consider the infrastructure on which the most innovative apps are currently being built.

What I'm thinking is that, through web technologies (by which I mean DHTML, Javascript, scripting, XML, REST, etc), we've spent the last few years walking back from decades of "hardening" of runtime environments and development tools, and consequently of applications.

By "hardening" I mean static checking (of which Java is a good example), fairly strict runtime checking, strict parameter and I/O checking, etc. The cost of which is, of course, the need for a fairly complex environment in whi