In the software world, there are often new technologies coming to market, new fields to explore, new techniques to use, etc. Filtering through these in itself can be a challenge. Deciding when to move forward with one in practical applications can be even harder. Many times as developers, we will be brought a problem that we can solve in a way we’ve heard about or read. This is when theoretical example attempts to meet practical implementation. We ask ourselves “Does [X] tool I read about recently solve this problem?” or “Would [Y] really work in my organization?”. This is where we can employ the proof of concept.
Source Allies is proud to be involved in many charitable endeavors such as dsmHack, Hyperstream and Tech Journey. Tech Journey is a 501c(3) non-profit founded in 2013 by my friend Tony Kioko and my teammate David Kessler. Tech Journey was created to inspire youth with limited resources in Des Moines to increase their knowledge and interest in technology by providing engaging learning opportunities led by technology professionals.
I’ve been pairing for over a decade. I’ve witnessed and tried all kinds of things shoulder-to-shoulder with all kinds of pairing partners. Through the years I’ve witnessed a single consistent misfire while pairing. We don’t understand our roles. As professional problem solvers we gravitate towards actively solving the problem at hand.
In a previous post, I mentioned that in order to have a successful DevOps experience, there were some key components and principles that need to be implemented. In this post, I’ll cover those components in more detail.
Authored by: Trevor Richardson & Todd Brunia
In a previous article we discussed some of the positive characteristics of microservices that we’ve found while implementing them in a production setting. Two of the primary benefits we discussed are the architectural agility and enforcement of api boundaries. While you may find those and many more benefits from using microservices, you will also find that the positives don’t come for free. In this article, we’ll discuss some of the challenges that we’ve dealt with in implementing a microservice-based architecture. Being aware of these will save you the time and frustration that we experienced early on in our experience with micro services!
What I want to cover in this post is the experience that I had transitioning from a traditional development role to DevOps and what I learned to be useful in that transition. One of the nice things that I experienced with DevOps was that it pushes developers to take more ownership of their application because they are living through the pains and difficulties of running the application which in its turn pushes them to make running the app easier.
Wikipedia defines DevOps as:
DevOps (a clipped compound of “development” and “operations”) is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.
I like to simplify this definition by saying that DevOps is when you’re not only responsible for developing the application but you’re also responsible for running and supporting the application in your testing and production environments. As opposed to the traditional way of developing where you have the luxury of developing the application then throw it over the wall to the Ops team.
A recent topic grabbing the stage in the software community is the use of Microservice Architectures. Microservice architectures are often sold as a great way to enhance a project’s agility over a standard, monolithic architecture. While this can certainly be the case, and there are indeed many benefits from using microservices, the use of a microservice architecture also brings about many unwritten challenges to the way software is designed, developed, and put into production. In this article, we will lay out some of the positive characteristics specific to using microservices that we’ve found while implementing them in a production setting.
Motivated by the introduction of Lambdas in Java 8, I wrote a couple of examples to see how difficult it would be to follow a functional programming paradigm in real production code.
Latest posts by Ghaith Alrabadi (see all)
- Java 8: Parallel vs Sequential Stream Comparison - September 23, 2015
- How to implement the splitter and aggregator patterns with Apache Camel - January 19, 2014
- Iterators, Functors and Predicates - August 24, 2012
I will demonstrate using some features from Java 8 with a simple and fun example.
About a month ago, I facilitated the first event as part of the Source Allies external mentoring program known as Source Allies University (SAU).
It was an interactive forum and networking event designed to:
- Cover basics and explore new tricks of Test Driven Development (TDD) in Java
- Create new code & refactor existing legacy code via TDD
- Code through a sample project for hands-on experience