 Yeah, sure it depends right okay, so that lady here. What do you want to tell me? Who's your favorite superhero maybe? Batman Okay, so if I probably keep asking this question to every individual We are likely to hear names of lots of superheroes, right? And we kind of subscribe to the notion that so many superheroes can exist Okay, because their superpowers are special and some of the superheroes as are very successful in a particular area and some aren't in some other areas So the interesting part is though we subscribe to this notion of polyglotism in the world of superheroes Sometimes it becomes very difficult for us to apply the same concept to a very real concept the concept the very concrete thing of selecting a programming language sometimes Becomes very difficult right so with this I introduce This topic to you. We are going to talk about polyglot programming in the entire context of agile development Yeah, imagine like having a spider-man in Kansas City or like in the middle of Arkansas Or in the middle of like a small village near Bangalore. There are no buildings. So he can't really jump So so that's what we are going to talk about like there are some tools that are good in certain contexts And there are some tools that you may want to think of if the context changes. Yep So I am Shashank. I've been working with ThoughtWorks for the last two years and incidentally I've been doing agile only for two years. That's 20% of the work experience. I have and I'm loving it My name is Pramod Sadalgay. I've been working with ThoughtWorks since 99 And I've been doing agile since 99 Yep So let's get started before we start the presentation We're going to base. This is a case study of one of the One of the work we did for one of our clients who's working in consumer electronics, especially creating building Hardware for gamers like headsets mice and stuff like that So I'll just do a small demo of the application and then we'll go into the slides and we'll talk about polyglot programming, right? So The application which I'm talking about is this and the hardware is which is it is going to configure is this headset Okay, now the client basically has a lot of devices. They are headsets as I said there are Mice which you can see arrival. Okay, I haven't got it with me, but what I'm going to showcase is The ecosystem which we have built to to basically run a software on my laptop on any OS which we support to configure a device and This also you can also configure your your setup can actually back up these configurations to a cloud service Yeah, the use case for that was like let's say I have set this machine up I have taken a lot of effort to set my mice at my headboard or headsets set my keyboard up and things like that and I go to my friend's house or I go to a gaming Championship or something like that where they provide their own hardware, right? Or own computer right? So at that point I have to like put out plug in all of my stuff and set it up again Instead of that why can't I just go to that machine and log into my account so that all my settings just appear automatic? So I'll just look quick demo. Okay, I'm not getting too much detail about this application So you can perhaps see this orange light on the headset I'm just giving an idea of the how the UI looks like Okay, both of your hands and we'll basically talk about what was used to build this UI and what are the processes which are running on this laptop, right? So if I click on Siberia elite, there is this window which comes up. Okay, it's a pretty Awesome UI as like when I look at it. I always like it The best part here is the the easiest thing which I can showcase is changing the LED of this this lamp and I think was of resolution Yeah, I think If I click on this it will basically We're promote. I think it's a bad differ both of us Let me change the resolution of it. I think it's Just give me a minute. I'm not sure if it can support it, but I'll just give it a try. All right Start it all over again So on the dog. There's an icon. Okay, so on Mac operating system There'll be a different way to open this engine on windows. There'll be something different and If I click on open steel series engine 3, I Click on Siberia elite. I'm pretty sure it's not going to work again. But what they have, okay? I'm not going to continue on this anymore. So the idea is when I click on this this interface It is very easy for me to configure the device settings and many of these devices actually have RAM and So they are the firm base can be whatever configurations that want to deploy they get deployed on the device itself Okay, so let me not get into too much detail Especially since I could not show what I was trying to show let me jump back to the presentation and let's talk about What we came here to talk about So let's talk about the problem statement. So every every engagement starts with a problem statement. The client says To create multi-platform gaming hardware Configuration software with crowdsourcing and backup abilities with an awesome GUI which looks the same on all platforms Adding a new platform of device should be trivial Now this is a very easy statement to make but all of us know how and we do cross-platform How things become complicated very fast? Of course, don't forget that the software should have minimal CPU and memory footprint because gamers hate bloatware, right? So especially because when you are playing like multiplayer games and stuff like that if your configuration software itself Is taking like 500 MB of RAM and chewing up CPU. They can't play the game, right? So that's why they don't like software that is chewing up RAM or resources on the machine Yeah, and the team is basically a very small team. Okay distributed across three continents and What he says obviously is they should not be busy tackling operational challenges. They should be busy delivering features, right? a very typical scenario but Sounds tricky in the beginning, right? So it's not a special situation now in this scenario when you see the entire problem space well defined The question is how do you architect? So let's look at the world for inspiration, right? Whenever we are we have a problem Especially when we're doing object-oriented stuff. We always say, okay, let's look at the real world Let's see how the real world works and maybe model it back So let's look at how other professions do their polyglotism, right? So you don't find a carpenter who just has a hammer, right? So you find a carpenter who has many more tools than just a hammer, right? So he has nails he has other tools He has saws and things like that the reason is he wants to tackle the art of or he wants to tackle the problem of building Furniture with all the tools that he could use to build a furniture, right? So similarly, why not try the same approach in software, right? Why not just? See and experiment what all other things I can try or what all other tools I can use to make sure that I have the right kind of solution for the customer and it's the interesting bit is Things in world are there for a reason, right? Now these things are very tangible So maybe we are able to appreciate the reason why there are so many tools But in software something they're not very tangible. So the choice becomes a little difficult, right? In fact, if you look at the diagram the carpenter actually uses too many tools to get the job done, right? Okay Jumping back to our Software world Sometime back a lot of financial systems were using cobalt to design their systems If you if we ask this question today, would you actually program in cobalt? Which is actually in its own place a decent language the question many of us would say I don't think so Probably because the language have evolved over the over a period of time They are other high-level languages which probably tackle your domain problems in a much more efficient fashion So one thing is said for sure that languages as many as they are they are not equal right There will be some in some context some languages will be far more powerful than the others and it's not about the subset of features which are there in the language But how much of a match it is to the problem we have at hand? In fact to be to be honest the world is actually quite polyglot in nature and I don't think I have to get in too much detail about this But this is a fact right in fact polyglot programming is something which we have not been doing right now It's it's a pretty old concept and all of us consciously or subconsciously have been doing it at some point in time Or even today right, but we never really identify it and say okay. I am actually doing polyglot programming Examples are there right we have used bash shell scripting for string manipulation, etc We have used org pearl said and the list can obviously keep going on Formally, I think Neil Ford coined this term in 2006. This is the link to the first block post which he had coined he had written and Soon after that the JVM was also maturing at its that's a good pace And we you would have seen that at that point of time and onwards a lot of JVM based languages came into existence Right, so you already had Java Then you started having J Ruby you had it Jython you had closures Kala Ruby and so on and each one of these languages Ex came into being for like some of the languages were pretty older But some of them came into being because they were serving a particular use case in its in the Probably not so efficient in the non-JVM world But probably performance or some other feature got introduced when they started using the entire JVM for running itself, right and If you look at this list You will see some of the very object-oriented stuff on the top and then you will see functional programming coming into the picture, right and You will see now onwards like Intel and they made predictions, right that a chip can only be that much faster So you'll start having multi-core machines and you have to start realizing how to Write your code so that it runs efficiently on a multi-core system. So multi-core programming is now becoming quiet a Very important technique everybody should have in their pocket and hence the rise of functional languages Which focus on immutability of data and stuff like that So, let's talk of our experiences. Yeah, so this project that we started like maybe early 2013 the client came to us and we had this to deliver all the way from integrating with the device at the device level Talking to device drivers and all the way to like the UI that we built Multi-platform UI that we built and the ability for the UI or the client based software desktop based software to talk to a cloud service where they could be Saving all of their configurations so that they can download later or share with other people and things like that had to be built in One stack like the experience had to have all of that from top to bottom So two things come into play right Observation and awareness Observation that the domain is actually complex enough that you have to actually break it down into smaller components Which can be studied further and an awareness that? Not all that some languages will suit a particular context better than others as long as these two things are playing in anybody's mind I think the rest of the things become pretty simple so Let's talk a little bit about Observation right so functionally we have actually evolved quite a bit in Being able to divide the functional space into nice user stories and break the entire functionality down into small consumable units, right so Functional processes have probably more formal Technically we've always been doing this right we've always been dividing and integrating we've always whenever there's a large component We build we have always been dividing into smaller components so that they are testable in its own way And then we have been integrating it in some some form one way or the other So and so let's talk about we've talked about the observation. We've talked about So Eric Coined this term right domain driven design right so the idea was That you have to divide the entire domain into subdomains and you have to figure out what is the bounding? What is the bounded context in which your paradigms paradigms lie, right? So initially you'll see a lot of paradigms appearing whenever you're looking at a problem You basically have to separate those paradigms in such a way that we know that these are the boundaries in which each one of them Like so what I've done here is I've taken this problem statement And I've broken it down into some paradigm which I can see up front and then we'll see what language is how we match these paradigms With the languages right if you look at it here the client is looking for multi-platform That's a paradigm is looking for hardware configuration software. That's a paradigm is looking for minimal CPU usage That's a paradigm is looking for a small team and distributed way to give this Solution that's the thing that you have to look at there's a memory footprint. That's a paradigm So how do you solve all of these with the same language? Right so that you have to when giving a solution or coming up with architecture for this You have to think about how this can be done in a language if it cannot be done in language What language is suit to fix that particular paradigm or solve that particular paradigm? yeah So I've divided this into what best I could do here So at the cloud side you have a lot of operational challenges right you have got maybe a 2-3 member team Which is going to manage a lot of virtualized hardware and the hardware which the company sells has actually sold in a lot of Geographical areas around the world. So you've got Japanese gamers. You've got Southeast gamers in Southeast Asia. You've got Europe. You've got America's they have a lot of time zones We are covering and for it to be performant You have to actually bring the cloud service nearest to whoever is consuming that data Which means actually we've actually so we are using Amazon AWS and we have multi we have multi zone Setups and people who are managing it are not too many. So We have to be efficient in how do we set up the cloud and scale second thing which comes in is This software is used for backing up and backing up should never fail So we have looked at a database which is highly available and partition tolerant and on the API side We have a lot of APIs which we have built for doing the backups Creating a config and stuff like that right and especially since this is distributed and at the same time in the cloud There is a lot of automation that goes into like pop like a share for puppet To automate AWS instances and businesses go down bring them up and that kind of stuff So there is one other paradigm that you have to think about infrastructure management like not just like programming the solution itself But how do you manage infrastructure in the back? Yeah, and on the laptop? There are actually two pieces which are supposed to run the GUI is actually a short-lived process Right. I mean it will be consuming some amount of RAM when it is alive and gamer would not want that to be alive When he's playing a game. So the idea was that the GUI should be running a separate process. It should be short-lived Whatever code you we build we think we should build with a shade code base across platforms and not specifically for natively for each platform Because that becomes a maintenance nightmare And it should look awesome I will talk about looking the same and then you have the core piece which is a Long-running process which will probably run as long as the system is not restarted and it should not The so the language which is used should be should have a good garbage collection. It should not crash Right. It should be easy to write multi-threaded code in it It should build easy and obviously it should interface well with the lower level drivers, right? Which are more often than not written and see and the device library is We build was kind of a little generic in nature in the sense that it has a generic HID USB interface and it should be easy For us to add a new device swap in swap out a new device configuration into the entire setup But sometimes it so happens that as the device has been released in the market and the user is already using you find a bug in this Device hardware device level software. You want to release it We wanted a mechanism where we could just release that software through the cloud like in the cloud We will put new software for the device and the UI would pick that up Give it to the core and the core would then put it on the device so that we would get a fix Automatically and not having to go to a site where you download a patch and then apply it to the device. Yeah All right, so let's talk about awareness, right? So in our search for a right language, we should always underrate the current skills which we have, right? So many of you must have heard a blub programmer, right? Because we don't want to offend a particular Person who likes a particular language. Let's say there is a language called blub, right? So anybody who codes in that language For him all those languages, which don't have that feature set will feel inferior Right, he'll feel that his language is better than most of the languages because they are some feature sets which his language has Now when he or she looks up into the power continuum of the language All the languages available all the languages which look obscure The psychology is that Most probably that language is as popular as the language which I know but there are some hairy syntax thrown inside it So why should I actually even try to learn that tough syntax when I can already do at the entire bit in a language? Which I'm very good at But more often than if you now use some kind of an induction the person who is using a language Which is hairy will look down on that programmer and say that language is actually an inferior language in whatever context We are talking about so it is very important for us to forget the part where we have an expertise in a language and Actually genuinely and honestly figure out how should which language is the perfect for us And then let's see how we can go around in dealing with the operational challenges of having a multiple languages in our entire solution And choosing the right language is actually a competitive edge As many of you would have noted WhatsApp got sold to Facebook for a huge insane amount, right and from what I've read They have a very small number of engineers like around 32 engineers 32 engineers Building software being used for 450 plus million users with one million users getting added Do you think they would have worked if they would have used any arbitrary language or any mainstream language? Obviously not right. They needed a distributed fault tolerant System and they chose Erlang for it and there is a reason why Facebook There is a reason why all the mobile companies use Erlang in the back end systems And in fact Ericsson was the one which gave us Erlang right So whenever you are building a system which is kind of similar in nature to WhatsApp or building a chat client chat software or something You should definitely think about what all languages might already might be suitable for you So here we enter into the case study What I've done is I've tried to put these subdomains back and I'll replace these subdomains with a choice of Technology there, right? So if it's cloud and I've used keynote for the first time So I've been a little fancy with the animation effects Okay, so I burned the subdomain out and what do I have? So I'm using chef I'm using react and we are using Sinatra So as promote pointed out It's very difficult to manage a lot of software if they are if you have to actually log in into the machines and execute those commands How pretty it would be if your infrastructure would be nothing but code right and many of you might have used chef So in chef you should go back and read about it if you haven't You're dealing with infrastructure service so scaling it becomes very easy, right? And if you are combining it with certain reporting technologies, right? Naju or whatever then auto scaling also becomes doesn't become not doesn't remain a very difficult problem to deal with on the database side we've used react and it's actually a Distributed database with a very tunable cap. So in react you can actually say How much consistency I want? What is my availability requirement? What's the partition tolerance? So for example, if I am feeding some logs into the database I don't need it to be very consistent So I can tune a particular bucket to say I don't need consistency here but I need more partition tolerance or availability and On the API side you have used Sinatra, which is a modular rack app There's not too much domain logic there and wherever there is not too much domain logic We've tried to use a language which is faster for us to develop And these choices we don't didn't just come up with like, okay Let's think our yako chef and that kind stuff We actually implemented this in multiple different ways like one of the stack was using these the other stacks We tried Java with Mongo. We tried Java with react. We also tried closure using the express framework With react as a back end. So after trying a bunch of these different stacks That's when we said, okay, this stack looks better for us like from multiple angles like productivity like Ease of scalability and bunch of other different things. So not just that we said, okay in this scenario These are the requirements. Let's choose this without experimenting We actually experimented with multiple different languages even in that one particular domain to come out with the right Technical stack or tech stack that we needed for this. Yeah All right GUI goes out in flame. And what do we have? We have so the critical choice here was using Node Webkit, right? We're writing native apps in HTML5 and Because we're writing it in HTML5 we are using JavaScript We're using CSS 3 and a lot of developers are actually very good in using these technologies, right? So building an awesome UI becomes quite simple, right? If I would have if we would have been developing in some of the native technologies Then there would probably be some time where we would learn how to build an awesome awesome UI in that native platform So Node Webkit for us was like a game-changer, right? You write once and you run it anywhere On Node Webkit. Yes, you would know you can actually choose to run any of the Node.js modules and other libraries we are using knockout for our for handling the domain logic better on the UI end and and For whatever special things we have for an OS level like for example, we have the task bar We are using some we are using cocoa or we're using dotnet or something in the window side so that those small pieces can be written in native native technologies and The most critical piece the core is actually written using Google Go so there's a lot of Opinion it controversy around Google Go whether it's good or whether it's bad the reason we like Google Go is because of The less fluff around The way you write code in Google Go, right? There are a lot of things missing and go You don't have virtually inheritance and the moment you say that a lot of people who do object oriented code say It doesn't make sense, right? How can you have a language which works which doesn't have inheritance in it? But it has a very wonderful way to write code in the whole interface fashion where the way we leverage it is We have a particular interface and the implementation of that interface is different for different OS So the rest of the code is all same, right? It is already in the best practices of go all those parts Which are special to a particular OS and we support Windows and Mac and both windows 32 bit and 64 bit So those implementations now become very small, right? I mean it's just a small part of the entire code base Which is has to be written in a different fashion Simple and ambiguous you focus on the domain. There are a lot of the standard libraries very rich So you can easily, you know, you don't have to think about how to create the net HTTP connection and do all that low-level stuff And the other amazing part is the built-in concurrency primitives So as many of you would have experience this pain, right? Whenever you're writing multi-threaded code, you will always enter into some very subtle bugs Which you cannot reproduce easily and then you have to spend time on figuring out how to synchronize and how to set up The mutexes and stuff like that in go. They are primitive which are already available and it's all about using those primitives in a very simple fashion So and it handles all the rest the rest of the multi-threaded all the complexities behind it and we needed something like that and To interface with other libraries Google has Google go has see go see Go list and stuff like that which helps us to interact with the device library and and Yeah so The Google go choice was an interesting discovery for us and none of us actually knew Google go when we started doing it device library We're using good old C and we're using list here Now the usage of list is actually very limited. Okay, but if you look at list It is code which writes code and data itself is code So it's very easy for us to write the device specification in list and load it in go. So what happens is You can very easily change the way go send signals to your device devices So if you have a new device just write that specification in your list language and it just loads it up and go because go cannot Reload classes right we have to actually kill the go process and bring it back again to reload everything Whatever is there in this case we are just fapping it fapping out the configuration by using this amazing piece of technology and obviously list I mean Is the most powerful language? I don't know if I should actually be talking too much about it But anyway, let's use the topic of another day that was a feature Which we also used to push down like new versions of device drivers or bug fixes and things like that So you could push it down that way and the user didn't have to kill his process It would just be like on the fly update of the device Yep Okay device drivers like there was not much debate here You've already got we know that see is good at doing those low-level things and we didn't want to disturb so the idea is disruption is required, but we don't want to take it too far and The most interesting pieces. This is actually a 10-member team which manages all of it and As promote rightly said all of this looks very intimidating if you look at it once like at once when you look at it But it's all evolved over a period of time like this all evolved over eight or nine months of development Right. It was not like as if the first day we went Okay, we made all these ten different choices and started like everybody started coding in that scenario at the go What we started doing was okay. Let's experiment on this a little bit see how it flows Then let's try the other piece see how it flows and slowly start integrating them and bringing up new languages What this also gave us the 10-member team that was there was rotating and doing all of these at the same time If there was no silo like this one guy or girl does go lang this one guy or girl does JavaScript only this one guy Or girl does react only there was nothing like that people rotated about and were comfortable going through the pace of stuff Yeah, sure with the flames I Find very interesting to burn all this up. We are going to load the presentation up anyway later So you should not have to worry about documenting it. Okay. Thank you All right, the secret sauce. There's always a secret sauce, right? So the secret sauce which we think is Feed the bill pipeline The bill pipeline is most crucial, right? Only when you think from the perspective of how your bill pipeline should be built a lot of things become very clear so This is one of the pipeline which I'm showing it may not be very clear But this is a bill pipeline for building the production So there are similar bill pipelines for for development environment staging Production okay the moment you bring so many components into place suddenly are wondering like how what are the integration problems? Gonna be what if someone changes codes in that particular scenario and breaks like let's say someone changes code in the core And the UI is dependent on it and things like that like how do you integrate all of this? You solve it by using build pipelines like dependencies between these smaller projects If something changes in like say core you compile core if compile Compile and test and all of that stuff in core is successful. Then you say okay now The UI is dependent on course I'm going to trigger a bill on the UI side to make sure the UI test also run You are integration test also run so that it confirms that the core is confirming to whatever it's expecting from So that's known as a bill pipeline if you are if you see just around you should talk to him about build pipelines Okay, so let's talk about how we set up the bill pipeline Simplifying it a little bit You have these main components, right? You have the device library core drivers front end functional tests And I'm drawing a boundary here saying that nothing escapes this area unless until the functional tests have cleared So let's look at it one by one, right? So divide drivers are basically all your C code Which we don't test independently as of now any change in the driver or firmware which comes from the vendor or Even if we change make any changes. It's just Basically, so all these three things any change in drivers core of front end will actually trigger the functional tests I'll come into functional tests in a little while The device library is the part which is the shade library across all devices This is the place we have put in the list magic and stuff So any change which happens in the device live it actually pushes changes into git Okay, we're using it as source control and it changes it pushes with the so it's some kind of an embedded Polyglotism where any code which gets changed device lip gets pushed into core itself and any get any change in core itself Will actually trigger a build for core and what will happen for each for core and both front end is The executable will be created Depending on whatever the platform we decide whether it's windows 32 and do all the environment variable setting and A turbo will be created which contains the executable for both core and similarly for front end only if the unit test pass So we have unit written unit test for both obviously for both core and front end So only if a unit test pass for core a turbo is created and then the functional tests again get triggered on the front end side Since we are using html 5 html is an html app Ultimately, we are using jasmine for our unit testing Okay, and jasmine as you would have used is actually a pretty good tool to test your user interface So only when a jasmine test pass grunt basically does all the hard work It creates the package and if any of these three things are disturbed the functional tests run and We don't and the functional test we have Use cucumber to write the functional test which is a nice DSL way of writing your tests in a way that even business people can actually look at the The functional side of the test the English of it and figure out what's happening Okay, so you these contain the acceptance test so you can actually give it to a qa or give it to a business person to see if all these scenarios are covered or not and The functional tests also generate some things like code metrics like code coverage We don't want to we don't go into details like what complexity and things like that But some basic reports are generated so that you know what's the health of the code line and once functional tests are run and they are successful we basically call it promotion of build and When you promote the build basically all of these tar balls library package gets pushed into one Installer so we have separate pipelines separate agents which do the running of this combination for Windows and Mac operating system right, so you get like a Installer for Windows 32 environments Windows XP environment Windows 7 environment Windows 8 one for Mac And Mac as you know you can't build on other platforms, so you have to build the Mac on a Mac machine So there's a different agent sitting on a Mac build machine where the Mac package is being built Right, so you have to take care of those kinds of environmental things and a build pipeline Okay, we'll definitely have more than one machine. Yep In fact, I could have shown you but the networks doesn't connection doesn't work very well I'll see if I can show some page which I've already opened So once this is done the the artifact is actually uploaded to box.com from where QA is Can actually download the software to the laptops and just do the testing once the testing is done We uploaded to the production website from where generally the general users can actually download the setup Okay, so Other than the making the software language choices. There are some other things which work in our favor As I've already talked about working with an embedded chromium browser really helped us And whenever we had components we have used the service-oriented architecture and when we are publishing the service We have actually kept it simple. So we have used a restful architecture To model the service so that it is predictable for the producer and as well as the consumer And the specifications have been like for example, we have the sse client and you have the cloud right now both systems need not be Developed simultaneously. Okay, you could actually develop cloud separately You can develop your client separately and initially you can just decide both teams can decide saying that what is the specification of The interface we are following and then we could use mocks and stubs to actually independently develop each of these components That also gives you a good way of testing these components in isolation like if I change something on my cloud side I can test the cloud side by just running the interface tests or integration test that the UI is expecting so I don't have to actually run the UI and then test the cloud side I could just run cubes on the cloud side only not have to worry about Running the UI side cubes also and we have used cucumber throughout It's not that we have used Qt's only for cloud testing We have used use Qt's wherever we thought there's a web service to be tested And in our case the core is actually running as a web service So it becomes easy for us to use a simpler language in by in comparison to some language which may be difficult to master like Google go right Keeping a tight control over test quad test code quality helped and I don't want to beat it to death but test driven development Really helps right if you writing honest tests from the beginning it becomes very easy for anybody to know how Well, you are structuring the code And when when people talk about code quality don't take a perception that they are talking about production call quality What we are saying is the test code quality also matters like as you go further you want to refactor your test to be more simpler More smaller more granular they're testing the right things as your architecture is changing as you're adding more code and things like that So that your test when something breaks like there's very the it actually points you to the exact Part of the code that is failing and not just like a random test that breaks and you have to like debug again to figure out where the problem is in the code yep, and Speed and simplicity of building go meant a tighter turnaround. So many languages which are compiled in nature It is very important especially when you're using test driven development You have this red green cycle right if that red green cycle is too long Like you you write some test the test fails You write code and then you make the test pass if the compilation times are huge then It becomes difficult for the developer who's writing the test to actually be honest When you're writing tests so go the the power of which we saw was the compilation times were pretty significantly low And we don't care if the ultimate like people complain that go creates a large After the package is pretty large in size that is not a concern for us And some other non-functional things which work is having a Skype channel for communication Some people use campfire base camp campfire. The idea is always communicate like we are in three continents So we have to keep talking to each other saying what we are doing so that the other team knows what changes we are performing And it's not need not be a very formal way like we're not documenting it in like in some kind of a Like a story card or something. It's just communicating just telling what we are working on and of course Everything is not hunky-dory. It's not that The you should we should be applying this To every project right so I'm going to tell you what are the challenges which we faced Paradigms are hard to master like suppose if I have to learn functional programming It's going to take a while before I really understand how to write good functional programming code Now the expectation is that not everybody in the team will learn the language as fast as everybody, right? There will be one or two people who will master it better the idea is when you're code pairing and you're doing rotation Then automatically this knowledge gets very easily transferred from one person to the other Especially if I'm a developer and I don't know why I made a choice of a language Sometimes working with it becomes frustrating enough for me not to really extend it well or you know If I don't know why the choices were made of I can't see it in front of me Then it's very becomes very difficult to keep the faith And then you are not bought into the decision of why the language has chosen Then then you don't become productive or in sometimes you are and drag the team down because you are not bought into the decision And the debugging can be tricky. This is the like when you are having so many moving parts Like how do you debug go code? How do you debug cloud? what I feel is Debugging can be easy if you have broken down into components and you have actually got good integration good unit tests Covering each one of those components in that case you very easily know which part is actually failing and then debugging it just becomes like debugging any other application and Don't succumb to the Highlander fallacy, which means let's say I'm using Google Go And I think it's great. It doesn't mean that I replace my other web service in go Right, if whatever is not broken, don't break it So if Sinatra is a good choice for me to use the web service at the cloud end I don't want to change it to Google Go and yes, most importantly Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live Okay, remember whenever you start writing code, we actually say this that okay. I don't want to be murdered, okay? And ultimately what matters? Is a happy client a? Client who can give you a feature and which you can give a quick turn around is actually giving him a lot of competitive edge right, so the choice of technology actually becomes very important and To clue back always remember superheroes Okay, but this slide actually shows 600 superheroes and when you look at it You see that all of them are coexisting right? You're not fighting with each other So languages need not be opinion wars right you don't have to fight one language against the other every language can stand in its own might As long as you know we understand how they work So that brings us to the end of The presentation Let me just check how much time we have Okay, if I if you have any questions we could take it up or maybe I could just do a quick demo of Go like front-end side how things work, you know, so I'm let's let's hope the resolution works So what I'm going to showcase right now is on the front-end side We have a node we are using node node.js webkit right and we have written unit s and we are using grunt so the idea is try to script your Toolchain as much as you can right in such a way that every developer knows Just as you execute that command and it does all the packaging and It gives you the final result whether whatever code you have checked in works or not So if I just write grunt here You'll actually see that it's doing a quite it's doing quite a lot of stuff Especially because we are using coffee script So it's doing conversion from coffee script to JavaScript and things like that if I start looking from here it's basically doing a coffee compilation and first scroll down it's running this converting the specs also and Finally you'll see that all the Jasmine specs are being run these small dots are actually each test So we have 742 tests which pass in this much time and you'll also see the code coverage result Okay, now you as you see even after talking so much about Testing we still have achieved Some what okay code coverage, you know, there's still some red marks But if you plug it into Jenkins and say this job will not succeed if the code coverage is not sufficient Then it just depends what how you feel about code coverage like if you think it's just a wasteful metric Then you may not want to use it and in the end you basically create your We are using less with doing conversion to CSS and Ultimately creating that executable in the form of a zip file and just keeping it ready The same job actually gets run on the Jenkins side So as Pramod had pointed out earlier, the things should not be different in your development environment and your Jenkins environment try to keep match as much as possible and Well any questions Yes, sure The team made this decision So in the beginning I said like we just don't didn't like just sit and decide okay. We'll use this We actually did a spike on multiple technologies, right? Like even on the front end we said okay, we can use this we can try that Google go Also, we tried it a little bit see how it works with the device driver See if we can inject list the list requirement came a little bit later And then we tried to program and see how that happens on the cloud side I said like we did try Java with react We did try other stuff to go and over a period of time Okay said we this this stack works better for us in terms of productivity in terms of performance in terms There are other trade-offs right like I was telling someone during during one of the catch-ups outside in the hallway that software Development is all about trade-offs and you have to trade one thing against other constantly. So Like the cloud side we picked up Ruby on rack and then we started going because we thought like Ruby on Sinatra So that we thought we could go faster in terms of development because there's not much domain logic there So things like that we decided based on Actually doing doing a spike and then okay, this works like let's choose it. Yeah, and it sometimes Sorry, I mean decisions were mostly about architecture likes we did Do some refactoring later on but it was mostly about how the code is structured Where does the code need to lie? What kind of test you need to pick up and that kind of stuff because if you are Behaving if you trust your rest of the team members and the rest of the team members show you what they tried Right, there is high amount of trust if someone just comes in your room and says you will use goal And walks out then there is no trust But if you sit in the room code with them show them and that's how trust builds right if you do that Then there is lot less argument. There is lot less two camps fighting with each other people kind of tend to pick up like okay That makes sense for that solution that makes sense I don't know that can you teach me that that happens regularly You need to build trust before you actually make decisions and that's how trust is built Like by doing it with people and not having this hierarchy like oh, I am architect I get to decide like there was nothing like that. Yeah, to be honest if anybody behaves like that then it's it's tough yes but to be frank in our Now the our client was actually Strides in the gaming industry right so he's technically inclined so whenever you're having a discussion actually can actually show him like I Build this thing have a look at it and then make a choice. So there isn't the for us. What was there was an open mind? So it was easy for us to convince Yeah, Dave Yeah, actually if I look into the get account of Steve series then you you'll probably find more than 20 Get have like accounts to like get have repositories, right? But Each one of them does not execute independently Like there are some there are some libraries for keeping the firmware. They are some for keeping the drivers. They are some for go But essentially what happens in the end is there's one component which has a release, right? Like for instance cloud has a release Now in cloud we may be using four or five technologies But ultimately all of them are coming together as one installation or one upgrade right and Especially about software upgradation problems since we have a good Test infrastructure, okay, which also includes performing performance testing, right? So every time anything changes we run it through the entire test suite which gives us a very good signal whether something's breaking or not and Though they are so many have not really realized it like you told me that they are 20 and now and I think I say Yeah, there's so many of them. But when I'm working with them, it's actually four or five main pieces Which I have to basically worry about integration In that particular component and we have had this open philosophy of as a new release comes take it and put it through Spaces because we also build performance testing suites on the side and it runs as part of the pipeline Right. So we have this confidence like if you if I take it and then if it pulls it and something breaks Then I I just change my chef stuff to point to a older version and go right? So that also gives like a venue in automate infrastructure also it gives this is easy ability to roll back versions I didn't have to like let's say react came up with a new version while we were developing We picked it up and we went through spaces if it had failed We were just in chef changed what react version to pick instead of the latest Right. So that helps a lot in terms of like even I have seen like we had a three node cost cluster to begin With and sometimes we used to take down one cluster and just upgrade one cluster and go in a rolling fashion that way So that you could then pick up and see what happens. Yeah, so we were working like we were working on cloud We were working on building core front-end. So the only challenge was the learning curve involved in learning the language So what would happen is typically in a team, they will be one person who will pick it up Well, it could be anybody right and when you're pairing and sitting with the person you're actually engaging in a conversation And in that mode slowly over a period of time it the knowledge level automatically gets upgraded We also had a lot of lunch and learn kind of sessions happening during and exploring like Lisp was so new for so many people like then people used to some some person to take it up and like do a lunch and learn session Constantly and I remember like as long as I was on that project like every Thursday used to be a lunch and learn by default and Yeah, I mean to be honest if you look at it like if Learning a new language is not that hard. I mean we will never know everything about the language But we to know as much to know that we are doing the right thing for many people to be doing the right thing and having a conversation It doesn't take too long Sometimes I feel we are we a little bit too conservative about learning a new language thinking that it has a lot of cost involved But on the longer run, I think it's better to have an open mind Refactoring is actually continuous. We have not measured how much of it But the only thing is once if you have a good test suite you become more confident in refactoring Can you can we take the questions offline because I think we'll run into other speakers time here. All right. Thank you Okay, thank you very much