Showing posts with label java. Show all posts
Showing posts with label java. Show all posts

This Week I Learned - 2016 Week 17

Write-up for last week or you might want to read the whole series.

Busy week, didn't follow up with anything else. Nothing but reading and writing papers.

Being a developer after 40? (HN thread) Are you too old for development? Nope. While general consensus is that if you over 35, you should either be in the management, start your own company, or be a consultant. But why you want to move on to something else? There is still so much to learn. Have fun, rest well, and keep yourself healthy. The first post of the discussion may shed some lights on the actual reason why organization are reluctant to hire more experience (often correlate with age) developer.

Learn a new technology each week in 2016. Awesome weekly project! Unfortunately, most of the project are written in Scala. Not that I've something against the programming language, but I've painful and dreadful slow experience setting up both Scala and Play framework. The main culprit is sbt, the interactive build tool. The number of dependencies to be downloaded in order to get sbt to work is so painful huge is like you're downloading the whole Internet. Furthermore, you really need a powerful development machine to do any development work in Java-based platform.

Pandoc (the universal document converter) with Markdown is awesome. But no one still can solve the annoying problem of making it easy to create a simple table. 

Why isn't Perl more popular? Reasons? Perl is a glorified AWK. The TMTOWTDI motto. Osborne effect of Perl 6PHP, the simplified version of Perl took over the web and dethroned Perl. No killer apps (like Rails for Ruby or WordPress for PHP).

PlantUML

PlantUML is always my go-to diagramming tool whenever I need to understand and document any existing legacy system. Two things I love about this tool. First, you can generate any UML diagrams from mere textual description. Meaning that, plain text file is universal format and easy for version control as well. Second, you don't need to worry about layout but focus on the modelling and let the program decides on that.

Below is some notes I've jotted down while trying to set it up in a new machine. I believed it was around June 2015 but I've updated it for Fedora 24 (Rawhide).

Installation.
$ sudo dnf install plantuml graphviz java-1.8.0-openjdk

If you want to get the latest pre-compiled PlantUML version, then you've to run it manually.
$ java -jar plantuml.jar -version

For those installation through distro's repository, there exists a shell script, '/usr/bin/plantuml' that set up all the necessary JAVA environment details for you.
$ file `which plantuml`
/usr/bin/plantuml: Bourne-Again shell script, ASCII text executable

Since PlantUML is using Graphiviz as its renderer, we need to verify that PlantUML can detect it.
$ java -jar plantuml.jar -testdot
The environment variable GRAPHVIZ_DOT has been set to /usr/bin/dot
Dot executable is /usr/bin/dot
Dot version: dot - graphviz version 2.38.0 (20140413.2041)
Installation seems OK. File generation OK

Another way is to check our PlantUML version.
$ java -jar plantuml.jar -version
PlantUML version 8027 (Sat Jun 20 18:13:59 MYT 2015)
(GPL source distribution)
OpenJDK Runtime Environment
OpenJDK 64-Bit Server VM
1.8.0_45-internal-b14
Linux

The environment variable GRAPHVIZ_DOT has been set to /usr/bin/dot
Dot executable is /usr/bin/dot
Dot version: dot - graphviz version 2.38.0 (20140413.2041)
Installation seems OK. File generation OK

Go generate our sample diagram with verbosity set (useful for detecting issues).
$ java -jar plantuml.jar -verbose sample.txt 
(0.000 - 117 Mo) 114 Mo - PlantUML Version 8033
(0.074 - 117 Mo) 113 Mo - GraphicsEnvironment.isHeadless() true
(0.074 - 117 Mo) 113 Mo - Forcing -Djava.awt.headless=true
(0.074 - 117 Mo) 113 Mo - java.awt.headless set as true
(0.085 - 117 Mo) 113 Mo - Setting current dir: .
(0.085 - 117 Mo) 113 Mo - Setting current dir: /home/hojimi
(0.087 - 117 Mo) 112 Mo - Using default charset
(0.093 - 117 Mo) 112 Mo - Setting current dir: /home/hojimi
(0.099 - 117 Mo) 112 Mo - Setting current dir: /home/hojimi
(0.100 - 117 Mo) 112 Mo - Reading file: sample.txt
(0.100 - 117 Mo) 112 Mo - name from block=null
(0.728 - 117 Mo) 93 Mo - Creating file: /home/hojimi/sample.png
(0.776 - 117 Mo) 90 Mo - Creating image 121x126
(0.812 - 117 Mo) 90 Mo - Ok for com.sun.imageio.plugins.png.PNGMetadata
(0.860 - 117 Mo) 89 Mo - File size : 2131
(0.861 - 117 Mo) 89 Mo - Number of image(s): 1

The textual description of 'sample.txt' that produces that UML diagram.
$ cat sample.txt 
@startuml
Alice -> Bob
Bob -> Alice
@enduml

Android Java

"Android - really the biggest reason today why anyone besides the enterprise guys cares about Java anymore - is well down this dark dark road as well. It’s increasingly common to read a page of Android API documentation and have no idea what the fuck it’s talking about initially. You get there eventually of course, you just have to take a detour through 17 other classes. What, you can’t handle that? You obviously lack the perseverance and vision to conceptualise this grand cathedral that has been built to populate a list. Loser."
-- Neil Sainsbury, additional emphasis added.
You have to agree that Java still relevant today due to the popularity of Android. Otherwise it will headed to the same fate as Cobol or 4GL as well, in the enterprise world.  But off course, Enterprise Java and Android Java are two different beasts.

Java, the Predictable Language

"Java is neither a good nor a bad language. It is a mediocre language, and there is no struggle. In Haskell or even in Perl you are always worrying about whether you are doing something in the cleanest and the best way. In Java, you can forget about doing it in the cleanest or the best way, because that is impossible. Whatever you do, however hard you try, the code will come out mediocre, verbose, redundant, and bloated, and the only thing you can do is relax and keep turning the crank until the necessary amount of code has come out of the spout. If it takes ten times as much code as it would to program in Haskell, that is all right, because the IDE will generate half of it for you, and you are still being paid to write the other half."
...
"So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product. It was pleasant to not have to worry about whether I was doing a good job, or whether I might be writing something hard to understand or to maintain. The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands."

-- Mark Dominus, Why I Like Java (emphasis added)
Not sure he being sarcastic or stating the truth, but the predictability of Java is why this language triumphs in the education sector and in developing Enterprise software. Not to mention heavy marketing and evangelism when the language was first introduced. Furthermore, "nobody ever got fired for picking Java".