We always like to share success stories. How a particular project was executed successfully and how the team was appreciated. There is abundance of such case studies. The case study I am presenting is more like sharing a story about a UX project that was well executed for the outside world, but what happened behind the scene to make it a success is very interesting. Its got nothing to do with any sort of technology trends or best practices on the SDLC process. It’s about how a particular situation was handled, how people were handled, how expectations were managed, how internal conflicts were mitigated, the kind of mistakes that happened, how delivery and excellence teams impact the overall project, how subjectivity plays a role in the entire engagement. How does one adapt to a totally unknown and unchartered situation? I will also be sharing an analogy called as “The “Perpetual design”. It explains in a very visual & easy way “How every stake holder (project teams, business, and technology teams) can be convinced about the practicalities of a project.

Apache Kafka is a next generation pub-sub model where the notion of distributed computing is built in. It proposes a unique way of handling message queues and is ideal for handling large volume of messages/logs as seen in internet age. Kafka has also interesting use cases in IoT where it can help ingest large amount of machine data which consumers can process.

In this session, Lalit will give you a good understanding of Kafka, its typical use-cases and things to watch-out for.

When we think of OO, most people think of modeling THE real world in software by mapping every real world object (nouns) to entities in software. These entities are then modeled using Is-A-Has-A relationship to build complex, polymorphic hierarchies with deep object graphs. State is stored and mutated in-place inside the object to achieve the desired functionality. This paradigm leads to a fairly convoluted design and encourage imperative style of programming.

Not everyone who has designed large complex systems, think of OO the same way. For instance, people who Test Drive, do not have the luxury of a big-up-front design, instead they focus on small and incremental design. IME, TDD facilities a design that is side-effect free and encourages a declarative style of programming. While decoupling and composing objects in a functional style with the right granularity of abstraction.

Let's assume we've to build a web commenting and discussion feature (like Disqus). And we've a requirement to implement this as a React component. Can we apply pure functional principles to design this? Or will the design be better if we try a classical OO JS approach? In this live demo, we'll build this component from scratch and see how TDD will help us drive an object-functional design to strike a pragmatic balance between the 2 paradigms.