When you are like me working in a team of web engineers, on a project which involves usage of external 3rd party libraries and you are using npm and/or bower to manage those dependencies, you probably will find it useful.

The problem:

When you are working in a team and you are not keeping the 3rd party dependencies as part of your repository. Someone decides to add/remove/upgrade some dependency, they modify package.json or bower.json files reflecting the change and submits the change into repository.

Now you pull those changes into your local copy of the project and unless you run manually npm install and bower install you won’t have those dependencies updated for you locally. Which in most cases result to build/run errors or inconsistency.

The solution:

As we are working with grunt, I wrote a small grunt task which helps detect and update dependencies if package.json or bower.json files version was changed.

So from now on, when someone changes a dependency and bumps npm/bower version, grunt task will automatically update every team member local dependencies.

Which eliminates notifications, questions and increases productivity. :)

Feel free to use it: 

If you are a web developer and you are using Grunt as your default task runner, you probably in most of the cases use it from some inner folder of the project, something like ”client/app”.

In this case, every time you want to work on your code using command like ”grunt serve”, you need to change directory into client/app to run it all the time.

Below, I show you the way to make grunt commands work from root directory which makes your life more comfortable, eliminating the need switching to client/app directory all the time.

  1. Add in your original client/app/Gruntfile.js file the following code to let Grunt know the base directory location:
module.exports = function(grunt) {
  // Must have in order to work from root



2.. Add symbolic link in your root directory to original client/app/Gruntfile.js file:

ln -s client/app/Gruntfile.js Gruntfile.js

3.. Create package.json in root directory with grunt as dependency and install Grunt:

npm init
npm install grunt --save-dev

4.. Run grunt from root to test it.

grunt serve

That’s it, pretty simple. Hope you like it and use it.

Before we begin, I just want to make sure that we are on the same page about what is “Test Automation”. For me, it is a way to automatically validate that a real user experiencing the predicted application behaviour. For example: User click on a button which should open a new window. In this case we need to automatically validate that user is able to click a button and a window will show up with predefined text. Wikipedia: Test automation

Ideally, I wouldn’t recruit a test automation engineer at all. I beleive that software engineers should be capable to test their own code (as part of ”eat your own dog food” concept) by writing unit, integration or end to end tests. It makes even a higher level of bond to the code that you are developing and need to maintain in the future.

But in reality, there are many reasons that might prevent you from living without QA position at all. It could be a culture of the organization that you are working in, legacy code that you need to deal with, could be the product nature that you are developing and etc… Moreover, you might need someone to own quality control in your organization.

My team was missing a QA person to take control of the product quality that we were developing and take ownership of quality all in all. We wanted to do 80% of the testing automatically while covering the manual in the left 20%. I had a budget to recruit test automation engineer of junior to mid level.

How do you recruit a good junior engineer? You are looking for a potential which you need to find and validate by testing it. So I composed a simple exercise for test automation position interview. I gave it as homework after meeting a potential candidate which passed the initial screening.

I thought that it would be a nice exercise to use some SaaS tools to check our company website contact form. I choose to use Saucelabs for test automation code execution in the cloud using Selenium web driver and Loader to do the load test.

I tried to make the test work myself, before I give this exercise for candidate, to make sure that it’s possible and to learn the field myself to feel more eligible. (I never did test automation before)

The main purpose of the exercise was to see how candidate can learn and deal with new tools, use them to write automation and summarize all his work in a document describing what and why it was done.

I sent the exercise as homework to few candidates asking them to send me results in 24 hours, including the test automation source code and document explaining the services and the work that was done.

Eventually I found this approach of testing candidates very effective. You could see weak candidates return partial test results or not returning results of tests at all. Strong candidates asked question and tried to accomplish the mission in the best way. Some even found bugs in our contact form by running their unique tests. :)

Hope you find it interesting. If you have any question, let me know.

I wanted to share few Linux bash (terminal) tips I found to be useful for me over the last year.

1. Commands

cd - goes back to previous directory you have been at. useful when you accidentally switch to root dir for example.
!! - repeats your last command. most useful if you forgot to add sudo to last command: sudo !!
fuser -k tcp/8080 - to find and kill a process which is using port 8080.
history - shows you the history of commands you executed)
history | grep ‘git’ - will show you all the history items with word ‘git’ in it

And now try Ctrl-R in terminal to open history search and type the desired search pattern.

I’m sure you know that Ctrl-C cancels a process execution. Did you also know that Ctrl-Z pauses a process by putting it in background and releasing a prompt for you? To bring back the paused process type fg (ForeGround).

2. Aliases

You can also set some aliases for your most used commands in ~/.bashrc file:

My aliases are:

