Agile Metrics in Action: A good how-to guide to getting better performance measurements – #programming #bookreview

Agile Metrics in Action

Christopher W. H. Davis


In the rapidly changing world of software development, metrics “represent the data you can get from your application lifecycle as it applies to the performance of software development teams,” Christopher W. H. Davis writes in his well-written, well-structured new book, Agile Metrics in Action.

“A metric can come from a single data source or it can be a combination of data from multiple data sources. Any data point that you track eventually becomes a metric that you can use to measure your team’s performance.”

The goals of agile metrics include collecting and analyzing data from almost every useful and accessible point in the software development life cycle, so team and individual performances can be measured and improved, and processes can be streamlined.

A key aspect of the data collection and analysis process is distributing the resulting information “across the organization in such a way that everyone can get the data they care about at a glance,” Davis says. He explains how and highlights some “traps” that teams can “fall into when they start publishing metrics,” such as “[s]ending all the data to all stakeholders,” many of whom won’t know what to do with most of it.

Metrics remain a controversial topic for many software developers, Davis emphasizes. So any business leader planning to rush his or her company into adopting agile metrics will need to proceed cautiously, instead. It is vital to get buy-in first from developers and their managers, he says.

“There will likely be people in your group who want nothing to do with measuring their work,” he explains. “Usually this stems from the fear of the unknown, fear of Big Brother, or a lack of control. The whole point here is that teams should measure themselves, not have some external person or system tell them what’s good and bad. And who doesn’t want to get better? No one is perfect—we all have a lot to learn and we can always improve.”

The concept of continuous development is a key topic in this book. “In today’s digital world consumers expect the software they interact with every day to continuously improve,” Davis states. “Mobile devices and web interfaces are ubiquitous and are evolving so rapidly that the average consumer of data expects interfaces to continually be updated and improved. To be able to provide your consumers the most competitive products, the development world has adapted by designing deployment systems that continuously integrate, test, and deploy changes. When used to their full potential, continuous practices allow development teams to hone their consumer’s experience multiple times per day.”

Of course, continuous development produces continuous data to measure and manage, as well, using agile metrics techniques.

Many different topics are addressed effectively in this book. And the practices the author presents are organized to work with any development process or tool stack. However, the software tools Davis favors for this book’s code-based examples include Grails, Groovy and MongoDB.

Agile Metrics in Action is structured and written to serve as a how-to book for virtually anyone associated with a software development team that relies on agile metrics. You may not understand all of the text. But if you take your time with this well-illustrated book, you can at least gain a better comprehension of what agile metrics means, how the process works, and why it is important to your employer, your group and your paycheck.

Si Dunn

Unity in Action: A top-notch how-to guide for game developers – #gamedev #programming

Unity in Action

Joseph Hocking

Manning – paperback

Unity, the cross-platform game development environment, is easy to download and get running. But it definitely is not easy to learn without some help.

Fortunately, Joe Hocking’s Unity in Action makes it reasonably straightforward to learn how to develop games in 3D, as well as with Unity’s new 2D capabilities. The book takes the reader from “Hello, World” all the way to “Putting the parts together into a complete game” and then “Deploying your game to players’ devices.”

Even with this fine book, however, game development can be hard and complicated work. There are many different elements to consider, such as “Adding enemies and projectiles to the 3D game”, “Developing graphics for your game”, “Adding interactive devices and items within the game,” and putting sound effects and music into your game. Hocking’s book does a good job of showing how to handle these tasks, plus many more.

You may have heard Unity described as a game development environment where you don’t have to know how to program. Yes, you might be able to create some games without programming skills. But, “to produce commercial titles” using Unity, you definitely need some programming experience, Hocking emphasizes. In this case, you should have some knowledge of C#, but a background in some other object-oriented (OO) programming language will be helpful if you are new to C#, he adds.

Hocking’s book has many examples, illustrations, headings and subheadings. But step-by-step listings are sparse. Therefore, be prepared to read the text closely and, if necessary, develop lists of steps yourself. There is nothing wrong with this approach, and it is not really a criticism of the book. Game development, after all, is not something that you can, nor should, just dive into and speed through, step by step. It requires a lot of careful planning and thought before you start.

Unity in Action wastes no time. It gets right to the essential stuff you need to know. And it can get you into action reasonably fast as a game developer. But “reasonably fast” in this case must be defined by how quickly you personally can learn to handle Unity, plus the myriad tasks of planning, creating, testing, revising and distributing a game.

Si Dunn


