Test-Drive your Database & the 4 Rules of Simple Design

Apr 27, 2016 by Madalina Botez in Announcements

Enjoy the following series of interviews with the speakers, top-notch software crafters from across Europe, joining I T.A.K.E Unconference, Bucharest, 19-20 May. Discover the lessons learned and what drives them to challenge the known path in their field.

Alastair Smith, developer at Redgate and founder of the Cambridge Software Craftsmanship Community in the UK and a co-organiser of DDD East Anglia, will join this edition of I T.A.K.E Unconference. After attending his sessions, participants will be able to use their programming language to clearly express a program’s purpose and stop writing the programming equivalent of legalese. They will be able to write unit tests for their own SQL code and enjoy database development again.

#1. SHARE TOP 5 THINGS YOU DID THAT HELPED YOU GROW & BECOME THE PROFESSIONAL YOU ARE TODAY

The five things that put me on this path were:

Reading software development books hungrily in the first few years of my career. Texts such as Code Complete and especially The Pragmatic Programmer and Test-Driven Development by Example were hugely influential on my early career and the direction I chose to take. The Pragmatic Programmer in particular is worth re-reading: I didn’t fully understand some parts of it as a fresh graduate joining the industry, and the experience I’ve built up over the last ten years has allowed me to get more from it on each later reading.
Attending developer meetups, user groups, and conferences. Aside from the knowledge gained from the talks and workshops run at these events, they’re an invaluable opportunity to meet other developers, learn from their experiences, and about the local software industry.
Finding a good mentor. As it turned out, my mentoring was very unofficial: a former colleague of mine guided me in the ways of professional software development, and pointed me in the direction of books, blogs, and other resources to learn from. His advice was invaluable in helping me discover techniques for writing good tests (and why tests are important), the importance of refactoring, and the foundational principles of Object-Oriented Design, such as SOLID. All of this at the beginning of my career, in an environment where I wouldn’t have otherwise been exposed to such topics.
Understanding people as well as tech. As technical people, we can often be quite blinded to the problems around us and focus on the tools and technologies rather than the underlying collaborations with other people.
Applying principles I’d learned elsewhere to my profession. I play a lot of music, and have been for over 20 years; as such, the idea of deliberate practice is quite a familiar one to me, and applying this principle to the techniques used in software development made a lot of sense. Participating in and organising things like Dojos and Code Retreats has helped me understand and improve my own development process enormously.

#2. WHAT CHALLENGES WILL THE PARTICIPANTS FIND SOLUTIONS TO DURING YOUR SESSIONS @ I T.A.K.E UNCONFERENCE 2016?

Test-Drive Your Database

Database changes are difficult to get right, and objects like Stored Procedures and Functions can be particularly hard to work on. We’ll take a tour of test-driven development, and how we can apply it to our database objects to reduce risk in deployment. We’ll also look at how we can set up a CI server to run our new database tests automatically, just as we would for application code.

Express Yourself!

We’ve all had to read contracts at various points, e.g. when renting a flat, or borrowing money, or the EULAs that ship with software (and who actually reads those, right?). These contracts are generally written in “legalese”, the language of lawyers that is so concerned with being fully precise, and closing loopholes created by interpretation, that documents written in this language become obscure and the meaning obfuscated.

Just as human languages are a communication tool, so are programming languages, and we have our own form of legalese: code that’s far too concerned with implementation details, such as nested for loops, if statements, etc. Refactoring helps us move away from this, but where should we head? If we’re writing new code, how can we best express ourselves in the code we write?

#3. WHAT ELSE WOULD YOU LIKE TO SHARE WITH PARTICIPANTS?

Creativity is an important part of my life: I play the bassoon to a high standard and recently started singing. As well as music, I enjoy cooking, and working with chocolate; photography; and losing myself in a good book. William Boyd is a favourite author, and having recently enjoyed The Hunger Games series, I’m continuing my dystopian fiction streak with the Divergent series.

Similar to the Craftsmanship metaphor for software, I like collecting “real-life” examples of software delivery ideas. Ask me about minimum viable cathedrals, or the early Sputnik launches.

I’m super-excited about Star Wars: Rogue One!

Want to join Alastair and many more software crafters from around Europe?

Join I T.A.K.E Unconference 2016!

16 years of legacy code with mob programming and Lego | Joe Wright

Feb 13, 2017

Enjoy the following series of interviews with the speakers, top-notch software crafters from across Europe, joining I T.A.K.E Unconference, Bucharest, 11-12 May. Discover the lessons learned and what drives them to challenge the known path in their field.

Joe Wright, Senior Developer, Coach & Architect, helps people deliver software that’s well designed, fully tested and released early. You will learn from his case study at #itakeunconf about how a team can go from individuals to a mob.

speaker-badge-professional-status-joe-wright

#1. Share with us 5 things from your experience that helped you grow & become the professional you are today

# Make time for deep work

Set a few hour blocks aside each week that you will dedicate to improving yourself or creating something each week. As a parent, I’ve had to start doing this by getting up early to grab two hours each day. During this time you can learn a skill, practice coding, write a book or make a podcast. It’s far too easy to let distractions rule your life. Make time to do something you are proud of.

# Become a facilitator

I think everyone is terrified of public speaking. It’s an unnatural thing to do. Our ancestors learned this behavior as a survival instinct – if lots of carnivores are looking at you then you are probably the dinner. Time to run.

Getting over this is an important step that enables you to have all sorts of life experiences. Speaking at conferences, leading workshops and meeting interesting new people. The way I beat the fear was by volunteering to co-organise a well-attended meetup. Each month I would have to get up in front of a room of my peers and say some boilerplate about welcome and the agenda. But just that act of getting up and speaking was enough to dull the fear over time. I’ve not been made into dinner yet.

As well as building yourself up as a speaker, it helps improve your network of people. People like speaking to the host at an event and it gives you an easy opportunity to learn about those people, then take a mental note when you might want to get into contact with them in the future.

# Ask for help

Don’t feel you have to figure everything out yourself or read up online. Reach out and ask people for help.

As you spend more time in your career you meet more people – and one day you’ll have a question you’d love to ask them. It’s even easier now with social media and video conferencing. People will give you 30 minutes of time online or meet you over coffee to give you their advice if they think you’ve got an interesting question to answer.

I always have a list of three things I want advice on. You never know who you are going to meet.

# Improve in more than one dimension

At first, newly minted developers want to get projects released and in users hands. During this, you try to get better at creating software that can be changed to meet their needs. Eventually, newer technology comes out, which promises to solve the problem of getting code out quicker and is easier to change.

It’s quite easy to fall into the trap of just learning technology stacks. This can be rewarding, but that’s not the only way to improve as a developer and meet people’s needs.

Seek out opportunities to see the world from the other functions in software. If you tester goes on holiday then volunteer to stand in for them. If you have an ops team then ask to pair on making the release process smoother. Facilitate a retrospective for another team. Run a usability session with real world users to see how your product is used. Stepping into another roles shoes helps build empathy, which will allow you to work better with others people in the future.

If you tech stack isn’t challenging you then concentrate on improving your “soft skills”. Teach someone how it works. Figure out ways to promote and resolve conflict on your team. Fix the root causes of communication and process issues that slow you down.

# Find people that will challenge you

It can be hard to get feedback about how you are doing. Are your ideas valid? Often you can’t get this feedback in your workplace. Seek out a group of people or a person that is willing to challenge how you think.

For me, this is the Lean Agile space and my local code craftsmanship group.

Consider these people that challenge you your core group. The way you work should be consistent with the ideals of that group. So don’t ever worry about saying what you think at work, just make sure you stay true to the principles of your core group.

#2. What challenges will the participants find solutions to during your session at I T.A.K.E Unconference 2017?

How can I reduce communication, approval, and tech debt issues from slowing down my team?
How can I measure and improve how a dev team spends their time?
How can I get started doing this at my work?

#3. Recommend for the participants 3 sources you find inspiration from and would help them better understand you

Deep Work: Rules for Focused Success in a Distracted World by Cal Newport (book)
Facilitation advice – available here
The Goal by Eliyahu M. Goldratt and Jeff Cox (book)

Want to join Joe, +30 international speakers and ~300 software crafters from around Europe?

Hexagonal Architecture Ports&Adapters with J. Martinsson & R. Sanlaville

Feb 10, 2015

Until recently, layered architecture was the most common way of organizing large applications or modules. We’ve learned from practice that it has limitations:

business rules tend to escape or be duplicated in UI and/or data layer
switching from a database to another is very difficult
adding another UI to the application (eg. mobile or smart client) requires heavy changes
changing a library used by the application with another is often complex and risky

A new architecture style has appeared in the recent years that tackles this problem: Hexagonal Architecture, or Ports & Adapters. Its intent is to allow more flexibility by cleanly separating business rules from everything else.

Johann Martinsson and Rémy Sanlaville have described the basics of Hexagonal Architecture and then shown an example of such an architecture.

Enjoy their presentation @ I T.A.K.E. Unconference 2014 edition. Curious about 2015 edition?

Check out more about I T.A.K.E. Unconference 2015 or see directly the Schedule.

Users, tests & TDD

Apr 08, 2016

Thomas Sundberg, developer with more than 25 years of experience, has developed an obsession for technical excellence. This translates to software craftsmanship, clean code, test automation and continuous deployment. At I T.A.K.E Unconference, he will share more about continuous deployment, TDD, and testing.

#1. Share top 5 things you did that helped you grow & become the professional you are today

The five things I am able to come up with now are:

Automation
Tidiness
Teaching
Speaking at conferences
Starting my own business

Automation

I have always found it fascinating to automate things.

One of my earliest experiences automating things was with my first PC where I made a boot floppy that booted the system and brought up a word processor. And it only took 1 minute or so. I didn’t really know if this was usable or not, but it was fun.

I wrote code that verified code back in 1997. A colleague of mine asked why. I thought that it was a good idea since I could. It wasn’t formalized like we do today with tools like JUnit, but it was code that verified code.

Automation has also led me to continuous integration back in 2004. This was the time when tools like Cruise Control wandered the earth. Probably hiding from dinosaurs.

Using Cruise Control, Ant and JUnit, I was able to implement continuous delivery at Gamefederation where I worked at the time. I didn’t know it back then, but that is what we call it today.

We had a build that took 20 minutes. It built the system, rebuilt the database, deployed the system and tested that it worked on a freshly setup database.

The testing was so thorough that the operations guy took the artifacts from passing builds and put them straight into production.

When I left Gamefederation, I was told that there had been times when the project manager had been thinking who he should give a task to. Should he give it to the guy leading the developers, we would say lead developer today, or to me. He concluded that if he gave it to the lead developer he would get something back in two hours and a NullPointerException. If he gave the task to me, he would get something back in two days and it would work. One of our differences was that I did unit testing and the lead developer didn’t.

Tidiness

I don’t like a mess. A kitchen sink with lots of unwashed dishes is awful. At the same time, I don’t mind some things being totally out of order. I don’t have to sort the toothpicks at a restaurant. A friend of mine, also into clean code, has told me that he sometimes does this.

The tidiness led me to Clean Code after watching Bob Martin at a keynote at Agile 2008 in Toronto. Hearing him talk about why we prefer clean code over crap was liberating. I bought his book and read it.

Clean code was among my earliest presentations.

Teaching

During an oral exam 1998, before we where even done, I was asked if I could help out as a teaching assistant in a database course. I said yes. This was a start for me where I learned that it is fun and rewarding to teach. Since then I have been working as a teacher and trainer on and off.
Speaking at conferences has enforced this urge to spread knowledge about things I think are important.

Speaking at conferences

Traveling to conferences has been a way to make new connections with people who care about the same things that I care about. That is, clean code, testing stuff, getting code into production and similar things.

I have met new personal friends this way. I have also made business with people I met at conferences.

Starting my own business

I became independent in 2013. This has given me a platform where I can strengthen my possibilities to spread the word about stuff that matters. Not just programming, but also doing it properly.

It took a while before I made the move. It was a scary decision to take. When I started there were a lot of things I was unsure of. Selling and finding assignments, taxes, book keeping just mentioning a few of them.

Running your own company is much more than just writing a few for loops and be done for the day. It is a lifestyle. But it is a lifestyle I enjoy.

#2. What challenges will the participants find solutions to during your sessions at I T.A.K.E Unconference 2016?

I have two sessions at I T.A.K.E. Unconference 2016.

How deep are your tests?

I will show how it is possible to test all paths through a system without using many integrated tests and that it isn’t possible to test all paths through almost any system using integrated tests.

I will also show that it is possible to test all paths using unit tests.

Using some mocking and stubbing in combination with actual unit tests is the way to do this. If we do this properly, we are able to check all paths through the application and will have very few integrated tests.

Definition of done: Working software in production!

This is a case study where I will share how I implemented CD at one client. CD can mean, at least, two different things.

Continuous Delivery – the system is delivered for use continuously
Continuous Deployment – the system is deployed into production continuously

The way we did this was to create packages that were possible to install as the main artifact from our continuous integration build. The target was Red Hat servers so RPM packages where a good artifact.

Delivering these packages to a YUM repo allowed us to install them easily.

The last step was to trigger the installation. We used Puppet for provisioning our servers so all we had to do to automate the deployment after a new package was built was to trigger Puppet.

#3. What else would you like to share with participants

I am an amateur musician

I play the trombone in two orchestras: One show orchestra at Stockholm University- KÃ¥rsdraget and A big band – West Side Big Band. This means that I attend regular rehearsals twice a week and sometimes public gigs at dances or concerts.

Cat lover

I have two cats at home. Sune and Gretchen. They are both cats that we have gotten through an agency that helps homeless cats to new homes.

I write a lot

I have a personal goal to write a blog post each month. I wrote a Maven plugin for helping me with my writing. Most blog posts include source code and copying and posting code is error prone. Including part or complete files that compile is less error prone. This has helped me a lot. It fits quite well with my urge to automate things.

Downhill skiing

I had never seen a pair of skis close until I was over 30. Then I joined a few friends and went skiing for a week in France. The first day was horrible. I fell and hurt myself. But after a week with ski lessons I had understood some of the basics. Skiing is a favorite activity today.

Want to join Thomas and many more software crafters from around Europe?