Today’s enterprise applications are complex, distributed and mission critical. In this session we want to share how the concepts, tools and patterns introduced by Domain Driven Design helped us in enterprise application architecture and design. DDD is invaluable in strategic architectural decision making. DDD was instrumental for us to layout our microservices architecture. We learned to speak DDD and adopted that as our medium of communication to build our team. DDD made our communication with outside teams and integration within the enterprise easier. It made us conscious about implications of enterprise integration at strategic and implementation level.

This presentation will include concepts of strategic and tactical DDD. It is also organized in such a way to encourage discussion rather than follow a strict lecturing mode.

With such a strong set of available talks, it was difficult to choose just one - so we've decided to pick two topics that Michael is most passionate about: The Micronauts Framework, along with The Influential Engineer. 

Micronaut is a modern, JVM-based, full-stack framework for building modular, easily testable microservice applications. In this session he'll give a solid overview of Micronaut - it's strengths, capabilities and best practices when building & testing services, functions and reactive apps. Even if you don't use Micronaut itself, you'll get a clear understanding about what's possible with a well engineered micro-service framework.

Being The Influential Engineer is a dream of seasoned professionals, thumb-sucking nubies, and many in between. After pure technical competency, the most important set of skills we have are social. During this part of the meeting, Michael will share with us clear and simple techniques that we can use to effect culture change in our organizations, lead the transition toward a new technology, or simply ask for - and recieve - better tools. How awesome is that!?

More information about these and his many other presentations is available at he No Fluff, Just Stuff web site, at his about the speaker page.

Every July, the NEJUG Production Team (formerly known as the NEJUG Advisory Group) gathers to discuss various business items. The meeting is open to all members, as usual, there will be food and drinks. Meeting format, however, will be different. There will be no external/guest speakers, rather, there will be roundtable discussions by NEJUG production team members.

So you have some code and it is in a bounded context with a REST API. You are on your way to Microservices. Next you wrap it in a container and now it is an image that others can run. Simple. Now what? No service is an island. Your service needs to log information, needs to scale and load balance between its clones. Your service needs environment and metadata way outside its context. What about where the service will run? Who starts it? What monitors its health? What about antifragility? Updates? Networking? Oh my.

Services live in clusters and clusters live in data centers. There are hybrid solutions that span data centers. Many concepts overlap with the features of cloud management. But don't get too flustered since, fundamentally, services are managed by clusters. There are several approaches to cluster management such as Docker Swarm, Mesos with Marathon and Kubernetes.

Minikube with Kubernetes is an approachable technique to set up a local cluster that is easy to understand and get started. Whether you have a simple service or a Web application with a set of services, you can develop much of it on Kubernetes with Minikube. We will run some practical examples. Once you understand the mechanics of the tools, we will explore how it works, sort through the terminology and share ideas about practical uses for this technology.

Afterward you will understand how to run your personal cluster with your Linux, OS X or Windows laptop to further enjoy unravelling the mysteries of running applications in a cluster.

As Java developers, we have long understood the value of early feedback, unit testing, and Continuous Delivery (CD). As practitioners in a DevOps environment, we tell others how important these practices are. How well do we implement these practices for software intended for DevOps applications? Do we “eat our own dogfood”? In this presentation, I will review an approach taken to apply Continuous Delivery practices with a Java application that creates Jenkins Pipelines.   After hearing the presentation, I hope you will walk away with some ideas on how to implement your Java CD practices in a broader context. 

Kotlin and Category Theory: Pragmatic Functional Programming 
by Craig Lubin

What is Functional Programming (FP) and why should you care? This presentation will provide a simple (but not simplistic) introduction of the science behind both Functional Programming and Category Theory by using simple mathematical concepts and the Kotlin programming language. I will show how to apply these techniques for error handling, IO, and more AND how these techniques can also work in Java (it's not just a "Kotlin thing").
No prior knowledge of Kotlin or advanced mathematics is required. 

When should you refactor code and when should you not do it?  How do you make sure you have adequate test case coverage?  What are the strategies, techniques, and patterns for refactoring existing code?  And how do you get your boss to agree to let you spend the time to refactor code?  This presentation will cover these questions and more.  Topics covered include Acceptance/Approval Testing, Design Patterns, Code Smells, Refactorings, and Tools.

For a deeper dive into related topics of Mob Programming, TDD, and software craftsmanship, join Ethan at the Mob Programming Conference April 12-13 in Burlington, MA.  Several of the presentations are on refactoring.

In most of the Monolithic applications business objects and data, model designs are already present. As part of moving to cloud, companies miss out of the use-cases the REST APIs need to support. Implementing cloud solutions on top of existing models may lead to performance issues with APIs and cause scalability issues. Clients need to rewrite code due to a new version of APIs.

In this talk, we will explore ten steps methodology for designing superior Cloud Native RESTFul Microservices APIs. Firstly, define the business domain objects and how they relate to use cases. If the use-case is to support <500 ms response time and availability of 99.99%, design the application for Consistency, Availability, and Partition tolerant. Next, Create an ideal design which solves the use-cases, refer to the industry standard JSONs and designs from schema.org, iana.org, and ​microformats.org. Later, find the fail points in the process and go back to the first step to resolving the pain points: Go back to Define the problem. Question to ask is what can go wrong? When can it go wrong? Next, create Facade pattern to connect to either existing Monolithic App or create a new App to support the new cloud use-cases. Create API Gateway, so other companies can build software and create more offerings. Next, design common Layers for error handling, logs, and security. For API security, perform Threat Modeling to find security vulnerabilities and plan for mitigation of risks. Use generic authentication using SAML, OAuth, and JWT to support Authentication and Authorization. Next, create API Versioning strategy so that the REST API can evolve with minimal client changes. Apply Cloud Native design patterns for Resiliency. In the end, test APIs using contract driven testing and PACT files.

We all have seen our share of bad code and some really good code as well. What are some of the common anti patterns that seem to be recurring over and over in code that sucks? By learning about these code smells and avoiding them, we can greatly help make our code better. Come to this talk to learn about some common code smell and how to improve the quality of code.  

This presentation is sponsored by the No Fluff, Just Stuff / Software Symposium. The next NFJS event in the Boston area is scheduled for March 16 - 18, 2018 in Wakefield. Venkat is on the roster for that event - which is a great way to get more of him and choose from many other top-tier speakers. Plan ahead and allocate that weekend for a great training, growth, and networking event!

the NEJUG Holiday Party is scheduled on our normal "second Thursday" in December, but it is not a normal presentation meeting. Instead, it's an "all fun time" event where we get to chat, eat, drink, and socialize. Think of it as an extended meeting break, without the before-and-after presentation parts. (And with food choices other than pizza!)

IMPORTANT: Unlike our regular meetings, the holiday party is NOT free. You must purchase tickets in advance, using our EventBrite event page. We are offering an Early-Bird price discount (until November 15), so grab your tix now and save a few bucks!

Location is Princeton Station Restaurant in Chelmsford, MA

Ticket prices will be $30 through November 15*, $34/after*. Donations to help defray the cost of course are welcome.
*EventBrite price will include a processing fee of about $2.90

Princeton Station
147 Princeton Street
North Chelmsford, MA 01864

There will be a selection of delicious appetizers. Soft drinks and coffee will be served, and drinks of all kinds will be available at the cash bar.
Come enjoy the great food, fine venue, great company, and raffle prizes! We always want to make it a better event with more to offer.
We'll have a buffet with a variety of food to choose from, including vegetarian options. Ham, turkey, potatoes, Mediterranean platter, fruit tray, spanikopita, more!

What if a debugger could allow you to simply step BACKWARDS? Instead of all that hassle with guessing where to put breakpoints and the fear of typing "continue" one too many times... What if you could simply go backwards to see what went wrong?

This is the essence of the "Omniscient Debugger" -- it remembers everything that happened during the run of a program, and allows the programmer to "step backwards in time" to see what happened at any point of the program. All variable values, all objects, all method calls, all exceptions are recorded and the programmer can now look at anything that happened at any time.

In this talk, I will describe the design of the "ODB" -- an implementation of Omniscient Debugging for Java programs -- and discuss the various costs and tradeoffs. The last half of the talk will be a demonstration of the ODB, showing how the various pieces of data are displayed and how the programmer can "navigate" through time to see what the program was doing, where values were set, when various threads ran, etc.

At the conclusion of the talk, the audience will be invited to use the ODB to find some actual bugs.

If you have a bug (current or former) in a Java program that you'd like to explore, bring it along! Please make sure it's pure Java, in a relatively small program that you have the source code to, and that it manifests itself within 10 seconds of a known action (e.g., start up or a button push).