Find your way through OSCON with these four learning paths.
The open source movement has been with us for almost two decades, and it’s clear that open source is now a de facto choice for software engineers across the globe. The content that you’ll find at OSCON is a reflection of that fact.
The open source world and OSCON itself are vast. With 48 sessions over two days and a bonus day with 11 workshops to choose from, you’ll no doubt have some tough choices to make when you attend the event. Keeping that in mind, I put together four learning paths that encompass the hot topics and important transitions we’re covering at OSCON.
Implementing software quality standards guarantees measurable results.
Listen to the podcast Better code is cheaper to learn how the Software Improvement Group (SIG) is paving the way for software quality and maintainability.
Software quality is an often-overlooked development parameter, making way for those items that resonate outside of the engineering team – a faster schedule and an on-budget project. Joost Visser, Head of Research at Software Improvement Group (SIG) sat down with me to explain how a focus on quality helps to achieve the fastest possible schedules and lowest possible cost of development and maintenance.
What to expect at OSCON 2015.
Twenty years ago, open source was a cause. Ten years ago, it was the underdog. Today, it sits upon the Iron Throne ruling all it surveys. Software engineers now use open source frameworks, languages, and tools in almost all projects.
When I was putting together the program for OSCON with the other program chairs, it occurred to me that by covering “just” open source, we weren’t really leaving out all that much of the software landscape. It seems open source has indeed won, but let’s not gloat; let’s make things even better. Open source has made many great changes to software possible, but the spirit of the founding community goes well beyond code. Read more…
Five things we learned from the O’Reilly Software Architecture Conference 2015.
Within this piece you’ll find my takeaways and lessons learned from the event. I expect these initial impressions to both shape our upcoming exploration of software architecture and be shaped by continued shifts within software architecture.
Migrating to cloud-native application architectures leads to innovation.
Editor’s note: this is an advance excerpt from Chapter 1 of the forthcoming Migrating to Cloud-Native Application Architectures by Matt Stine. This report examines how the cloud enables innovation and the changes an enterprise must consider when adopting cloud-native application architectures.
Let’s examine the common motivations behind moving to cloud-native application architectures.
It’s become clear that speed wins in the marketplace. Businesses that are able to innovate, experiment, and deliver software-based solutions quickly are outcompeting those that follow more traditional delivery models.
In the enterprise, the time it takes to provision new application environments and deploy new versions of software is typically measured in days, weeks, or months. This lack of speed severely limits the risk that can be taken on by any one release, because the cost of making and fixing a mistake is also measured on that same timescale.
Internet companies are often cited for their practice of deploying hundreds of times per day. Why are frequent deployments important? If you can deploy hundreds of times per day, you can recover from mistakes almost instantly. If you can recover from mistakes almost instantly, you can take on more risk. If you can take on more risk, you can try wild experiments—the results might turn into your next competitive advantage.
The elasticity and self-service nature of cloud-based infrastructure naturally lends itself to this way of working. Provisioning a new application environment by making a call to a cloud service API is faster than a form-based manual process by several orders of magnitude. Deploying code to that new environment via another API call adds more speed. Adding self-service and hooks to teams’ continuous integration/build server environments adds even more speed. Eventually we can measure the answer to Lean guru Mary Poppendick’s question, “How long would it take your organization to deploy a change that involves just one single line of code?” in minutes or seconds.
Imagine what your team… what your business… could do if you were able to move that fast!
Find out if mediator or broker topology is right for you.
Editor’s note: this is an advance excerpt from Chapter 2 of the forthcoming Software Architecture Patterns by Mark Richards. This report looks at the patterns that define the basic characteristics and behavior of highly scalable and highly agile applications, and will be made available to download in advance of our Software Architecture Conference happening March 16-19 in Boston.
The event-driven architecture pattern is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. It is also highly adaptable and can be used for both small and large, complex applications. The pattern is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.
The event-driven architecture pattern consists of two main topologies, the mediator and the broker. The mediator topology is commonly used when you need to orchestrate multiple steps within an event through a central mediator, whereas the broker topology is used when you want to chain events together without the use of a central mediator. Because the architecture characteristics and implementation strategies differ between these two topologies, it is important to understand each one to know which is best suited for your particular situation.
Four ways programmers can thrive in their careers.
As O’Reilly continues to build and assess our programming content ecosystem — now more than 30 years in the making — we have gone from covering a few key languages, operating systems, and concepts to a diversification of topics that would have made an editor’s head spin in the 1980s. Our goal, however, remains the same: to continue to provide practical content from experts who help you do your job. An important piece of that goal is to keep you informed as we interpret the trends on the horizon. What follows are a few of the core themes we are focusing on at the moment. Expect these to evolve and change with the speed of innovation.
You can also stay in the loop on the latest analysis and developments through our weekly Programming newsletter.
Actually be a software engineer
The term “full-stack” first emerged in a 2008 blog post (the original post is no longer available, but an archive is published here). The term perhaps reached its canonical definition in a post by Facebook engineer Carlos Bueno. He wrote:
“A ‘full-stack programmer’ is a generalist, someone who can create a non-trivial application by themselves. People who develop broad skills also tend to develop a good mental model of how different layers of a system behave.“
Whether you are striving to be a full-stack programmer, a T-shaped engineer, or you choose to rebuff those terms entirely as mere marketing, what now floats around as a “full-stack developer” definition is incomplete. Read more…
Neal Ford, the author of The Productive Programmer, discusses the benefits of polyglot programming and the impact it’s had on software development.
Help by doing what you love
Vanessa Hurst (@dbness), is a programmer that does good. She started CodeMontage, helps to guide Developers for Good and WriteSpeakCode and co-founded Girl Develop It . We sat down to talk about how coding and coders can truly make a different when it comes to social innovation.
Key highlights include:
- What exactly is Social Innovation? [Discussed at 0:14]
- The impact open source can have on social innovation is huge – [Discussed at 0:43]
- Developers for Good – So you don’t have $10,000 to hand to your favorite charity, what about helping them redesign their website. [Discussed at 1:57]
- How can you actually get involved? Check out Developers for Good, CodeMontage, or Social Coding for Good. [Discussed at 3:03]
You can view the full interview here:
How will our connected world navigate ethics and morality?
Joshua Marinacci (@joshmarinacci), is a researcher at Nokia, author, and speaker. We sat down recently to talk about the quickly growing internet of things and what the future might hold in terms of consequences both foreseen and unexpected.
Key highlights include:
- And the internet of things is not actually so clearly defined [Discussed at 0:20]
- The good, bad, and ugly of the internet of things [Discussed at 1:12]
- Having every single thing connected is a risk [Discussed at 2:14]
- The origin of The Laws of Robotics [Discussed at 3:24]
- Should we be paying closer attention to The Laws as we populate the world with more and more robotics? [Discussed at 4:49]
You can view the full interview here: