barbarianmeetscoding

hackerz edition

A Brief Guide on How to Pass the 70-480 Certification Exam

| Comments

A couple of weeks I did my first certification exam ever and I passed! Wihoo! I thought that you who are planning on taking this or any other certification exam could maybe find my experience of value and thus here we are. :)

I approached the whole exam thing mainly as an excuse to learn and refresh my knowledge in web development, starting from the very basics to the more advanced APIs that I hadn’t had the chance to look into, trying to fill in all the gaps that I felt I have had in my web dev knowledge in the past. So this is not going to be an article on how to pass the exam with the least amount of effort possible, no tricks or shortcuts, it is just going to be an article about how I went about preparing for the exam, just plain old studying, practicing, coding, learning and writing a freaking exam XD.

Barbaric Basics: Building Flexible Layouts With Flexbox

| Comments

With Barbaric Basics I brush up on basic techniques, practices and APIs. Come along and get them refreshed you too. Who knows? You may even learn something new!

Today we live in a world of many devices, many resolutions, many form factors and as such it is more challenging than ever to build websites that provide an awesome experience in all of these different and ever-changing conditions.

Fortunately, HTML5 brings with it a couple of new techniques that let us developers create flexible layouts with less hassle than ever before: flexbox and grid. I have created a tutorial/walkthrough that I hope will get help you start getting acquainted with Flexbox, the most mature of these two new layout systems. I hope you’ll enjoy it!

To Flexbox Tutorial

Flexbox is a stable standard and is supported by all modern browsers (>IE10), so there’s no reason not to start using it today.

And here are some additional references if you want to learn some more!

Barbaric Basics: Web Workers

| Comments

With Barbaric Basics I brush up on basic techniques, practices and APIs. Come along and get them refreshed you too. Who knows? You may even learn something new!

So in something like a couple of weeks I am going to be taking my first ever Microsoft certification exam! I am going to start with the 70-480: Programming HTML5 with JavaScript and CSS3 and get my way through all the web development stack. A certification? – you may ask yourself – Do you even need that? Is it worth anything?

And This Was Swetugg on Day 2

| Comments

And it was a wrap-up for Swetugg the Swedish conference for .NET developers by .NET developers.

Swetugg

tl;dr; Great second and last day at the conference with more interesting talks on BDD, specification by examples, Conway’s Law, Polyglot programming and persistence, event sourcing, graph databases, document databases, Entrepreneurship, Lambdas, UX magic, EPiServer and Game Development backed on Azure.

And This Was Swetugg on Day 1

| Comments

Today I was at Swetugg a Swedish .NET conference organized by the very awesome members of the Sweden .NET User Group also known as SWENUG. I thought it would be nice idea to write down my impressions of the different talks, the event itself and point you to some resources if you yourself find any of it interesting.

Swetugg

tl;dr Great small conference with interesting talks on Gamification, SOLID, TDD, Design, Akka.net, ApprovalTests, F# and Web Security.

Barbarian Meets Aurelia: First Contact and Building Athena, My Very Own Jarvis

| Comments

The “barbarian meets” series are a collection of articles that intend to introduce and explain useful libraries, frameworks, tools and technologies in simple and straightforward terms. These new series will focus on the brand new framework from Rob Eisenberg the maker of Durandal and Caliburn frameworks which brings all the goodness of ES6, ES7 and web standards to your toolbelt: Aurelia

This week Rob Eisenberg surprised us all (or me at least xD) when he announced his new web framework Aurelia, a framework that allows you to start using the latest and greatest in JavaScript and web standards to build your apps today.

Learning Test Driven Development With Kent Beck

| Comments

With Barbaric Book Reviews I bring you interesting reviews and useful insights from awesome books that I have read. I also bring myself the magic of everlasting memory so that I don’t forget these tidbits of knowledge as I grow old and wither.

I have been doing TDD (Test Driven Development) for the past 4 years and yet I didn’t know that Kent Beck had written a book expressly devoted to teaching TDD. So image my surprise as I was browsing the interwebs for my next book-ish victim and I stumbled upon Test Driven Development By Example.

Test Driven Development By Example

This is one of the most pedagogic and hilarious programming books that I have read. Imagine that you had the chance to learn TDD sitting beside Kent Beck in a pair programming session. Cool right? Well that’s how the book feels like. You and Kent will program side by side and test drive a multicurrency system in Java, and a testing framework in python (and yes, you will test drive the testing framework while using it to run your tests #inception #ftw xDDDD). And to wrap it all up, Kent summarizes and reflects about useful test patterns, refactoring heuristics and useful design patterns for both testing and refactoring.

I leave you with a quote that describes who TDD is for:

(…)TDD rests on a charmingly naive geekoid assumption that if you write better code, you’ll be more successful. TDD helps you to pay attention to the right issues at the right time so you can make your designs cleaner, you can refine your designs as you learn.

(…) TDD is also good for geeks who form emotional attachments to code. One of the great frustrations of my young engineer’s life was starting a project with great excitement, then watching the code base decay over time.

(…) TDD enables you to gain confidence in the code over time. As tests accumulate (and your testing improves), you gain confidence in the behavior of the system. As you refine the design, more and more changes become possible. My goal is to feel better about a project after a year than I did in the starry-eyed beginning, and TDD helps me achieve this.

Test Driven Development By Example Kent Beck

Update 22th January 2015: So I was having a shower and my mind started wandering towards some of the interesting and surprising things that I had learned from this book that I hadn’t thought of or read about before. And I thought it would be nice to share them with you:

Start writing tests from the assert.

I have always followed the AAA (Arrange Act Assert) and I don’t know, it feels super natural to start from the beginning, so this was a super interesting proposition, to start from the end instead. Kent assures us that it has a simplifying effect, that it will help you focus on one problem at a time. He uses the example of communicating with a system over a socket. When we want to test that, what we want to achieve is to have obtained some data, and to verify that the socket is closed, so we write:

1
2
3
4
5
6
TestCompleteTransaction(){
    ...
    // Assert
    Assert.That(socket.IsClosed());
    Assert.That(reply.Contents, Is.EqualTo("abc"));
}

And then we ask ourselves, where does the reply come from? and answer A socket of course, so we write:

1
2
3
4
5
6
7
8
TestCompleteTransaction(){
    ...
    // Act
    var reply = socket.read();
    // Assert
    Assert.That(socket.IsClosed());
    Assert.That(reply.Contents, Is.EqualTo("abc"));
}

And we continue asking questions until we have our test. I have tried it a couple of times and I have mixed feelings about it. But perhaps the problem is the lack of familiarity XD.

Using TDD and Unit Testing To Learn New Libraries Or Frameworks

Another interesting concept was the use of TDD to teach yourself to use new libraries. The idea is to go get a new library that you want to learn, Install-Package LibraryXYZ and you start writing tests against its API and exploring how it works.

Alternatively you could reuse those tests that you’ve written to learn the library to make sure that future updates play well with your own codebase (no unexpected breaking changes).

Red Green Ref… Remove Duplication

It is very remarkable that when Kent defines TDD he starts not by talking about the famous Red/Green/Refactor but about the two rules of TDD:

  1. Write new code only if an automated test has failed
  2. Eliminate duplication

(which then derives into the TDD Mantra of Red/Green/Refactor). And what it is very interesting about it, is that it is not only the duplication that you refactor out of your design in your production code, but oftentimes the duplication between your tests and your code. As you go through the TDD workflow you go removing this duplication: start writing a test, write the production code that provides the easiest/fastest solution to pass the test, which will probably be a hardcoded value and thus the duplication between test code and production code. So you remove the duplication to continue the TDD workflow until the arrival to the desired solution with no duplication, unicorns and rainbows. Another cool point of view that I hadn’t reflected about.

And that’s it! Have a nice day!

Why I Write Unit Tests and Why You Should Too

| Comments

A friend from work started a conversation thread about whether or not there is value in unit testing and I wrote a pretty long response. And then I thought to myself… hmm, that could actually be a blogpost!! And so here we are, getting more value out of these precious keystrokes. Here it is the slightly rewritten version of why you should write unit tests…

I am definitely a pro unit testing kind of guy. I see it like this, in order to ensure that your code works as you expect you need to test it. In the olden days you may have done this manually, you may still test some parts of your application manually like the UI (parts where automated testing can be/feel too expensive), but the most cost-effective way to test is by writing automated tests, and particularly unit tests (test a unit of work/code in isolation). For me it’s usually about the short feedback loop, the instant and unequivocal knowledge that the code that I have just written works.

There is quite a score of benefits you can get from writing unit tests. Unit tests:

  • ensure the code behaves as you want it to behave
  • are fast to write, fast to run and provide a very short feedback loop to let you know that your code works
  • help you find bugs with super-high granularity (if a unit test shows a bug, you pretty much know which class it is in, you don’t need to go throw all classes nor debug it, that’s priceless)
  • force/encourage you to write very simple classes and increase modularity and separation of concerns (because writing unit tests for fat, complex classes with tons of collaborators is horrible and we have a natural tendency to avoid pain)
  • increase developer confidence to refactor
  • act as documentation for my future self and other developers
  • ensure that a bug/defect never happens again (regression test)
  • ensure that you don’t break something that was previously working

They are also a cornerstone for Agile development practices, without unit tests (and of course other types of automated tests) it becomes very hard to succeed with continuous integration and continuous delivery. How can you have confidence in that your application works as you expect if you have nothing to prove it? This becomes even more apparent when you have bigger application and the number of developers collaborating increases. (Although there’s people that thinks that the solution to manage complexity is to not write big applications in the first place xD). Anyhow, unit tests, and other types of automated tests, are one of the most basic fundamental elements that allows facebook or github developers to deploy to production several times a day.

At the same time, writing unit tests does not imply that you are going to catch all bugs in the universe with them or that you shouldn’t write other types of automated tests: acceptance tests, integration tests, end-to-end tests, UI tests. Different types of test have different costs/benefits and different “bug profiles” associated to them. Generally, high-level tests will provide a truer representation of the current state of your application which means high value to me, but they will typically have a higher cost to write and they will take a longer time to run (more setup, more cleanup, can be more brittle as well). You are also going to need to be ready to put some time to write unit tests and expect that you are going to write at least as much test code as production code, and see it as an investment that you can start taking advantage of instantaneously and into the future for ever and ever XDDD. Fortunately there are many tools that make writing unit tests easier and less of a hassle: testing frameworks (NUnit, MSTest, mbUnit, SpecFlow, NSpec, etc) , mocking libraries (RhinoMocks, Moq, FakeItEasy), testing utilities (AutoFixture, AutoMoq, etc), continuous test runners (NCrunch, MightMoose, etc), and so on.

If you want to be serious about testing (and about writing clean code), it is very important to keep your eyes open and exercise your awareness when writing unit tests. When you write unit tests you are exercising your own code, and you get a very good chance and are in a very good position to feel the pain, to experience whether your design is easy to use or a nightmare. TDD it is particularly interesting in this regard, you get to be the first person to use your own code. Do you feel pain when using your code? Fix it, refactor it, redesign it till you get to something that is pleasing. Do you update some implementation and break a bunch of tests? Perhaps you tests are too specific, focus on testing behavior, the appreciable results of exercising a piece of code. Test, reflect, improve (your tests and your production code).

Some Awesome Resources to Learn About Unit Testing and TDD

Books

Articles and blogs

Courses

And those were some thoughts from the top of my head on why I think that you should write unit tests :).