Elixir in Action: A good guide to the ‘alternative language for the Erlang virtual machine’ – #programming #bookreview



Elixir in Action

Saša Jurić

Manning – paperback

“Elixir,”  Saša Jurić writes, “is a modern functional programming language for building large-scale, distributed, fault-tolerant systems for the Erlang virtual machine.”

What Elixir really is, of course, is a breath of fresh air for software developers who find it hard or confusing to work with Erlang’s sometimes complicated syntax and conventions.

Erlang has long been almost off the chart–the bottom of the chart–when computer languages are stacked up by popularity.  It began its oddball life in the 1980s as a programming language for the computers in telephone switching systems, specifically Swedish-made, Ericsson telephone switching systems.

Indeed, I first encountered Erlang in the  late 1980s while trying to help Ericsson sell Swedish-made computers to American banks. Back then, I counted my lucky stars that I didn’t have to learn it, because I was a tech writer, not a software developer.

Today, however, Erlang and its Open Telecom Platform (OTP) libraries are gaining new converts among serious practitioners of functional programming. Many of them likewise are drawn to Erlang’s built-in support for concurrency, distribution and fault tolerance.

The digital Swedish meatball known as Erlang turns out to be a powerful choice for providing high reliability and scalability to networked and distributed systems with multi-core processors. Telephone networks require high reliability and flexible scalability. And Erlang was designed to help provide both — without limiting itself to telecom systems.

Some of Erlang’s lack of popularity can be blamed on the language’s somewhat difficult learning curve. But it also has not been heavily promoted to software developers. That has been changing recently as companies and developers learn more about Erlang’s good track record, Saša Jurić points out.

“It powers various large systems and has been doing so for more than two decades, such as the WhatsApp messaging application, the Riak distributed database, the Heroku cloud, the Chef deployment automation system, the RabbitMQ message queue, financial systems, and multiplayer backends. It’s truly a proven technology.”

In Elixir in Action,  Saša Jurić nicely meets his goal of writing a book that brings “programmers new to Elixir and Erlang to the point where they can develop complex systems on their own.” Elixir provides an alternative language based on several other languages, including Ruby and Clojure, as well as Erlang.

Jurić’s how-to guide requires no prior experience with either Erlang or Elixir, but you should be familiar with at least one other programming language, such as JavaScript, C# or Ruby.

His book is divided into three parts:

  • Part 1, “The Language,” offers a high-level overview of Erlang and Elixir. Then it delves into Elixir’s basic building blocks and details common functional programming idioms.
  • Part 2, “The Platform,” focuses on primary aspects of BEAM, the Erlang virtual machine, as well as “how concurrency works and how it can help you build reliable systems.” Indeed, “[c]oncurrency is at the heart and soul of Erlang systems,” Jurić writes. “Almost every nontrivial Erlang-based production system is highly concurrent. Even the programming language is sometimes called a concurrency-oriented language.”
  • Part 3, “Production,”discusses “production aspects of BEAM-powered systems,” as well as “how to package components, reuse third-party libraries, and build a simple web server,” and “how to build a deployable standalone release and how to interact with the running system.”

Elixir in Action does not cover everything. But it provides fine overviews, clear how-to instructions, and compact code examples that illustrate important points. It can get you going in good directions.

“Elixir,” the author emphasizes, “lowers the entry barrier into the Erlang world and improves developer productivity.”

 — Si Dunn


Will “Smart” Device Dependence Make You Increasingly Dumb?

I strolled into my favorite Austin Starbucks recently and noticed a startling sight. Every person standing in line or sitting at tables simultaneously had their head down as if in group prayer. All at the same moment were staring at their smartphones.

I pulled out my own phone, dramatically flipped it open, held it aloft, and waved it in silent protest. No one got the joke, because no one noticed.


We’ve all seen people become panic-stricken and helpless when they realize they have lost or forgotten their “smart” device, or had it stolen. “Everything—my whole life—is on there!” one friend wailed recently. “All my pictures, my personal information, my contacts. And—oh, god–work emails! I don’t know what to do!” She kept frantically digging through her big purse, which also contained “everything,” including papers from work, so she could keep working at home after she got off work. When I called her phone from my phone, we found her “smart” phone buried deep beneath makeup containers and assorted other purse rubble.

Many people now use their smartphones for “everything,” from paying a restaurant check (after using the calculator function to split it and calculate the tip) to hailing an Uber ride and remotely controlling their home air conditioning. And, anytime a question is raised in a group, several people will circumvent natural debate or brainstorming by immediately going to Google and reading off some article titles and paragraphs.

Meanwhile, a few unrelated videos also will pop up and be shared:  Cat attacks python! Man sets shoes on fire by standing on hot coals! Ha-ha-ha!

The smartphone video distractions are only going to get worse. As AT&T’s CEO, Randall Stephenson recently told Fortune magazine: “…mobile video…is the real deal,” adding: “Half our mobile network traffic is video now, and it’s really growing fast.”

So, recent statutes banning talking or texting on a digital device while driving are now far behind the curve of progress. (“Sorry, officer, I was not breaking the law. I was watching Game of Thrones while paying no attention to the traffic and scenery around me.”)

Perhaps it is time to ask yourself two serious questions. Are you losing touch with the real world as you become increasingly distracted by your smartphone? And will your growing dependence on its “smart”-ness make you correspondingly “dumb” over time?

Si Dunn

BIG DATA: A well-written look at principles & best practices of scalable real-time data systems – #bookreview



Big Data

Principles and best practices of scalable real-time data systems

Nathan Marz, with James Warren

Manning – paperback

Get this book, whether you are new to working with Big Data or now an old hand at dealing with Big Data’s seemingly never-ending (and steadily expanding) complexities.

You may not agree with all that the authors offer or contend in this well-written “theory” text. But Nathan Marz’s Lambda Architecture is well worth serious consideration, especially if you are now trying to come up with more reliable and more efficient approaches to processing and mining Big Data. The writers’ explanations of some of the power, problems, and possibilities of Big Data are among the clearest and best I have read.

“More than 30,000 gigabytes of data are generated every second, and the rate of data creation is only accelerating,” Marz and Warren point out.

Thus, previous “solutions” for working with Big Data are now getting overwhelmed, not only by the sheer volume of information pouring in but by greater system complexities and failures of overworked hardware that now plague many outmoded systems.

The authors have structured their book to show “how to approach building a solution to any Big Data problem. The principles you’ll learn hold true regardless of the tooling in the current landscape, and you can use these principles to rigorously choose what tools are appropriate for your application.” In other words, they write, you will “learn how to fish, not just how to use a particular fishing rod.”

Marz’s Lambda Architecture also is at the heart of Big Data, the book. It is, the two authors explain, “an architecture that takes advantage of clustered hardware along with new tools designed specifically to capture and analyze web-scale data. It describes a scalable, easy-to-understand approach to Big Data systems that can be built and run by a small team.”

The Lambda Architecture has three layers: the batch layer, the serving layer, and the speed layer.

Not surprisingly, the book likewise is divided into three parts, each focusing on one of the layers:

  • In Part 1, chapters 4 through 9 deal with various aspects of the batch layer, such as building a batch layer from end to end and implementing an example batch layer.
  • Part 2 has two chapters that zero in on the serving layer. “The serving layer consists of databases that index and serve the results of the batch layer,” the writers explain. “Part 2 is short because databases that don’t require random writes are extraordinarily simple.”
  • In Part 3, chapters 12 through 17 explore and explain the Lambda Architecture’s speed layer, which “compensates for the high latency of the batch layer to enable up-to-date results for queries.”

Marz and Warren contend that “[t]he benefits of data systems built using the Lambda Architecture go beyond just scaling. Because your system will be able to handle much larger amounts of data, you’ll be able to collect even more data and get more value out of it. Increasing the amount and types of data you store will lead to more opportunities to mine your data, produce analytics, and build new applications.”

This book requires no previous experience with large-scale data analysis, nor with NoSQL tools. However, it helps to be somewhat familiar with traditional databases. Nathan Marz is the creator of Apache Storm and originator of the Lambda Architecture. James Warren is an analytics architect with a background in machine learning and scientific computing.

If you think the Big Data world already is too much with us, just stick around a while. Soon, it may involve almost every aspect of our lives.

Si Dunn

D3.js in Action: A good book packed with data visualization how-to info – #javascript #programming

D3.js in Action

Elijah Meeks

Manning – paperback


The D3.js library is very powerful, and it is full of useful choices and possibilities. But, you should not try to tackle Elijah Meeks’s new book if you are a JavaScript newcomer and not also comfortable with HTML, CSS and JSON.

It likewise helps to understand how CSVs (Comma Separated Values) can be used. And you should know how to set up and run local web servers on your computer. Prior knowledge of D3.js and SVG (Scalable Vector Graphics) is not necessary, however.

Some reviewers have remarked on the amount of how-to and technical information packed into DS3.js in Action. It is indeed impressive. And, yes, it really can seem like concepts, details and examples are being squirted at you from a fire hose, particularly if you are attempting to race through the text. As Elijah Meeks writes, “[T]he focus of this book is on a more exhaustive explanation of key principles of the library.”

So plan to take your time. Tackle D3.js in small bites, using the website and this text. I am pretty new to learning data visualization, and I definitely had never heard of visualizations such as Voronoi diagrams, nor tools such as TopoJSON, until I started working my way through this book. And those are just a few of the available possibilities.

I have not yet tried all of the code examples. But the ones I have tested have worked very well, and they have gotten me thinking about how I can adapt them to use in some of my work.

I am a bit disappointed that the book takes 40 pages to get to the requisite “Hello, world” examples. And once you arrive, the explanations likely will seem a bit murky and incomplete to some readers.

However, that is a minor complaint. D3.js in Action will get frequent use as I dig deeper into data visualization. D3.js and Elijah Meeks’s new book are keepers for the long-term in the big world of JavaScript.

Si Dunn

Programming for Musicians and Digital Artists: Creating Music with ChucK – #music #programming #bookreview



Programming for Musicians and Digital Artists

Creating Music with ChucK

Ajay Kapur, Perry Cook, Spencer Salazar and Ge Wang

Manning – paperback

Manning’s Programming for Musicians and Digital Artists is enjoyable, informative reading, particularly if you like music and programming and are motivated to combine them in some way.

The book offers plenty of clear how-to content for those who want to take their first deep dives into the techniques needed to make, modify and perform music using computers.

Indeed, this excellent guide can help take you from generating  “Hello, World” and “Twinkle, Twinkle, Little Star” to linking up with MIDI devices and creating sophisticated music and sounds that can be used in live performances and elsewhere.

Don’t be scared by the word “Programming” in the title. Yes, it can help–but it is not required–to have a little bit of programming experience. As you start working with the audio-centric programming language ChucK, you will simply type a few brief lines of code or paste them from downloaded files into a simple on-screen tool known as the “miniAudicle.” With this tool, you can then make changes and hear the results “instantly without interrupting other sounds being synthesized and heard,” the authors point out. You also can save your files, load different files and do other tasks quickly.

The free, open-source ChucK programming language, the authors’ emphasize, “is designed specifically for real-time sound synthesis and music creation.” Their book provides numerous short code examples to tinker with, as well as a few basic physics, math and music pointers that illustrate features and help support the authors’ descriptions.

Note: If your goal is to sit down at a keyboard and immediately start creating digital music, you may want to skip this book and look for other options. The authors concede that “many artists are happy with over-the-counter software systems and controllers for real-time performance work. And there are many who only want to use computers to produce static final products in the form of .wav/.mp3 files, CDs or collections of songs, sound tracks for videos, and more. A large number of those artists are happy to learn and use the packages and tools from commercial or free sources.

“But there are many, and we’re betting you’re one, who want more,” they add. “Maybe you’re coming to this book with a big idea (or many big ideas) and want the tools to help you realize it/them. Maybe you’re looking to shift directions in your art making. Or perhaps you already know how to program in a language such as Java, but you find it doesn’t do what you want.”

ChucK gives you “greater under-the-hood access” than some of the other popular music/sound languages and systems, such as Csound, SuperCollider, JSyn, Max/MSP and PD (Pure Data). And Chuck, the authors note, “is generally more succinct, requiring much less code (lines of typed text) than these other languages in order to accomplish a particular task.”

You learn how to work with many different tools, ranging from oscillators, to filters, to delay generators, reverberators and other audio effects, and MIDI (even without a MIDI interface and cable). You also learn how to generate the sounds of several different musical instruments.

ChucK has a key emphasis on ease of controlling time: for example, how long a tone or sounds occurs, how often it occurs within a set time period, and how long are the silences between tones or sounds.

I have not yet tried all of the code examples in the book, but the ones I have tried in several chapters have worked very well on a Windows laptop and are easily modified and tested in real time using the miniAudicle. (The book also shows how to install ChucK on Mac OS X and Ubuntu Linux systems).

Thus far, I have encountered only one typo in the printed book’s code examples. In Listing 1.8, “Playing notes with integer values,” there is a mistake in the line that is supposed to multiply the frequency of a tone pitch by 2. However, the line is printed “1 *=> myPitch;” — which simply repeats previous pitch. Changing the line to “2 *=> myPitch;” fixes the problem and takes only a couple of seconds to implement in the miniAudicle.

Si Dunn