AngularJS Meetup Berlin – Expectations and the Future

In April 2013 I initiated the first AngularJs Berlin Meetup at co.up, followed by two other meetups in May and June. Although the first meetup attracted quite a lot of people, the next two left me with a mixed feeling.

My original idea was very simple: find other AngularJS developers to exchange ideas and experiences. Unfortunately most of the people that showed up had no former AngularJS experience.

That's not a bad thing at all! Quite the opposite: I love passing my enthusiasm for the framework to others. But this leaves me in a tough sport for the meetups:

I don't want to give an introductory talk every time. I gave one during the first meet up and another one at the apps.berlin.js meeting in June. On the other hand, I don't want to bore beginners with endless discussions about advanced techniques or very specific problems.

AngularJS as a topic is too specific to have talks and presentations at every meetup. I'd rather keep it as what I originally had planned: an informal get-together to discuss Angular's design, solve specific problems, answer questions to beginners or just exchange ideas about web development in general.

Maybe all I need to do is to communicate this concept better to help people have a better idea what to expect.

I would like to get some feedback from you on this? What directions should the AngularJS meetup take in the future? Please leave comments below:

AngularJS Talk apps.berlin.js May 2013

During the apps.berlin.js in May i gave yet another, more simplified introduction to AngularJS. In that talk I created a short Todo-Application using Hoodie as a persistence backend, showing the vary basic elements used to assemble an application.

The example app for that talk is at http://github.com/janv/yatl, the slides are available here: AngularJS Example.

Code Literacy oder Digitaler Alphabetismus

Der folgende Text ist eine deutsche Übersetzung von Why Coding is and is Not The New Literacy die ich für das Code Literacy Blog geschrieben habe. Hier fehlt das Originalzitat von Pierce Gleeson, der nur auf Englisch im ursprünglichen Post vorliegt und ohne den der erste Absatz einwenig den Bezug verliert.

Wenn Menschen im Zusammenhang mit Programmierung von "Code Literacy" oder "digitalem Alphabetismus" sprechen, ist damit nicht gemeint dass Programmieren eine dem Lesen und Schreiben ähnliche Grundfähigkeit ist, sondern dass Programmieren die Beherrschung von Schriftsprache als Unterscheidungsmerkmal der intellektuellen Elite ersetzt.

Damit diese Argumentation nachvollzogen werden kann ist es nötig, zunächst den Begriff des Programmierens zu klären. Das wesentliche ist nämlich nicht, in der Lage zu sein, tatsächlich Computerprogramme zu schreiben. Wichtiger ist, ein Verständnis dafür zu entwickeln wie Algorithmen Informationen verarbeiten, wie unsere Welt zunehmend von Maschinen und abstrakten mathematischen Modellen geformt und gelenkt wird, kleinen hochspezialisierten Teilen die nach strengen Regeln zusammenarbeiten um neue, mächtigere Fähigkeiten zu entwickeln.

Wenn das Studium der Informatik mich eines gelehrt hat, dann Probleme in ihre Teile zu zerlegen und nebensächliches vom wesentlichen zu trennen, bis sich die Essenz offenbart und sich die Lösung fast von selbst präsentiert. Genau dies ist die wichtigste Fähigkeit der Informatiker. Ist diese Denkweise einmal verinnerlicht verändert für immer die Herangehensweise an Probleme jeder Art.

So gut wie jeder kann heute lesen und schreiben, aber nur wenige Menschen verfügen über allgemeine Fertigkeiten zur Lösung von Problemen. Programmieren ist im Grunde nichts anderes als das: formalisiertes und strukturiertes Analysieren und Lösen von Problemen, kombiniert mit eher unwesentlichem Hintergrundwissen über die Syntax der Programmiersprache in der man sich gerade bewegt. Um Programmieren zu können braucht man daher eigentlich keine Ausbildung als Softwareentwickler. Jeder der schonmal mit Excel gearbeitet hat, hat schon programmiert, vielleicht ohne es zu wissen.

Theoretisch in der Lage sein etwas tun zu können und es tatsächlich zu tun sind zwei sehr verschiedene Dinge. In diesem Fall ist es wichtiger, theoretisch und allgemein zu verstehen was beim Programmieren vor sich geht, nicht die praktische Erfahrung aus Jahren in der Softwareentwicklung. Dieses Verständnis kommt fast von allein wenn man sich mit strukturiertem Denken beschäftigt, sei es in der Wissenschaft oder der Geschäftswelt.

Es lässt sich kaum verleugnen dass in einer Gesellschaft die besessen von Informationen und Effizienz ist, Menschen die Probleme lösen und Systeme durchschauen können einen wesentlichen Vorteil haben, so wie es in der Vergangenheit Menschen mit Schriftkenntnis gegenüber Analphabeten hatten.

AngularJS introduction slides

