What have I been learning lately/What Have I been reading lately (March/April 2018)

It’s been a while since I’ve done a blog post like this.

However, I’ve been busy and I have a few things to show for it:

Exciting Meetups Attended:

Projects That I’ve been working on:

    • Scala99
    • Temperature Sensor Data Generator
      • This is a utility project that will generate a series of data from sensors that closely resemble a day’s change in temperature.
      • This is to generate a large enough dataset to really demonstrate large-scale distributed processing
    • CQRS Framework
      • An extendable framework used to track events throughout a data object’s lifespan.
      • Using Shapeless
      • Currently on hold until I can fully wrap my head arround Shapeless
    • Sample Akka-HTTP Based Application for Inventory Pricing
      • This is a sample Akka HTTP Based application that responds to Time based requests for inventory.
      • Akka HTTP was a bit irritating to setup the routing.

Technologies I’m Learning Right Now

  • Apache Spark
  • The Play Web Framework
  • Amazon RedShift
  • Shapeless

Books Read:

Things I’ve Mastered/Dealt with Cooking

  • Sous Viding
    • Experimented with Octopus (They were a bit too small to get right, and this was done with Sous Viding)
    • The Perfect Steak and Crust on the outside
    • Dry Aging Ribeye Steaks
  • Keto
    • Lemon Bars
    • Tirmasu Fudge
    • I’m very close to making a stock

Books I’m Currently Reading

Topics I want to learn/read about

  • Optaplanner
  • More with IOT
    • I had a chance to work with a Seed WIO wifi based IOT board
    • I bought a Nano PI from FriendlyElec.
  • Cassandra
  • ElasticSearch
  • Going further indepth with Kafka
  • Akka Typed


Things I’ve been Learning This Week (13 April 15)

Just as a quick summary of the things I’ve been up to this past week:

  1. Reading:
    1. The Last Girlfriend on Earth (Fiction)
    2. Grails In Action-  2nd Edition (Great book btw) [I’ve read the first one, and like it. I’m loving this edition as that it’s more recent and includes the new toys that the later Grails and Groovy editions offer you]
    3. Soft Skills (Also a great book)
  2. paramValidFields within generated Grails tests is meant as something you’re supposed to implement yourself. (This intended to create params that are valid.)
  3. The Fixture’s plugin for Grails has a few quirks
    1. All of the fixtures, unlike in Ruby with the equivalent, are based on a DSL in Groovy (so you have more Groovy files in your projects, and those are compiled in)
    2. The Fixture’s plugin intentionally tries to create valid domain objects (based on your set attributes)
  4. The fairly ubiquitous class Expando is something you can use yourself. It basically allows for you to dynamically define and expand your class (as you would with Python or Ruby)
  5. DropWizard: This has been a little bit of a challenge to get setup and working. However from the looks of it, it doesn’t look too bad.
  6. Chipotle isn’t horrible, its also not horrible. (I’ve been a bit resistant as that it’s a chain and is owned by McDonalds).  On that front I’m still waiting for Nandos to come to Chicago.
  7. How to use a Mac. As a linux person: it’s disappointed me quiet a bit> It’s ridged, not so user friendly, for my purposes, and it has some strong unforgiving opinions about how you’re to use a computer. Would I buy one? Nope.
  8. Using Hibernate via the JPA Annotations (I’ve always depended on the HBM and the Generation afforded).

Awesome Projects That I’ve found Recently

After I started learning Python and Ruby I’ve started to find some interesting things.

  1. Automating Skype and MS Speech API with Python and PyWin32
  2. WkHTML2PDF (Webkit HTML to PDF)
  3. Opensource command line OCR Reader – Tesseract OCR
  4. The Bastards Book Of Ruby
  5. [Not Python or Ruby but once all of the bugs are gone, this will be awesome] Telesco.pe – Forum software in MeteorJS
  6. Ruby Version Manager – This is the only way that you should install Ruby

Two book reviews that were not done

This year, I haven’t blogged as much as I have previously. Things have kept me busy… However, in the world wind of all the things I’ve been up to… I forgot to write a recommendation/review of a few books.

Instead of boring you with the details on every item of the book I liked or disliked of it here are a few of the books that I greatly approve of:

  • DSLs In Action – Ghosh
  • Everything is Negotiable – Kennedy
  • 33 Strategies of War – Green
  • The Obstacle is the Way – Holiday

Are all technical books dry and boring?

