Chapter 1. Data-Driven Cultures

What does it mean to be a truly data-driven culture? What tools and skills are needed to adopt such a mindset? DJ Patil and Hilary Mason cover this topic in O’Reilly’s report “Data Driven,” and the collection of posts in this chapter address the benefits and challenges that data-driven cultures experience—from generating invaluable insights to grappling with overloaded enterprise data warehouses. 

First, Rachel Wolfson offers a solution to address the challenges of data overload, rising costs, and the skills gap. Evangelos Simoudis then discusses how data storage and management providers are becoming key contributors for insight as a service. Q Ethan McCallum traces the trajectory of his career from software developer to team leader, and shares the knowledge he gained along the way. Alice Zheng explores the impostor syndrome, and the byproducts of frequent self-doubt and a perfectionist mentality. Finally, Jerry Overton examines the importance of agility in data science and provides a real-world example of how a short delivery cycle fosters creativity.

How an Enterprise Begins Its Data Journey

by Rachel Wolfson

You can read this post on oreilly.com here.

As the amount of data continues to double in size every two years, organizations are struggling more than ever before to manage, ingest, store, process, transform, and analyze massive data sets. It has become clear that getting started on the road to using data successfully can be a difficult task, especially with a growing number of new data sources, demands for fresher data, and the need for increased processing capacity. In order to advance operational efficiencies and drive business growth, however, organizations must address and overcome these challenges.

In recent years, many organizations have heavily invested in the development of enterprise data warehouses (EDW) to serve as the central data system for reporting, extract/transform/load (ETL) processes, and ways to take in data (data ingestion) from diverse databases and other sources both inside and outside the enterprise. Yet, as the volume, velocity, and variety of data continues to increase, already expensive and cumbersome EDWs are becoming overloaded with data. Furthermore, traditional ETL tools are unable to handle all the data being generated, creating bottlenecks in the EDW that result in major processing burdens.

As a result of this overload, organizations are now turning to open source tools like Hadoop as cost-effective solutions to offloading data warehouse processing functions from the EDW. While Hadoop can help organizations lower costs and increase efficiency by being used as a complement to data warehouse activities, most businesses still lack the skill sets required to deploy Hadoop.

Where to Begin?

Organizations challenged with overburdened EDWs need solutions that can offload the heavy lifting of ETL processing from the data warehouse to an alternative environment that is capable of managing today’s data sets. The first question is always How can this be done in a simple, cost-effective manner that doesn’t require specialized skill sets?

Let’s start with Hadoop. As previously mentioned, many organizations deploy Hadoop to offload their data warehouse processing functions. After all, Hadoop is a cost-effective, highly scalable platform that can store volumes of structured, semi-structured, and unstructured data sets. Hadoop can also help accelerate the ETL process, while significantly reducing costs in comparison to running ETL jobs in a traditional data warehouse. However, while the benefits of Hadoop are appealing, the complexity of this platform continues to hinder adoption at many organizations. It has been our goal to find a better solution.

Using Tools to Offload ETL Workloads

One option to solve this problem comes from a combined effort between Dell, Intel, Cloudera, and Syncsort. Together they have developed a preconfigured offloading solution that enables businesses to capitalize on the technical and cost-effective features offered by Hadoop. It is an ETL offload solution that delivers a use case–driven Hadoop Reference Architecture that can augment the traditional EDW, ultimately enabling customers to offload ETL workloads to Hadoop, increasing performance, and optimizing EDW utilization by freeing up cycles for analysis in the EDW.

The new solution combines the Hadoop distribution from Cloudera with a framework and tool set for ETL offload from Syncsort. These technologies are powered by Dell networking components and Dell PowerEdge R series servers with Intel Xeon processors.

The technology behind the ETL offload solution simplifies data processing by providing an architecture to help users optimize an existing data warehouse. So, how does the technology behind all of this actually work?

The ETL offload solution provides the Hadoop environment through Cloudera Enterprise software. The Cloudera Distribution of Hadoop (CDH) delivers the core elements of Hadoop, such as scalable storage and distributed computing, and together with the software from Syncsort, allows users to reduce Hadoop deployment to weeks, develop Hadoop ETL jobs in a matter of hours, and become fully productive in days. Additionally, CDH ensures security, high availability, and integration with the large set of ecosystem tools.

Syncsort DMX-h software is a key component in this reference architecture solution. Designed from the ground up to run efficiently in Hadoop, Syncsort DMX-h removes barriers for mainstream Hadoop adoption by delivering an end-to-end approach for shifting heavy ETL workloads into Hadoop, and provides the connectivity required to build an enterprise data hub. For even tighter integration and accessibility, DMX-h has monitoring capabilities integrated directly into Cloudera Manager.

With Syncsort DMX-h, organizations no longer have to be equipped with MapReduce skills and write mountains of code to take advantage of Hadoop. This is made possible through intelligent execution that allows users to graphically design data transformations and focus on business rules rather than underlying platforms or execution frameworks. Furthermore, users no longer have to make application changes to deploy the same data flows on or off of Hadoop, on premise, or in the cloud. This future-proofing concept provides a consistent user experience during the process of collecting, blending, transforming, and distributing data.

Additionally, Syncsort has developed SILQ, a tool that facilitates understanding, documenting, and converting massive amounts of SQL code to Hadoop. SILQ takes an SQL script as an input and provides a detailed flow chart of the entire data stream, mitigating the need for specialized skills and greatly accelerating the process, thereby removing another roadblock to offloading the data warehouse into Hadoop.

Dell PowerEdge R730 servers are then used for infrastructure nodes, and Dell PowerEdge R730xd servers are used for data nodes.

The Path Forward

Offloading massive data sets from an EDW can seem like a major barrier to organizations looking for more effective ways to manage their ever-increasing data sets. Fortunately, businesses can now capitalize on ETL offload opportunities with the correct software and hardware required to shift expensive workloads and associated data from overloaded enterprise data warehouses to Hadoop.

By selecting the right tools, organizations can make better use of existing EDW investments by reducing the costs and resource requirements for ETL.

This post is part of a collaboration between O’Reilly, Dell, and Intel. See our statement of editorial independence. 

Improving Corporate Planning Through Insight Generation

by Evangelos Simoudis

You can read this post on oreilly.com here.

Contrary to what many believe, insights are difficult to identify and effectively apply. As the difficulty of insight generation becomes apparent, we are starting to see companies that offer insight generation as a service.

Data storage, management, and analytics are maturing into commoditized services, and the companies that provide these services are well positioned to provide insight on the basis not just of data, but data access and other metadata patterns.

Companies like DataHero and Host Analytics are paving the way in the insight-as-a-service (IaaS) space.1 Host Analytics’ initial product offering was a cloud-based Enterprise Performance Management (EPM) suite, but far more important is what it is now enabling for the enterprise: It has moved from being an EPM company to being an insight generation company. This post reviews a few of the trends that have enabled IaaS and discusses the general case of using a software-as-a-service (SaaS) EPM solution to corral data and deliver IaaS as the next level of product.

Insight generation is the identification of novel, interesting, plausible, and understandable relations among elements of a data set that (a) lead to the formation of an action plan, and (b) result in an improvement as measured by a set of key performance indicators (KPIs). The evaluation of the set of identified relations to establish an insight, and the creation of an action plan associated with a particular insight or insights, needs to be done within a particular context and necessitates the use of domain knowledge.

IaaS refers to action-oriented, analytics-driven, cloud-based solutions that generate insights and associated action plans. IaaS is a distinct layer of the cloud stack (I’ve previously discussed IaaS in “Defining Insight” and “Insight Generation”). In the case of Host Analytics, its EPM solution integrates a customer’s financial planning data with actuals from its Enterprise Resource Planning (ERP) applications (e.g., SAP or NetSuite, and relevant syndicated and open source data), creating an IaaS offering that complements their existing solution. EPM, in other words, is not just a matter of streamlining data provisions within the enterprise; it’s an opportunity to provide a true insight-generation solution.

EPM has evolved as a category much like the rest of the data industry: from in-house solutions for enterprises to off-the-shelf but hard-to-maintain software to SaaS and cloud-based storage and access. Throughout this evolution, improving the financial planning, forecasting, closing, and reporting processes continues to be a priority for corporations. EPM started, as many applications do, in Excel but gave way to automated solutions starting about 20 years ago with the rise of vendors like Hyperion Solutions. Hyperion’s Essbase was the first to use OLAP technology to perform both traditional financial analysis as well as line-of-business analysis. Like many other strategic enterprise applications, EPM started moving to the cloud a few years ago. As such, a corporation’s financial data is now available to easily combine with other data sources, open source and proprietary, and deliver insight-generating solutions.

The rise of big data—and the access and management of such data by SaaS applications, in particular—is enabling the business user to access internal and external data, including public data. As a result, it has become possible to access the data that companies really care about, everything from the internal financial numbers and sales pipelines to external benchmarking data as well as data about best practices. Analyzing this data to derive insights is critical for corporations for two reasons. First, great companies require agility, and want to use all the data that’s available to them. Second, company leadership and corporate boards are now requiring more detailed analysis.

Legacy EPM applications historically have been centralized in the finance department. This led to several different operational “data hubs” existing within each corporation. Because such EPM solutions didn’t effectively reach all departments, critical corporate information was “siloed,” with critical information like CRM data housed separately from the corporate financial plan. This has left the departments to analyze, report, and deliver their data to corporate using manually integrated Excel spreadsheets that are incredibly inefficient to manage and usually require significant time to understand the data’s source and how they were calculated rather than what to do to drive better performance.

In most corporations, this data remains disconnected. Understanding the ramifications of this barrier to achieving true enterprise performance management, IaaS applications are now stretching EPM to incorporate operational functions like marketing, sales, and services into the planning process. IaaS applications are beginning to integrate data sets from those departments to produce a more comprehensive corporate financial plan, improving the planning process and helping companies better realize the benefits of IaaS. In this way, the CFO, VP of sales, CMO, and VP of services can clearly see the actions that will improve performance in their departments, and by extension, elevate the performance of the entire corporation.

On Leadership

by Q Ethan McCallum

You can read this post on oreilly.com here​.

Over a recent dinner with Toss Bhudvanbhen, our conversation meandered into discussion of how much our jobs had changed since we entered the workforce. We started during the dot-com era. Technology was a relatively young field then (frankly, it still is), so there wasn’t a well-trodden career path. We just went with the flow.

Over time, our titles changed from “software developer,” to “senior developer,” to “application architect,” and so on, until one day we realized that we were writing less code but sending more emails; attending fewer code reviews but more meetings; and were less worried about how to implement a solution, but more concerned with defining the problem and why it needed to be solved. We had somehow taken on leadership roles.

We’ve stuck with it. Toss now works as a principal consultant at Pariveda Solutions and my consulting work focuses on strategic matters around data and technology.

The thing is, we were never formally trained as management. We just learned along the way. What helped was that we’d worked with some amazing leaders, people who set great examples for us and recognized our ability to understand the bigger picture.

Perhaps you’re in a similar position: Yesterday you were called “senior developer” or “data scientist” and now you’ve assumed a technical leadership role. You’re still sussing out what this battlefield promotion really means—or, at least, you would do that if you had the time. We hope the high points of our conversation will help you on your way.

Bridging Two Worlds

You likely gravitated to a leadership role because you can live in two worlds: You have the technical skills to write working code and the domain knowledge to understand how the technology fits the big picture. Your job now involves keeping a foot in each camp so you can translate the needs of the business to your technical team, and vice versa. Your value-add is knowing when a given technology solution will really solve a business problem, so you can accelerate decisions and smooth the relationship between the business and technical teams.

Someone Else Will Handle the Details

You’re spending more time in meetings and defining strategy, so you’ll have to delegate technical work to your team. Delegation is not about giving orders; it’s about clearly communicating your goals so that someone else can do the work when you’re not around. Which is great, because you won’t often be around. (If you read between the lines here, delegation is also about you caring more about the high-level result than minutiae of implementation details.) How you communicate your goals depends on the experience of the person in question: You can offer high-level guidance to senior team members, but you’ll likely provide more guidance to the junior staff.

Here to Serve

If your team is busy running analyses or writing code, what fills your day? Your job is to do whatever it takes to make your team successful. That division of labor means you’re responsible for the pieces that your direct reports can’t or don’t want to do, or perhaps don’t even know about: sales calls, meetings with clients, defining scope with the product team, and so on. In a larger company, that may also mean leveraging your internal network or using your seniority to overcome or circumvent roadblocks. Your team reports to you, but you work for them.

Thinking on Your Feet

Most of your job will involve making decisions: what to do, whether to do it, when to do it. You will often have to make those decisions based on imperfect information. As an added treat, you’ll have to decide in a timely fashion: People can’t move until you’ve figured out where to go. While you should definitely seek input from your team—they’re doing the hands-on work, so they are closer to the action than you are—the ultimate decision is yours. As is the responsibility for a mistake. Don’t let that scare you, though. Bad decisions are learning experiences. A bad decision beats indecision any day of the week.

Showing the Way

The best part of leading a team is helping people understand and meet their career goals. You can see when someone is hungry for something new and provide them opportunities to learn and grow. On a technical team, that may mean giving people greater exposure to the business side of the house. Ask them to join you in meetings with other company leaders, or take them on sales calls. When your team succeeds, make sure that you credit them—by name!—so that others may recognize their contribution. You can then start to delegate more of your work to team members who are hungry for more responsibility.

The bonus? This helps you to develop your succession plan. You see, leadership is also temporary. Sooner or later, you’ll have to move on, and you will serve your team and your employer well by planning for your exit early on.

Be the Leader You Would Follow

We’ll close this out with the most important lesson of all: Leadership isn’t a title that you’re given, but a role that you assume and that others recognize. You have to earn your team’s respect by making your best possible decisions and taking responsibility when things go awry. Don’t worry about being lost in the chaos of this new role. Look to great leaders with whom you’ve worked in the past, and their lessons will guide you.

Embracing Failure and Learning from the Impostor Syndrome

by Alice Zheng

You can read this post on oreilly.com here.

Lately, there has been a slew of media coverage about the impostor syndrome. Many columnists, bloggers, and public speakers have spoken or written about their own struggles with the impostor syndrome. And original psychological research on the impostor syndrome has found that out of every five successful people, two consider themselves a fraud.

I’m certainly no stranger to the sinking feeling of being out of place. During college and graduate school, it often seemed like everyone else around me was sailing through to the finish line, while I alone lumbered with the weight of programming projects and mathematical proofs. This led to an ongoing self-debate about my choice of a major and profession. One day, I noticed myself reading the same sentence over and over again in a textbook; my eyes were looking at the text, but my mind was saying Why aren’t you getting this yet? It’s so simple. Everybody else gets it. What’s wrong with you?

When I look back on those years, I have two thoughts: first, That was hard, and second, What a waste of perfectly good brain cells! I could have done so many cool things if I had not spent all that time doubting myself.

But one can’t simply snap out of the impostor syndrome. It has a variety of causes, and it’s sticky. I was brought up with the idea of holding myself to a high standard, to measure my own progress against others’ achievements. Falling short of expectations is supposed to be a great motivator for action…or is it?

In practice, measuring one’s own worth against someone else’s achievements can hinder progress more than it helps. It is a flawed method. I have a mathematical analogy for this: When we compare our position against others, we are comparing the static value of functions. But what determines the global optimum of a function are its derivatives. The first derivative measures the speed of change, the second derivative measures how much the speed picks up over time, and so on. How much we can achieve tomorrow is not just determined by where we are today, but how fast we are learning, changing, and adapting. The rate of change is much more important than a static snapshot of the current position. And yet, we fall into the trap of letting the static snapshots define us.

Computer science is a discipline where the rate of change is particularly important. For one thing, it’s a fast-moving and relatively young field. New things are always being invented. Everyone in the field is continually learning new skills in order to keep up. What’s important today may become obsolete tomorrow. Those who stop learning, stop being relevant.

Even more fundamentally, software programming is about tinkering, and tinkering involves failures. This is why the hacker mentality is so prevalent. We learn by doing, and failing, and re-doing. We learn about good designs by iterating over initial bad designs. We work on pet projects where we have no idea what we are doing, but that teach us new skills. Eventually, we take on bigger, real projects.

Perhaps this is the crux of my position: I’ve noticed a cautiousness and an aversion to failure in myself and many others. I find myself wanting to wrap my mind around a project and perfectly understand its ins and outs before I feel comfortable diving in. I want to get it right the first time. Few things make me feel more powerless and incompetent than a screen full of cryptic build errors and stack traces, and part of me wants to avoid it as much as I can.

The thing is, everything about computers is imperfect, from software to hardware, from design to implementation. Everything up and down the stack breaks. The ecosystem is complicated. Components interact with each other in weird ways. When something breaks, fixing it sometimes requires knowing how different components interact with each other; other times it requires superior Googling skills. The only way to learn the system is to break it and fix it. It is impossible to wrap your mind around the stack in one day: application, compiler, network, operating system, client, server, hardware, and so on. And one certainly can’t grok it by standing on the outside as an observer.

Further, many computer science programs try to teach their students computing concepts on the first go: recursion, references, data structures, semaphores, locks, and so on. These are beautiful, important concepts. But they are also very abstract and inaccessible by themselves. They also don’t instruct students on how to succeed in real software engineering projects. In the courses I took, programming projects constituted a large part, but they were included as a way of illustrating abstract concepts. You still needed to parse through the concepts to pass the course. In my view, the ordering should be reversed, especially for beginners. Hands-on practice with programming projects should be the primary mode of teaching; concepts and theory should play a secondary, supporting role. It should be made clear to students that mastering all the concepts is not a prerequisite for writing a kick-ass program.

In some ways, all of us in this field are impostors. No one knows everything. The only way to progress is to dive in and start doing. Let us not measure ourselves against others, or focus on how much we don’t yet know. Let us measure ourselves by how much we’ve learned since last week, and how far we’ve come. Let us learn through playing and failing. The impostor syndrome can be a great teacher. It teaches us to love our failures and keep going.

O’Reilly’s 2015 Edition of Women in Data reveals inspiring success stories from four women working in data across the European Union, and features interviews with 19 women who are central to data businesses.

The Key to Agile Data Science: Experimentation

by Jerry Overton

You can read this post on oreilly.com here​​.

I lead a research team of data scientists responsible for discovering insights that generate market and competitive intelligence for our company, Computer Sciences Corporation (CSC). We are a busy group. We get questions from all different areas of the company and it’s important to be agile.

The nature of data science is experimental. You don’t know the answer to the question asked of you—or even if an answer exists. You don’t know how long it will take to produce a result or how much data you need. The easiest approach is to just come up with an idea and work on it until you have something. But for those of us with deadlines and expectations, that approach doesn’t fly. Companies that issue you regular paychecks usually want insight into your progress.

This is where being agile matters. An agile data scientist works in small iterations, pivots based on results, and learns along the way. Being agile doesn’t guarantee that an idea will succeed, but it does decrease the amount of time it takes to spot a dead end. Agile data science lets you deliver results on a regular basis and it keeps stakeholders engaged.

The key to agile data science is delivering data products in defined time boxes—say, two- to three-week sprints. Short delivery cycles force us to be creative and break our research into small chunks that can be tested using minimum viable experiments. We deliver something tangible after almost every sprint for our stakeholders to review and give us feedback. Our stakeholders get better visibility into our work, and we learn early on if we are on track.

This approach might sound obvious, but it isn’t always natural for the team. We have to get used to working on just enough to meet stakeholders’ needs and resist the urge to make solutions perfect before moving on. After we make something work in one sprint, we make it better in the next only if we can find a really good reason to do so.

An Example Using the Stack Overflow Data Explorer

Being an agile data scientist sounds good, but it’s not always obvious how to put the theory into everyday practice. In business, we are used to thinking about things in terms of tasks, but the agile data scientist has to be able to convert a task-oriented approach into an experiment-oriented approach. Here’s a recent example from my personal experience.

Our CTO is responsible for making sure the company has the next-generation skills we need to stay competitive—that takes data. We have to know what skills are hot and how difficult they are to attract and retain. Our team was given the task of categorizing key skills by how important they are, and by how rare they are (see Figure 1-1).

Figure 1-1. Skill categorization (image courtesy of Jerry Overton)

We already developed the ability to categorize key skills as important or not. By mining years of CIO survey results, social media sites, job boards, and internal HR records, we could produce a list of the skills most needed to support any of CSC’s IT priorities. For example, the following is a list of programming language skills with the highest utility across all areas of the company:

Programming language Importance (0–1 scale)
Java 1
SQL 0.4
Python 0.3
C# 0.2
C++ 0.1
Perl 0.1

Note that this is a composite score for all the different technology domains we considered. The importance of Python, for example, varies a lot depending on whether or not you are hiring for a data scientist or a mainframe specialist.

