Archive for the ‘Pair Programming’ Category

A Week in the Dojo

Amanda Alvarez

Amanda Alvarez

Amanda Alvarez

Latest posts by Amanda Alvarez (see all)

Hello readers! My name is Amanda and I am the Dojo’s newest member here in Cambridge. Words cannot describe how excited I am to be here! I am normally afraid of big changes, but I felt comfortable with this new beginning as I had a gut feeling this team would help me begin my career in this journey. It really helped my anxiety when Victor Fong gave everyone on the team a Lego Pokemon toy after he just returned from a trip. Here he is!

Once I met my team I jumped right into standup with literally no time being wasted to get my day started. Shortly after, I was paired to work on UI project. This exposure to code without needing documentation about it really blew my mind away. However, I get to see Ruby, HTML/CSS, git, and angular JS all in one day! Later, I got to rotate with my team to work on deploying Kubernetes. It can be challenging to understand what is going on, but that is because this is my first time really using things like Ruby or cloud technologies. My week with this new team finished with retro on Friday, which is when we all get together and talk about the good, okay, and bad things that happened during the week. I admitted in the bad category I felt ashamed for taking too longto learn, but I was reassured by the whole team these things take time and that I will get better.

So what have I learned?

  • Ask lots of questions. People want you to learn! There is no such thing as a stupid question. 🙂
  • Things will break. Sometimes it is an easy fix like adding a missing parenthesis. Sometimes it is a challenge that takes a day or two to figure out.
  • Ruby is a weird language. That is all I have to say about that.
  • DevOps is a really efficient way of rapidly delivering code.
  • Test Driven Development and pair programming made my first week feel almost seamless. I say “almost” because I have so much learning to do in order to get familiar with this kind of environment.
  • Tools such as Diego, Kubernetes, and Bosh can do many “things.” You might ask, “What kind of things?” And I could probably tell you they help manage deployment of containers and VMs.
  • Don’t be afraid to make mistakes. They’re something to be learned from.
  • Everyone has something to bring to the table. Share your ideas, even if you might be disagreeing with others.

Hopefully this gives you an idea of how much I learned during my first week, I am fortunate to be working with intelligent individuals who make up an amazing team. From my past experiences, I have never worked so closely with people as I have been since working here. No more contributing to one thing from the confinements of the cube of solitude and instead working with people on multiple project at a given moment. It is so easy to ask anyone what is going on because they are all familiar with the ongoing projects that are happening. Being able to pair with someone has definitely made my transition into this role feel easier. This team is passionate about what they do, and it really motivates me to do my best to get up to speed with their skills. At the time of this post, I have been working in this role two weeks now and the time feels like it elapsed in seconds. I wake up everyday to come to work feeling energized and thrilled to be at the office. Hopefully I can share something more technical next time!

~$ whoami
Before I go, I should probably share a few things about me. My favourite hobbies include: gardening, 3D printing, video games, and reading. This year I have successfully grown various herbs, such as basil and parsley, and I am an avid succulent/cactus collector. I like to 3D print miniatures and tiles that get painted for D&D, which I play occasionally when I find a good group to play with. I have always been a PS2 girl at heart, but I have been playing PC games for the last 4 years now. Lastly, I like to read mostly sci-fi books and I am currently reading through Stephen King’s “The Dark Tower” series. This pretty much sums me up outside of work. So feel free to reach out if you ever want to talk about what I do for work or my hobbies! I would love to get to know more people in this community. 🙂

Dell EMC Dojo at Hopkinton! Reviewing what we covered, and what we learned

Reviewing what we covered, and what we learned

Hey again everyone! We’re writing out today to talk about a few topics that we covered during our time at the Dell EMC Dojo Days in Hopkinton. We met with a lot of great minds and took plenty of input into how we work. We also gave a lot of insight to passersby in what we did and how we worked.

Firstly, Brain Roche and Megan Murawski debuted the famous “Transformation Talk”. We normally give this presentation in preparation for an engagement with another team, but in this case, it was given to allow open criticism and circulation of our methodology to the rest of the company. We cover in this presentation: pairing, and why it’s important to our process, why we use TDD (Test Driven Development) (and why you should too!), and our weekly meetings including Retros, IPM, and Feedback to name a few. We had plenty of great ideas and questions, as usual, and we realized twenty minutes over time that we couldn’t get Brian off the stage.

Xuebin He eventually got Brian off-stage for a talk he conducted on CICD (Continuous Integration, and Continuous Deployment). Xuebin being one of the developers at the Dojo allowed him to be a bit more technical in his talk, and cover some of the programming practices and tools we use to achieve this at the Dojo. Concourse is our tool for running our beautifully constructed tests, along with standard mocking design patterns and the code quality produced with TDD.

We picked up again on Tuesday at 1145 to talk about why a PaaS exists, and why it’s important. That talk, given by yours truly, was focused on some of the common technical roadblocks that keep developers, customers, and managers from being able to work efficiently; as well as the ways using a PaaS can solve those problems to build a better business.

To containerize applications for a PaaS, we would need to learn basics like “What is a 12 factor application, and what’s a container?” Thinh Nguyen stepped in and gave a great description on how we use guiding principles while developing our application environment to be better for us and our customers.

Throughout all of our talks, we worked away on two pair stations very carefully brought from our lair in Cambridge. We gave away some free swag, some free candy, and raffled off some super giveaways. We thank everyone involved in preparing and executing these few days for their hard work. We also want to give a huge thanks to everyone who attended our talks (rambles) and participated in some mind-expanding conversations.

Finally, I want to close with a few notes. We always enjoy fresh perspective. If you had more to say, or you missed us during our time and you want to start a conversation, leave a comment in the comment section! If you don’t want to comment here, then drop us a line in my email. We’d love to hear from you.

Until next time, remember: Cloud Foundry, Open Source, The Way. #DellEMCDojo.

Introducing Ginkgo4J Ginkgo for Java

Ginkgo for Java

Paul Warren

Paul Warren

Paul Warren

Latest posts by Paul Warren (see all)

Having been an engineer using Java since pretty much version 1, and having practiced TDD for the best part of 10 years one thing that always bothered me was the lack of structure and context that Java testing frameworks like JUnit provided.  On larger code bases, with many developers, this problem can become quite accute. When pair programming I have sometimes even had to say to my pair

“Give me 15 minutes to figure out what this test is actually doing!”

The fact of the matter is that the method name is simply not enough to convey the required given, when, then semantics present in all tests.

I recently made a switch in job roles. Whilst I stayed with EMC, I left the Documentum division (ECD) with whom I had been for 17 years and moved to the EMC Dojo & Cloud Platform Team, whose remit is to help EMC make a transition to the 3rd platform.  As a result I am now based in the Pivotal office in San Francisco, I pair program and I am now working in Golang.

Golang has a testing framework called Ginkgo that was actually created by one of Pivotal’s VPs Onsi Fakhouri.  It mirrors frameworks from other languages like RSpec in Ruby.  All of these framework provide a very simply DSL that the developer can use in his test to build up a described context with closures. Having practiced this for the last six months I personally find this way of writing tests very useful.  Perhaps the most useful when I pick up an existing test and try to modify it.

Java version 8 has included it’s version of closures, called Lambda’s.  Whilst there aren’t quite as flexible as some of their equivalents in other languages; all variable access must be to ‘finals’ for example, they are sufficient to build an equivalent testing DSL.  So that’s what I decided to do with Ginkgo4J, pronounced Ginkgo for Java.

So let’s take a quick look at how it works.

In your Java 8 project, add a new test class called as follows:

Let’s break this down:

  • The imports Ginkgo4jDSL.* and Ginkgo4jRunner add Ginkgo4J’s DSL and JUnit runner. The Junit runner allows these style of tests to be run in all IDEs supporting Junit (basically all of them) and also in build tools such as Ant, Maven and Gradle.
  • We add a top-level Describe container using Ginkgo4J’s Describe(String title, ExecutableBlock block) method. The top-level braces {}trick allows us to evaluate the Describe at the top level without having to wrap it.
  • The 2nd argument to the Describe () -> {} is a lambda expression defining an anonymous class that implements the ExecutableBlock interface.  

The 2nd argument lamdba expression to the Describe will contain our specs.  So let’s add some now to test our Book class.

Let’s break this down:

  • Ginkgo4J makes extensive use of lambdas to allow you to build descriptive test suites.
    You should make use of Describe and Context containers to expressively organize the behavior of your code.
  • You can use BeforeEach to set up state for your specs.  You use It to specify a single spec.
    In order to share state between a BeforeEach and an It you must use member variables.
  • In this case we use Hamcrest’s assertThat syntax to make expectations on the categoryByLength() method.

Assuming a Book model with this behavior, running this JUnit test in Eclipse (or Intellij) will yield:
Screen Shot 2016-06-02 at 8.31.35 AM



Focussed Specs

It is often convenient, when developing, to be able to run a subset of specs.  Ginkgo4J allows you to focus individual specs or whole containers of specs programmatically by adding an F in front of your Describe, Context, and It:

doing so instructs Ginkgo4J to only run those specs.  To run all specs, you’ll need to go back and remove all the Fs.

Parallel Specs

Ginkgo4J has support for running specs in parallel. It does this by spawning separate threads and dividing the specs evenly among these threads. Parallelism is on by default and will use 4 threads. If you wish to modify this you can add the additional annotation to your test class:-

which will instruct Ginkgo4J to run a single thread.

Spring Support

Ginkgo4J also offers native support for Spring. To test a Spring application context simply replace the @RunWith(Ginkgo4jRunner.class) with @RunWith(Ginkgo4jSpringRunner.class) and initialize you test class’ Spring application context in exactly the same way you normally would when using Spring’s SpringJUnit4ClassRunner.

The nooptest @Test method is required as Spring’s JUnit runner requires at least one test class.

Trying it out for yourself

Please feel free to try it out on your Java projects. For a maven project add:

or for a Gradle project add:

compile ‘com.github.paulcwarren:ginkgo4j:1.0.0’

for others see here.

2 Heads Are Better Than 1: Pair Programming at the #EMCDojo Pairing at the EMC Dojo, Brian Roche Sr Director of Engineering

Pairing at the EMC Dojo, Brian Roche Sr Director of Engineering

Brian Roche

Brian Roche - Senior Director, Cloud Platform Team at Dell EMC. Brian Roche is the Leader of Dell EMC’s Cloud Platform Team. He is based in Cambridge, Massachusetts, USA at the #EMCDojo.

I work on a team where we practice ‘pairing’ and pair programming every day.  Before joining this team I had only a passing experience with pair programming. And now, after many months of pairing, I have a much better understanding of why we pair.

Pair Programming Explained
Pair programming is a technique in which 2 programmers work as a pair at one workstation.  One, the driver writes code and focuses on the tactical aspects of syntax and task completion.  Two, the observer considers the strategic direction of the code they’re writing together.  In our case, each developer has their own monitor, keyboard and mouse but is connected to one IDE.  The two programmers switch roles often.


Follow Us on Twitter

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.