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


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

First Thoughts: “Coders at Work” by Peter Seibel

I’ve just started to read the book Coders At Work. The book is a nice, recent collection of interviews from many big name developers. I’ve read other developer interview books before, but this one sticks out in an unusual way: with most “interview” books, the interview is either completely boring or incredibly interesting. In Coders At Work, the interviews have varied between amazing and neutral. I haven’t gotten to a bad interview yet.

A few things jumped out at me and made me think. Jamie Zawinski’s interview made me wonder about the value of non formally-educated developers in “today’s market.” Brad Fitzpatrick’s interview reminded me of the “I’ll build everything,” but you “must know everything” attitudes. Douglas Crockford’s interview didn’t inspire me, but it did make me consider other issues within software development.

Jamie Zawinski’s interview was an amazing conversation about a guy who has many interests in learning and doing work. He is a self taught LISP developer who can occasionally get very opinionated. I found his work experience with Netscape fascinating. As a user of the early versions of Netscape, I never knew all of the politics or construction going behind the scenes. I also found it technically intriguing that the pre-3.0 mail reader within Netscape was not written in C++. I have a lot of respect for Mr. Zawinski for being able to identify a potential bias of his – he appeared very introspective when asked about hiring new developers. He understood that he could distinguish people that he could find reputable, but not those who would make good candidates.

One of the things that struck me as a bit off-putting about Mr. Zawinski was his rejection of automatic unit testing. I feel that if it was made as easy in the 90s as it is today, software would be VERY different today.

Brad Fitzpatrick’s interview left me with mixed feeling about the guy. I’m not sure if he is a guy you would want to work with, however he sounds like the kind of guy that you would want to share war stories with over drinks. He has worked on many interesting projects, mainly LiveJournal, and is one of the early “Growth Hackers {http://en.wikipedia.org/wiki/Growth_hacking}.” I like his recommendation that you should spend some time in reading other’s code. He fights the immediate urge to ignore others’ code and his approach sounds different from what I had expected: I expected his approach to making suggestions on other people’s code would be antagonistic. However, it was described as the following:

  1. Code copies are distributed to the audience – in digital and paper form

  2. The developer presents their code line by line

  3. Q&A time

  4. Suggestions / feedback from the audience

This struck me as different from my experience where code reviews tend to be either technically or personally antagonistic (or both). This approach was more similar to proofreading a paper you just made or audience-testing a book you just wrote.

The two things that really put me off about Mr. Fitzpatrick was one of the questions he asks in interviews, and the other is the insistence of knowing everything. Mr. Fitzpatrick’s “famous” interview/programming question was a recycled question from his “AP CS” exam. The question is to write a class that handles large number arithmetic (rewrite BigDecimal). It appears that he uses his previous experience as a baseline for evaluation. I also got the feeling that it is a way for him to “show superiority over others” (over something he did many years ago a high school student). Second, he is incredibly insistent over knowing everything about how every layer works. He ranted against high-level language developers because they didn’t know that a specific way of polling may not work on a specific deployment machine. He even ranted over those who deployed towards a VM because the VM’s “virtual”->native OS/hardware has been abstracted. I feel that in 98% of the cases he’s picking up pennies in front of a steam roller.

I was not very thrilled with Douglas Crockford’s interview. Primarily because it dealt with Javascript, it was a little too high-level for my taste. During the reading of this interview, my mind went back to Mr. Fitzpatrick’s interview. It made me wonder and realize about how you find the “best” tools. I find it incredibly difficult to keep afloat of all the languages and tools available. Recently, for example, I just learned how – and why – Git, Jenkins (plus the automated unit/lint/reporting/checkstyle plug-ins), and deep Maven knowledge are really good things to know if you’re developing in Java.

When new languages, tools, and frameworks come around, I love to read about them and learn how they work (if they’re useful and interesting enough). However, time is limited: how do you identify the tools that would solve the most pressing need you have?  Prior to Jenkins, I built everything via an IDE. Why would I need an automated build tool? I’m the only developer on the project. Prior to Git, I used Subversion – it did everything I needed. Why would I want to make “sub-commits”? Prior to Maven, why would I want to have the build tool automatically deploy the WAR file or require that all unit tests pass before generating an executable? (I’m running unit tests all the time anyway.)

Later it made me think about the code reading suggestion and I realized: I’m not very happy with the code review tools I know about. ReviewBoard looks nice, but that is for only for Ruby. Should I write my own? Where are the existing tools for Java (which can also integrate with Maven and Jenkins)? Are the tools good? Are there others out there that have solved this issue? Is it worth setting up a code review tool just for this? This are questions I’m not sure how to answer.

Overall, I really enjoyed that this book goes over many topics – personal projects, interview questions, and famous debugging stories. I do occasionally enjoy a story bragging how the developer’s language or tool was miles ahead. However after reading about their accomplishments in a serial fashion, it just gets old. Perhaps interspersing their accounts in a more conversational form would have made this book more interesting, and easier to recommend.

Similarities of the individuals who were interviewed:

  1. All have a strong focus on one particular project

  2. Each interviewee has worked in many companies

  3. None of them focused on the reputation of the company they have worked for

  4. All have interesting debugging stories

Why I’ll buy more Logitech Wireless mice

If you’ve read much of my blog, I tend to be a bit more critical rather than rewarding. It’s human nature, the negative emotions/experiences tend to be amplified more than the positive ones. However, I feel that I must mention my experience with the Logitech wireless mice. I first bought a Bluetooth wireless mouse and I had a horrible experience with it. The battery would last 1-2 weeks at most. However, a friend of mine owned a m325 [which has its own custom wireless protocol and adaptor]. From my experience, I have never had to change the battery that comes with the mouse, and it’s been nearly a year now.

Recently, I have moved and one of the USB micro adaptors broke. I bought a new mouse and found out another one of the mice got lost. [I previously had two] It turns out that the adaptors are easily reprogrammable with the “Logitech Unifying Connectors.” Although this software is for Windows/Mac only, this is slick. Additionally, you can program multiple keyboards and mice to one adaptor.

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.

Part 2 of 2: How To Make Your Life Easier As A Tech Worker (IT/Software Engineering/System Administrator): Motivation

The lack of motivation can affect your work and personal life severely. These are some of the things I found to be helpful:

  • Having a daily status. This helps you to understand what needs to be done, what needs to be done later, what problems you faced, and helps communicate what you’ve been up to with your peers/clients/superiors. Good daily statuses answer the questions:
    • Did you have any roadblocks today?
    • What did you do today?
    • What is on your task list today?
    • Also I find that its incredibly helpful to finish the daily status prior to leaving for the day and reviewing the items left to do in the morning when I get in. Once the daily status is reviewed it is incredibly easy to focus and knock out tasks.
  • Daily statuses may help you get a raise or help to establish job security. Daily statuses can help you to support your claims of higher pay due to work performed. With a daily status, your manager can go back through them and see work performed, and it’s easier to account for your work. My coworker uses this template. [As mentioned in the last part of this series].
  • Plan out the tasks that need to be performed prior to starting them. If you have a task to build a twitter clone, breaking the tasks into extremely small tasks such as evaluate database, create test interface, create authentication system, etc would be a good way to go about it. Reviewing prior to the start of work is the way to go about this. With a good understanding about the tasks to complete, it becomes incredibly difficult to procrastinate or avoid working. The tasks are easily achievable and you have something to show for it, even when the work isn’t incredibly visible.
  • Organize similar tasks in batches. I’m sure Tim Ferris wasn’t the first person to suggest this, but I found this tip from one of his books. If you have lots of individual tasks that have the same process, collect all of the tasks and perform all of the actions in a batch-like fashion. For example: If the task is to go to the store every time you need something, consider creating a list and going to the store to get all of the items at once. This will cut down on the costs (time, money, and stress) involved with driving to and from [his example was batching bill paying].
  • Monitor your time – this may be an extension of the daily status suggestion. Monitoring your time helps you to identify times where you may become unproductive or easily distracted. It also helps you identify the amount of time that you can work until you need a break.
  • Weekly self reviews – this involves a bit more time. A weekly self review can help you see the big picture of the tasks that you performed that week, and may even change your mind about the approach taken. For example, if you repeatedly struggled with a Java GUI component every day of the week, a weekly review would show that a different component might be beneficial or that it might be helpful to go for training on the individual component.
  • Clear out your email box. Similar to a cluttered desk, a full inbox makes emails difficult to search through, and may cause new emails to be lost.
  • Keep a notebook or journal. New ideas rarely come when you want them to. Keeping a physical notebook helps you to write the ideas out without becoming distracted with what you’re working on. Also, a physical notebook acts as a unique outside task from your current job. It’s similar to “Rubber Ducking” the problem. Roald Dahl suggested doing this, too – he kept a notebook and wrote down every idea he had for a story as soon as it came to him (even using the dust on his bumper once when his notebook was missing).
  • Keep A Blog: Blog about the problems you’ve faced and how you overcame them. For example, when I had an problem with a particular issue with my Gentoo configuration, I wrote a blog post after going through the trouble of finding a solution and testing many others. When I ran into the same issue again when re installing  the solution now was quickly available to me. Google picked up the post and made the search even quicker. Also, it may turn out to be an issue that others have faced. If your blog is fairly popular you may even get feedback, or kudos for solving the problem that others have had.
  • Writing down expectations/concerns about tasks. This may sound silly, but writing down the potential negative feelings you have towards a technical approach may help you overcome biases or aggravation down the road. http://life-sucks.org/negative-thoughts
  • Keeping a task list. Creating/using a task list will give a quick feedback on completing tasks. Use an online to-do manager that can schedule tasks, organize them into projects, and can integrate into your existing PIMs [Outlook, Kontact, Gmail+Calendar]. Some examples of this are doit.im, trello, vitalist, Toodledo, Nozbe, and Nirvana for GTD.
  • Keep track of things you want to learn. This helps when you have free time during work and want to learn something. Also, learning new technologies helps you with new tech projects and makes you more marketable.
  • Read Regularly. This may not be directly beneficial to completing the problems you face today, but this is more of a multiplier. It helps you to branch out from your current set of problems, and find new solutions. Blogs, RSS feeds, technical books, and most other books will help keep you motivated and productive.

Suggestions for Authors of Technical Books

If you are writing about something that has to be installed on the reader’s machine there has been something that has become annoying. Please do not provide distribution based instructions for installing the software/component/framework. I would prefer it if this was listed on the book’s website, or linked to the platform/distribution’s website. In place of the section, I would prefer a brief history of the component that the book requires. For example, if the framework’s API was forked from another project, if the API would have been motivated by particular problems, and/or who uses it.

Having a website for the installation and configuration would allow it to be updated when the software gets changed. For example, if there was a major break in the API usage, the website could be updated and the user could be warned against using future versions.

CrossOver Linux Professional

I’ve been using  [Gentoo] Linux as my primary OS for quite a few years now. I like it. It helps me work, the way I want to work. The only downside to being this committed to using Linux is the lack of a good office suite. Yes, there is LibreOffice, KOffice, and was OpenOffice. However, from my experience those don’t offer nearly the nice experience that MS Office does.

This is where Crossover Linux comes in. I hate sounding like a marketing tool for a company. But this is a product I’m glad I paid for. It has saved me many headaches. Crossover Linux is a tool that basically turns Wine into apt-get/portage/yum, but for Windows binaries. On top of that, there is the support and innovation that wine doesn’t give you right out. Without Crossover office, to install MS Office you’d have to modify your wine environment many times, grab and install the dependencies in a sorted order, and then finally try [and possibly fail] at installing MS Office. That was depending on which guide you’re looking at. With Crossover Office, to install MS Office just open the wizard to install software, create a new bottle, and tell it that you’re installing MS Office, provide the installer files and it does all of the hard work for you. Crossover even finalizes the install by setting up the nice menu items in the K menu, and in your file manager.

Another neat feature that it has is bottles. Basically it creates sandboxed environments for each application. You can have your Steam install files separate from MS Office, or WoW files. Yes, I did say it runs steam. CrossOver office is just $50 for 6 months of free upgrades, and you get email support.

If you want to save quite a lot of time, and remain productive on Linux, get this product. Lastly, by supporting this company, you support their effort to give back to the Wine project. Their employees regularly release their changes back into the Wine project.

Review: “Fooled By Randomness” by N. Taleb

{{“Fooled by Randomness”}} is a book about the negative consequences of a dynamic financial market. More specifically, the book’s focus is due to the lack of a balance criticism of the potential negative outcomes and the evaluation of performance in the market.

There are some main features of the book that could be considered to be strong points. One of them being the topic of the book, compared to the neighboring books in its genre. The book attempts to debunk the hype surrounding popular strategies as being luck rather than an effective strategy. Another strength this book accounts for is randomness. It mentions that randomness may account for many successes that individuals attribute to events. Lastly, I must commend the author for advising the reader to stay out of short term markets. Short term markets are highly volatile and are not for individuals who cannot afford a loss.

Despite the redeeming qualities, “Fooled by Randomness” has a fair amount of distracting and vexing issues. Mainly the issue is with a personal bias. The author speaks with the reader in parts of the book and brags about how everyone is foolish not to see his point of view. For example he describes a radio debate, in which the radio host is talking with him about how a market downfall caught investors who had not properly considered the risk. His retort in the book was that he had been warning “these investors” for years.  This strikes me as rather off putting and ineffectual to put in the book. Assuming he has been issuing warnings, shouldn’t one consider the lack of response as an indicator of ineffectuality’s in communication?

Halfway-through the book I started to wonder: “Who is the target audience of this book?” Earlier in the book, while he is bragging, it’s obvious that he is targeting serious day traders and employees of investment groups. However, later in the book he attempts to debunk the effectiveness of these people. For example:  For brokers he claims that the people with a history are merely people who had gotten lucky. For analysis, they were merely lucky that history had a tendency to repeat itself. For academics, their work was really only good for the time period that they were in, and that it was too little too late (complex systems researchers).  I was quite shocked about his dismissal of Complex Systems Researchers. Typically Complex Systems advocates promote the idea of randomness influencing the system, and they can account of it.

Lastly, this book leaves me with the question:

If people are able to consistently make money on the market, then how do you successfully evaluate performance? His arguments attempt to ignore performance and claim that everything is merely luck.