- What is Public? (Anil Dash) — the most cogent and articulate (and least hyperventilated dramaware) rundown of just what the problem is, that you’re ever likely to find.
- talon — mailgun’s open sourced library for parsing email signatures.
- Signals from OSCON — some highlights. Watching Andrew Sorensen livecode synth playing (YouTube clip) is pretty wild.
- Two Cultures of Robocars (Brad Templeton) — The conservative view sees this technology as a set of wheels that has a computer. The aggressive school sees this as a computer that has a set of wheels.
Elevate automation through orchestration.
As sysadmins we have been responsible for running applications for decades. We have done everything to meet demanding SLAs including “automating all the things” and even trading sleep cycles to recuse applications from production fires. While we have earned many battle scars and can step back and admire fully automated deployment pipelines, it feels like there has always been something missing. Our infrastructure still feels like an accident waiting to happen and somehow, no matter how much we manage to automate, the expense of infrastructure continues to increase.
The root of this feeling comes from the fact that many of our tools don’t provide the proper insight into what’s really going on and require us to reverse engineer applications in order to effectively monitor them and recover from failures. Today many people bolt on monitoring solutions that attempt to probe applications from the outside and report “health” status to a centralized monitoring system, which seems to be riddled with false alarms or a list of alarms that are not worth looking into because there is no clear path to resolution.
What makes this worse is how we typically handle common failure scenarios such as node failures. Today many of us are forced to statically assign applications to machines and manage resource allocations on a spreadsheet. It’s very common to assign a single application to a VM to avoid dependency conflicts and ensure proper resource allocations. Many of the tools in our tool belt have be optimized for this pattern and the results are less than optimal. Sure this is better than doing it manually, but current methods are resulting in low resource utilization, which means our EC2 bills continue to increase — because the more you automate, the more things people want to do.
How do we reverse course on this situation? Read more…
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.
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…
Andrew Sorensen's cyberphysical music-making demonstrated programming real-time systems in real time.
Music and programming share deep mathematical roots, but have very different senses of “performance”. At OSCON, Andrew Sorensen reunited those two branches to give a live “concert” performance as a keynote. Sorensen brought his decade of “live coding musical concerts in front of an audience” to a real-time demonstration of Extempore, “a systems programming language designed to support the programming of real-time systems in real time”:
“Extempore is designed to support a style of programming dubbed ‘cyberphysical’ programming. Cyberphysical programming supports the notion of a human programmer operating as an active agent in a real-time distributed network of environmentally aware systems.”
Your views on full-stack development could be featured at OSCON. Here’s how.
We’re putting together a series of short videos that explores the trend of full-stack development from the point of view of people who consider themselves to be full-stack developers—as well as those who’d like to be.
This means your insightful perspective on full-stack development could be seen by new developers and industry experts alike.
Want to participate? Here’s what you need to do:
Submissions are due by the end of the day on Monday, July 14. Read more…
Developers who understand the whole stack are going to build better applications.
Since Facebook’s Carlos Bueno wrote the canonical article about the full stack, there has been no shortage of posts trying to define it. For a time, Facebook allegedly only hired “full-stack developers.” That probably wasn’t quite true, even if they thought it was. And some posts really push “full-stack” developer into Unicorn territory: Laurence Gellert writes that it “goes beyond being a senior engineer,” and details everything he thinks a full-stack developer should be familiar with, most of which doesn’t involve coding. Read more…
A common vision is more important than seeking approval
Bruce Eckel is well known for his books in the field of programming, such as Thinking in Java, Thinking in C++, and Atomic Scala as well as his co-leadership of the Java Posse. And yet, on top of his work in programming, he has spent the last several years investing in and researching a topic that seems quite different, yet is intertwined with the destiny of software companies: the culture and operation of businesses.
In his OSCON 2013 Mainstage session, Bruce lays the foundation of modern business management, including a look back as far as Taylorism, a survey of what it means to get an MBA, and ways to gain this knowledge outside of the traditional institutions.
Intriguing reviewers and attendees
The OSCON call for proposals closes on January 30th. I’ve seen some great explanations of how to write a conference proposal generally, and my co-chair Matthew McCullough has an excellent presentation on how to write proposals and presentations:
Tailoring talks to specific conferences sometimes takes a bit more. For OSCON, we’d like talks centered on the Open Source computing ecosystem, but the call just lays out the broad story. What helps a proposal that’s in that neighborhood become a session? If you have an idea, how do you develop it?
Audience: Who are they? What do they want?
My first suggestion to anyone proposing a talk (or a book, or even a blog post) is to focus on audience. Who is going to be interested in what you want to discuss? Will they be at that event? What should they know before they get there? How can you convince them that it’s worth their time to join your conversation? Even for lectures and books, thinking of it as a conversation helps to focus planning.
OSCON Mainstage Talks: Create more value than you capture
At OSCON 2013, Tim (@timoreilly) asked us to aim higher and work on difficult problems while highlighting the most important trends that should be guiding open source developers and entrepreneurs. To illustrate his points, he offered up great examples from companies as diverse as Google, Square, Wikipedia, and O’Reilly Media.