How to add IntelliJ Google Style Guide to IntelliJ

Leave a comment

For some reason intelliJ doesn’t let you import code style guides.
Like the Java one I wanted to use from Google.

https://github.com/google/styleguide

To import the style guide (intellij-java-google-style.xml) after cloning the repository, to this.

> cd ~/Library/Preferences/IntelliJIdeaXX
> mkdir codestyles
> cp /intellij-java-google-style.xml .

Fire up intelliJ, goto preferences, search for Coding Style, and you should see Google Coding style there.

Screen Shot 2015-08-07 at 2.19.55 PM

Links that help

https://github.com/HPI-Information-Systems/Metanome/wiki/Installing-the-google-styleguide-settings-in-intellij-and-eclipse

The Making of Karateka by Jordan Mechner – A Review

Leave a comment

When I saw that there was a book on Amazon about the making of one of my favorite childhood games – Katateka – how could I not click ‘buy’.

Just to be clear, this isn’t a book. It’s a journal. A short, sketchy stream of consciousness from a kid who, while taking Psych at Yale, created one of the Billboards top seling number one Apple games of the 80s – Karateka

That journal itself won’t appeal to use unless you are already a big fan of the game, or you are just really interested in the creative process. For me this was both.

I was fascinated to read how Jordan had to simultaneously deal with the frame rate limitations of the Apple ][, juggling a full course load, while hammering out a deal with Broderbund, while also watching a tonne of movies and considering becoming a full time screen writer.

It’s just a fascinating journey that does contain nugets of wisdom for those who are looking. Here are a few of my favorites:

Maybe what makes great artists — composers, painters, writers, filmmakers — different from competent ones isn’t so much raw ability or talent (although they help) as the willpower to continue refining a design until it’s really perfect.

I get this. I feel this when I write, draw pictures, or just try to come up with innovative ways of teaching people about computers. I know I’m not the brightest tool in the shed. But I also know what it’s like to spend hours on a single paragraph, until that very moment when you just get it right, and it glows!

You can’t do good work in an art form you don’t love yourself. I still do, sometimes, really get into a video game – Lode Runner, Dr. Creep – and it’s that part of me that I’ve got to aim at pleasing. If I can’t satisfy myself, I won’t satisfy anyone else.

Who are they? It’s us!

This perhaps my favorite quote of the book. It’s here that Jordan explains why some games are awesome, and some aren’t. Here is was referring to ports of Karateka to other platforms. None of them were as good as his on the Apple ][ because no one else was prepared to spend the 100s of hours it took to get the animations just right. No surprise. Just reassuring. That love, hard work, attention to detail still maker. And that people feel it when they use your product.

Anyways, I loved this book. And I just started reading the companion journal Prince Or Persia. I will post more then if I find something worth sharing.

Cheers – Jonathan

Digital Revolution – Stockholm Tekniskamuseet

Leave a comment

Just had an awesome tour today of a killer retro computer display at the technology museum today.

That had Mac, Next machines, Mac with the lid off where you can see the signatures of the designers, Altairs, Commodore PET, it was all so cool. They even had my old Garfield phone.

Anyway, checkout the picts and display text if you are intro retro gaming. And if this display comes to your city be sure to check it out. It’s very cool.

JR

Screen Shot 2015-07-26 at 4.44.35 PM

Screen Shot 2015-07-26 at 4.44.28 PM

Screen Shot 2015-07-26 at 4.44.22 PM

Screen Shot 2015-07-26 at 4.44.14 PM

Screen Shot 2015-07-26 at 4.44.08 PM

Screen Shot 2015-07-26 at 4.43.56 PM

Screen Shot 2015-07-26 at 4.43.51 PM

Screen Shot 2015-07-26 at 4.43.43 PM

Screen Shot 2015-07-26 at 4.43.38 PM

Screen Shot 2015-07-26 at 4.43.31 PM

Screen Shot 2015-07-26 at 4.43.26 PM

Screen Shot 2015-07-26 at 4.43.21 PM

Screen Shot 2015-07-26 at 4.43.17 PM

Screen Shot 2015-07-26 at 4.43.11 PM

Screen Shot 2015-07-26 at 4.42.59 PM

Screen Shot 2015-07-26 at 4.42.52 PM

Screen Shot 2015-07-26 at 4.42.48 PM

Screen Shot 2015-07-26 at 4.42.33 PM

Screen Shot 2015-07-26 at 4.42.27 PM

Screen Shot 2015-07-26 at 4.42.22 PM

Screen Shot 2015-07-26 at 4.42.16 PM

Screen Shot 2015-07-26 at 4.42.08 PM

Screen Shot 2015-07-26 at 4.48.44 PM

Screen Shot 2015-07-26 at 4.48.32 PM

Screen Shot 2015-07-26 at 4.48.26 PM

Screen Shot 2015-07-26 at 4.48.20 PM

Screen Shot 2015-07-26 at 4.48.15 PM

Screen Shot 2015-07-26 at 4.48.02 PM

Screen Shot 2015-07-26 at 4.47.56 PM

Screen Shot 2015-07-26 at 4.47.42 PM

Screen Shot 2015-07-26 at 4.47.35 PM

Screen Shot 2015-07-26 at 4.47.27 PM

Screen Shot 2015-07-26 at 4.47.18 PM

Screen Shot 2015-07-26 at 4.47.12 PM

Screen Shot 2015-07-26 at 4.47.07 PM

Screen Shot 2015-07-26 at 4.46.33 PM

Screen Shot 2015-07-26 at 4.46.27 PM

Screen Shot 2015-07-26 at 4.46.20 PM

Screen Shot 2015-07-26 at 4.46.14 PM

Screen Shot 2015-07-26 at 4.46.09 PM

Screen Shot 2015-07-26 at 4.46.04 PM

Screen Shot 2015-07-26 at 4.45.57 PM

Screen Shot 2015-07-26 at 4.45.49 PM

Screen Shot 2015-07-26 at 4.45.44 PM

Screen Shot 2015-07-26 at 4.45.33 PM

Screen Shot 2015-07-26 at 4.45.27 PM

Screen Shot 2015-07-26 at 4.45.20 PM

Screen Shot 2015-07-26 at 4.45.13 PM

Screen Shot 2015-07-26 at 4.45.06 PM

Screen Shot 2015-07-26 at 4.45.00 PM

Screen Shot 2015-07-26 at 4.44.54 PM

Screen Shot 2015-07-26 at 4.44.44 PM

Launching Spotify on the Sony Playstation

2 Comments

Delivering a new product to 60 million users

Last week was an exciting one for me and my team here at Spotify. We launched the Spotify player on the PS3 and PS4 and brought the Spotify music experience to over 60 million PlayStation users. Here are some notes on how we did it.

How it was run

This was a big project – one that spanned many tribes and cut right across the entire organization. Marketing, sales, licensing, distribution, all of tech. It was also very distributed with Sony and Spotify teams spread across San Francisco, London, Stockholm, Tokyo, and New York.

Spotify doesn’t have project managers. But for this project we did appoint someone to play the role of an overall programme manager. This was key because there were a lot of moving parts, and someone needed to help coordinate.

We did several onsite visits. Many teams came to Stockholm. We went to Tokyo. And there were a lot of early morning/late night calls (not to mention a tonne of email and Slack chats). Every Friday we also had a standing lunch where anyone interested could get an update on where things were at along with the current problems we were facing.

My team was responsible for building the app that would run the Spotify player on the PS3 & PS4. Four developers, three QA, a designer, a Product Owner, and me the coach.

Challenges we faced

Spotify doesn’t normally do projects. Instead we prefer giving teams a goal, and then letting them decide when best to release. We didn’t have that luxury. Sony’s old music application was due to shutdown at end of March, and we needed to be ready with our player to take it’s place. So in that sense, this was a very traditional project with a really hard deadline.

How we overcame

We ran this project like a typical Scrum project, only we quickly resorted to a kind of code and fix mentality that often comes when you realize you have too much to do and not enough time.

In addition to playing coach I also played the role of project tracker (tracking things like our team velocity and keeping an eye on overall deadline). For pretty much the entire project things didn’t look good. We had too many features. Not enough time. Typical project stuff.

Spotify’s approach to situations like these is to leave the team alone and let them sort things out for themselves. If they want extra help it’s there. But really it’s up to the team to solve their own problems.

What was interesting on this project was that the team (mostly the dev’s) didn’t initially want any outside help. Even when it became apparent that there was too much to do.

There was an inflection point in the project were senior management insisted we take someone else on (a fourth developer). This turned out to be a very good choice. Our new addition ended up making an invaluable contribution and we wouldn’t have made it without him.

But this leads to an interesting question for management – how far should you trust the team, and how do you know when to step in and ‘overrule’ their judgement. It’s not an easy call.

Finally, and perhaps most importantly, the one thing we did have going for us is we were the #1 priority project for the entire company. This meant that whatever we wanted – we got. A project this cross cutting and of this size can’t be handled alone. And the entire company was needed to pitch in. So when we needed people, meeting rooms, resources, or just decisions, people on the team just pulled out these ‘magic’ project cards and things got done. It was a fun way to work. But one you must be careful not to abuse.

Finally, this project required a lot of overtime, weekend, and late nights to bring across the finish line. We made it. We delivered. But there was definitely a human cost in terms of time, capital, and technical debt.

The launch

Now for the fun stuff! Here are some pictures of the war room on launch day.

There was a lot of coordination and monitoring that needed to happen on launch day. We created a war room, with each team represented at their own workstation.

spotify-sony-playstation-1

We also had sample Sony Playstation on standby, so we could log in to different regions around the world and make sure things were working.

spotify-sony-playstation-2

We also had a real cool analytics team that specializes in tracking usage in real time around the world.

spotify-sony-playstation-3

The Apollo launch feeling was created by design. Several pictures a phones like these were in full force that day.

spotify-sony-playstation-4

And this is what things looked like just before launch.

spotify-sony-playstation-7

spotify-sony-playstation-8

We kept the war room going for about 48 hours. Once Sony pushed their package out to all the PlayStations, we slowly saw people start to come online around the world, and it was great to see no major hiccups or disruption our backend services couldn’t handle.

To be honest I was amazed. I wasn’t expecting anything to go smoothly. What isn’t easy to see is the amount of work that goes on behind the scenes to make something like this happen. So many things can go wrong.

But somehow it worked. It all came together. It wasn’t Agile. It wasn’t any process, or secret sauce. It’s that same old cliche – it was the people. The talented, passionate group that went the extra mile, stayed the extra night, and worked the extra weekend to make this thing happen.

In Summary

I don’t know if I will ever get to participate in an event of this magnitude ever again. It’s pretty incredible to see this much focused work come together in this timeframe, in a single effort.

But I am thankful to have been a part of it. And I want to thank my team for all their hard work and making it happen.

umbrella-team

Newsletter

If you like this newsletter, you can find more here:

http://www.agilenutshell.com/newsletter

Pragmatic Programming in Java 8 with JUnit

Leave a comment

Jeff Langr recently put out a new book Pragmatic Unit Testing in Java 8 with JUnit which I highly recommend. I’ve recently come back to Java (mostly through teaching XP courses) and wanted a refresher on some unit testing best practices. Jeff’s book didn’t disappoint.

Here are some take aways and language for for me from this great gook.

AAA – Arrange – Act – Assert

Exposing Private Data Versus Exposing Private Behavior

Try not to test private methods/data too much.
Occasionally is OK. But if you are constantly exposing deep, gobs of interesting behavior it’s usually a violations of the SRP (Single Responsibility Rule) which states that classes should be small and single-purpose

Your best bet is to extract the interesting private behavior and move to to another class where it can be public behavior.

What to test?
Flex your Right-BICEP.

Right – are the results right?
B – Boundary conditions
I – Inverse Relationships
C – Cross check results with other means
E – Error conditions
P – Performance

Remember Boundary Conditions with CORRECT
Conformance – Does the value conform to the expected format (i.e. email)
Ordering – Is the set of values ordered or unordered as appropriate
Range – Are values within acceptable min/max range.
Reference – Does the code reference anything external not under direct control of code itself
Existence – Does the value exist (is it non-null, nonzero, present in a set, so on).
Cardinality – Are there exactly enough values (0 values, 1 value, 10 values etc, off by one)
Time – Is everything happening in order? At the right time? In time?

Anyways. This is a great book and one you should definitely checkout if you are into unit testing in Java.

Classical vs Mockist testing

2 Comments

I’ve been looking for language to help articulate the difference between two styles of unit testing, and really like how Martin describes it in Mocks Aren’t Stubs.

 

Classicist Mockist
Like working with real objects Prefer working with fake objects
State verification Behavior verification
Use mocks to test collaborations Use mocks all the time
Will hard code collaboration Will mock collaborations
TDD from middle out TDD from the outside in
Use ObjectMothers/Factories for test setup Will mock only what they need for test collaboration
Test tend to be more coarse grained – approaching more integration style tests Tests tend to be very fine grained – may miss integrations
Classists don’t couple tests to implementation Mockists do
Classists don’t like thinking about implementation when writing tests Mockists do
Don’t mind creating query methods to support testing Mockists typically don’t have to
Classists style can encourage Asking Not Telling design Mockists style encourages Tell Don’t Ask

Classical vs Mocking

I generally prefer the classical style to the mocking mostly because I don’t like thinking about implementation when writing a test.

I do however like having the mocking option in my back pocket, for those cases when a system is difficult to test, an object has a nasty setup, or I am refactoring legacy code.

The other piece of advice I recommend (my ex colleague Jonas Claesson turned me onto this) is to keep your calculations separate from your orchestrations.

If you can do this you get the best of both worlds. Calculations can be classically testing. Thin orchestrations mocked. Should keep both set easy to read, and easy to setup.

Here are some more summary notes from Martins article.

Article summary

Regular tests

  • state verification

Mock tests

  • behavior verification

Classical and Mockist Testing

  • Classical style uses real objects
  • Mocking style is to do everything with mocks
  • Classicists will use mocks for creating doubles

Choosing between the differences

  • If collaboration of objects is easy – classic is obvious choice
  • If collaboration between objects is awkward – mock
  • No big choice to be made here
  • Where things get more interesting is when we talk TDD

Driving TDD

  • Mockist will TDD there systems from the outside in
  • They will start with the GUI, describe their collaborations, and progressively marching deeper and deeper into the stack one layer at a time
  • Classical TDD doesn’t offer that kind of guidance
  • Whenever a classist requires something from a collaborator they simply hard code it
  • But classists take a slightly different approach – middle out
  • Here a classist will create an object for whatever domain they need and once they are working then you layer on the UI
  • Doing this you may never need to fake anything
  • Focuses the attention on the domain model, which helps keep the logic from leaking into the UI

Fixture Setup

  • Classic TDD needs to create SUT with all it’s collaborators
  • Mockists need only create SUT and mocks for immediate neighbours
  • Classics will do this using ObjectMothers – reuse whole objects
  • Mockists will say this is more work
  • Classists will say we do this once and reuse – you setup every time

Test Isolation

  • If you introduce a bug mocking, only those tests whose SUT contains the bug will fail
  • In classic, any tests of client objects also fail – ripple effect throughout system
  • Mocksts will say make finding bug harder to find
  • Classists say its usually pretty obvious – little bit more noise

Granularity

  • Classic tests can be more coarse grained than mockists as they test overall interaction of objects
  • In essence classic xunit tests are not just unit tests, but also mini-integration tests
  • Classists like this
  • Mocksts lose that quality – also run the risk that the mocks are incorrect masking inherent errors
  • Which ever way you go you need both – coarse and fine grained

Coupling Tests to implementation

  • Mockists couple their tests to implementation
  • Classiss don’t care about implementation – only the final state – not how it was arrived
  • With mock testing, writing the test makes you think about the implementation behavior
  • Mocksist like this – classists dont
  • Coupling implementation also interfere with refactoring, since implementaiton changes are more likely to break tests than classic testing

Design style

  • Classist are more comfortable creating query methods to support testing
  • Mockists don’t have to do that as much
  • Mocking also encourages Tell Don’t Ask
  • Classis can encourage Asking Not Telling – though in practice this is easily hadnleld
  • Mocking can also result in more classes (interfaces in various languages)
  • May not be as true now, but i remember many more interfaces and classes being ccreated than was necseary when mocking
  • Also DHH dislikes the designs mocking sometimes creates – mockists like it

Classic or mockist?

  • I have never seen a reason to go all mock
  • Mockists focus solely on implementation details of the SUT – never felt nature to me

Jonas

  • Don’t combine logic with orchestrations
  • Logic classis – classic mock
  • Orchestrations – simple as possible, no calcs, mockist

Links that help

http://www.martinfowler.com/articles/mocksArentStubs.html

http://googletesting.blogspot.se/2015/01/testing-on-toilet-change-detector-tests.html

Turn that ship around

Leave a comment

My friend Jason Yip shared with me the work book for Turn this Ship Around which comes as a highly recommended book on leadership.

He also had a cool deck of cards I wanted to save to later. Here are some images for when I am ready to do so.

turn-that-ship-around-1
turn-that-ship-around-2

turn-that-ship-around-3

turn-that-ship-around-4

turn-that-ship-around-5

turn-that-ship-around-6

Older Entries

Follow

Get every new post delivered to your Inbox.

Join 333 other followers

%d bloggers like this: