Wednesday, June 1, 2016

Setting javaagent on Tomcat 6 Running As Windows Service

This will be a quick post, for reference.

If you ever need to set the javaagent on Tomcat 6 running as a Windows service, you need to set it using tomcat6w.exe in the Java tab.

For example, to add the New Relic Agent, add the following line

-javaagent:"c:\Program Files\Apache Software Foundation\Tomcat 6.0\newrelic\newrelic.jar"

Note that the path to the javaagent needs to be a fully qualified path, and path separator is the typical Windows backslash.

Sunday, February 14, 2016

Your Code Is Broken If You Don't Understand It

If you don't understand every line of code you write, your code is broken!

Ever start writing a pice of code, and it snowballs on you and you end up with a couple hundred (or thousand) lines of code, and it starts to get away from you? You start wondering what it all means? Maybe you're working with other developers, with various levels of experience, which is adding to the overall code mass. Collectively do you understand what you are writing?

If at any point you stop being able to understand the code you are writing, it's time to stop and rethink  things. The code is broken. Now is the time to correct it!

A problem you perceive is a problem you own!

If there's something bothering you about your code base, there's no better time than the present to address it. It doesn't matter your seniority level. You should talk it through with other devs. Maybe they have similar problems with the code, but we're hesitant to bring it up. Continuously thinking about talking about, and improving your systems is the only way to keep your systems functioning. Putting off problems will only cost you more in the future!

From my experience, good code is boring code. Good good is self explanatory. Good code is modularized. Good code reads well. Good code matches up with the domain concepts. Writing good code takes time, patience, and access to experience developers who know what good code is and how to write it. Good code is hard to do, but worth the effort if you ever want to maintain it.

Writing good code is possible even under time pressure! Stress is no excuse for sloppiness!

If at any point you notice you can't understand the code, it's usually an indication that you are heading down the wrong path!

There is usually a simpler way!

When you recognize that you're code is getting to complicated, stop and think. Why is this so complicated? Is the complexity inherent to the domain? If not, then most likely it's incidental complexity.

The best thing you can do if you ever get this point is to talk it through with someone else!

The act of explaining things to someone else helps solidify in our minds what we're trying to accomplish.

Ever feel the need to write comments in your code such as

// hackety hack hack, this is a hack

? If you ever feel that need, stop. You know that your code us getting away from you. It's talking to you. Don't write that comment and carry on. While the business wants results, they also don't want to carry around a liability!

And what value to future maintainers do such comments provide? Every line of code, every character you type should have a reason, and a dam good one. The code should be clean, and as simple and straightforward as possible.

The single responsibility principle and the don't repeat yourself principle applied religiously go a long way to improving the maintainability of your code. In my experience, they aren't applied enough!

Ok, kind of a rantish vibe emerging.

To end this on a positive note, apply the 4 XP simplicity rules, and take pride in your work! Also, check out an answer I posted on Quora which has lots of links to great talks and books that I have found the most valuable.

I highly recommend you watch Rich Hickey's talk "Simple Made Easy".


I just watched Uncle Bobs talk " The Last Programming Language" on InfoQ, and it fits really well into this post.

Uncle Bob talks about the divide between business and engineering, and I believe this divide does indeed exist. Deeply technical engineering work is necessary to deliver long lasting results, but it doesn't fit very well into high level business metrics.

Also, the developers and engineers who understand what it really takes to deliver quality software can have a hard time selling the costs of doing things "right". And on top of that, we developers and engineers don't agree on what " right" really means.

Sunday, December 13, 2015

Ember + Node + Express + EJS + Elastic Beanstalk

Here's the set of steps I follow to test out Ember using Node / Express in Elastic Beanstalk. For reference, here's a test project I've deployed to AWS EB using these steps.

Start a new Ember project, and add in the Express dependencies

    npm install -g ember-cli
    ember new my-awesome-app
    cd my-awesome-app
    npm install --save express
    npm install --save ejs
    npm install --save path
    npm install --save debug
    mkdir bin
    mkdir views

create a file named www inside bin folder
#!/usr/bin/env node

var app = require('../index');
var debug = require('debug')('autocare:server');
var http = require('http');

var port = normalizePort(process.env.PORT || '3000');
app.set('port', port);

var server = http.createServer(app);
server.on('error', onError);
server.on('listening', onListening);

function normalizePort(val) {
  var port = parseInt(val, 10);

  if (isNaN(port)) {
    // named pipe
    return val;

  if (port >= 0) {
    // port number
    return port;

  return false;

function onError(error) {
  if (error.syscall !== 'listen') {
    throw error;

  var bind = typeof port === 'string'
    ? 'Pipe ' + port
    : 'Port ' + port;

  switch (error.code) {
    case 'EACCES':
      console.error(bind + ' requires elevated privileges');
    case 'EADDRINUSE':
      console.error(bind + ' is already in use');
      throw error;

function onListening() {
  var addr = server.address();
  var bind = typeof addr === 'string'
    ? 'pipe ' + addr
    : 'port ' + addr.port;
  debug('Listening on ' + bind);

Grant www execute permissions

    chmod +x www

Change package.json start script to execute the www script, so Elastic Beanstalk app will runn the Express Server, instead of the Ember server

    "scripts": {
        "build": "ember build",
        "start": "node ./bin/www",
        "test": "ember test"

Create index.js in root folder, that will startup the Express server, and route traffic from '/' to the ember page at /public/ember-app/index.html (note: I used /public/ember-app instead of /public/app because /public/app was breaking the ember build).

var express = require('express');
var path = path = require('path');
var ejs = require('ejs');

var app = express();

app.use(express.static(path.join(__dirname, 'public/ember-app')));
app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'ejs');

app.get("/", function(req, res) {
 res.sendFile("index.html", { root: "./public/ember-app/" });

if (app.get('env') === 'development') {
 app.use(function(err, req, res, next) {
  res.status(err.status || 500);
  res.render('error', {
   message: err.message,
   error: err

app.use(function(err, req, res, next) {
 res.status(err.status || 500);
 res.render('error', {
  message: err.message,
  error: {}

module.exports = app;
Create error.ejs template in views folder

<!DOCTYPE html>
  <h1>An Error Has Occurred&bt;/h1>
   <%= message %>

Build Ember App

    ember build --environment production --output-path ./public/ember-app

Commit / Push to GitHub

    git add // (add files)
    git commit -m "setting up express"
    git push

Deploy to Elastic Beanstalk

    eb deploy

Sunday, November 22, 2015

2015 Reading List

So it's that time of year again when I look back over my goodreads list of books, and share the ones I've actually finished. Lots of good stuff this year, IMHO. If I had to pick, I think The Toyota Way and Holacracy are at the top of the list.

I'm a software developer, and I spend my days in the coding trenches. However I like to read about and understand the bigger picture, and how my work fits in with the rest of the company, and the rest of the world for that matter. Having said that, I'd read just about anything.

Lean Enterprise: How High Performance Organizations Innovate at Scale, Jez Humble, Joanne Molesky, Barry O'Reilly

The Toyota Way: 14 Management Principles from The World's Greatest Manufacturer, Jeffery Liker

Understanding the Four Rules of Simple Design, Corey Haines

A Brief History of Time, Stephen Hawking

The Tao of Pooh, Benjamin Hoff

Siddhartha, Hermann Hesse

Peace of Mind: Becoming Fully Present, Thich Nhat Hanh

Fish!: A Remarkable Way to Boost Morale and Improve Results, Stephen C. Lundin, Harry Paul, John Christensen, Kenneth H. Blanchard

Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization, Dave Logan

The 4 Disciplines of Execution: Achieving Your Wildly Important Goals, Sean Covey, Chris McChesney, Jim Huling

A Simpler Way, Margaret J. Wheatley, Myron Kellner-Rogers

Delivering Happiness: A Path to Profits, Passion and Purpose, Tony Hsieh

Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness, Frederic Laloux, Ken Wilber

Holacracy: The New Management System for a Rapidly Changing World, Brian J. Robertson

Mindset: The New Psychology of Success, Carol S Dweck

Switch: How to Change Things When Change is Hard, Chip Heath, Dan Heath

Start with Why, Simon Sinek

How to See Yourself as You Really Are, His Holiness the Dalai Lama

Quality is Free, Philip Crosby

Conscious Business: How to Build Value Through Values, Fred Kofman

Soft Skills: The software developers life manual, John Sommez

Fierce Conversations: Achieving Success at Work and in Life One Conversation at a Time, Susan Scott, Kenneth H. Blanchard

Agile!: The Good, The Hype, and The Ugly, Bertrand Myer

The Software Craftsman: Professionalism, Pragmatism, Pride, Sandro Mancuso

The Tao of Zen, Ray Grigg

Sunday, June 7, 2015

Quality is Free

Ed Horch commented on an answer I posted on Quora, suggesting I add Quality is Free by Philip B. Crosby to my answer. I have never read that book before, so I went ahead and bought a used copy. This book is stirring up things in my head about quality as it relates to software development, and I want to jot down a few notes, before I forget them.

What is Quality?

According to Crosby
Quality is conformance to requirements 
That's a very simple definition of quality, and at first glance it might not seem revolutionary. And it's in stark contrast to how Prisig tries to define quality in Zen And The Art of Motorcycle Maintenance, driving the main character mad trying to define exactly what quality is. I really like Crosby's definition of quality. I'll try to expand on that a little bit.

Another way quality was book in the book, and I'm paraphrasing here
Quality is when a customer gets what they expect
What are your customers expectations?

Most of what your customer expects is what they have been told. There's what you have promised them. All your marketing materials, demos, product documentation, etc.

There's what they expect from your product that you haven't explicitly told them.  If you're building a better word processor, then your users might expect it to work similar to Microsoft Word. And in the absence of being told, your customers might make up their own requirements, based on past experiences.

And your customers expect your software to work, regardless of how many others are using it, if you're building online software.

What have you promised?

The marketing materials, demos, and product documentation are the explicit things where you make promises to your client, if you provide them. If you have an SLA, that spells out in explicit detail what your clients can expect. Your brand also makes promises of your product - for example, I would expect all Apple products to be well polished and just work, regardless of what product they produce.

How to get Quality for Free in Software Development?

That's an interesting question, and I'm not claiming I have the answer. But I do think there is something to the idea of "Quality is Free", and I think it align's pretty well with the agile / lean development practices. Here's what this means to me.

We can measure quality by executing BDD style tests for use cases. To me, a use case is a promise for how a feature will behave - a promise to our customers.

We need to tests for non-functional requirements to have quality. To do this, we need to plan for usage patterns, and design to support that load.

We can start thinking about testing for quality before writing a single line of code. Imagine that the feature is finished, and you want to demo it to a prospective client. What language would you use? What is your sales pitch? However you want to sell it, those selling points are your promise to your clients, and can be captured in tests, before writing the software!

I'd love to hear about how "Quality is Free" has influenced your software development practices.

Tuesday, March 17, 2015

Code Comments

The whole "no comments" thing can be taken too far. We should strive to write code that is clear as possible so comments aren't necessary.
However, the act of writing a function header before writing the function is a good way to think about the intent of the code your about to write.
If you try to write a concise description of a function and you struggle with it, then its a sign your design might be over complex,or you haven't decomposed the problem well enough.
Its also a good way to spot violations of SRP.if you find that you have to use the word "and" multiple times to describe the intent of a function, then you probably have multiple functions crammed Into one.
After refactoring your code, perhaps using TDD, if your comment is completely redundant because the code expresses everything you need to know, then as a last step you should delete the comment.
Here's what I consider bad comments:
1. Comments that add no value because the code already expresses intent more clearly than the comment.
2. Comments that are out of sync with the code.
3. Code block comments that would be better written as a function name.
Writing clean code takes discipline. The act of writing intent before the code helps you clarify in you mind the design, and is a valuable design tool.
The most valuable comments are ones that describe the why. Comments that describe the what are the dangerous kind.