Wednesday, June 29, 2011

σήμερα θα ήθελα να φύγω....

Ξεκίνησα την μέρα μου από τις 7 παρά. Αγχωμένος πάνω σε ένα τιμόνι να φτάσω στην ώρα μου για την δουλειά. Μια δουλειά που δεν σταματάει ποτέ, εδώ και 8 χρόνια δεν σταμάτησα ποτέ. Κάθε πρωί τις τελευταίες μέρες με το βλέμμα του απεγνωσμένου περιμένω στην είσοδο κάποιας ΔΕΚΟ μήπως κάποιοι θελήσουν να δουλέψουν. Κάθε μέρα κοιτάω τα site με απεργίες για να ξέρω αν θα μπορέσω να πάω στην δουλεία μου, γιατί κάποιοι άλλοι αποφασίζουν για την καθημερινότητα μου. Η καθημερινότητα μου είναι ένα βάρος, δεν μπορώ πια να κάνω ούτε τα βασικά - δεν ξέρω αν αύριο θα μπορώ να κάνω το ένα ή το άλλο.Κάποιοι ανόητοι πιστεύουν ότι θα έρθει λογικός άνθρωπος να κάνει επενδύσεις σε αυτό το άναρχο κράτος που θυμίζει έντονα τα φέουδα παλαιότερων χρόνων.

Μεγάλωσα σε μια κοινωνία που γαλουχήθηκε με σημαίες, με ψέματα και με ρεμούλες. Μια κοινωνία από άχρηστους φιλοσόφους της στιγμής - που όλο τους το είναι αν το αναλύσεις  η μπάλα(επίκαιρο ε), οι εφημερίδες, αν θα πιαστούν στο δημόσιο, αν θα πάρουν τα λεφτά του δημοσίου, αν έχουμε κάπου γνωστό, αν μπορώ να περάσω στο φανάρι μπροστά πρώτος, αν μπορώ να παρκάρω όπου να ναι, αν μπορώ να φανώ έξυπνος, αν μπορώ να μπω με το καλό μου αμάξι σε ένα club και να καβαλήσω γκόμενες και άλλα.Η πολιτική ζωή της χώρα ακολουθεί. Μια κοινωνία που τα σπάει (κυριολεκτικά και λογικά). Μου την σπάνε οι λέξεις πια ο λαός, ο κόσμος, δικαιώματα, υποχρεώσεις, θεσμός και νόμοι. Σε αυτή την χώρα δεν υπάρχει τίποτα δεν πιστεύω σε κανένα.

Σήμερα μιλούσα με τον πατέρα μου χιλιάδες μίλια μακριά- ο καθένας δίνει την μάχη του για το πως αισθάνομαι, πως πάνε τα πράγματα πολιτικά, για το πως είναι η ζωή. Για το γεγονός ότι κάθε μέρα που ξυπνάω πρέπει να κοιτάω και πιο κάτω - με πιο σφικτή καρδιά. Να μάθω να ανέχομαι λαϊκισμούς, ψευτο επαναστάσεις, ρεμούλες, εμπαιγμούς και την κοινωνική ανισότητα σε όλες τις εκφάνσεις της. Πάνω στα διάφορα λεγόμενα είπα ' σήμερα θα ήθελα να έχω τα @@, να σπάσω αυτό το παράξενο πράγμα μέσα μου , συναισθηματισμός; καρδιά; δεν ξέρω τι είναι και να φτιάξω την βαλίτσα μου και να φύγω'. Δεν ξέρω τι είναι πια αυτό που με κρατάει εδώ, μάλλον μια ιδέα που έχω φυτεμένη στο μυαλό μου και μέρα με την μέρα βλέπω ότι όλο και δυσκολεύομαι να την δω να πραγματώνεται. Ξαφνικά ο καλύτερος μου φίλος (διαβολική σύμπτωση) πετάγεται σε άλλη συνομιλία και χωρίς να μου έχει πει κάτι με ρωτάει - 'Πάρι, να σου πω κάτι, γιατί κάθεσαι εδώ πραγματικά'. Ομολογώ ότι απογοητεύτηκα πλήρως. Τουλάχιστον παραδέχομαι ότι για την ώρα δεν το έχω λύσει αυτό το θέμα.

Ένας άλλος φίλος (Δημήτρη, ΠΑΟΚ ΕΙΣΑΙ) μου γράφει: "ξέρεις κάτι τα πράγματα επι της ουσίας έτσι ήταν απλά τώρα συνειδητοποιήσεις ότι θα συνεχίσουν να είναι έτσι για πάντα΄.

Ορατότητα μηδέν..όχι άλλο κάρβουνο!Ναι το ξέρω μην μου λες ότι όλα είναι στο μυαλό..το ξέρω αλλά αυτό το πράγμα δεν έχω καταφέρει ακόμα να το νικήσω. Όταν το νικήσω θα σου γράφω από κάπου αλλού και όχι από την Ελλάδα.

η καθημερινότητα



είναι κουραστική και μοναχική τελευταία (ίσως εδώ και πολύ καιρό ήταν)...αλλά πρέπει να την αποδεχθείς as is.

Monday, June 27, 2011

Services, practises and tools that should exist in any software development house / department - Part 4 (the security manifesto)

This part (4) is contributed by a fellow reader of this blog and experienced professional, Dimitri Stergiou (linkedin, twitter, blog). Dimitris is working as a Information Security Manager and through this post is eager to highlight the importance of designing and building a secure software solution.Security must part of the overall software development lifecycle.
You may find the previous parts of this post here: Part1, Part2, Part3.



As it was mentioned in Part2,, testing is one of the most important software activities. However, in most of cases, testing is limited to functional requirements and non-functional requirements (such as application security) are largely ignored.

Before we dive into the details, there is an acronym that you need to keep in mind, OWASP (and yes, we will reference it a number of times)

Practise: It is common knowledge, that unless the software product is scrutinized non-stop (e.g. Adobe, Microsoft), the organization is not putting any “effort” in non-functional requirements (such as security). And in all fairness, why should senior management devote resources (people and money) to address security, when it provides no directly marketable feature, nor any tangible benefits?


The answer is simple. Security requirements are there to act as an insurance (pay now, prevent bad things from happening), preserve market share (who wants to use a crappy product?) and provide resilience (especially if your product is used as a service - web based)

Now that we have established that we need security, let’s see how will achieve it. Since the latest trend is Agile Development, here is an example on how you tie security activities with development activities


Since this is not a “be all, end all” post, we will only focus on the security testing (code inspection and dynamic testing)

Before starting the security testing activities, we need to know what we are looking for and how to find it. The best resources on this subject are provided by OWASP in the form of the “OWASP Top 10 Web Application Security Issues” document and the “OWASP Testing Guide v3” (v4 is on its way). These 2 documents will provide the basics on what are the most common (and harmful) web application issues, what are the defences against them and how to identify them in your project

Tools
There are a number of tools available to help with security testing. For code inspection, some of the solutions are:
  1. Peer review: Have development teams read each other’s code. Yes, it is a manual process, but enhances awareness and improves the developers’ ability to produce “better” code. If your programming language is not supported by any of the open source static code analysis tools, and you have no budget for a commercial solution, this is the only way to go
  2. Static code analysis [PDF]: Depending on the programming language in use, it is a good idea to use one of the open source static code analysis tools to check your code for common problems (OWASP maintains a list of tools as well). It is not a bulletproof procedure, and it usually generates enough issues to look at, but if you manage to find a code analysis tool that you like and you manage to built custom rules (to adhere to the organization’s coding style) it will definitely catch a lot of the low hanging fruit (empty try / switch blocks, unused variables, etc.)
  3. Commercial static code analysis: As Gartner suggests [PDF], there are 3 major players in this area: IBM (after buying Ounce Labs), HP (after buying Fortify) and Veracode (they didn’t buy anything - not directly at least). Be prepared to pay crazy amount of money, depending on the number of projects, the programming languages used and a number of other parameters which are solely used to complicate the licensing model (or that is my impression). After working with 2 out of these 3 products (IBM/HP) i can say that they are amazing products but in no way they can provide “out of the box” functionality. They require a LOT of configuration in order to provide meaningful results (no one will be happy with a scan producing 19,387 defects) but AFTER you manage to establish the baseline, they will be quite helpful
  4. Static code analysis in the cloud: Fortify also offers a cloud (hosted) solution, if you can’t afford the in-house hosted solution. They have some special offers for open source software, but i have never tried the service, mainly because every company i have worked for was not happy “publishing” their source code in the cloud
By now you should have an idea on how to cover static testing. However, you need to cover dynamic testing as well. Let’s take a look on how to do this

Tools
  1. Manual penetration testing: Although a number of tools are available, when it comes to web application security, no tool can match results from an experienced penetration tester. Penetration testers DO use automated tools for automating tedious, time-consuming tasks, but DO NOT solely rely on the scan results of a scanner. Amongst other reasons, we are VERY FAR away from being able to create a web application scanner that understands and evaluates business logic
  2. Web application scanners: This category includes a number of sub-categories, depending on how the product actually performs its functions. Some that definitely worth a second look are:
    1. Nikto (written in Perl, one of the oldest kids on the block)
    2. w3af (metasploit approach to web application security)
    3. Arachni (installs as a Ruby gem, nice concept)
    4. skipfish (from Google’s Michael Zalewski)
    5. websecurify (Nice GUI and nice coverage)
    6. sqlmap (for SQL injections)

The 5 products mentioned here are open source, decent communities supporting them and obviously provide the ability to extend the products as you see fit. However, if you have the budget for a commercial solution, here are some interesting ones to try:
    1. Accunetix VWS (one of the oldest companies in the field)
    2. IBM AppScan (ties nicely with IBM’s static code analysis)
    3. Tenable Nessus (although more of an infrastructure scanner)
    4. Rapid7 Nexpose (again, more of an infrastructure scanner)

For a complete list of open source, commercial and cloud solutions, you can go here
  1. MITM proxy: MITM (Man In The Middle) proxies are used by penetration testers to craft of modify requests to / from web applications on the fly. Some of the proxies also contain active reconnaissance capabilities, such as spidering, XSS / SQL injection vulnerability scanning and session manipulation. Some proxy tools to check are:
    1. OWASP’s ZAP
However, expect to be putting in some manual work, since the proxies are a tool to help the penetration (security) tester and not replace him

People, Process, all that Jazz
One thing must be made clear. No matter how many (or few) of the tools an organization implements, it’s the people and the process that will make the difference. Imagine that it has to go something like:
  1. Awareness: Managers, development, everyone needs to be aware of what the goals are and how they will be achieved. Managers need to devote time and money to security testing, developers need to understand how to produce less security bugs (and how to fix old ones) and operations needs to help by deploying infrastructure controls which will help web application security (web application firewalls)
  2. Training: Developers need to understand why the code has security issues, and how to fix them. One of the best weapons in the arsenal of developers is OWASP and specifically the ESAPI (Enterprise Security API) framework. By using ESAPI developers can focus efforts on developing the parts of the software they have their expertise in (bussiness logic) and leave security functions to be implemented by the ESAPI framework
  3. Development: Use open and proven solutions, don’t re-invent the wheel. There is no way that your in-house developed hashing algorithm is better than SHA, nor that your encryption module is faster / better than AES
  4. Testing: Testing for non-functional requirements is a must. End of story!
  5. Lather, rinse, repeat: Whatever you do, remember: it’s a continuous process, you don’t get to do it once and be secure for ever
If you decide that you want to have the process in place, the best way to start is to go through the BSIMM (if your organization is really big) and OpenSAMM (for medium / smaller organizations) and decide which parts of the model you would like to see implemented

Good luck!

Services, practices and tools that should exist in any software development house / department - Part 3.


Code quality: (Practices and tools): Code quality is very similar to testing. Everyone acknowledges that you should move forward implementing practices  and actions  enforcing quality of the delivered software but then again these actions are usually considered as waste of time, badly planned or non existent at all on any project time plan. On the other side developers either poorly trained or with no realistic time to tackle both the problem of the actual business development + building their solution with less mistakes and using best practices. Luckily enough there are ways to tackle the time and effort problem by using tools during development that can scan your code and provide reports, tips and todo's.  We must point that all these tools  can not - detect issues like a poor architecture or design but can proactively secure you from writing lazy or non efficient/'fast' code. 

The following list is a set of tools that any Java Developer can integrate to it's daily work + IDE. These tools can also be automated by wiring their execution on the life cycle of a continuous integration server which will perform code analysis tasks upon request or on predefined intervals. That way you can remove the extra processing (resource) burden on each developer's machine and assign it to a central machine - sharing all the results and reports to the team or making it available to senior stuff.
  1. FindBugs
  2. PMD
  3. CheckStyle
  4. JDepend
  5. Google CodePro Analytix
  6. Sonar (one stop shop-code quality- platform)
  7. Prevent (commercial)
  8. EclEmma
(feel free to comment on other  -that work either as standalone tools or plugins on your favorite IDE).
All the above tools (or many others added in the comments) provide us a first line of defense from our code development mistakes - but can not be considered as the holly grail of code quality. You still need developers with skills and will to learn and adapt. Enforcing or introducing these tools shall be on a department level - part of the development life-cycle. The more you apply such concepts on a wider level the better chances you have to see the results of this practice on the majority of your software development activity.

Continuous ...training (Practice): The road towards developing quality software solutions is related to tools, practices and people. This last part, the people part is the most important. As we have already said in the previous posts none tool or practice is effective unless the people applying it are eager to participate, have a common sense of what is quality and love their job (that is software development). How can a company or department though help to preserve or even increase the skills of their people? How can we make people more motivated and how we can ensure that our people are capable of implementing and delivering the business promises we've sold to our customers? 

It indeed a big question and may have multiple answers - on this post I would like to raise the importance of training (as a potential answer or activity on the above issues). I will try to list some practical and pragmatic actions.
  • Buy technical books: Every software house or department should have its own mini tech book library. I would recommend, bring something new every month. There are lots of companies that do buy books from amazon or so - but only when they are necessary. If you go one step further with minimum amount of money (come ...just a portion of other bonuses and freebies - in terms of budget the company is willing to pay to its employees. 
  • Send people to training sessions: This practice indeed costs a lot more comparing to buying a few books every month. Good training sessions are considered a good investment and provides a quick and flexible way on acquiring certain skills that can be leveraged through a specific project. Realistically I would propose to  every company to provide some sort of less 'other bonuses' and invest on training of its stuff. In the software /IT business knowledge is power, the more in you invest on knowledge skills the better the investment on the future and on the abilities on delivering to your potential customers.
  • Engage people internally : Organize internal sessions, code reviews between different development teams and encourage people who seem to be more active than others to give talks or workshops. It can be a great way of engaging the developers and raise expectations.

    Saturday, June 25, 2011

    ο βασιλιάς επέστρεψε...imac

    Τελικά με αυτό το μηχάνημα έχω ισχυρούς δεσμούς. Μάλλον ανεκτίμητης συναισθηματικής αξίας, μέρος της geek κουλτούρας μου . Μόλις ξανα-post-άρω απο τον αγαπημένο - γέρικο iMac. Η επισκευή κράτησε 2-3 μέρες αλλά δεν μπορούσα να το παραλάβω καθημερινή οπότε περίμενα μέχρι σήμερα. Να ευχαριστήσω την ΔΕΗ και το δίκτυο της που κατάφερε να γονατίσει ένα μηχάνημα που δεν νικήθηκε ποτέ- lol+ epic fail.

    Από τότε που τον αγόρασα είναι η πρώτη φορά που τον ανοίγουν τεχνικοί (όπως μου είπε ο Χ.Π 'παρθένο'). Εκτός από αλλαγή τροφοδοτικού έγινε και ένας καθαρισμός και μπορώ να ακούσω τα αποτελέσματα ήδη. Το μηχάνημα ήταν ήδη αθόρυβο ακόμα και μετά τα τόσα χρόνια λειτουργίας. Όπως και να έχει σκόνη και διάφορα άλλα είχαν συσσωρευτεί μέσα, κάτι το οποίο σίγουρα θα έκανε την δουλειά των ανεμιστήρων πιο δύσκολη. Μπορώ να πω ότι το imac μου είναι σαν την μέρα που το άνοιξα - δηλαδή δεν ακούω το παραμικρό.

    Το μόνο που με στεναχωρεί και τρώει σαν mac addict πια είναι το MacOSX Lion που θα είναι κοντά μας σε λίγο καιρό δεν θα παίζει σε 32bit μηχανήματα όπως το δικό μου. Άρα εκτός απροόπτου ο γερο iMac θα παραμείνει με το τελευταίο release update του Snow Leopard. Θα ήθελα πάρα πολύ να μπορούσα να χρηματοδοτήσω την αγορά κάποιου νέου (27άρι κατά προτίμηση- αλλά οι υποχρεώσεις μου δεν το αφήνουν). Ίσως η αγορά κάποιου μεταχειρισμένου - θα πρέπει να ψάξω και να δω τις διάφορες προτάσεις.


    Ευχαριστώ τον X.Π που ανέλαβε την επισκευή στη systemgraph. Όπως έχω δηλώσει είναι από τους λίγους ανθρώπους και μέρη που εμπιστεύομαι την επισκευή των μηχανημάτων μου.

    Friday, June 24, 2011

    μπλε...


    Όταν ξεκίναγα πριν χρόνια το Judo δεν φανταζόμουν ότι θα έφτανα ως εδώ, πόσο μάλλον μετά από τις διάφορες περιπέτειες υγείας. Φέτος αν εξαιρέσεις το (αυτοκινητιστικό) η χρονιά κύλησε ομαλά με αρκετές προπονήσεις και βελτίωση σε επίπεδο τεχνικών αλλά και κατανόησης στην πάλη (πιο χαλαρό σώμα, πιο εύκολο στις πτώσεις, πιο τολμηρές επιθέσεις και όχι τόσο άμυνα). Δεν είμαι επαγγελματίας αθλητής και ούτε φυσικά θα μπορέσω να γίνω παρόλα αυτά αισθάνομαι απίστευτη χαρά και γαλήνη μετά από κάθε προπόνηση. Κοιτάζω την φωτογραφία του Jigoro Kano που κοσμεί κάθε dojo καθώς υποκλίνομαι και λέω απο μέσα μου  ευχαριστώ παππούλη και για την σημερινή προπόνηση.

    Σήμερα απέκτησα την μπλε ζώνη. Πράγμα που σημαίνει ότι τα πράγματα αρχίζουν να είναι ακόμα πιο σοβαρά.  Ο μεγάλος μου στόχος και πλάνο είναι να συνεχίσω να αθλούμαι καθημερινά με αυτή την παρέα που ξέρω πια χρόνια. Το judo είναι ένα άριστο μέσο κοινωνικοποιήσης. Εύχομαι πριν τα 40 μου (max) να μπορέσω να δώσω στην ομοσπονδία για την μαύρη ζώνη. Αυτός είναι ο μεγάλος στόχος και μου αρέσουν οι στόχοι και τα όνειρα γιατί μου δίνουν δύναμη για το μέλλον αλλά και το δύσκολο σήμερα.

    Να ευχαριστήσω την Ζαχαρένια που επιμελήθηκε ξανά μετά από χρόνια το χρώμα της ζώνης μου στο γνωστό πια avatar του μικρού 'σπασμένου' javapapo judoka!

    υποκλίνομαι σε όλους σας - και εύχομαι υγεία σωματική αλλά και πνευματική!

    hajime!

    Services, practices and tools that should exist in any software development house / department - Part 2.

     We will continue to list and elaborate on simple steps towards shaping up a proper development environment. In the first part we have gone through 3 basic tools 1) Code Repository 2) Issue Tracker 3) Wiki (Part 1). Let's move on.

    3. Build Server (Continuous Integration): One of the simplest and accurate descriptions on the definition of continuous integration  is given by Martin Fowler
     "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible" . Simple as that. A builder & integration server is a software service (usually a web application hosted on an app server) that will offer functionality like - automatic and regular builds of the code saved in the repository, run tests or other quality plugins and produce reports daily regarding the 'health' of the code. Team members will be able to monitor and get notifications about exceptional cases of errors in each aspect of the integration life cycle for example, build errors, number of tests failing after a specific update, quality metrics after analyzing the code. Wikipedia has a quite decent article on the subject.

    There are some basic concerns around selecting a continuous integration /build server.
    • (Type-$$) Which one of them? We are lucky enough (yet again) to point that there is a variety of potential solutions both commercial and open source. When it comes to open source you will see services like Hudson /Jenkins /CruiseControl / Continuum . I have worked with most of them in different companies and I would say that all of them keep their promise on providing basic functionality. You will need to examine the different features / release and update cycles of the technology / and integration with other systems - in order to make your choice. When it comes to commercial packages there is a again a large set of available solutions- some of them would be  TeamCity / Bamboo  etc. You will find lots of blog posts around the net listing potential solutions for example this one.
    • (Backup) As already elaborated many times in the previous post.After installing the service and using it, we should be aware that we need to setup a backup strategy and procedure, usually assigning this task to any of our administrators.
    • (People) An integration server is a component that works for the team, the main thing you want to ensure is that it works properly and that people around the software development life cycle pay attention to its work results (notifications, reports and monitoring facilities).Integrating continuous integration into your software development process you make a step towards being proactive on ensuring software quality. It is something that the management should evaluate carefully.
    4. Testing (tools and practices) : Testing is one of the most important activities during software development. Eventually many people (even today) consider it as waste of resources and time. There are several things that we can do in order to easy our pain on these things + change our attitude towards this important (quality wise) activity.
    1. Practice- Testing should be supported by the project management & upper  layers. Testing does not start on the technical level when it comes to 'actually doing it'.The testing phase starts when it is slowly being properly integrated in the project plan, in the attitude of the software development process, in the trust that the managers and PMs will put on it. There is no - magic button - called now we do testing - in a any software development team. I have seen the following mistakes through out my carreer. 
      1. Project and task estimates do not include time (in a pragmatic manner) for proper testing either unit testing (done by developers mainly) or functional testing (done by a testing team - if there is one). By not assigning time, the developers are forced to tackle the implementation and testing of their tasks into the same time slot- resulting to skipping the less urgent sub task (the test). You can not easily  persuade a project management or a budget manager of a software project to take into account testing as an activity. The results are obvious after the first releases or after the service/ product goes into production resulting to immediate switch from extreme programming to extreme testing on a problematic solution (something that is again completely wrong - see above the magic button effect).
      2. Developers get lazy: Eventually we can not blame the 'managers all the time. Software developers get lazy from times to times since they consider as well testing - as a second class citizen on their task list. Eventually this attitude should be enforced by senior management and by the overall software development practice followed on each department. For example when you introduce automated testing through the exeucution of tests on a continuous integration server - and you monitor the areas of the code where the developers have indeed performed test - you may apply the correct change of attitude to those not paying attention. Some times the complexity of the software and it's design acts like a another reason of a developer moaning (I can not test) and this something that senior developers and architects should pay attention and modify as soon as possible potential parts of the code - make it modular and use the appropriate technologies in order to help/automate/ and encourage on the developer level the testing practice.
    2. The tools -  There several tools and practices that can be applied in order to implement and ease the work on testing. I will provide a short list on things I have seen in my java related career up until now.You may find many other links here for other programming languages or frameworks, here.
      1. Developer frameworks and tools
        1. JUnit (Unit testing)
        2. TestNG (Unit testing)
        3. JMock (mocking techniques)
        4. Mockito
        5. Ejb3Unit (or standalone contaners nowdays)
        6. XMLUnit
        7. HTMLUnit
      2. Web testing /automating fuctional testing
        1. Selenium (web)
        2. Sahi
        3. JMeter (Performance & Testing)
    3. Code Coverage : Up until now we have talked about basic steps towards integrating testing into our project management and every day coding. How we will be able to tell if we are on the right track? How good or how much are we testing? What about quality constraints applied by potential customers (example: we demand 80% of the business code to be covered by tests or similar requests). This is where code coverage as a practice kick in. It is tool to monitor and efficiently fine tune our testing activities. There are certain tools and frameworks that analyze our source and test source trees and provide metrics regarding the amount of real business being tested. In the Java world you may see tools like :
      1. EMMA
      2. Cobertura
      3. Clover (commercial)

    That is all for this second part. I don't want to make the posts huge (they already are). Bare in mind that I expect senior and experienced developers/ architects to already have all the above in place or know about them. The main purpose of these posts is to act a reference point - starting point. I encourage you to post comments and provide your own alternatives on the things mentioned above. See you on part 3.

      Thursday, June 23, 2011

      Services, practices and tools that should exist in any software development house / department - Part 1.

      I truly believe that it's part of our job, some soft of duty, to evangelize the correct way of working within the company / department we work for. Apart from doing our regular tasks analysis, design and implementation we must work efficiently under certain practices and using tools that have been there for years and will continue to exist. It is not an uncommon thing to see while hopping around on different IT companies especially smaller firms, that the software development practice is not functioning properly or is not established at all.

      We could elaborate around the term 'practice'  - what I am really eager to write though is about the minimum tools, services and practices that every developer should be aware of and every new manager or it software company owner/manager should install setup and maintain so that he/she can help his team(s).

      1. Code repository/Versioning system : Eventually it is a central place where we have to save and share code. It manages aspects like version-ing and distribution through out the team. It is amazing but even today you may see around developers sharing code using shared folders, emails or setting up their own code repositories per project (waste of resources). These are practices that we should strongly discourage at all cost. There are some basic concerns around selecting a code versioning system.
      • (Type)Which one of them? Indeed we have quite a few, VSS, CVS, SVN, Git, Merculiar etc. In genera, SVN and Git tend to trend in these recent years. Eventually you pick one depending on your existing know how and your requirements. In case you completely lack previous experience pick one that is trending  (SVN or Git). In case you have your own personal preferences and you know what is good and bad you are free to make your choice and support it. SVN would be a good and safe choice at the moment (IMHO).
      • ($$ )Most of these services/servers are open source and free so you wont have to spent any extra money on downloading and installing them (SVN, CVS, GIt).
      • (Backup) After installing the service and using it, we should be aware that we need to setup a backup strategy and procedure, usually assigning this task to any of our administrators.So proper back-up and maintenance is required!
      • (People) No matter if we manage to buy or install the best code repository/versioning system in our company if the majority of people do not follow the it is another wast of resource. Bringing the tool inside the corporate context is the first step the second one is to make the people start using it - this is where you gain all the benefits!
      • (Remote Access)A central code repository gives you the ability to enable remote working (if it is required or you are willing to do so). People may download parts of work code at home or at the clients premises and contribute hours - not being restricted to local corporate resources.
      2. Issue & Bug Tracker : An issue tracker is a software service (usually a web application) that helps us create, monitor manage and filter the different issues and bus found during development, operations or maintenance of a software solution. Any software product or service can be considered as a living organism, from the very early stages of its creation will need special attention producing errors or problems. Even when we manage to make it work when you release it in the production we always discover new problems, new issues or new ideas emerge. 

      In order to manage this long lasting process of finding, fixing, prioritizing and filtering all these issues and problems we usually fall back to the use of an issue and bug tracker - that can be access from all the related parties. In such a system we are engaging both developers, managers even the end customer to support the issue and problem life cycle of the end product. The developers have tool to associate problems with tasks of work, preserve a history of their fix work and probably able to reactively fix things as they show up. Managers are able to monitor the 'health' of the system by being aware at any time the maturity of the solution. That way they are capable to plan efficiently, give better estimates and provide efficent cost estimates for future releases and change requests. Last but not least the end customer is able to monitor the progress of work, get involved with the product at early stages and being able to log and push on the priority list things that he/she consider that require immediate attention.

      I need to point that an issue tracker usually can be used an efficient way of logging work hours - something that usually companies do using interfaces with other systems like SAP or siebel etc. Logging hours and creating weekly monthly reports you get valuable budgeting information regarding your teams / department. (for free). 

      There is no system with 0 bugs especially in it's initial life and we can not log, archive, search and keep history of this evolution (through the fixes, issues or change requests) with no issue and bug tracker help.

      There are some basic concerns around selecting an issue tracker:
      • (Type) Which one of them? We still have a variety of solutions. Their features more or less are the same in terms of what the system is doing. Each product though differentiates by providing a lot more o certain areas (eg. better reporting, better ui, price, compatibility and integration with other systems). My personal favorite and the one that I have seen in most companies is JIRA from Atlassian. I personally consider it as one stop shop and a great and decent product. I would also have a look on IDEA's YouTrack which features great functionality in a cheaper price. Trac or bugzzilla are interesting free open source alternatives.
      • ($$)The situation is a bit mixed on this category. Great proprietary products and a list of free open source. It is really a matter of money I guess in this. I would strongly though recommend to invest on something good rather than use just for the sake of it a non usuable or handy solution.
      • (Backup) After installing the service and using it, we should be aware that we need to setup a backup strategy and procedure, usually assigning this task to any of our administrators.So proper back-up and maintenance is required!
      • (People)  As already elaborated - using an issue tracking service requires a change of work mentality on teams that have not seen this before. I think it is change that pays back very soon + the company is rapidly reducing man hours on its work log by automating procedures and tasks that were manual in the past.
      • (Remote Access) Remote access is a great asset, anyone (you want to) may have control & access to different parts of this service (per project, per company per client) and remotely can handle important work - regarding the end product.

      3. Corporate - central Wiki: Creating software means exchanging information either related to the end product or the technologies used. The information flow within a software department or even within software development teams is a great problem even today. Problematic information flow at any level may lead to inconsistencies, problems or bad quality work for any team and product. We need to ensure that we have available those tools and practises that will enable all involved parties during software development to easily and flexible enough share information, document findings and share content together. We live in the era of blogs, twitter and web services. Tons of content is being loged, saved and archived through web applications. Google is indexing a searching web pages and related resources. So since we are doing it for our every day life why not follow the same pattern within our company?

      From my personal experience having a central wiki service available is enabling people to easily document and share knowledge either related to a specific project or something general far easier comparing to our old style of Writing multi page and multi megabyte word documents. How many of you have received in your inbox huge word files with the title ' System Specifica version1' having track changes enabled with thousand of comments and a ever changing structure. Word/ Office documents in general are formats that aim to the printed outcome of the document and do not encourage viewing or working on the electronic format it self. I am not against word documents but I am really against writting information, sharing information with other people and having to share the same instance of the same resource, merging changes or keeping track of them while I would just share a virtual page/ place on a wiki (like ablog) and start writting and sharing immidiately.

      I strongly engourage all of you to start experimenting moving your technical analysis or business analysis  documents to such a service by transforming them to wiki pages and web resources. You will be amazed how easier would be for all the related parties (Analysts- Developers- Managers - The Customer) to find, read through efficiently and even comment of add information comparing to the old office sharing way! It is really a change and I always remember proposing such a thing to different management teams while getting back some weird eye- you are proposing something our of our comfort zone thing. But truth to be said - start capturing information in a wiki and stop misusing word or open office - produce word documents or pdfs only at the final stage.

      • (Type) ($$)Which one of them? Mainly most of them do the same thing. Plenty of choices. Proprietary solutions like Confluence are trending a lot but you can easily cover your needs with a free solution like MediaWiki etc.
      • (Backup) The same as above!
      • (People)  As already elaborated -(yet again) - you need to persuade people understand the significance of information flow within an organization.Lots of people are used of the old way, messing around with excel and word documents. Eventually we have we have a solution for this uncomfortable way of working.
      • (Remote Access) Like blogs or any web resource wikis can be easily accessed  shared (or limit them if you wish so) to a variety of people or groups.

      This is the first part illustrating 3 main tools /services that will get you started. In the second part we will elaborate more on other tools or practices. Bare in mind that in some cases the combination of these services - provides - functions and automation levels that have not been covered in this blog post. For example, an issue tracker system may automatically associated issues /bugs with parts of the code as retrieved automatically by the versioning system. Or you may extend the design/solution or an explanation of a problem using a link to an issue that targets your wiki!
      Feel free to comment and provide proposals on the above 3 categories (for example products or services you have used and you consider worth buying or installing).

      Thanks for your time..you may continue with the second part here.

      Monday, June 20, 2011

      το πιο δύσκολο πράγμα

      ..δεν είναι να ξαναχτίζεις κάτι που γκρεμίστηκε γιατί στο κατέστρεψε κάποιος ή είχε σαθρα θεμέλια. Είναι στην φύση μας να φτιάχνουμε ότι διαλύεται ξανά και να προσπαθούμε.

      Το πιο δύσκολο πράγμα είναι να αποδομείς όνειρα, σκέψεις και προσδοκίες....Αυτά πονάνε πιο πολύ και γεμίζουν την καρδιά μου με σκοτάδι.

      Wednesday, June 15, 2011

      there is no place like 127.0.0.1 - papohome

      Αγαπητό ημερολόγιο. 

      Σου γράφω γιατί σήμερα είναι μια πολύ ιδιαίτερη μέρα για μένα. Μία μέρα που εδώ και χρόνια στριφογυρνάει στο μυαλό μου, άλλοτε με απορία, άλλοτε με φόβο, άγχος ή και περιέργεια. Σίγουρα καταλήγει με μία αίσθηση χαράς και ανακούφισης. 

      Το ξέρω ότι η γενικότερη κατάσταση στην κοινωνία και στην χώρα δεν είναι ανάλογη με την χαρά και τον ενθουσιασμό που νιώθω. Το πρωί έβλεπα την χώρα μου στο χείλος του γκρεμού μετά από ένα πολύχρονο κοινωνικό και πολιτικό αδιέξοδο. Βέβαια όπως έχω γράψει και παλιότερα όλα αυτά τα ευτράπελα που είδα σήμερα (πολιτικά και μη) είναι σε απόλυτη αναλογία με τα ευτράπελα εδώ και μερικές 10ετίες στην καθημερινότητα μας. Όπως και να έχει δεν ειναι αυτό το θέμα μου, δεν σου γράφω γι'αυτό.

      Πριν απο 2 ώρες έβαλα μάλλον τις πιο σοβαρές υπογραφές της μέχρι τώρα ζωής μου. Υπογραφές που φέρνουν στους ώμους μου αρκετό βάρος και ευθύνη. Όπως και άλλοι σαν και μένα - στα ελληνικά πλαίσια και στην λογική της μικρο μεσσαίας τάξης στην οποία ανήκω - η απόκτηση κατοικίας ήταν ένα απο τα πράγματα που ζούσε μέσα μου. Θες να πεις οτι μου το μεταλαμπάδευσαν; ίσως. Σαν ενήλικας και εργαζώμενος πέρασα νομίζω όλες τις φάσεις. Έζησα και εγώ μεχρι κάποια ηλικία με τους δικούς μου - μετά μεγάλωσα λιγο παραπάνω και αποφάσισα να ζήσω μόνος μου και τότε είδα τι σημαίνει σπίτι, έξοδα και μηνιαίος προγραμματισμός. Μετά απο 3+ χρόνια στην τελευταία κατάσταση ήμουν πια σίγουρος ότι το να συνεχίσω στην αγορά δικής μου κατοικίας παρότι πιο δύσκολο (οικονομικά) ήταν το πιο λογικό και το πιο σωστό στην λογική του χτίζω για το μέλλον.

      Ανήκω σε μια μερίδα ανθρώπων που θέλουν ή προσπαθούν να χτίσουν το μέλλον. Μπορεί τα πράγματα να μην έρχονται όπως τα θέλουμε πάντα αλλά πάντα πίστευα ότι όσο πιο σκληρά προσπαθείς για να φτάσεις έναν στόχο - ακόμα και τελικά δεν τον φτάσεις στην πορεία θα έχεις κερδίσει και ανακαλύψει για σένα αλλά και τον στόχο σου.

      Είμαι χαρούμενος γιατί το σπίτι μου είναι στο μέρος το οποίο μεγάλωσα, στο μέρος που είναι κοντά τα πρόσωπα που αγαπώ πιο πολύ, η οικογένεια μου και οι φίλοι μου. Δεν πειράζει αν για την ώρα μερικοί είναι δεξιά και αριστέρα κάποια στιγμή θα βρεθούμε όλοι ξανά. Το μέρος το οποίο με κάνει να νιώθω ήρεμος όταν περπατάω στα όρια του και στις γειτονιές του.

      Είμαι χαρούμενος γιατί το σπίτι μου μπορεί να στεγάσει όχι μόνο εμένα και τα όνειρα μου. Μπορεί να στεγάσει πιο πολλούς με αγάπη και καλή διάθεση. Ίσως στο μέλλον να γίνει η απαρχή για μια οικογένεια - αλλά αυτό για την ώρα φαντάζει κάπως μακρυνό.

      Όλα τα παραπάνω δεν θα μπορούσα να τα ονειρευτώ αλλά και υλοποιήσω χωρίς την πολύτιμη βοήθεια της οικογένειας μου που στάθηκαν και στέκοντε σε αυτο το σημαντικό μου βήμα.
      Αγαπητό ημερολόγιο, με περιμένει αρκετή δουλειά τις επόμενες εβδομάδες αλλά μου φτιάχνει την διάθεση ότι θα δουλεύω πάνω σε κάτι δικό μου. Έπιπλα, συσκευές, καθαρισμούς, μεταφορές..ακόμα και αυτό το άχαρα cash flow analysis που κάνω τα βράδια για να δω πόσα χρήματα μπορώ να δώσω εδώ και εκεί - για να κλείσω κάποιες τρύπες με την σειρά μου.

      ένα όνειρο, ένα θέλω σήμερα αρχίζει..μετά απο 2 μήνες σχεδόν που ξεκίνησε αυτή η ιστορία - θα κοιμηθω λίγο πιο ελαφρά σήμερα!

      Αυτά.

      Monday, June 13, 2011

      ζημιές

      PA080041.JPG


      Το καμάρι μου, ένας απο τους λόγους που εδώ και 5 χρόνια γράφω παθιασμένα για την Apple και τα mac, το 20αρι iMac μου - χθες μετά από ένα up/down της ΔΕΗ- μετά την γνωστή μπόρα - με άφησε. Έχουν περάσει αρκετά χρόνια και σίγουρα το power supply του ξέρω ότι έχει δεχτεί διάφορα - μερικές φορές και από βλακεία μου γιατί δεν φρόντισα να αγοράσω από την αρχή καλύτερη προστασία (UPS). Χθες το μεσημέρι ήταν κλειστό αλλά όταν ανεβοκατέβηκε το ρεύμα το είχα πάνω στο πολύ-μπριζο. Από το πρωί με τίποτα δεν ξεκινάει. Ακούω ένα μικρό τικ τικ τικ κάτω στους ανεμιστήρες. Θέλω να πιστεύω ότι απλά με άφησε το τροφοδοτικό. Το είχα ξαναπάθει πριν 1 χρόνο αλλά τότε μετά από ένα 2ωρο εκτός ρεύματος - επανήλθε. Τώρα τίποτα.

      H Geek πλευρά μου δέχτηκε ένα μεγάλο πλήγμα - λίγα είναι τα gadget που είναι κάτι παραπάνω απο gadget.Πχ με το iphone δεν είμαι δεμένος με τις συσκευές - αλλά με το concept , ίσως γιατί τα αλλάζουμε πιο συχνά. Τον υπολογιστή όχι και τόσο - πόσο μάλλον όταν είναι και ο πρώτος που σε έμπασε σε αυτό τον μαγευτικό κόσμο (ναι συνεχίζω να είμαι μέσα στο confort zone μου).

      Αλλά τον πιστό μου φίλο δεν θα τον αφήσω έτσι - τις επόμενες μέρες θα τον πάω στην Systemgraph για επισκευή. Ελπίζω να είναι τροφοδοτικό  ή κάτι τέτοιο και όχι logic board. Θα λυπηθώ αρκετά αν δεν καταφέρω να τον επισκευάσω - δεν είχα τεράστιους λόγους αλλά και περιθώρια έτσι και αλλιώς να αγοράσω καινούργιο αφού έκανα την δουλειά μου.

      Ο πιστός φίλος νο2 , ο εργάτης του σπιτιού (mac mini) ήρθε να σηκώσει το βάρος των home user activities μου πια! Ένα μηχάνημα που τα τελευταία 3 χρόνια λειτουργεί 24/7.


      ένα ακόμα αντίο...

      (Santa Helena. S.Pacific Ocean)

      Τα τελευταία 2-3 χρόνια νιώθω ότι πραγματικά μεγαλώνω.Ίσως είναι και οι ευθύνες που σιγά σιγά νιώθω ότι συσσωρεύονται στους ώμους μου (όχι οι φιλοσοφικές αλλά οι πραγματικές), λίγο οι συμβιβασμοί που πρέπει να κάνεις σε όλα τα επίπεδα. Οι σφαλιάρες από τα αναπάντεχα της ζωής πονάνε πιο πολύ πια και πρέπει να σηκώνεσαι καταρχήν μόνος σου.

      Το κοντέρ σε λιγότερο από 2 μήνες θα γράψει 31 αλλά αυτό δεν σταματάει τελικά με τίποτα το γεγονός ότι υπάρχουν στιγμές που είσαι παιδί. Παλιότερα είχα γράψει για ένα μικρό ξανθό μπόμπιρα που σέρνεται μυξοκλαίγοντας στους διαδρόμους του Ανατολικού Αερολιμένα. Αυτό το κομμάτι μου παρά τα 31 μου χρόνια δεν έχω καταφέρει να το ανδριέψω να το κλείσω σε ένα βλέμμα σε μια ματιά. Πάντα σε αυτή την αγκαλιά την πρώτη και την τελευταία πριν κάθε ταξίδι του πατέρα μου - νιώθω παιδί - έτσι και σήμερα ξανά. Αυτή την αγκαλιά και το αντίο δεν το καταλαβαίνει κανείς - δεν είναι το αντίο του 'μου την βάρεσε και έφυγα', δεν είναι το αντίο του 'φεύγω για ένα καλύτερο άυριο', δεν είναι το αντίο του κύκλου που ολοκληρώνεται. Είναι το αντίο της ανάγκης που πρέπει να σπάσει αλλά και να διατηρήσει συνάμα αυτό που λέμε οικογένεια. Είναι μια υπόσχεση μια υλοποίηση της πραγματικής οικογένειας, ένα σημάδι των δεσμών της.

      Όσο περνάνε τα χρόνια νιώθω βαθιά μέσα μου ότι η οικογένεια  είναι το πρώτο πράγμα σε αυτό τον κόσμο που θα σε στηρίξει με ανιδιοτέλεια και το παντοτινό σου στήριγμα - πιο πάνω απ'ολους τους άλλους. Μέχρι, μέχρι να σφίξεις τα χέρια και τους ώμους σου και να ξεκινήσεις την δική σου, με την ίδια αγάπη και με την ίδια δύναμη στην αγκαλιά σε αυτούς που την απαρτίζουν. Νιώθω ότι έχω καθήκον να στηρίζω αλλά και να φανώ  ακόμα πιο δυνατός στο μέλλον να στηρίξω την δική μου νέα οικογένεια.

      Το αντίο κάθε χρόνο στον πατέρα μου και η ευχή για καλές θάλασσες είναι ένας ακόμα λόγος να ονειρευτώ τα δικά μου παιδιά κάποια στιγμή, τα οποία θα ήθελα να μεγαλώσω με την ίδια ίδια δύναμη στην αγκαλιά και τις ίδιες ηθικές αξίες.

      Καλά ταξίδια...captain.

      I've been trying



      ...

      ps) νέος DJ Shadow

      Sunday, June 05, 2011

      Εντυπώσεις απο την υπηρεσία TaxiBeat - Ναι ρε, αυτό είναι service.


      Λοιπόν είχα την τύχη να είμαι από τους beta tester του TaxiBeat (iphone) μερικές εβδομάδες πριν γίνει διαθέσιμο στο κοινό. Με το που άκουσα και διάβασα για την ιδέα ενθουσιάστηκα. Σαν πελάτης και χρήστης taxi τους έχω χώσει και σύρει διάφορα αφού θεωρώ (εκτός εξαιρέσεων) ότι είναι μια ιδιαίτερα κακή ομάδα επαγγελματιών με αρκετές στρεβλώσεις και στον τρόπο δουλειάς τους αλλά το επίπεδο τους. Έλλειψη ανταγωνιστικότητας, μηδενική παρέμβαση από το κράτος ελεγκτή (ακόμα ένα τρανό παράδειγμα ανομίας) και ο πελάτης στο έλεος τους. Από την άλλη ως προγραμματιστής είπα από μέσα μου ' αυτό είναι μια ιδέα που θα ήθελα να την είχα σκεφτεί εγώ ή υλοποιήσει' με την έννοια ότι είναι σε γενικές γραμμές απλή και doable και αισθάνεσαι μα πως δεν το σκέφτηκα'.

      Όσο ήμουν beta tester δεν κατάφερα να δοκιμάσω σε κανονικές συνθήκες την υπηρεσία μιας και στην περιοχή μου δεν έβρισκα οδηγούς - αλλά τώρα που έγινε διαθέσιμη στο κοινό και σε επαγγελματίες η κατάσταση άλλαξε.

      Χθες και προχθές λοιπόν (2 φορές) ήμουν στο σπίτι και ήθελα να μεταβώ κέντρο και σε μια μακρινή περιοχή που με περίμεναν φίλοι. Το σπίτι μου είναι κανένα 10λεπτο περπάτημα από τον κέντρο του Χαϊδαρίου οπότε συνήθως όταν έχω αποφασίσει ότι θα πάρω taxi περπατώ ως εκεί και περιμένω στον δρόμο μέχρι να περάσει κάποιο διαθέσιμο. Ήμουν λίγο κουρασμένος μιας και είχα περπατήσει αρκετά χιλιόμετρα ιδιαίτερα σε μέρα καθημερινή οπότε λέω ΄είναι μια άριστη ευκαιρία να δω αν το taxibeat δουλεύει'.

      Ξεκινώ την εφαρμογή βρίσκει ακριβώς την θέση μου, μου δίνει 2 οδηγούς σε απόσταση 1 και 1.5 χιλιόμετρο. Μου αρέσει που έχω την δύναμη να επιλέξω. Ο ένας οδηγός είχε μια Mercedes και ο δεύτερος κάτι άλλο. Επέλεξα αυτόν με το καλύτερο αμάξι (μην το παίρνεις βαριά για τις μάρκες παρόλο που μου αρέσουν οι Mercedes) - θέλω να τονίσω ότι είχα την επιλογή. Κάθισα 2-3 λεπτά κάτω από το σπίτι και έβλεπα στον χάρτη το ταξί και κινείται προς τα εμένα - cool! Πράγματι μετά από λίγο εμφανίστηκε- κούνησα το τηλέφωνο στον αέρα για να με αναγνωρίσει και έφυγα προς τον προορισμό μου Έφτασα πλήρωσα ότι είχε γράψει και τέλος. Deal is done! 

      Την επόμενη μέρα έκανα το ίδιο μιας και είχα αργήσει για μια επίσκεψη και εκείνη την φορά διάλεξα μεταξύ των διαθέσιμων οδηγών αυτόν που είχε το υβριδικό Prius (και όχι Mercedes) από περιέργεια μιας και δεν είχα ξαναμπεί σε τέτοιο αμάξι. Ο οδηγός κατά την διάρκεια της διαδρομής όχι μόνο ήταν ευγενέστατος αλλά πιάσαμε και την συζήτηση για το Prius και τεχνικά χαρακτηριστικά. 

      Θεωρώ ότι το taxibeat είναι εκτός από μια ωραία ιδέα και μια υπηρεσία που επιτέλους δίνει στον πελάτη δύναμη και επιλογή. Τόσα χρόνια ο κόσμος έχει κουραστεί να κράζει τους οδηγούς και νομίζω όχι άδικα. Μέσα σε αυτό τον χαμό οδηγών και την μικρο- οικονομία που έχουν αναπτύξει με τι άδειες υπήρχαν και υπάρχουν μερικοί που ήθελαν να ξεχωρίσουν γιατί ήθελα να προσφέρουν ένα καλύτερου επιπέδου service. Μέχρι τώρα αυτές οι εξαιρέσεις δεν μπορούσαν να φανούν. Δεν μπορούσε να φανεί και να αναγνωριστεί η προσπάθεια του επαγγελματία α) που δεν σε κλέβει στην ταρίφα β) που φροντίζει να έχει νέο , άνετο και καθαρό αμάξι γ) που δεν οδηγεί σαν μανιακός ή παίρνει άλλους 15 μαζί σου δ) που δεν καπνίζει και δεν βγαίνεις από το αμάξι λες και έχεις βγει από καφετέρια ή μπουζούκια.

      Το taxibeat θεωρώ είναι ένα εργαλείο που εκτός από εμάς τους απλούς πολίτες/χρήστες θα βοηθήσει και τους καλούς taxi-τζήδες να λειτουργήσουν σε περιβάλλον ανταγωνιστικότητας με τους πελάτες σε κυρίαρχη θέση. Αυτό είναι γενικά μια δύναμη που θα βοηθούσε πολλούς κλάδους υπηρεσιών και όχι μόνο το taxi.

      Με το πέρας κάθε διαδρομής η εφαρμογή σου ζητάει να κάνεις ένα μικρό σχόλιο για τον οδηγό αλλά και να του δώσεις μια βαθμολογία. 

      Εύχομαι η υπηρεσία να τα πάει καλύτερα και να αποκτήσει μεγαλύτερο userbase αλλά και driver base. Δεν βρίσκω το λόγο γιατί να μην γίνει. Ως απλός χρήστης την δοκίμασα και πραγματικά κρατάει την υπόσχεση της.Δεν υπάρχει καμία οικονομική επιβάρυνση από την μεριά του πελάτη. Είναι λοιπόν, από τα λίγα παραδείγματα εφαρμογών ή υπηρεσιών που δεν μένουν απλά στο επίπεδο - cool ή α τι ωραία που είναι αλλά τελικά δεν την χρησιμοποιείς. Μια εναλλακτική πρόταση που κάνει την πραγματικότητα του urban Αθηναίου καλύτερη - λογικά θα εμφανιστεί και σε άλλα αστικά κέντρα σύντομα!

      Keep beat-ing λοιπόν.. την συστήνω ανεπιφύλακτα.

      Thursday, June 02, 2011

      OReilly - Learning Android by Marko Gargenta- Book Review


      I have been developing software using Java since 2001 eventually . If I was about to describe my developer profile I would say mostly a J2EE guy, writing code based on various J2EE web frameworks, EJBs and lately business processes. Learning Android was a true challenge for me. I have been constantly trying to keep in touch with the platform as a developer. The beauty of Android is it's Java centric approach (you write Java) so despite the fact I don't have such a phone I knew that this was the platform that I should target first if I ever wanted to enter the mobile development world - fast and flexible enough.I have tried some other resources in the past but it did not work out for me very well. I was lacking a significant amount of free time so the learning activity was a bit tiring and I could not invest a lot of energy going through quite generic material or investing know how time on a platform that was rapidly evolving.

      When I started reading the book - I was a bit skeptic I have to be honest,  would it work for me this time? I really wanted to grasp the big picture and then based on my  experience I would manage to find my way in the complexities of the platform when needed. To my surprise this book was exactly a great fit for me!  The main idea behind this book is to introduce you the basic building blocks through a very concrete example and then depending on your experience you could leverage this introductory knowledge further on. Despite the fact that the book would not be a bad fit for a junior developer I truly believe that prior knowledge of Java (medium to senior) would act as a 'learning booster' for any potential reader.

      I really enjoyed the very first chapters, (2 The Stack, 4 Main Building Blocks,6 Android User Interface) very well written and easy to grasp. I got a very concise view of the basic things on the platform - far better comparing to other resources or material in the previous years. 

      Based on these first basic chapters you feel confident enough to continue on more specific - platform centric features such as the Threading Architecture, The Preferences mechanism, the Data base layer component or access to the low level device features through Android's abstraction layer.

      The writing style is very good and the pace the author is extending and updating his sample application reasonably balanced for any developer with any prior java development experience.

      I would highly recommend the book to any Java developer especially for those that already have some experience either on Swing (UI development) or server side. This book keeps its promise on transferring a significant amount of Android Platform knowledge  which then can be extended or leveraged depending on your needs and your free time to invest. After a few days reading through, I feel comfortable enough to produce some worth demo-ing small examples and that is very good for my standards at the moment. The examples are based on the Android 2.2/2.3 but I don't find it restrictive and I consider it quite up to date - since it's overall approach is to cover the basic building blocks rather than specific version technicalities.

      Amazon link
      Author LinkedIn / WebSite
      Oreilly Link