Thursday, September 25, 2014

Push to a Different Branch


I made updates to files, added them to the local git repo and committed them to the index (git's local staging repo).

Then I realized that I had failed to create a new branch.

So the files I just updated are in an old branch.

How do I move these files to a new branch on the remote repo in one command?


Use one of my handy git aliases, of course!

$ git push-current-branch-to-another <CURRENT_OLD_BRANCH_NAME> <NEW_BRANCH_NAME>


This work is licensed under the Creative Commons Attribution 3.0 Unported License.

Thursday, September 18, 2014

Atrocious API Architecture (AAA)


Use the following planning, design, implementation and testing pointers to create a terrible API.

Or do the opposite of each recommendation to create an API that rocks.


  • Start building your app before you clearly define your system requirements
  • Do not try to understand your problem domain
  • Do not identify constraints
  • Focus on on individual steps, rather than overall system throughput
  • Do not try to improve efficiency of your biggest constraints (see previous rule)
  • Refer only the articles listed in the References section below


  • Do not use RESTful APIs
  • Use web services and assume your integration partners will not change their APIs
  • Make your API as big as possible
  • Use SOAP or better yet, roll your own request/response protocol
  • Do not apply the Fascade Pattern (expose your implementation details via your API)
  • Do not use default args, varargs, generics or enums
  • Do not version your API (change your API at will without notifying clients)
  • Never use JSON (Use a custom message protocol or at least SOAP)
  • Do not implement rate limiting (allow a single client to hog system resources)
  • Use nonsensical API operation names
  • Use inconsistent API operation names (ex: use both AddProduct and insertClient)


  • Permit non SSL access to various end points
  • Require as much data as possible from your clients to satisfy simple requests
  • Never use interface types for input parameters (use classes)
  • Require generic input parameter types
  • Always use the String type for inputs and outputs
  • Expose access to all internal data fields and methods
  • Use inconsistent parameter ordering (and lots of them!)
  • Force clients to use exceptions for flow control
  • Force client to specify data type of fields in each request
  • Use session based security for long running transactions
  • Do not provide authentication options (do everything in the clear)
  • Do not notify clients when data has been modified (force them to perform bulk reads and compare)
  • Do not filter any of the fields from your database tables
  • Do not allow clients to indicate which fields they want returned in the response
  • Do not return updated_at attribute (make the client hit your API repeatedly for the same data)
  • Do not use HTTP status codes in your response


  • No Agile development (that's a given!)
  • Do not use project management software like Jira, Pivotal Tracker, Rational Team Concert
  • Hold hour-long meetings hourly
  • Micro manage your developers
  • Never allow time for research or prototyping
  • Assume everybody will get everything right the first time and plan accordingly


  • Do not use feature branches
  • Merge all code into the single, master branch
  • Do not tag your commits with a ticket/reference number
  • Do not make your API pluggable
  • Provide the same level of service regardless of business requirements
  • Design such that small specific changes will require lots of system upgrades
  • Always copy and paste code (no code reuse!)
  • Avoid writing modular code
  • Create only mutable objects (avoid stateless design)
  • Avoid functional programming
  • Do not fail early (process as much of the request as possible before you return an error)
  • Use Java (always overload your methods and use subclassing as much as possible)
  • Fail silently when possible
  • Use only global variables
  • Use floating points for monetary values


  • If you do test, do not try to test individual components (which would be nearly impossible, given your needlessly complicated API)
  • Do not write unit tests
  • Do not provide an API test framework for your clients to use
  • Ensure that your tests take so long to run that it is impossible for developers to test their new code before they merge it into the master branch
  • Do not document (and if you do add non-valuable comments like: // This is a loop)


This work is licensed under the Creative Commons Attribution 3.0 Unported License.

Thursday, September 11, 2014

Fix Go SDK Version for go-lang-idea-plugin


Go works fine from the command window, but within IntelliJ you get a message about incorrect SDK version.


You installed Go using homebrew.

Go Environment

Here, we see that Go 1.3.1 is the current installed version:

$ go env
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"

Fix IntelliJ Problem

The go-lang-idea-plugin reported that it expected Go version 1.3, but got 1.3.1. So, just remove 1.3 (assuming that you don't need it) and create a symlink fro 1.3 to 1.3.1:

$ cd /usr/local/Cellar/go
  /usr/local/Cellar/go $ tdml
├── 1.2.2 -> /usr/local/Cellar/go/1.3/
├── 1.3
│   ├── bin
│   ├── etc
│   ├── libexec
│   └── share
└── 1.3.1
    ├── bin
    ├── etc
    ├── libexec
    └── share

11 directories
  /usr/local/Cellar/go $ rm -rf 1.3
  /usr/local/Cellar/go $ ln -s /usr/local/Cellar/go/1.
1.2.2  1.3.1/
  /usr/local/Cellar/go $ ln -s /usr/local/Cellar/go/1.3.1 /usr/local/Cellar/go/1.3


This feels like such a hack, but I could not find a way to configure the version of the Go SDK for the go-lang-idea-plugin.

If anybody finds a better solution, please let us know. Thanks!

The Rest of the Story

I eventually found where to conigure the Go SDK in IntelliJ.

File > Folder Structure > Project Settings > Modules > Dependencies

Click the Module SDK dropdown and select the latest Go SDK (In my case it is currently Go SDK go1.3.3 darwin/adm64)

If that is not an option, you may need to click the New... button and select the path that is $GOPATH.

Also, verify that you selected the correct Go SDK in File > Project Structure > Project Settings > Project


This work is licensed under the Creative Commons Attribution 3.0 Unported License.

Thursday, September 4, 2014

Jasmine Now Supports Pending Status


Jasmine is a BDD-style testing framework for automated testing of your web UI using headless browsers.

By default, it is configured to test Chrome and Firefox browsers.


Until recently, Jasmine did not allow you to indicate that any of your tests are in a pending state.

As of version 2.0, that is now possible.

Install Jasmine 2.0

You may run into issues updating your Jasmine installation.

Below, are the commands that worked for me:

$ rm -rf node_modules/karma
~/dev/angularjs/test $ npm cache clean
~/dev/angularjs/test $ npm install karma-jasmine@2_0 --save-dev
npm WARN package.json todomvc-angular-tests@1.0.0 No repository field.
npm WARN package.json karma-chrome-launcher@0.1.4 No README data
npm WARN package.json karma-phantomjs-launcher@0.1.4 No README data

> fsevents@0.2.1 install ~/dev/angularjs/test/node_modules/karma/node_modules/chokidar/node_modules/fsevents
> node-gyp rebuild

  CXX(target) Release/
  SOLINK_MODULE(target) Release/fse.node
  SOLINK_MODULE(target) Release/fse.node: Finished

> ws@0.4.32 install ~/dev/angularjs/test/node_modules/karma/node_modules/
> (node-gyp rebuild 2> builderror.log) || (exit 0)

  CXX(target) Release/
  SOLINK_MODULE(target) Release/bufferutil.node
  SOLINK_MODULE(target) Release/bufferutil.node: Finished
  CXX(target) Release/
  SOLINK_MODULE(target) Release/validation.node
  SOLINK_MODULE(target) Release/validation.node: Finished
karma@0.12.23 node_modules/karma
├── di@0.0.1
├── graceful-fs@2.0.3
├── rimraf@2.2.8
├── colors@0.6.2
├── mime@1.2.11
├── q@0.9.7
├── minimatch@0.2.14 (sigmund@1.0.0, lru-cache@2.5.0)
├── optimist@0.6.1 (wordwrap@0.0.2, minimist@0.0.10)
├── glob@3.2.11 (inherits@2.0.1, minimatch@0.3.0)
├── source-map@0.1.38 (amdefine@0.1.0)
├── lodash@2.4.1
├── useragent@2.0.9 (lru-cache@2.2.4)
├── log4js@0.6.20 (semver@1.1.4, async@0.1.15, readable-stream@1.0.31)
├── http-proxy@0.10.4 (pkginfo@0.3.0, utile@0.2.1)
├── chokidar@0.8.4 (recursive-readdir@0.0.2, fsevents@0.2.1)
├── connect@2.12.0 (uid2@0.0.3, methods@0.1.0, cookie-signature@1.0.1, debug@0.8.1, pause@0.0.1, fresh@0.2.0, qs@0.6.6, bytes@0.2.1, buffer-crc32@0.2.1, raw-body@1.1.2, batch@0.5.0, cookie@0.1.0, negotiator@0.3.0, send@0.1.4, multiparty@2.2.0)
└── (base64id@0.1.0, policyfile@0.0.4, redis@0.7.3,

karma-jasmine@0.2.2 node_modules/karma-jasmine

Test Code

Here's how to indicate that you have a Pending test:

Continuous TDD - Console Output


Instead of saying PENDING: 1 in an intuitive yellow color the console output says, "Skipped 1".

Mocha/Chai is another alternative that also works well and has a more flexible plugin architecture.


This work is licensed under the Creative Commons Attribution 3.0 Unported License.