RubyKaigi 2013 is over and it has been a very positive experience for me, I applaud the organizers and the attendees. But one incident left a bad taste in my mouth.

During a presentation, the speaker mentioned that he wanted us to come visit a conference in Taiwan next year. He gave us many good reasons of why, but one that stuck with me was that he said “Taiwanese girls are ‘kawaii’”. Kawaii is a Japanese word that means “cute”.

This was said in a joking manner. The largest room in the venue, full to the brim, lit up with cheers, applause, and laughter.

At a conference where I estimate at least 95 % of the attendees are men, how will such a thing affect how women feel about coming next year? Would this comment and reaction give the impression that this kind of conference is for men and women are meant to be looked at?

Note that I don’t mention who the presenter was. I don’t think he is a bad person, he seemed very nice. It is not only what he said that is the problem, but how almost the entire audience reacted. This is a problem in our community culture, not the fault of a single person. So I see it as my duty to bring it up, so that we can learn from it and improve. It would be much worse if I saw a problem and kept quiet about it.

Many people at RubyKaigi are also involved with RailsGirls. So there is awareness that female participation at Ruby conferences and, more importantly, in the programming community, is a problem.

I know, I know. This is not a DongleGate, nor is it a “Perform Like a Pr0n Star”. This was a minor hiccup at an otherwise great conference. But since we already have so few women here, we need to be really careful not to scare off the ones that show up.

If I was a woman, I’d feel a bit alienated. Wouldn’t you?

The Relevance Podcast episode 27 featured Tim Ewald talking about the Clojure web framework Pedestal. Here are my raw notes that I took while listening to that. I figured they might be useful for somebody else too.

What is it?

Separation between app (clojurescript) and services (clojure). Pedestal is a set of libraries, try not to use the word framework. Rich browser-based apps with back-end services. CLJS – CLJ. Why doing this? There are already many web frameworks.

• They like building stuff in Clojure. Found issues that they wanted to address, so they are using it themselves.
• There is an advantage in working with one language end-to-end. Dev/test tools, cross-compiling code, etc.
• App model separates the logic from the rendering, but all can be built in Clojure. Behaviour cross-compiled and then rendered in the browser.

Browser based apps are more exposed than server based ones. Anyone can pry it open, presents an interesting challenge. If you make a decision in the browser and updates the screen, it needs to send something to the server. If it sends a result, how does the server know this is an acceptable result? E.g. sending $1000 to someone. So don’t send the side-effect/decision, send information so that the server can make the decision. If you want a fast app and a secure server, having the same language simplifies it. No having to rewrite validation checking for decisions in two languages. Is going to be pretty important.

Server side

Services are based on an abstraction called an interceptor. Ran into limitations of Ring. Ring has a lot of work behind it, cookies, sessions, parameter mapping, flash, file info, etc. But the execution model is bound to a single thread, a request follows a thread and then returns a result. But if you want long polling or other techniques where you don’t hold but keep the connection open, without blocking a thread. Interceptors are not bound to a thread, they can release a thread and then resume processing on another one. Have worked hard to keep interceptors compatible with Ring, worked with Ring team to refactor Ring to accommodate both the classical and the interceptor approach. Can still use all Ring middleware and so on. There are leiningen templates with basic routing and interceptor plumbing.

Client side

Imagine creating a word processor as a web app. If you try to do that through event handlers and DOM handling in js, it will get messy really fast. If the possible states of the DOM explodes, you need another way of doing that, you can’t reload the world every now and then by refreshing the page. So if we maintain a separate data structure to maintain state, and javascript to render just the parts of the DOM that have changed. You don’t want to write the code that does all of that though, since the state changes might be big, so Pedestal solves that problem. Comparing the data structures and rendering based on the delta, helped by immutable data structures (?). Data model, app model (a tree) which is a list of deltas, and a renderer that uses that list of changes to change the DOM.

Why giving this away?

Still far from done. Altruism, they like open source. Relevance has a long record of contributing stuff back. Plus, a web framework these days that is not open source doesn’t have much of a chance. You also want input from the people who use it to see if it solves their problems. If they want Pedestal to grow and have a broad user base, it needs to be free. Started work on it around Halloween. Sometimes full-time of 4-5 people, some times only 20 % time (Fridays). They want to use it themselves for client work.

Ring and interceptors

Interceptor is more complex than ordinary Ring model. Don’t want to let ease of use trump flexibility. E.g. Rails has an ambient database, it’s just there. But if you want to use 2 dbs, it is not easy at all. It is a limitation. As an app grows, you want to do more and more complex things, and Pedestal has been made with that in mind. There is capability and flexibility that they feel from experience that they need.

Linking and routing

Route table maps requests onto the interceptor path. More dynamic than Ring. Anyone in the middle of the path can know where the request is going, or change it. Can read meta-data from path and make some decision based on that.

Documentation

Working on it. Chat example demonstrates pretty much all the pieces of both apps and services. App has mock service so you can run stand-alone and work on UI. Services can be worked on without app, just curl.

Debugging

