Category Archives: Technology

Artikel über konkrete technische Fragestellungen

Viseca-App, umgesetzt von Fabware: Kreditkarte auch unterwegs immer im Griff

Praktisch, übersichtlich, nützlich, genial, super. So wird die Viseca App, welche von Fabware umgesetzt wurde, in den App Stores von Usern beschrieben. Entsprechend positiv fällt auch die Bewertung mit mehr als vier von fünf Sternen aus. Dieses grossartige Feedback lässt sich nicht zuletzt auf die langjährige Erfahrung von Fabware im Bereich der mobilen Applikationsentwicklung im Allgemeinen sowie den „Financial Apps“ im Speziellen zurückführen.

Mit dieser Anwendung hat jeder User seine Kredit- und / oder Prepaidkarte jederzeit im Griff. Sie bietet auf Tablet und Smartphone eine Übersicht aller Transaktionen und Rechnungen. Kartendetails wie Saldo und Kartenlimite sind nur einen Touch entfernt. Dank verschiedener Filterkriterien findet die App jede Transaktion und führt sie auf.

Apropos finden: Ist die Kreditkarte plötzlich unauffindbar, kann diese direkt und unkompliziert über die App gesperrt werden. Ausserdem kann bei Bedarf jederzeit ein neues Passwort angefordert werden. Die App ist somit ein nützlicher Helfer in Punkto Sicherheit, aber damit nicht genug. Sie ist sogar dem Portemonnaie dienlich. Pro Rechnung, die man sich nach Hause schicken lässt, zahlt man derzeit eine Gebühr von 1.50 CHF. Diese Kosten gehören mit der gratis App der Vergangenheit an, da alle Rechnungen über die App abrufbar sind.

Last but not least muss auf eine Spezialität dieser App hingewiesen werden: Viele Apps sind ausschliesslich für ein Betriebssystem optimiert, auf das Zweite werden sie meist lieblos portiert. Nicht so die App von Viseca. Diese wurde von Fabware parallel sowohl für Android als auch für iOS entwickelt, so dass das Erscheinungsbild optimal mit den Design Guidelines des jeweiligen Betriebssystems übereinstimmt. Die Buttons sind somit genau dort, wo der jeweilige User sie seiner Gewohnheit entsprechend erwartet, Farbgebung, Schrift und Anordnung der einzelnen Symbole sind angepasst, kurz: Die Benutzerfreundlichkeit wird optimal gewährleistet.

MyAccount Mobile Viseca im iTunes App Store

MyAccount Mobile Viseca auf Google Play

Personal Sigma App: Design und Funktionalität von Fabware optimal umgesetzt.

Durch den Auftrag von Personal Sigma arbeitete Fabware das erste Mal an einer App ausserhalb des Finanzsektors und das Ergebnis kann sich im wahrsten Sinne des Wortes sehen lassen.

Das Design und die Funktionalität des bestehenden Personal Sigma Webauftrittes bildete für Fabware die Grundlage zur optimalen Umsetzung einer Mobilen Applikation. Diese erspart dem User das Wälzen unzähliger Stellenanzeigen, indem anhand verschiedener Suchkriterien bereits eine erste Vorauswahl getroffen wird. Der gewünschte Standort der zukünftigen Arbeitsstelle so wie das Arbeitspensum können erfasst werden, um die Suche einzugrenzen. Sind alle Parameter festgelegt, wird eine Liste treffender Inserate angezeigt.

Mit einem Klick auf die favorisierte Arbeitsstelle gelangt man zur kompletten Stellenbeschreibung und den zugehörigen Kontaktangaben des zuständigen Personal Sigma Mitarbeiters. Dieser kann über die App per Mail oder Telefon kontaktiert werden. Jedes Inserat kann bei Bedarf auf die persönliche Favoritenliste gesetzt und somit unabhängig von einer neuen Suche jederzeit bequem wieder abgerufen werden.

Die einzelnen Inserate bezieht die App direkt von den Personal Sigma-Filialen und ist somit stets auf dem neusten Stand. Das heisst, die Inserate sind immer aktuell und bereits vergebene Stellen werden nicht mehr angezeigt.

Personal Sigma App

Fabware unterstützt die ZKB bei der Entwicklung der „Mobile Bank“-App

Die „Mobile Bank“ App der ZKB ist eine Banking-App, welche einfache Finanztransaktionen über das Smartphone ermöglicht.

Apps im Bankenbereich stellen aufgrund sehr hoher Rechtlicher und Sicherheitsrelevanten Ansprüchen, stets eine Herausforderung dar. Dank langjähriger Erfahrung im Bereich Financial-Apps und hochqualifizierten Mitarbeitern gelang es Fabware, Design, Funktionalität und Sicherheit unter einen Hut zu bringen.
Insbesondere die Tatsache, dass sich Fabware allen Komponenten annimmt und somit alle Fäden an einer Stelle zusammenlaufen, wurde von der ZKB sehr geschätzt.

Die „Mobile Bank“ App der ZKB macht den Gang zum Computer für verschiedenste Finanztransaktionen unnötig. Jeder Kunde der ZKB mit einem Onlinebankvertrag kann mit dieser App jederzeit Konten und Buchungen einsehen, Zahlungen annullieren und Kontoüberträge tätigen. Auch Börsenkäufe und –Verkäufe können jederzeit und überall in Auftrag gegeben werden.

Selbst für diejenigen ohne Konto bei der ZKB hat die App eine Menge zu bieten. Sie gewährt einen Überblick über die Geschehnisse an der Börse und ermöglicht es, dank einer Suchfunktion und einer Watchlist auch persönlich favorisierte Börsentitel gezielt zu verfolgen.

Auch auf Reisen ist die ZKB App ein nützlicher Helfer, indem sie anhand der aktuellsten Währungskurse ein grosses Spektrum an Währungen direkt in Schweizer Franken umrechnet.
Auf Zürcher Boden entfällt zudem das langwierige Suchen eines Gelautomaten oder einer ZKB-Filiale. Die integrierte Karten- und Ortungsfunktion führt einem bequem zum nächstgelegenen ZKB-Standort.

Mit Fabware wird die Luzerner KB zur ersten Schweizer Universalbank mit iPhone-App!

LUKB LogoUnser Team hat in den letzten Monaten intensiv an der Entwicklung einer iPhone-Applikation für die Luzerner Kantonalbank gearbeitet. Das Ergebnis dieser Arbeit ist jetzt im App-Store erhältlich. Damit kann die Luzerner Kantonalbank als erste Universalbank in der Schweiz eine iPhone Applikation anbieten. Die LUKB schreibt dazu:


LUKB iPhone
App-Store

Die Luzerner Kantonalbank (LUKB) lanciert als erste Universalbank der Schweiz eine App (Applikation) für das iPhone und den iPod touch. Diese steht per sofort kostenlos im App Store zur Verfügung.

Mit der App können Nutzerinnen und Nutzer von der Anlagekompetenz der LUKB profitieren. Die LUKB beleuchtet das tägliche Geschehen an den Finanzmärkten, wobei sie die Entwicklung von Aktien, Devisen, Zinsen kommentiert und einen Blick auf ausgesuchte Unternehmen wirft. Zudem bietet die App Informationen über die mehrfach ausgezeichneten LUKB Expert-Strategiefonds. Ebenfalls verfügbar ist die aktuelle Anlagepolitik, welche die LUKB 8-mal jährlich aktualisiert. Diese bildet die Basis für die Anlageberatung und wird von der LUKB bei den LUKB Expert-Strategiefonds und in der Vermögensverwaltung 1:1 umgesetzt. In die App ist auch der Kursverlauf der LUKB-Aktie integriert sowie der wöchentliche LUKB-Podcast, der die Entwicklung der Finanzmärkte thematisiert.

Die STUcard App fürs iPhone!

STUcard iPhone AppFabware hat die iPhone-Applikation von  STUcard entwickelt. Die Applikation zeigt die STUcard-Angebote aus der ganzen Schweiz und verfügt über eine Volltextsuche. Angebote in unmittelbarer Nähe des aktuellen Aufenthaltsorts können mittels Google Maps angezeigt werden.

Damit man auch ohne Internetverbindung von den STUcard-Deals profitieren kann, werden die Daten zwischengespeichert und aktualisiert, sobald erneut eine Internetverbindung besteht. 

Die Applikation kann ab sofort im AppStore heruntergeladen werden.

 

Book Review: The Definitive Guide to Grails, 2nd edition

The Definitive Guide to Grails is an introductory book to the Grails web application framework. Being an introductory book does not mean that it is only suitable for Grails beginners. Even for more experienced Grails users this book is an invaluable resource. It is written by Grails project lead Graeme Rocher and contributor Jeff Brown, who are both with SpringSource.

The first few chapters (1-7) are dedicated to explaining the basic concepts of Grails: Controllers, Views, Domain Models, Internationalization. Even tough advanced users could easily skip them, they should really skim these chapters as they not only recapture the essentials of Grails in a very intuitive manner but also reveal new insights on how to approach certain classes of problems.

Starting with chapter 8, the subjects become more advanced, covering Ajax, Spring WebFlow, Security and Web Services. Other interesting chapters include GORM, mapping legacy databases with Hibernate and Plugins. The GORM chapter, for example, does an outstanding job explaining potential pitfalls when working with Grails‘ domain layer. The chapter on ‚Integrating Grails‘ explains how configuration and the command line system works which allows you to extend and customize the Grails build system – e.g., building a script to deploy the application directly to Tomcat. Another invaluable chapter introduces the reader to Grails‘ underpinnings, namely the Spring framework. This is by far not a complete introduction to Spring but it gives just enough knowledge to understand what’s going on under the hood and to leverage these internals in own projects or plugins.

Testing support is promoted to be one selling point for Grails but surprisingly, no chapter is dedicated to this topic. This however does not Western union locations mean that testing is not discussed at all. Rather, throughout the construction of the store example, aspects of testing the respective artifacts such as controllers, tag libraries, services etc. are explained. This is certainly a natural way of introducing the topic but makes it somewhat harder to use the book as a reference for Grails‘ testing mechanism.

To summarize, The Definitve Guide to Grails is a good introductory book with the potential to serve as a reference in addition to the official Grails documentation.

Some Lessons Learned from our First Grails Project

After we have discussed the main benefits and praises of Grails in the previous blog posts, let’s now have a look various lessons we have learned so far:

  • The domain-driven approach for database schema generation is fine for development purposes but as soon we go to production mode, we don’t want any automatic updates to happen to our database schemas – even with the liquibase or autobase plugins. We are still investigating on how to solve this problem but for the moment being, we just work with plain SQL migration files which update the schema from one version to the next.
  • Scaffolding is great but use it with care. Especially, before you start generating your controllers and views, be sure to customize the generation templates according to your needs. Otherwise, you will spend a lot of time tweaking the generated views or controllers to your needs. Of course you can regenerate them, but any changes you might have made to the views and controllers may get lost.
  • Updating from one Grails version to the next is straightforward, just run grails upgrade. However, it seems that this will overwrite certain files. We saw it happen to the main index.gsp and ivy.xml. In a toy application, it also seemed to have happened to messages.properties and UrlMappings.groovy but we did not attempt to reproduce that. The takeaway message here is to always use a version control system and commit your latest changes before upgrading to the most recent Grails version.
  • We think the user guide is excellent and we could solve most of our problems with (re-)reading the appropriate section. Also, if you work with the latest betas and RCs, be sure to browse the detailed change logs for each release as this gives you the feeling which issues have been fixed and which issues remain.
  • The community is pretty strong. The blogosphere is buzzing at full steam, producing several interesting blog entries per day. It’s recommended to subscribe to the groovyblogs.org blog aggregator to stay up to date. Blog posts are great resources, and occasionally reading them will allow you to learn „along the way“. Also the mailing list archives contain tons of useful information and, last but not least, the bug tracker will keep you informed about current issues and possible workarounds.

Outlook.
We have learned quite a lot in our first project but we’re not finished yet. Some of the things need to investigate further might be the following:

  • Database migrations, as mentioned previously.
  • Continuous Integration with Hudson.
  • Creating and maintaining a private plugin repository. This is necessary to share common code parts between different applications without releasing them to the public (because we simply cannot opensource all of our code). Using a repository also eliminates manual installation of custom plugins which anyways gets in the way since Grails 1.1 automatically resolves plugin dependencies. Sadly, the user guide does not go into details about creating and maintaining plugin repositories.

Final remarks.
If you ask both of our developers if it was easy to pick up Grails, both will answer with an enthusiastic yes! Sure, you will be a bit unproductive at the beginning, but as you get along with experimenting and reading the excellent documentation your speed will increase. In the end, we are glad we have chosen Grails for this project because it has allowed us to quickly deliver initial results to the customer and we would not have been nearly as productive with the Struts framework which we use for optionrating.com.

Modeling Domains in Grails


After we have discussed several aspects of the Grails framework in our previous blog post, it is now time to say a few words about domain modeling.

In Grails, the domain model is the skeleton of the application, as in all the other languages, but in case of Grails, there’s even more emphasis on that. Your POJOs (here POGOs) take place in the domain folder, and will immediately give the definition of the database layer: all table will be generated based on them. You have to define here the relation between classes with static mappings. Some years ago everyone (sorry for those who did not) started the design of an application with the schema, the n:m, n:1, relations, struggling for hours, spending days to achieve the optimal database model, and then one could start the domain model. If you use Grails, the story ends here because the framework takes care of defining the Hibernate mappings based on the domain class definition. So, no more manual mapping of your domain objects to the database schema – which is of rollershop.gr course still possible if you need to work with a legacy database schema. This is a nice thing since we can really concentrate on the domain and business logic.

Whats also very useful is the ability to define constraints on the domain, right inside the class where they belong to: just define static constraints. Grails has some predefined constraints like credit card numbers, email addresses and URLs, length of fields, etc., which are the most necessary ones in an average application) but one can create custom validators as well. Our application has a slightly complex domain model and we think the validators are quite handy. Any change can be accomplished without rewriting large parts of the program.

All these convenience features have saved us a lot of time on the database definition and the dynamic finder methods have saved a lot of time in providing Create-Retrieve-Update-Delete facilities. This has proven to be essential, because as we all know, the only constant is ‚change‘ – not only change in technology but mainly in requirements. Nowadays most of the complexity comes from the special requirements, complicated domains, and not from the technical side.

Our current project is a perfect example here: its concept is far more complicated than the technical issues. To handle this complexity we still need an extensive set of design practices, techniques and principles, an approach, a way of thinking like domain driven design. Also we should test our domain model with simple unit tests. Grails pushes us to this way, since at the time of the domain class creation, it also generates us a unit test for that class. As a generally accepted principle we always suggest to follow test driven development. In this project we try to follow these techniques, although we have a stronger rule that sometimes overwrites the others, called common sense…

A First Grails Project

It has been almost a year since we got Grails on our Radar for the first time. After playing around with the framework for a while we decided to evaluate it in more depth. After we’ve been busy with optionrating.com for
a long time, we recently decided to implement a small application for one of our customers in Grails to get some hands-on experience outside a pure lab setting.

While we’ve not finished it yet, we can already share some experiences with it.

Project setting

The application is a rather small but still fairly complex project. It will allow our customer to upload an input file and to perform some quite sophisticated analysis on the input data. He can then compose the final report which can be downloaded again. Because this is an internal application, we cannot currently give more details about it.

There are mainly two developers working on the project, one full-time and one part-time employee, none of them had real Grails experience: the first one had never worked with Grails while the second one had made a very simple toy project and had studied the documentation as well as followed the blogosphere quite a bit.

