Peter is the Principal Architect at EnerNOC Labs, a dedicated R&D laboratory within EnerNOC, a global provider of green energy solutions in Boston, MA.
Before joining EnerNOC, Peter was a Principal Cloud Engineer with Kronos Incorporated, a global provider of on-premise and cloud-based workforce management solutions and prior to that, he held the position of Technical Director with Brokat Technologies, a global provider of mobile payment solutions. Prior to that, Peter was a Sr. Architect with GemStone Systems, providing distributed, enterprise-ready data grid and object persistence solutions and J2EE application server technologies.
Peter has a Honors degree in pure mathematics from McMaster University in Hamilton, Ontario, Canada. He is a technology addict and evangelist and has led many grass-roots efforts to introduce leading edge, advanced technologies and development processes.
A lifetime learner, Peter thrives on digesting new technologies and sharing his discoveries with others. He has authored and delivered numerous technical seminars on a variety of topics including Ruby on Rails, Grails, Git, Angular, Meteor, Flex, GWT and AOP.
To find out more about Peter, check out his LinkedIn profile: https://www.linkedin.com/in/peterpavlovich
There is no doubt that Angular is now mainstream. That made it easier for you to convince the powers-that-be to let you select Angular for your project. You’ve done a small but successful POC and now your ‘big’ project has been green lighted to kick off next month. Your team is jazzed but as you start to plan out the real work, you begin to realize that there are many aspects inherrent to large Angular projects that have no ‘out of the box’ answers.
Stack overflow can only contribute ‘it depends’ answers that leave you more confused than before you read them. And now the panic starts to seep in, killing your buzz. Never fear! In this session, we will explore a variety of ways to architect your project and structure your code. We will look at the pros and cons of each option and discuss when trigger points for choosing each.
Meteor is an open-source, all-JavaScript platform for building reactive, top-quality web apps in a fraction of the time. Whether you’re an expert developer or just getting started, Meteor is the rising star of the JavaScript frameworks you need to see to believe!
From concept to reality, in this session we will code and live deploy a fully featured, Meteor application. Along the way, explore and explain the cool technologies underlying Meteor that empowers such fantastic productivity. You will experience, firsthand, how Meteor makes developing web applications fun and exciting!
Learn about the new hierarchical Injectors, router and component lifecycle API in Angular 2.0 and how they work together to bring new capabilities and flexibility to your Angular toolbox.
Angular 2.0 is coming and with it a new router and dependency injection mechanism. Join me as we take a look at these shiny new capabilities and explore their current state and how they work together to bring new power and flexibility to your angular applications!
Aurelia is the newest front-end client-side JS framework. Created by Rob Eisenberg, a former key member of the Angular 2.0 team who, disheartened by the direction Angular 2.0 was taking, left Google to devote his time to driving Aurelia over the finish line. Don’t get left behind! Why not invest 90 minutes to discover why Aurelia is such a compelling alternative to Angular 2.0 and why you need should pay attention to this newest contender for the crown
Aurelia is what Angular 2.0 should have been. At least that seems to be the opinion of its originator, Rob Eisenberg, who left the Angular 2.0 team in order to bring Aurelia to us. Why would we want to consider yet another front-end, JS-based framework? Isn’t Angular ‘good enough’?
You really owe it to yourself (and your career as a front-end developer) to spend the 90 minutes to discover the answers to these questions yourself!
Join us to see a head-to-head comparison of Angular 2.0 and Aurelia and decide for yourself which you would rather use. I think you may be surprised by your own answer!
Users are in revolt! They are on strike! “Freedom!” is their repeated demand. They plague your twitter feeds with complaints. They picket your headquarters building. The signs read “No More Refresh Buttons!” If you have not attended this presentation yet, that is your certain future! Join us for this enlightening discussion of Reactive Application Architectures for modern enterprise applications and secure the good name of your enterprise today!
Users are demanding applications which keep them informed of new events as soon as they happen. They are no longer willing to accept “Just hit the refresh button” or “It will update in a few minutes by itself” when demanding satisfaction of this new basic requirement. They are collaborating in real time, co-editing, co-authoring, ‘co-laborating’ with colleagues across the country and around the world, chatting over the phone or VOIP while working together via your app. They want their updates to travel from their laptop to their co-workers screens as fast as their voice reaches them through the phone. This is a tough requirement to meet, especially when trying to put a modern face on a legacy app or integrating a shiny, new, reactive app with a legacy, REST-based datasource.
And it is not just your end-users that are clamoring for reactive data sources. No, the requirements for server-to-server communication of changes to data or state have forever changed. REST no longer is King in the world of web services. REST just doesn’t cut the mustard any longer. Users of your data services are also demanding more flexible, reactive options when consuming your endpoints.
Join us for this thought provoking journey of discovery as we explore the real strategies that you can apply today as you architect your new or existing stack to satisfy the ever-increasing demand for ‘real-time’ applications and data services, fed by reactive data sources, regardless of your current technology choices.