GPS, the veteran of the group, has a plethora of satellites at its disposal, offering almost anywhere in the world a precision in meters. The devices which implement this technology are small enough to be inserted even in phones, smart enough to do their job or even more by tracking many satellites in the same time and eating less power, affording the usage of this service for hours in a row. But it needs clear sight to the sky in order to see at least 3 satellites and needs quite a long time in this busy era to get a clear position and be able to pinpoint the location on a map.

Its child, the aGPS helps by relying not only on satellites but also on GSM towers, locating and triangulating them too. Knowing their location, the power of the emitted signal, the user can be easily triangulated. Especially useful in crowded cities, where many GSM antennas are installed removes the need for a clear sky. Thus, it allows even in places surrounded by tall buildings to have a good enough precision while locating the position on the map.

The GSM positioning system continues the movement of the positioning technologies from the sky to ground bases by replacing completely the satellites from the picture. In developed countries there are a lot of GSM towers in urban areas. This is added to the fact that this technology doesn’t eat more power in phones. Since the phone knows by default how to measure and get the tower’s id, there is just a software issue to get the ids, match them to a table with geographical positions and triangulate based on the strength of signal the user’s position. But if you’re in a remote area, like in mountains, where there are few emitters the quality of location falls dramatically.

Wifi, on the other hand, is a newborn technology created out of the people need to communicate. Internet access is getting cheaper and cheaper, being for some business a nice feature to offer. Especially the large fast foods chains offer free wireless Internet access, but also people with enough bandwidth offer this for free. And given the fact that in the big cities these hotspots are countless, some smart guys invented a positioning system based on tracking these hotspots location, offering sometimes a comparable precision in comparison with the classic – the GPS system.

Bottom line, no method is perfect – GPS needs clear sky, aGPS improves this but still needs some satellites to be seen, GSM works like a charm if you have lots of antennas but falls dramatically if you’re in a remote place and WiFi positioning is good in cities, but absolutely lacks in remote zones. Only the composition of all can cover all the situations encountered in a normal life – crowded city when going to work and big, empty spaces when going to mountains to relax.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009(besides the images whom are taken from internet)

Post from: Radu Poenaru's Weblog

GPS vs aGPS vs WiFi vs GSM localization

Since then lots of GPS signal emitting satellites were launched, now the entire surface of the Earth being covered by them. Since 1983, it became also available to civilians, but with lower precision (but still 50 m were quite good for that time) and higher times for getting the current position.

The mechanism of its functioning is simple: you need three satellites to get your precise position in the device line of sight, unobstructed for entire period of measurement, or four if you want also the elevation. The device receives high precision clock signals (atomic clock precision) in order to measure the delay of the wave between the satellites and earth. Then, using triangulation, the location can be pinpointed on the Earth surface by doing some math calculus. The entire process takes few minutes in a device start and less if the device is readjusting the location.

Since its creation, it was used in all domains: aviation for getting to the correct location, help and rescue for climbers and excursionists which missed their path in mountains, sea navigation and now more and more for city navigation. Since the receivers became so miniaturized that they can be easily fit into smart phones, one can use it to get to a newly recommended cafe or theatre without having to carry with it the map of the city.

The recording devices that use GPS can be split into three categories:

1. Data loggers – log data as it arrives and here we can include almost all devices with user interface, no matter that this device is a cell phone or a standalone device. They simply receive the GPS signal, record it and show it to the user.

2. Data pushers – the kind of devices using for tracking logistic fleet in realtime- they read the GPS data but instead of only show it to the user, they also send it via GSM connections or radio to a central location where it is processed. Then the data is analyzed and the merchandise path to the client can be optimized.

3. Data pullers – almost the same as the pushers, but instead of sending by their own at specific intervals data to the central location, these ones can be queried as needed. One of the most important usages is placing one of these devices inside of a valuable device and if stolen it can send its position once queried for it.

The main drawback of this technology is the fact that it requires clear line of sight to at least three satellites. In crowded urban areas or in mountains, this is a luxury. New technologies help minimizing these facts, like Assisted GPS which relies also on GSM towers to get its location done.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009

Post from: Radu Poenaru's Weblog

GPS – Global positioning system

• one of Agile processes
• use incremental framework for developing complex software
• managing new products
• considered more like a framework in which you can employ various processes and techniques
• Key principle: during a project the customers can change their minds

Manages complex processes by:

• Transparency
  • The outcome of the product should be visible to the manager who is managing the outcomes. Also each process that affect the outcome of the product also should been visible to the managers.
• Inspection
  • Various aspects of the process must be frequently inspected regularly so that quality of work and peoples can be seen.
• Adaptation
  • If the inspection process find outs some process are outside the scope of the product or the outcomes will be unacceptable, then the inspector should response quickly and adjusts the process or data being used in the process.

The partners in this process are:

• Product Owner (Also known as chickens)
  • is responsible for the communicating version of the product.
• Scrum Master
  • Scrum manager provide cooperation between the product owner and team.
• Team (Also known as pigs)
  • It’s the team which performs work or sprint- usually there are many teams working on their sprints and each team consist of 5 to 9 cross-functional members.

Main SCRUM terms:

1. The Sprint
   • Sprint is one iteration. Project is dived into small workable sprints which take 2 to 4 week durations, no change to the sprint backlog
2. The Backlog
   • list of requirement from product owner based on their priorities – after every sprint, backlogs are updated.
3. The Sprint Backlog
   • the information how this sprint going to be implemented- process/features are broken down in to small tasks (6 to 8 hours) for teams.
4. The Time Boxing
   • Everything in scrum is time-boxed – It’s about release planning meeting, sprint planning meeting, sprint review and daily scrum meetings.
5. The Daily Meeting/Scrum
   • also called as "the daily standup“ – 15 minutes and all peoples are welcome to join but only the teams (pigs) are allowed to speak. This meeting has only 3 questions to answer
     • What you done yesterday?
     • What you will do today?
     • Do you have issues which are stopping you doing this job?

This is a good example of pattern that started from Software industry going towards the other industries – as opposed to Toyota Production System:

• first applied to software development
• but then successfully used in big industries
• now it used for developing any kind of product.
• the best part of SCRUM as compared to other agile process that it introduces the idea of real world progress of a project not just the best guess on unknown information.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009

Post from: Radu Poenaru's Weblog

SCRUM

Waterfall model:

• Predictive model
• Optimized for a single purpose
• Hard to change

eXtreme Programming

• Reusability
• Easy to change direction
• But no idea of next 6 months

Because the software industry is so different than any other, the development model used prior of creating agile methodology was taken from the engineering disciplines, such as civil or mechanical engineering. Those disciplines put a lot of emphasis on planning before you build because the resources are very expensive and cannot be wasted because of bad synchronization or different physical characteristics like calibers, by example. The planning style is a predictive method that focuses on planning the future in detail. A team that uses these predictive techniques can report precisely what features and tasks are scheduled, both their order and length, for the entire time span of the development process. Predictive teams are very difficult to redirect after the client needs. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. These teams will often institute a change control board to ensure that only the most valuable changes are considered.

Opposed to this, the software as industry relies more on reusability and on site modifications. If a programmer finds a piece of code, of course respecting the intellectual property, can easily adapt it to his project. This approach is called adaptive, because these methods focus on adapting quickly to changing realities – no customer knows from the start exactly what he needs from the start. When the needs of a project change, an adaptive team changes the specifications as well. But this comes with a drawback; because an adaptive team will not be able to describe exactly what will happen in the future, it will precisely know only the current step, the next one depending on the user feedback. Thus, adaptive team knows exactly what tasks are being done next iteration, has an idea about the overall project, but only which features are planned for next month. But if asked about a future release, let’s say six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.

Post from: Radu Poenaru's Weblog

Agile vs Waterfall

This methodology and set of principles has the root in the company with the same name. After the Second World War, the Japan and its companies were almost ruined both physical and financial. To recover the economy, they had to rethink all the processes of production in order to maximize their efficiency. This was required because not only that they lack financial resources, but even the loans that they could do as a country came with big price. In Toyota Company, a smart man called Taiichi Ohno, created a new way to build cars, focusing on creating as many quality products possible with limited amount of resources.

The three principles that guided the rebirth of Toyota and other Japanese companies were:

1. Build only what is needed – literally, they strived to build only products for which they knew that a customer exists. There was no room for additional expenses with storage and building stocks of merchandises, thus only the products quickly convertible in money survived. Also the quality of them assured that they were solvable.

2. Eliminate anything that doesn’t add value – meaning that the product should be really useful to the customer, but also more usable than the one of the competition – assuring that the entire production is sold fast, thus improving also the flow of money in the Japan’s almost ruined economy.

3. Stop if something goes wrong – this is almost a sum of above principles, ensuring once again that only quality products are built. In any process there can be faults, but if stopped when they are minor, by the first worker who noticed the defect, a lot of time and resources can be saved. This is the base principle of zero-defect production, based on a quick feedback of wrong action rather than the late confirmation that an error occurred somewhere along a long line of production.

Besides respecting and caring for budget and products, the Toyota Production System also settled in work environments a set of values, creating a philosophy of work, which:

· respects those engaged in the work

· strives for full utilization of workers’ capabilities

· places authority and responsibility for the work with those doing it, enabling any worker to stop the entire line of production if he knew about a defect.

These principles thrived in Japan, as we all know now, after more than 50 years, bringing it to the top of the biggest economies in the world. Almost all companies soon adopted these principles who were tested by Toyota, becoming the usual way to conduct a business in this country. Very surprising, they weren’t very appreciated in other areas until 1980. These ideas were so well implemented in Japan’s industry, that their almost destroyed industry became the main producer of cars, expanding throughout the world. Even more, during the oil crisis in 1975, they quickly adjust their production to new demands that prove again that Ohno’s principles aren’t obsolete and don’t depend only on the theory behind, but more on the people that implements it.

The Toyota Production System entered into the largest economy, USA, late in 1980 as a tiny idea and later in 1990 they actually started to think seriously about it. The pioneers in this area were James Womack, Daniel Jones and Daniel Roos in the book “The Machine that Changed the World” published in 1990 and by Womack and Jones in the sequel “Lean Thinking” in 1996. They coined the term “Lean Thinking”, depicting a set of five principles, more general and not limited to industry, but to all enterprises independent of field of activity, as follows:

· Specify value

· Identify the value stream – line up activities which contribute value, eliminate those which add no value

· Create the conditions for value to flow smoothly through the stream

· Have the customer pull value from the stream

· Pursue perfection – work on improving the responsiveness of the production system to the customer demand for value

These principles didn’t remain only as ideas, but were quickly adopted by the economy and also fundament a new base for research, in the newly founded Lean Enterprise Research Centre in Wales, England, where it became an instrument of researching, documenting and spreading the lean techniques for improving the work processes.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009

Post from: Radu Poenaru's Weblog

Agile roots: Toyota Production System

Because the software industry is so different than any other, the development model used prior of creating agile methodology was taken from the engineering disciplines, such as civil or mechanical engineering. Those disciplines put a lot of emphasis on planning before you build because the resources are very expensive and cannot be wasted because of bad synchronization or different physical characteristics like calibers, by example. The planning style is a predictive method that focuses on planning the future in detail. A team that uses these predictive techniques can report precisely what features and tasks are scheduled, both their order and length, for the entire time span of the development process. Predictive teams are very difficult to redirect after the client needs. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. These teams will often institute a change control board to ensure that only the most valuable changes are considered.

Opposed to this, the software as industry relies more on reusability and on site modifications. If a programmer finds a piece of code, of course respecting the intellectual property, can easily adapt it to his project. This approach is called adaptive, because these methods focus on adapting quickly to changing realities – no customer knows from the start exactly what he needs from the start. When the needs of a project change, an adaptive team changes the specifications as well. But this comes with a drawback; because an adaptive team will not be able to describe exactly what will happen in the future, it will precisely know only the current step, the next one depending on the user feedback. Thus, adaptive team knows exactly what tasks are being done next iteration, has an idea about the overall project, but only which features are planned for next month. But if asked about a future release, let’s say six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.

Agile methods are a family of development processes, not a single approach to software development. It represents the ways of creating software in a lighter, faster, more people-centric way. The base of this is the Agile Manifesto, widely regarded as the canonical definition of agile development and accompanying agile principles. The Agile Manifesto states that:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

As methodology, agile development tries to push the development process to the user intended direction, providing many opportunities to assess the direction of a project throughout its lifecycle. This is achieved through iterations of work and at whom end teams must present a finished piece of code, usually a piece of shippable code. Because of this repetition of small chunks of work, as well as the functional product they yield, agile methodology can be described as “iterative” and “incremental.” As opposite, in waterfall approach, development teams have only one chance to get right each aspect of a project. Even more, in an agile paradigm, each and every one stage of development like requirements, design just to mention two of them, is continually revisited throughout the project lifecycle. Because of the short periods between reevaluations, usually couple of weeks, when the team stops and re-evaluates the direction of a project, there’s always time to redirect it in the correct direction.

