Adam Pohorecki

Test first, ask questions later

AngularJS talk at meet.js

| Comments

On the 20th of April this year I gave a talk at meet.js about AngularJS. It was a much shorter (30min vs 1h) version of the one I gave at the 33rd Degree Conference a month before.

Since it was a JavaScript meetup, most of the listeners were already familiar with JS MVC frameworks, and a fair percentage of them was already familiar with AngularJS. That’s quite impressive if you consider there were well more than a hundred developers there.

Not having to explain that SPAs are now a viable choice for writing web applications saved me some precious minutes and there was a lot more audience participation than I usually encounter - a good sign that the people could relate to what I talked about.

If things progress the way they do with AngularJS adoption, maybe the next time I talk about it I will be able to talk about advanced application patterns in AngularJS instead of introducing it for the nth time:) Fingers crossed.


The presentations on meet.js were not recorded, so there’s no video.

Clojure talk at Lambda Lounge

| Comments

On the 28th of March this year I gave a talk about Clojure on the inaugural meeting of Krak√≥w’s Lambda Lounge.

With the questions from the audience this talk run way too long - over an hour and a half. I definitely tried to cram too much content into the presentation - from protocols and multimethods, through macros, first-order functions, immutability to concurrency constructs. Most of those things really deserve a presentation of their own.

Protocols and Multimethods

If you ever used an Object-Oriented language like Ruby, you are probably familiar with the concept of polymorphism. Since Clojure is a functional language and it’s primary unit of composition is a function, you’d think that by using it you have to sacrifice polymorphic dispatch, but you don’t.

Even better, Clojure’s polymorphism is much more advanced than that of Ruby, and allows you to dispatch on arbitrary properties of any number of function arguments. Defining type relationships is also more powerful, since they can be defined on a per-function basis (if needed of course). Function-first approach also saves us the headaches of naming conflicts that could happen when including multiple modules into a class in Ruby.

Functional Programming

Functional programming is all the rage right now, but many people seem to think that it’s all about using first order functions. Once you get to use it however, you suddenly realize that the thing that makes the biggest difference is state management and immutability.

Immutability not only helps in multithreaded environments, but it also makes reasoning about code much easier, because any state change made very explicit by forcing functions to return updated data. This approach to handling state also helps testability by separating your code into the functional core (super easy to test), which you can unit test to your heart’s content and imperative shell (interaction with the external world, state management), which you can easily integration test, because there are only a couple of paths possible through it.

Concurrency Constructs

I spent a good deal of time in my presentation showing a laundry list of Clojure’s concurrency constructs, which certainly are plentiful and seem like a very nice addition to java.util.concurrent. So far I only used atoms, but I don’t really deal with multithreaded apps much, hopefully one day that will change:)


The presentation unfortunately wasn’t recorded on video.

AngularJS talk from 33rd Degree Conference

| Comments

On 15th of March this year I gave a talk about AngularJS on the 33rd Degree Conference. Instead of trying to introduce the building blocks of AngularJS like I did a couple of times before, this time I tried to concentrate on the things that I consider the biggest advantages as compared to other JS MVC frameworks.

Two-way data binding

Something that really changed the way I write JS code is two-way data binding. It removes a ton of boilerplate code from your applications and allows you to completely remove the coupling of your controllers to DOM. Honestly, I can’t imagine using a framework that does not have this feature any more.

AngularJS is POJO

The code you write in AngularJS is mostly written in Plain Old JavaScript, without the need to inherit from any framework base classes or introducing a custom object model. This gives you a lot of freedom when it comes to modeling your domain, saving you from putting most of your logic on your “model classes”, which many other solutions seem to default to. The fact that pretty much all the code you write is Plain Old JavaScript Objects also helps a lot with testability, since isolating yourself from the framework is much easier if your are not inheriting from classes you don’t own.


Unfortunately the talk was not recorded, so there’s no video, but I hope the slides alone will give you some idea what I talked about.