Since we started the project in late January, with the Grails 1.1 release expected for Q1/2009, we decided to start development on Grails 1.1-beta1 and have successfully upgraded to almost each intermediate beta or release candidate. There were very
few bugs that turned out to be show stoppers for us and we are still impressed by the amount of improvements and bug-fixes that make it into each release.

Experiences

Grails is fairly easy to pick up, if you have some Java and web application experience. The main language used to create the applications is Groovy (groovy.codehaus.org) which is very close to Java and therefore is very easy to learn. It has some nice syntactic sugar that simplifies development quite a bit. The rest of our experiences can be summarized as follows:

  • Views and Layout: Grails uses Sitemesh as its view component. Sitemesh applies a decorator philosophy to the views. You can think of it as a reverse include: it’s not the layout file that indicates which content will be included but it’s the content file which
    determines in which layout it will be embedded. The views are located per convention and are automatically resolved for the respective controller and action. This means that there’s almost no configuration necessary which is certainly a big plus over Struts tiles which requires quite a lot configuration work. Groovy Server Pages, or GSP, is the Groovy counterpart to JSP. We found it easier and more flexible to work with than JSP. GSP comes with a ton of useful predefined tags and it is very easy to build own tag libraries as needed (but don’t call your TagLib call it FormTagLib because this will interfere with the builtin form tag).
  • Controllers: with respect to controllers, Grails follows a very Rails-like approach. Assume you have a controller named UserController with an action named login, then this action will be accessible under /appname/user/login. No configuration there. If you come from Struts 1 development, you know what a relief this is because there you will wire each and every action in struts-config.xml. But still, if the Grails default schema won’t fit to your needs, you can easily define custom URL mappings.
  • Deployment: there is no need to set up a complex build system. Just type grails war and a production-ready .war file will be built. If you need to configure several environments with different settings for the database and so on, this is also no problem. However, we still need to investigate on how to set up a more automated build process which can automatically tag releases in our repository as we currently can do with our Maven-based build process for optionrating.com.
  • Running on your development machine: Here Grails wins completely over other frameworks which will need a relatively complex server and IDE setup. For example, to run our optionrating.com application on a development machine, you must install a Tomcat instance, configure the Eclipse IDE with the correct plugin and JVM parameters and so on. If you are lucky, you are ready to start after 20 minutes but it can also take significantly longer. In contrast to this, we can get our Grails-based application up and running on any development machine in approximately five minutes. Assuming that Grails is installed on the machine, just check the project out from the repository and type grails run-app. Thanks to the Ivy plugin the required dependencies will be installed automatically and in Grails 1.1, also the Grails plugins will be resolved automatically. That’s really a big timesaver!

 

@Devoxx ’08 – the java community conference

logodevoxxneg150dpi.jpg Here again, on ex-JavaPolis, this time called Devoxx, but the same atmosphere, incredible geek-crowd, fabulous presentations. And where else could you pay more attention, than in comfortable cinema seats, served with unlimited amount of coffee?After having a quite good presentation about REST, I picked the Grails and Groovy session, to hear some fancy new features, in-depth tricks and so on. Well, it was not in-depth, but was a pretty good overview of the groovy language, right from the most authorized resource, Guillaume Laforge.Did you know that using dynamic typing, is faster? Actually it’s quite obvious, because there is no need to check against the constraints. Groovy has optional typing, which means it supports both static and dynamic typing, you have the opportunity to choose. That also should not be a big surprise, since Java code is a groovy code by default (except for some features, like anonymous inner classes) as well. We were insured that Groovy 1.6 will be out in January ’09. It will get AST transformations, brand-new annotations, and users can define their own annotations. The second part was about Grails, well, again, not many new things popped up, although it was a really nice overview, and also got some sneak peek into the newest version 1.1, what will also come out in January ’09 with improved GORM, and this version will be able to reuse JSP tag libraries as well. Also I felt emphasis on supporting legacy resources in general.All in one, nice to be here, have the technical boost, drink belgian beers, and eat waffles, and see the fellow geeks gathering together once in a while.