MrBoolean

Categories

words-croppen

And the winner is… hold on… I meant the five winners

09.05.2013

Hello Folks! A month ago we have promoted some codes for the awesome OSX App Words App. The contest is over! Finished! Done! The winners are found!

I am proud to present you the five winners:

  • Gokmen Goksel
  • Monica Messaggi Kaya
  • Alberto Caceres
  • Carina Skladal
  • Rachel Young

Please answer the mail you have received to get your code.

Along these lines thank you for reading my interview with Sven. At least I have to announce a new project called face.io. In the next months you can read interviews like On the past, present & future of Words and what we learned along the way every two weeks. Get involved into the business of other creators and check their thoughts!

“On the past, present & future of Words and what we learned along the way”

19.04.2013

In the past few weeks I have reviewed some Open Source projects (e.g. review or traffic-light). Today I have taken a look on a very interesting OSX application. The uniqueness of this app is that most of the stuff you can see is built with HTML5, CSS as well as JavaScript.
Maybe some of you have heard about it: The Words App.

In the next days you have the chance to win some promo codes using our contest page. I am proud to present you the first interview I have ever done. Sven, the Designer of the named application had a talk with me about his work.

Hello Sven, how are you? Could you please introduce yourself?

sven-uxmunich

Hi. My name is Sven Read. I am a 35 year old designer living near Munich. I am a designer at BörseGo AG (by the way, we are looking for an awesome JS ninja!) at day, while being a husband to a beautiful wife and father of two young children. And if both leave me some spare time (which is rare) I love playing soccer with my friends or going to the cinema.

You can follow my musings on Twitter or check out stuff I built on my Github account. And, perhaps the most interesting, I often preview my work on Dribbble. So you should check it out if you want to see what I work on at the moment.

You built your own desktop app named Words. What is Words and what is it good for?

Yes, that’s true. And the short answer would be: Words is a library app.

If you use one of the major read-it-later services, like Instapaper, Readability or Pocket, you most probably use it to save interesting & bookmark-worthy textual content you found somewhere online. And Words downloads all these articles to create a local library of content, curated by you. And you have this precious knowledge safe & near you, just a click away, ready to be searched, even offline. That’s what Words is for. It works as your private library of knowledge.

That’s interesting. What was your motivation in creating such an app?

That’s actually a long story. I am a classic self-taught designer who learned all the finer points of his craft from stuff other designers had written or made and I have an extensive list of ePubs and articles saved inside these services. And I had this growing issue of managing this knowledge base. Actually, my initial idea was to create an ePub reader. But this turned out to be rather complicated to build, due to the quite volatile standard that ePub was at that time.

So I refocused my plans on getting a grip on my saved Read-it-Later articles first. I wanted a super-easy way to search and read my articles, even offline. That was my initial motivation. And that ended up being the first version of Words. It was rather simple & plain. But it sold quite well. And many users wanted more. They longed for a real Read-it-Later client.

So my father, my brother and I, we made one. Words 2.

Screen Shot 2013-03-31 at 7.25.43 PMWas this actually the first app you guys made?

Yes, indeed. We all had some experience making a few mobile apps, but that’s all. I actually live from doing web and UI design. My father had to learn to code Cocoa and I had to learn what users need in this quite different environment.

So this was quite an adventure for us. And a lot of work. Much more than we had expected. But it was lots of fun, too. And we learned so much doing this our own way.

Tell us more about the things you learned along the way.

Most important, we had to learn that making software and launching websites are quite different from what we had expected. At the beginning, we didn’t really test our software. Or, to be more precise, we thought we had tested it hard enough, but ended up having horrible bugs all over the place. Things broke in the most unexpected ways, especially because we needed to handle three different APIs with varying and often very unreliable output. This was frustrating at times. But we worked our way out of this.

Another very useful lesson is, in my opinion, that you can build big parts of Mac desktop software just using web technologies, like HTML, Javascript and CSS. Nearly all of the front end is built this way. It took some time to get it right, but far less than it would have taken to get Interface Builder to do the same stuff. Especially if you want to sweat the details, like custom line heights or other sophisticated typographical features. To be precise: Getting this level of detail and control in native would be almost impossible. And it just would not be worth the fight. Even Apple themselves do it on occasions. Just have a look at how the Appstore is built.

Naturally, there are some disadvantages to mention, too. While most stuff gets easy & fast, some small things suddenly get complicated. You can’t easily make the context menu work for you in a web view the same way it would play nicely with native implementation. The same applies to loading content for very long lists or tables. Native implementation is easy, but in HTML it’s a pain to recreate the native performance. So, have a deep think before deciding how to go along, but don’t be afraid of taking the HTML/CSS path. We would do it again.

Screen Shot 2013-04-02 at 7.38.11 PM

