Can I get the recipe for that – Kung Pao Chicken

The Ingredients

  • 1 lb boneless, skinless chicken breast or thigh, cut into 1 inch cubes
  • 2 tbsp peanut or vegetable oil
  • 8 to 10 dried red chilies
  • 3 scallions, white and green parts separated, thinly sliced
  • 2 cloves garlic, minced
  • 1 tsp ginger, minced or freshly grated
  • 1/4 cup unsalted, dry-roasted peanuts


  • 1 tbsp soy sauce
  • 2 tsp Chinese rice wine or dry sherry (do not use Mirin - Japanese rice wine)
  • 1-1/2 tsp cornstarch


  • 1 tbsp Chinese black vinegar or good quality balsamic vinegar
  • 1 tsp soy sauce
  • 1 tsp hoisin sauce
  • 1 tsp sesame oil
  • 2 tsp cornstarch
  • 1/2 tsp ground Sichuan pepper

The Directions

  1. Marinate the chicken: In a medium bowl, stir together the soy sauce, rice wine, and cornstarch until the cornstarch is dissolved. Add the chicken and stir gently to coat. Let stand at room temperature for 10 minutes.
  2. Prepare the sauce: In another bowl, combine the black vinegar, soy sauce, hoisin sauce, sesame oil, sugar, cornstarch and Sichuan pepper. Stir until the sugar and cornstarch are dissolved and set aside. NOTE: If you like a saucy sauce, you can scale up the ingredients. This is a dryer sauce at this ratio.
  3. You may need to turn on your stove's exhaust fan. Stir frying chilies on high heat gets a bit smokey!
  4. Heat a wok or large skillet over high heat until a bead of water sizzles and evaporates on contact. Add the peanut oil and swirl to coat the base. Add the chilies and stir-fry for about 30 seconds or until the chillies have begin to blacken and the oil is slightly fragrant. Add the chicken and stir-fry until no longer pink about 2 to 3 minutes.
  5. Add the scallion whites, garlic, and ginger and stir-fry for about 30 seconds. Pour in the sauce and mix to coat the other ingredients. Stir in the peanuts and cook for another 1 to 2 minutes. Transfer to a service plate, sprinkle the scallion greens on top, and serve.

Version Control by the numbers

One of the least automated functions in software is the realm of numbering releases. Often, these numbers are functions of a marketing department, trying to impress customers rather than actually following any set standard.

In the movie Tron: Legacy, the character Alan Bradley, a former programmer, now executive, asks the president of ENCOM:

Given the prices we charge to students and schools, what sort of improvements have been made in Flynn... I mean, um, ENCOM OS-12?

And the president replies:

This year we put a "12" on the box.

Ironically, this is not as far from reality as you might expect. But suppose you are responsible for a software release. In that case, you need a version control numbering system that the engineering department can rely on, even if you need to maintain a translation grid somewhere else (hint: You probably will need one).

Version Number Basics

Numbering schemes vary by company but generally follow a template similar to this:



XX is a major release version number

YY is a minor release version number

ZZ is a patch release version number

AA (AAA) is the daily or latestrelease version number

The Daily or Latest release (AA or AAA)

The most automated of the version numbers is the daily or latest stable release number. If you use a build system, the last number is the build number. Every time code builds, the last number increments automatically, whether the build is successful or not. When the build is successful, usually by passing all automated tests, it is considered the latest stable build. This build is usually not released, but teams use it to develop additional features or patches or validate release candidates. While this build usually comes out of the development branch (in a three-branch system), nothing prevents it from coming from other automated build branches.

This number may or may not reset if one of the other three numbers is incremented based on the release management policy.

Many artifact repositories will alias the newest stable build as latest.

The Patch release (ZZ)

The most frequently updated public version number is the patch release number. This indicates changes to the base code that all users should take and update. This may include specific spot releases or roll-up patches from daily releases that are now regression tested and ready for everyone.

The patch release should not include new functionality. This release is a bug fix, major or minor, only.

The Feature Release (YY)

As an application matures, new features are added, and these features do not break backward compatibility but extend existing functionality or introduce new functionality. These releases tend to be less frequent than patch releases.

The Major Release (XX)

When an application does a major release, we discuss new features and functionality that break backward compatibility with prior versions. These big releases might include new kernels, schema designs, or APIs that no longer talk to older versions.

Major versions are often entirely new code bases, redesigned UIs, or tuned to specific hardware or changes to third-party requirements for API interactions. Depending on the software, it is usually possible to run two major versions simultaneously (although you probably do not want to).

Internal versus External Version Numbers

As mentioned, version control can be impacted by marketing. It is common, though bad practice, for the marketing version number not to be updated when a system is patched, even if the internal version number is updated. Sometimes this is to obscure the patch, sometimes, it is to prevent confusion with marketing campaigns and sometimes, it is contractual.

It is vital to ensure that regardless of the marketing number, you keep tight control of the internal numbers, incrementing them per build, patch or feature merge, and, finally, major releases. These numbers should result in tagging in the version control system, and all software that ends up in the artifact repository should be clearly identified.