After reading many technical books I believe that a trend has emerged: Most technical books tend to be varying degrees of being dry. This is starting to become incredibly irritating, it also hurts in keeping the readers attention. At the moment I don’t have a lot of justification to support why non-dry techincal book, however some of the most memorial books  have included silly examples, real world examples, and a non-referential tone.


So far the only books I’ve read that didn’t have a dry tone:

1. Test Driven Development By Kent Beck

2. Effective Java- Joshua Bloch

3. Head First For Design Patterns

4. Apache Wicket in Action – Martijn Dashorst

Whats on your bookshelf?

Recently, Tim Ferris did a blog post about the bookshelves of well-known individuals in the entrepreneurial/tech sector. By the end of the list, and after his own bookshelf, he listed some of the individuals’ bookshelves that he would like to see. His list included: Arianna Huffington, Elon Musk, Martha Stewart, Joss Whedon, and Cory Brooker.

I would like to see the following individual’s bookshelves:

  1. Joshua Bloch (The author of Java Puzzlers, Effective Java [I highly recommend this book])
  2. Martin Dashorst (Writer of Wicket In Action)
  3. Eddie Izzard (Multi-linguist, comedian, and actor)
  4. Vince Gillian (Writer of Breaking Bad)
  5. Charlie Brooker [He is a comedian, and columnist at the Guardian]


Apache Wicket [In Action]: A Review and How It Relates to the Java World

Java is a great tool for creating software. It is well designed, modular, has a wide array of platforms that it can run on, performs well, it’s very extendable, and it has a large community with lots of support. However, it’s support for websites and related services is severely lacking. It’s bad enough that frameworks that extend the existing infrastructure have massive pitfalls that you later discover.

For the most part Apache Wicket solves many of the web related issues that J2EE (JSP) has. If you are to follow the prescribed way of doing things, it can actually be quite pleasant. However, there are a few thorny patches with Wicket. I will get to those later.

Wicket In Action like a marriage. During the honeymoon, everything is great. Everyone is happy, and then later discontent grows and things go up and down. However, unlike a marriage, you don’t really get an ending. This is a rather good way to end things, but some of the lesser parts of the book were rather disappointing. One of the big selling points of Wicket is that it is a framework that assumes that the developer has already prototyped the pages in HTML prior to starting with Wicket [The pages are adapted into Wicket-ized and previewable pages]. This upside was enough to ignore the placement of the HTML files, in the class path rather than the web resources section.

I jumped into this book with lots of enthusiasm after reading the introduction. I even bore through some of the non-stated setup issues in the book. The book starts off by creating a project, from scratch, however I went the Maven route (which I discovered is the better way to go). The book mentions maven, but it doesn’t mention how to build your application or to generate a project. I believe that I went the correct way because Maven helped to setup all of the application servers and the folder structures. The book started by having the user to jump in, examine a few code segments, and then to start on a sample (full featured) e-commerces application. The store was oddly pleasant; the goal was to sell cheeses online. The application started from a few sample view pages, it went on to creating a reusable shopping cart, and finally on to a membership mechanism. This is a very straightforward and to-the point way of starting a new framework. It’s already addressing the needs of the majority of its audience.

Another nice thing to point out about the introduction is that it did not try to cover all of the material at once. It would frequently describe what you were doing, but would mention the chapter where the concepts were explained in depth later on. Something that pleased me was that the code listings did not include a listing number. They were place in the correct location of the text. After you’re done with the sample application, you should be quite proud of yourself. This is similar to your first website.

However, the book got a little disappointing when describing the more detailed interworkings of Wicket: sessions, bookmarkable pages, and layering/rendering. The book improves when it gets to the Ajax functionality and a brief mention of dependency injection and Wicket. The book gets a little rough in the Spring through Hibernate sections and then better in the testing section. The book ends in a rather low note on SEO, production configuration, and JMX. If I had known more about JMX, I would have probably had a better opinion of the ending.

Overall I am not sure if I can say that the less than stellar sections of the book were entirely the authors’ or the book’s fault. It quite possibly may be the technology’s fault.  I would strongly recommend the book if you are new to Wicket.

Lastly, here are some direct tips that I had to discover on my own that helped out a lot:


Review: The Java Virtual Machine Specification: Second Edition (Java 2 Platform)

Despite the age and subtitle. This book is still relevant for the Java 6 and 7 platform. The Java Virtual Machine Specification,by Tim Lindholm and Frank Yellin, is a specification book from a pre-Oracle time. The book goes over how the Java language is structured and designed. This is a great guide for any serious Java developer. The book provides insight on the reasons why things are designed the way they are, Java [assembly like] byte code, the classfile format, and a handy reference for the bytecode [including the op codes].

