- Handheld Scanners Attack — shipping and logistics operations compromised by handheld scanners running malware-infested Windows XP.
- Adventures in Cognitive Biases (MIT) — web adventure to build your cognitive defences against biases.
- Quoc Le’s Lectures on Deep Learning — Machine Learning Summer School videos (4k!) of the deep learning lectures by Google Brain team member Quoc Le.
- FLOSS Community Metrics Talks — upcoming event at Puppet Labs in Portland. I hope they publish slides and video!
How inclusivity, complexity, and empathy are shaping DevOps.
Over the next five years, three ideas will be central to DevOps: the need for the DevOps community to become more Inclusive; the realization that increasing Complexity of systems is the underlying reason for DevOps; and the critical role of Empathy in the growth and adoption of DevOps. Channeling John Willis, I’ll coin my own DevOps acronym, ICE, which is shorthand for Inclusivity, Complexity, Empathy.
There is a major expansion of the DevOps community underway, and it’s taking DevOps far beyond its roots in agile systems administration at “unicorn” companies (e.g., Etsy or Netflix). For instance, a significant majority (80-90%) of participants at the Ghent conference were first-time attendees, and this was also the case for many of the devopsdays in 2014 (NYC, Chicago, Minneapolis, Pittsburgh, and others). Moreover, although areas outside development and operations were still underrepresented, there was a more even split between developers and operations folks than at previous events. It’s also not an accident that the DevOps Enterprise conference took place the week prior to the fifth anniversary devopsdays and included talks about the DevOps journeys at large “traditional” organizations like Blackboard, Disney, GE, Macy’s, Nordstrom, Raytheon, Target, UK.gov, US DHS, and many others.
The DevOps community has always been open and inclusive, and that’s one of the reasons why in the five years since the word “DevOps” was coined, no single, widely accepted definition or practice has emerged. The lack of definition is more of a blessing than a curse, as DevOps continues to be an open conversation about ways of making our organizations better. Within the DevOps community, old-time practitioners and “newbies” have much to learn from each other.
Your data is telling you what you need to know about turnover and age
To really grasp a free/open source software project, you need to know how the community that develops and supports it is evolving. Attracting lots of new members will be a reason for celebrating success in a young project — but you should also check whether they stick around for a long time. In mature projects, however, you can afford not attracting many new members, as long as you are retaining old ones. The ratio of experienced, long-term members to recent ones also tells you about the quality of the code and need to support members.
Internet of Things, local energy sources, and online collaboration underlie the Zero Marginal Cost Society.
Use teaching stacks to drive growth.
Elliott Hauser is CEO of Trinket, a startup focused on creating open sourced teaching materials. He is also a Python instructor at UNC Chapel Hill.
Well-developed tools for teaching are crucial to the spread of open source software and programming languages. Stacks like those used by the Young Coders Tutorial and Mozilla Software Carpentry are having national and international impact by enabling more people to teach more often.
The spread of tech depends on teaching
Software won’t replace teachers. But teachers need great software for teaching. The success and growth of technical communities are largely dependent on the availability of teaching stacks appropriate to teaching their technologies. Resources like try git or interactivepython.org not only help students on their own but also equip instructors to teach these topics without also having to discover the best tools for doing so. In that way, they play the same function as open source Web stacks: getting us up and running quickly with time-tested and community-backed tools. Thank goodness I don’t need to write a database just to write a website; I can use open source software instead. As an instructor teaching others to code websites, what’s the equivalent tool set? That’s what I mean by Teaching Stack: a collection of open tools that help individual instructors teach technology at scale.
Elements of a great teaching stack
Here are some of the major components of a teaching stack for a hands-on technology course:
Not just for code anymore
Do you really want a technical book for your project? Does your community need to provide more helpful docs to support even more users? Does your community have a lot of knowledge they need to get out of heads and into bits and bytes? Do you have a good mix of technical experts and technical writers and users who would enjoy each other’s company for a week of hard work?
If the answer is yes, then consider a book sprint. If you’re in the open source world, you may have heard of a code sprint. A book sprint is a similar event, with an intense collaborative authoring session time boxed by a few days or a week. People get together typically in person to author and complete a book in a week.
Generally speaking it’s best if you have an idea of the scope and audience for the book prior to holding the sprint. These discussions can take place on line, such as on a mailing list or in a wiki page or Etherpad. You can also meet with future collaborators regularly, but understand, the first day of your sprint your book will certainly take shape. As book sprinter Adam Hyde says, “While you may not know the exact book you want when you go into the sprint, by the end you will have the book you need.”
For the OpenStack Operations Guide, we held a five-day book sprint in February 2013. OpenStack releases every April and October, and this timing was nearly halfway between two release dates. With Adam as our facilitator, seven authors agreed to work together and we nervously awaited our fate. We asked, “Could we complete a book in a week?”
Reinvigorate a Perl project today
I contribute heavily in the Perl community, and I’m consistently impressed by the pains we take with code and assets that we personally have no interest in. There’s a group of Perl people who shepherd (camelherd?) code and projects that have lost their maintainers. I’m one of those people.
There’s a very simple system CPAN uses and which has been working since around 1994. Basically, CPAN is a big directory structure that other mirrors rsync (see Jarkko Hietaniemi’s The Zen of Comprehensive Archive Networks). People contribute code through the Perl Authors Upload Server (PAUSE), which does some light verification for identity and permission for the namespaces in that code. No one really “owns” a namespace in Perl, but developers have permissions to control it, including extending that permission to other developers. This is a small bit of a social control. (As an aside, Perl 6’s design handles this differently by allowing people to specify an “authority” for modules)
A conference report on the IP transition.
Although readers of this blog know quite well the role that the Internet can play in our lives, we may forget that its most promising contributions — telemedicine, the smart electrical grid, distance education, etc. — depend on a rock-solid and speedy telecommunications network, and therefore that relatively few people can actually take advantage of the shining future the Internet offers.
Worries over sputtering advances in bandwidth in the US, as well as an actual drop in reliability, spurred the FCC to create the Technology Transitions Policy Task Force, and to drive discussion of what they like to call the “IP transition”.
Last week, I attended a conference on the IP transition in Boston, one of a series being held around the country. While we tussled with the problems of reliability and competition, one urgent question loomed over the conference: who will actually make advances happen?
A Frank Talk about Women in Programming with the Founder of CodeChix
Rupa Dachere (@rdachere), Founder and President of CodeChix, and I had a chance to talk programming and open source community culture at OSCON 2013. She brings up some great points about the specific problems that arise for women, talks about why she brought CodeChix to life, and what we can all do to make the programming community more diverse.
Key highlights include:
- Women face unique challenges: Time, Resources, and Support [Discussed at 0:18]
- And, there is support, for instance, CodeChix has refresher courses and tech talks [Discussed at 0:50]
- The CodeChix origin story [Discussed at 2:36]
- Cultivating positivity [Discussed at 4:02]
- Eighteen month outlook – some companies are talking but others need to join the conversation [Discussed at 4:57]
You can view the full interview here:
The past, present, and future of Dell's project
Barton George (@barton808) is the Director of Development Programs at Dell, and the lead on Project Sputnik—Dell’s Ubuntu-based developer laptop (and its accompanying software). He sat down with me at OSCON to talk about what’s happened in the past year since OSCON 2012, and why he thinks Sputnik has a real chance at attracting developers.
Key highlights include:
- The developers that make up Sputnik’s ideal audience [Discussed at 1:00]
- The top three reasons you should try Sputnik [Discussed at 2:46]
- What Barton hopes to be talking about in 2014 [Discussed at 4:36]
- The key to building a community is documentation [Discussed at 5:20]
You can view the full interview here: