Photoshop turns 20 If a product becomes the synonym for what it represents- that is the ultimate definition of success.

This picture is photoshopped. You know what that means.

The software applications blows out 20 candles - much software development respect!

Read its history here.  ¶ 15:08 0 Comments

  On Client Platforms Suppose you are going to develop your next application that needs to run on an as broad selection of user's client devices or computers, what development platform are you going to target?

There are a lot of client platform possibilities that a developer can choose to develop their application for.
All of these client platforms have their technical and business merits and drawbacks.

In this post I give my take on some of the major possibilities, feel free to comment or send in your thoughts!

Note:
I list the main points is three categories:
The Good: are properties of the technology that are a clear advantage
The Bad: are properties that are limiting or stumbling blocks, and cannot be overcome
The Ugly: are properties that are limiting or stumbling blocks, that can be overcome or mitigated by the developer of the application

1. Native Application
An application that the user installs and runs on their computer/device.
For instance: native Windows application

The Good
-integration in the overall user experience of the OS (or hardware: f.i. iPhone), native look and feel
-performance
-both an on-line and off-line solution
-mature development environments
-large ecosystem of 3rd party library/components

The Bad
-locked to a specific OS/device, for each OS a version needs to be developed
-application needs installation, possible roadblock as sometimes not even allowed (f.i. corporate policy)

The Ugly
-updates: need to be installed each time per user

This platform is mostly pushed by Apple, and Microsoft

2. Flash application
A application that runs on the Adobe Flash runtime in a browser.

The Good
-OS/browser/device independent
-large installed base of Flash runtimes (see: riastats.com), shrinking slightly
-no installation required, if plug-in is available
-updates easy, app is downloaded each time

The Bad
-browser plug-in needed
-some platforms not supported (f.i. iPhone)

The Ugly
-performance
-good integration in OS is challenging (no native look & feel; local file access, etc...)
-technically challenging to implement all required functionality
-development tools are so-so
-lack of large ecosystem of 3rd party library/components
-flash blockers, user apathy

Biggest supporter for this is Adobe.

3. Silverlight application
A application that runs on the Microsoft Silverlight runtime in a browser.

The Good
-OS/browser/device independent
-no installation required, if plug-in is available
-updates easy, app is downloaded each time
-mature underlying technology (.NET subset)

The Bad
-browser plug-in needed
-small installed base, but growing (see: riastats.com)
-some platforms not supported (f.i. iPhone, Linux)

The Ugly
-performance uncertain
-good integration in OS is challenging (no native look & feel; local file access, etc...)
-technically challenging to implement all required functionality
-Silverlight plug-in probably not installed, so user will need to do this
-lack of large ecosystem of 3rd party library/components
-user apathy

This pushed heavily by Microsoft too, but with clear focus on Windows.

4. HTML/Javascript application
A application that runs entirely in a browser, using Javascript and HTML

The Good
-OS/browser/device independent
-only a recent browser needed, virtually available everywhere
-large and growing ecosystem of 3rd party library/components

The Bad
-no local storage of files
-basically an on-line only solution

The Ugly
-performance
-there are technical limitations on what can be accomplished with HTML5/Javascript
-development environments non-existent
-good integration in OS is very challenging
-technically challenging to implement all required functionality
-some popular browsers (Microsoft IE) lack modern Javascript/HTML5, so graceful fallback needed
-Javascript + HTML not so elegant combo from a software development point of view: impact on maintenance, debugging, etc...

This is a methodology that is being pushed by Google.

5. Java applet
A application that runs on the Java runtime in a browser.

The Good
-OS/browser/device independent
-no installation required, if plug-in is available
-updates easy, app is downloaded each time
-mature underlying technology (Java)
-mature development environments
-large ecosystem of 3rd party library/components

The Bad
-browser plug-in needed
-unpredictable installed base
-some platforms not supported (f.i. iPhone)

The Ugly
-good integration in OS is challenging
-Java applets seem to be a dying platform

This was push somewhat by Sun, taken over by Oracle now. New follow-up tech JavaFX didn't catch on.

There are of course various others: Adobe AIR (need specific runtime installed), Java application (also special runtime needed), XBAP, Prism, etc...
But I wanted to focus on the main important ones.  ¶ 14:51 0 Comments

  Speed matters Facebook uses a lot of PHP, and given the scale of the service, they must be watching performance very closely.
Bandwidth and infrastructure will be their main costs, so it makes economic sense to try to run as much of Facebook on as little infrastructure as possible.
And one of their tools they have announced this week: HipHop.

HipHop is a toolchain that preprocesses PHP into C++, which can subsequently be compiled by a C compiler, and then used with their webservers. Facebook says they are seeing a 50% increase in performance.

This is beautiful engineering: they can now run double the load on the same infrastructure.

Evangelists always cleam that dynamic (or interpreted) languages are a win-win.
You win on ease of use, as a dynamic language is easier to program for, easier to debug and easier to maintain.
And you supposedly win on performance, as they run as quick as compiled code.
The latter is never true in practice, no matter what complicated theoretical explanation they always give to say it really is so.

There are numerous real world examples:

• Google wants you to use a Java-like on Android Phones, but if you want it to go fast, use C and compile to binary. (a brilliant video to drive the point home here). Java is not fast, using it on a small phone cpu is a challenge.
  
• Apple supposedly have written their first iPhone widgets (time, weather, stocks, etc...) with javascript/html - but decided to rewrite them in Objective-C because performance was poor
  
• Windows Vista contained a lot of .NET during development, but that was ripped out and changed to native x86 for speed reasons.
  
• Using PHP based Wordpress for a large site is only really doable when you use static caching, and do not run PHP at all for most of the requests.
  

A lot of the evangelism for dynamic (and interpreted) languages is like marketing propaganda; they sell you a dream, but a lot of dreams do not survive a confrontation with reality.

The fastest and most efficient way to run code is to use the least amount of the best instructions for a given cpu.

Speed matters in the real world.  ¶ 08:53 0 Comments