From Epam Systems
Seasoned Java developer, Team Leader and Solution Architect. In human language I’m: writing and reviewing code, saving world with vim via ssh around Saturday midnight, deciding about technology used in the project and ﬁlling a communication gap between client and developers. After over 7 year-long adventure with Java, still passionate about the platform, even after having romance with Excel and Outlook. Pragmatist at heart and propagator of Agile approach to building software. Tricity JUG leader, conference speaker and blogger (recently on holidays)
There is that day in life of every developer when he goes to boss and asks for permission to rewrite / refactor our application. It can be that inherited thing, maybe something we wrote on our own, however it's often the moment when we feel it can't go any further. We're frustrated and angry. I've been there, did it couple of times, and I won't hide, failed couple of times. There are still systems out there, that counted on me, that I'll get some love for them from business and I've failed them!
Right now it's a perfect time to share some of that experience, especially all the successful techniques I've been able to identified, to rescues all the systems out there among with sanity of developers that work on them. I'll share everything I've learned on how to convince business to refactor, what are the possible strategies and finally, most likely most importantly, what to do and how to live with that legacy crap if we fail. The world does not end and we don't have to change our job if we fail.
Each developer that had to deal with any reasonably sized system was wondering what is the ultimate approach to building highly modular, well performing, scalable and easy to change systems. They should also be easy to write, maintain, earn a lot of money and go for a beer when we are tired.
Latest approach, silver bullet of nowadays modularity is to build in small applications, so called microservices. In this talk we're not going to judge is it right or wrong approach, instead let's see what benefits we get from them and what are the other options available today in Java world. There will be a comparison to older ways of keeping application modular, like OSGi and quick rant about building monolith applications with internal modularization.
Whole thing is going to be from Java developer perspective, however non Java speaking folks, should also be able to benefit, especially if you know only Node and want to go beyond. On the same note, it's not another Nashorn vs Node talk! It's all about Nashorn, and each example we'll check out is focused only on it and unique platform features.