viernes, 17 de octubre de 2014

London Software Craftmanship Community: Pair programming

Yerterday I went to 7th Talk by the London Software Craftmanship Community.
Really glad I could go and meet this great people:
http://www.meetup.com/london-software-craftsmanship/events/212202712/

The event consisted of two half-hour talks and one ten-minute live kata. Everything was recorded and will be published soon.

A new Model of Testing, by Paul Gerrard

I remember sometimes I have talked with some friends about the following: 
We are programmers, and sometimes we don´t know what kind of magic, charms, terters do. All we see is a smile coming to your place, "it doesn´t work, I found a bug".
Testers, designers, developers, we live in the same ecosystem to create a common thing, we should know each other!

It was great to assist to this talk. Paul is a tester who used to be a programmer (he even programs yet).
According to Paul, the old testing way won´t work any more. He is writing a book about that. you can download the paper and give Paul feedback:
http://dev.sp.qa/download/newModel/NMIntro

Bassically the old testing way won´t work because our system are changing, InternetOfThings is here, we have million of devices and it will get humungous in some years, we´ll have internet everywhere and testers won´t be able to test the same way.

Key take aways:

-Forget about testing logistics (using sql or oracle, using chrome or IE, using agile or waterfall,..) testing thinking should not rely on it.
-All testing is exploratory: We identify sources of knowledge, to build test modules, that inform our testing
-All testing is based on models. Humans use models everywhere: maps, class diagrams, uml, mathematics,... Bassically all models are wrong (otherwise it would be reality), but useful!
-When we are testing we should actively think that we are using models.
-When a test fails, first thing testers think: has my testing model failed? That´s when you ask the programmer "is it ok?" If now, then you report a bug, testing model was good, programmer´s produced a model that doesn´t fit to it.
-We explore (create a model) and then test (using the model). Devs, we do the same!!
-Tester and programmers, we have the same capabilities.
-Goal: End manual, let automation do it. Human testers, will produce models (programming) to feed automation frameworks.
-So testers do need to learn how to code
-Testers don't own testing anymore.

Do simple constraints when creating and algorithm, by Sandro Mancuso

It was really impressing to see Sandro in action. He implemented an algorithm to calculate the Romans numbers based on a decimal input. He followed TDD sistematically from the beginning, it has the type of "wow" effect that I always feel when somebody is doing TDD. He also used sublime together with some plugin to run from Jasmine tests (impresing to see it).

I´ll try to reproduce the exercise he did but this is the key take away:
When doing an algorithm, enforce simple constraints in the beginning. By trying to use simple constraints along the way (like if), then use more complex if needed (like exceptions treatment).
If use complex when simple is feasable, the algorithm gets more complex.

When I saw that I remember that according to TDD you write the minimun code that make a test to pass. Sandro´s workshop fits perfectly with that: writing minimun code= writing simple constraints to make a test passing.

Be the best pair you can be! by David Morgantini

David is a software developer with a unique experience: he is married to a girl with did a PhD thesis about Pair Programming. When she was writing it, he had to read it, sometimes :)
He did took the practical essences of it.

I wrote some time ago about the benefit of pair programming:
software-creation-using-collaboration II

When David explained it, I thought, "ok, this is common sense", but you know what happens with it: it is great if somebody reminds you common sense things. 

Here are my notes and take aways. The video will be available soon, so I let you know. It is worth watching.

Some definitions:

Driver, navigator
Disengagement
People: Expert, novice, we can have different types of pairs (EE, EN, NN). If you were the novice in one session you can become the expert in the other, because you know more in that case.

Patterns: 

One keyboard, two keyboards, a laptop, a mirrored lapton,
Dual station (he prefers it,then everyone has its own space).

Benefits:

Researchers strugle to measure Pair programming, measure its actual benefit. Issues are: people have different motivations, benefit is better seeing in practice. But to summarize benefits:

Economics: number of defects is lower.
Quality: two heads looking at the same
Dev statisfaction: you write better code, it makes you happier when you arrive home
Learning/ knowledge sharing
Comunication, team building

Disengagement, the big problem!

If disengaged, the pair looses all of the benefits of Pair Programming!
We see it when...

1. The pair gets distracted: solution mutually agreed disengagement ("let´s do a break")
Expert-Novice: It is very easy novice becomes disengaged. Solution: expert checks attention frequently.

It is the best if pair knows the goal of the session: quality, learning, the two are novices,... Then we can better achieved the goal.

2. Some work doesn't fit for pair programming. We can try to make it work by:
-Split a U/S into tiny tasks. Some of the tiny tasks can fit Pair Programming.
-Break the pair if it doesn´t work.
-Identify tasks that need pairing
-Expert: ensure novice is driving!! 

3. Uncomfortable dev environment. Solutions: 
-swap pairs, 
-try to make your pair feel like at home (same IDE he uses, proper monitor, no laptop for Pair programing!!...)

4. Interruptions: A team leader comes over and tell you important stuff... Rules:
-A pair shouldn´t be disrupted.
-If pair gets interrupted: "Please, wait a minute..." and complete an ongoing discussion
-If pair suffers a longer interruption, plan it! Make sure one of the pair can follow and go on when alone
-Re-establish the pair when interrupted in order to go on: "from where did we leave it?"

5. Time pressure:
-Plan novice pairing in Planning meeting.
-Expert: verbalize progress and ask for feedback

6. Social pressure:
Novice: I don't want to look as a stupid.
-E: Let some time alone for novice to consider solutions alone, before doing the pairing.
-N: stop if you don't know what´s going on, ask questions!
-E: Should Encourage the novice to drive!
Establish context before you start: expert explaining the problem before starting!!

That´s it for today. I tell you when the video is ready. Thanks for reading and have a great weekend!

Maybe find some time in the weekend to?...

Keep coding!!


miércoles, 15 de octubre de 2014

The Good, the Bad and the Ugly of the HTTP Archive: Performance of web sites using HTTP Archive

Hi again!

Yesterday I went to a workshop carried out by the London Web Performance Group, The Good, the Bad and the Ugly of the HTTP Archive.
I was really surprised with the content of the talk, in addition pizza and beer was provided at the end of the talk. Furthermore, a position to work in Google was announced there and they even have a lottery with free tickets for the next Velocity conference in USA.

http://www.meetup.com/London-Web-Performance-Group/events/209433702/

This same talk was held in Velocity Conference in New York this year.
The speakers were Robin Osborne @rposbo and Dean Hume @deanohume, two developers that share a common interest in Web performance.

So what is HTTP Archive?

The HTTP Archive is a vast data store of web sites (http://httparchive.org/), it collects the web content, how it is served and constructed.

It runs once every month and it collects a lot of information about performance, including load time, page size, http requests and much more.
The information is stored in MySQL and can be downloaded. The problem is the size of the file, some hundred terabytes.
But wait a minute, we have google bigquery that provides an endpoint to query this information:
https://cloud.google.com/bigquery/
Bigquery makes it really easy to query big data. We can run SQL queries really fust.

In addition, we have bigqueri.es, comunity of people sharing queries to be run for HTTP Archive.
They provide the sample sql query together with some results and discussion with other members. One can also post his own query and ask questions.

Checking performance of web sites

So Robin and Dean created a couple of benchmarking queries. They aim not only to get the best and worst web site, but more importantly, check what they were doing good or bad in terms of performance. Yesterday they shared their main conclusion.

They explained how they measured it:
-They took out the main 100 websites. This is because big companies have dedicated teams for performance, they wanted to know what they can in their daily basis as regular developers.
-Measurements: Fully Loaded time, Page downloading size, page speed (0-100), speed index (how quicly different check points in the page loading takes).
-If sites were usable and modern, if they follow best practices, and bonus if the site was responsive.

The Good:

Or how web pages went better...

Filament group: 

Very good performant and responsive page, and they blog about how they do it.
They scored 100.
His trick is reducing the critical path, this means getting the main content in the beginning, when the site is loading.
In addition they have made several tools available in github: Grunt-CriticalCSS, LoadCSS, LoadJS

Nature.com:

They score 86.
They stick to basis, 14 rules for faster-loading web sites: http://stevesouders.com/hpws/rules.php
Monitor is key for them: They monitor every new feature they release. They use: ShowSlow.com, statsD and graphite.

Zomato.com:

88
Their point is:
-Start small: A blank page is always going to be the fastest, start from there. Add only what is needed.
-Caching: Heavy use of caching, makes sense since they are a search provider. HTTP caching.

Envato marketplaces:

85
Stick to basics and aim for low hanging fruit.
They think about performance from the earliest design stage.
If users add their own images you need a performance strategy.
Consider user content generated.

The bad:

In this case they didn´t ask directly to the web sites, to avoid dissapointing them.
Instead, Robin and Dean asked themself, if they could do one single thing to improve these sites´performance, what would it be?

Welovefashion.it:

In this case lots of data is downloaded to the client when page loads:
Simple trick, enable compression.

GU-JAPAN.com

15.5 MB images loaded in start up.
717 http requests
And this is because a carousel of images.
One simple trick: Remove carousels, it has been studied that 1% users care about carousel.
If you don´t believe check ShouldIUseACarousel.com

GAMEPEDIA.com

They have users generated content, such images that aren´t scaled. Trick: serve scaled images

The Ugly:

Can it go even worse?

Sailboatlistings.com

They score 44.
The reason is that the build 15000 dom elements in the beginning, because of an everlasting scrolling in the home page.

colorsbycherry.com

Scored 14!!
It takes 1 min loading completely, because of lots of images.

CALLOFDUTTY

Its a great page, with reasonable measures, but... they scored 11 out of 100.
The reason is because they have a video looping in the background, is not streaming, it downloads the entire video, again and again.

Performance in the build process

One great part of the talk. Robin and Dean explained that performance can be measure and automated in the build process.
We can use PSI, that measures performance, automate into build, so it fails if speed is bigger than some threshold.
The problem with PSI is that it needs to expose a public url, and that means that functionality needs to be released. So what happens if we want to automate our own main current developed branch.
We can use NGROK, which creates a secure tunnel to localhost, and then PSI can run using it.


So that´s it for today.

Keep coding and being performant!

lunes, 13 de octubre de 2014

NCrunch, your friend with TDD

Today I wanted to talk you about NCrunch, a great tool I´ve discovered thanks to my colleages in my new job. It allows us to automatically run our Unit Tests while we are writing the production code.


So we´ve been told about TDD, Test Driven Development. The methodology itself is easy to understand but specially in the beginning hard to take, I think is because it may seem like against common sense. TDD is based on three simple steps:
1) Start with a failing test (don´t fail to fail!). This test checks a small working piece of functionality.
2) We write the minimun amount of code that makes it pass. Minimun is minimun!
3) Refactor the code (tests and production code) to avoid duplicated code and do improvements.
We iterate though every of these steps, adding more and more tests until we have all of the user story finished. Previous tests must pass in every moment.

You´ve probably noticed that a quite important part is running tests. I´m so used to watch the tests explorer (whatever it is) and run tests manually as I follow TDD.

So here it comes NCrunch to give us a hand in this task. NCrunch is running on paralel, watching our changes, and running all of the tests again as soon as it finds any modification.
We´ll see a few things going on:


There´s a circle in the corner of the right side. It will be green if every tests pass. Otherwise it goes red with a number, this tells the number of failing tests or projects that don´t compile.

In the left side along the code, we see some arrows. These are starting tests. The arrow is green if it passes or red if the test breaks.
In addition we can find code coverage in a very easy graphical fashion. If you see, we have some circles in colour. This circles are green if that line of code is succesfully reached by a test, likewise it goes red if the test doesn´t pass. Circle becomes black when the line is not covered at all.

If you browse the NCrunch page you can see a video of all of this in action. An image is worth a thousand words:
http://www.ncrunch.net/

You can imagine how this helps doing TDD: we write a test and it goes red inmediately. We implement the minimun code (Resharper can help us doing that from the test). It will be the minimun, otherwise we´ll see black circles appearing in the logic. Test goes green and we do refactor having the test still green, together with other previous tests.

It´s just amazing how you forget about Tests Explorer. When I started in my new job I noticed my colleagues hardly ever debug the code, and the reason for that was easy: NCrunch was doing the hard work for them. They code simply focusing on the programming part.

NCrunch can be used with MSpec, Specflow, MSTests, NUnit and probably many others.
NCrunch is just another productivy tool (yes, Resharper is the big boy). I know I have a few friends that don´t like to polute their wonderful Visual Studio environment, arguing mainly because it makes VS slower.
Well, while the former is true, I´m a big fan of these tools, and the reason for that is because I can just simply a more efficient programmer. Yes, the machine can go slower, but isn´t productivity increasing a good reason to ask for more memory to your manager?:)

As a side note, I would like to talk you something very funny that happened to me regarding NCrunch. In order to get the position I got in my new company, I need to do a programming exercise. I finished it and I was proud of the result. I followed TDD and so, my code coverage ought to be great. A couple of days after I started the new job, I opened my exercise solution with my brand new Visual Studio and NCrunch installed. Suddenly I noticed an entire method full of black circles, that wasn´t covered at all... Luckily my technical leader, Richard, was so kind to let me start working with them.

Cheers mates, keep coding!


sábado, 4 de octubre de 2014

What's going on with C# 6.0!

Hello! This is Juan Antonio, back again into the arena.
I'm sorry, it's been a long time since I last wrote a post back in August.
Certainly there have been lots of things to take care off, but I don't want to stop sharing things with my friends.

A couple of days ago an interesting Pluralsight course fell into my hands, What's new in C# 6.0, by Scott K Allen: http://www.pluralsight.com/courses/csharp-6-whats-new
I really recommend if you can watch it not only because of the content but also because Scott is a great speaker. I felt really amazed with what is coming in C# world.
In this post I wanted to summarize the new features of the language.

Everything I'll tell is possible because of the new compiler, .Net Compiler Platform "Roslyn". It is an open source project that we can download and see the source code (http://roslyn.codeplex.com/). It comes along with a new Visual Studio 2014. When I'm writing this, every of these things are in beta testing version so one can download everything for free.

Autoproperty initializers:

With C#6.0 we can set the initial value of properties easily:


See how we can initialize even a read only property.

Primary Constructors:

Primary constructor allows us to define a class constructor and capture the constructor parameters to initialize class properties.

In C# we have a common pattern, we inject a component through a constructor and we use this injected component throughout the rest of the class:



With Primary Constructor we don't need to specify the constructor, instead we can use primary constructor together with autoproperty initializers:


The code becomes more elegant and concise and the benefit is that the menu primary contructor variable is available in the rest of the class as well.

Dictionary initializers:

Initializing a dictionary is now more concise with the new syntax:


Event initializers inside constructors:

Until C#6 the following piece of code is illegal:


Params input parameters now with IEnumerable:

Now we can specify a variable number of arguments with IEnumerable and not only with array, like this:

Declaration expresions:

Normally we declare variable and then we assign it a value of an expression. C# 6 will allow us to join the declaration and the expression. Let me show you an example:


See how we declare out total inside the TryParse.
The benefit is that the code has become more explicit and that we have declare the variable where it makes more sense, taking more control over the scope.

Using static:

Simple but cool feature. If we have a static method on a static class, now we can declare the static class in the using part and just invoke the static method anywhere in the file. Therefore we don't have to type the typical Assert.AreEqual, but instead:

Conditional access:

Now instead of having lots of null checks before accessing properties of object, we can use ?. so we'll get the value of the property only if the object is not null, like this:


Expression bodied members:

This feature allows to assign value s of properties using Lambda syntax, like we have done here for NumberOfDishes:


There are a few more of features but this post is just a taste of what we will have soon available. It makes a bunch of small features but altogether it will allow to code simpler and more concise.
Remember, great power involves great responsibility.
Looking forward to have these tools in our daily projects!

Keep coding!

sábado, 9 de agosto de 2014

Did you know that...? foreach

IEnumerator is a simple interface that defines a basic low level protocol to traverse a collection in a forward-only manner. The protocol is so simple:


Collections normally don't implement enumerators directly. Instead, they provide enumerators via IEnumerable interface:


The benefit of implementing this interface in a collection is that several consumers of the collection can enumerate it without interfering with each other. 

Enumerable can be thought of as "IEnumeratorProvider".

So we could walk a collection like this:


However we have a  great syntactic sugar for Enumerable: foreach.


The compiler will convert the former foreach into the previous enumeration using the underlying Enumerator.

There's more...
We normally will make use of the generic counterparts, IEnumerator<T> and IEnumerable<T>.
One of the main advantages of using the generic version is that IEnumerator<T> inherits from IDisposable. This allows us to have a collection on which every element can be disposed, like a database connection.

So let's go to the point of this post. Let's see real magic in action.

1. This is what we write:



2. Compiler converts this to use an using block because of IDisposable nature of IEnumerable + Compiler converts it to use underlying enumerator:



3. Compiler converts this using block to call Dispose defined in IDisposable:


(I know I have a compiling error but you get the idea right? :))

If we compare the first piece with the last one we can save a few lines of code.
This is the magic that happens behind the scenes if we call a foreach using a disposable collection.

Keep coding!

sábado, 19 de julio de 2014

NDC 2014 Oslo: Core software design principles (DRY, YAGNI and SRP+SLAP)

So here we go with one of the greatest talks I went in the conference: Core Software Design Principles by Venkat Subramaniam.



I didn´t know Venkat before the conference (you can blame me) and everybody told me he was a good speaker. I went and it was a lot more than what I expected.
If you want to know more about Venkat I think one of the best ways would be to go reading one of his books:
http://www.amazon.com/Venkat-Subramaniam/e/B001JOS4R2

I went also to his talk Transforming C# into functional programming, samely awesome.

Today I wanted to share with you the highlights of his talk Core Sofware Design Principles, cause it turned out to be the clearest explanation of SOLID and many other principles I´ve ever received.
I wish I could explain it as good as he did.
Maybe you are thinking "I know SOLID, leave me alone". Well, I thought I kew but... what about Liskov substitution (its name doesn´t give it any favour)? Do you know YAGNI, DRY?

If you have been reading about design patterns, code, principles, you´ll probably notice that one of the cornerstones is Simplicity. No matter what you read, simplicity is always the goal. Here you can find a few hints about it: http://codexfun.blogspot.com.es/2014/06/keep-that-simple.html

What I really liked in Venkat´s lecture was the real life examples he put and the passion in his explanations. He also made use of code examples that ease understanding of the concepts so much.

Design Principles

Principles are a set of practices that help us create better quality software, which are found to be effectived for many programmers along the years, if applied in the correct way in the right degree.

We shouldn´t confuse principles with patterns. If we take a pattern and try to apply it to a problem, it may be that we can´t apply it. Nevertheless a principle is something we always strive for so that it offers a bigger value than anything else. A pattern is a specific solution to a specific problem, and the solution is always met by trying to meet some principles. E.g. Strategy pattern solves a problem when a system is prone to change by meeting the Single Responsability Principle.

Nevertheles, principles, as patterns,  offer a common vocabulary to express ideas to communicate each other, so that when you are in technical grooming somebody might say: You can´t do this because, it will break OCP.
We must be careful because we may, as patterns, overuse them.

Venkat told he doesn´t like the term SOLID that many programmers are used to, because there are many other principles that are as important as SOLID.

So let get this party started!

DRY Principle, Don´t Repeat Yourself

Every knowledge in a system must have a single authorative unambigous representation

When we try to follow this principle we must ask the following: where is this piece of knowledge in my code?

Who´s playing the guitar? What if we have a bug in the guitar:D

Imagine we have a system that creates Requisitions. What if in the future we have to change this knowledge to create requistions? If we spread this logic into several places in the code, we would have to change all of these places, making a dupplication effort. And when bugs arise we would have to fix bugs in multiple places.

Imagine we have a web application with several pages. In several of these web pages we have a field called OrderNumber, on which we perform some validations. We should strive to have these validations over OrderNumber in a single place. Because of the same reasons.

DRY is not only about duplication of code, but also about duplication of knowledge.

YAGNI Principle, You Ain´t Gonna Need It

This principle is telling us that something we are coding now, won´t be required at all.
When we are designing a system from scratch we put a lot of different things in place: validations, new data types, generics for better reuse, extensibility mechanism,...
Question is: Do you really need it? If the answer is No, we should postpone the decission until we know it better.

Somebody already invented a lips painting mask, just in case. I don´t think it even works but any girl in the room would better tell:)

Apparently this principle makes Venkat´s mates angry: they took a lot of time to make that generic superb cool class, you better use it!
What he does is that he adds: You Ain´t Gonna Need It + Yet!
Isn´t this cool, we have a way to avoid angry colleagues. Argument is the following: requirements may change, right? So why don´t we postpone the decission to add this generic class for future sprints until we have a better knowledge. It may be that we need it, but we don´t know it YET!
If so, we can track back the history of the project and include this class again.

Bear in mind that most of the extensions and generic component that we add in our code are likely not to be used. Maybe you have experience the following disgusting situation:
-Code reviewer: "This generic interface is cool mate but you have only one concrete implementation."
-Programmer: "Oh, yes, but it is already there, so in one year we could add a second implementaion! Don´t piss me off"

SRP, Single Responsibility Principle

Every piece of code must have ONE purpose, ONE reason. 
One of the best known, in my opinion because of its simple meaningful name, or not? :)

This principle is about Cohesion: things that go together must belong together. If not, they should go separate.

We all have been students and sometimes we didn´t have time to tidy up our room, not gonna blame you if this was your "clothes box":

What if we want to wear our favourite dress for a date with a beautiful girl. It can be tricky, but we can make it, we may use a B-Plan:


Our parents probably tried to teach us how to tidy up our clothes, but it never worked!
We eventually went serious with that girl, we got married... She was a wonderful and tidy girl, our wardrobe became this:


Isn´t this a realm of harmony and peace? Everything in its right place. Awesome. One part for tshirts, one for suits, one for ties,...
Now we have a great advantage: We can find our favourite tshirt very quickly when required!
If we were used to this mess, our girl did a big effort with us to change our mindset because it was much easier to throw things into our box.

Same thing happens in code. We get a task and it is much easier to throw this piece of functionality anywhere in the solution. But we should bear in mind that solving bugs takes more money that adding the code in the beginning. We want to save money and time when it comes to fix something in the future.
If we take discipline and follow SRP, it gets easier and easier, you get a good habit.
We can follow SRP all over our code:

Classes: 
Before this talk I was a lot into applying SRP in classes, because classes are natural representation of a bussiness entity in our software. Some simple rules to apply SRP in classes:
  • Don´t put multiple classes in one file.
  • Classes have to be narrow and focus. E.g. imagine one class with multiple calculations, database operations, communication. This is so unstable, every change in the system will affect this class because it does everything. If we create multiple small focus classes, a reason for a class to change becomes lower.
Methods:
Something stupid from my side was that I hadn´t thought in the importance of SRP in methods. Venkat took quite a bit of time to explain this.
Long methods are a bad idea because:

  • They are hard to read.
  • Hard to test.
  • Hard to reuse: how do you reuse a monsterous method when you need that 10 lines of code in the middle? You can´t and it leads to dupplication of these 10 lines.
  • Hard to maintain, modify and eventually remove if some piece of the method changes.

Please spread this idea: Don´t write long methods. It´s a simple thing to avoid and it leads to a great benefit.
If we write short methods we turn to follow SRP in them.

How long is long? 

Instead of trying to put a number or a size, Venkat gave an example similar to this:

Remember this Kid A mate that is new in your company. Everybody says he writes long methods. You want to check...

-How was your weekend Kid A?
-At 19.00 on Saturday I took my car, drive to Albert Hall using Ring3, arrived to a concert by Radiohead, it was great, they played the full album called as me, Johny Greenwood did a mistake in a song, I drank 6 beers and a few shots so I had to sleep in a park and I couldn´t speak to that girl I like, so on Sunday I had a huge handover....
Ten minutes later...
-Ouch, please stop, TMI. 
-Oh, you told me how was my weekend, what´s up?
-Yeah right, I thought you could explain me how was your weekend without doing the same you do in code. You are the guy that writes long methods, aren´t you?

His answer was too long, he of course violated SRP. We don´t speak to people like this.
We speak to colleagues like this:
-Hi Jose Gonzalez, how was your weekend?
-Well, on Saturday I played in a concert, on Sunday I went to the park.
-Wow a concert! How was that?
-It was great, people liked my new album.

Jose Gonzalez is a SRP guy. He explains in high level of concepts. When we wanted more info about a certain concept, because we prefer music, we follow and ask about his concert.
Maybe another colleague more interested in parks will come and ask Jose about it with more detail.

So please keep this:

We must mention things in one level of abstraction at a time.

This is the so called SLAP principle, Single Level of Abstraction. 
It is also called Compose Method: a method should nicely compose things at a single level of abstraction. If you need more info about a certain abstraction you can go to that method and see the next level of abstraction:

 How_was_your_weekend()
{
       Played_in_concert()
       Went_to_park()
}

Played_in_concert()
{
     Where_was_it()
     Which_songs_did_you_played()
     Duration()
     ....
}

Went_to_park()
{
      Which_park()
      What_did_you_do()
      ...
}

I think this is more than enough for today.
Next day we will follow with TDA (Tell don´t ask), OCP (Open-Close), LSP (Liskov Substitution) and DIP (Dependency Inversion).

Please send me your questions, answers, insults.
I know it´s summer vacation but I´ll throw it..

Keep coding!:D

viernes, 18 de julio de 2014

NDC 2014 Series

Hi there!

Last June I had the pleassure to assist to Norwegian Developers Conference (NDC). It was held in Oslo Spektrum, 2-6 June.
This is one of the things you shouldn´t miss if you like programming, design, technology, agile methodologies and much more.
Oslo Spektrum is a perfect scenario with a big large hall full of stands with lots of mainstream brands, a big stage with music, one book shop, entertainment and good food.


In the sides of this main hall there are 9 stages with different sizes, where 9 parallel talks are held every hour, from 9 am to 5 pm.


The quality of the speakers and topics made it so difficult to choose between talks  so one could simply go to stage #10 and watch every of them in different screens, simply by changing the headphone´s channel.

If you are in this code´s business, this is the kind of experiences that really can change your way to look at things.
You could go to a life changing talk about productivity, an architecture speach held by one of these american big gurus, attend to a talk about a cutting-edge technology or simply let the great Kevlin Henney explain why indentation matters in half an hour.

I know sometimes the problem is the price. I´m checking prices for NDC London 2014 that will take place in December. If you apply now it costs 950 pounds, almost 1200 euros. Ok, it´s a lot for a Junior programmer salary or whatsoever. But if you look at this as an investement it isn´t much.
Be sure that if you go to one of this you´ll be doing a better job and what´s more important you´ll have more fun everyday.


Even though you can´t afford this for any reason, all of the talks are available online in Vimeo.

Here you have the full program:
http://ndcoslo.oktaset.com/agenda

And here there are all of the videos:
http://vimeo.com/ndcoslo

Still, if you are as lazy as me, I will try to do a post with the most interesting talks I went, NDC 2014 Series
I hope you like it. Please send me your feedback.

See you in NDC London 2014?

domingo, 6 de julio de 2014

Being a Junior developer

Hi there!

One of the things I do to take the best of my time is to do things when doing other things. Maybe this is not a good thing, so I don´t want you to take this as an advice:)

But yes, I do run, and while I'm running I will hear some Music I like. But I also hear podcasts, and one of my favourite time span to hear that is while running. I hear programming podcast. I know, I can look like a nerd, but these podcasts are pretty awesome.

Yesterday I was running back home and I took one of the great Scott Hanselman. This is the podcast:
http://hanselminutes.com/427/what-it-really-means-to-be-junior-developer-with-jonathan-barronville

The podcast was a talk between Scott and Jonathan Barronville, a Junior Programmer. Yes, he was proud of being a Junior Programmer.
It was like a revelation for me. I remembered myself some years ago, pretty stressed being a Junior Programmer, I wanted to become a Software Architect in some months.

Why should I be proud of being a Junior Programmer?

Have you experienced that situtation: you are clearly the "junior guy"?
It can be really a stigma, you hate yourself for being that and salary doesn´t help on that.

Jonathan experienced the same situation, and one day he asked himself, why is that happening?
He suddenly noticed that it was more a benefit than a bad thing, it was a great:
-He could learn.
-Being paid for it.
-Yet it was Ok to make mistakes, actually he was expected to make it.

The Senior guy, despite the fact of having an awesome title, it is harder for them to messed up.

What is Experience?

Years, years in the company, years in the technology?
Experience is more what you know and what you have to learn.
Have you ever hear the following: this guy must be a Senior because he has 20 years in the company.

We all know people that have been so many years in a company, maybe 10 years, but they keep on doing the same every year (language, project, technology). That´s the same year 10 different times.

On the other hand, if you have the same 10 years, but you´ve been in 5 different projects, three companies, four frameworks, diverse group of people, failing, it has much more value.
We must focus not only into years of experience, but even more important what have you done in those years.

Making Mistakes 

Ouch, it even hurts to write this word, MISTAKE...



In our industry, mistakes are not seen well.
In my opinion failures are so valuable: it tells that somebody have tried something and learn something while failing.

In our culture we would probably take the following resume very seriously:

Juan Antonio Vicaria, PhD Computer Science, MVP Microsoft, C#, Phyton, JS, Ruby, C++, Erlang. 5 years experience...

Would you think the same about the following?

Juan Antonio Vicaria, 2 years in C# learning from scratch, 2 years trying different JS Frameworks, 1 project that failed because of scope, 1 project failed because of incorrect technology chosen, 1 succesful project.

I would like to be the second Vicaria. I´m going to work so hard to make mistakes when I can.


Embrace Learning

Learning is as important as failing. They are so related because when you are learning something you make mistakes, that´s how you learn.
We should see and understand what people have learnt.
For example we should value not only the number of languages somebody knows, but what he has learnt with them.
"Ok, you have NodeJS in your CV, but tell me what it offers, what have you learnt with it".

We should value people learning new things. Every time we learn a new language, even though you are not using it, you have learnt something. You don´t need to be a master in the language, you just may know that it exists and what kind of problems solves. One day, if needed, you will go and learn it properly for a project.
If we take the example of a famous cooker, in his CV we won´t see that he is able to use 20 different pans, 1000 techniques for preparing meat, 2000 ingredients he knows how to use.
Instead, we should probably see some examples of his best dishes. Knowing techniques to get the very best of every ingredient is much better than just saying, I know 1000 techniques.



A Junior developer is somebody realising there are a number of tools that he needs to learn to do well under different scenarios.

We could be a 20 years experience developer, and suddenly we have to learn Erlang. We are totally new to Functional languages.
Why shouldn´t we accept that we suddenly became Junior Developers? What´s the problem in that?
We were just lucky, because we suddenly are allowed to take our time, go and learn, and fail when learning.

Embrace Not-knowing

Our world is crazy, we have to know ASP, Knockout, Node, Angular, ext, .net, js, sql, mongo, spring, hybertnate, jasmine, nunit, specflow,... I could follow like that forever.

Again, what´s the problem in saying "I DON´T KNOW"?



Imagine we go to a meeting and when somebody suggests SignalR for the next project, we don´t know what it even is.
In our world, any programmer (Junior or Senior) normally would simply don´t say a word. Later he would go to Wikipedia and read the first paragraph of SignalR.
I have done it so many times that I feel ashamed.

Why don´t we go to that meeting and tell "Sorry, I don´t know what is SignalR, seriously buddy I don´t have any idea of what it is. Can you explain me?"
Even if you have 15 years experience, you don´t have to know everything.

Please next time you are in that situation, please go ahead, tell "I don´t know". Ask that question, nobody should look at you badly.
Please if you are the guy that knows, don´t look at them badly. Please go ahead and explain.
I would like to say that to the junior Juan Antonio, please mate, don´t feel bad when asking, you are there to learn.

Specially when a new guy arrives to the company.
Have you seen the typical nerd superb programmer in the company who is the typical don´t-ask-me-questions guy?
Yes, you will go to his place, you are the new programmer in town, he will look at you with an icy sight, telling:
"I would tell a few words, but why on earth have you entered in the company without knowing that, why are you such a moron?".

Please go ahead and get rid off this type of people surrounding you, people that makes you feel so damn for not-knowing.
If you don´t know what I mean please meet Nick Burns, watch this:


We are all learners, we should keep that passion about learning, even if you have 30 years, you should still feel like a junior programmer, feeling that you are getting a new thing everyday, starting fresh every year.
If you are one year experience, if you are a junior programmer surrounded by Nick Burns, please don´t feel bad. Embrace the passion of learning.

Being a Junior developer again


I know a person, he has worked in my company for more than 10 years. He knew everything about the old framework. One day, he felt like he wanted a change and moved to a new project.
Suddenly he was surrounded by young people with more knowledge about the new project.
But he was able to say and ask these questions, he went modeslty and started to learn again. Now he is an architect in his area.

Some years ago I felt so badly being a Junior. I was payed lower than my Nick Burns´ mates, I would literally sit in front of the computer, everyday, feeling like a damn, blaming myself, I would think every 5 minutes when I´m going to stop being a Junior programmer.

One day something change, I stop blaming and complaining about my role, if I had to be there, let´s take the best of everyday. I stop getting stressed about being a Junior, instead focus on learning.
I suddenly became a non-junior programmer without actually thinking on that.


In one month I´ll be starting in a new company. I´m going to be the Junior guy, I´m not going to feel bad for not knowing. Yet, I won´t arrive as a super star. I would like to be able to say: "I don´t know that" "Can I ask you a question?".
I´m looking forward to being again a Junior programmer. Because life is so boring that we have to keep moving ourselves out of the confort zone. Yes, it feels hard in the begining, but isn´t it great when you have faced that and you have learnt something new.

Please let´s go and change our bussiness. We have a long way to go.

Here you can read the full article written by Jonathan Barronville about this:
 https://medium.com/i-m-h-o/what-it-really-means-to-be-a-junior-developer-266acb772b4b

If you don´t know Scott Hanselman, please go now to his blog:
http://www.hanselman.com/
I met Scott in NDC 2014 here in Oslo. He gave a great talk: Fun with Javascript. Fantastic talk:
http://vimeo.com/97454683

Keep coding, keep learning!

domingo, 29 de junio de 2014

Keep that simple!



You can find beauty in code, beauty is in simplicity.
There´s one quote by Plato that states:

Beauty of style and harmony and grace and good rythm depends on simplicity.

How many times we have been told that code should be:
-Readable.
-Maintainable.
-With great quality.
-That we must follow SOLID and a number of other principles.
-That we must use patterns when appliable.

Simplicity is all of them together, this is what Plato is telling.

But what is beauty? This is a very subjective question.
For some architects, beautiful buildings are big ones, full of exotic luxurious stuff, whilst other would say minimalist buildings are the most beatiful ones.



If you are a drummer, and somebody asks what is a beatiful rythm, you may say you like simple grooves that just follow your heartbeat. Other would say beauty is virtuosity in a complex solo fill.
And not to mention human beauty perception... Do you prefer, blondies or a gorgeous brunette, or a beautiful brown haired woman?:)

I see programming as an art, we create beauty, yet beauty that works, that´s useful, but still an art.
We are given a complex requirement, full of use cases and scenarioes to cover, full of abstract concepts, and we create a system that satisfies them all.
Where is beauty in our art?
Well, imagine you are in front of your source code system, and I tell you to find a beautiful code you remember. I bet that something you will find in that code is simplicity.
(Forgot to tell, please study, read,... others´ code. Why? Ok, we agree cooking is an art. Would you be likely to master cooking if you don´t go and taste famous cookers´ creations? If you don´t look for their secrets, their magic ingredients?)

I can remember I once saw a not very beautiful code. It was full of paths, strange names, only a few classes with lots of dependencies and complex inheritance structure. Hard to test, hard to add a single line of code without breaking anything.
On the other hand, I remember we did a beautiful simple code following the strategy pattern, it was like magic how the strategy was triggered. We had a change from customers, it was extremely easy to add another strategy without changing the controller classes. We met a number of principles when we created that code (open-close is one of my favourites, yet not easy to met).

But making something simple implies knowledge. Knowledge of the domain, knowledge of technology and experience.

A couple of weeks ago I did a code that wasn´t so beautiful, I know, I´m not proud of it:)
We are creating a process that runs periodically every day. I was told under code review: check with a test that everything is resumed ok after a power cut in the middle of the process.

"Ouch, that is difficult, how do I simulate a power cut in a test and later on assert that a subsequent run was ok, inside a single test..." "Parallel tasks" was my first thought. I had been reading about C#5 new parallel programming features, I wanted to proof I knew it.
Here is a simplified version of what I did:
 
[TestMethod]
public void Check_clean_up_after_power_cut()
{


  //Prepare first run, interrupted by power cut
  bool didPowerFail = false;
  var powerFailSimulatorToken = new CancellationTokenSource();
  Task interruptedProcessTask = new Task(() =>
  {    using (powerFailSimulatorToken.Token.Register(Thread.CurrentThread.Abort))
    {
           try
           {
              Process.Start();
           }           catch (ThreadAbortException)
           {
              didPowerFail = true;
           }
     }
  }, powerFailSimulatorToken.Token);

  SimulatePowerFailMock(powerFailSimulatorToken);
 //Trigger first run
 interruptedProcessTask.Start(); while (!didPowerFail)
 {     //Still running first process
 }
 
//Trigger second run of process
 Process.Start();

 Asserts...
}
 
Cool eh?...

I felt like a beast: "it´s likely that this test is going to be the most complex test in my company, I´m the best". But Ok, haven´t we told that beauty is in simplicity.

Yes, this test is ugly, hard to read, fragile, hard to refactor and very likely to be a pain in the ass for a future programmer. In one word, complex. Tests should be simple.
I didn´t have enough knowledge of the domain. I just jump to the code, without taking my time to analyse the system. I just wanted to prove that I can do complex stuff.
Of course, code review came and I did this:
 
[TestMethod]
public void Check_clean_up_after_power_cut()
{

   //Simulate first interrupted run by inserting corrupted test data
    SimulatePowerFail(powerFailSimulatorToken);//Trigger second run of process
    Process.Start();

    Asserts...
}


Yes, it´s simpler, but isn´t this better?

A number of ways to achieve simplicity in your code:
-Don´t jump to code without fully understand the problem. Take your time, run existing tests, make sketchs, do a meeting with your colleagues and explain the problem.
-Do TDD. Yes, you will be creating a lot of tests. People don´t like TDD because it slows the development process. For me that´s a mistake, while you are incrementally developing the system, you will be creating a simpler class structure that makes all of the tests to pass, while making the code minimun.
As stated by Uncle Bob, tests grow to specific, logic gets more generic and minimun.
-Read and read code. Even if you are reading something you are not working on. You are in front of somebody else´s work and time. Please sit back and relax and understand why that was written.
-Go to conferences, read books, keep yourself educated. Famous cookers educate themselves, they go to workshops, they go to other famouse cookers´restaurants. Please eat others´dishes.
-Don´t think: if it was hard to write, it should be hard to read. Instead think that your code is going to stay for a long time (at least some years), it should be easy to maintain and fix. Oh yes, it would be eventually fixed:).
-Code reviews... Yes, cookers receive feedback. Imagine you create a new dish, you give it to the jury, but then they don´t tell a word about it, they just go home. Do you think you will improve that dish? Will you think that dish was ok, or that they didn´t like it?

If you just want to keep one thing after this babble, keep this:

Beauty is born and found in simplicity.


Jørn Ølmheim, 97 Things Every Programmer Should Know


What do you think? Have you had any experience about that? Any trick you use? I appreciate feedback:)
 
Speak soon, keep coding!