Being skeptical: Pair Programming

Introduction
The term “pair programming” was originally coined by Kent Beck and refers to a software engineering technique in which, a pair of people sit together on the same desk, side by side, and work on the same task. The process can occur during all development phases, including not only coding but also design, testing, algorithm design, debugging and so on [1](p. 312). The basic setup of pair programming consists of two roles, a driver and a navigator. The driver, is the one who focuses on the task, writes the code or puts down the design. On the other hand, the navigator is responsible for real-time review. Therefore, he or she has to observe the driver and think of strategies for solving any possible defects. The navigator is not as deeply involved as the driver, consequently, he or she can have an objective point of view and think strategically about the direction of the work. As you can imagine, in case the navigator is quite and does not communicate, the pair is considered dysfunctional [1](p. 311). During the pair programming process the driver and the navigator should switch roles. In some cases, it is common for peer rotation to occur among team members.

Benefits and Limitations
Pair programming is considered as a controversial technique for many reasons as it has both benefits and limitations.

Communication
First of all, by applying pair programming the development process, from a solo activity becomes a more social one. This is because, there is constant communication between the participants. The two peers are now “brainstorming partners”. Research suggests [2](p. 51, Pair Programming Chat) that they solve problems a lot faster, and the quality of the work is usually higher because of the ideas flowing.

Additionally, they are “chatting partners” [2](p. 51, Pair Programming Chat). This helps on work effectiveness since the peers are continuously talking, triggering new ideas. In the case where one peer gets stuck, the chatting helps to unstuck them, the same way as when solo programmers talk about their problems out loud. Furthermore, the “pair pressure” [2](p. 53, Fighting Poor Practices) creates the feeling of not wanting to let your partner down. For this reason, a relationship is created between the two partners which sometimes can lead to satisfaction [3](p. 4, Satisfaction). Particularly programmers think that pair programming takes them out of their “comfort zone”, but as research has shown [3](p. 3, Economics) after some time when a relation has been built, programmers en-
joyed pair programming more, and were more confident than when they programmed alone.

Importance of Peer Rotation
As it is already mentioned, communication continuously triggers new ideas to the participants of a pair duo. However, as psychological research shows [2](p. 53, Pair programmers notice more details) when two programmers pair together, the things they notice and fail to notice become more and more similar. Eventually, the benefit from two pairs of eyes becomes negligible. That effect is called, “pair fatigue” and significantly affects the productivity of a pair. As a result, Kent Beck suggests that the pairs should rotate frequently, even twice per day.

Knowledge Sharing
Next, and what I personally consider as the most important aspect, is knowledge sharing. In a big team there is a wide range of expertise between its members. As a result, when putting people to work together, the knowledge is constantly being passed between the participants. This knowledge includes tool usage tips, design, programming insights and overall skills. In addition, since two peers who work together will not have the same prior knowledge, one will spot some insights or defects faster than the other.

Bad Habits
It is a fact that software engineers are used to working alone, especially those who were educated this way. Also, many of them have the idea that by using pair programming they are wasting their time because their peers will slow them down. However, from the psychological field there is what its called “inattentional blindness” [2](p. 52, Pair programmers notice more details). Inattentional blindness suggest that, if we do not know what to look for, we can stare right at it but still miss it, and what we notice depends on what we expect to see. According to that, although some pair programmers will concentrate mostly on identical parts, they might notice different things.

Economics
The most challenging issue of pair programming is the financial one. Although there are many research results [1](p. 314-317) which support the contrary, the software organizations still believe that pair programming will double the development costs, because two programmers are working on one task. As most managers think that by using pair programming they double the code development costs, they reject it’s usage [4](p. 1, intro). Consequently, a solution to that is to inform the management about research and empirical results that show how, why and when pair programming works in order to have a complete overview of the technique before rejecting it. However, from my experience, applying pair programming in a startup setup is a has bad effects in the economics factor, because usually a startup has to “move fast and break things”, owing to that, this kind of companies do not focus so much on the quality of the product that a pair programming process would provide, but more on speed and parallel work. As a result pair programming is not appropriate method to use in such companies structure.

Coordination
Since more that one person needs to work on a single task, they need to coordinate with each other. This is a problem because they have to work at the same time, on the same team and therefore synchronize their schedules. According to research [1](p. 321, Challenges), one way to resolve this issue is to determine the composition of the pair programming duos during the scrum meeting.

Distributed Teams
Finally, pair programming by definition implies that the participants have to be colocated. However, pair programming would also work in a distributed team.

Distributed Pair Programming
There is a whole new branch of pair programming that is called “distributed pair programming”. Apparently, these distributed team participants can work on pairs using a variety of tools that are available on the Internet. According to research [1](p. 319 Distributed pair programming), distributed pair programming has also proved to be beneficial, although not as much as the co-located pair programming. More specifically, in the case of students, they viewed pair programming positively in general, but the distributed pair programming significantly less favorably.

Variations
There are some variations to the pair programming setup depending on the experience and the expertise of the two participants.

Expert-Expert
Of course, the obvious choice for the managers would be to pair two experts in the field in order to achieve the highest productivity results. However, this does not always work since both parties consider themselves experts in the field and it is unlikely to question their practices. Due to that, navigator’s feedback may not provide the wishing insights and the process might be unproductive. In some cases only one person keeps the knowledge of a module in the system and thus the team can suffer if this person leaves. However using the “expert-expert” combination could save the day in such cases by increasing knowledge sharing and make it available to more people in the team.

Expert-Novice
This combination is the most suggested one [2](p. 50) since it brings the maximum benefit in both the team and the product. The knowledge sharing in this case is significant, while experts transfers their knowledge to novices and novices can introduce new ideas, as they are more likely to be more critical about the established practices. On the other hand, an expert is more likely to challenge and inspire the novice. However, in this type of pairing, a novice may be passive and hesitate to participate meaningfully in the process and as a result this will lead to an unsuccessful pair.

Novice-Novice
This pair is usually discouraged [3](p. 6, Problem Solving – Learning) since the knowledge sharing is very low and the communication could be proved difficult because both of the participant will take a passive approach to the process. However, when is used in students it shows significantly better results than two novices working independently.

Empirical study
Pair programming, is a widely used practice with numerous studies in both industry and education. The results are presented extensively in [1](p. 313, A History Of Pair Programming), [3](p. 3, Economics), and [4](p. 3, Factors of the economic comparison model) .

Pair Programming In Industry
The research shows [1](p. 313, A History Of Pair Programming), [3](p. 3, Economics), that in industry the products took 4% more time in case of pair programming, although the quality of the code was a lot higher, with 39% fewer defects in user acceptance testing. Also, pair rotation in industry is a very common practice to maintain the pair dynamic and the knowledge flow.

Pair Programming In Education
Pair programming in education has showed very good results since it creates an environment for students which activates learning, enhances social interaction and boosts confidence. Not only that, but they also feel more responsible of the task and they are afraid of jeopardizing their partner’s grade. Therefore, they are more active and  articipate a lot more than if they were alone. In the educational setting, the pair rotation is very rare since educators prefer pairs to remain consistent for a whole semester because the overhead of communication could be important.

Conclusion
Although, pair programming results to higher product quality, enhances learning and reduces risk due to improved knowledge management, and, finally, enhances team spirit significantly, it is hard to convince the management to implement it. Therefore, the managers have to invest time to research the subject and give it a shot, since as studies suggest the results are very impressive and this technique becomes more and more popular.

References
[1] Oram, A., and Wilson, G., 2010. Making software: What really works, and why we believe it. ” O’Reilly Media, Inc.”.

[2] Wray, S., 2010. “How pair programming really works”. IEEE software, 27(1), p. 50.

[3] Cockburn, A., and Williams, L., 2000. “The costs and benefits of pair programming”. Extreme programming examined, pp. 223–247.

[4] Williams, L., and Erdogmus, H., 2002. “On the economic feasibility of pair programming”. In International Workshop on Economics-Driven Software Engineering Research EDSER, Vol. 4.

Being skeptical: Test Driven Development

Introduction
Test driven development (TDD) is an agile practice that has been introduced by Kent Beck, or as he puts it “rediscovered” in his book “Test Driven Development in Practice” [Kent, 2002]. Its structure is simple although a bit controversial because of the way it affects the development process. TDD is represented by a development circle, starting always with writing tests and then followed by writing the implementation code.

How it works
Indeed, the first thing is to make a list of the tests that you have to write in order to achieve the goal of your software. The idea behind this, is that it makes you think about the requirements and the specifications of the software before you write any code. Next step is to run these tests and get the “red light”, meaning that those tests should fail. This will ensure that the tests really work and validate the test harness. Therefore, having the tests in place, the following step is to write some code. Since you broke a test you need to fix it! Moreover, TDD suggests writing the simplest code possible, just to pass the tests in place. Particularly, Kent Beck [Kent, 2002] suggests to “Fake it until make it” which implies even returning constant values in order to make the test succeed. As a result, you will never implement something that you are not going to need (YANGI) but you will implement “just enough” to pass the tests. Once the tests and the implementation are in place you need to run the tests and get the “green light”, meaning that all code must pass the tests. Now you need to step back and think about it. You’ve started with failing tests in the morning, you wrote the least possible code at lunch time and in the evening you have a fully working and tested program. Doesn’t this makes you more comfortable? Doesn’t it make you feel more productive? Apparently, that is the point. Of course, you don’t feel that comfortable because even if your code passes the tests you know that you forced it to. For this reason, the next step is to refactor the code. This is the time where you have to apply your favorite software quality standards and principles, while having already the design and the documentation in place, which makes it a lot easier. At last, since you’ll make the tests run again, the implementation always implies new tests. Due to that, you have to go again from step one and follow the development circle.

Benefits
As can be seen from its definition, the benefits of TDD are numerous, from software design to developer’s psychology, and from software requirements to testing and high coverage. Personally, I believe that this technique can often lead to a more reliable software. To begin with, when a feature is finished, most of the time managers force developers to move fast to the next one since the first one “works”. However, the feature is not fully tested which eventually affects its safety. Thus, using TDD you ensure that your feature is already tested with high coverage. Other than that, TDD significantly improves the design. As Ward Cunningham mentions “Test first coding is not a testing technique”. Moreover, Kent Beck presents [Beck, 2001] that TDD offers more than just simple validation of correctness, it can also drive the design of a program. TDD is thus an analysis and a design technique since writing tests before the code requires to consider the design of the solution. In my opinion, this is a good technique to avoid the “analysis-paralysis” effect. It forces you to think about the design, which is considered a topdown process, but during writing tests, which is a bottom-up process. Consequently, it introduces a middleout process which can positively affect the tests, the design process and the developers productivity.

Limitations
So now that your confidence and the test coverage are high and your designs are good, it is time to mention that TDD does not always work. As presented in the previous paragraph, TDD “ensures” reliability, but apparently not always. This is why, most of the time the same developers who write the tests, also write the code. Because of that, the possibility of leaving “blind spots” in the implementation is very high, since the developers are “biased” with high confidence towards their code correctness. The developers think that everything has been tested and feel comfortable about it. However, there are a lot techniques to solve this problem. For instance, test coverage frameworks that analyze to which extent the code has been tested, or random testing that checks cases that you never thought about. In addition to that, there is always the case where the requirements were elicited the wrong way, and in this case you have a perfectly working and tested software, but the wrong software. Furthermore, as it can be seen [Oram and Wilson, 2010] [Beck, 2001] TDD is not applicable in cases that require a lot of functional testing, for example in GUI testing. Additionally, there is no recommended best context for the use of TDD. Thus, TDD can not be used as a framework for specific cases and, when applied, it can not always ensure that the best option, since TDD is difficult to learn. It involves a steep learning curve that requires skill, maturity and time [Oram and Wilson, 2010]. From my experience, you need to invest a lot of time in order to learn TDD, and even some more to practice it before applying it. Generating some personal “heuristics” and patterns that will make your work-flow easier will help. Despite that, once you grasp it, it is easily applicable and provides you with all the aforementioned advantages. Eventually, if not TDD itself, some of its variants, help a lot on many difficult situations. One of those TDD variants is Acceptance Test Driven Development (ATDD). Whereas TDD is a tool for well written unit of code, ATDD is a communication tool for requirements that are well defined. I believe that applying ATDD is a good practice since it does not affect the quality of your code, it is not time consuming, most of the times at least, since you usually test only the APIs, and it can make sure of the validity of the requirements, something that is a problem in the case of TDD. I personally use ATDD a lot. Following ATDD there is also BDD, Behavioral Test Driven Development that focuses on tests which describe behavior. Empirically speaking, there is evidence [Oram and Wilson, 2010] which suggests that on one hand, TDD strongly favors external quality and the modularization of an application, but on the other hand it negatively affects the productivity. Because of the steep learning curve, in the beginning it decreases productivity and introduces a lot of initial overhead. However, I believe it that despite that, it significantly increases productivity overtime, because of the end result is both running and tested software.

Conclusion
Test Driven Development is a very controversial topic in software process. Its costs are usually unknown which makes it an ambiguous technique to use. Online you can find fighters from both fields, favoring or opposing TDD with numerous success and failed stories. In the end it is a nice idea which provides great insights. As agile suggests, “adjust”, try it, and adjust it to your work-flow. If it does not work, change it.

References
[Beck, 2001] Beck, K. (2001). Aim, fire. IEEE Software, (5):87–89.

[Kent, 2002] Kent, B. (2002). Test driven development: by example. Boston, Massachusetts: Addison-Wesley Professional.

[Oram and Wilson, 2010] Oram, A. and Wilson, G. (2010).

Making software: What really works, and why we believe it. ” O’Reilly Media, Inc.”.

Search Based Software Testing – An introduction

[This post is part of my activities as M.Sc. Software Engineering student in University of Amsterdam]

Software testing is an important process during software development. Software developers and testers spend a lot of time and effort to create effective test cases and integrate the testing process in their workflow inside an organization. Although software testing is a great investment for the software’s quality and software’s life, creating test cases manually is a very time-consuming, high-cost and, most importantly, an error prone process. Since this is a common and considerable problem, there has been researched and developed methods that can automate the test generation and make the testing process effortless and reliable. Those methods can reduce the time and cost and increase the quality of the test cases set. A solution for automated software tests generation is given from the Search Based Software Testing which uses optimization algorithms, like genetic algorithms, simulated annealing, swarm optimization and more, to achieve the tests cases generation.

The term Search Based Software Engineering has been coined by Harman and Jones in 2001 [1], and is considered as an optimization discipline for software engineering. SBSE has applications on many software engineering areas such as Requirements engineering, Software metrics, Software project management, Automated Software Repair (automated bug fixes) and Software Testing. The first publication on Search-Based Software Testing was in 1976, from Webb Miller and David Spooner [4]. That work concerned test data generation which included a ‘cost-function’ (also called fitness function for meta-heuristics) for running a simple optimization process. It was a notable contribution to the area since it was different from the existing static methods of that time. The basic idea of the search based test data generation approach is that the set of possible inputs to the program forms a search space and the test adequacy criterion is coded as a fitness function [1]. Furthermore, the test in this situation is transformed into an optimization problem. The test object searches for test data that fulfils the respective test aim in the search space [6].

The simplest implementation of an optimization algorithm is a random search. This method is very poor on finding solution, especially when those solutions are widely spread to the search space [3]. A solution is provided from optimization algorithms and meta-heuristics which “guide” the solutions into the search space by using fitness functions which calculate the quality of the generated solutions [4]. A simple optimization algorithms is the Hill-Climbing. In that algorithm a solution starts at a random point and the points that are close to the current point are evaluated for their “quality” (fitness). If a better solution is found, then the algorithm moves to that point and the process is repeated until the best solution is found. The problem with this method is that when a space doesn’t offer a better solution then there may be a ‘local minima’ of that space. An alternative to simple Hill Climbing is Simulated Annealing. Search by Simulated Annealing is similar to Hill Climbing, except movement around the search space is less restricted [3] and therefore it provides the avoidance of local minimas by introducing a “jumping around” of the solution.

Although meta-heuristic methods like Hill-Climbing work for simple optimizations, software is a non-linear problem and the conversion of test aim to optimization problems mostly leads to complex, discontinuous, and non-linear search spaces. Evolutionary Algorithms have proved a very powerful optimization algorithm for software testing[6]. An important contribution was from Xanthakis et al who applied Genetic Algorithms to the problem [7]. Introducing genetic algorithms to such a problem helped a lot by expanding the search space and providing a form of ‘global’ search, sampling many points in the search space at once. Therefore, Evolutionary Testing implemented as a subfield of the SBT to apply genetic algorithms into the SBST problem.

Search-based optimization can be applied to many areas of testing, more specifically it requires the testing goal to be defined numerically. Therefore search based software testing is considered as a very good solution and many authors are trying to adapt that method [6]. The first application area of the SBT, taken from Miller and Spooner approach [4] is in the Structural Testing (White-Box). It is considered the most applicable and most researched area [3]. In Structural Testing the fitness functions are for path coverage, branch coverage, data flow coverage and more. The program that is under testing performs a code tracing process (Dynamic Structural Test) and is executed with inputs suggested by the meta-heuristic algorithm. The code instrumentation helps with the presence of loops and complex logic which makes it difficult to be analysed statically. The path that has been taken during the execution is compared with some structure of interest for which coverage is attempted to be found [3].

Another application area of SBT is the Temporal Testing in which the purpose is to  find the Best Case Execution Time (BCET) and the Worst Case Execution Time (WCET). This is very helpful for safety critical systems and embedded / real time systems. From reports, search based testing has good results in those kind of tests [8], [9]. The fitness function in this situation is the execution time of the software and it can be found by running it with some inputs. The genetic algorithm generates inputs and rates their quality through the fitness function. In the case of the BCET the search tries to find the minimum execution time, while in the case of WCET the search tries to find the longer execution time.

Although Functional Testing (Black-Box) has not that many publications [10], it is considered as an evolving area while many search techniques can be applied to this kind of testing including simulated annealing, genetic algorithms and particle swarm optimization. Particle swarm optimization is a “population based stochastic search technique” that is inspired by social metaphors of behavior and swarm theory. Functional testing describes the logical behaviour of a system. The fitness function rates the solutions based on how close they are to satisfying the conjuncts to each route. The solution generated tries to optimize this distance to the minimum [11].

Finally SBT can also be applied on the Gray-Box Testing  area which combines both structural and functional information. This area includes the following applied methods. Assertion Testing, is a method where the search tries to find test cases that violate assertion conditions which are inserted in the code by the developers. Another is the Exception Condition Testing in which the meta-heuristics search for inputs and test the run-time errors handling in the code (exceptions). The are many future references that can be applied in this kind of testing therefore it is considered as a growing area [4] [11].

Although the Search Based Software Engineering is not widely applied in the software industry, the Search Based Software Testing, as a sub-field, has been developed a lot all over the years with considerable contributions from both the academic and industry (mostly from embedded and real time systems) world. As it can be seen SBT can be applied on many areas including many kinds of testing and produce impressive results. In conclusion, the are many references and prospects of future work on this field that can help the software developers, testers and most importantly the manually testing process which is slow and painful for many organizations.

 

References

[1] Mark Harman, “The Current State and Future of SBSE”, Future of Software Engineering

(FOSE’07), IEEE Computer Society, 2007.

[2] Stefan Mairhofer, Robert Feldt, Richard Torkar, “Search-based Software Testing and Test Data Generation for a Dynamic Programming Language”, (GECCO’11), ACM, 2011.

[3] Phil McMinn, Search-Based Software Testing: Past, Present and Future, 4th International Workshop on Search-Based Software Testing Berlin Germany, March 2011

[4] W. Miller and D. Spooner, “Automatic generation of floating point test data,” IEEE Transactions on Software Engineering, vol. 2, no. 3, 1976.

[5]  M. Harman and J. Clark, “Metrics are fitness functions too,” in International Software Metrics Symposium (METRICS 2004). IEEE Computer Society, 2004.

[6] P. Maragathavalli, Search based software test data generation using evolutionary computation, International Journal of Computer Science & Information Technology (IJCSIT), Vol 3, No 1, Feb 2011.

[7] S. Xanthakis, C. Ellis, C. Skourlas, A. Le Gall, S. Katsikas, and K. Karapoulios, “Application of genetic algorithms to software testing (Application des algorithmes genetiques au test des logiciels),” in 5th International Conference on Software Engineering and its Applications, Toulouse, France, 1992

[8] P. Puschner and R. Nossal, “Testing the results of static worst-case execution-time analysis” Computer Society Press, 1998.

[9] J. Wegener, H. Sthamer, B. F. Jones, and D. E. Eyres, “Testing real-time systems using genetic algorithms” Software Quality Journal, vol. 6, no. 2, 1997.

[10] Raluca Lefticaru, Florentin Ipate, Functional Search-based Testing from State Machines, IEEE Computer Society, 2008.

[11] Phil McMinn, Search-based Software Test Data Generation: A Survey, Software Testing Verification and Reliability 14(2), 2004.

Google Cloud Endpoints – Simple Chat application part-1 (Server)

In order to get a basic knowledge in web service backend for mobile clients using Google’s App Engine technologies, I am writing this tutorial that is about a very simple Chat with single conversation channel and OAuth for user’s authorisation. The technologies that are used here are the Google App Engine for the backend hosting, where the server is written in Python and Google Cloud Endpoints. In this part-1 of the tutorial I will show you the Server Side of the Google Cloud Endpoints application in Python. In next tutorials I will present you the client’s side starting with a simple iOS client in part-2.

The project consists of a very simple “Chat Room” (only one and it will be static just for convenience) where users must be authorised under OAuth mechanism to send and receive messages. The users will be able to post messages (just text for this post) and then can retrieve the conversations of this channel. It is a very simple application and it is implemented just to show you how the GAE cloud infrastructure is working with clients.

If you never heard of Google’s App Engine a good start is here ( for python) https://developers.google.com/appengine/docs/python/gettingstartedpython27/introduction.

Considering that you already familiar with the Google App Engine technology, and you have installed the required Google App Engine Launcher we starting with creating an empty project.

In the app.yaml file we only need the basic information and the Endpoints information :

application: sugarapptest
version: 1
runtime: python27
threadsafe: true
api_version: 1

handlers:
# Endpoints handler
- url: /_ah/spi/.*
script: main.application

The app.yaml file is a description file of the application, here we entered the application id, the version, the python runtime version, if it is threadsafe and the api’s version. The only difference from an simple empty application is the Endpoint handler that we added for the Google’s Api explorer that we will see later.