For our top skills, we had the “importance” dimension, but we still needed the “abundance” dimension. We considered purchasing IT survey data that could tell us how many IT professionals had a particular skill, but we couldn’t find a source with enough breadth and detail. We considered conducting a survey of our own, but that would be expensive and time consuming. Instead, we decided to take a step back and perform an agile experiment.

Our goal was to find the relative number of technical professionals with a certain skill. Perhaps we could estimate that number based on activity within a technical community. It seemed reasonable to assume that the more people who have a skill, the more you will see helpful posts in communities like Stack Overflow. For example, if there are twice as many Java programmers as Python programmers, you should see about twice as many helpful Java programmer posts as Python programmer posts. Which led us to a hypothesis: 

You can predict the relative number of technical professionals with a certain IT skill based on the relative number of helpful contributors in a technical community. 

 

We looked for the fastest, cheapest way to test the hypothesis. We took a handful of important programming skills and counted the number of unique contributors with posts rated above a certain threshold. We ran this query in the Stack Overflow Data Explorer:

 

1  SELECT
2  Count(DISTINCT Users.Id),
3  Tags.TagName as Tag_Name
4  FROM
5  Users, Posts, PostTags, Tags
6  WHERE
7  Posts.OwnerUserId = Users.Id AND
8  PostTags.PostId = Posts.Id AND
9  Tags.Id = PostTags.TagId AND
10 Posts.Score > 15 AND
11 Posts.CreationDate BETWEEN '1/1/2012' AND '1/1/2015' AND
12 Tags.TagName IN ('python', 'r', 'java', 'perl', 'sql', 'c#', 'c++')
13 GROUP BY
14 Tags.TagName

Which gave us these results:

Programming language Unique contributors Scaled value (0–1)
Java 2,276 1.00
C# 1,868 0.82
C++ 1,529 0.67
Python 1,380 0.61
SQL 314 0.14
Perl 70 0.03

We converted the scores according to a linear scale with the top score mapped to 1 and the lowest score being 0. Considering a skill to be “plentiful” is a relative thing. We decided to use the skill with the highest population score as the standard. At first glance, these results seemed to match our intuition, but we needed a simple, objective way of cross-validating the results. We considered looking for a targeted IT professional survey, but decided to perform a simple LinkedIn people search instead. We went into LinkedIn, typed a programming language into the search box, and recorded the number of people with that skill:

Programming language LinkedIn population (M) Scaled value (0–1)
Java 5.2 1.00
C# 4.6 0.88
C++ 3 0.58
Python 1.7 0.33
SQL 1 0.19
Perl 0.5 0.10

Some of the experiment’s results matched the cross-validation, but some were way off. The Java and C++ population scores predicted by the experiment matched pretty closely with the validation. But the experiment predicted that SQL would be one of the rarest skills, while the LinkedIn search told us that it is the most plentiful. This discrepancy makes sense. Foundational skills, such as SQL, that have been around a while will have a lot of practitioners, but are unlikely to be a hot topic of discussion. By the way, adjusting the allowable post creation dates made little difference to the relative outcome.

We couldn’t confirm the hypothesis, but we learned something valuable. Why not just use the number of people that show up in the LinkedIn search as the measure of our population with the particular skill? We have to build the population list by hand, but that kind of grunt work is the cost of doing business in data science. Combining the results of LinkedIn searches with our previous analysis of skills importance, we can categorize programming language skills for the company, as shown in Figure 1-2.

Figure 1-2. Programming language skill categorization (image courtesy of Jerry Overton)

Lessons Learned from a Minimum Viable Experiment

The entire experiment, from hypothesis to conclusion, took just three hours to complete. Along the way, there were concerns about which Stack Overflow contributors to include, how to define a helpful post, and the allowable sizes of technical communities—the list of possible pitfalls went on and on. But we were able to slice through the noise and stay focused on what mattered by sticking to a basic hypothesis and a minimum viable experiment.

Using simple tests and minimum viable experiments, we learned enough to deliver real value to our stakeholders in a very short amount of time. No one is getting hired or fired based on these results, but we can now recommend to our stakeholders strategies for getting the most out of our skills. We can recommend targets for recruiting and strategies for prioritizing talent development efforts. Best of all, I think, we can tell our stakeholders how these priorities should change depending on the technology domain.

1 Full disclosure: Host Analytics is one of my portfolio companies.

Get Big Data Now: 2015 Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial