Lately I’m reading through AI algorithms and I came across a goody which a lot of developers want to have because everybody uses it all the time and it’s really useful and that is a recommendation system.

Best known through sites like amazon or youtube: You look at A and the website tells you: oh by the way people who looked at A – also looked at B.

So the system relies on data based on the actual behavior of its users. The data comes from the behavior of the users and needs to be aggregated and then evaluated within an endless process.

The algorithms used in this area come from linear algebra and a bunch of stochastics. Typically a set of n-features is represented within an n-dimensional space and to find related entities you compute a clustering of the features or their shortest distance in n-dimensional space.

But let’s don’t go that road yet, because everybody can build a recommendation engine with some very simple ideas.

Let’s don’t care about scalability while doing that because that is a another story because the amount of data and processing time can get really big.

We don’t care about that here. Let’s only focus on some very simple ideas.

We want to build a recommendation system for a shop. We have Users and we have Items.

Each time a user X looks at an item A we want to recommend n items that other users also looked at when they looked at item A because we – of course – want that the users buy more.

1.Step: Track what all users view.

2.Step: Track for each item which users viewed them.

3.Step: Aggregate the users common items with occurrence count.

1. Look up all n users which looked at the item x.
2. Look up all items which the users of item x viewed and merge the items into a new data structure while count each items occurrence.
3. Order the occurrences by descending order.

4.Step: Take the top n results as recommendation.

The good thing about this algorithm is that you can pre-compute the recommendations for item x and you can continuously keep updating them. They don’t have to be perfectly up to date, they only get better if you keep updating them.

But there are a lot of down sides.

1. Most annoying thing is that you need to remove deleted items from all users x. You can lazily remove them by adding a hash table with delete items and while making a union looking up each item if that item has been marked as deleted and then remove it from the user’s x list.
2. The computation is simple but needs space and time.

Next time we talk about the space and time complexity and improvements. It depends on its implementation.

Syntax highlighting makes it easier for kindergarteners to program.
Douglas Crockford

And Crockford has pretty good arguments what he exactly means by that (of course a little joking):

https://plus.google.com/118095276221607585885/posts/XXkzgJEoE9v

The point that he makes is that the current way of syntax highlighting that all IDEs and editors provide don’t add any kind of additional value for the reader of the program except of looking childish and that is exactly right.

He resolves this issue by adding a feature to JSLINT which highlights the scope of the syntax.

Let’s take a look at regular syntax highlighting:

This is how jslint applies highlighting:

I must say that I am pretty shocked that we haven’t been using this highlighting earlier because for experienced, professional programmers regular syntax highlighting is pretty pointless.

The way that Crockford recommends doing highlighting actually adds real value for the reader.

You can test some code live here.

I saw something really random about programming interview question guides on the web which often completely misses the point of the whole interview question. The problem is that they distract from the essence of the question.

An example:

We have a list of n elements and we have x unknown duplicates within that list: find the duplicate elements.

If a question is so simple as this one then the answer to this is for sure not to come up with a random algorithm but to ask the right questions.

Instead you see average programmers brute forcing tens of different versions to solve this problem in the comments section, on the given website. That is just stupid because every programmer must be able to solve this anyways. That is not the point.

Only the boundaries for this algorithm are interesting which determines the algorithm.

So expect programmers to first ask for boundaries rather than trying to randomly solve this. If a programmer is not suspicious about this question then something is wrong.

Possible boundaries, as always:

• We have enough CPU time but tiny memory (QuickSort + Binary-Search, or + lineare Search comparing neighbours)
• We have very little CPU time but huge memory (Counting-Sort)
• We have in both cases plenty (Counting-Sort)
• We have both cases very tiny amount available (if n huge probably MergeSort for external devices + blockwise linear neighbour comparison, or b-tree index look up)

That is the actual question: What are the boundaries.

I typically read technical books only from people who I trust. And with trust I mean that I have the feeling that what this person says makes sense and is not expressed from a personal point view but the person tries to bring together all faces of the problem and tries to rationally make a decision based completely on arguments with consistent logical structure. In this case I saw a presentation of Nicholas Zakas on Youtube which made a good impression to me.

I think Nicholas Zakas made a pretty good job in this book by bringing together all relevant practices in the professional JavaScript development field. He’s tries to bring together all threads and options and let you decide what’s best for your project. It is focused to be really practical and he’s even going down to the level describing how to write ant build scripts for your JavaScript projects.

Topics are: programming styles, statical code analysis, organizing complete projects, testing, integration with continuous integration with scripts, minification and many more details.

As a more seasoned web programmer I already knew most of it but it was still a good read and gave me new ideas applying best practices in my projects. I wished he would have told more stories from his practical experience which have led to problematic results. Even I have in my relatively young age a lot of stories about stupid behaviours in projects which led to problems.

For web developers I can recommend reading this book especially if you need a compact view of all best practices.

You can almost calibrate an atom clock hourly by the intervals which new JavaScript frameworks appear.

One main reasons is that JavaScript frameworks are easy to write.

The other reason is that web developers are all day long on the web and spamming the web with discussion about what “the” best framework is.

To a certain extend you cannot just close the door and escape from these sphere because you have to constantly educate yourself and keep track of trends.

The downside is that you get constantly hypes to no end by childish web developers which dancing around their Macs with their Starbucks coffees in their hands.

The web was never constantly hyped that much than in the last years. In the 60s to 70s the big topic was the software crisis. In the 80s object oriented programming was the next big topic which dominated the press. Today in my opinion it’s JavaScript frameworks. They dominate the complete web due to the overrepresentation of web developers on the web who generate this junk-heap of battles for “the” next thing.

The important thing is that you have to trust you own judgement to distinguish between short lived hypes and persistent trends.

But the pure amount of stuff that get’s into your view makes it more and more difficult to reliably make predictions about the durability of frameworks or any other software or technology.

I just recently experienced it by myself. I was writing a project where I programmed the client side code purely in plain JavaScript. After it was getting messy I created in some kind of way my own little framework. After that I wasn’t really happy with that although it was working pretty fine.

However I tried to rewrite it entirely in Ember.js which was a big mistake. Because the project it relatively new, the api wasn’t really stable and the documentation was for my standards way too shallow and didn’t go really in depth in terms of practicality showing reasonably complex real world examples. Additionally the framework was just too big and somehow intransparent. It pretty much dismissed itself naturally with these factors.

Due to this experience I jumped over to Backbone.js and rewrote the code again. At some point when I was almost done I got pretty angry while I was using the framework because the abstractions were too weak and shallow that it was pretty much pointless to use this framework. It neither had any elegance nor the elaborateness of any good framework. So I wasted another full two days to learn this framework.

At this point I was about to return to my original JavaScript code because it was the most straightforward. Anybody would be able to understand it because it was really straightforward without the superficial surface that Backbone.js provides distract you from your actual work.

I took these frameworks because my judgement let me alone. I took the one which were the most hyped frameworks without actually making a judgement. At the other side I could argue that I only lost probably a week before I dismissed these framework where others spend years before seeing their mistakes, if the see what they’ve done wrong at all.

After this sobering experience I took a look at a very less hyped – but at this point more mature – framework. I won’t tell you which one because it’s not important. The important thing is that this framework had either a very light abstraction but it had the right abstraction. You just need to hit the nail on the spot.

I don’t say that the time I spent on those frameworks was wasted. I think it only will be wasted in the future – if I’m going to make the same mistakes again.

Be always careful with hypes. Especially within the short lived web developer community. Things in this area are exciting because they are very dynamic but it’s requires a huge amount of experience to judge what is important and what’s not.

Comments are an art form. Sometimes too much.

Thanks for telling me.

Methods are free. Some don’t know. Maybe.
Objects are free either. Some don’t know. Also maybe.

