Lecture 5:
MVC-Framework - Model: Databases & Migrations, automation
Rails cookbock: Not important for my project as I don't use rails
#1: Adding features (model, view, controllers)
#2: Add a new action to a rails app
#3: Create a new submitable form
Everything that is important and big should be stored in a database!

MVC: the
View-Layer: Haml = HTML on a diet
Explicit scenarios: part of acceptance tests
Implicit scenarios: logical consequence of explicit requirements
Imperative: specifying logical consequences, often complicated
Declarative: try to make a domain language from steps, better choice
Pitfalls: customers who confuse mock-ups with completed features, sketches
without storyboards, adding cool features that do not make the product more
successful, trying to predict which code you need, before you need it --> sounds all logical
Remember: debugging sucks, testing rocks :-)
HTML: general overview, invented by IBM: not a lot of new stuff for me
CSS: introduction: I already learned about it
Comments should describe things that aren’t obvious in the code: why not what!

The same thing is possible in Java with the libraries "SVNKit" and "JGit". I already programmed two test programs with those libraries too. But I decided to stick to C#, because the later implementation of the visualization of the geo data will be done in C#.

Problems encountered:

I already encountered speed problems when working with SVN. I used an SVN repository from the University of Applied Sciences Salzburg. When I read the geo data like every second, the storage of the data in de SVN repository takes like 5 seconds. You can see the log message here:

It is no problem for the weather data which I am using, because that data comes in with a period of 5 minutes. But if you use faster sensors, five seconds for storing the data will be too long.
I don't have these problems with Git. But I have to mention, I store the data in the local Git repository, not in the remote one.

today I want to take a closer lock on existing version control systems.

The following table shows a general overview of existing centralized and decentralized systems:

For further evaluation I chose three of the versioning systems in the table. The version control systems Subversion, Git and Mercurial have been picked, because they are currently the most popular systems and they are open source applications.

Apache Subversion (SVN)

The development on Apache Subversion started in October 2000 by CollabNet. In February 2010 it became an open source Apache Software Foundation Project. SVN is a centralized version control system. Collaboration with other developers, even in remote locations, is possible since SVN uses HTTP. HTTP (Hypertext Transfer Protocol) is a standard protocol which is allowed by most firewalls [7].

SVN offers a lot of features like for example a merging tool, branching support, commit messages and a whole lot more. It tries to solve conflicts if two developers have being working on the same place in a file. SVN features also true atomic commits. That means that either a whole commit completes or nothing is committed. That helps repositories to not become corrupted due to incomplete data [7].

Because SVN is open source, easy to learn and offers a lot of features, that other version control systems in the past didn't had, it found a wide adaption by a large number of companies. That results in a wide support with third-party applications. Nevertheless, Subversion suffers from the disadvantages centralized file systems have. If using a slow internet connection the speed of updating or committing data goes down rapidly. Also SVN merging abilities suffer if a file is not cleared of the additional code generated [7].

Mercurial

After the free version of Bit Keeper was removed from the market Mercurial was started to be developed in April 2005 by Matt Mackall. Mercurial is open source and a decentralized versioning system including all advantages and disadvantages of that kind of systems. For example changes are most of the time just pushed to the local repository which gives a huge speed increase. When pushing to a remote location that can be set up with SSH. SSH (Secure Shell) is very similar to the standard HTTP protocol but more secure. That can be an advantage if all HTTP ports are closed in a locked-down network for whatever reason [7].

Mercurial is programmed in Python, which ensures good cross-platform compatibility. It is mostly a command line tool but there are also graphical implementations available. Mercurial offers some nice features like for example changes can be exported to a file. Another user can import that file to a remote repository still under the original name of the first user. This can be useful if new code has to be reviewed and approved of other team members before committing [7].

Because of all that features Mercurial found a wide number of users like for examples the companies Mozilla, Netbeans or Growl [7].

Git

Git started to be developed nearly the same time like Mercurial. Linus Torvalds, the inventor of the Linux kernel, programmed the first version of Git in just 4 days. Git was developed for managing the source code for the Linux kernel development with two core ambitions: speed and security. It is a decentralized version control system [7].

Git takes a special focus on rapid branching. In Git it is possible to make separate branches (so called Git stashes) for special features that can be merged back in the repository after they have been finished. Git is also very scalable. Even if managing a huge project with it doesn't slow it down [7].

The local use of Git is quite impressing, but there are also disadvantages like all decentralized version control systems have. In addition, the set up and learning curve of Git is not as easy like with other systems. The communication with a remote Git repository requires having SSH keys for the local and the remote machine. Nevertheless, there are a lot of books and online resources available for getting to know this versioning system [7].

