trevmex's tumblings

Java Coder, JavaScripter, Rubyist, Functional Programmer, Agile Practitioner.

#JavaOne Adopting Java: Create Java’s Future. Now. [Notes]

Martijn Verburg, Séti Afanou


  • JUG - Java User Group
  • JCP - Java Community Process
  • JSR - Java Specification Request
  • RI - Reference Implementation
  • TCK - Technology Compatibility Kit

Java EE’s RI is usually JBoss or GlassFish

If you want to have an RI you have to pass the TCK (their test suite).

Adopting a JSR starts here.

You should get involved in shaping Java if you like coding in Java. If you don’t then other people (not you) will be the people shaping the language, and that could be a bad thing for you…

JUGs can get involved with JSRs in lots of ways. One of the big ones is through training, testing and debugging.

One of the fun things about the program is that you can meet lots of people from other JUGs around the world.

Every single JSR is developed out in the open. It is all public and open for comment.

You can join the virtual JUG if you do not have a JUG near you.

Java is build by OpenJDK. You can compile Java 9 right now!

A great way to give back is to try out the new APIs (write an app that runs against a proposed API) and see if it works the way you expect.

You can work on RIs themselves as well! One fun one is JavaMoney.

There is also a units and measurements API that you can contribute to as well.

Oracle is the lead for most of the Java EE JSRs, if you want to get involved with them, check out

You can also join the “Expert Group” for a JSR, but fair warning it is a 20-40 hour per week time sink if you decide to do that.

If you are really insane, you can ask to join the executive committee. There is almost no tech work on the executive committee, it is almost all lawyer work.

If you want to get involved with a JSR, make sure you contact the Spec Lead before diving in.

Great information, thanks!


#JavaOne James Gosling, Robots, the Raspberry Pi, and Small Devices [Notes]

James Gosling, José Pereda, Johannes Weigend, Shai Almog, Jens Deters

Java can be used to program any number of embedded systems. James Gosling, the father of the Java language is using JavaSE embedded on ARM to power robots in the ocean to do research.

Also, it seems that the embedded comminuty REALLY LIKES Netbeans as an IDE.

Java works great on RaspberryPI hobby hardward boxes. RaspberryPis are cool because they allow you to rapid prototype hardware project for very low cost. There is a great library called Pi4J to help you write Java code on a RaspberryPi.

RaspberryPis are a great thing to play with your kids with. They are good tools to get your kids excited about programming and computer engineering.

Fun stuff!

Solarized Dark for Slack

We use Slack at work for intra-office communication. It is a great tool, but I don’t really like the default color scheme. Fortunately, you can customize it (well at least the sidebar).

I like Solarized colors, so I set about making a Solarized Dark Sidebar Theme. Here is how you do it:

  1. Click on your name in the bottom right and open Preferences:
  2. Click on the Sidebar Theme tab on the left.
  3. Click the link on the bottom of the pane that says: Feeling adventurous? You can customize your theme and share it with others.
  4. Copy this line:
  5. Paste the line in the box at the bottom of the dialog:
  6. Click Done.

And voila! You now have solarized Dark colors in your Slack Sidebar:



#Agile2014 - Beyond Budgeting - an Agile management model for new business and people realities - the Statoil implementation journey (Notes)

Bjarte Bogsnes

You can be as agile as you want at your team level, but once your hit the enterprise level you will hit a wall. Scaling agile is hard, and scaled agile might not look a lot like agile at all.

Beyond Budgeting is a methodology to scale an organization without falling into the trap of a command-and-control culture.

Budgets are often a very bad yardstick for evaluating performance. Budgets and traditional management can be a big barrier to improving performance.

The Human Side of Enterprise teaches us that there are two theories of how people get motivated. Theory X and Theory Y tell us that people are motivated with strong control and rules (X) and people are motivated by being given power and freedom (Y).

Beyond Budgeting is all about moving your processes towards a dynamic style and your leadership towards a values-based system.

Statoil explains their system in The Statoil Book

Beyond Budgeting was pioneered by Handelsbanken back in the 1970’s

Beyond Budgeting is NOT no budgeting. You have to figure out how to allocate resources, but it is given a disproportionately large role in business.

A budget is a target, a forecast, and resource allocation. The first step is to separate budgeting into these three steps, and then focus on improving and optimizing each individually.

"Do I have the budget for this?" is the wrong question. Ask "is this really necessary?," "What is good enough?," "How much value is this creating?," "Is this within my execution framework?"

We want to move away from traditional detailed and annual budgets and towards a budget that increases autonomy and flexibility.

We want to make our decisions at the last responsible moment .

Simple is not the same as easy!

Moving towards a more dynamic mode is an attempt to simplify, but it certainly is not easy.



#Agile2014 - I don’t keep my code clean, I just turn the lights off! (Notes)

Scott Dillman

Hey you. Go read Clean Code by Uncle Bob. It is a good book!

You should care about keeping your code clean! It is important for your code to be readable, especially to other developers.

We spend 10x times READING others code, as opposed to writing code.

Messy code, a.k.a. code that is hard to understand and is poorly tested, slows us down. When you have to deal with that type of code you are much more likely to make mistakes. Ramp up time is longer when code is messy. All these factors make it hard for developers to add new business features.

Why isn’t your code clean? - “Good enough,” deadlines, “I didn’t write it!,” “I’ll clean it up later…” There are a LOT of excuses we, as developers, make for writing messy code.

"Management won’t let us do it" is NOT an excuse. If your manager is telling you how to do your work, maybe they should be doing the work.

Leave the campground cleaner than you found it.

Coding standards matter! Make sure that your team establishes a standard.

There are a lot of great refactoring tools in your IDE (IDEA and ReSharper are especially good), take some time to learn them.

Duplication is the enemy (in production code, not tests).

Delete your commented out code. Delete your unused code (you can find unused code with static code analysis).

Don’t abbr. your code

Naming matters, make names that make sense, are descriptive and understandable.

Include “good” comments. JavaDocs are good comments. Bad comments are comments in the code. Comments inside methods tend to be a code spell to extract a method.

Keep your classes small. Keep your functions small. Keep your features small. Keep your X small is generally a good rule.