Sunday, February 24, 2013

Ingrediences to be examined in order to cook up a good Xplatform mobile development stack ...

 Our mission:
           create "something",  that will help us to quickly deliver applications across various mobile platforms and devices.
 Requirements:
          reuse a vast amount of code base that we will pretend we have in place and we will pretend the business  code is written in .Net languages ,
          perhaps C#, F#.
          The fact is, many companies have written web applications in ASP.Net and desktop apps in C#.
          So, let's keep it simple and "profitable".

 Not all methodologies, frameworks or languages will be used in our effort. I have put together a shopping list and then  we will see how it goes .
 To understand cons and pros of the ingredients we are going to use or not, we should investigate and try to understand functionality of the stuff listed below:

  • HTML5
  • CSS3
  • Javascript
  • C#
  • F# (for financial and scientific computing)
  • LESS  (maybe?)
  • Coffeescript  (why not to bring fun to writing code?)
  • iOS, Android, Blackberry etc (not necessary but good to know)
  • knockout.js
  • Server Side Events
  • Javascript bridges to native code 
  • Rx.Net (in case we will use C#, this way we will be able to build Reactive UI)
  • Websockets (we can try to hook them up to Rx) 
  • XML (we already know it, right?)
  • JSON
In case I forgot to throw in anything, please, let me know




Cross-platform mobile development. New approach needed.

  A cross-platform mobile development is a mess. In order for a company to develop a money making application on different platforms, we need to hire either developers who know a particular platform (which means we have to start as many projects as many platforms we have to support) or we have to hire developers who know it all (which will mean the application will be of average quality).
 If we look closer to investigate the problem, we will see, that using a right design and architecture, it will not be a mess any more. The design is more important than the actual coding in any project .
Many methodologies, including Agile and similar flavors    are not applicable in this field,  because they prioritize "working progress" and customer immediate satisfaction compared to a solid design and architecture.
 Agile methodology delivers software very quickly, that's why we need JIRA and similar tools to track all these bugs that have been created in environments, where "DONE" is more important than "DONE RIGHT".
 What we need in order to successfully target multiple mobile platforms, is to slow down, sit back and have a cup of tea or coffe and start thinking... I will not be using "scientific" terminology on purpose, because terminologies are invented by people pushing for certain ideas. I don't like being pushed.
Many bright developers have created systems for Android, iPad, iPhone, Windows Phone , Blackberry etc. It is good, each platform has its strengths and these developers tried to squeeze as much as possible out of these devices. It is excellent and for games and specialized applications it is the only way - to go native.
  Most of us work for corporations, which are in business to make money, it means, they need to target as many customers as possible. One problem is, that all the customers are using different devices and they are not willing to buy another device only to be able to run our application. Most of applications developed by corporations don't need to squeeze as much as possible from particular device. In fact, they all are similar  The application takes input from the user, makes some calculation and possibly saves the result in a database.
 And of course, the company producing the software wants to use developers who can be easily replaced or hired. They simply don't want to invest in having Java, Objective-C, C++, C#, etc. experts to be able to develop one application and I don't blame them. It is sufficient to have experts in one of these languages, because then they can come and go and the company will not feel the pain.
  In this blog I will be playing with idea of creating a development stack that is good for most corporate applications.

 Stay tuned...don't go anywhere.




Sunday, February 10, 2013

IronGlue starts kicking ......

This blog is called IronGlue not by accident ... The Iron Glue symbolizes the fact, that software should be written to be solid like an iron and "glued" together so its iron "pieces" will not fall appart.
If these pieces will be glued together in an intelligent way, they can work in different environments and 
serving different purposes and still be the same pieces of iron .....