Selection of two suitable systems for implementation

For the next part of my work, the implementation of version control systems for the processing of realtime geo data, I decided to use Subversion and Git.

These two systems have been chosen to have a comparison between centralized and decentralized systems. They are two very popular systems which are used in many companies. Git won over Mercurial because it is faster and offers more (branching) features [7].

Friday, February 22, 2013

as I will work with Version Control Systems a lot, I want to post a short introduction:

------------------------------------------------------------------

Version Control Systems (VCS) are tools helping developers to manage changes of software. They are used for documentation, sharing and merging of code. This is an essential part in software development and for the success of projects. Software is usually developed in teams which members work parallel on the same code. So it is very important to have a tool for sharing and merging changes [1].

Because this task is so important, there are already a lot of tools available. In my project I want to take use of these systems for handling real-time geo data. The process of merging geo data streams to each other is nearly the same like merging code of several developers to each other. Also documentation is needed for handling sensor data.

In general there can be made a classification of two types of version control sytems: distributed and centralized systems.

Centralized version control systems

Centralized version control systems consist of one single server that contains all the versioned files and a number of clients that are allowed to down- and upload files to that server. This architecture has been a standard for many years [2].

Advantages:Easier to learnEverybody in a project knows what others are doing at the momentAdministrators have control over what everyone is doingFor administrators a central version control system is easier to deal withUsed in many companies

Disadvantages:The centralized server is a single point of failure. When for example the server goes down for one hour, nobody can work with the version control system any more.If the hard disk, where the central server is stored, becomes corrupted, all the data is lost. So the making of proper backups is a central aspect when using central version control systems.

Examples:Subversion, CVS, Perforce

Distributed version control systems

In a distributed version control systems each client fully mirrors the whole repository [2].

Advantages:Every checkout of a client is a full backup of the repository. If the repository goes down, any of the client repositories can be copied back on the server and fully restores the system.A hierarchical model for workflows is possible. It is possible to work with different people in different groups within the same project.Speed increase

Disadvantages:More complex to learn [3].

Examples:Git (can also be used as centralized version control system), Mercurial, Bazaar, Darcs

My plans are to make a evaluation of different systems and chose then two options for a practical implementation. My two current favorites are Subversion and Git. I think they are the two most common systems in companies. I also want to have one example of a centralized and one of a decentralized version control system in my thesis. But we will see ;)

as the use of my project is to improve the data management of geo sensor networks, I want to post something about geo sensing in general:

Geo Sensing

Today geo-information technology is a rapidly rising discipline. The data is mostly collected via airbone and orbiting sensors using photogrammetric techniques, but how has it all started? In former times geomatics were known as land surveyors. Land surveying needs a lot of mathematics and physics. The German mathematician Carl Friedrich Gauss (1777-1855) spent about 20 years of his life with establishing a geodetic
coordinate system. Using photogrammetric for collecting geo-data has been started in the nineteenth century. Geo data is the most important requisite for doing research in the field of geoscience and for getting to know Earth-related processes better [4].

For collecting these data, the use of geo sensor networks created a lot of new opportunities in the recent time. Geo sensor networks communicate wirelessly, they are sensor enabled small devices and they can be distributed throughout a geographic environment [5]. So they can be defined as networks that monitor phenomena in a geographic space [6].

Examples for Geo Sensors [1]

Fields of application

Geo sensor networks open a wide range of new possibilities, like the following examples will show. Therefor three application types can be distinguished based on their observation characteristics: [1]

Terrestrial Ecology Observing SystemsIn these systems continuous monitoring is usual. For example the observation of the growth or the health of plants. In Australia a project was started in 2006 for monitoring the growth circumstances of a nectarine orchard. The orchard had been covered with about 270 sensors and a gateway connected to the internet [1].

Geological Observation SystemsThese systems describe real-time detection applications like a volcano sensor network deployment. For example, the volcano Mount Pinatubo on the island of Luzon in the Philippines erupted on the 15th of June 1991 after about 600 years of dormancy. For observing the volcano scientists are interested in monitoring the mud flow which is the dynamic spatial field in this example. With the help of geo sensor networks they can find out if one of the major tributaries has split or if the mud flow is still expanding [5].

Aquatic Observing SystemsThat group describes geo sensor systems that are mobile or attached to mobile objects. Mobile objects can for example be cars, animals or ocean buoys. Also tsunami early warning systems or coastal and ocean observation systems belong to that group [1].

I study Information Technology & Systems Management at the University of Applied Sciences in Salzburg, Austria. I currently write my master thesis about geo sensing at the Hawaii Pacific University in Honolulu, Hawaii.