Full Disclaimer: I am not developing primarily for monetary purposes, since this is a side project it needs to be fun for me and I have been using .NET since the first beta.

iOS Development with Objective-C ~ circa 2009

Although architectural approach looked perfect on paper (use of MVC, clear separation of different responsibilities), the development experience with IDE and the language was a while different story. Simple things such as creating properties would require 3 disconnected steps, the libraries were a left-over from the Next Systems (NS-prefix on everything) and frankly for someone with Java/C# experience on a day to day basis it felt like I was going back in time to develop on a device. Long story short, I was not having enough fun to develop on the iOS to make it a hobby. I suppose since I was not quite interested in the monetary rewards that comes with iOS development, I lost interest and stopped altogether.

iOS Development with Titanium ~ circa 2009/10

Then I used Titanium to see if it was possible to come up with a simple application using JavaScript for behavior and a JS like layout language. Yes, it was possible and it was pretty quick too. I actuallly published one application. However, since Titanium was an abstraction on top of the native API, certain lower level things were not quite accessible. It remains a viable option to create a form over data type of  application within a couple hours, but for games and more complex applications it was not really a good candidate in my opinion.

Andoid Development with Titanium ~ circa 2009/10

While I was at it, I figured it would be interesting to see if the same code-base I used for iOS using Titanium would compile and run on Android. Unfortunately the experience was not that great. Credit to Titanium folks who really try hard to create a consistent cross-platform compatible API and I admit that it is a very hard problem get 100% right and make everyone happy. 
Although 80% of the code-base just worked fine, certain things kept just crashing and I was not too keen on isolating every single issue and then forking the code, so I stopped there.
Android Development with Java ~ circa 2010
After the not so successful try with Titanium on Android, I went ahead and started looking into Android SDK. Farnkly, I love the architecture. It is well thought and makes complete sense to any programmer who looks at it for the first time (unlike the iPhone SDK). I created a couple of prototypes and deployed onto the emulator everything worked fine and I was happy. Since I did not have an Android device at that time, I did not test on the device. The only thing that I did not like about this was how slow the Simulator was and each compile/deploy took forever on a reasonably good machine (dual-core, 4GB ram etc).

Windows Phone Development with Silverlight: ~ 2010

When they announced Windows Phone 7 SDK beta prior to the device launch, I did not pay much attention to it. Then one day, I realized it was using Silverlight. Since I had used Silverlight on a couple of projects I had a good idea on how to get started on it. I downloaded the SDK and within 6 hours I had ported the game done in Titanium over the course of 2 weeks. I have to admit that C# and Silverlight with Visual Studio are my comfort zone. That probably has much to do with the fact that it took so little time.

One thing that was not too exciting on the Windows platform was that it is way too simple to get started and create the apps just like the VB6 days. Stuff everything into the UI control handlers and let the code execute in the UI thread and eventually lock the thread by doing web-bound I/O.  Hopefully, certain frameworks that are available out there will emerge and somewhat force developers to use the MVVM pattern when developing apps on the WP7.
As per gaming experience, I certainly love the XNA model. It was my first introduction to XNA with WP7 and it is very simple to grasp and run with. I definitely recommend looking into WP7 with XNA to all developers who are trying to get into game development.

Conclusion

In my experience, working with iOS using the intermediary language/platform such as Titanium was a good enough way to create some line of business apps or simple things. Android has a great SDK but really suffers from JDS (Java Development Syndrome) on the windows stack – hopefully Linux environments are faster/more stable, and Windows Phone 7 development is the easiest for existing .NET developers, has great IDE/environment support.
I am really hoping to use MonoTouch and MonoDroid in the next couple of months to see if cross-compilation/execution of mobile apps is possible with C# or will people have to wait for HTML5 to be available on all platforms.

However seeing Bob Parsons kill an elephant in Africa while making the entire village wear GoDaddy hats was something I really could not stomach. So effective today, I will start moving my domains away from GoDaddy (about 60 of them) to another provider like NameCheap.com.

For those of you wondering how you can do this quickly (through the complicated UI that GoDaddy has that practically makes this impossible) here is a guide on how to switch your domains from GoDaddy to another provider.

I hope many follow the lead and do not put the $1-2 year savings every year above some good ethics both as a person and as a corporation.

Even if you hate them, tablets are here to stay. They cater to the needs of most people who want to just digest information from the web on the go. Nothing ground breaking here so far but let’s take a look at how this information is actually different…

Some of the most common tasks performed on the tablets are:

1. Watching videos
2. Flicking through pictures
3. Reading the news/magazines
4. Consuming social content (mainly looking at bits of text from your updates and sending out bits of updates)

