Schedule of 2015

  • Workshops
    August 7 -
    Codathon would bring with it an objective to meet, a problem to solve. It challenges developers & designers to build a functional app prototypes using tools and APIs provided for at the Codathon
    Raghuvinay krishna
    August 7 -
    Continuous Delivery Workshop Using J2EE
    Build a J2EE (Spring +Hibernate+ MySQL+ Tomcat+ Jenkins+ GIT) based web-application using CD principles. This application code consists of all levels of automated tests, along with a CI and deployment pipeline which keeps doing Continuous Deployment (instead of Continuous Delivery)! The product will be split across 3 feature scrum teams, doing simultaneous development. There will be a preconceived and prioritized product backlog available, split across 3 features. Participants need to install below software in their laptops before the workshop begins: a) Eclipse b) jUnit c) Cucumber plugin for Eclipse d) Git plugin for Eclipse
    August 7 -
    Continuous Delivery Workshop Using Node. js
    Build a Node.js (Node.js+ AngularJS+ MongoDB+ Jenkins+ GIT) and Angular based application using CD principles. The product will be split across 3 feature scrum teams, doing simultaneous development. There will be a preconceived and prioritized product backlog available, split across 3 features.
  • Clean Code – Experiential Talks
    Gautam Rege
    Don't Test your Code
    Testing is overrated. This talk is about using the best Agile practices for a perspective on * Code Quality * Better test coverage * Happy Customers In this talk, Gautam also would speak about his experience at Josh - a company he co-founded 8 years ago. The best (and worst) practices that they followed that helped them get the right perspective to work. Gautam would also talk about the tools that they use and integrate to reach a level where they do not have any QA personnel in their office. Everyone writes code and every tests code (including our customers). This talk is about a way to do things differently - because "Programming is an Art"
    vinay krishna
    Test-Driven Development Surveillance - Common Misinterpretations
    In this session, Vinay is going to share his encounters with different teams and their understanding of TDD. It's surprising to find that lots of wrong interpretations are still fairly common in the industry. Vinay has either worked directly with or had the chance to discuss with multiple teams in many organizations, and he has observed that in reality, people often misuse the concept of TDD.
    Writing S.O.L.I.D code
    Requirements change and so does your code. Want to make the changes less painful ? Then this talk is for you. The talk is about application of Uncle Bob's S.O.L.I.D principles in your Ruby code. The talk highlights benefits of these design principles through concrete code samples and real world application. We will refactor out a badly designed code handpicked from a production application using Uncle Bob's S.O.L.I.D design principles. It also includes practical application of 4 simple design rules by Kent Beck.
    8th August -
    One Packaged Geek Is All We Need In The New Software World
    In XP, Collective ownership holds much higher value than anything else. When the team members possess a strong sense of ownership, the beauty of the product increases by all means. In this session, let's understand how full stack developers contribute to collective ownership. Full stack developers are mere mortals having mastery over every facet of the technology stack. Even if not mastery, they at least hold genuine interest in multiple dimensions of software technology. So, the only possible outcome of having full stack developers is a great product getting built in less time by smart minds.
    deepak gururaja
    Bou Saam (African for Building together)
    This is a game Deepak developed while playing with Jenga blocks. The basic idea is to have fun while learning some of the XP principles and practices. Deepak believes, as adults, we learn more by experiencing than by being taught. If we experience a challenge and are able to find a way to come out of it, the learning will be immense and the lessons will stay with us for a longer period of time. Deepak strongly believes that such games are the first step towards driving a mindset change, as people have a first hand experience while going through the game All this, not through hearing, but, through experiencing. Participants will be asked to build a product using Jenga Blocks. Through iterations, participants will experience the learning. The game is built in a fun and interactive setup
    Utility of Test Coverage Measurements in Test Driven Development
    TDD is based on the premise that automated test is written before we write actual code. In such a scenario, we should be getting very high test coverage by default. We will discuss whether test coverage metrics have any significance in TDD paradigm. Demo: We will present an application developed using TDD from scratch. Using this application we will try to answer following questions: - Do we get very high test coverage by default. - Do test coverage measurements bring in any value in TDD - Which coverage metrics might be useful Learning Objectives: Audience should take away following learnings from this presentation - Significance of test coverage metrics in TDD - Some of the most common test coverage metrics and their utility - How to use these metrics in actual practice - Some tools for test coverage measurement
    Karthik S
    Clean Code Basics - Let's get it right
    Have you been in a situation where either you or your peer/stakeholder/client asking for overnight transformation in technical practices? Everyone day dreams to become a Master in a unfortunate? This session is an attempt to do the impossible (well I've had success with this approach ;) - convince the importance of getting the basics right and straight, by way of letting the participants make mistakes.
  • Continuous Delivery – Experiential Talks
    yami gopal
    Rapid prototyping- the lean way
    Rapid prototyping- the lean way
    Branching for CD? Think Again!
    Vivek ganesan
    Developer 2.0 - Redefine the Role of Developer to achieve Success for All
    Gone are the days where developer was responsible for just writing clean code. Traditional definition of developer affects the individual developers more than it affects the organization. The developer tends to concentrate on getting better at just the area of coding and ends up not learning the nuances of building a successful product. As a Developer 2.0, the developer performs all of the following roles. 1. Coder 2. Devil's advocate 3. Code Reviewer A developer can work in multiple stories but cannot do more than one of the above tasks for the same story. For example, the same person cannot be both the coder and Devil's advocate. A team at Gainsight worked with this improved definition of developers and saw higher product velocity, better awareness about product and increased responsiveness to issues. This session will take the audience through the improved definition of the role of developer and present some thought-provoking questions to the audience to make them realize that the traditional definition of role of developer is just not enough.
    Devops implementation in an ecommerce platform
    We will present our implementation experience of implementation of DevOps methodology , tools and approach towards the continuous deployment in our ecommerce platform implementation. We will talk about aspects related to how we developed the Build Pipeline, focused towards continuous delivery and deployment
    Vijay Bandaru
    Nightmare to Nightly builds...
    This topic is a case study of a company where the production, testing, staging infrastructure and the branching strategy have been improved as part of agile transformation and continuous integration and delivery. This is a true engineering culture shift to a "nightmare" of production deployment to "Nightly build and deployment" culture. This talk also covers some of the best engineering practices that the team used to achieve this goal. These practices include: Test Driven Development, Pair Programming, Whole Team, Collective Code Ownership, Small Releases, Continuous integration, Refactoring, feature toggles, etc. concepts.
    priti biyaniyahya poonawala
    Who Will Test Your Tests?
    Some of us must have been on that one project, where your test suite was causing more problem than solving it. You change one thing, and hundred tests will fail. Your continuous integration build will fail randomly, but will pass if you just re-trigger it. This eventually leads to people losing all the trust on test suite. They stop adding tests, because it’s more painful than writing production code. They start ignoring failing test, because they fail randomly and nobody knows why. Everybody knows tests are now more trouble than help. In this talk, we will talk about some behaviors and reasons which leads to this "flaky test suite" situation. What are some development practices, which can avoid such situation. And finally we will also talk about how to fix this situation if you already in it.
    8th August -
    Learn Play 2 Java in TDD Style
    The objective is give a hands-on experience of building end to end Play 2 - Java application using TDD approach (unit testing, functional testing) from writing routes, controllers, services dependency Injection and deployment to Heroku. The idea is to incrementally add test cases to a sample App (routes controllers, services, dao etc) and explain the concepts of Play framework and also introduce new test tools like mockito, code coverage, FEST assertion matchers etc For e.g. Testing controllers (introduce junit & FakeApplication concepts), difficult to test because of external dependencies in controllers like (dao, web services etc) - introduce Services using Spring DI, Mockito for unit testing, FEST and hamcrest assertions etc), How much code has been tested - introduce cacao for code coverage,and finally deploy to heroku. At the end of the session, the participant should find it easy to understand end to end Play 2 App and its ease of writing tests.
    vijay raghavan
    7th August -
    Common Blind Spots on the Journey to Production and Beyond
    Many teams are getting on the bandwagon of CI and CD - but they tend to miss out on some of the aspects of software development. For eg: 1) What branching strategy (at the SCM-level) to use for maximum speed to deploy business features? 2) What does this choice imply for CI and CD? 3) How are database changes scripted? (Do you use rails-style migrations, dbdeploy, flywaydb, etc?) 4) Do you ensure that the forward and rollback scripts don't error out? If so, how? 5) Do we ensure that the existing data conforms to the validations/rules present in the current version of the codebase that is going to be deployed next? If so, how? This session would give ways to foresee and mitigate issues that arise with a "blind" adherence to Continuous Delivery goals