If you are not familiar with Google Cloud Endpoints here is a very nice reference with great documentation : https://developers.google.com/appengine/docs/python/endpoints/ .

I am going to use a very useful python module from a google developer Mr. Dhemes, that allows you to interact directly with the model entities of your API methods rather than ProtoRPC requests. This is the link that you have to download the lib and put it on your project https://github.com/GoogleCloudPlatform/endpoints-proto-datastore .

Ok lets start now, lets take a look at the code bellow, this code is as simple as it can be, you can do so many things with GAE Cloud endpoints with few lines :

# description: A very simple chat Google app engine service using OAuth
# author: Alex sug4r
# email: theol.zacharopoulos@gmail.com
# date: 2/2/13

from google.appengine.ext import endpoints  # for endpoints
from google.appengine.ext import ndb        # for data storage
from protorpc import remote                 # for API

from protorpc import messages
from endpoints_proto_datastore.ndb import EndpointsAliasProperty
from endpoints_proto_datastore.ndb import EndpointsModel
from endpoints_proto_datastore.ndb import EndpointsUserProperty

# Static Default Channel
IRC_CHANNEL = 'channel'

# order by class, to order by created date time
class Order(messages.Enum):
    WHEN = 1

# Database Model & RPC Model for Chat Message
class ChatMessage(EndpointsModel):
    _message_fields_schema = ('content', 'fromUser', 'toChannel', 'created') # Set model schema

    content = ndb.StringProperty(required=True)         # the message's content
    fromUser = ndb.UserProperty(required=True)          # get username from OAuth
    toChannel = ndb.StringProperty(required=True)       # send to channel
    created = ndb.DateTimeProperty(auto_now_add=True)   # when the messages is created

    # set order
    def OrderSet(self, value):
        if value == Order.WHEN:
            super(ChatMessage, self).OrderSet('created')
        else:
            raise TypeError('Unexpected value of Order: %s.' % (value,))

    # apply order
    @EndpointsAliasProperty(setter=OrderSet, property_type=Order, default=Order.WHEN)
    def order(self):
        return super(ChatMessage, self).order

# The API
@endpoints.api(name='sugarchat', version='v1',
               description='Test google endpoints chat')            
class ChatAPI(remote.Service):

    # Method to POST a Message
    @ChatMessage.method(user_required=True,        # for OAuth
                 request_fields=('content',),
                 name='chatMessage.send',
                 path='chatMessage')
    def send_chatMessage(self, chatMessage):
        chatMessage.fromUser = endpoints.get_current_user()       #from OAuth
        chatMessage.toChannel = IRC_CHANNEL        
        chatMessage.put()
        return chatMessage

    # Method to Get a Conversation
    @ChatMessage.query_method(user_required=True,
                       query_fields=('limit', 'order', 'pageToken'),
                       name='chatMessage.conversation',
                       path='conversation')
    def conversation_messages(self, query):
        return query.filter(ChatMessage.toChannel == IRC_CHANNEL)

application = endpoints.api_server([ChatAPI])

So let’s take it from the beginning, first we have imported endpoints for Google’s Cloud Endpoints usage and ndb for Google’s Datastore usage from Google’s App Engine module. Next we are importing the endpoints_proto_datastore’s EndpointsModel, this is the class from the module that you downloaded before and will make our life a looooot easier. This IRC_CHANNEL is a constant (for this post) that describes our only one channel that we have into our app.

But see the good stuff here, the class ChatMessage is a sub class of EndpointsModel and it is something like a ndb Model and protoRPC Message at the same time. Very convenient huh? Thank you google! This model is our Chat Message that the user sends to (the only one channel we have). The properties of this model are of course the content, that it is the text that user sends that is a string and it is required (otherwise is not data at all), the id of the user who send that is a user property that takes value automatically from OAuth, and the created date that is a timestamp that triggers the time of ChatMessage creation. Consider that next there is a Sorting method defined, used to order by created timestamp, we need to specify the model’s schema with the line above. The OrderSet function is used to set the order of model results based on a value (WHEN) and the order method is a EndpointsAliasProperty decorator that is used to apply order by (sorting).

Next we only have to construct our API Service, we create a class called ChatAPI that is sub class of remote.service, so it is a service class that provides the properties of API Service to our instance. But, there is something strange above this line of code, this @endpoints.api thing is a decorator for the service that Google provides to us. With this structure we build our service, the data we use here is a name for the service, a version and a human readable description.

Of course this class needs some methods to operate. We need two methods, one to send a message to the channel, and one to read all messages from the channel. So we creating an instance method called send_chatMessage that take as a parameter ChatMessage model, the message to be sent. We set the “fromUser” property to the currently logged user from OAuth, the ‘toChannel’ property to our only one channel (in a real application we want to change channels). After we get the right data, we store this data in the datastore using put() and return the new message. Using the same Decorator we required values as you see.

The last method that we need is a method that will return the list of all messages (Conversation) on the channel. So we return the query from datastore applying a filter, to show results based on selected channel. I know this is not needed for this application because we have only one channel. The decorator here is a little more complex, because it has some parameters like ‘limit’ that is used to show a limited number of messages, and ‘pageToken’ that provides a token for the next page results when there is limit on them.

Finally we set the application to be a service that contains our API : ChatAPI.

Time to see our app online, we run the Google App Engine launcher, run the application locally (or remotely if you prefer), and with this address in our browser we can have access to API apps on GAE : localhost:8080/_ah/api/explorer or <yourapp>.appspot.com/_ah/api/explorer .

If everything it’s gone well you will see something like this :

Here is the Api application when you click on that, you can see your API methods :

Lets test if the app is working from this google’s tool, first we have to authorise ourselves with OAuth mechanism using our google account :

Now let’s try to create a new message :

Everything went great and as you can see it works, but before you are completely sure you have to check your data store also :

Now don’t forget that we can see all messages from he method we create to show conversations, after adding 2 more messages log in using OAuth you can see the following :

As you can see, there is a sorting method applied here, because I set as default sorting, order by created date.

That was the Server’s side code, hopefully after everything is working great we are ready to create some client applications to store / retrieve messages form the server. At part-2 of this tutorial I will show you how to create a very simple iOS client for this endpoints application.

Sources:
https://developers.google.com/appengine/docs/python/gettingstartedpython27/introduction
https://developers.google.com/appengine/docs/python/endpoints/
https://github.com/GoogleCloudPlatform/endpoints-proto-datastore
https://developers.google.com/appengine/docs/python/tools/protorpc/

Hotel Reception Manager developed on Qt

Within the framework of the course “Software Engineering II – Laboratory” (Department of Informatics and Communications, T.E.I of Serres) we developed as a semester assignment an application for the management of hotel businesses.

Both the graphical user interface (GUI) and the application were implemented with Qt while the database in SQLite. More specifically, the end user can perform through this application functions such as: processing of customers / rooms, booking rooms, search rooms / customers, inventory of hotel services offered to customers, central management for the correct operation of the hotel, central management of the cost of services provided, as well as adding new users and system administrators to the system.

The development methodology we followed for the development of the application was the Unified Proccess.

In this project my role was as ‘Project Leader’ and my job was to organize 13 persons of doing their specific work, basic system analisys – uml diagrams and operational units. I also participated as a developer several times giving solutions for major problems.

Special features of the application:

• Portability across many operating systems ( Because of Qt )
• Use of lightweight SQLite database system ( Without any background server running)
• Use known design patterns
• Object-oriented approach for the design of the application ( MVC )
• SQL Injection security ( On data forms )
• Use of W3C CSS to GUI objects to format them
• Full documentation of source code using Doxygen

The project is under the GNU licence and you can get it free.

For more information you can get the project ‘reception‘ itself.