NDC Oslo 2013, day #3

TDD, where did it all go wrong

General

There are different kinds/levels of testing:

  • Unit testing:
    • testing class/method:
      • Helps us to get good design, but coupled to the implementation details
      • Implementation details is going to be changed so that we need to change also our class/method tests => which is expensive and we are lazy to do it => we skip it and the tests are dead
    • Testing behaviour:
      • HERE should be the focus
      • When implementation details have changed but behaviour stayed same, these tests are untouched and we should be free to refactor them
  • Integration testing
    • Testing componentization
      • Should be small amount of them
  • UX testing

ATDD

  • hard to maintain
  • Written by business analysts, customers, maintained by devs => nightmare,
  • Results in RED state
  • What’s the value  having them? They are veeery expensive

 

 Where did all go wrong?

  • Writing UT against classes, methods

 

Read the book written by Kent Beck: Test driven development by example to understand more, should be like a bible for devs who takes testing seriously

 

 

Zen of testing

  • Don’t write tests against UX
  • UX is going to be changed so your tests have to be changed
  • Let UX devs write them

 

Write tests against surface of module , avoid testing against implementation, don’t couple to implementation, couple to the behavior

 

Testing should be done using simple steps:

  • Get solution to the problem fast
  • Don’t solve the problem and engineer together, split them! Then unit testing becomes a part of problem solving task
  • Result:
    • Write hacky code just to make test working but DON’T STOP THERE!!! please
  • Engineeirng comes later => in form of refactoring!!!!, please, keep it in mind!

 

 

Result

DON’T COUPLE TESTS TO IMPLEMENTATION DETAILS!!!!!!

=> you write less tests

 

 

Common issue

Ice cream problem:

  • Manual testing is too expensive
  • Automated GUI tests – we need to rewrite them as soon as UI changes, they are never done, stays RED
  • Most useful and the cheapest are UT

 

 

Unit Tests – focused on business logic, behavior,

Integration testing: cooperation between components

UI – testing:

  • UI widgets testing
  • Keep them manual

 

It should be like this:

 

Hexagonal architecture

  • In the center there is a Domain Model
  • Around it there are so called ports – application program interfaces – which makes surface of the system
  • Around them we have port adapters (MVC adapter, DB adapter, Notification adapter …) <= this we need to fake in order to
  • We test around ports! – public API

 

 

TDD/BDD

  • Don’t test the things you don’t own
  • UT  coupled to the implementation helps us with a design but don’t be afraid to delete them. Tests on higher level should be kept long-term only.

 

 ATDD

  • Can help to clean-up the communication developer vs. business
  • Very expensive, business people don’t want to do it
  •  

 

Summary

  • BDD is unit testing on the higher level ..
  • DON’T mock internals
  • MOCK port to adapter

 

Applied MVVM in Windows 8 apps: not your typical MVVM session!

[UPDATE] I attended this session especially to check others with MVVM experience. Good talk and I spend almost half an hour discussing MVVM details and correction. The presentation was built on the author’s experience rewriting  Contoso cookbook into MVVM style.  

 

IMHO the author applied  “programming against interfaces” too much, everything what was possible was abstracted via interface. When I asked why, the reason was: I like it. After the session I had to correct his 1 slide:

 

He was binding View to Model items, so he didn’t follow the diagram, but that’s the purist MVVM model he presented. IMHO, just from my own experience, it makes send to follow purists model. Imagine that your model items has to be extended with custom view-related properties or containing view model logic (freeze/thaw logic). Freeze/thaw model is very usefull on Windows 8 platfrorm, especially when the application is running on ARM platform. Basically it freeze the VM and all its items when the use navigated from the view and thaw when the user is back. 

Another thing we discussed and I corrected the suggested approach was a communication between view models. Suggested approach was to use the standard EventAgregator pattern and publish/subscribe approach.

The speaker didn’t have skills with authoring composite user controls but after all we agreed that sharing a master-viewmodel and making the inter-component communication via that master-viewmodel. 

There are more things to be discussed, e.g. proxy properties, but it would be to have a special post just for it. 

I’m going to rewrite Contoso Cookbook into WinJS and MVVM style so that I can make a speech on some conference 😉

 

 

Test-Driven JavaScript Master Class

Another testing session. A sessions showing how front-end JS guys could do unit testing in cross browser manner – UI TDD

 

TDD:

  • Think: small step
  • Red
  • Green
  • Refactor

 

 Areas of testing

  • State
  • Events

 

Karma for cross-browser testing

 

More info on Letscodejavascript.com

 

 

 

This time, the post is shorter than previous posts, other sessions I attended this day were good but you can watch the videos 😉 to see the all.   

 

I spent quite much time with the speakers who did the testing sessions today, also a lunch during which we had a practical coding & discussion session how to style BDD tests in Jasmine. But more about it in a separate blog. It was great event finished by attending C# 5 session made by Jon Skeet

 

ALL Jon’s sessions are worth watching them!

That’s all for now. 

 

There will be one more post about “examples/jokes” speakers used @ NDC 😉

 

PS: all videos are available online now! https://vimeo.com/ndcoslo/videos

I strongly recommend to watch all Dan North’s and architecture related videos. If you are C# dev, watch all Jon Skeet’s sessions, Jimmy Boggard’s session and SignalR session. If you like testing (you should!), watch all sessions having in the title testing/TDD/BDD.

Uncel Bob’s sessions were almost same as last year. 

 

 

The main observation from the conference is that functional languages including Js, ClosureScript, Erlang and libraries built upon them are taking the hype now! You know, more languages you know, better developer you are 😉 

 

 

 

NDC Oslo 2013, day #2

It was busy day. Very busy. Information overload!

This time, it’s be very fact-based, just programming stuff.

RequireJS

It helps to solve the following problems:

  • Developers needs to ensure that all dependency JS files are loaded in the correct order => it results in a dependency map, hard to handle, manange, etc.
  • Only god knows what’s the dependency map of the single-page apps (SPA)

 

Solution:

  • use RequireJS

 

How to start?

  • just import <script data-main=”js/main.js” src=”require.js” />

 

It’s AMD complaint (asynchronous module definition)

=> AMD is aimed to solve dependecies and modularity of the application

 

 

Module pattern

  • Helps separating public/private members, establish scoping
  • There is revealing module pattern which is better (more readable) than just standard module pattern.

 

How to define a module

  • Use define() method
  • Syntax: Define(id?, dependecies?, factoryMethod)

 

 

It’s possible to define a module with multiple dependencies:

  • multiple dependencies, but you need to follow the order of dependencies

 

Using a module

  • Using require([dependencies], callbackFunction)

 

Configuration:

 

 

Advantages:

  • It’s non-blocking asynchronous loading mechanism
  • automatic dependency map resolution

 

AMD vs CommonJS

  • The difference is asynchronous vs. synchronous loading
  • CommonJS for server side, see node.js
  • Instead of define() method there is export
  • You can mix them on the server side
  • CommonJS doesn’t make send on client-side because we don’t want synchronouse loading

 

Possible to use it for loading not just JS but other files, too. Works via plugins:

  • Plugins for loading text files, css, json, etc…
  • Other useful plugins:  async, domReady, etc.

 

This approach can result in sending many requests to the server

=> use optimizer to bundle it together, it’s page specific, works as node.js package

 

Testing

  • 2 purposes:
    • Loading dependencies
    • Overwriting loaded dependencies for so called mocking, works well with BDD/TDD style (I’ll write a blog post just about testing with RequireJS)

 

Future

  • RJs is just a middle step
  • ES6 module, export, import capabilities is going to be replacement, let’s see what comes

 

 

Summary

IMHO, TypeScript is a way to go.

  •  It can compile TS code into JS and use AMD (via RequireJS) for resolving dependencies and
  • once browsers support ES6 (hope next year), the TS compiler will just use new capabilities, no changes on development side

 


Maintainable CSS

talk about how to organize the CSS in the maintainable  way. See slides attached.

Takeaways:

  • Use SASS (already using ;o)
  • Look at the Compass which provides SASS plugins
  • Follow object oriented style of CSS
  • Use BlockElementModifier style of writing the CSS style names
  • Take a look at:  Scalable and Modular Architecture for CSS

 

It’s great to see our front-end guys following much of that style which really turns CSS into maintainable piece of code

Unfortunately, not very good talk.

 


Telephones and postcards: our brave new world of messaging

This was performed by Jimmy Boggard. I met his output when using StructureMap, anyway, respect!

Nice talk, I bet you to see online video next week. Main takeaway was how he presented CQRS system on real-world example (ala burger king shop). I like this style when the speaker use real-world examples explaining the technical stuff. If you want to use CQRS (I bet you should know about it), watch the video!

 

 


 

Erlang: a jump-start for .NET developers 

I must say great talk. Great to know about Erlang, its approach. Deails can be found here

 Takeaways:

  • functional language which can achieve 99.9999% of availability
  • complements C# as any functional language
  • concurrency oriented language, fits really very well for solving concurrency problems with fault tolerance
  • Main idea about concurrency:
    • Concurrency via message passing is faster, scalable and cheaper 
    • Shared memory concurrency is hard 
  • Difference to traditional styles:
    • 1 thread in WinOS allocates by default 1MB
    • 1 thread in Erlang just 1 kB => results in less overhead, bigger throughput
    • and many more … 

 

It’s main goal is: concurrency and fault tolerence

 

Already used by many known companies in the production!, i.e. Facebook

Btw, Erlang concurrency model reminds me new OS, currently in the development phase, Midori.

 


The Architecture of Uncertainty

Again, general talk, worth watching the video.

Takeaway:

  • isolate uncertainity from your system by making a border (interface) so that the code is not affected when uncertainty evolves. 

 

 


ClojureScript: Lisp’s Revenge

Funny message was announced by the presenter: JS is dead ;), closure will survive 😉

 Takeaways:

  • Based on LISP
  • Solves JS pitfalls
  • Compiles to JS
  • Has module support
  • Immutable lists
  • Better scoping
  • Equality is based on the value
  • Uniform interfaces
  • Lazy sequences,
As it’s know, it’s good to know this language because it can help to solve i.e. pattern-matching-based issues in very elegant, clean and short way. I had a talk during party with the closurists and it’s really different approach, but interesting.

 

Uff, that’s all for now… yeah, party time  .. 

MaintainableCSS.pdf

NDC Oslo 2013, day #1

This time it’s going to be a report from day #1 on Norwegian Development Conference.

 

Key note

Done by Joel Spolsky. It was interesting talk about the community he created around his stackoveflow.com site and all related sub sites. The main goal of any website/community and the reason the site is so popular is that:

know, focus and clearly define your business area (community) you want to focus on, make a business from

 

 

Accelerating Agile: hyper-performing teams without the hype

Performed by Dan North. The guy I met in our office already. 

He shared his experience working in a trading/risk SW development team.

How to organize the team, the work, etc. to get high-performing team:

  • new people on-boarding matters
    • make sure the team is prepared for new member, all dev “toys” are prepared
    • avoid giving newcomer long documentation, etc. – just remembered my start in the previous company
  • each day the team has 2 standups – morning stand-up and before end-of-day the demo to product owner so that all are on the track, the work is demo-ed
    • approach we use often, just coupling it together with morning stand-up meeting
  • plan the work but for short time, 1 week is the most appropriate, 2 weeks are acceptable
    • as usual, planning is essential, plans are useless
  • working in the distributed system 
    • tooling support for agile team doesnt matter, keep it simple, use board, sticky-notes, make a screenshot and publish it on the board (results in presenting them on the retrospective meeting, in form of chaining screenshots)
  • learning morning or lunches, no powerpoint presentations, pure coding, no excuses if somebody is missing
  • share the love within the team 
    • pairprogramming (results in the best code), 
    • do code review -> less shocking, more learning, ask new members to do codereview – more learning about the code, startup
  • DO learn new languages, programming styles (CSP, actors, fork-join), SCALA, Go, Closure
    • the main goal is to learn from others, to get other ideas which could be useful in your daily work
  • Functions, objects ~ namespace vs. classes/prototypes in dynamic languages
  • Prioritise risky over valuable. You don’t want: value, value, value, showstopper, sorry, we have to throw that away
    • implement first with risky stuff then values

 

All in all, great talk, worth watching online when the video will be available.

 

 

The Abstractions of AngularJS

Done by Scott Allen. 

 

  • it’s used for one-page applications, which is very similar to WWA applications
  • simple usage for simple problems
  • based on MVC pattern
  • having dependency injections (DI) in Javascript solved:
    • translate function code into string, take first line of the method containing the signature, parse it and use internal DI service
  • data binding, DOM manipulation, animations, UI extensions etc. is done on developing so called “directives” which are used as the attributes on the DOM elements
  • defines very clean separation of concerns (MVC), constraints the developer from misusing MVC pattern
  • Knockout vs AngularJS – more religious decision but Angular keeps the patterns strictly followed but could have performance issue
Comparing to WinJS for WWA apps, I’m more than happy to stay with WinJS, just missing more business application support from WinJS: dependency injection/resolution support.

 

 

Do it right, then do the right thing

Main message:
  • keep short iterations, development and deployment cycles 
  • develop a feature together with feedback gathering logic (i.e. usage statistic), make customers to give you the response, release the feauture, inspect/analyze data and adapt change and again. All in short iterations.

 

 

Patterns of Effective Teams

Again, Dan North, again great talk!

The talk was going around the following map:

 

Patterns

Dreyfus Squared

  • Different levels of people, do the pairing!, share the love and knowledge within the team

Shallow Silos

  • Rotate team/pairs

Seize of Day

  • Energize standups, discuss the status, not just report!, we don’t care about the brief status: I did XYZ, I will do ABC, I have no issues. Do the real scrum as it was inspired from american footbal to decide what the team will do now, today and how it’s going to solve the current problems.

Near and far

  • Cross-funcational teams vs. single specialized teams
    • solution in the middle, keep having very specialized teams but ask them to teach cross-functional teams

Warm welcome

  • already covered in his previous talk

Code Critique aka code reviews

  • Learning from others
  • Socializing

 

Team Hack Days

  • “TODO” days
  • “SMELLS” days – fix the smells in the code, I know, you don’t have smell in the code, just in case 😉
  • “RESEARCH” days
  • go and play with non-project tasks
  • => getting people together, great ideas can evolve

 

Walk a mile:

  • What’s the benefit of person (dev, manager)
    • Walk in his/her shoes
    • Take him off and let’s see

TDD

  • Can slow down in case I don’t know where you are heading to, i.e. prototyping, proposing different solutions, 
  • Find a balance where it’s needed, some simple code could be verified by explanatory tester and it’s wasting of dev time

 

 

You are not (only) a software developer! – Simplicity in practice

Done by Russ Miller.

Very common problem is over-producting. SW devs tend to write the SW to have fun during the coding, creating over-complex code instead of solving business value in the most simple way. 

The main goal how to solve the business issues:

  • create impact map, use 5 why method, root cause analyzes
  • explore the problem before writing the SW 
  • move from delivering valuable SW to delivering the valuable change and SW is just one of the options

 

 

Faking Homoiconicity with graphs

Done by Mark Seeman.

Some languages (most notably LISPs) exhibit a characteristic called Homoiconicity, which means that code is data and data is code. This makes a language very powerful because a program can inspect and manipulate itself.

  • Complex business logic with many if/else statements is very hard to test. Solution is to transfer business logic/code into data + behavior, example mortgage contract rendering processor
  • Inspect the code and extract the common interface, i.e. 
    interface IRendering {
        IEnumerable<IRenderingNode> Render()
    }
  • Apply composition
    class Renderer {
        IEnumerable<IRenderingNode> Render() {
            for(var renderer in this.Renderers) {
                yield return renderer;
            }
        }
  • The result:
    • Write test for general compositor to prove the code works
    • Write small tests for each different render
    • Total amount of the tests is smaller, the business logic is covered by tests, design is clean, SOLID principal applied => ALL good.

 

  • Could apply testing by example
    • setup compositor (i.e. renderer with rendering nodes) 
    • serialize it into data! – JSON, XML, 
    • transform it to business readable form (i.e. HTML) and 
    • communicate with the business, 
    • make them verify it => specification/definition by example

Summary

I missed many other sessions but all videos will be published out on the internet in a week or two.
That’s all for now.