The results approach to development greatly reduces both software product development costs and time to reach the market. In other methodologies, there’s a dead time associated with creating complex specifications while development team is in a code writing pause. Agile teams, on the other hand, can gather requirements at the same time they’re implementing them, so this process can’t really impede a team from making progress. And because a team’s work cycle is limited to few weeks, it gives stakeholders recurring opportunities to recalibrate releases for success in the real world. In essence, it could be said that the agile development methodology helps companies build the right product.

This combination of features is an attractive option for stakeholders and developers alike. In the end, the development agile methodology preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009

Post from: Radu Poenaru's Weblog

Agile – techniques, principles and methodology

All enumerated methodologies of software creation have the common ground of recalibrating themselves and their result, the code, will be crafter to the user’s desire by asking for input on each stage of project evolution. These recalibrations occur after the user evaluates the product, creates a feedback and sets the next iteration goals. This is also known as sprint or iteration. The sprint is organized into three parts: code creation, user review and setting new goals. At the end of every sprint, the team presents a functional module or piece of software to the user responsible with this for review. This emphasis is on creating a shippable product and also ensures that the software engineers from that team don’t get overwhelmed with a huge amount of requirements. The sprint has a specific length and this can either be set in the first place or can be adjusted later, depending on the team members personal skills or the load with tasks.

Because sprints repeat and the resulting code continually grows in functionality, this style of programming – Agile – is described as “iterative” and “incremental.” Comparing with the waterfall model, the development teams have just a single shot at getting each part of a project right. Usually, the longer and complex the project is, the farther will be the product to desired functionalities. This is happening not because of bad programmers, nor bad specifications, but because the lack of feedback. Fortunately, the Agile style not only asks, but enforces the process of getting the final user or Product Owner feedback.

With the advantage that teams can gather requirements while coding, the process of creating, maintaining and rewriting them is greatly reduced. Thus the customer will not be bored too much with them and fewer errors can be slipped into this process – bored people are more prone to errors. The agile team can focus on smaller tasks, delivering quality and almost bug-free and also having all the time the good feeling of making progress. While agile teams develop within the short, repeatable work cycles, the owners or users have all the time the opportunity to look at the results, test them and ensure that the product being created really matches the customers’ need. Bottom line, we can conclude that agile programming helps companies build products their customers want.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009

Post from: Radu Poenaru's Weblog

Agile Lab – Coining the Agile techniques

Starting from the Fall of 2002 a close collaboration begin between the RWTH Aachen University, University of Bonn, the Fraunhofer Institute Centre Birlinghoven Castle IZB and the University of Applied Sciences Bonn Rhein-Sieg . They joined forces to establish the Bonn-Aachen International Center for Information Technology (B-IT) who, as a collaboration, ranked the first university in Computer Science in Germany, above Technical University of Munich and the University of Karlsruhe.

As for now, I study in Media Informatics master held by RWTH Aachen university joint Master with University of Bonn.

I just got the confirmation that I will be enrolled into Agile  lab and study the Agile development techniques along with Ruby on Rails and mobile programming.

I have high expectations from this lab, which is composed from 2 parts : seminar and the actual laboratory hours. In seminar we will study different aspects of Ruby on Rails programming, each of the attending students have to prepare at least two different subjects to present to their colleagues. I strongly believe that I will enjoy these, especially that I am a web developer and I really enjoy to learn cutting edge technologies.

In the practical (lab) part, we will have to develop a mobile web application. This is very challenging because of the devices who imposes restrictions – as general, but also as a particular device – some of them know how to render only JPEG, others know also PNG. Some use MID files for music, other use MP3 or even know to play MPG movies. Different capabilities, different user experiences, different programming for each device. Or not? This I will discover as the time will go by.

So you, all my readers, can expect to find here a lot of articles regarding the stuff I will learn. I will try to present it from a newbie point of view (which will not be hard because in Ruby I’m really beginner) and explain in depth the technologies and the principles which are the presented the lab.

Post from: Radu Poenaru's Weblog

Ruby on Rails & Agile development