There is something really awful in most imperative programming languages which is the absence of tail recursion optimization.

It means that if the last thing you do in a function is to call the function itself then the recursive call is compiled into a goto, just a jump.

Why the hell should anybody need that?

First of all anything you loop can often be expression more elegantly as a recursive call, it’s often easier to work with recursion. Let’s look at an example:

This is a recursive function to compute the factorial of a number. Let’s look at the loop version:

Let’s look at an example in a functional language like Erlang:

I chose Erlang because it really elegantly handles recursion because it provides a powerful polymorphic pattern matching for function signatures. From top to bottom the function signatures are pattern matched until it fits your parameters and then it’s called. Awesome.

As you immediately recognize the loop version is the most cryptic one and keep in mind that this is a really simple example. As it gets more complicated like traversing trees and doing more elaborate stuff then the elegance of recursion fully comes to light.

But what I don’t like in imperative programming languages is that I have to think about the stack. Let’s look again:

is expanded to:

When you get to 1 to the deepest path then the stack is unwind and the sub tree returns its result to the callee function up to the root which return the final value.

I think this is nice in terms of the theoretical representation of the tree but it’s much more complicated than working with tail recursion optimization and keeping track of just one state without having to think about the stack. You have to keep this tree which consists of a function call chain in your head all the time, this is for my taste way too error prone.

Here JavaScript and Closures come in to save the day:

You think the syntax is the most ugly yet? You are absolutely right, that’s what you get when you have badly designed language.

But still, we used JavaScript’s closures doing recursion without having to keep track of the stack. We just have to focus on the current value of factorial in every recursion step.

As your recursion gets more complicated and you keep changing more stuff than just one variable then this is the more transparent form.

I just started a new small library with handy JavaScript functions called SCHICK.js

The first function is to query arrays and objects:

Example:

The next interesting enhancement would be to allow wildcards:

I just recently finished another project which made me think again.

So let’s describe a typical day and I’ll tell you where the problem is.

You come into the office and you still have 10 things to do from yesterday. You have received about 20 emails about many little things that need to be fixed and you have to write them back and everybody is responding something that you have to read again.

During the day also many people are calling which forces you to add more stuff to your to do list although you try to solve issues on the spot. But often you need to tell the people to write you an email so you can work on that issue later and write back. So another issue which you need to keep track of in your head.

Of course you also get support calls and mails during the whole day which you have to filter and decide their priority and also write again emails or call customers back.

Suddenly people come in or call you because they need some small registration until tomorrow for upcoming trainings. It only need to store the data inside the database and send an email confirmation back to the person who registered and the training managers.

Now your calendar is popping up because in 15 minutes you have a meeting with someone and the conference the room next door is already occupied. So you need to find another free room for the meeting because you cannot bother your two co-workers with an one hour meeting at your desk.

You go out for 5 minutes to check if a room is free and come back and you had also 2 missed calls.

However the project that you were working on has two days left but the registration page needs to be up until tomorrow morning. So you start working on that.

You just hack a script together because you need to go on with your to do list and you know that you will have via emails many back and forth discussions until the page will be ok to go live.

The next day they call you because they also need an email confirmation link and to generate an Excel export for all attendees.

Alright so you need and protected area and you need to find out how to generate an Excel file. So you add all that stuff and the page is getting hairy and ugly but it finally works.

A few months later you are already working on many other things but a new co-worker came in and needs to change something on that small registration app you wrote.

Now I come in and try to come to a conclusions why everything is so messed up.

Next time I will tell you my conclusions.

As a nerd I really like the aesthetics of plots of three dimensional functions. I’ll sometimes just look for cool looking ones or just try to build one that looks neat.

Here I just add some cool looking ones and some which are well know on the web because they had hit also mainstream media.

• The really chaotic looking function is the Rastrigin Function.
• The one which looks like rockets flying through holes I just made up.
• The one which looks like a black holes I just shifted +60 to move it above the grey zero surface which Google plots.