schedule Mar 18th 02:00 PM - 03:30 PM place Grand Ballroom 1

Over the past decade, eXtreme Programming practices like Test-Driven Development (TDD) & Behaviour Driven Developer (BDD), Refactoring, Continuous Integration and Automation have fundamentally changed software development processes and inherently how engineers work. While TDD has seen a great adoption on server side, developers still find it hard to apply TDD for developing UI components.

In this hands-on, live coding demo, Naresh will build a web commenting and discussion feature (like Disqus) in React.js, 100% test driven. He will also demonstrate how TDD will help us drive an object-functional design to strike a pragmatic balance between the Object-Oriented and Functional Programming paradigms.

3 favorite thumb_down thumb_up 5 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

  • Quick intro to TDD (5 mins)
  • Live demo of the comment's plugin with the following features (75 mins)
    • Should be able to accept comments as json
    • Should display more recent comments on top
    • Private comments should be displayed only to the author of the comment
    • Should take a URL to fetch the comments json from server
    • Others should be able to like your comment
  • Recap of certain design decisions driven by our tests and how they encouraged functional programming (5 mins)
  • Q & A (5 mins)

Learning Outcome

  • How to Test Drive UI code.
  • Communication, Simplicity and Flexibility are the hallmarks of a good design. Irrespective of the programming paradigm, TDD can help you achieve these values in your design.
  • Deeper understanding of OO and FP design principles. 
  • Importance of Virtual DOM for UI development.

Target Audience

Developers, Architects & Testers who are interested in Test Driving their UI code. Also Functional Programming enthusiasts

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Submission
  • Joel Tosi
    By Joel Tosi  ~  3 years ago
    reply Reply

    Hi Naresh,

        This topic sounds interesting.  Will I be watching you code for 75 minutes?



    • Naresh Jain
      By Naresh Jain  ~  3 years ago
      reply Reply

      Hi Joel,

      Short ans. is Yes. Long ans. is it depends.

      This session would be very interactive. At each stage I would ask the participants, what should be the next logical scenario we should cover.

      Also I've the project setup on github such that people can download it and code along (however based on my experience running these kinds of sessions in the past, I know most people would prefer watching me code live.) 

      If people are interested, I can turn this into a Dojo style - come pair with me on stage type thing. However I'll need to be very careful since this might slow us down and I might not be able to cover some key elements of the design evolution.

      What do you think?

      • steve ropa
        By steve ropa  ~  2 years ago
        reply Reply

        Dojo style would be awesome. 

        • Naresh Jain
          By Naresh Jain  ~  2 years ago
          reply Reply

          It would really depend on the participants. We'll need to make these decisions on the fly. But I'm ready with all the options.

          • Joel Tosi
            By Joel Tosi  ~  2 years ago
            reply Reply

            I do like the dojo / randori style better at this duration.

  • Naresh Jain
    Naresh Jain
    schedule 3 years ago
    Sold Out!
    45 Mins

    On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.

    It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.

    In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.

  • Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 Mins

    A successful startup/product company needs to master the art of validating early product ideas quickly and effectively. Whether you are building a product, service or a new feature, the two most important questions to find out early are:

    • are we solving the right problem?
    • if yes, how do we pitch the idea to the target customer to generate a favourable action?

    During this session, we'll focus on various safe-fail experimentation techniques used by Lean Startups for quickly identifying and validating the customer's value hypothesis, without having to build the real product. You will leave this session equipped with various MVP design techniques, that will allow you to rapidly discover a viable product/service that delights your customers, without spending a lot of time and effort.

    Traditionally, entrepreneurs believed that the only way to test their product/service hypothesis was to build the best-in-class product/service in that category, launch it, and then pray. Most often, products/services fail, not because they cannot be built or delivered. But because, they lack the market-fitment and customer appeal.

    To avoid these risks, these days startups are focusing on building a "Minimum Viable Product" (MVP), a product that includes just enough core features to allow useful feedback from early adopters. This reduces the time to market and allows the company to build subsequent customer-driven versions of the product. Hence mitigating the likelihood of wasting time on features that nobody wants. MVPs are typically deployed to a subset of customers, such as early adopters that are more forgiving, more likely to give valuable feedback.

    However the problem with MVPs is that companies still spend too much time building stuff and very little time learning. Don't forget the purpose of MVP is validated learning NOT building. This session will give you ideas on how to quickly formulate and test your value and growth hypothesis in a scientific framework using extremely cheap MVP techniques collectively referred to as MVP Design Hacks.

  • Liked Rajat Talwar

    Rajat Talwar - Pains and Gains of being a Full Stack Developer

    45 Mins
    Experience Report

    As the industry is shifting towards an Agile (Continuous Delivery) style for developing products and services, (whether startups or large established organisation), everyone today has to thrive by innovating and adapting to the latest trends in technology. They have to keep themselves ahead in the race to delight customers. Full stack developers are key players in experimenting and delivering value consistently using varied tools and technologies throughout the stack.

    In this session I'll be share my journey of how I became a full-stack developer. Hopefully this will help others understand how they can target and plan to gradually become a full stack developer in their respective teams.

    Also I'll highlight the following topics:

    • What is the importance of a full stack dev?
    • What tools/resources/languages in my experience work best for full stack developers?
    • Downsides of being a full stack developer!
  • Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 Mins

    What started off as a trial-and-error approach to improve the state of software development by a bunch of tinkerers, is today dominated by management consultants, "Thou-Shall" codified frameworks and rigid, expensive tools. Over the last 20 years, we've gone from, "I'm not sure, let's try this in a small-safe environment" to "you/your-team sucks; you guys have a very poor agile maturity because you are not doing _x_y_z_ (not conforming to the standards)." Along the way, we've lost the purpose of being agile .i.e. to embrace uncertainty and simplicity. Instead we've been forced to believe that consistency via top-down standardisation and predictability by increasing the rigour on process is our eternal quest. Anything that sounds simple and works 80% of the cases is discarded as being naive. What once drove thought-leader into agile, is now driving them insane. This is the unfortunate fate of Agile.

    Luckily there has been some fresh perspectives from Nassim Taleb, author of Antifragile. His work explains how some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. More importantly why antifragility is beyond resilience or robustness.

    In this talk, I'll use some of Nassim's thoughts (and some of my own) to explain what is wrong with our current approach to Agile and how we can bring life back into Agile. Particularly how we can leverage Volatility, Uncertainty, Complexity, and Ambiguity to make product development more antifragile.