Debugging is easy, you can verify from command line using curl to see if the problem is client-side or server-side. Dev-mode, going back and forth in history. Since the service is sending deltas to the app, you can debug rendering on a delta by delta basis. It is super useful for pinpointing bugs.

CORS

Support for CORS, cross-origin resource sharing (see sample here https://github.com/pedestal/samples/tree/master/cors), which makes it easier having 10 different apps using 20 different services. The coupling between apps and servers become looser.

The name “Pedestal”

Tim has a background in building architecture. A pedestal is near the bottom of classical buildings, something that you base stuff on. A good, solid base to build apps on top of.

“[I do not] carry such information in my mind since it is readily available in books.”
- Albert Einstein, when asked to recite the speed of sound

It’s a good quote, but the meaning of it is not that we should never memorise anything. If so, we could all become the best programmers we could be by investing in a lot of books and then look up the solution to any problem in there.

It is rather that we shouldn’t waste time memorising irrelevant details. We should internalize higher-level ideas, frameworks, pros and cons of different approaches, that we then can look up the details of how to implement them.

This realisation, combined with the fact that I tend to forget ~95 % of everything I read, led me to experiment with spaced repetition.

Spaced repetition is a simple idea: you memorise something and get reminders about that at different intervals depending on how well you remember it. So if I know the Japanese word for “cat” very well, I don’t need a reminder until perhaps 20 days from now. But if I am struggling with recalling the word for “Paris syndrome”, getting a reminder every few hours would probably do me good. As I remember it better and better, the reminder frequency drops off.

So whenever I read a book about programming, or anything else for that matter, I:

1. Read a chapter or two while highlighting the parts I want to remember. I don’t want to stop and write down thoughts constantly when I’m reading, since that becomes a constant source of interruptions.
2. Flip through the pages of those chapters and create question-answer pair out of each highlight.
3. Add this as a flashcard in Anki.
4. Go through today’s flashcards every evening. The flashcards I get to repeat are the ones I’ve been sucking at answering or new ones.

To make sure I don’t skip studying, I have a reminder set to 6:30 pm in my todo-app. That triggers me almost every day.

I find that the amount of stuff I remember from books now is far greater. More ideas and concepts show up in my head when I need them at work and since my books are electronic I can easily look up the details.

A common pitfall has been that I focus too much on detail. Whenever I start adding code in the answer part of a flashcard, that is a smell that I have left the conceptual domain and that I am focusing on the wrong thing. Thanks, Einstein!

Ps. Does the “don’t memorise unnecessary details” idea mean that you should have an editor that remembers the syntax for you, e.g. snippets and code generation, whereas you should focus on keeping domain concepts and problem solving techniques in your head? Is this an argument for a full-blown IDE? I think so, I don’t want my head to be an API documentation library complete with parameter ordering. Ds.

The debate of IDE or no IDE usually boils down to static or dynamic, or to helpful or getting things done. Right now, I tend to agree with both sides.

I work as a .NET programmer using Visual Studio 2010 by day, but during evenings and weekends I do mostly Ruby/Python/JavaScript in TextMate on my beat-up old white MacBook. The Mac is so slow it freezes for a second or two when I scroll to the next page in a PDF, so a heavy IDE is out of the question. Since I spend a lot more time at my day job than I do at spare time hacking, I am much more accustomed to the IDE way.

Speed and crutches

The major points are speed and editor help. Visual Studio is slow but helps you out a bit more (refactorings are soooooo easy), TextMate is fast but doesn’t reach out its hand when you are making mistakes. So when using a text editor I find myself spending a lot more time duckduckgoing (yes, I verbalized “DuckDuckGo”, so what? (yes, I verbalized “verb”, so what?)), reading through documentation or correcting stupid spelling errors.

Example: last night I mistakenly typed “.” instead of “_” in a method call, which gave me absurd error messages to the point where I felt compelled to cook dinner instead. I would have discovered and corrected this in a matter of seconds in Visual Studio. But Visual Studio is huge and requires a performant machine, otherwise you’ll spend a lot of time swearing and waiting.

Watching Zed Shaw code confirms my thoughts. He is an experienced text editor programmer and his workflow is much more chopped up than mine in Visual Studio. There is a lot more pausing because you don’t remember a method name and have to go to the documentation, which interrupts your current thought process (“what is a customer, really?”) and replaces it with another one (“what arguments are needed?”). I don’t know if this is good or bad, but it is a difference that I still am adjusting to.

Not only am I less experienced with TextMate than with Visual Studio, I am also a bit of a special case, since my internet connection is very unstable. I sometimes experience weeks without online access in my home. This makes duckduckgoing around a huge bottleneck. I’ve downloaded books and downloaded API documentation and guides with wget, but sometimes that documentation is not enough and I get stuck on very trivial problems for a long period of time.

So, Visual Studio makes coding more fluent, but seeing your work requires waiting. TextMate makes coding less fluent, but you see the results of your work much faster. Which is better?

Messy code

There’s the argument that people using IDEs as crutches make messy code, since they don’t have to think as hard about the structure. I don’t know whether this is true or not, but see Avdi’s post on the messiness of legacy Rails applications compared to static ones. I’m pretty sure the apps he mentions were not written in Eclipse.

A lot of very smart people prefer to work without the crutches of IDEs. Maybe the case is that young programmers, that don’t yet have the complex thought patterns that come with experience, make complete messes without an IDE, whereas more experienced programmers are better off without them.

Conclusion

I make a bit of an unfair comparison, since I am much more accustomed to Visual Studio. But I like both, I use a gargantuan IDE for static code and a lightweight text editor for more dynamic code. Just like everybody else. There is no winner in this war, there are only different tools for different jobs.

This blog post was written in TextMate, not Visual Studio. Go on, comment about how that means something.

At ExplainerDC we usually watch a video or do some code sparring on Friday afternoons. Last week I showed the other developers the introductory episode of Uncle Bob’s series Clean Coders. Today we watched episode 2, “Names++”, and afterwards we had a short discussion about the topic. I tried to transcribe it as we went along:

Ibrahim: I thought it was very informative and it reminded me of things taught in school. I can’t wait to see the next episode.
Kwabena: Really, you were taught this stuff in school?
Ibrahim: Yes, at NIIT.
Francis: I used to think that code was just for myself, so any name was a good name. Now I understand why good names are important for communication with other people.
Me: Yes, but it can also be important for yourself. Like if you have a CSS class called “VideoHeader” that you use in the header on both the image and video page, and you then go back to it two weeks later and forget that the class is used on both pages and make a change, then you get into trouble.
Kwabena: This video should be good for somebody who still is in school, it is important to learn this early. Also, the material was not as advanced as I thought it would be.
Me: I found the reversed scope rules confusing, how public functions should have short names and private longer, but for variables it was vice versa.
Raymond: It is because few verbs are long, they are often short but expressive.
Ibrahim: I found that a bit confusing too. Shouldn’t it just be one pattern for naming? That would make it easier.
Me: And I also think it is more important that public functions are easy to understand than private.
Ibrahim: I like the thought that we need to challenge ourselves and look at what our code looks like. It’s been a long time since I was taught by such a worthy lecturer, it was a style of teaching that really keeps you awake.
Me: What did you think of the astronomy part in the beginning?
Kwabena: I think it was related to how the egyptians didn’t have good enough tools and therefore made mistakes. Today we have good tools, like good compilers and IDEs that mean we don’t have to use type prefixes and so on.
Sylvia: The part that I liked the most was that code should read like beatiful prose.
Kwabena: But I think that abbreviations are good, GetLName is as understandable as GetLastName but makes me program faster.
Me: I think that can be tolerated if we are sure that everybody will understand them, like very common abbreviations in the business. But what will they look like to new developers in the team?

Then we got into an architecture discussion. We will most likely watch episode 3, “Functions”, next Friday.

Good: “How do I access the file system? Aha, good. Next step!”

Bad: “How do I access the file system AND mock out the file system for my tests? Wow, a feta cheese salad would be nice by now! Is Matlock on yet?”

The flow. I experience that whenever I really enjoy doing something. It is very important for making just about anything a joy. Therefore, all things that break up the flow should be eliminated. Sometimes they can’t, but it should nevertheless be the vision. TDD messes up my flow when I am taking a plunge into the world of a new programming language.

There are so many things that you need to take into account when learning a language. Not only the syntax, but the frameworks, the runtime, the environments, databases, shell/visual tools, idioms, package/module structure and so on. TDD on top of that means you need to understand more advanced architecture, mocking, TDD tools (like how do I run the tests?), etc. Important things, but they multiply the complexity level, and for flow you should ideally have only one level of complexity at any given moment.

TDD gives me a flow when I am familiar with how the general way of doing things and how to get around in the programming language, IDE, editor, infrastructure etc. But when I am new to all that, I really don’t need more levels of complexity which might put me off the whole thing altogether.

I’ve so far encountered one exception to this: learning Ruby while picking up Rails. Since testing is so deeply engrained in that experience, doing TDD and learning at the same time becomes a joy.

The problem for me is that whenever I abandon TDD and just hack, I feel filthy. I usually don’t add on tests after and manual testing is dirty testing. But sometimes you need to get off your high quality horse.

So tonight when my wife has fallen asleep, I’ll pour a glass of red wine, put on a Mogwai record and just hack. I will need a shower afterwards, but at least there will be Flow (and not just of water).

Fads are like a wave. You can either swim against them, expending a lot of energy and swallowing a lot of salt water in the process. Or you can jump up on your surf board and get a boost from the tremendous power of the ocean. Sure, you’ll be a part of something that resembles a religious cult, with the hardliners claiming that Clojure or Kanban always is better than all the options in all contexts. As long as you are aware of this and don’t let your guard down such a dangerous mentality, you can learn a lot.

The fads usually mean that a large number of people will be coordinating their focus on a leading edge topic, creating user groups, conferences and trying out the theories in different settings, before (hopefully) learning from it and moving on to the next big thing. This is progress. Why let all that energy go to waste?

Follow the fads, but be aware that they are just that.