Jerome's Blog

As part of my own personal professional development, I publish the books I've read for the year. I'm on GoodReads, and here is my r eading challenge . Looking back, there were a few themes Performance - I'm staring to get serious about performance analysis of systems. Brendan Gregg and Martin Thompson are influential in my understanding of systems and how to design for performance. It's also clear that what I thought I knew about computers, specifically OS kernels, is severely lacking.  Operations - Site Reliability Engineering opened my eyes as to how large companies such as Google support applications in production.  Philosophy and religion interest me. The more I think about it, I'm probably an atheist. The scientific method resonates with me, as well as Occam's Razor. I question my Catholic upbringing. The Bill Nye / Ken Ham debate gets you thinking.  Systems Performance: Enterprise and the Cloud , Prentice Hall, 2013, Brendan Gregg Extreme

Overview I've seen Brendan Gregg's talk on generating mixed-mode flame graphs  and I wanted to reproduce those flamegraphs for myself. Setting up the tools is a little bit of work, so I wanted to capture those steps. Check out the Java in Flames post on the Netflix blog for more information. I've created github repo ( github.com/jerometerry/perf )  that contains the scripts used to get this going, including a Vagrantfile, and JMeter Test Plan. Here's a flame graph I generated while applying load (via JMeter) to the basic arithmetic Tomcat sample application. All the green stacks are Java code, red stacks are kernel code, and yellow stacks are C++ code. The big green pile on the right is all the Tomcat Java code that's being run. Tools Here's the technologies I used (I'm writing this on a Mac). VirtualBox 5.1.12 Vagrant 1.9.1 bento/ubuntu-16.04 (kernel 4.4.0-38) Tomcat 7.0.68 JMeter 3.1 OpenJDK 8 1.8.111 linux-tools-4.4.0-38 linux-to

Sales Demo Imagine you have a Java web application that you deploy via a WAR file to a Tomcat server, and you want your sales staff to be able to demo that application from their laptops. The sales folks often times go onsite to customers offices, where they don't have internet access. What options are available for running these kinds of sales demos? Option #1 - Run Web Server Directly One way to solve this is for the sales staff to install Tomcat and Java on their laptops, and deploy the WAR file by hand. That can work, but if your sales staff aren't that technical, having them configure web servers isn't a good use of their time. Not to mention that if your application requires a database as a dependency, then they must also install a database server such as Postgres, and configure the security settings properly to allow the app to connect. There's too many moving parts here for sales staff to configure a demo in this way. Clearly, we want to automate this pr

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.

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 abo