xtc Berlin

Late Tuesday evening, the night before the ALE conference started, I sat in the hotel bar of the venue talking to people who had arrived early. Looking around, I thought, "cool, it's like an extreme tuesday club in Berlin". Since then I've been thinking about what it would take to actually create something like this in Germany.

So what is the extreme tuesday club?

A regular London meeting (weekly) for Agile/XP/Kanban/Scrum newbies, practitioners, and experts. (*)

That's not very elaborate but I like that it casts a fairly wide net in terms of target audience.

There are already a lot of different software and agile related user groups in Berlin and I like what I've seen of them so far. But each of these only cater to a specific topic or technolgy.

I'm looking for something less formal. Have a beer, talk to people about what they're working on, share war stories, cross-pollinate new ideas, ask for help or give help, if wanted. I would hope it would be as inclusive as possible. So, newbie or expert, programmers, PM/POs, design people, start-uppers, whatever - as long as you care about what you're doing and want to talk with people about it, it should be fine.

I did a little open space session at ALE on this and there seemed some general interest and I said I would just try and get this rolling and just see what happens.

Someone suggested the Cafe 100 Wasser as a pub to go to. And that's where I'll be, this Tuesday from around 8pm onwards. I'd be happy for you to join me. If you do plan to come, please let people know on Twitter.
[we've since changed pubs around quite a bit. Twitter is probably the safest bet to find out where people are. We're now usually at the Prater Garten in Prenzlauer Berg]

Some closure (ha!) to 7 Languages in 7 Weeks

I'm currently trying to work through a backlog of things I've been meaning to blog about. And at the top is this post. The whole experience deserves being wrapped up properly. But I'll keep it brief.

When last I wrote about it, I was somewhere in the middle of week 6, working with clojure. This is probably my favourite of the languages in terms of learning new things and offering new perspectives while also having enough momentum that I might actually be able to do something with it at some point. I really hope this doesn't fall victim to my inherent lazyness.

The last week dealt with Haskell. At this point I was so busy with moving apartments and starting my new job that I barely managed to read the chapter but didn't get to try the examples. It sounded interesting but maybe a bit too strict. Others in the study group seemed to like it a lot though.

So, what's left to say. I really appreciated the study group and being able to learn from other people's code on github.

I enjoyed the weekly google hangout sessions with the others, when I was able to join them. I particulary liked how aimee facilitated those, keeping track of threads of discussions and making sure everybody got to say something.

The book requires quite a bit of commitment to get the most out of it but where I did that I felt it was well worth it.

I certainly recommend doing this together with other people. And share your experience with the world. 

All in all, I stick to what I said in my first post on this.We live in amazing times!

Learning clojure just in time

It looks like we've moved to clojure at just the right moment.

As mentioned, I started using emacs for the first time again in ages. While I still struggle remembering all the useful key combos I did get a little bit of help in the transition by installing aquamacs. It keeps buffers in tabs and lets you use cmd-c,x,v while you're trying to remember how to work the yank buffer.

I'm really liking clojure so far. I'm finally writing tests again (not sure I actually ever did for any of the other languages) and it's nice to have that inside emacs and also have the REPL to try things out.

So, Day 1 only had two excercises. I'm going to just point to aimee's entry on that, because we both came up with pretty similar code.

But let's look at the second exercise

Write a function called (collection-type col) that returns :list, :map, or :vector based on the type of collection col.

I got the following:

I wasn't quite happy with repeating the col argument for each condition. So I started to play around with using the various test methods (list? vector? map?) as keys in a map and then filtering the keys based on the collection argument given. I eventually gave up on it, because it is a rather silly approach. But it was an interesting opportunity to play around with the language.


Then I noticed multi-methods and became interested. Method dispatch based on the result of a function applied to the arguments of the method. This is pretty powerful and will probably take a while to get comfortable with. I used the rather simplistic approach of dispatching on the class to do the second exercise again.


This is silly, too. And it works pretty sloppily. The empty list creates an instance of PersistentList$EmptyList which doesn't seem to match PersistenList. But whatever, it's good enough and it got me thinking about multi-methods. There is more on those in this blog post.

And now it's on to day 2, where apparently we see the list comprehensions I was so impressed with in Erlang enter clojure, too.

Excuses, Excuses. Also, Emacs.

My, I've been a bit lazy, I guess. Has it really been that long?

Starting a new job and trying to find a new place to live has taken quite a bit of my time. So it was that during the Prolog week I started to struggle finding the time to do the examples. Then during the Scala week I didn't do much at all other than reading the chapter. But with Erlang I had some more time again and at least managed to do the day 1 and 2 stuff. With Clojure this week I hope to give it even more attention.

For all of it, I neglected writing about it. So to get this rolling again I'll do a quick rundown.

Prolog

Prolog is old and weird. The book compares it to Rain Man, which seems apt. Having never done any work with any logic languages this was very new to me. It was a very big shift in thinking. I appreciated that. It's one of the reasons to work through the book after all.

I think Prolog as a language is not very practical for me. But the chapter provided some really useful basics for understanding the syntax of Erlang and for pattern matching, which shows up in the Scala and Clojure chapters, too.

Scala

Scala was, as mentioned, somewhat neglected by me. Some of the syntax in the examples (especially for the actor stuff) seemed a bit weird to me and I really should actually work through them to get a feel for it. Minor inconsistencies in syntax are probably the main thing bugging me about what I read about Scala so far. And defining your default constructor inside the class definition while still having the option for actual init methods really rubbed me the wrong way.

Still, XML as a first class language construct looks very nice and getting around some of Java's noise is also charming. I reckon we'll cross paths again at some point and I can give it a closer look.

Erlang

Next came Erlang. And that was quite a bit of fun. Having been eased into the syntax by the Prolog chapter helped a great deal. I was quite fascinated by list comprehensions. I'm not sure if their power comes at the cost of maintainability. But it's hard for me to judge that given my lack of experience with the language and syntax.

I didn't even get to play with the actor stuff but I suppose people are happy with it and specifically with the Erlang implementation.

At some point I should really revisit Erlang. It's different enough to challenge the mind to take a new look at old habits. And it looks interesting in general with its focus on concurreny.

Clojure

I'm trying to dig a little deeper this week again. Clojure is interesting to me because for a long time I've wanted to try and make sense of a Lisp language.

In the process of reading up on it I noticed that a lot of people seem to prefer using emacs as an editor for clojure. So I installed that. (As a complete Mac noob let me point out that brew install emacs and brew install emacs --cocoa are two very different things. I have yet to learn why [cf. mac noob] but you probably want the latter.)

I had been using emacs (XEmacs, to be honest) for quite a while as my primary development environment. But that was some 7+ years ago and I never really touched it again. I'm incredibly amused that a lot of the key bindings are coming back to me anyway. And it feels kinda nice. Maybe I will rejoin the battle for the one true editor.

Sidenote: emacs installation notes for anyone who bothers. From someone who has no clue what he's doing:

• brew install leiningen clojure clojure-contrib 
• brew install emacs --cocoa
• git clone https://github.com/technomancy/emacs-starter-kit.git ~/.emacs.d
• alias emacs='/usr/local/Cellar/emacs/23.3/Emacs.app/Contents/MacOS/Emacs -nw'
• lein new someproject
• add :dev-dependencies [[swank-clojure "1.2.1"]] to the (def-project entry in someproject/project.clj
• lein deps
• lein swank
• start emacs in another shell
• (you may or may not need to install some elpa packages for slime and swank and paredit and whatever. See if it works with the just the stuff from the emacs-starter-kit or otherwise ask google. I did get annoying errors doing this and have no idea why it worked in the end. Sorry.)
• M-x slime-connect
• edit e.g. someproject/test/someproject/core.clj
• execute tests with C-c C-,
• you can also do other things with the REPL inside emacs but you best google for that

I hope that can be of help.

Back to the study group...

It seems like most of us have been struggling keeping up with the pace of the book, with everyone taking the odd week off from working through all the examples. But we were lucky that it seems to have mostly been different weeks, so there was always at least one person who could explain more details about a given language. So while I was very lazy there have been a lot of really interesting posts from others in the group.

• aimee on Prolog
• and again on Scala (fuck the pope!)
• Alberto on Erlang (check out the Solution = list comprehension. It's quite impressive)
• Susan with an Erlang follow-up
• More posts here

We've also continued our weekly chats which are always a source of inspiration for me. As of recently we're using the Hangout feature of Google+ and it's really good. Since Skype keeps crashing my little Win7 netbook I'm happy to have found a better replacement.

Tl;dr

It's really nice to see how the chapters of the book build up on each other. I think the book has made me more adventurous to just play around in new languages. It is still nice to have this little virtual study group to help push me along. Technology is still awesome, too (git pushing from a train via tethering to the phone. Magic!) I reinstalled emacs after all those years.

[Insert clever play on the name Io]

And so goes the second week and the second language on our seven week trip. Compared to the first week in Ruby, I struggled a lot more with Io. It's a language with very simple rules which, for me, made the edge cases all that more confusing. I also was a bit preoccupied with other, unrelated issues and so I skimped on a lot of the examples. Thankfully, Alberto did a lot of that work and wrote about it in a series of excellent posts. If you want to know more about Io, you should really read those.

As such, I'm going to keep it short with my own observations. As an abstract, Io is a prototype based OO language where everything is either an object or a message passed to it.

• I was unable to build Io in Windows and I don't know what I would've done if I hadn't found some forum posting with a link to pre-built binaries. 
• I particularly liked the way conditionals were also just messages, apparently just extending the base boolean types
• Yet I don't really understand message precedence and how something like self sum / self size works. self size obviously gets evaluated before being passed to the divide operator, which I didn't expect
• getSlot('foo') code print will print a method definition, similar to Javascript's foo.toString() (where 'foo' is a method/function)
• sadly, that is not usable for the language constructs as they are written in C
• Io has a pretty solid concept of coroutines, actors and futures, much unlike Javascript. Quickly writing some parallel code might indeed be one of the languages strong points

It seems the book deliberately started with Ruby to ease me in and then started to get a bit more challenging with Io to progress to Prolog, which I guess will be quite a bit different from what I'm used to. 

I'm again grateful for our study group. Our little skype conference showed that I wasn't the only one struggling with Io and I'm not sure I would've gotten much out of this chapter if it wasn't for other people's blog posts further explaining things. This isn't really a failure of the book as much as I just wasn't able to commit the time to really dig into the examples.

And now it's on to Prolog, which should get interesting, as I haven't worked with logic languages before. This time, installation is easy, as there is a package in cygwin that provides the 'pl' executable. (And, once again, let me recommend also getting mintty.)

First language done; inspiration had

Continuing on through Seven Languages in Seven Weeks I've finished the chapter on Ruby. I'll quickly list a few more things I've noticed and then do a little initial retrospective.

• I was a bit confused with how method definitions apply to classes v. instances and how module inclusions and extending classes work into that
• Interestingly, I feel reminded of similar troubles I had with understanding Javascript prototypes, functions and new. 
• obj.freeze appears to be a way to dynamically declare variables final. I suppose that could be useful
• you can always pass blocks to functions even without having declared them as arguments
• there is what I'd call reverse varargs that lets you explode arrays to match method arguments using the same notation as varargs, which I quite like. def foo(one, two, *rest) …
  foo(*[1,2], 3, 4, …)
• Having things like .methods on all objects to do reflection for debugging/getting to know the language is really helpful
• if I had worked through this before and added a bit of rspec knowledge I might have been able to contribute a lot more on the occasions I paired on Ruby at code retreats

Code is here. 

So now a little bit about the learning experience. I'm greatly enjoying this so far and I think it comes down to three things.

The book

The book is great for getting you started in a language. As I mentioned on twitter I left with more questions than answers. But I now have a vague idea of where to look to find those answers. It's a really great achievement to pique the interest to go into the details of a language and to not make you feel completely lost doing so. I'm already looking forward to learning about Io.

The group

I'm also really enjoying our little virtual study group. People share their questions, answers or just share their fun in the learning. There's a lot of interesting blog posts already (aggregated here) and also quite a bit of activity on the github network for the project. I find this both liberating and motivating. It's safe ground for exposing your ignorance and at the same time I feel challenged not to slack off and actually keep working on it and do things like writing blog posts. 

The technology

And I love the technology that enables this and the fact that there are people that care enough to take part in this. We live in amazing times! Programming is fun and being able to share that with others makes it even more fun. I love that it's so easy to organize this on twitter more or less on a whim (at least my taking part was on a whim). I love that to get started reading I only needed a few clicks on pragprog (even if the kindle version has its little issues). I love that github lets me see how others solved the problems given in the book, both reassuring me that I did something right or helping me along to find better solutions. And then of course it's great to be able to just download and try out all these languages.

Seven Languages In Seven Weeks

I'm stuck trying to put my thoughts on estimation, conferences and switching jobs into writing. So many unfinished drafts, oh my!

So instead I'm now trying to write the odd post about my experience working through Seven Languages In Seven Weeks.

aimee daniells had the great idea to start an online study group for said book (not gonna type that title again, nu-uh). And since it helps distracting me from worrying about finding a new place to live within the next 3 weeks I gladly took the opportunity to join. (Sidenote: if you're looking for a flatmate in Hamburg please do get in touch.)

The book is very interesting to me because I don't know all that much about any of the languages but have been meaning to take a closer look at Clojure, Ruby and Erlang for some time. It's nice to have something concrete that gets me doing that.

The first language is Ruby. I've worked through days 1 and 2 now and here's a quick summary of what I took away from it.

Ruby has a lot of syntactic sugar. Enough to almost certainly give you diabetes. Parts of me (the old, elitist parts) feel somewhat uncomfortable with that. Other parts of me (the ones trying to get work done in Java) just feel jealous.

There were some more notes I took that I'll just list here without trying to add context (or sense)

• The kindle version of the book doesn't wrap the code examples correctly with larger text sizes. That's pretty annoying. Does no one test these things?
• When googling for the api docs one should be careful that one reads the docs for the correct version of ruby one is using. I spent 10 minutes wondering why str.match(regexp) { block } never executed the block until I figured out that that feature just didn't exist
• String and exec expansion seem to behave pretty much like in bash. Single quote string get left alone, double quote strings get processed and backticks execute native programs. (I hope I'm not misremembering my bash there)
• if and while have counterparts in unless and until. Sugar++
• Sugar++ would not actually work. Sugar += 1 does, however. And I think I like why that is the case
• Numeric zero and empty strings evaluate to true, which i find pretty disgusting
• Running in a windows shell I successfully ran into encoding issues for Umlauts. Probably Windows' fault. I hate character encoding
• Cygwin can install ruby and Umlauts look ok there. Calling the windows ruby executables from inside cygwin, which I tried first, had some really weird issues
• On that note: mintty still rocks
• Enumerable has all the nice sugar you can only get via Google's guava in Java. And with blocks it's a lot better readable
• And you can mix all that into your own classes, with just a bit of duck typing. Very nice
• All that duck typing really makes me long for some grapes
• If I understand it correctly, Hashes can lazily evaluate values from keys which reminded me of the guava MapMaker. Also very nice. 
• Hash.invert seems almost too sugary but could be useful
• Same goes for String.next. Instant tooth decay!
• A File API with permissions and methods to create symlinks? I never dared dream of that (although, wasn't there something in that regard in the works with Java, too? About time anyway)
• IO.readlines/foreach is really handy. Convenient enough to never look at perl again. 
• The automatic closing of files when using blocks is also nice. Kinda like using() in C#, implicitly. (Wasn't there also something like that coming to Java? I can't remember all the things that may or may not go into the language)
• I felt pretty clever doing Array.new(16) {|x| x+1} until I saw (1..16).to_a

Code is here.

All good fun so far.