February 2009 - Posts

Tracking moved files: An interesting tidbit on file references in OS X
13 February 09 11:14 AM | mrdecav | 2 comment(s)

Today I had to help someone with a problem with iTunes on Windows.  For those of you that have not had the pleasure of using iTunes on Windows, it sucks, like most software written by Apple for Windows.  That being said, this problem really had nothing to do with iTunes.  The problem was that iTunes was 'losing' music.  As it turns out, the music that the user saw as 'lost' turned out to have been moved from its original location (the desktop) to the 'Music' folder.  iTunes uses absolute paths in its media library to hold reference to the file.  When the file moves, the reference is broken, and thus, the music appears 'lost'.  Without iTunes open all the time (and due to the occasionally unreliable file system watcher), it is simply not possible to track these files.

But then I started wondering... Surely Apple wouldn't let this happen on OSX.  Details like this tend to be a place where Apple shines.  So what in the world does iTunes do if I move something from the 'Music' folder to my 'Desktop' in OSX.  I decided to try.  First I closed iTunes, then I copied a music file, went back to iTunes, and hit play.  Low and behold, it played, no problem.  Not only did this leave me confused, but it also left me interested, so I decided to do a little exploring...

From what I can tell, Apple foresaw this problem with their 'aliases' early on in their original Mac OS, so rather than referencing files by path, you can reference files by a unique ID (if they are on a partition that uses a supported file system).

I'm no expert on Cocoa, but from what I can tell, the details of this can be found in the File Manager APIs and FSRef.

And for some more interesting reading on the topic.

So next time you get the dreaded 'cannot find the target to this shortcut, do you want to try to find the file?' prompt, just think about those 1980's Apple employees and how they solved this problem...

Filed under: , ,
The Browser Love Affair, RIA and JavaScript as the 'new byte code'
12 February 09 06:42 PM | mrdecav | 8 comment(s)

Jump to a section of this article:

Why do consumers love the browser?

One of the things I still have not fully understood is the consumer's affection for the browser.  Unlike desktop applications, consumers seem to feel more comfortable and safe in a browser.

Perhaps it is the familiarity, always knowing where you are with a URL, the 'safety' of not messing up your computer, the security of having data stored in a cloud where it doesn't need backup, or the easy way to get away from where you are with the back button.  Add to this the familiarity of having an interactive 'page' over a bunch of forms and dialog boxes and popup windows, and the element of design and simplicity on the web, web developers were quicker to embrace a "less is more" approach, and web pages are typically thought through and designed by professional designers more often than desktop applications.

When you take all of these things into account, it makes a bit of sense why consumers have shown a preference for web based applications, and it is no surprise that most of the WPF applications we've seen emerge have followed the same basic browser concepts (back button, page like UI, navigation at top, hyperlinks, etc).

For someone who tries to stay away from web development, my recent past has been riddled with all the latest buzz-words on the web - Silverlight, Flash, AIR and JavaScript are all tools that I've had to engage with.  I've built trading systems in Flash and my most recent application is RIA in HTML + JavaScript...  None of these platforms have had the allure of WPF for me, the developer, but its what clients have asked for, and clearly what consumers are interested in.

 

Who is winning the war in RIA (Flex, Silverlight, HTML+JavaScript)?

Why is it that we feel the need to place browser chrome around everything, and when we do, what platform has emerged as dominant for the new breed of complex applications (Google Maps, docs, etc) that we've come to expect in the browser?

With out a doubt, HTML and JavaScript has been a hands-down winner.  Why is it so hard to name a single site that is a pure Flash or Silverlight application.  HTML + JS is certainly not easier to program, and Flash is now ubiquitous, so the concern of requiring a plugin is not there, is there something about interacting with the native browser, not a plugin, that has some appeal. 

I have become a firm believer that as a non-software company, it is your interest to leverage Microsoft-based development technologies as much as possible.  The ability to quickly get things done in .NET and its surrounding technologies is unparalleled.  When you are a software company though, it is much harder to justify.  Tying yourself to Microsoft, one who likely is or will become a competitor in your space is risky.  Hiring good web people (if you're a web startup) is harder because the .NET development culture tends to do things "the Microsoft way". And your acquisition story becomes limited (Google, eBay, Facebook, etc is less likely to by a .NET based system because it doesn't fit in their infrastructure).  For this reason, it may be clear why Silverlight is and will not become the dominant application platform on the web any time soon. Perhaps many web companies have the same fear of Adobe Flash.  By contrast, HTML and JavaScript is "open" and is not dominated by any particular entity.

The decision of most web companies to stick with HTML, despite the rich features of other platforms, is simply a business decision.  HTML will always be there, is relatively reliable, relatively backwards compatible (Adobe is pretty good at breaking builds of older code with newer versions of Flex), and does not tie you to the whims of any one company or platform.

 

JavaScript as Byte Code - C#, Java, etc to JavaScript Compilers and Cross-Compilers

HTML is great for document layout.  Its fast, clean and everyone knows it.  Sprinkle a bit of JavaScript on that, and you have a nice interactive document.  But HTML was never designed to be the basis for an application platform, and really is a pretty poor application platform.  But despite the features of other platforms, and the number of times HTML and JavaScript is pronounced dead, something breaths life back into it.

It started with FireFox, and continued on with the awefully impressive Google Maps.  Google has a large interest in keeping the browser alive and relevant.  The longer it does so, the longer it has a platform on which to compete with Microsoft that is already deployed to 99% of the world's user base.  A "Google Flash" may not be feasible, because of the deployment nightmare involved, but as HTML evolves with offline capabilities, richer CSS and faster JavaScript engines (see Google Chrome), it becomes a platform that can largely compete with the rest.

And for this reason, Google has cleverly turned the browser into their own RIA platform.   The "Google Virtual Machine", as you may call it.  To do this, they've leveraged the existing tools that Java has to offer, and created Google Web Toolkit - a Java compiler that can compile Java into cross-browser JavaScript.  And on the client side, they've added Google Chrome.  You can easily consider Google Web Toolkit and Google Chrome to be a full RIA platform, with JavaScript as the byte code transport.  And not only that, but its an RIA platform fully backwards compatible with the existing deployed base of browsers.

Perhaps the most interesting thing is that Google Web Toolkit is not the only JS or cross-compiler.  A variety for compilers have been built for this purpose.  Microsoft Research has Script#, which compiles C# to JavaScript, and a bunch of projects use JSC, a cross compiler that compiles MSIL into JavaScript (and therefore any .NET language).  With a whole variety of tools out there by different vendors to compile to JavaScript, it appears that JavaScript has become the new universal byte code.  It can be processed by a whole variety of browsers, and produced by a variety of tools - one of the only computing platforms that that is true for.

And compiled JavaScript can also be pretty fast and make applications that are rich and look good.  While it doesn't compare to the offerings of Cocoa, WPF or Silverlight, the quality of application that can be achieved is good enough for most consumers.  In the case of GWT, it is not only fast, but also efficient - and best of all, code can be shared amongst client and server.

 

I don't like HTML as an application platform, and I am not very fond of running every application inside the browser chrome.  But as business strategy and deployability have become increasingly important to me in my recent venture, an RIA application based around the native browser has become my platform of choice.  Cross compilation, in my experience, has proven an effective way to make a very rich client that can even handle push-data.

Filed under: , , , , , , ,
On Compensation in Finance
05 February 09 10:55 PM | mrdecav | 4 comment(s)

This post is part of a series of essays on things unrelated to software development. You can find all the essays here.

The compensation structures on Wall Street have long been criticized as excessive, lavish and unnecessary.  Banks have consistently justified such salaries, noting the executives being compensated brought in big earnings for the bank.  When the bank balance sheets were positive, there was little incentive to attempt to correct the salaries, however with most banks now in dire straits, many have begun to take a more firm tone with banks.

This concern was underlined this week by Obama’s new government enforced incentive cap of $500k per year for top executives in banks receiving federal aid. While Obama has found a significant problem in banks, their compensation structure, his cap is not only horribly low, but may also have a significantly negative effect on banks.  Without that ability to recruit top talent into executive positions, banks will have more trouble hiring than the offices of Mr. Madoff.

Free markets tend to assume that people will do what they consider in their best interest.  Consider a classic example of a big, blue lake, full of fish with multiple fishermen.  If the lake is a public entity, it is in the interest of each fisherman to collect as many fish as possible, without regard for environmental impacts or long-term sustainability.  If they do not, the other fishermen will fish the entire bounty from the lake, draining it of their resource, and they’ll be left with nothing.  If each fisherman owns their own portion of the lake, however, they will want to sustain their portion of the lake for future years, to ensure long-term prosperity.

The banks have begun to look much like the overfished lakes of Wall Street.  With huge annual bounties, and little incentive to maintain the overall value of the organization, traders, bankers and executives alike have taken large risky bets at expense of the the organization, in effect hollowing out their balance sheets.  Large bonuses rewarded short-term harvests, and threatened long-term prosperity.  Even with some compensation supplied in stock options, the incentive to make a few large cash bonuses and move on was so great, that it simply eclipsed the interest in ensuring a banks long-term viability.

Compensation structures should provide incentive for employees to ensure long run profitability over short-term profits.  The most obvious way to accomplish this is to lower annual cash bonuses and increase the use of instruments that mature over time, such as stock options.  Employees who receive bonus compensation based on the performance of the company in five years are more likely to ensure that the organization maintains long term profitability, and is less likely to take risky bets that undermine the banks sustainability and performance.

Obama is right to point out the broken compensation structures on Wall Street, but the amount of the compensation on Wall Street is not the cause of current economic woes. It is the form of compensation and how that from makes people act.  Obama should not be looking at limiting overall executive pay, but rather rewarding success in solidifying a firm over the long run.  If a salary cap is necessary to push a bill through congress in the short term, a bonus structure should be provided for any executive who has been instrumental in restoring confidence and a positive cash flow to a bank.  Change in the way banks provide incentive to their employees is necessary, but populist politics should not get in the way of proper reform.

Filed under: , ,
More Posts