Posted by & filed under Devops, Information Technology, infrastructure, IT, Operations.

Last week at Devops Days in Boston, I had the opportunity to attend back to back presentations that complemented each other and helped bring into focus an idea that has been hanging around just beyond the horizon of my awareness. Namely, when it comes to infrastructure software, we are working through a time of major transitions that affect both our tools and the structure and processes of our work.

Expecting conflict and adapting

The first presentation that started turning my vague sense of what’s been happening into a revelation was Nikolas Katsimpras presenting on conflict within organizations. He described various types of conflict between: individuals and individuals, individuals and groups, different departments, and so on. Although the talk was nontechnical, it was easy to apply many of the concepts Katsimpras described to infrastructure software and devops, where our work tends to be driven by other departments, whose needs define our priorities. This arrangement causes many organizations to get stuck maintaining the status quo with inefficient compensation patterns rather than changing with time and technology.

Katsimpras emphasized the importance of responsive adaptivity and described Nelson Mandela as brilliantly adaptive in that he was willing and able to adjust himself as circumstances changed. During another portion of the presentation, Katsimpras defined “double-loop learning,” which is a term used to describe the process of questioning initial assumptions when seeking to change outcomes, rather than focusing on refining strategies and goals. This concept strikes me as particularly salient given the rise of automated configuration management and test-driven infrastructure.

Today’s tools are not tomorrow’s

After the constructive conflict presentation, Kelsey Hightower went on to discuss CoreOS. I found myself completely rapt and pondering the near future, in which CoreOS is the solution to all my high-traffic, high-availability web app problems. But then it happened—I felt conflicted as to whether CoreOS would solve problems I’m already solving with Chef. I felt a pang of worry. On the one hand, we are still developing our Chef-based infrastructure: expanding test coverage, updating and standardizing dev tools, among other things. But on the other hand, the purpose of our business is to serve customers, not to commit to a particular system configuration management tool for all time. So maybe I ought not get defensive about keeping today’s infrastructure tools around for tomorrow. Here it was, double-loop learning in my own everyday life!

Three years ago, the tools needed for automatic dependency resolution and local testing in Chef were only starting to manifest in discussions and as ideas. Today, many of these tools—which were often initiated by third-party developers in the user community—are part of what is considered the Chef standard toolkit. By incorporating behavior- and test-driven development practices into infrastructure software, companies are improving the customer experience by separating the customer from the config and deployment errors.

These initiatives in the developer communities have led to an advent of tools that have dramatically improved efficiency and productivity in ways that would have sounded like magic a decade ago. But the outcomes are consistent with the double-loop learning principle of returning to initial assumptions before changing practices. For instance, just five years ago, most reasonable people would have agreed that it was difficult-to-impossible to test infrastructure changes on a local workstation. Now this type of testing is increasingly the norm, thanks once again to developers questioning the original assumptions.

Similarly, today we use all kinds of virtualization infrastructure in order to accommodate and scale complex web software, so our current patterns are generally predicated on using VMs as individual hosts: this reliance on VMs is just one example of a concept that is no longer relevant in CoreOS. During his talk, Hightower mentioned his personal interest in Golang, which made me contemplate how many of today’s tools that are written in C, C++, and even Java will be implemented in Go over the next decade.

While searching to make sure I wasn’t stepping on someone else’s title, an option I tried was “The Future is Adaptive.”  When I saw Ian Clatworthy’s essay from seven years ago, I knew I had found mine. In his essay, Clatworthy, a Bazaar dev, discussed the importance of adaptability in context of version control and described the tensions that arise from diverging priorities. Today we are even further down that road, and we’re going faster. Clatworthy’s ideas are still applicable and interesting today, even though the specific technologies change. It’s easy to forget that we will pass through many moments of now on our way to what lies ahead. Between now and the future we will implement the changes that distinguish the two from each other. While these changes will create situations that are ripe for conflict, we must learn to leverage contention as a constructive force. We must do this because the nature of software engineering and soft product development has been and will continue shifting under our feet.

Posted by & filed under programming, publishing, xslt.

Twice in the past couple of weeks I’ve needed to solve this problem:

We have content provided as individual displayable pages, but we need a document for those pages to refer to, with a table of contents so that a user can navigate between them. In one case it was a set of articles in a journal issue, in another it was entries in an encyclopedia. I solved both of these problems with the same general XSLT structure, so I thought I’d write it up for others to use. Read more »

Posted by & filed under news.

Safari was founded in 2001, as a joint venture between O’Reilly Media and Pearson, two publishers that care deeply about learning, innovation, knowledge, and personal growth.

Today I’m thrilled to announce that O’Reilly Media, Inc., has acquired the Pearson stake in Safari, and Safari is now a wholly-owned subsidiary of O’Reilly Media, Inc. Safari will continue to operate as an independent company, and Pearson Education will remain a strategic content partner of Safari.

Safari - O'Reilly Read more »

Posted by & filed under Information Technology, infrastructure, IT, tools.

If you’ve used Chef, you’ve probably used a community cookbook. Community cookbooks are helpful because someone else has figured out how to solve your problem, be it installing nginx or configuring postgresql. While community cookbooks are great, they sometimes don’t include everything that you need. That’s where wrapper cookbooks come in. If you want to change or extend the functionality of a cookbook without having to rewrite it from scratch, a Chef wrapper cookbook is the way to go. Read more »

Posted by & filed under Content - Highlights and Reviews.

You’ve probably noticed we’ve made some changes around here, including a brand new design and sharp new logo.

New Safari Logo

Safari began more than 13 years ago as “Safari Tech Books Online,” with the promise of replacing the collection of IT and programming reference books on your shelf with something online and searchable. (As the saying goes, “You can’t grep dead trees.”) Read more »

Posted by & filed under java, programming, testing.

A few months ago I noticed the JUnit Attachments Plugin and was inspired.  Recording pictures and other files after test failures is such an obviously good idea, especially if you’re the one who has to fix the tests.

Unfortunately, the JUnit Attachments Plugin has some rough edges. I wrote a small library that handles the busywork while keeping tests readable.  Since we are awesome, we open sourced it so you can use it too!

Read more »

Posted by & filed under Tutorials.

Safari is seeking help in usability testing for Safari Tutorials, our curated learning paths based on Safari books and videos. You will be speaking with folks from our product development team, and your input will directly influence how the product evolves in the next few months. That’s pretty cool, don’t you think?

fisheye image of UI books

Photo by loureiro, used under CC-By A / Cropped from original

The Details

Tests will be performed remotely via a Google Hangout video chat, running for 30 to 45 minutes. Session times are available on June 18 and June 19.

If you are interested in participating, we ask that you take a few minutes to complete this short questionnaire.

Those selected for usability testing will receive a $25 gift card (iTunes or Amazon) upon completion of the session.

Thank you for considering participating in our study. Feedback from our community is essential as we build products that help our users learn and grow. Plus we just like speaking with you.

Posted by & filed under accessibility, authoring, book design, css, design, Digital Publishing, ebooks, epub, html5, talks.

I originally presented this talk on ebook markup to an audience of ebook developers and publishers. As someone who cares deeply about accessibility and discovery, it’s a subject that tends to get me agitated, but I tried to be extra-polite because my audience was Canadian.

My hope is that as web-based book resources like Safari continue to proliferate, publishers will take advantage of the opportunities afforded by many years of research by the web community into what makes content semantically rich, accessible, and competitive with the wealth of free material available on the open web.

The craft of ebooks

Read more »

Posted by & filed under analytics, content, Product Updates & Tips, search.

We’ve made quite a few changes lately to the search engine and interface on Safari Flow. These changes were motivated in no small part by the evolution of the application itself. When Flow launched last summer, it included a highly curated collection of approximately 250 books and videos, primarily aimed at web developers. We’ve more recently decided to expand the scope of that content, and the original 250 has increased 100-fold — almost exactly, in fact: today, we’re rapidly approaching 25,000 titles on a myriad of topics from dozens of publishers.

The evolution of searching in Flow

Searching across 250 titles is not the same as searching across 25,000. We’ve addressed this shift with a number of refinements, some small and some large. Among the smaller changes we’ve made are adding autocomplete, giving users the option to search across specific indexes (author, title, published, and ISBN), and some retuning of how search results are weighted (one example: book titles are now weighted slightly more heavily than chapter titles).

More drastically, we refactored the interface of the results page. When we had fewer titles, the results page was quite simple and emphasized individual chapters over complete titles.

Search results for 'just enough research' showing two book covers and and links to three chapters in each book.

