seralize my thoughts into posts

Last time I was looking for a great engineer for my team I  published a post and asked readers to solve a  tricky puzzle.

Results were amazing – got many responses with quality CVs, and eventually  found the right guy.

My conclusion is that developers like challenges, and teasing them with an interesting puzzles can really help you boost your recruitment with great CVs.

We are extending our team again, and we are looking for a brilliant engineer, so if you think you got what it takes here  a new challenge for you.

contact me via twitter or drop your CV via mail – yonatan [at] outbrain [dot] com.

As I posted before I’m  Looking for an outstanding Software Engineer. Interested ? try solve this puzzle, and contact me via twitter or drop your CV via mail – yonatan [at] outbrain [dot] com.

puzzle

Provide an alternate implementation of the following class,  Thunk, that uses no conditional logic. For extra credit, make it thread-safe.

abstract class Thunk {
  private boolean evaluated;
  private T value;
  public T get() {
    if (!evaluated) {
      value = compute();
      evaluated = true;
    }
    return value;
  }
  abstract protected T compute();
}

If you thought about something like this, try to find a more elegant solution.

abstract class Thunk<T> {
  private T value;
  public T get() {
    try {
      value.toString();
    } catch (NullPointerException e) {
      value = compute();
    }
    return value;
  }
  abstract protected T compute();
}

Outbrain is hiring and I’m looking for the next awesome developer.

Are you the next candidate?

  1. Want to build distributed high scale system together with awesome web-based applications ?

  2. Want your code to have a direct effect on the business performance ?

  3. Want to reach millions of Internet users all over the world ?

  4. Get tired of too many Broken Windows ?

  5. Want to exchange a long release cycle, with a single deploy button ?

  6. Waterfall – is something you see only while hiking ?

  7. Care what happens to your code after it’s been committed ?

  8. Want to be part of a professional team with high standards and great atmosphere ?

  9. Want to join a successful mature startup with a unique DNA ?

  10. Think that Continuous Deployment is the best thing happened to humanity since sliced bread?

Less than 7 points:

I share your grief

– 9 points:

consider running

sudo apt-get upgrade system

and contact me

10 points (and beyond):

Great. So, we are looking for an outstanding software engineer who is passionate about quality and bringing value to our users. You will be part of a small, intimate, dynamic, hands-on team that takes pride in high coding standards and modern development practices.

Each member of our development team is an athlete / all-around-player. You should be able to build a product end-to-end, from the careful mastery of the front end / client side to the efficient and maintainable design of the back-end / server-side.

Requirements:

  • Intelligent and self-motivated
  • Gets things done! (on time, with quality)
  • Strong communication and problem-solving skills
  • BS or MS in computer science or related field
  • 3+ years experience in Java and web development
  • HTML / JS  / CSS
  • MySQL, Hibernate
  • JUnit

Nice to Haves:

  • Experienced in developing in Linux environment
  • Experience with agile, TDD and continuous integration
  • Spring
  • Tomcat and Jetty
  • REST, JSON, HTTP
  • Selenium, Jasmine
  • AngularJS

Development practices:

  • Continuous Deployment
  • Continuous Integration

Extra points: Blogger, open source contributor.

contact me via  or twitter or drop your CV via mail – yonatan [at] outbrain [dot] com

As part of my work in Outbrain.com I’ve developed a maven plugin to standardize eclipse setting in a multi projects maven environment.

I’ve just shared it in gihub – https://github.com/yonatanm/codecleaner

The codecleaner plugin update the following types of eclipse settings:

  • Code Formatter
  • Save Actions
  • Clean up settings
  • Compiler Error/Warning level
  • JSP/XML/XSD/HTML Validation

more details will be followed soon…

In the last few month I’ve been dealing with a field called “Evidence Based Medicine“. The idea about this concept is that clinical decisions should be made based on evidences for examples clinical trials, clinical guide lines and protocols.

This approach claims that patients will get a better treatment  when physicians trust less on their own subjective history (which usually biased) ,  hunches and intuitions and more on facts.

Maybe the best definition is an effort which helps medicine become a science”  (so we will get  less  Dr. House-like decision, but this is a topic to another post :-) )

It is true that “if all you have is a hammer, everything looks like a nail”, and in my case I start thinking of development. Too much code was written using non scientific (or more accurate engineering) methods.

TDD programming is closest paradigm I know that can be tagged as “Evidence Based Programming“.

The red-green-refactor  steps are your evidences – they can help you claim that code will produces the correct output.

BTW, When you start comparing physicians to developers you get interesting results for example: you find that both have large ego, both trust massively their own experience, both must keep updated with the latest technology. On the other hand a developer that does not follow the best practices will (mostly) not kill you while a physician will :-)

While driving home at the end of a working day, I opened the radio and listened to “פותחים ערב עם שמעון פרנס” which was broadcast  in the Israeli Army Radio (גל”צ). At  this radio program,  shuka dinur (שוקה דינור) has an item in which he tells a story. This time he told the story of “The Pontiac that was Allergic to Vanilla Ice Cream“.After finish listening, I decided to dedicate the next development meeting for bugs and to tell the story to the team (There are many references to this urban legend and I copied it from snopes. Here is the Hebrew version) :

This is a weird but true story … A complaint was received by the Pontiac Division of General Motors:This is the second time I have written you, and I don’t blame you for not answering me, because I kind of sounded crazy, but it is a fact that we have a tradition in our family of ice cream for dessert after dinner each night. But the kind of ice cream varies so, every night, after we’ve eaten, the whole family votes on which kind of ice cream we should have and I drive down to the store to get it.
It’s also a fact that I recently purchased a new Pontiac and since then my trips to the store have created a problem. You see, every time I buy vanilla ice cream, when I start back from the store my car won’t start. If I get any other kind of ice cream, the car starts just fine.
I want you to know I’m serious about this question, no matter how silly it sounds: ‘What is there about a Pontiac that makes it not start when I get vanilla ice cream, and easy to start whenever I get any other kind?'”
The Pontiac President was understandably skeptical about the letter, but sent an engineer to check it out anyway. The latter was surprised to be greeted by a successful, obviously well educated man in a fine neighborhood. He had arranged to meet the man just after dinner time, so the two hopped into the car and drove to the ice cream store. It was vanilla ice cream that night and, sure enough, after they came back to the car, it wouldn’t start.
The engineer returned for three more nights. The first night, the man got chocolate. The car started. The second night, he got strawberry. The car started. The third night he ordered vanilla. The car failed to start.
Now the engineer, being a logical man, refused to believe that this man’s car was allergic to vanilla ice cream. He arranged, therefore, to continue his visits for as long as it took to solve the problem. And toward this end he began to take notes: he jotted down all sorts of data, time of day, type of gas used, time to drive back and forth, etc. In a short time, he had a clue: The man took less time to buy vanilla than any other flavor. Why? The answer was in the layout of the store.
Vanilla, being the most popular flavor, was in a separate case at the front of the store for quick pickup. All the other flavors were kept in the back of the store at a different counter where it took considerably longer to find the flavor and get checked out. Now the question for the engineer was why the car wouldn’t start when it took less time.
Once time became the problem —  not the vanilla ice cream — the engineer quickly came up with the answer: vapor lock. It was happening every night, but the extra time taken to get the other flavors allowed the engine to cool down sufficiently to start. When the man got vanilla, the engine was still too hot for the vapor lock to dissipate.

Moral of the story: even insane-looking problems are sometimes real.

I guess that almost all of us received strange complains about code, strange bug description that were opened describing weird behaviour  — for example “your codes throws an exception only when I execute it while talking over the phone”….

Usually the reactions are:

  • WTF ?
  • What is the linkage between my code and your phone ?
  • The stupid user dosn’t know how to run my  code …
  • WTF ? WTF ?

The messages I want to send to the development team:

  • Weird problems eventually explained by a set of simple facts.
  • got a complain about a strange behaviour ? You almost sure that it is not in your code ? Treat it as it is a bug in your code. You can never tell what are the causes for the bug.
  • a bug is like a boomerang, when you throw it away and ignore it, it usually returns…
  • Problems are not solved by themselves
  • Most of your users are not stupid

Any other messages  you can think of ?

What is the 1st thing I  need to do in order to implement Alef-FS ? have RFuse-ng installed on my machine as a ruby gem.

RFuse-ng is a bridge between ruby and FUSE. The concept is very similar to Java JNI, which mean that it is mainly a native code written in “C”

RFuse-ng comes with a REDAME which is good, and it has a Makefle which is even better, but it also has several compilation errors – not good.

While reading the docs I find out why –  RFuse-ng was tested with ruby 1.8 and I’m using 1.9.2. Further investigation of the code made me realize that ruby does not have Backwards compatibility, at least not in the aspect of native code support.

As Michael Feathers wrote in Working Effectively with Legacy Codelegacy code is code without tests” I understood that it is not going to be fun.

I had to tackle issues mainly due to changes in the way ruby exposes its string representation to “C” code. #define rules!!!!!!

Anyway, at the end of the road I’ve managed to create a patch file for  RFuse-ng describing the changes required to make it work  under ruby 1.9.2

Now, all I have to do now is to implement, (at least until the next obstacle)

class AlephFS < RFuse::Fuse
# implement
end
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: