This time of the year I get truly inspired by the Des Moines technology community. Blown away actually. Did you know that over the last 3 years more than 255 technology professionals donated over $494,000 of in-kind services to area nonprofits?
Build an API backend for your application using the newest version of .NET that can be developed anywhere and run everywhere. This tutorial walks through the process to build a production-ready service to perform CRUD operations on a “Pokemon.”
Now that Agile has become mainstream, teams are looking to go beyond their Agile process to find ways to improve. There has even been recent use of the term “Antifr-Agile”, where process is secondary to product validation and customer learning (AgileDayChicago, 2016). Here are 7 ways that your team can go beyond your Agile process.
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.