Search results in the new interface are much richer. Because users have so many more results from which to choose, we aimed to provide tools and information to make choosing easier. For example, results are shown in context, and the user has more filtering options. A user can filter out specific types of media, and sort on relevance or publication date. She can drill down further by clicking on a specific author or publisher. And perhaps the best part: search results are returned twice as quickly.

Search results for 'just enough research' showing bold text of the results in context

Reviewing the results

Our hypothesis was that providing users with a richer search experience would make the site easier to use and generally more engaging. Roughly 81% of logged in visits include a search of some kind (40% of which originate on the home page), so it’s important to us that we get it right. So how are we doing?

The new search interface has been on the site for a couple of weeks now, and we’re encouraged by the some of the early analytics. For example, the number of times users search again after the initial search has decreased by 7%. So they are finding what they want more often. Great!

We’ve also seen an uptick in engagement. For example, the amount of time a user stays on the site after searching has increased on average by over a minute. The average number of pages a user views after searching has gone up by a full page. We see these data points as signs that we are doing something right.

Not all of the analytics are unambiguously good or bad. One of the more perplexing data points is related to a new autocomplete feature. Specifically, autocomplete has not consolidated the search terms. Before we added autocomplete, we saw 17,824 unique search terms and 26,814 unique searches, which is 66% unique. Since we added autocomplete (using a smaller sampling size), we’ve seen 10,689 unique search terms and 13,262 unique searches, which is 81% unique. We’re not quite sure to make of that!

This is of course not the end of the story. We know we still have a lot of work to do so that Flow’s search serves users accurately and quickly. Our users regularly write in to suggest changes, and we’re listening. And as you can see in this post, we’re making sure to measure the results of the choices that we make. In addition to the usage on Flow, we have the further benefit of over a decade’s worth of search-related data from our Safari Books Online platform.

Posted by & filed under talks.

Fletcher Nichol – Kitchen CI

kitchenci

We use Test Kitchen to test our continuous integration software at Safari Books Online. We run it on LXCs on both vagrant and testing nodes in our continuous integration pipeline. I was curious to see what was new with Kitchen CI and what Fletcher had to say. We use the framework in a standard way, though I learned the

kitchen diag

command, which is short for ‘kitchen diagnose’, and helps diagnose errors within Test Kitchen. I also learned how easy it is to test operating systems outside our current production systems with Kitchen CI. This would be useful to test cookbooks that we planned on releasing to the community. We could get a sense of what other OSes were already supported and what work would need to be done in order to support them if not.

Jamie Windsor – Berkshelf

We use Berkshelf to manage our cookbook dependencies. We love it and it works well. Jamie talked about the vision for Berkshelf 3.0 and how the product has been improved. I downloaded and installed the new Chef DK to play with which included both Berkshelf 3 and Kitchen CI. His talk details how artifacts are more strictly regulated in Berkshelf 3. Jamie also spoke about an online game platform he build using Elixir. He will be speaking more about it at the Atmosphere Conference in Poland.

Rachel Chalmers

Rachel said something that has stuck with me and I have repeated many time since. To paraphrase,

Automation Software is the Codification of Institutional Knowledge

I love that idea. Chef recipes are self-documenting processes for other engineers to learn from. What was once stored inside one person’s head is now codified with recipes. I love the concept!

John Esser

My big take-away from this talk:

Automating everything allows your business to pivot.

Big and small companies need to pivot; markets change and businesses change. If your infrastructure creation is automated, you can pivot from one direction to another more easily and in a safer, testable way.

Justin Arbuckle

mobydickbykish

Justin gave a great talk on automation software in our contemporary corporate culture. He used the story of Moby Dick to illustrate different struggles we face. This was a delightful talk with fantastic artwork by Matt Kish.

The Take-Away

nathenharveynotblowup

It is easy for departments to live in silos. The current trend is to find ways to diminish the time wasted handing off tasks from one department to another. We’ve taken some of the recommendations to heart at Safari Books Online already. Historically, we’ve supported two Jenkins servers: one for IT and one for Engineering (Development). We have two source control repositories. We did this with good intentions: to stay out of each other’s way. For new projects that involve both departments, we try to consolidate source control and testing to the Engineering infrastructure. We now have software developers writing deployment cookbooks, which is exactly the direction we want to go. We have a long way to go, but this is a start.

nathenharveyblowup