Other interesting articles on the subject: * Test Behavior not Implementation * Barbaric Book Review: The Art of Unit Testing 2nd Edition * Write 30% Less Test Code With AutoFixture

Barbaric Tip of the Week: Improve Your Code Typing Skills With Typing.io

| Comments

Barbaric Tip of the Week is a weekly series whose main purpose is to share tiny bits of knowledge that I find specially useful and interesting.

A couple of years ago I started using vim and I realized that my typing skills did not cut it – I did not practice touch typing but my own deformed version of typing born of using the computer from an early age mainly to play video games and chat on IRC.

I didn’t despair, not yet at least. I decided to switch keyboard layout, nothing drastic, just from a QWERTY Swedish keyboard layout to a US layout (noticing that it was much easier to type parens, semicolon and other programming keys). I also started learning proper touch typing with the typingweb – great web app for typing btw. For the next four weeks I practiced touch typing 2 hours before going to work and 2 hours before going to sleep. The first two days were horrible, I was writing like 10 WPM and thinking to myself all the time: “Come on Jaime! You can do better than this!”. It got better afterwards but that wasn’t the worst, after a couple of weeks I had sooo much pain in my wrists for the excessive typing (before, during and after work) that I couldn’t lift weights at the gym. For the next 6 months or so I wouldn’t do any curl exercise.

Today, almost two years after, I am pretty decent at touch typing and at vim-ming. I am still not as fast as I used to be but I can do 70-80 WPM relaxed when typing text. However, touch typing text is not the same as typing code. And that’s why typing.io is so awesome:

Imagine practicing typing code by using the source code of your favorite open source projects (or any other source code for that matter). Read and learn cool stuff from open source, and at the same time improve your typing skills with pesky characters such as ], }, ), *, =, etc. That’s what typing.io is all about. Cool right?

Typing some code

A lesson summary