RavenDb 3.0 Wow features

The last time I wrote about RavenDb was two years ago, RavenDb is a great documentDb that has changed a lot since then and now has clients for C#, Java, Python and Node.js. In this lecture Ayende Rahien demonstrates some of the "Wow feature" from the new RavenDb 3.0 version.

Enjoy

TED: Your body language shapes who you are

Great TED lecture that shows how our body language affects the way we think about ourselves, the impression we create on others and basically how it shapes who we are.

So next time you will be facing a job interview, a presentation you are giving or anything you want to be awesome at remember: a couple of minutes before that job interview  stand in a "victory position"

and not in a "I'm afraid" position.

Think about it ;)

UI Tests vs Visual Layout Tests - part 2

In the previous post we understood that testing only the UI logic is not enough and that manually testing the layout across all the platforms that our application supports is impossible. We need to automat it and add it to our continuous integration process.

What is Automated Visual Layout Testing?

*Later I will introduce a platform that automates the whole process, but first some basic concepts.

Baseline

In order to verify that our layout is correct we need a "baseline" – pictures of our different website/application pages/windows. Those picture are "print screens" of the layout as it supposed to be presented. After we manually verify that the layout is correct we set them as "baseline".

Image Comparison

From now on each commit will trigger a comparison between the new pictures of the application and the baseline in order to check whether the commit's changes changed the layout. The comparison is not as simple as it sounds, if you try to compare "pixel to pixel" you will see that a pair of identical pictures are not really identical.

Take a look on these 2 pictures:

This pair of pictures is a close up to the "the" word in the sentence. The pictures look almost the same but if you look closely then you will see that not all the pixels have the same color or the same brightness. However then you zoom out and look at the "the" word in the sentence it will look absolutely the same. Those differences accrue since the browser/the operation system doesn't render the pictures the same way, it depends on different parameters that I don't want to talk about them in this post.

More examples:

Conclusion: Two identical pictures to the human eye are not really pixel to pixel identical.

That makes image comparison a lot harder. Luckily there are enough "smart" image comparison algorithms and tools out there, one of them is a platform called "Applitools eyes". More about it in the next post.

UI Tests vs Visual Layout Tests - part 1

In my post The Pyramid of Tests I introduced the different levels of testing that you should have in your application. In this post I want to focus on the UI testing phase.

UI Testing

In order to fully test your application you have to write unit tests, system tests and integration tests to fully cover you business logic and the systems workflows, however that's not enough. You also have to test the UI of your app, to verify that it displays the right output, check that the different UI elements behave as expected and so on.

In the past we used to manually test it – click some buttons, enter an input and assert that the output was as expected, nowadays we use automatic UI testing frameworks like CodedUI, selenium and protarctor. These frameworks allow us to record the actions we used to perform manually and run them automatically. Now our application is fully tested. That’s all we need right? Wrong!

Checking only the UI logic is not enough!

Even if the logic is correct it doesn’t mean that the application is ready to production.

This is a screen shot from a website where the graph width didn't match the screen size any more.

Another example is a bank website where all the letters in the site turned into gibberish. UI Logic tests will not find those errors. Obviously we cannot allow our self to have an application with these errors in production. That means that besides our UI Logic tests we also need to test the Layout.

In order to fully verify that the layout is "correct" we need to test it on all the possible browsers – Chrome, Fire Fox, IE, Opera and on all the possible screen sizes – PC, Tablet and the different mobile devices. You do it since the CSS that suites Chrome doesn't look the same in IE and the HTML tag that you've used on one platform behaves differently on another one.

Let's say that my last commit included some CSS changes, those changes didn't affect any logic however they might ruin style in some place in my application, my UI Tests will not find it since they check the logic and not the style itself.

As you can see the tests matrix is too big and it is not possible to manually test it.

We need to find something else...

Introducing Visual Layout Testing. Next post.

Kanban and McDonalds

Keep reading. The title is correct.

You wake up one day and decide to eat a burger in McDonalds (not so good to your health but who cares).

You enter the closest McDonalds branch and you stand in line. You wait for your turn to order.

You wait patiently until it is your turn.  Then you tell the nice kid with a cap the details of your order.

After that your order is displayed on the monitor above the desk where all the previous orders are displayed. You can immediately see what your order status is – is it the first order in the list and the kids in the kitchen have already started working on it or are there some orders before yours, and you need to patiently wait.

Meanwhile the kids in the kitchen receive the orders one after another. They work only on the first order in the line (not the shouting dude's order). If there are lots of orders then more kids come and join the kitchen (or the front desk) to help handle all the clients. When they finish working on an order they "send it" to the guy responsible on calling the hungry person who asked for it.  You check that the order is indeed what you asked for ("I asked for no onions!") and then sit down and enjoy your meal.

So what does McDonalds have to do with Kanban!?

Let's take a look at the roles here:

·         The client as the hungry dude (yes that's you)

·         The product owner as the kid at the desk who receives your order

·         The developers as the kitchen kids

The clients comes to the product owner (who can be the team leader) and describes him what they want. The PO adds the client's user story to the backlog according to its priority (someone is really hungry and is in a rush and a VIP might be before someone else) and here's the important part – the backlog is shown to everyone who wish to see it! The board above the desk shows all the orders and their statuses so if a client wishes to check his order all he has to do us look up.

The main purpose of this is transparency in order to calm down the clients, so that they won't bother the desk kid every second with annoying questions – "Hey remember me? What's up with my order? Why I'm I still waiting? How long does to take to make a burger?" If all the kitchen's work is displayed for everyone then the clients are calm and are patiently waiting. They understand that there's someone before them and that McDonalds actually work and not just stall time.

Meanwhile, inside the kitchen the kids work on the orders. They don't randomly choose what to work on – they have a prioritized list of orders (Backlog with user stories) and they work on the first order that the desk transferred to them (The one with the highest priority). They divide the work among them (divide user stories to tasks) and every kid can make any part of the order. So if "Moshe" is sick the team still is able to make the whole burger and even the French fries.

The manager, an older kid, can easily know what the team is currently working on without endless status meetings with the team (or the team leader), he just looks on the board, the same as the clients since all the work is displayed to everyone.

When the order is done the client is being called to the desk to take his order. He performs a quick review and happily goes to eat his burger.

Ladies and gentlemen this is pure Kanban (I didn't cover the limits part or indicators of work – that's for another post).

McDonalds is working like this for years, they called it "Great Customer Service", we - the software developers who instead of burgers make software (or develop\support hardware infrastructures) called it "A card" – in Japanese.

What is not on the Calender does not Exist!

You know those people who remember EVERYTHING??? Well, I'm not one of them and probably (don’t kill me) neither are you.

When you have a job, a hobby (ies), university academic studies, some commitments and a life(!) then every day you have a lot of duties and tasks in all the areas described above. Some are more important than others, some are scheduled for the next day and some are scheduled for the next month. Either way you have to remember them all and eventually do them, however all of us sometimes forget. Most of the time we remember the most important tasks and duties but often we forget the other ones like going to the supermarket, call someone and remind them to do something, some ideas you want to share or maybe a meetup you wanted to attend.

I have a quote: "מה שלא ביומן לא קיים" – "What is not in the calendar does not exist" (the translation is not as neat as in Hebrew – improvements are more than welcome).

I believe in this quote since your calendar shows what you are actually doing. A doctor's appointment, work meeting and so on. However all those "blank spots" you leave there are not actually blank – you are doing something it's just not "as important" as the scheduled ones, but is it really? Is going to the gym or the supermarket less important than a work meeting? Perhaps, but the reason that the work meeting is scheduled in the calendar is because you want to be there (not necessarily want to be there but you sure don't want to miss it).  Don’t you want to go to the gym? Or don’t forget to go to the supermarket?

If you really want things to happen, like going to the gym or calling someone, you have to treat those tasks and duties the same as your "important tasks". Think about this for a second – "All the things you want to do are important"! If it wasn’t important you wouldn’t want them. Yes, some tasks are more important than the others – So they should be scheduled before the other ones. It's ok to postpone something since you have more important things to do right now or you don’t have enough time for it. But it is a decision that you make. You decide not to do something you don’t forget about it.

There are plenty of tools and apps to help you manage your day and your life. I use Google Calendar for the scheduled tasks and meetings (yes I have scheduled time to go the gym), I use Any.Do for reminders like calling someone or not to forget to take back my HVR card from my mom. Last but not least I use Trello to keep track of tasks which take time to complete and don’t have a start date – like my apartment duties or the books I'm currently reading and want to read in the future.

How do you keep track and manage your day? Your life?

Trello:

Any.DO:

 Google Calender:

Creating temporary 'Break Point' in Visual Studio 2013

It's a short one about a cool feature in VS 2013.

While editing your code you can right click and choose 'Run to Cursor'. It will compile your solution, run the app and stop on the line of code where you've clicked 'Run to Cursor'. It will not create a permanent breakpoint. You can also use 'CTRL + F10'.

Felt like sharing.