Install Oracle Java8 on Ubuntu

This is a summary of the steps I did to install Oracle Java8 on my laptop running Ubuntu 16.10 (Yakkety Yak). I used the PPA repositories provided by Wepupd8 and specifically referred to this very detailed post.

Please note that most Linux distros recommend openjdk as the default Java platform.  However, there are some products that specifically recommend Oracle’s JDK for their products.  I had one such product to install for my work and had to install Oracle’s JDK.

So here we go. Here are the main steps with the commands further below…

  1. Add webupd8’s PPA repositories for oracle java.
  2. Install Oracle Java.
  3. Set Oracle Java as the default.
  4. Verify that Oracle java is set as the default JVM.


Add webupd8’s PPA repositories for oracle java.

$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt-get update

Install Oracle Java. Do note that you will have to accept the binary license during the install, so stay there.

$ sudo apt-get install -y oracle-java8-installer

Set Oracle Java as the default.

$ sudo apt-get install -y oracle-java8-set-default

Verify that Oracle java is set as the default JVM.

$ java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) Server VM (build 25.111-b14, mixed mode)

If you see the HotSpot server VM being output then you are good. Finally, cleanup the unneeded stuff

$ sudo apt autoremove

Additionally, you may want to set the JAVA_HOME environment variable. Some products need this environment variable. To do this, enter the following line as the last line in ~/.bashrc file. Of course, this assumes you are using BASH as your shell. If you use some other shell, like fish or zsh, then check appropriately how to set JAVA_HOME permanently.

$ file `which java`
/usr/bin/java: symbolic link to /etc/alternatives/java
$ file /etc/alternatives/java
/etc/alternatives/java: symbolic link to /usr/lib/jvm/java-8-oracle/jre/bin/java
$ echo "export JAVA_HOME=/usr/lib/jvm/java-8-oracle/jre" >> ~/.bashrc

So that’s that. You should be all set now.


SBT, Scala, and “Hello, World!”

I am learning to program in Scala these days and plan to put up some random posts about it here.  Here I want to put up the instructions about how I installed Scala, through the Scala Build Tool (SBT), and how I got the hello world program working.  I used CentOS as the operating system.  So you might want to check parallel instructions for your specific operating system.

Installing SBT

I used the RPM packages to install SBT.  Briefly, the steps were as below.

$ curl | sudo tee /etc/yum.repos.d/bintray-sbt-rpm.repo
$ sudo yum install sbt

If it went well SBT should be installed at /usr/bin/sbt.  You can check the version of SBT installed using sbt about.

$ curl which sbt
$ sbt about
[info] Set current project to hariharan (in build file:/home/hariharan/)
[info] This is sbt 0.13.12
[info] The current project is {file:/home/hariharan/}hariharan 0.1-SNAPSHOT
[info] The current project is built against Scala 2.10.6
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.6

The Hello, World Program in Scala

Let us create a quick and simple “Hello, World” program here.  A more formal program with the recommended directory structure comes in the next section.

$ mkdir hello
$ cd hello
$ vi HelloWorld.scala 

Write the hello world code in this file.

object HelloWorld {
  def main(args: Array[String]) = println("Hello, World!!")

The command sbt compile will compile the code and sbt run will run it.

$ sbt compile
[info] Set current project to hello (in build file:/home/hariharan/work/training/scala/hello/)
[info] Updating {file:/home/hariharan/work/training/scala/hello/}hello...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Compiling 1 Scala source to /home/hariharan/work/training/scala/hello/target/scala-2.10/classes...
[success] Total time: 132 s, completed 15 Oct, 2016 10:51:30 AM

The command sbt run will execute the hello world program.

$ sbt run
[info] Set current project to hello (in build file:/home/hariharan/work/training/scala/hello/)
[info] Running HelloWorld 
Hello, World!!
[success] Total time: 1 s, completed 15 Oct, 2016 10:51:55 AM

Restructuring into the Correct Scala Directory Structure

In real-world Scala projects, the source code would be arranged in a more structured format than placing all files in a single folder.  If not other folder structure is defined, SBT assumes the conventional folder structure as recommended by Maven.  Let us now re-arrange the earlier hwllo-world code into the conventional form expected by SBT.  This should look as below:

|-- build.sbt                      # Build definition for the project
|-- src                            # all source files go here
|   |-- main                       # production source files and resources go under this folder
|   |   |-- resources
|   |   `-- scala                  # Scala source files go here
|   |       `-- HelloWorld.scala
|   `-- test                       # test source files and resources go under this folder
|       |-- resources
|       `-- scala                  # Scala test files go here
|-- target                         # all compiled and downloaded binaries go here

Now build and run again

$ sbt compile
[info] Set current project to hello (in build file:/home/hariharan/work/training/scala/hello/)
[info] Compiling 1 Scala source to /home/hariharan/work/training/scala/hello/target/scala-2.11/classes...
[info] 'compiler-interface' not yet compiled for Scala 2.11.8. Compiling...
[info]   Compilation completed in 18.884 s
[success] Total time: 150 s, completed 15 Oct, 2016 11:43:38 AM
$ sbt run
[info] Set current project to hello (in build file:/home/hariharan/work/training/scala/hello/)
[info] Running HelloWorld 
Hello, World!!
[success] Total time: 1 s, completed 15 Oct, 2016 11:44:05 AM

Set up Version Control

We have the basic Hello world program working in the right folder structure.  Let us commit this into a Git repository now.

First, move to the root folder of the project.  Then create a .gitignore file so that git does not track the target/ folder tree.  Finally initialize a git repo and commit all files.

$ echo 'target/' > .gitignore
$ git init
Initialized empty Git repository in /home/hariharan/work/training/scala/hello/.git/
$ git add .
$ git status
# On branch master
# Initial commit
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#    new file:   .gitignore
#    new file:   build.sbt
#    new file:   src/main/scala/HelloWorld.scala
$ git commit -m "First commit of the hello world project in Scala"
[master (root-commit) ed1500f] First commit of the hello world project in Scala
3 files changed, 11 insertions(+)
create mode 100644 .gitignore
create mode 100644 build.sbt
create mode 100644 src/main/scala/HelloWorld.scala


Origins of Lean Software Development

The intention of this post is to briefly touch upon the development up to the Lean Software Development movement starting from the very origins in Toyoda. This post may touch upon many words, concepts, and principles but provide no detailed explanations. The intention is to produce many other posts that will explore the details of Lean Software Development.

The Beginings

Sakichi Toyoda, the founder of Toyota, owned the Toyoda Loom Works that manufactured fully automatic machines for the textile industry. His machines had one of the earliest implementation of what would later become the concept of Jidoka (a.k.a stop-the-line or Autonomation in Lean manufacturing). When the machine encountered any little problem it would stop and signal for the weaver to fix the problem.

The origins of Just-in-time (JIT) Production

Sakichi Toyoda was joined by his son Kiichiro Toyoda and they together grew the loom business profitably. Kiichiro Toyoda later diversified into automobile manufacturing by founding the Toyota Motor Corporation in 1937. The new company soon hit into manufacturing restrictions placed on passenger cars during the second world war. After the war the restrictions were lifted but the American automobile industry (Ford and GM, specifically) had surged way ahead through their huge factories and mass production models. There was little Toyota could work conventionally match such competing economies of scale due to the following factors:

  • Lack of land and finances in post-war Japan prevented building of huge factories
  • Lack of natural minerals and other natural resources
  • High unemployment

These compulsions led Sakichi Toyoda to vision a “Just-in-time production system” that was based on Jidoka,  understanding the whole, respect for people and Kaizen (continuous improvement). He set a vision and challenged employees in his company to implement this and catch up with the American competition.

The Toyota Production System (TPS)

Taiichi Ohno, an employee of Toyota Motor company and the Toyoda Loom Works before that, responded to the challenge. He was a shop floor supervisor in the engine manufacturing shop. He studied the US automobile industry, especially Ford, and used the experience from Toyoda Looms to perfect a production system that incorporated Sakichi Toyoda’s vision of JIT, Jidoka, and Kaizen. This he called the Toyota Production System which he defined as a system to absolutely eliminate all waste from Toyota’s automobile manufacturing process. He defined 7 types of Muda (waste) for this purpose that ought to be eliminated:

The 7 types of wastes in a production system

Delay, waiting or time spent in a queue with no value being added Unnecessary movement or motion
Producing more than you need Inventory
Over processing or undertaking non-value added activity Production of Defects

The basic principles of the TPS system are listed here:

1. Kaizen

Challenge and understand the whole, Genshi Genbutsu (go to the floor and observe to understand the problem first hand)

4. The right process will produce the right results

Kanban (Visualize a pull based workflow), Heijunka (level the workload), JIT, Jidoka, standardize, transparency

2. Respect

respect for people, teamwork

5. Add value to the organization by developing your people and partners

Develop exceptional and committed people, grow leadership at every level, respect partners and suppliers

3. Long term philosophy

Management must have a long-term view while making decisions

6. Continuously solve root problems to drive organizational learning

Genshi Genbutsu, Nemawashi (make decisions slowly but implement rapidly), Hansei (become a learning organization) and Kaizen


The Spread of TPS

Shigeo Shingo was a consultant specializing in factory management. He worked closely with Taiichi Ohno to deploy the TPS in Toyota. He later took the TPS and implemented it in various Japanese companies. Some of his books, especially the English translation Study of the Toyota Production System (a.k.a The Green Book) of his Japanese book, brought the TPS to the shores of America. He added the concept of quick assembly/re-assembly of machines (also called SMED) to produce various parts in the speed demanded by a JIT production system. His other notable concepts, added to Taiichi Ohno’s definition of TPS, was about Poka-Yoke (mistake-proofing the system by designing it to eliminate root cause of defects and making mistakes impossible to occur) and zero quality control (no need to examine results).

In the US, several researchers who studied the TPS expanded the 6 principles to 14 as listed below:

1. Establish customer-defined value to separate value-added from waste 8. Fully integrate suppliers into the product development system
2. Front-load the product development process to explore thoroughly alternative solutions while there is maximum design space. 9. Build in learning and continuous improvement
3. Create a level product development process flow 10. Build a culture to support excellence and relentless improvement
4. Utilize rigorous standardization to reduce variation, and create flexibility and predictable outcomes 11. Adapt technologies to fit your people and process
5. Develop a chief engineer system to integrate development from start to finish 12. Align your organization through simple visual communication
6. Organize to balance functional expertise and cross-functional integration 13. Use powerful tools for standardization and organizational learning
7. Develop towering competence in all engineers.

The Lean Production System and it’s Spread

During the 1990s, the TPS became famously known as the Lean Production System largely due to the book The machine that changed the world. Within Toyota, The Lean Production system also acquired other counter parts over time – The Lean Supply Chain (to extend Lean to suppliers and partners also), and The Lean Product Development System (to extend Lean to the product development process also).

Lean Software Development

Outside of Toyota Motors, the Lean Manufacturing system were adapted into services and IT forming the Lean Services and Lean IT respectively. The Lean Software Development adapted Lean manufacturing, Lean Services, Lean IT  to the software domain and merged them with the Agile principles and practices.. This was designed by Mary Poppendieck and Tom Poppendieck based on their experiences in Software development and implementing Lean in their manufacturing industries. It contained 7 principles and 22 tools or practices.

The 7 principles of Lean Software Development are listed here.

1. Eliminate waste 5. Empower the team
2. Amplify learning and create knowledge 6. Build integrity/quiality in
3. Decide as late as possible 7. See the whole
4. Deliver as fast as possible

The 22 tools or practices are listed here.

1. Seeing waste 12. Cost of delay
2. Value stream mapping 13. Self determination
3. Feedback 14. Motivation
4. Iterations 15. Leadership
5. Synchronization 16. Expertise
6. Set based development 17. Perceived integrity
7. Options thinking 18. Conceptual integrity
8. The last responsible moment 19. Refactoring
9. Making decisions 20. Testing
10. Pull systems 21. Measurements
11. Queuing theory 22. Contracts


  1. Lean Software Development: An Agile Toolkit by Mary Poppendieck et al.
  2. Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck et al.
  3. Lean Software Development – A History
  4. The Toyota Production System

Book review: Outliers

This is a cross-post from my other blog – A day in the circus – with some changes.

I first heard the word Outlier in the context of statistics. Wikipedia defines it thus

In statistics, an outlier is an observation that is numerically distant from the rest of the data. Grubbs defined an outlier as: An outlying observation, or outlier, is one that appears to deviate markedly from other members of the sample in which it occurs.

The book applies this word in the context of achievers. Continue reading

The fifth principle behind the Agile manifesto

The fifth principle of the Agile manifesto states

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Too often, we have read that people are an organization’s greatest asset. We have read that the success of the organization can be tied down directly to how motivated and focussed are the people working in it. It is repeated by the leaders in every organization every so often that it can now be considered a cliché. Despite the overuse, it is utterly true that people are indeed an organization’s biggest asset.  It is therefore not surprising that the Agile Manifesto justifiably founds its philosophy on this assertion. Indeed, the success and failure of Agile in an organization can be tied to how well this particular principle is realized and implemented. Continue reading

The fourth principle behind the Agile manifesto

The fourth principle of the Agile manifesto states

Business people and developers must work together daily throughout the project.

Many many years ago, I was part of this offshore maintenance project for around 2 years. During the first year, we were a team of 3 – a project manager (PM), a technical and documentation lead (TDL), and a developer(DEV). I was the DEV. The PM had to interact with the client in getting new requirements, change requests, defects and prepare a plan for them. The TDL was in-charge of conducting feasibility studies, preparing implementation proposals and relevant  documentation. The DEV had to implement it. I guess you can already understand the problems with this setup.

Continue reading