Software Integration

When embarking on a change, a developer takes a copy of the current code base on which to work. As other developers submit changed code to the code repository, this copy gradually ceases to reflect the repository code. When developers submit code to the repository they must first update their code to reflect the changes in the repository since they took their copy. The more changes the repository contains, the more work developers must do before submitting their own changes.

Eventually, the repository may become so different from the developers' baselines that they enter what is sometimes called "integration hell", where the time it takes to integrate exceeds the time it took to make their original changes. In a worst-case scenario, developers may have to discard their changes and completely re-do the work.

Continuous integration involves integrating early and often, so as to avoid the pitfalls of "integration hell". The practice aims to reduce timely rework and thus reduce cost and time.

Maintaining code repository means the practice advocates the use of a revision control system for the project's source code. All artifacts required to build the project should be placed in the repository. In this practice and in the revision control community, the convention is that the system should be buildable from a fresh checkout and not require additional dependencies. Extreme Programming advocate Martin Fowler also mentions that where branching is supported by tools, its use should be minimized. Instead, it is preferred that changes are integrated rather than creating multiple versions of the software that are maintained simultaneously. The mainline (or trunk) should be the place for the working version of the software.

NASA stays competitive

I was trying to find something to blog about when a friend of mine suggested that i google NASA's Puffin project. I did, and couldnt believe my eyes! NASA has developed a special air craft called Puffin. "It takes off like a helicopter and flies like a plane. It can cruise at 140 mph and, with a boost mode, hit about twice that. Oh - and its electric," reports Jason Paur in a blog, which can be found at:http://www.wired.com/autopia/2010/01/nasa-puffin/

If you go to Nasa's website, http://www.nasa.gov/, you can navigate through their search to find the Puffin project. The puffin project was conceptualized by aerospace engineer Mark Moore. "Moore came up with the design for the electric powered 12 foot long, 14.5 foot wingspan, personal air vehicle as part of the coursework for his doctoral degree."

(Nasa.gov/topics/technology/features/puffin.html)

My first thought was that it was very Iron Man like! lol I am astonished that we have come this far with interfaces, and robotics together. And with the two different flight capabilites combined in one aircraft! That kind of integration is impressive. I wonder if we'll ever have the technology to drop the price on those so that we can use them in all of our armed forces?

Eventhough the Puffin hasnt been constructed yet, "NIA hopes to fly a remote control one tird sized model to validate assumptions made in academic studies, with the specific intent of exploring the transition from hover to forward flight."(NASA.gov)

Modularity

Recently, I've come across two different examples that lead me to think about modularity. The first is a pretty obvious one, given current developments. The second is a tech that has just been displayed for the first time at the Mobile World Congress currently happening in Barcelona, Spain. The two offer a dramatic contrast in terms of size and highlight the benefits of modularity and its alternative, integration.

The first is the more obvious: the International Space Station. I've been following a Japanese astronaut currently on the space station on twitter. He's been charged with the task, among others, of taking pictures of the earth from the space station. The results are pretty amazing. But one of the coolest pictures he took was of the space shuttle endeavor approaching. This picture got me to thinking about modularity because of what the shuttle carries in its loading bay. The cylindrical object you can see there is called the "cupola" or Node 3. It provides some amazing views to the astronauts on board. One of the amazing things about the mission is how quickly they were able to attach the new piece. Within a couple days of arriving, the astronauts had already fully attached and made functional the cupola. Such ease of piece-by-piece construction is a prime example of one of the benefits of modularity. You can watch them continue to work on the ISS live here.

The second example is the new technology on display by SK Telecom. What they've presented is a SIM card (like the one's used by T-Mobile and AT&T in their cell phones) that carries the phone's processor, memory, 1 GB of storage, and even the Android OS. I know, I know, this is the opposite of modularity. Its an example of a competing trajectory of technology development. The benefit of such a SIM card is that when you want to change phones (whether for a new form factor, bigger screen, etc.) you can simply switch the SIM card from your old one to your new one. This means no worrying about contact transferral, or manual transferral of info from to the other at all. It also potentially means that you could have several devices (phone, netbook, tablet, desktop) that could all utilize the same SIM card for their data, OS, processing, memory, storage, and internet access.

Finally, while I was typing this, I thought of another example of modularity vs. integration. Android is an example of software modularity in that it is designed to be implemented on a wide variety of devices that have very wide-ranging processor power, screen size, ram, etc. Apple's iPhone OS is an example of software integration. The only device you can get that OS on is an iPhone. The benefits of this method are obvious. It is easier to design software for a very specific set of specs and ensure that the software utilizes that spec list fully. The difference of approach demonstrates the difference in business model. Apple is in the business of selling hardware, so designing an OS for their specific hardware makes sense. Google (developer of Android) is in the business of generating internet ad revenue . Thus, they simply want the greatest quantity of OS incarnations running on any phone possible to increase the number of people utilizing their services and hence, looking at their ads.