Die Hüllen um das „schlecht gehütete“ iPhone 5 werden heute fallen gelassen, zu dem wird das preiswerte iPhone 4S released.

Nach der „Let’s talk iPhone“-Promotion, gibt es schon ein signifikantes Anzeichen auf Features im neuen 5er Smartphone. Denn letztes Jahr wurde das Voice-Controlling-Tool „Assistant“ für 200 Mio. $ von Siri erworben.

Ich bin auch gespannt, wie viel Zeit vom Release bis zum Markteintritt vergehen wird… Was denkt ihr?

Hier eine kleine Statistik zu den alten Apple-Produkten:

Apple - Days to Lunch

Ab wann sprechen wir iPhone5?

Permalink |

• Head of Software Development (m/w) mit mehrjähriger Projektmanagementerfahrung im Bereich Rich Internet Application.
• Data Mining Engineer (m/w) mit ausgezeichneten Kenntnissen in den Bereichen Data-Mining und Statistik.

Genauere Informationen können Sie den jeweiligen Stellenausschreibungen auf der Website entnehmen. Bei Interesse wenden Sie sich bitte an Christof König.

Permalink |

• GWT
• REST
• MongoDB
• PostgreSQL
• Test-Driven Development
• Pair Programming

Das Frontend ist in GWT implementiert. Das Backend besteht aus mehreren Services, welche untereinander und mit dem Frontend via REST Schnittstellen kommunizieren.

Die Stelle ist ab sofort zu besetzen. Solltest Du also Interesse haben und entsprechende Erfahrung mitbringen, dann wende Dich einfach per Mail an jobs@crealytics.de.

Permalink |

Wir bieten ein junges Team, zukunftsweisende Technologien und moderne Entwicklungsprozesse (Kanban) – und natürlich auch etwas Geld

Wichtig: Wir suchen jemanden, der möglichst noch im November 2010 starten kann und ca. 2 Monate bei uns arbeitet – Verlängerung ggf. möglich.

Schmankerl für denjenigen, der den entscheidenden Tipp gibt und uns den gesuchten Entwickler vermittelt: 500 €.

Kontakt: development@crealytics.de

• Gesucht: Spezialist (Freelancer) für REST-Authentifizierung / -Authorisierung und Network Security

Permalink | Freelancer, gwt, java, rest

• Jetty
• Nginx
• REST
• Network Security
• Virtuelle Maschinen: Virtual Box

Schön wären auch Kenntnisse in:

• OAuth
• OpenID
• Cloud-Systeme
  • EC2
• PostgreSQL
• MongoDB
• Java
• Ruby

Sicher hat den Job, wer (optional) auch das beherrscht

• Puppet
• Nagios

Da die angedachten Tätigkeiten verhältnismäßig losgelöst von anderen Entwicklungsarbeiten sind, kannst Du – bis auf einen Einführungstag – extern ohne Präsenz bei uns in Passau arbeiten. Wenn Du lieber mitten drin statt “nur” dabei sein willst, bist Du natürlich herzlich willkommen bei uns.

Da die Zeit doch immer drängt, bräuchten wir jemanden nach Möglichkeit bis spätestens Ende November.

Kontakt: development@crealytics.de

Permalink | Freelancer, Jetty, Nginx, rest, REST-Authentifizierung

Wie es scheint, funktioniert dies aber nur, wenn man sich im Google-Konto angemeldet hat. Google Instant kann auch über kleines Menü im oberen rechten Bildschirmbereich abgeschaltet werden (siehe Screenshot).

Google_Instant_1 Fullscreen

Die erste Frage, die mir durch den Kopf schoss: Produziert das ständig aktualisierte Listing auch ständig neue Impressions? Interessant wäre auch zu erfahren, mit welcher Rechenleistung diese Funktion überhaupt machbar wird.

Wer sich Google Instant in Bewegtbild anschauen möchte, der kann dies unter folgendem Link:

Google Instant Suche in Echtzeit

Die Welt wird immer schneller und verrückter und Google hilft ganz gut dabei mit!

Wer wissen will, wie man Google Instant in Google Analytics trackt, der lese folgenden Blogpost. Einen sehr ordentlichen User-Guide zu Google Instant findet ihr unter folgendem Link auf searchengineland.

Permalink | Echtzeitsuche, Google Echtzeitsuche, Google Instant

So, many will be happy to read that Google has announced to give wave a second life as full open source project: In the coming months, the company will open-source a combination of the server and a client, with the server having persistent wave store and search functionality (first of which is heavily desired; they will use the same backend as crealytics, that is MongoDB).

The newest developments will be published in the Google Wave Federation Protocol discussion forum.

• Google Wave can now remove persons from Waves

Permalink | alternative, collaboration, Google, MongoDB, opensource, persistent, wave

Sun hatte Java im Jahre 2006 unter die GPL gestellt und damit dem eigenen Ruf, nicht nur innerhalb der Open Source Community, einen großen Dienst erwiesen. Dieser Schritt fixierte Java weiter als eine der beliebtesten Programmiersprachen. Auf der anderen Seite hat Oracle, der neue Besitzer von Sun, aber bereits im Hickhack um MySQL bewiesen, kein uneingeschränkter Freund des Open Source Gedankens zu sein. Nun ist das bei MySQL zwar ärgerlich, wenn das dahinter stehende Unternehmen sich unsicher über die Zukunft des Projektes äußert. Hier gibt es aber z.B. mit PostgreSQL diverse freie Alternativen, auf die man relativ problemlos migrieren kann.

Bei Java liegt der Fall anders. Java ist längst mehr als nur eine Programmiersprache. Es existieren für nahezu jeden Anwendungszweck Frameworks und Tools, die die Arbeit an entsprechenden Projekten enorm erleichtern. Insbesondere die Öffnung der JVM für andere Sprachen, wie Groovy, Scala oder Clojure, haben dem ohnehin sehr lebendigen Ökosystem Java einige weitere Einwohner hinzugefügt (siehe grails, lift, sbt).

Und nun hat Oracle also Google verklagt, weil in Android ein JVM Nachbau schlummert:

Laut Oracle sei Java ein mit Android konkurrierendes Mobilbetriebssystem und Google nutze auf Java basierende Technologien ohne Lizenz.

Google sagt daraufhin verschnupft die Teilnahme an der diesjährigen JavaOne ab und auch die kürzlich mit Apple im Clinch liegenden Herren von Adobe äußern sich negativ zu der Aktion. Wenngleich der aktuelle Streit um die Android-Java-Implementierung an sich nicht so dramatisch ist, so hinterläßt Oracles Vorgehen gegen Google doch einen faden Beigeschmack. Man stellt sich zwangsläufig Fragen wie: Wie lange wird Java noch offen weiterentwickelt? Und was wären denn Alternativen? (Mono anyone?)

Man darf also gespannt sein, wie sich der Streit um Java weiter entwickelt und kann im Grunde nur hoffen, dass die Entscheider bei Oracle ihre Strategie nochmal überdenken. Sonst heißt es eines Tages: Java ist nur eine Insel. Was denkt ihr, wie die Geschichte weitergeht?

Permalink | Google, java, oracle, sun

Tests give you a certain amount of stability as they fail when you break functionality. This amount heavily depends on the coverage rate, which measures the amount of code paths of your program are tested by your tests. Normally, test driven development also leads to testable code – smaller classes, encapsulated functionality. If you have a program, that was written some time ago without any tests and maybe evolved over time, it’s very likely, that you best can compare your code to spaghetti. Every class somehow relates to 50 others, functionality is spread all over the classes like tomato sauce and you really don’t like to change anything, because the whole thing surely will break.

The best idea then is to wrap the whole thing into an accompanying skeleton of acceptance tests, to ensure that you don’t break main functionality when refactoring and changing code. Then you can start to split the whole chunk into smaller units, that then can be tested in a more modular way. (xUnit anyone?)

The big advantage of this approach is, that you don’t have to do it all at once. Start writing the acceptance tests and start writing unit tests for bugfixes. Maybe you also have some more minutes when fixing a bug and increase the code coverage by adding another small unit test for some other small class. When you’re feeling comfortable about the code coverage and about the interdependencies of your code, you can also do some refactorings without too much risk. Step by step, the big ball of mud will become a maintainable piece of code with good test coverage and not too much time wasted.

(sources: infoq, dzone, image published by Kieran_KB on flickr under a Creative Commons License)

Permalink | legacy code, tdd, testing

You should try to split your changes into small logical steps, and commit each of them.They should be consistent, working independently of any later commits, pass the test suite, etc.

So what exactly do you gain from following this advice?

Makes your commit messages more accurate

Writing commit messages that describe the content of your patch can be difficult. Especially when you cram many changes into a single commit. Try to follow the ‘One Single Change Per Commit’ rule and prefer two commits like

Fix logging bug in Logger.warn()

Organize imports.

over a one long commit like

Fix logging bug in Logger.warn() and organize imports.

It is not always this easy but often possible, just try it.

Makes continuous integration easier

The whole idea behind continuous integration (or CI) is to integrate your own code with the main repository as often as you can. If you make small changes and put them into single commits you may integrate them often (and probably should). Doing so minimizes merge conflicts with your team members. You can read more about CI in a Git context in Martin Fowler’s excellent FeatureBranch article.

Makes git-revert more useful

git-revert allows you to apply a single commit negatively and thereby roll it back and make it undone. This comes in handy on several occassions: When taking back a change which was inadvertently pushed too early or when taking out code once again which turns out to contain bugs. When keeping your commits small chances are you just can revert this single commit as a whole. No need for cherry picking single lines of code.

Makes git-bisect more useful (my favorite)

git-bisect is a fine bug hunting tool whenever you encounter strange behaviour which you know was not there before in an older version of your code. It deserves an article on its own.

But the basic idea is to switch back to any older version of your code which did not contain the bug, tag this version as good and then let git-bisect do its magic (it’s basically just a binary search through your commit history, which is kind of magic anyway). When git-bisect finishes its search it outputs the single commit which introduced the bug.

And that is why it’s especially useful to keep your commits small when you want to git-bisect often: When git-bisect tells you the buggy commit and it is small enough you can often enough spot the buggy line(s) immediately.

You can combine multiple commits into one large commit after all

If for some reason you believe you created too many commits when a single should have been sufficient then you can squash several commits into one with git rebase. git ready explains how squashing commits with rebase works. Beware that this only works as long as you have not already shared your local changes with anyone else.

apples soon to be tarted… image published by jek in the box {is traveling}
under a Creative Commons License.

Permalink | ci, code, git