I read this book for non-professional reasons. It was more of a curiosity to read this book. At times, the book went into more detail than I cared about. Also, I skimmed over the documentation on the bytecode. However, I really did like that it introduced the detailed bytecode documentation and then followed it up with examples of how code is transformed into its related bytecode.

Reading this book should make Java Performance (Hunt) a bit easier to read, understand, and more interesting. That is when I can get to reading the book. At the moment, I have more than 30 [physical and non-physical] books on my reading queue.

Groovy in Action: A review

{{Groovy in Action}} is the book that I should have put down quite a long time ago. However, I did trudge through it. Most Manning Press “In Action” books do a good job at introducing basic concepts at the beginning, and then go into blinding detail near the end. “{{Hibernate [3.0] In Action}}” is a very good example of this.

However, “Groovy in Action” is annoyingly different.I have wanted to learn and use {{Groovy}} for quite a while. It’s a Java-based language, which uses the JVM, and comfortably interacts with all of your other {{Java}} libraries, and frameworks. With most books, which are responsible for introducing someone to a new language/framework, I expect the resource to really sell the language/framework in the beginning, and ease into the more gritty details. However, this book tried to do this at some points of the book, but lacked order.

The start of the book introduced the user into how to setup their environment and to create a few sample to get your feet wet. There was a very brief overview on what Groovy is able to do. However, after the brief overview, the book’s Part 1(pages 27-227) section becomes a reference book. Part two (228-451) started off nicely, but quickly became tiresome (mostly due to the strenuous task of the first part of the book).The third section was where the book really got interesting: going over how to apply Groovy to solve problems that you may run into. I liked the last section the best.

As a developer, my interest is in solving problems. I enjoy learning about advanced features and details of a language; however, a language/tool/framework is a means to solve a problem. If the tool/language/framework really piques my interest to use it more than once, I’ll go into more detail with it. This book would be better suited for someone that has already developed a strong interest, and would like a reference manual.

Review: “Test-Driven Development” by Kent Beck [The creator of JUnit]

It is always interesting to read a book about a technical topic from its creator. They tend to better identify the motivating factors and history that went into creating the product than other authors could possibly try. Kent Beck is the creator of JUnit, and happens to be the author of this book. The book is designed for people who are new to unit testing and Test-Driven Development. For anyone in the current software development industry, this is very few people.

The book is divided into three separate sections. The first being a walk-through with JUnit (by example), xUnit, and then a “best practices guide.” The JUnit section, the majority of the content of this book, is focused on developing a currency class. While there were some interesting design decisions, this part irritated me the most. The first section produced blatant errors, just to create a test that would fail. I would have preferred if these errors had been described rather than presented to the reader. The currency example was a good example, however adding another example would have been better. The xUnit section of the book focused on creating a test environment for Python. I am not a Python developer, but I have written a very small amount of code. I was not a fan of this section. However, I was pleased with the best practices section. The only issue I had with the last section is that I do not recall that the best practices section went into why the recommendations are better than what they replace. If my memory serves me correctly, it did not.

This is a great resource for developers who have never heard of TDD. It may even be a great book for students that have just completed half of a class in Java. However, it is not such a great book for people who have worked with Test Driven Development.  For those who have already worked with TDD, a Manning Press’s “In Action” series may be more suitable. Although their resource on JUnit looks to be a bit dated. Manning Press’s dated JUnit book includes information on integrations with other frameworks, which are slightly harder to test against [J2EE, XML, Servlets, EJB, DBs….].

In summary, I was probably looking for another book similar to “Pragmatic Unit Testing in Java with JUnit” (Hunt and Davis). Their approach was more focused on how to try to find trouble spots, and improve existing code.

Given that this was written in 2002, the following is not exactly fair criticism, but it should be mentioned by anyone that is claiming that TDD is beneficial. I would have liked to see more support [research/studies] on why Test Driven Development is beneficial. Every TDD-related article/publication/book that I have read always attempts to convince the reader that it’s necessarily with marketing-speak. The claim is that it is good for “high stress environments,” or it reduces defects. However, I have never seen evidence supporting the claim mentioned. I, personally, have found that TDD to be a significant improvement in development. However, I have never been able to quantify how much of an improvement it has made. What is the amount of time saved by TDD? Has it made today’s software more reliable than before? Has it affected the developer job market? [Increased/Decreased] Has it made the users of the products using TDD happier? Most importantly, has test-driven development reduced the stress of software development?