At the Barcamp Ruhr 2013 I gave a spontaneous introductory talk about AngularJS. Because I wanted to show live coding within the presentation and also demonstrate the power of AngularJS, I used reveal.js and wrote my own little version of jsfiddle that

  • Had an iframe next to a textarea
  • Offered presets that could be loaded into the text-box
  • Loaded the code in the textarea into the page in the iframe
  • All in barely over 100 lines of code

Being lazy first, then busy with the move, I finally got around to releasing the sourcecode for the presentation on github

AngularJS Meetup Berlin

AngularJS-Berlin

Even before I actually moved to Berlin I started a Meetup/Usergroup for developers interested in AngularJS. Once a month we meet to discuss our experiences working with AngularJS, find answers to questions and introduce curious newcomers to the framework.

Planning is currently done through lanyrd, with the usual rhythm being every second wednesday of a month at the co-up coworking space on Adalbertstr. 7 in Kreuzberg.

Opera using Webkit

Opera announced today that they would be using Webkit as their rendering engine. Some people did not like that move and voiced concerns on their favorite social networks, bemoaning the lack of competition and diversity in the browser space.

Are you fucking kidding me!?

Competition and Diversity brought us the great browser wars. Competition is good if you want differentiation but if

  • The goal is to conform to standards as strictly as possible
  • Differentiation in rendering isn't driving sales (not that you were earning anything with the browser to begin with)

having four Teams (Webkit, Firefox, IE, Opera) working on different solutions to the same problems is a huge waste of effort that could much better be spent moving Webkit lightyears ahead.

Differentiation is good for selling cars, but not for implementing technical specifications.

Fizzbuzz in Haskell

Getting into the groove again.

Apparently this thing does not care to preserve whitespace. View raw for great justice.

Gabe Newell: Reflections of a Video Game Maker

How to do nested views in AngularJS (Hint: Don’t)

Starting to use AngularJS in November was an eye-opening experience. Angular does application architecture like would have done but with a level of polish and refinement that I could never have achieved.

That said there was an issue I encountered early that also comes up from time to time on the AngularJS mailing list, namely that of nested views. Angular has facilities to watch the location/history and control an ngView directive in response, but it only supports one ngView per app. How could you build a nicely structured application with that when you have nested levels of hierarchy?

It took my a while to realize that I was think in the wrong direction, coming from a Backbone project and doing years of Rails development.

Views are not what you use to structure your application!

In fact, views are more of a crutch, a shortcut, to create structures similar to traditional websites, only with angular as a driver. When developing a web application, the way to deal with complex interfaces is to use, in combination:

  1. Scope objects/variables that store your desired view state explicitly
  2. ngSwitch directives on this view state
  3. Directives to include custom templates/perform complex DOM manipulation behavior

Stop thinking of your application in terms of views that need to be loaded. That kind of thinking aligns better with imperative frameworks but doesn't work well in angular.

Think instead of components that fulfill a particular purpose. Define the components as directives, passing objects into your components, manage view state explicitly using simple objects or single variables in your scope. Angular is declarative and data-driven at its heart. Therefore decisions over what to display belong in the directives really, either as part of your linking functions or as ng-switch directives in the templates. They should never be managed in a controller although that seems to be what many people instinctively try to do when getting started with angular.

Defining multiple views that are manipulated imperatively goes against the core concept of angular.

Those approaching angular with concepts from other JS frameworks will have a hard time realizing the full power of Angulars clean separation of concerns.

To new shores

After almost five years, I quit 9elements at the end of October 2012. This wasn't easy for me as I have been the company's second full-time employee, knowing them from the beginning, and accompanied Sebastian, Eray and the rest of the team through good times and bad. Seeing an agency grow from a bunch of friends hacking in a tiny apartment to a company with more than a dozen employees within a short timeframe through creativity and craftsmanship was thrilling and I'm proud to have been a part of this. During this time, 9elements was never just an employer, they were dear friends and I'm glad they still are, even though I'm not working with them anymore.

Developing software there was my first actual full-time job after leaving university. I've never worked for anyone else (not counting several short internships during my school and university time) so after five years I felt the need to go out and make new experiences. Despite always wanting to, I never managed to leave the Ruhr area and go to Berlin. At every occasion, there was always something or other that held me here. After school, I decided to go to TU Dortmund to study with a classmate. During my studies, I was too busy to make the move and towards the end of my diploma, it was clear that I would join 9elements.

But now, in September, an opportunity presented itself to join Sascha, Paolo and Stephan at Thriventures, a startup working on a promising cloud based content-delivery solution, and move to Berlin. This was a tough move, pretty uncommon for me, as I've always been someone who likes safety and comfort, but now that the decision is made I'm excited and looking forward to use my knowledge and experience to develop a great product in a great team.

At Thriventures I do primarily frontend development. In the future I probably won't be writing and talking about Rails anymore, but instead try to spread my love for AngularJS and my frustrations with Javascript ;)

For now, I'm working from home most of the time, waiting for my girlfriend to finish her bachelor thesis. In April we will finally move to Berlin.

Looking forward to meeting you there.