alias ll=’ls -alF’
alias la=’ls -A’
alias l=’ls -CF’
alias cd..=”cd ..”
alias node=’nodejs’
alias s=’http-server -o -cors’

3. Prompt

As well as define custom prompt colors and git branch you are working on, like I have for example:

More details on how to do it here.

If you are developing web application and you are working on client side, I hope you write unit tests or test automation or even both like we do. The following tips might be helpful if you write your tests using Jasmine and execute it with Karma or Protractor.

I guess you already know that if you want to disable a specific test you can add “x” before describe or it statements?

xdescribe('my beautiful function', function() {
 xit('having fun', function() {


Did you also know that if you add “d” before describe or “i” before it, it will run only this specific test and skip the others?

ddescribe('my beautiful function', function() {
 iit('having fun', function() {


This is especially helpful when you need to focus on debugging specific test.

Hope you liked it. If you have more tips to share, please do.

A story about group of people who were passionate enough to try and make a change in Israeli elections process.

TL;DR We successfully built a social voting application in few days of work in our spare time. Released it two weeks before recent elections in Israel and got 12,000 people registered and voted in that period. All by using viral Facebook marketing.

Read on →

So true, about code quality. The only valid measurement of code quality: WTFs/minute.

I’m just going to put it here, as some great engineering culture references I beleve in:

Few weeks ago I joined Spectory, a small projects outsourcing company with great culture and people.

My job is to form and lead a new team of software engineers. Our mission is to build a new strategic product for Google using modern client side technologies.

The challenge is huge - get to know new people (Spectory and Google), form a new team and build a new product.

As part of my job, I’m and my team deployed at Google and working closely with Google teams and other vendors. We need to integrate well to make a progress.

I wanted to share with you my observations of Google culture after few weeks of work. I share it because I think its interesting and some facts were surprisingly new for me:

  1. Work with a smile. Engineers, security guys, cooks and cleaning stuff are nice. Everybody are willing to help and actually suggesting their help. I still didn’t hear someone rising their voice.

  2. Although we are sitting in an open space, it is pretty quiet here. This is leading to productive and focused work.

  3. As a developer you get a very powerful machine. You can order any enhancement (keyboard, cables, headphones, etc..) that will make your work environment even more comfortable. Nobody will ask you to justify your order and you will receive it quickly.

  4. On your first month you have to learn a lot to get introduced with Google unique tools and standards. Google have a lot of great documentation resources like code labs, wiki and internal user groups.

  5. You have a lot of technologies and different tools you have to work with as engineer in Google. Engineers are free to choose which tools or technologies work best for them. Even every team can choose to develop their own work flow which suits best their culture and product they are working on. Still, standards you should apply to exists.

  6. Requirements for new product development are usually not well defined and documented. It’s customer, product and engineering team responsibility to brainstorm and finalize it. Engineers have a lot of power to decide on product development paths and priorities.

  7. Although it is an enterprise sometimes with its bureaucracy and politics, each team operates like a small start up. Trying to be as lean and iterative as possible delivering value fast to customers.

  8. Last and most important aspect of this culture is the great professional engineers working here. I think it wouldn’t be possible to build such culture without the people who get a lot of responsibility here.

To be continued…

LinkedIn views chart

I left eToro about 2 months ago and started to look for a new challenge. It was my first time actively looking for a job and trying to “sell” myself. :)

Below you will find a list of things I learned from the process of looking for a new job:

  1. If you can afford it, leave your current job before you found a new one. It gives you more time to look for a new job and you can do it transparently without hiding. That’s what I did.

  2. At the beginning, you have to understand what kind of job and in which type of company you are looking for. This is good for training on your pitch and to make a focus. When you know what you are looking, you can decline job opportunities which looks less appealing for you.

  3. Looking for a new job is fun. You have the opportunity to meet a lot of new interesting and sometimes inspiring people. Quit your job now! :)

  4. Don’t trust recruitment agencies. Their recruitment procedures are outdated and not aligned with real market needs. Use social networks and your connections.

  5. LinkedIn is working. Add a new company and call it “Looking for new challenges/opportunities” in your LinkedIn profile. You will receive 300% increase in profile views and at least one new job opportunity a day in your private inbox.

  6. Look for people (team) and culture, but not for product, company or technology stack. You have to work with people at the end of the day.

  7. It takes time to open your mind after a long period employed in one place. Meet old friends who were working with you and who you respect, see what they are doing. It will give you more ideas or maybe you can join forces.

  8. Learn something new, you have plenty of free time now. Read books you always wanted to read, but couldn’t do it because you were busy at work. Learn that new technology and hack something. Spare more time with your family, kids, yourself. You won’t have this time for long.

Let me know what you think and if you have some other findings.