Team coach and full stack developer.
Team coach and full stack developer.
Daniel and Martin have been in the same team since the beginning of summer and they’ve been collaborating in an unconventional way. Yassal interviews them to understand what’s been going on.
You’ve been successfully using mob programming with your team at Expressen for the past 6 months. How did you get started?
Daniel: The project started without any tech solutions in mind. We decided as a team that mob programming was a good way to figure out what tech stack to use. We had no backlog, but we sort of knew what we needed to do
Martin: I remember proposing this as the best way to do discovery work from a tech perspective. We didn’t know what language or tech platform we were aiming for, and this way we would learn more quickly as a team and could come to a decision.
So, what is mob programming anyway?
Daniel: I don’t really care about the formal definition, to me it’s group programming rather than pair programming. One person is at the keyboard and the others act as support, coming up with suggestions, or researching potential solutions. This helps the whole team stay on the same page, and makes sure that we’re all learning at the same pace.
Our goal at the Crisp hack summit last weekend was to migrate our 2 year old shopping app written in Meteor to the latest version and to learn about Google’s material design. Our old app was built as a way for us to learn Meteor. The structure is less than ideal, and as we learn new things we add them to the app, but don’t revisit old parts. So we followed Dan North’s experiment rewriting the app from scratch. We also decided to use Materialize for the UI. We wanted to rewrite the app in 2 days, keeping all the functionality we currently have, but at the same time adding the UI and usability improvements that we really need.
We ended up completing the rewrite in 9 days: 2 hack days and then a couple of hours each day for the next week. Not too bad for a brand new app, but surprisingly longer than we would have guessed. Both Meteor and Materialize are pretty simple to get started with, but adding Materialize to Meteor proved to be challenging. Here are some highlights!
How do you decide what to build next? Who comes up with the ideas? How do you decide in what order to implement them? How do you keep track of what you’re working on, and what you want to work on?
Here’s a behind the scenes look at how the Candy Crush Soda team comes up with ideas and decides what to build next!
Curious about how we developed Candy Crush Soda at King? Like any project we’ve had our challenges. We developed the game on a framework that had never been tested live, while programming in two languages simultaneously to support multiple operating systems. Adding to the challenge, we started working without a prototyped game idea, within an existing Saga format that comes with a long list of features that players are used to. The project, code-named Stritz, was born in the spring of 2013. We soft launched a year later, and hard launched in the fall of 2014. This is our story.
At my current project we use a Google spreadsheet to manage our backlogs. This works really well for storing and sharing the backlog, but it’s not very good for visualizing it. So we print out the stories on cards by copying and pasting each row into a document table cell and reformatting, adding extra labels, and manually inserting priority. Well, that’s what we did the first couple of times, until I found David Vujic’s fantastic Index Card Generator for Google spreadsheets (http://davidvujic.blogspot.se/2011/06/visa-vad-du-gor-eller-dude-wheres-my.html).
Except, we have multiple backlogs in one sheet, our column names aren’t the same, and we use a different layout for the cards. Here’s how we customized David’s script! read more »
Here are the slides from my lightning talk at Crisp today on Continuous Delivery!
There are no standard plugins for Grunt in Gradle, but it’s easy to add all the code manually. After all, this is Gradle not Maven 😉
Have you ever been part of a great team? Or worked with one? I’m ending an assignment at Projectplace, where I’ve been working with team “SNAP”. SNAP is a great team! As I move on to other challenges I’ve been thinking about what makes a team great.
Jez Humble posted a blog entry with the same title in 2010, but if you haven’t read the entry, or just want a quick explanation, here’s the short version:
A continuous delivery pipeline automatically tests the application, but keeps the deployment decision as a manual step. A continuous deployment pipeline, on the other hand, will automatically deploy this working version. There is no “right” way. Different organizations have different needs. Use the one that delivers the most value to your customers!
Continuous delivery is a hot topic. A lot of people are talking about it, but implementation in the real world is scarce. I lucked out at my last assignment when I was at SVT (Swedish Public Television) and got the chance to work on implementing a continuous delivery pipeline.
When I started, the project had delivered once and was gearing up for its second delivery. Representatives from each team met, and we decided to aim for an (at the time) aggressive schedule of one release per week! Our first “fast” release would go out in January, and we would continue from there.
It would be nice to say that this worked out well and we were continuously delivering from then on, but this blog entry is about our road to continuous delivery, so my story starts here!
I gave a talk to a group of mechatronics students at KTH (Royal Institute of Technology) today. The topic was agile software development with an emphasis on Scrum, and some information about Kanban and Lean Startup. Here are the slides:
Thanks to everyone who attended the Mobile First Responsive Design Seminar.
If you’re curious about mobile first responsive design, here’s the presentation http://www.yds.se/mobile-first-responsive/:
The “slides” (a mobile first responsive site) are also available on GitHub: https://github.com/crispab/mobile-first-responsive
read more »
read more »
For the past couple of years I’ve had to work with Jira. Really, it’s mostly been dreading working with Jira. At both projects I’ve had Greenhopper available, and that hasn’t really made things better. My frustrations have had to do with the complexity of setting up the right fields, to creating a new sprint to creating a new project, down to mundane things like problems with ranking. I don’t particularly enjoy spending hours just tidying up my data. I want to quickly organize so I have time to actually work. I also want to easily see how much work we’ve done, and how much we have to do. Cards and a physical board are great for this, but I end up with stacks of cards everywhere, and after several sprints I don’t know what to do with them anymore. Enter Trello! read more »
Backbones aren’t the usual fare for tech blogs, but if you’ve been following frontend development, then you’ll have heard of Backbone.js. From their site: Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions,views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface. read more »
The Let’s Test conference (“A European conference on context-driven testing – for testers, by testers”) kicked off today in Sweden. I know, I’m not a tester, so why was I at the conference? Certainly it wasn’t the “context-driven” that drew me, since before I heard of the conference I didn’t really know what that was. The “for testers, by testers” wasn’t so inviting to me as a developer, even though as a member of an agile team I write unit and regression tests, and participate in functional and exploratory testing.
I’ve been playing around with a cool presentation tool, Impress.js by Bartek Szopka.
All you need is an editor, some HTML5 and CSS3 know-how and you’re up and running:
Mercurial is my first serious foray into distributed version control systems (dvcs). When I started gathering my notes for this entry I knew that this would be a really negative review of Mercurial. The first version control system I actually liked was Perforce. Several years later I encountered Subversion, it took a while to adjust but eventually I grew really fond of it. For the past 3 months, I’ve been using Mercurial… definitely not impressed. Or so I thought, but as I looked through my cons, I saw pros all over the place. So here are my [not-so-negative-after-all] thoughts on using Mercurial!
Great retrospectives are amazing, they have a way of really getting a team to work together and to energize them ahead of a new challenge. But even a great retrospective becomes boring and routine after a while. Luckily, there are a lot of us at Crisp working with different teams, so we got together this evening for a peer to peer exchange about retrospectives. We each got to pitch retrospective exercises and games that we’d like to try, or that we wanted to share. We ended up discussing and trying out 9 of them. Here’s a summary in case you’d like to try some of them out at your next retrospective!
I had a conversation with some of my colleagues about what makes a good daily stand-up, here are some properties:
* The team has dumbells by the scrum board. The rule is that if you feel the current speaker is monopolizing the meeting, you can hand the speaker a dumbell. Now the speaker can keep talking only as long as they can hold up the dumbbell with an outstretched arm.
I attended the Optimera STHLM conference this spring where SSL was a recurring theme. The speakers convincingly argued for more extensive use of SSL in websites. Consider that without SSL anyone can see what you read online, what you look at and what your interests are… I was pretty confident after the conference about setting up a website with SSL, and I got the chance to test it out soon after. In the process I discovered that sometimes it’s a bit tough to find information when you have a problem with the implementation, or when you want to learn more. So here’s a how-to guide with what I learned and links to the resources I used most. Maybe it’ll help you, and hopefully you can give me some feedback
So let’s get started!
read more »
After several years of running our blog on Pebble we’ve made the move to WordPress, and it’s pretty exciting! But how did we get here? It turns out that migrating a blog from an unsupported platform is not very difficult, all you need is a bit of programming know-how and in a couple of hours you’ll be migrated!
Pebble stores all of its data in XML files on the server, WordPress data can be imported from WordPress eXtended RSS format. XML to XML pretty straightforward, you just need to pick a language! I figured I would try out Groovy since it seemed to offer some nice api’s for processing and producing XML.
read more »
You may remember Mats Henricson’s blog entry about what we know at Crisp. Well now we’ve put that same tag cloud (with some minor changes) on a mug!
I’m sure you’ll be seeing these mugs in the hands of a Crisper near you in the coming weeks, but here’s a sneak peek:
I’ll just start out by saying that I’m no Jira expert, in fact I don’t even have Jira admin privileges at my current project. I do however use Jira at least once a day. I manage versions, and create components. I also create stories and epics, and try to maintain sprint and product backlogs in Jira. My project also uses Greenhopper.
My problem today? Greenhopper stopped ranking my stories! Or rather started randomly ranking my stories! In the Greenhopper planning board view, every time I edited a story or epic and saved my changes, my backlog would get re-ordered. It didn’t take long before my whole backlog was scrambled, the more I tried to fix the ordering the worse it got.
If this happens to you, do not try to fix the ordering! Stop making changes, and… “Optimize(repair)” your ranking field!? Yeah, that’s right, you need to fix the ranking field every once in a while. You’ll find this “great” feature under Tools -> Configuration, under General find the Ranking Field section. Here you’ll find the Optimize(repair)link, just click and wait… and wait… and wait… and then your ranking problems will be solved.
Unfortunately, you’ll still have to come into the office tomorrow and somehow get your product backlog back in the right order, because it’s still scrambled.
No solution is perfect, but sometimes it feels like Greenhopper is a just way too far from perfect.
nb the version of Jira we’re using is v4.0.2#472 and Greenhopper v4.3
I recently ran up against a large XML file and legacy code that manipulated it.. the code had mysteriously stopped working, there were no unit tests and the XML file was large and had no line breaks. What do you do in this situation?
Loading the 30MB file in any kind of editor made the editor slow. Trying to format the file left the editors unresponsive. There’s no point in doing a grep find on a one line XML file, and while writing a cleanup script to add line breaks makes life better, why reinvent the wheel? Googling yielded several windows programs at first, but digging further, and using social networking finally produced two fantastic products for unix/linux based OS!
The first and easiest tool to use turns out to be xmllint! It’s most likely available with your unix/linux distribution just type it at the command prompt. Running xmllint –format my_file.xml > my_file_formated.xml will add line breaks where they make sense in your XML file. Now you can easily perform a grep find, you’re halfway there!
This perl program was the icing on the cake! You can download it here: http://search.cpan.org/dist/XML-Twig/ and then all you need to do is install it using the provided Makefile and you’re up and running. How did this help? Well among the hundreds of options provided with XML-Twig there’s a tool called xml_split. Just type xml_split my_file.xml and it will split your large unreadable file into manageable smaller ones. You can find more information about the usage here: http://search.cpan.org/dist/XML-Twig/tools/xml_split/xml_split
With just these two tools it’s easy to write unit tests against smaller sections of the XML file. It’s also easy to find the problematic sections in the XML file and easier to make changes and to test the fix!
What tools do you use?
Once upon a time all we had was java.util.Date and it was not good… then Sun introduced java.util.Calendar, and it got worse! How often do you sit at your keyboard and wonder how you can avoid writing date manipulation code just because you hate to look at the resulting mess? Maybe your project uses service or utility classes to hide the ugliness, but you know it’s still there. Well, stop hiding, there’s something better: Joda-Time!
If you’ve read Michael Feathers’ book, Working Effectively with Legacy Code, you’ll know that he presents his techniques for refactoring clearly and simply. My favorite is his metaphor of finding the “seams” in the code to break it apart then “sew” it back together again. If you’ve attempted to implement some of these techniques in your own project you’ll also know that it’s not easy. It is slow arduous work, and when there are no unit tests it can be scary.
Crisp hosted Michael Feathers’ course:”TDD and Refactoring Techniques” this week in Stockholm. I hoped that some secret knowledge of how to refactor easily would be revealed, something that was just too elusive to express in a book. Instead my experience that refactoring is difficult was reaffirmed.