My recommandation for starting out if you want to build a hybrid app: MacGap. They  wrap an HTML/CSS/JS app in an native framework and even provide a basic JS API for communication with OSX. Its very lightweight & easy to extend.

A third lesson I would like to share is that you should listen to your customers. Talk to them early. Let them participate. Most of your early users will be very passionate about what you are building and can be a great help in keeping focus, finding bugs and pushing you to go the extra mile. Words wouldn’t be what it is today without these awesome guys. They helped us so much. They tested like hell. They talked about Words to the people they know and helped us get traction. You can’t buy such support for money. Its priceless. You should find these people early, involve them and let them know how useful they are to you. They won’t let you down and help you get of the ground.

Thanks for the insights. So what’s next for you guys? And future plans?

Screen Shot 2013-03-31 at 5.46.55 PM

At the moment, we are working on integrating notes into Words. We want to enable our users to annotate everything they want in their articles. Perhaps even collaboratively. And perhaps including attaching files to their articles. We are in the process of figuring it out at the moment. But this feature will be the next to hit the store.

And our next really big thing will be ePub integration. This was my first intention and I haven’t forgotten about it. I want Words to be your private library of precious content, regardless of format. And ePub is a very important & common format. But this will take some time to make it happen. We want to make it awesome, so we will do what we need to make this happen. My personal goal is to make the best possible reading experience on the Mac. This is what keeps me up at night and wakes me in the morning. So expect some great stuff in the future.

Sven, thanks for your time and for sharing your experiences. It was a pleasure.

You’re welcome. The pleasure was mine to have the opportunity to share some of the experiences I made. And keep up the good work with you blog. I love reading it. By the way, I brought you some Words promo codes to share with you readers.

website

Internetseite – darf man das “Ding” überhaupt so nennen? Oder auch: Ein paar Details machen eine Internetseite rund!

27.02.2013

Relativ oft denke ich mir, ob der Entwickler der die jeweilige Internetseite erstellt hat, wirklich ein Entwickler ist. Das kann man sich irgendwie teilweise so vorstellen: Sonntag, 9:30 in Deutschland – fahre gerade auf der Landstraße. Vor mir ein Mann mit Hut der mit satten 30 km/h durch die Gegend tuckert. Beim abbiegen reduziert er seine enorme Geschwindigkeit noch um die Hälfte, sodass das schwere Auto (ein blauer Opel Corsa) nicht aus der Kurve bricht.

Bei Internetseiten ist das teilweise auch so. Ich drücke “ESC” in einem kleinen Window – das Ding geht nicht zu – ich drücke noch einmal – dann lasse ich der Schimpftriade freien Lauf.

Formulare: Das kann ich mir eigentlich sparen. Was ein Tabstop ist, wissen die meisten wohl nicht.

Und so stelle ich mir relativ oft die Frage: Ist derjenige, der die Seite gebaut hat, wirklich ein Entwickler?

Laut Statistiken werden die meisten Internetseiten mit PHP gelöst – ist PHP zu einfach, sodass fast jeder diese kleine Skriptsprache kann? Ich kenne das Problem nicht genau.

Internetseite

Formulare

Wenn man bei einem Formular (mal abgesehen von einer Textarea) die ENTER Taste drückt, möchte ich, dass das Formular abgesendet wird. Des Weiteren möchte ich auch eine Bestätigung erhalten – in welcher Form auch immer. Grundsätzlich muss man sich hier fragen, ob derjenige das mutwillig “scheisse” gemacht hat. Denn diese Funktionalität ist ohnehin schon der Default. Das jeweilige Event müsste man ohnehin abfangen?!

Windows/Modals

Sollte die Seite Fenster haben, die erscheinen, wenn ich eine bestimmte Aktion ausführe, sollte innerhalb dieses Fensters auf meine Tastatur reagiert werden.

Jetzt stellt sich mir noch die Frage: Was nervt euch an Internetseiten – mal abgesehen vom Aussehen an sich?

 

review_js

Die JavaScript Open Source Kiste hat wieder zugeschlagen: Review von Julian Gruber

25.02.2013

Wie bereits beim letzten Mal krame ich heute wieder in der Github Kiste von Julian Gruber, aktiver “Open Source Entwickler” und “Nodegeil”. Jeder Web Developer hatte schon einmal den Fall, dass er seine Webseite schnell und einfach in verschiedenen Auflösungen überprüfen wollte.

Mit dem Open Source Package ”Review” ist das kein Problem mehr!

Das Tool ermöglicht es, Screenshots in verschiedenen Auflösungen zu erstellen.  Dies funktioniert entweder über CLI oder über eine eigene Implementation. In dem folgenden Beispiel wird ein Review Server mit dem Namen My Review erstellt. Dieser Service überwacht anschließend http://google.com.

open soruce reviewIn den folgenden Auflösungen wird anschließend ein Screenshot erstellt: 1280×1024, 1900×1600 und 800×600. Diese wiederum werden auf einer von dem Server generierten Seite (in unserem Fall: http://localhost:4000) dargestellt.
So erhält der Nutzer eine Übersicht der jeweiligen Internetseite und kann diverse Inhalte auf Ihre Gültigkeit prüfen.

Damit review verwendet werden kann, wird phantomjs benötigt. Ab der Version 1.7 stehen Cookies zur Verfügung.

Installation

Die Installation ist sehr einfach: Über den NPM lassen sich alle Abhängigkeiten problemlos installieren. Folgende Befehle werden für die Library als auch für das CLI benötigt.

Hier geht es zum Projekt! 

Open Source Kiste: traffic-light

15.02.2013

Gerade in Dokumentationen ist es oftmals wichtig, dass man eine Übersicht bestimmter Ressourcen erhält und deren Erreichbarkeit repräsentiert. Genau aus diesem Grund gibt es das Projekt traffic-light von Julian Gruber (@juliangruber). Nehmen wir an, wir möchten eine Dokumentation einer API erstellen und deren Ressourcen in einer Übersicht darstellen.

Nun möchte ich nicht nur wissen, ob der jeweilige Service erreichbar ist, sondern auch, wie schnell dieser antwortet.  Das Node.js Package unterscheidet zwischen:

StatusCode 200; Timeout nicht überschritten

green

 StatusCode: 200; Timeout überschritten

yellow

StatusCode: nicht 200

red

Zusätzlich hat man die Option RegEx auf die Response anzuwenden. Eine volle Dokumentation zu traffic-light findet man auf GitHub.com!

Lange ist es her – eine neue Stelle

14.10.2011

Es ist schon wieder einige zeit her, dass ich einen Blog Beitrag geschrieben habe. Heute kann ich endlich einmal wieder meinen überaus kreativen Senf abgeben. Grund für meine Abstinenz: die letzten Wochen / Monate war ich leider vollkommen ausgebucht. Wer sich auf einen technischen Beitrag von mir freut, wird heute aber enttäuscht. Trotzdem wird es interessant: es geht um eine Art “Stellenausschreibung”. Mein Arbeitgeber, die BörseGo AG, ist derzeit auf der Suche nach einem “Senior Web Application Developer”. Die Firma ist laut „Great Place to Work“ einer der besten Arbeitgeber Deutschlands (mehr Informationen: http://bit.ly/pdgpXq ). Und das merkt auch wirklich jeder Mitarbeiter täglich. Neben etlichen Gadgets (Massagen, frei Getränke,…) bietet die Firma auch regelmäßig Events, gemeinsames Essen, sportliche Aktivitäten und vieles mehr an.

Jeder, der sich derzeit beruflich neu orientieren mag, sollte sich auf diese Stelle stürzen. Weitere Informationen gibt es hier.

Was einen guten Entwickler ausmacht!

18.05.2011

Seit längerem hatte ich nicht die Gelegenheit, einen neuen Beitrag zu verfassen. Heute ist es mir endlich mal wieder gelungen. Das Thema dreht sich dieses Mal nicht direkt um die Entwicklung von Software, sondern um die Eigenschaften eines Entwicklers.

Denn: was macht eigentlich einen guten Entwickler aus? Diese Frage stellt sich wohl jeder einmal. Produktivität? Abstraktionen auf hoher Ebene? Viel Ahnung vom Fach? Eigeninitiative? Kreativität? Selbstständigkeit? Kommunikionsfreude? Planung bis ins letzte Detail?
Man könnte sagen: von jedem etwas. Leider kann jede dieser Eigenschaften auch negativ auffallen bspw. durch Overengineering oder durch zu hohe Produktivität (hacken). Ich weiß, das hört sich jetzt am Anfang etwas komisch an – hat aber alles seine Richtigkeit.

Wenn ein Entwickler auf einer zu hohen Ebene Abstrahiert, kann es passieren, dass die Produktivität leidet (er verstrickt sich in Themen, die eigentlich total irrelevant sind, wodurch er mehr Zeit benötigt) – aus Sicht eines Unternehmers ist dieser Punkt durchaus schlecht. Auch wenn der Ersteller hierbei denkt, dass man diese Komponente immer und immer wieder verwenden kann.

Was häufig vergessen wird ist die Dokumentation bestimmter Komponenten. Ehrlich, man muss nicht alles dokumentieren – aber es gibt durchaus Projekte oder auch Bestandteile, die beschrieben werden müssen.

In der Uni lernt man gerne, dass Datenbanken immer nach bestimmten Konformen angelegt werden müssen. In der Realität wird man dann eines besseren belehrt. Denn nicht alle „Tricks“, die man lernt, sind sinnvoll. Das hat dann entweder mit Performance zu tun, oder einfach nur mit der Tatsache, dass gewisse Themen, die man lernt, nicht mehr den aktuellen Standards entsprechen.

Viele Entwickler Planen gerne (auch ich). Das bedeutet für Fachleute: UML Diagramme, Ablauf Diagramme und vieles mehr. Doch eigentlich sind derartige Themen überflüssig – ein grobes Konzept auf Papier reicht aus, um bestimmte Komponenten zu erstellen. In einem späteren Schritt können Ablauf als auch UML Diagramme erstellt werden, um es anderen Entwicklern nahe zu bringen, wie das Ganze funktioniert.

Selbstständigkeit ist gut für die Kollegen denkt man zunächst – aber auch dieser Punkt hat seinen Nachteil. Durch Rücksprache oder auch erhöhte Kommunikation können Denkfehler umgangen werden. Wodurch wir schon zum nächsten Punkt kommen: die Kommunikation.
Besprechungen sind ein Muss – das weiß jeder. Denn ohne Kommunikation ist das Unternehmen und auch die Mitarbeiter nichts wert.
Durch zu viel Rücksprache wird auch Zeit verschwendet, die nicht sein müsste.

Man sieht also, dass jeder Punkt Vor- als auch Nachteile hat. Was meiner Meinung nach einen guten Entwickler ausmacht ist relativ einfach – „Der Mittelweg“:

Kein Overengineering – aber auch nicht „einfach mal hinhacken“.
Rücksprache mit Kollegen – aber nicht permanent!
Dokumentation und UML als auch Ablaufdiagramme – zuerst sporadisch, dann digital für alle.

Eure Meinung?
Als kleiner Anreiz: Ich habe von einer kleinen Schule, die sich um die Ausbildung von Entwicklern kümmert, ein Buch bekommen, dass ich selbst schon kenne: Javascript Patterns von Stoyan Stefanov.

Jeder, der einen produktiven Kommentar hinterlässt, hat die Chance es zu gewinnen. Viel Spaß!

node.js – Eine Einführung (HTTP Log Server)

26.04.2011

In der letzten Zeit hatte ich nicht viel Gelegenheit, einen neuen Beitrag zu schreiben. Heute ist es endlich soweit! Wie soll es auch anders sein – heute geht es um Javascript. Zwar nicht Clientseitig – aber trotzdem ist und bleibt es Javascript. Node.js ist ein Event basiertes I/O Javascript Framework für die V8 JavaScript-Engine (vergleichbar mit Twisted). Node kann für viele Bereiche eingesetzt werden – meiner Meinung nach ist der Wichtigste jedoch WebSockets. Jedoch möchten wir uns heute nur mit der Einführung beschäftigen.

Die Installation:
Die Installation ist schnell beschrieben und vollzogen. Grundsätzlich muss der jeweilige Server, auf dem Node installiert werden soll, nur folgende Befehle ausführen:

Option (nicht notwendig):

Setzt die Anzahl der parallelen Jobs.

Anschließend wechselt man in das node/ Verzeichnis und führt dort folgende Befehle aus:

Zusätzlich ist es zu empfehlen, NPM (ein Package Manager) zu installieren:

Anschließend können Pakete wie folgt installiert werden:

NPM is a package manager that has become the de-facto standard for installing additional node libraries and programs. Here’s the quick and easy one-liner for installing on Unix.

Wenn das ganze getan ist, kann Node.js verwendet werden.

2. Die ersten Schritte
Node.js bietet wie o.g. viele Möglichkeiten – jedoch sind die meisten davon für den Anfang etwas übertrieben. Heute möchten wir uns zunächst einmal mit etwas einfachen beschäftigen: Einem HTTP Log-Server. Ziel ist es, unsere Daten in eine Log-Datei zu speichern (in diesem Beispiel /var/log/node.log), und diese mit einem MS Timestamp zu versehen.

Code:

Erläuterung:
Jedes Modul kann in node mit require geladen werden. Also Beispielsweise:

Diese Module können dann benutzt werden. So kann man mit http nun einen neuen Server erstellen, der auf einen bestimmten Port lauscht. Grundsätzlich ist es so, dass der Server keine Response liefert. Deswegen kann im CallBack eine Ausgabe definiert werden:

Den Request kann man mit dem Modul URL weiterverarbeiten:

Nun haben wir: params.query.message – also die jeweilige Message, die der Nutzer mitgibt, als Parameter zur Verfügung.

Jetzt müssen wir nur noch die Nachricht mit einem MS Timestamp in einer Datei speichern:

Wichtig: Die Datei muss zunächst geöffnet werden, damit das File-System Modul weis, dass die jeweilige Datei schon Content besitzt. Andernfalls wird die Datei immer wieder überschrieben.

3. Weiterführendes
Node.js API Documentation
FS
HTTP
URL

Older Posts