Do you see a trend here? The amount of input required to complete these actions are at most 2-3 taps on the screen. This is the key to designing any user-acceptable software for the tablet: reduce the input to output ratio with considerable think time between user inputs.

Let’s look at some examples of this in games and apps:

1) Angry Birds: carefully calculate what you think might happen, set the bird free (or on fire!) and just observe the impact.

2) Words with Friends: think about the word you will form and then put the tiles on the board with 4-5 taps

3) Facebook: browse through pictures of friends and latest status updates.

4) Twitter: read the tweets of people you follow

This is exactly why I cringe when I see applications like “focused writing” on the iPad. I just cannot possible imagine an adult sitting down and trying to type more then 3 sentences on a 10″ iPad while covering the lower part of the screen with a keyboard, making sure that there are no typos and then with the rest of the attention she has left focus on what she was actually trying to type. Tablets are meant to be information “consumption devices” where large amounts of data are distilled into smaller bits and the user quickly consumes the data and moves on.

This is right in line with how the society behaves in the past 20 years. The progression of people reading books to blog posts to 140 character messages shows us how much majority of  people value snippets of shallow information over deep thinking about a particular topic.

The actual work of creating the content should mostly be left to other input devices. So next time you start thinking about the scope of that tablet app, make sure you let the user consume more than he produces.

 

In recent years, chip manufacturers have stated that CPU speeds cannot continue to increase. Instead, hardware manufacturers have begun to create chips with more cores, making them available on lower-priced hardware. The responsibility now falls to the software industry to take advantage of these multiple-core processors.

There are currently a plethora of parallelization frameworks available that take advantage of the multi-core machines. Most examples, however, are focused on more scientific or computationally intensive operations such as dealing with prime numbers, ray tracing, or working on matrix operations. Although these are great ways of utilizing the extra horsepower that multiple cores provide, they certainly do not directly help the average enterprise application.

Unfortunately, enterprise development has traditionally not required a multi-threaded development focus for the majority of applications. Consequently, development teams in most enterprises are not well versed in multi-threaded programming. Therefore, just introducing the requirement for parallel I/O via multi-threaded programming with no automated guidance in the form of frameworks and tools is a recipe for disaster.

In this whitepaper, we look at how developers can take advantage of multi-threaded code to reduce the response time of an expense application by 70% by simply applying parallel I/O concepts without changing the current code structure or requiring new training for the development team. Through the use of a parallel I/O framework, development teams can create multi-threaded applications without having to deal with the complex programming of multi-threaded code.

Click here to read the rest of the article…

Below is an excerpt from the paper.

“Health care is one of the determining factors when categorizing different countries on development scale. Based on availability of health professionals, education system, infrastructure capabilities and finally available government funding, the quality and reach of health care varies greatly from one country to the next. Today, depending on one’s location and socio-economic status, the amount and quality of health care available ranges from non-existent to intensive and close monitored…”

You can download the paper in  PDF or Word.

Unfortunately, however existing systems that were architected for web applications does not scale well to serve the requirements of multiple mobile clients.

In short here are some key points from the presentation:

1. Cloud computing is the key enabler of scaling architectures for new mobile solutions
2. User Experience is key when designing a mobile solution
3. Analyze your users, not all of them are on the same platform. Create different applications for different users instead of creating a monolithic applications with menus and options
4. Touch UI is a minimum requirement today
5. Responsiveness of the touch interface determines the usability of the application
6. Responsiveness on the client is achieved by introducing asynchronous client development
7. People who use your mobile solution will have short attention spans, break-down your workflows into smaller activities that can be completed within a couple of minutes
8. Limit the text input to a minimum, use selection based data entry as much as possible
9. Platform choice is key but some of the determining factors are: Internal/External Deployment, current skills of development team, market share of the platform, form factor and screen resolution of the target platform

Above points mostly talk about the client aspect of mobile development. The server aspects were covered in great detail during the presentation.

Netflix apology

Not that 3% really matters on a $10/month account but this shows what customer satisfaction means to Netflix. Once again cementing my loyalty to their service, good job Netflix!

In recent years, health care providers, insurance companies
and health applications have all been collecting mountains
of health-related data in various electronic formats. The
ability to search and analyze this data in context is required in
order to prove it worthy of the effort of collecting it in the first
place. One big challenge that stands in the way of ubiquitous
health information is the data format disparity between different
systems. It is not uncommon today to see legacy applications that
are using older standards such as flat text files, HL7, CCR …

You can read the white paper on Netsoft USA’s web site by clicking here.