TDD and CI - closing the agile loop over system programming using Go (golang)

With Google Go becoming more popular and accepted, it becomes important for us to know the right framework to apply for adopting a TDD and CI approach to writing application written in Go. Especially, when we are talking in the context of writing software which interfaces with system drivers and services.


We will also look at how we can create a build pipeline to run automated tests and continuously integrate into a packaged software.


Other programming environments, have achieved a good level of maturity with tools for writing tests. I will present how we adapted our learnings in such environments into development in golang.

 
 

Outline/Structure of the Demonstration

1. Overview of the Go language
2. How developing in Go may bring in new challenges
3. How we tried to mitigate the challenges
4. Demonstration of TDD in Go
5. Demonstartion of CI Integration with automated testing for the Go tests
6. Caveats

Learning Outcome

At the end of the talk, I expect people to be at a good position to evaluate testing and integration strategies when developing in Go. Especially when there are device drivers to mock and stub.

We will see if writing a system program is different from writing a web application and how we can adapt.

Target Audience

developers

schedule Submitted 7 years ago

Public Feedback


    • Daniel Zen
      keyboard_arrow_down

      Daniel Zen - Agile Engineering Javascript with Jasmine & AngularJS, Karma & Jenkins

      Daniel Zen
      Daniel Zen
      CEO
      Zen Digital
      schedule 7 years ago
      Sold Out!
      90 Mins
      Tutorial
      Intermediate

      Agile & Test Driven Development of frontend JavaScript User Interface code is often passed over using the excuse that the UI code is "declarative" (What you see is what you get) and therefore does not 'need' to be tested. Others, will dismiss testing frontend AJAX code as too difficult to maintain or unnecessary because it is only important in context with the server. We will show how these misconceptions are false. 

      We will cover several popular JavaScript tools and technologies that make Agile frontend web development easy. We will show how these front end technologies cannot only be functionally tested, but Unit Tested. If time is available will cover Continuous Integration, Dependency Injection, & Mock objects.  

      By including your front-end code in your automated testing process you can prevent the inclusion of bugs that are usually only caught with manual testing.

    • Naresh Jain
      Naresh Jain
      Founder
      Xnsio
      schedule 7 years ago
      Sold Out!
      45 Mins
      Demonstration
      Intermediate

      "Release Early, Release Often" is a proven mantra and many companies have taken this one step further by releasing products to real users with every commit a.k.a Continuous Deployment (CD).

      Over the years, I've built many web/infrastructure products, where we've effectively practiced CD. However at Edventure Labs, when we started building iPad games, we realized there was no easy was to practice CD, esp. given the fact that Apple review takes a few days.

      Our main question was: As mobile app developers, how should we architect/design our apps for CD?

      We were a young startup, learning new behavior about our users (kids aged 5-8) everyday. We could not afford any delay in releasing latest, greatest features to our users. To solve this problem, I believe we've built an innovative solution to enable any mobile app developer to achieve CD.

      If you are building real products, which have platform/3rd-party dependencies and you want to practice CD, this session is for you.

    • Pramod Sadalage
      keyboard_arrow_down

      Pramod Sadalage - Ten Patterns of Database Refactoring

      Pramod Sadalage
      Pramod Sadalage
      Software Developer
      ThoughtWorks
      schedule 7 years ago
      Sold Out!
      45 Mins
      Talk
      Beginner

      Over the life of an application as requirements change, application usage patterns alter, load and performance changes the need to change database and database architecture is inevitable. There are patterns of these changes such as

      1. 1. Encapsulate Table with View
      2. 2. Migrate method from database
      3. 3. Replace method with views
      4. 4. Introduce Read only table
      5. 5. Split table
      6. 6. Make column non-nullable
      7. 7. Drop column
      8. 8. Add foreign key constaint
      9. 9. Merge columns
      10. 10. Replace columns

      In this talk we will discuss the above database refactoring patterns and different implementation techniques to enable blue, green deployments, allow for legacy applications to work with fast changing database and enable the teams to effectively refactor the database to fulfill the changing needs of the organization.

    • Johannes Brodwall
      keyboard_arrow_down

      Johannes Brodwall / Niruka Ruhunage - Remote Pair Programming

      45 Mins
      Demonstration
      Beginner

      Can you maintain agile engineering practices with a distributed team?

      Johannes is the Oslo based Chief Scientist for the Sri Lanka based company Exilesoft. In order to promote agile engineering practices, he uses remote pair programming to connect with teams halfway across the world.

      In this talk, we will go through a practical approach for remote pair programming adopted for high-latency situations. We will demonstrate remote pair programming with a live example and we will discuss the advantages and usages of the approach. We will also cover the practical parts of remote pair programming, such as tools and setup.

      After seeing this talk, the audience should be able to remotely pair with members of their distributed team. They will also get a lot of tips on how to use pair programming effectively in both local and remote settings.

    • Shashank Teotia
      keyboard_arrow_down

      Shashank Teotia / Pramod Sadalage - Polyglot Programming and Agile Development

      45 Mins
      Demonstration
      Advanced

      Polyglot Programming as a technique is not new and as a paradigm was coined in 2006 by Neal Ford. In today's world, we often architect solutions which need to be highly scalable, secure, efficient, have an engaging GUI, be extensible with low technical debt in parts or whole. To work with a single tech stack promotes a sense of mono culture which is detrimental and limiting the way a solution can be designed. Moreover, with multi-core machines available, processing now can leverage parallel processing and it maybe make more sense to use a language which takes away the overhead of the intricacies of multi-thread programming.

      In other words, in many cases, engaging in Polyglot Programming helps you focus more on the domain and adds to developer productivity.

      On the flip side, increasing the moving parts also means that if not designed well, Polyglot Programming could be a double edged sword and produce more mess in the way different pieces interact with each other.

      In this talk, we will showcase an ecosystem we built, involving a desktop device configuration backed, an OS-agnostic desktop GUI, a cloud service, a cloud cluster configuration tool and how we used the Agile principles, namely TDD, Continuous Integration and the works to be able to keep the polyglot ecosystem sane.

      Name wise, the languages/tools/etc which we used in our Polyglot case – Google Go, Node-Webkit, JS (Knockout/RequireJS), Ruby, Cucumber, RIAK, Chef, Lisp, Jenkins

       

    • Vinodhini
      keyboard_arrow_down

      Vinodhini / Thushara Wijewardena - Robotic Warehouses, Alien Domain, Offshore developers, Visionary customer : Saved by agile

      20 Mins
      Experience Report
      Intermediate

      Here is a case study of how agile outsourcing can be practically applied even when the business domain is very complex and alien to offshore teams.
      The example is a project in which Exilesoft provided for a leading Norwegian producer of Robotic warehousing solutions. The project involved transforming their legacy application, produced using multiple suppliers and methods, into a newly cast application solution. This project also had its own share of typical challenges.

      • Lacked definitive and reliable documentation,
      • Domain knowledge was limited to a few very busy individuals,
      • Development and redeployment could not interrupt attention to current customers,
      • Complexity was high and design was fragmented, and
      • Focus heavily invested on current product and customer support

      These limitations along with the lack of understanding of agile methods strongly suggested the use of a method adaptive in nature, and not heavily vested in large inflexible legacy elements.
      We commenced the engagement with two pivotal elements; client awareness (agile orientation) and a roadmap of committed involvement. To lay credibility this had to be backed up with proven result delivery in the very early stages. It allowed for flexible adaption, and the creation of an atmosphere that fostered client interest.

      During this session, we will take the audience through a small video clipping of such a warehouse. We will elaborate how the customer and offshore developers worked together using agile in a highly integrated team collaboration model to achieve success within a very short time frame.

      The session will cover the following key areas:

      How such projects can be initiated

      - What type of team model and contract type we used

      - How we did the agile transformation with the customer

      - How the roles were assigned between offshore and onshore team members

      - To improve remote collaboration the tools and techniques we used

      - Techniues learned to get teams up to speed with the new domain

      - As we go along, the process changes we identified and implemented to make things work better.

      - Agile engineering practices and team dynamics that helps in such situations

    • Prasanna Vaste
      Prasanna Vaste
      Business Analyst
      ThoughtWorks
      schedule 7 years ago
      Sold Out!
      20 Mins
      Experience Report
      Beginner

      On Agile projects we estimate user stories in order to allow team to

      1. 1. Track velocity
      2. 2. Decide scope for the Iteration
      3. 3. Help Prioritize stories
      4. 4. Help Release planning

      But most of the time we faced issues with estimation. It takes lot of time in estimating user stories, managers tend to relate estimate to number of days it will take to complete the story, in some teams estimate is equal to deadline. Most of the teams which use story points to estimate the work face these issues. This results in lack of confidence on development team when stories are taking more time to complete.

      Here I am going to talk about better alternative for both the suppliers of software products (financially and ethically) and their customers (internal and external). This alternative is being used in real companies delivering to real customers with great effect where team uses count of stories completed in an Iteration as measure of progress. Will talk about how this alternative can be used to track velocity, prioritize stories, planning Iteration and for release planning.

      I will share some exmples from my past projects where team did not use story points/velocty but used count of stories completed in Iteration to measure progress and also as best indicator of future performance.

    • Johannes Brodwall
      keyboard_arrow_down

      Johannes Brodwall - Kicking off agile remote teams

      Johannes Brodwall
      Johannes Brodwall
      Exilesoft
      schedule 7 years ago
      Sold Out!
      90 Mins
      Workshop
      Beginner

      So your project is just getting started. Or maybe you're just about to embark on a new release. Or new members just joined the team. What now?

      In either situation, your project will have a lot of energy and attention right now. But at the same time, there's probably a lot of uncertainty about what to do first. Many projects waste this valuable time without a clear plan or purpose. In Exilesoft, we have refined activities to deal with these problems, even with the additional constraint that the team may be distributed geographically.

      In this workshop, we share a typical plan of what activities to do every day in the first weeks together with a set of activities which yeld tangible results in terms of team building, vision, architecture and a coherent working system in a minimum of time. Participants will get a chance to practice the skills as well with several interactive exercises.

    help