Two interesting acquisitions were announced today, one exciting, one disappointing.

First, the exciting one.  Apple acquired Siri.  I've used the Siri app for the iPhone, and was very impressed.  It attempts tries to be your digital secretary, and actually does it quite well.  It abstracts you away from how it finds out information, and just presents what you want to know.  It works great for the simple cases so far, and I think over time will become very good at much more.  For Apple, who I believe is focusing on making computers into appliances, this is a great fit.  As I discussed in my post about the iPad, I believe the next evolution of the computing space is creating computing appliances, not computers.  Thinking of the iPad as a computer with a touch screen instead of a computer with a keyboard is wrong, just as thinking of a TiVo as a computer with a video capture card is wrong.  Yes, both analogies are technically correct, but they both miss the point.  Both are computing appliances, not computers, and the rules and expectations for them should be different.  I'm very excited to see what Apple will do with Siri.

And now for the disappointing one.  HP acquires Palm.  Palm was once a great company.  They nearly single handily created the PDA (Personal Digital Assistant) market, with the Palm Pilot.  The Palm Pilot dominated the market for years, until the advent of smart phones.  Then they created the smartphone market with their Treo line (technically they bought Handspring, which was formed by the same folks), and extended their domination.  I was an early adopter back in 1998 and used Palm Pilots and Treos up until last year when I switched to an iPhone 3GS.

If was very excited about Palm's new OS, but in the end it was too little, too late.  If they had launched the WebOS/Pre a year before the iPhone came out, they may still be dominating the landscape.  And they certainly should have been able to do that.  The Palm OS was great in the 90's, worked OK in the early '00's, but was really showing its age by 2005.  They waited far to long to move to the next generation.

I don't see how being acquired by HP will change their position.  iPhone and Android are locked arm-in-arm for the smartphone market.  iPhone owns the proprietary walled garden space, and Android is the open, extensible choice.  Microsoft and RIM are still hanging around, mostly in the corporate market.  There just isn't room for Palm.

HP is not an innovative company today, and is more known for their existing relationships and sales channels than engineering.  While I don't believe any company could have really saved Palm, an acquisition by HTC or another up and comer in the space would have been interesting.

Google and Apple are at war.  Google entered Apple's 'home turf' with Android, and Apple is entering Google's 'home turf' with iAd.  There is no question that the war is on.

In most situations, competition is a great thing.  It drives companies to innovate and produce better products and services.  While that will certainly happen with their respective mobile operating systems in this situation, I believe these are two companies that would be much stronger working together.

Google and Apple are good at very different things.  Gruber nails it when he says:

No better comparison of the cultural differences between Google and Apple than to compare Google Docs and iWork. iWork has no form of cloud based syncing or collaboration; the appeal of the apps (both on the Mac and iPad) is that it helps you create beautiful documents. Google Docs is all about cloud-based syncing and collaboration; its example documents are downright homely.

Google is great at building services that scale.  Gmail, Google Docs, and Google Maps are all great services, usually with simple and effective interfaces.  Apple is great at creating intuitive user interfaces and well engineered hardware.  As an end user, I want my services provided by Google on hardware built by Apple.

More specifically, I want my web user interfaces built by Google, and my native applications built by Apple.  I enjoy the close integration I have on my iPhone between the Calendar, Mail, and Contact applications and Google Apps (which is ironically made possible by Microsoft's ActiveSync).  I like Google's web interface to Gmail and Calendar.  I want them both, and I want them to work together.

In my ideal world, Google would provide a service interface for these services, and a generic web interface that is accessible anywhere, on any (modern) browser.  Apple (and others) would provide native applications that utilize these services.  I want to be able to access my data using either the browser (provided by Google) or a native app (by Apple) on either my iPhone or MacBook.  I wish the Address Book application on my MacBook worked as well with Gmail as the Contacts app does on my iPhone.

It should work this way across all services.  iWork should be able to store and edit files on Google Docs, which could then be edited using the web interface as well.  Everything lives in the cloud, with the ability to cache local copies with the native applications (or advanced browsers).  

Unfortunately, it looks like Apple and Google are moving farther apart, instead of closer together.  It is clear that Google first 'invaded' Apple's space with Android, but Apple is certainly a company that holds grudges and is very aggressive.   Adobe knows this all too well.

As an end user, I'm afraid this is one area where competition may not produce the best result, but who knows.  Neither Google nor Apple are going away anytime soon, and they may both surprise us with what they do.  Let's just hope it is about creating better products instead of damaging the competition.

I recently published a Reference Card with DZone: Getting Started with Flash Builder 4.  The Reference Card covers the new features of Flash Builder 4 and includes a basic overview of Flex application development.  Check it out!

I enjoyed working with DZone to publish this card, and the editorial process was great.  I hope you find it useful.  Let me know what you think!

I'm a big fan of Google.

While I've written my own email server, I've adopted Google Apps for nearly all of the domains I manage.  Gmail is a great tool, and has freed me from the tendency to over-organize my mail.  I can now find things easier and quicker than I ever did using Outlook or Thunderbird simply using minimal tagging and the built in search functionality.

I've used Google Search, Google Apps (Mail, Calender), Google Reader, Blogger, Google Docs,  Google Code, Google Web Toolkit (GWT), and the Google App Engine.  Great stuff.

If it works.

However, if something goes wrong, it can be difficult to find the answer.  Your best bet is to Google for the solution of course.  Hopefully someone has encountered the issue before and can point you in the right direction.  If not...

I recently migrated my Blogger setup (for this blog) from FTP publishing to a Custom Domain hosted by Google.  The transition went fairly smoothly (as I documented here), and while I was a bit annoyed I had to change my setup, it was fairly painless and hey, the price is right.

But I ran into an issue with my RSS (Atom) feed.  I've been using Feedburner for quite a while to track the number of subscribers.  When I used FTP publishing I simply edited the template to point to my Feedburner feed.  However, now that I switched to hosted mode, I can't edit the template the same way.  So most new subscribers are using the base Google feed, not the Feedburner feed. 

Google does offer an option to handle this, 'Post Feed Redirect URL', with the description: "If you have burned your post feed with FeedBurner, or used another service to process your feed, enter the full feed URL here. Blogger will redirect all post feed traffic to this address. Leave this blank for no redirection." Of course, when I enter my Feedburner feed in this URL, I get the error: 'This URL would break your feed, resulting in a redirect loop. Leave the field blank to serve your feed normally.'  Based on all the reading I've done, my setup appears to be correct and this should work.  Faced with limited support options, I posted a question to Google's help forums.  I got a response that appears to suggest that something internally needs to be reset, but no help from any Google resources.  So, I guess I'm stuck.

Or course, you can point out that I'm getting what I pay for, which is true.  Blogger is a free service, and I'm not entitled to any specific level of support.  But that doesn't make the situation any less frustrating.

At least this issue is minor.  In the end, it doesn't really matter.  But suppose I had in issue with Gmail.  What would I do then?  Well, I guess the answer would be upgrade to a Pro account, and then demand support, but that is only because I'm using Google Apps instead a plain Gmail account.

The risk of free...

I believe that successful application development today is about 'tweaks and sub-features', not major functionality.  But my thought process for this post was kicked off by an interesting post by Mike Taylor: 'Whatever happened to programming?' Mike laments the evolution of programming.  He is nostalgic for the day when writing a program was about creating something from scratch, instead of assembling the various pieces.

I think his assessment of the transition is fairly accurate.  The number of frameworks and libraries in projects today far exceeds the number used in projects 5, 10, or 20 years ago.  This is especially true in the Java world, where build tools like Maven gained traction because they handled the dependency management.  And now, a non-trivial Java project can easily incorporate 100 or more jar files, while a trivial 'boiler plate' web application can easily have 20 jars.

In many ways this is frustrating.  It has also given rise to what I call the cut and paste programmer.  You can actually achieve reasonably impressive results simply by searching for the right libraries, and them assembling them together but cutting and pasting example code found via Google.

From a business perspective, these are all good things.  The level of skill required to produce results is lower, and the speed of development has greatly increased.  We are standing on a very tall foundation.

This also means that the major functionality of many applications is provided mostly by libraries and frameworks.  The heavy lifting parts are not really heavy anymore.  I think Jeff Atwood hits this nail on the head when he stated on a Stack Overflow podcast episode that the major features of Stack Overflow themselves are fairly trivial.  The real value is that it is a collection of many small features and tweaks that make the overall system successful (I can't find the reference, so I apologize if I paraphrased incorrectly).  I think this point is right on.  Most major 'features' are trivial to implement today using the rich set of libraries that exist.  Building a website that has questions an answers like stack overflow is trivial.  Making it successful is hard.  And the difference is all in the fine print.

Jeff discussed at some length the time they spent with the syntax parser (markdown) and instructions on the 'ask a question' page.  Small changes to how the information is displayed and highlighted are much more important then the major feature of saving the question to a database and displaying it.

Successful applications today are about the user experience.  There are very few applications that are truly innovative themselves and could not be replicated by gluing together a set of frameworks.

Real innovation today is in the small.  This is also why I believe that the rise of Appliance Computing is here, and that Write Once Run Anywhere languages are inferior to native client applications.  It is the difference between a iPhone web application and a native app.  They both have the same features, but the experience can be very different.  In the end, the real value is the small efficiencies in the application, not the large features. 

I hate file extensions on websites.  It is an unnecessary leaky abstraction, and is discouraged by the W3C.  All file extensions are not necessarily bad, but any file extension that exposes the underlying technology implementation is.  Any .pl, .php, .asp, .aspx, .jsp, .do, *.struts, etc extensions are B A D.

I've talked about this before, and come up with some workarounds to build extension-less java web applications before.

However, I've come across what I think is a better way, thanks to a post a couple years ago by Matt Raible.

I came across the issue using the Spring WebMVC DispatcherServlet.  I want all dynamic URLs handled by the Spring Controllers, using Annotations.  However, mapping the DispatcherServlet to /* means that every URL will be processed by the DispatcherServlet, including the .jsp views returned by the Controller.  As I mentioned in the previous post, you can 'unmap' content and have it handled by a default or jsp servlet in some app servers, but not all.

You can also try to map specific subsets of URLs to spring.  However, this is harder than it sounds.  By default, Spring will map the wildcard portion of the URL matched, not the entire URL.  So if you have /foo/* as your url-pattern, the controller with a mapping of /foo/one will not match /foo/one, but instead matches /foo/foo/one.

It appears that you can use the property alwaysUseFullPath to change this behavior, but it did not seem to work as expected for me.

Instead, there is a more generalized solution, as Matt suggested.  URL Rewriting.

The URL Rewrite Filter project provides a Filter that you easily define rewrite rules for, just like in Apache.  So I setup my DispatcherServlet to match *.spring, I setup a rule to rewrite all extension-less requests to .spring, and I setup my annotations to have the .spring extension.

Now my web application can handle the odd html, png, or other static files if necessary, but does not expose any implementation details in the URLs.  Perfect.

For reference, here are the relevant portions of my config:

Web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

  <filter>
    <filter-name>UrlRewriteFilter</filter-name>
    <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
  </filter>
  
  <filter-mapping>
    <filter-name>UrlRewriteFilter</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  
  <servlet>
    <servlet-name>SpringMVCServlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
      <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/your.config.file.location.xml</param-value>
      </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
  
  <servlet-mapping>
    <servlet-name>SpringMVCServlet</servlet-name>
    <url-pattern>*.spring</url-pattern>
  </servlet-mapping>
  
</web-app>

urlrewrite.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.0//EN"
  "http://tuckey.org/res/dtds/urlrewrite3.0.dtd">

<urlrewrite>
  <rule>
    <from>/$</from>
    <to type="forward">home</to>
  </rule>

  <rule>
    <from>^([^?]*)/([^?/\.]+)(\?.*)?$</from>
    <to last="true">$1/$2.spring$3</to>
  </rule>
  
</urlrewrite>

Sample Controller

@Controller
@RequestMapping("/foo")
public class SimpleDataController {

  @RequestMapping("/bar.spring")
  public ModelAndView bar() {
    ...
  }
}

If you want to develop a Google App Engine (GAE) application using Maven, you can either use the Maven plugin maven-gae-plugin, which requires non-trivial hacking on your pom.xml, or you can keep your pom clean and create a simple Ant script.

My pom is a simple web application pom, with no specific GAE configuration.  I then created a build.xml in my project root that looks like this:

<project>
  <property name="sdk.dir" location="/opt/appengine-java-sdk-1.3.1" />

  <import file="${sdk.dir}/config/user/ant-macros.xml" />

  <target name="runserver" depends=""
      description="Starts the development server.">
    <dev_appserver war="target/yourappname-1.0-SNAPSHOT" />
  </target>

</project>

Using this, you can run your application in the GAE sandbox without having it take over your pom.

You can also have the ant task perform a maven package to insure everything is updated by adding an exec target to the runserver task.

You can read more about the full range of Ant tasks available for GAE, but I found this simple script helpful to get up and running quickly in the GAE sandbox without much effort.

I have my house wired so that every television can access a shared set of sources (mostly).  I wanted this solution because everything I watch is recorded.  Therefore, I wanted to access each of my three DVRs on every television in the house.  Here is how I accomplished it.

First, I located all of the DVRs in the basement.  They are each run to every television in the house using different transmission mechanisms.  Here is a general overview of my system layout:

Most of the components are in the basement, with the exception of the disc based components (DVD Players and game consoles). 

The Basement and Family Room are in close proximity, allowing direct wiring of all the devices.  The DVRs are wired directly to the TV using Component and S-Video connections.  The sound is sent back to the basement from the DVD and game consoles using digital audio connections.  The speakers are wired directly from the AV Receiver in the basement.

The rest of the rooms require some alternative transmission mechanism.  For the Standard Definition (SD) televisions, I use a Channel Vision E4200 RF converter.  This devices takes up to 4 standard definition sources (audio and video) and modulates them onto broadcast channels.  I then combine the Antenna feed with the Channel Vision output and run it on the RG-6 that runs to each television in the house.  Now ever TV can tune to a channel, say 63,  and display the output from the SD DirecTV DVR.  I also have a Cat-5 run to each television with an IR Sensor.  This allows signals from that room to be transmitted back to the basement and be 'seen' by the components there.

For the second HD TV, I use a system from Audio Authority (Model 9871 + Wall Plates) to transmit a High Def (HD) component video signal, digital audio signal, and IR signal to the second room.  This system requires a converter box at the source and destination, but allows all of the signals to travel over a pair of Cat-5 cables. 

Here is an overview of the wiring:
The RF Modulator is a great solution for sending audio and video to SD televisions.  I even have an SD feed from the HD DVR so you can watch down-converted versions of the HD shows on any TV as well.

The Audio Authority system is great for transmitting HD video, as long as it is component and not HDMI.  See my rant against HDMI for more information.

I use a Niles IR system to capture/repeat the IR signals.  It has worked well, although there does appear to be a quality difference in the IR sensors.  Spend the money to get a good one.

For music I use my laptop to stream music to one of two Airport Express devices, attached to each AV Receiver in the house.  It isn't a Sonos, but it works.

I have a Harmony remote in each room setup to control the local TV and the DVRs.

Overall, I've been very happy with this setup.  It has been in place for over three years now and just works.  There are certainly other solutions to this problem, but I've been pleased with this for my needs.

In my previous post, I discussed the trend toward computing appliances (ie DVRs, Kindles, etc.) instead of general purpose computers.  On the recommendation of Merlin Mann on MacBreak Weekly, I downloaded the Siri iPhone application and gave it a try.  Wow.

The Siri application attempts to be the ubiquitous Star Trek computer.  Just ask it a question and it will give you the answer.  It provides both voice and text interaction modes, and an easy user interface that exposes common feature easily.

It won't do everything you want, and I'm not sure this specific application will be something I use regularly, but at a minimum it provides an interesting example of where the world is going.  Imagine using this with what I imagine will become ubiquitous Bluetooth headsets.  Just ask a question and have the answer spoken to you.  We are not there yet, but we're starting to get really close.

This is an example of what I consider the appliance trend, applied to software.  The application provides easy access to a common (if limited) set of features that are intuitive to use.

The iPad is an appliance, and it will be successful.  But before we get to that, we need to start at the beginning.

When I was a kid I ran a dial-up BBS service (The Outhouse) on a computer cobbled together from old donated computers and a few new parts I'd purchased.  I would take apart old computers (donated by my friends parents after their companies discarded them) and test the various parts for something I could scavenge.  I spent hours pouring over the massive Computer Shopper magazine to find the best deal on a new hard drive or modem.  This was the very definition of an (economy) do-it-yourself general purpose computer.

In my first two decades of computing I never purchased a pre-built computer.  I always assembled new computers from parts, or upgrade my existing computer (often replacing everything but the case and CD-ROM drive).  Pricewatch.com was my favorite site for a long time.

But along came a new device that started a big change, TiVo.  I bought my first TiVo around the year 2000.  It was something I could have built myself, but I realized that the convenience of having a dedicated appliance was worth the cost.  I just wanted it to work, and it did. Very well.

In the years since, I've been transitioning away from general purpose computers to appliances.  The Linux and Windows desktop/servers I used to run (24/7) have been replaced by a Linux based wireless router (Linksys WRT 54 GL) and a NAS (ReadyNAS NV+).  They provide nearly all the services the old general purpose computers provided with a few exceptions, and each of those exceptions have been moved to the cloud.  I've moved my website hosting and email hosting to the cloud using GoDaddy (< $5 month for web hosting) and Google Apps (Free).  They provide a better quality of service, at a minimal cost.  Along the way I migrated from writing and hosting my own email server (Java Email Server), to hosting email at GoDaddy, to free hosting at Google.  That is quite a shift in effort and cost.

The same progression is true with my other devices.  I now exclusively use laptops, and have not assembled a desktop more than 4 years.  I've also embraced Apple devices, which have more of an appliance feel than do other devices.  I use iTunes to manage my music, a couple of iTunes Airport Express units to listen to music on my stereos, and an iPhone as my mobile music device, and phone.  While one could argue that these are not really a change to appliances, I think they match the general trend.  Appliances provide a pre-defined (somewhat inflexible) experience that 'just works' as long as you stay in the provided feature set.  This is exactly what Apple excels at doing.

Finally, I've adopted a Kindle.  While I could read on a laptop, or an iPhone, this single purpose device excels at linear reading (ie Books).  I use it every day.

There are several reasons for this trend.  One is simple economics.  As the years go buy, I have more discretionary income, and more demands on my time (namely two young children).  The convenience of buying appliances versus tinkering has certainly changed for me.

I think there is more to the story though.  As the computing and home electronic fields mature, it becomes easier and more cost effective to create appliances that fit into our worlds.  Which brings us to the iPad.

The iPad is not the first device to attempt to move the general purpose computing environment to an appliance.  One could argue that it is really a descendant of the WebTV concept.  Take the primary activities people use general purpose computers for and put them into an appliance.  This brings up a brief and interesting digression...

Apple does not create markets.  Apple waits until a market is ready, and then delivers a product with impressive polish and ease of use.  MacBooks don't do anything a similarly priced PC can't do, they are just prettier and easier to use (or have been traditionally).  The iPod was not the first portable MP3 player, it was just better (including the iTunes ecosystem).  The iPhone didn't break new ground on smart phone functionality, it was just better (again, including the iTunes and AppStore ecosystem).  Finally, the iPad isn't new either.  Microsoft has had a TabletPC version of their Operating System since 2001.  The previously mentioned WebTV provided email and web browsing as an appliance experience.

Apple is attempting to build on these ideas, with Apple's traditional polish, iTunes ecosystem, and of course, Reality Distortion Field.  I don't know that version 1 of the iPad will be a success, but I am convinced that appliance computing will become a significant mainstream success.

Final Note to Developers: As Software Developers, we will always use a general purpose computer.  Just as a carpenter utilizes a set of tools to build a house, we will utilize a set of tools (ie general purpose computers) to build appliances.  Our goal should always be building applications in the appliance mindset.  My youngest child (2 years old) can turn on my iPhone and open her favorite puzzle game.  All of our computing experience should be this easy.