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.

Why Coding is and is Not The New Literacy

Literacy is a direct method of communication. Coding is an indirect medium of communication. When a child learns to read and write, that iconography is directly applicable to all mediums of visual communication. The child can take a pencil and paper, a paintbrush, word processing software, or a stick and some sand and convey any information or idea that is within their powers to articulate. Their communicative ability is limited only be their language. They can also absorb information through equally diverse channels.

The ability to code offers no analogy in this regard. Coding is essentially the processing of information, such as mathematical representations of reality (units and volumes) or sensory-dependent data such as written language and images and sound.

The ability to code does not confer the ability to communicate directly, but rather to newly organise pre-existing modes of communication such as language, images and sound. While new hardware and software will ultimately offer potential to interact in new and exciting ways (video telephones, brainwave sensing, etc), the programming of these innovations are not the communication that these innovations offer. Your grandmother does not need to know how to code a thought-transfer device in order to kuse the thought-transfer device that coders will ultimately help develop.

Coding is not the new literacy because it will never be a requirement that every man, woman and child must know how to code in order to communicate fully. It is a function of the development of communication, not its application. As such, it is more true to compare coding to skills such as book-binding, or newspaper printing. It is sufficient for a relatively small proportion of the population to understand it in order for its benefits to accrue.

I understand the value of coding. It is good and necessary that coding will become more widespread and less alien to average people in the coming decades. But those who compare it to literacy do not understand the value of literacy.

-- Pierce Gleeson

When people describe programming as ”the new literacy” they don’t mean that programming fulfills similar cognitive purposes, but that programming replaces literacy in forming a new intellectual gap and in that regard, the observation is right.

Actually for this argument to work, we need to define the term ”programming” a little better. The important bit is not to ”be able to program a computer”, but instead to have an understanding of how algorithms process information and how the workings of our world is more and more shaped by machines and mathematical abstractions. Little, specialized parts that work together, adhering to strict rules to form new, more powerful capabilities.

If studying computer science has tought me one thing, it's how to break down problems into parts, strip away unnecessary elements until its essence lays bare and a solution almost presents itself. This is the core qualification of computer science. Internalizing this way of thinking changes how you approach everything.

Almost anyone can read nowadays but not that many people have generic problem solving skills. Programming is at its heart formalized, applied structured problem solving, combined with a bit of syntactic knowledge about whatever language you happen to use. You don't have to have a programming education to be able to program.

Being able to do something and actually doing it are different things, the important bit here is to be able to program. You almost automatically acquire this ability whenever you occupy yourself with structured thinking, in science or business.

In a society obsessed with information and efficiency there's no denying that efficient problem solvers have an advantage as much as the literate few had over the illiterate in the past.

REST in Place 2.0

Two weeks ago I began rewriting REST in Place as a gemplugin for the Rails 3.1 asset pipeline. I just pushed the final version 2.0 to github and rubygems.org and want to give some hints on the new direction of the project.

REST in Place has never been more than a proof-of-concept for me. It worked, pretty well even, so I never bothered much to develop it further, especially since integrating JavaScript code with Rails apps was a bit of a pain. I did only the barest, necessary maintenance and never actually realized that there are people out there using it.

When Rails 3.1 came out, there was finally a way to properly integrate the code into Rails, so I sat down on a weekend and made some massive changes to REST in Place:

  • No more standalone
    Since I don't think anyone is using it in a different way, REST in Place is now a pure Rails 3.1 gemplugin using the asset pipeline
  • Specs
    To facilitate development of new features and refactoring, the app now has a Jasmine spec suite in the testapp. It can be run by visiting http://localhost:3000/jasmine
  • CoffeeScript
    Because if you're not using CoffeScript there's something wrong with you. It makes JavaScript bearable again.
  • Proper CSRF token support
    This was hacky in the past but for a while Rails includes a standard mechanism for providing CSRF information to JavaScript running on the page.
  • Automatic detection of include_root_in_json setting in Rails
    Through the magic of erb and the asset pipeline, REST in Place can detect how you've configured ActiveRecord.
  • BC breaking interface changes
    Two major things have changed that might trip you up:
    • The default css class for REST in Place is now rest-in-place and not rest_in_place.
    • Elements with that default class are initialized automatically on document.ready.
    • The jQuery function to intialize elements with a REST in Place Editor was renamed from rest_in_place() to restInPlace().

All this is now available in a nice gem. All you need to do is add gem 'rest_in_place' to your Gemfile and you're rollin' (You might want to take a look into the README first).

Now that I have CoffeeScript and specs, development of new features can be done much faster and easier. Some things I have planned:

  • Differentiate between manual abort and a failure
  • Validations/proper error responses
  • Maybe a nicer set of default widgets and UI improvements
  • Rails view helpers

Especially the last two points go a bit against my original intentions for REST in Place, but if it helps more people to use it, hell, why not.

Unfortunately, these changes have come with a very bad timing. One day after I pushed the first beta of 2.0 to github, Ryan Bates did a Railscast about in place editing. While REST in Place is mentioned there, he's showing Best In Place, a pretty extensive fork of my code that already has most of what I just wrote (asset pipeline, specs) or am going to write (validations, helpers).

Well, as frustrating as that was, I didn't come as much of a surprise, considered how I've neglected REST in Place's development in the past. I won't repeat that mistake again, promise.