The China Vortex

If you are interested in the kinds of social networking applications Chinese are now using today, David Feng offers some ground-level observations in this article. I’m a great fan of first hand research and observations and David offers some excellent observations.

Maybe it’s been a reaction to some of media coverage of everything which has been going on with the coverage of China and Tibet, but I have been diving into technology lately. Specifically, I have been digging deeper into Apple’s frameworks for development on the Macintosh and iPhone platforms.

Here are some of my observations:

– Everything’s an object, and everything’s object-oriented. Think of actors on a stage, and passing data to objects, which act on them. All the time.
– The MVC (model, view, controller) analogy is used throughout, which makes it natural for Macintosh developers to make the leap over to Ruby on Rails development and other non-Ruby frameworks such as Django;
– While Microsoft has worked on developing new languages such as ASP.net and C#, Apple has stuck with one: Objective-C, which has roots in NeXT and OpenStep. (For instance, all classes begin with NS. What does NS stand for? NextStep.)
– Apple’s efforts, in contrast with Microsoft’s, has been on developing frameworks;
– Think of the frameworks as sandboxes which Apple provides for you to play in, which you can gradually grow and develop with, and then later contribute to;
– Cocoa and Cocoa Touch are frameworks of classes, all based on Objective-C. You use these classes to instantiate your objects;
– Instead of thinking about writing code, you spend more time thinking what you want your objects to do, and objects messaging each other;
– Apple provides many sample applications and their code. You learn by making minor changes to the code and seeing what happens;
– There is a small and very dedicated community made of Apple developers. Very smart people.
– The documentation is REALLY good, and includes videos which you can download into iTunes, online documentation, and documentation in Xcode, the development tool. It is clear, sharp, concise and jargon-free.
– Every Macintosh ships with all the development tools you need, including Xcode, Interface Builder and Dashboard so that you can develop native apps or web apps right out of the box.

After some play with it, I’ve come to the conclusion that part of the reason there are relatively few developers working on the Objective-C/Macintosh/iPhone platform is because it completely rejects procedural programming as a development model. In fact, procedural programming would most likely be a handicap in shifting to the Macintosh programming model because it basically requires programmers to relearn a new programming model.

If you embrace object-oriented programming and agile development as a model though, it’s the best.

Technorati Tags: agiledevelopment, Apple, cocoa, cocoatouch, Dashboard, development, Interface Builder, Macintosh, microsoft, next, nextstep, objective_c, openstep, rubyonrails, sns, socialnetworking, software, Xcode

I have been spending some time researching Ruby on Rails, how it works, its development philosophy, and how it has affected web development, and will affect business in the near future.

The Ruby on Railsframework was released by David Heinemeier Hansson(it’s open source) in July 2004 has had a profound effect, and has been especially important in the development of the Web 2.0 movement.

Most importantly, Ruby on Rails simplifies the web development process through its “convention over configuration” and “Don’t repeat yourself” it fundamentally changes the role of the programmer in web development. Instead of asking questions like “How do I get function x to call method y?”, he is able to focus or how to do something, he is freed to focus more on the general business logic of the application.

This is why Ruby on Rails and the Agile software development movement go hand in hand. The Agile movement places a premium on human interaction and communication between programmers and business experts over software tools, process and methodology. The relationship between the Agile movement and Ruby on Rails is most clearly defined in the book Agile Web Development with Rails. Although the book is written for programmers, an intelligent lay reader and business person can also get a lot out of it, and understand the business implications of Agile development for web application development.

What does this mean? Basically, web application development as it is done by most businesses today is broken. Here are the two most common approaches:

• Designer-driven development. In this model, the client is non-technical and is more focused on “look and feel” than functionality. The web design firm uses Photoshop and Fireworks (or similiar applications) to create mockups to show the client. When the client finally selects the look and feel he likes, it is then handed over to the front-end developers to start coding the HTML, CSS, JavaScript and Flash files as necessary, while the backend developers create the databases and tables, and finally hook up the backend to the assets. The problem which happens when the website is prototyped, the client inevitably wants to make changes to the look and feel, and sometimes functionality. Changes to look and feel mean that assets have to be found, destroyed, created and moved around. Changes to functionality mean that new databases and tables have to be made and old ones destroyed. On the business side, this means that the projects inevitably go over budget, and often the client and web design end up in an unfriendly state of affairs.
• This is backend driven by database developers and developers who have good database and networking experience, and focus on creating the databases and tables, with little care, and often even less interest in the look and feel of the website. The most frequent result of this is a website which works fine on the functionality and business logic level but is butt-ugly. In projects of this kind the designers come in to mount rescue jobs, trying to turn a website only a mother could love into something which does not scare visitors away. In effect, the designers end up playing the role of the cosmetic surgeons in “Nip/Tuck”. Sometimes it works, often it doesn’t.

For a non-technical client more interested in creating a working application from the user point of view, this constant back and forth between client-side (front-end) design and backend programming throws them off completely from their established business goals. This is frequently made worse by the whole process: The client gives a brief then goes away, comps are submitted for approval by designers, then they go away, then the whole completed web application is shown to him, and he is expected to sign the check for the final payment with very little recourse if he is not pleased with the results, and all changes incur extra charges.By the time they have finished the project and made their final payment, they are often walking wounded.

Obviously, there is something very wrong with this development process. The designers get frustrated by limited client feedback until the project is nearly completed, the programmers get frustrated when the client changes the business logic, and the account people get frustrated at everyone, including the client.

This is what the Agile development process attempts to address. Basically, the client is asked to be fully engaged throughout the development process, sitting with the developers throughout and providing feedback all the while through while the developer is programming. The client can makes changes at anytime, and the website can even be tested in production mode to get user feedback, and more changes are made.

How is this made possible with Ruby on Rails? Since RoR is a framework, it creates default folders or directories in a basic configuration. The business logic is fixed by the MVC (model, view, controller) multitier architecture so that if the client wants to make changes, it is very easy to do so since the relevant files will always be in the same folders. There is no need to worry about where to find files to make changes. This design philosophy fits in very well with the web standards movement, which has focused on separating client-side development into HTML for structure, CSS for presentation and JavaScript for behavior on the browser side.

So how will Ruby on Rails change the role of the developer? It will no longer be enough for a programmer to be only a coder; a good developer will also have to understand business goals and user experience. With its emphasis on convention and process simplification, it is very likely that some of the best developers will come from client-side programming, while the best programmers will be those who have worked in business and understand business goals.

Does this mean that budgets for development will go down? In many cases it will probably be “yes”, but for developers who know how to understand communicate with their clients, and understand business, it’s more likely that their services will be especially in demand, and their fees will most likely go up.

Programming will be taken out of the lab, and it may well be that if you see two or three people sitting together over a notebook computer (most likely a MacBook Pro) in a cafe in Beijing, London or Pretoria, they are creating a new web application.

Technorati Tags: agile, agiledevelopment, application, business, clientside, clientsideprogramming, css, database, davidheinemeirhansson, designer, framework, html, javascript, opensource, rubyonrails, software, web20, webapp