I’m asking for your help. (About this Summer)

The Youtube Casey Neistat inspired me with his recent video on the beginning of Summer.

This made me think. How can I make this summer the best that I have ever had.

A quick list for me came up to:

  1. Go out swimming in Lake Michigan (I haven’t done that in the last 4 years that I’ve been here)
  2. Rent a Jet Ski
  3. Visit a state that I haven’t yet. (Michigan will probably be it)
  4. Fly to somewhere new (I’m tempted to come out to Austin)
  5. The x-effect with meditation (Maybe?)
  6. Grill out an absurd amount.
  7. ….

But here is the challenge that I’m putting out there for everyone reading. What are some things that I could do to make this summer the best ever?

Please leave the comments below.

Something I love about the builder pattern

It makes the construction of similar objects a lot easier.

For this example, let’s assume that a ComplexPerson object represents a human that has parents, and has attributes such as age, name, etc.

ComplexPerson.Builder jimJaneFamily = ComplexPerson.builder().getParent(jimReference,janeReference);

To create new children from the same template, you would just use the builder “jimJaneFamily” object, adjust the new attributes and call build. A new builder object isn’t necessary as that the modifiable fields are overwritten and the builder is no longer relevant after the build method is called. Reusing the builder object looks a lot cleaner compared to new initializations per new object.

That’s pretty cool.

What I learned from my trip to Costa Rica and Panama

I had quite a vacation 2 weeks ago. I went to Panama City, Bocas Del Toro and Costa Rica. I learned quite a few things and had a lot of negative experiences that I’ve never encountered while traveling before.

I went to Panama without having a good working of knowledge of Spanish. This was a good and bad thing as that it meant that I had to learn fast to survive. All of the places I went were amazing. It was incredibly sunny and everyone was laid back.

Some of the issues I encountered:

  1. My sunscreen (Coppertone SPF70, bought new) was completely worthless (And deemed so by my dermatologist)
    1. This resulted in an extremely bad sunburn that I’m still getting over today. (The redness not the painful burning and other symptoms)
  2. My electronics failed.
    1. My phone’s screen broke mid-trip by falling onto gravel. Note: Cellphone repair shops in Costa Rica don’t hold Google phone glass and screens. It’s just not a popularly held phone.
    2. My camera had issues with the buttons inside of the electronics. That means that I could only shoot with manual mode. Also, Nikkon seems not to be interested in making cameras anymore. So buying a new point and shoot in Panama wasn’t an option.
    3. My credit card just completely broke. (The card, not account issues). Unfortunately this happened in a place where the mail doesn’t work.
  3. The sun burn that I got completely put me out of doing anything while in Costa Rica. This was rather unfortunate but it means you should give yourself time to heal.
  4. Companies who sell aloe products generally suck. They should be required by law to report how much aloe is in the product. Only the pharmacy provided me with a 100% aloe product that helped the bad sunburn that I had.

Some of the things I learned/realized:

  1. Buying a replacement phone with the internet while travelling helped a lot. It seemed like a “large” ($60) extra unneeded expense, but it helped a lot when trying to find things and navigating.
  2. Always carry backup forms of payment. I’ve travelled to europe with only a debit card and some spare cash. I was lucky that I had both forms for payment. Also, carry the local currency in different places in your luggage.
  3. If you’re going to be in extreme direct sun (at the equator) Sunscreen with zinc oxide is a must.
  4. I should have carried a much better first aid kit than what I had.
  5. I got an offer for a $99&$129 first class upgrade for my flight back. The $99 offer I got for the SJO-IAH flight was worth it. I wish I had taken the $129 offer for IAH to ORD as that it was a lie flat seat. Also, if your checkin is failing when you get this offer, do what I did: Call the airline and get it resolved. (Thank you United!)
  6. The general advice I got from fellow travels is to pack for one week’s worth of travel. (And wash while you’re there) That would have lightened the load I had by a lot.
  7. The people in Costa Rica and Panama were extremely laid back, but things still work. You don’t have to be aggressive with following up with everything.
  8. Google Translate is terrible to converse back and forth with. Complex sentences don’t translate very well. (I found this out when trying to buy a bus ticket from Panama City to Bocas more than 1 day in advance)

Will I go back to Bocas del Toro and Costa Rica? Absolutely! I will probably even go back to Panama City.

Response to: Quality vs Quantity and the Ceramic Art Students

I’ve seen the following snippet copied and pasted quite a few times on Hacker News:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

From: https://blog.codinghorror.com/quantity-always-trumps-quality/

Of all of the Hacker News comments that I’ve seen that quoted it: They’re attacks against others who claim that you should consider quality when developing software. The problem I have with the claim and the quote is that it completely misses the point. The context of the quote involves unskilled learners that are trying to build an understanding and get practical knowledge for the subject. Within that context, quantity has a lot of value. The students are developing hands-on learning, building muscle control/memory, and are applying their knowledge.

Another issue I have with the quote is that it never states what this quality was. Was it still at the student level? Was it sellable?  Also, the quote doesn’t account for: What did the students learn? What would they do differently? The goals of education are different from the goals outside of education.

As a professional software engineer, you are paid to produce professional quality software. Completing tasks to show that you completed task demonstrates that you can close tickets. It produces no evidence that you can deliver quality software. That’s the same with any engineer. Build 20 bridges, in which a couple fall, you’re going to be considered to be a bad bridge engineer. Also, all your previous work is going to be put in question.

I realize that the knee-jerk response to the previous statement is: “But Steven! Over engineering is bad, the business is going to fail because it can’t deliver/you can’t deliver like that/you have to have the experience to produce stuff and that comes from quantity.”  To address those see:

  1. Business is going to fail: There was poor planning and over promising done here many times over. Blaming the tech team for over-promising is trying to pass the blame along. Software takes time, we’ve got decades of experiences to illustrate this. If quantity were the ultimate winner, we wouldn’t have unrealistic deadlines.
  2. You can’t deliver like that: You can. You have to start with quality early, do the appropriate planning, and write software in a way where you can reuse existing code. Code reuse of quality code gives exponential returns. Sloppy code gives exponentially losses. You can’t turn around quality code later after most of the code is based on sloppy, unreliable, and untrusted code.
  3. You have to have the experience to produce stuff, and that comes from quantity: That statement is a bit of a strawman. Write the software, test it, and ship the code. Just don’t try to ship everything and then go back to try to rewrite everything because you didn’t do your due diligence the first time. Also, I never made the statement claiming there was no forgiveness for misunderstandings before. When you go back, and you went with quality first, the reason you went back to the code from before is that you realize that there was a misunderstanding. (Not because you just wanted to finish it early). The extra benefit is that you learned something.

From “The Zen Of Akka” By Konrad Malawski: Protip: Logging Formatting

I was watching the Zen Of Akka by Konrad Malawski, when he came across an interesting tidbit.

When writting out to log files, use the {} formatting options rather than string interpolation. If you’re doing debug logging, and it’s turned off: No formating is done. With String interpolation, the string is formated prior to executing the method.

That was something that I never really thought about, but he’s right!


My Christmas Wishlist For Groovy/Java/Scala

This should be an ongoing post until Christmas. These are the things I’ve been wanting to see in Java/Groovy/Scala. (Tooling wise/language/etc)

  • Better support/integration to show what lines of code haven’t been tested
  • Visualization of code execution within Threads.
  • A consistent templating solution to generate projects. (Maven needs a good cleaning on the templates)
  • Better organization of available libraries (Github repositories like awesome-java/groovy exist.. but they’re not great)
  • Better support for highlighting inefficient and duplicated bits of code.
    • I.e. For loops having a suggestion to use Lambdas
    • Searches for logic that is often repeated, and suggestions for refactoring hotspots.
  • PMD and findbugs does this sometime. But it would be nice to encourage library creators (Commons or Guava) to create Findbugs/PMD rulesets.
  • A basic starting template for standard applications, REST Apps, or Web apps
    • Should include testing, cucumber, the right plugins, etc
  • Lazy evaluation keyword in Groovy. (You can do that right now, but that relies on closures. In Scala, there is a lazy keyword.
  • Groovy: Lazy evaluation on collections (Built into the collections)
  • Groovy: Case Classes for Groovy (We’re close to it, but it’s not as concise)
  • Maven: Composable POMs
  • Scala: Better support amongst versions, and better support in Gradle to handle the Scala version to
  • Postgres/Hibernate: Support for dynamic data structure expansion.
    • This is handy when you have an extra column that is of type of JSON or HStore)]
    • Think of a weak MongoDB-like ability for dynamic documents, but the explicitly define structure of a Postgres SQL database
  • Scala: Support for Scala only libraries that don’t involve bundling the Scala runtime. (These would be compiled into your project)
  • All libraries: More distributing the API interface separately over the implementation (This is necessary for avoiding transitive dependency conflicts.)

“I wanted to like _______, but….”

I’ve been guilty of this. It’s a trite phrase that lends nothing but negative feelings and projects the image of “unpolished opinions.” The phrase: “I wanted to like x, but…”

I’ve used it in many of my Yelp reviews and probably a few reviews on this blog. I even knew it was bad at the time. I just didn’t understand why or what to say instead.

What should I have written?
I should describe the things that I attracted me to the place/thing. I should describe what my expectations were.  Then I should do a turnabout and describe why they didn’t match my expectations.
Once you get out the reason for why you were persuaded in a particular way, then you can evaluate if those initial reactions were even valid, or if the thing/place was as deceptive as you found it to be. In short, it’s nothing but descriptive writing. You’re not writing about an action that took place, nor are you writing a story. It’s all descriptive writing: it’s about your experience with a situation. I think I feel into this trap as that school re-enforced me to use descriptive writing only as a means to be a substitute to frozen visual imagery, rather than a possible re-enforcement of describing a situation.

I would like to say Thanks to the software Grammarly. It was the Grammar as a service based tool that pointed out awkwardly worded phrases and unnecessary statements that made my writing unclear.

Things I’ve learned so far this week (6 Dec)

It’s been a very long time since I’ve done one of these. So I thought I’d share. Not all of this was learned in the last week, but in the recent past.

  • When you do port forwarding with SSH, the default binding address for the forwarded port is This is a security feature that prevents that port from being used by outsiders.
    • If you want to expose this, enable the configuration GatewayPorts in the SSHD configuration
  • Groovy has special DSL support for Cucumber. It makes writing cucumber steps easier and simpler to manage environment hooks
  • The obvious one, but rarely done in practice: Creating a POC in code is a lot better to get your core logic working than building out a full app and trying to make decisions later.
  • Bash: Substring extraction is possible in a very concise and easy manner. (Like most things in Bash, there are magical characters for that) It makes sub-arrays possible.
  • Bash function parameters are errrr different. Unlike most C-like languages, they define them by an array index than a variable name. (I.e. $1, $2, …)
    • You should define your local variables in your function near the top
    • All variables are global unless you declare them as local in bash


  • Magic shows can be pretty cool (Thanks, Michael Carducci! [NFJS])
  • I need to see more firebreathing shows. (Rammstein included lots of fire displays)

Secure Services – It’s not just for REST or SOAP anymore

A note: I meant to write this blog post for years. I am finally knocking this blog post off of my todo list. Hurray!

In the beginning, there was the terminal, and it was great. After networking had come around, the terminal was networked and called telnet. It was thought to be good but later realized to be a disaster when people realized it was not secure. Then there came the secure shell which was a secure wrapper around telnet. Later the features for SSH expanded into:

  1. Port Forwarding (used as a jump box/service)
  2. Proxying network traffic
  3. X11 forwarding
  4. Secure shell environment
  5. Key based authentication
  6. Secure File Transfer (SFTP)

There are a lot of different uses of SSH and how you can configure it to do some pretty extraordinary things. That is something that would be out of the scope of this blog post. A great reference on SSH can be found in this book.

One of the features that caught my attention is that it is possible to create services that are purely in the Unix environment and are incredibly secure. The attack surface is small, communication is encrypted, and that your environment is sandboxed (well as much as you make it).

Authorized Keys

Passwords are incredibly low effort to unlock a system. They tend to be short, and they can be brute forced. (Even worse, they frequently have a small space of combinations as that they are human chosen). Randomly generated keys with lots of bits were created to avoid this issue. This was added to SSH to add in passwordless login and to avoid sharing passwords as well. All of the public keys are stored in the user’s authorized_keys file.

Within the authorized_keys, each entry has the following format:

<key encryption used> <public key> <comment>

Within each line, it is possible to extend the features (shell, a command to run, environment variables, etc.) of that particular login. (See the man page for more details)

To build a secure service, use the command variable. You will see in the section labeled your first secure service for an example.

The setup

  1. To setup an account, you are going to need a private key. Generate that with ssh-keygen without a password. (You can use a password, but it will make automation tough)
  2. Add the entry into the authorized_keys file. (~/.ssh/authorized_keys) With the ssh-copy-id command (ex. ssh-copy-id –i [location of your private key] [user running the command]@[server]
  3. Your ~/.ssh/authorized_keys file should have entries similar to the following:
    1. cat ~/.ssh/authorized_keys
    2. ssh-rsa A……..iJu+ElF7 steven@server
      1. See the section Authorized Keys section for an explanation of what this means.
  4. Test the access to the service by sshing into the box under that user and with that key. (Sample command: ssh –i [private key] user@server
    1. The first time you connect to a server with SSH you are going to get a message asking if it is ok to connect to a particular box. (This is something you need to do if you are automating a process as well)

Your first service

Your first service will be an incredibly simple example. Open up your authorized_keys file that was modified from the setup section. Add in the following command in front of the ssh-rsa/dsa line for the new entry.

command="echo hello the time is `date`"

The line of the login should now look similar to the following:

command="echo hello the time is `date`" ssh-rsa A.......

Now you can make a call to the configured service as such:

ssh -i .ssh/id_sitetest steven@localhost

You will receive an output of:

hello the time is Fri Nov 11 22:28:37 CST 2016
Connection to localhost closed.

Congratulations, if you followed along with the previous instructions: you have created your first secure service. All of the input communicated to the service and coming back from the service is encrypted. You have control over the format that is output and how you are going to take in input. The beauty of this service is that a terminal is not left open, and only the command that is defined is run. Once the command is done, the session automatically closes.


How should one best develop services?

You should develop a bash script to replicate the functionality that you would like the server to perform before setting it up to run in SSH. This gives you an isolated environment to test the process and to test it before it goes live. The SSH service setup is merely a layer above the script.

How should I get input into the service?
To do this, you would need to take in input just like how you would in a bash script. I would suggest using the ‘read’ command to do this. See this guide.

A note on this: Always validate the input. Attackers are unlikely (assuming that the key is managed properly), but it never hurts to

Is it webscale?

Honestly, I do not know the answer to this question. I guess it is possible to do this via the web, and I am not sure how stable it would be with lots of concurrent users. It is at most as scalable as the SSH service and system.

I did a brief search to see if this was possible in javascript on the client side and I could not find a source to show that it was possible.

Can you automate the use of these secure services?

Yes. However, when you create the key, you should never add a passphrase as that requires manual interaction. A word to the wise, keys should have a required live cycle and should be phased out periodically. Key management will be an issue in this situation.

No Fluff Just Stuff October 2016/Chicago

My workplace sent me to No Fluff Just Stuff to attend the conference. Some of the interesting bits about the conference were:

  • Garbage Collection in the VM
    • Lead to the following questions
      • If there a way to do leak testing in unit tests? (VC++ provides heapdump checking and you can do it there)
      • Where is the memory indexed at?
      • Is it possible to modify the code cache?
    • Ken Sipe is a great speaker and I managed to have lunch with him.
  • Tracer Bullet architecture
    • Advocates slow development (make sure things work on a smaller scale before escalating higher)
    • Some redefining the existing development change process, and some parts naming work patterns.
    • Advocated for many of the circuit breaker/fault resistance that was already baked into Akka
  • LAMBDA Architecture
    • Mostly advocated in a more efficient datacenter using Mesos/DCOS.
  • Metaprogramming and AOP programming with Groovy
    • This was a great talk on how closures can take in state
    • Went over some basic built up on extending the language through Abstract Syntax Transforms
  • Encryption/Security
    • Mostly reviewed encryption algorithms and briefly talked about exploits
    • The talks on the exploits were interesting
    • Oddly enough, the conference talked a lot about the Heartbleed bug.
      • Sidenote: The events and context surrounding this bug are very strange.

Other notes

The conference loaned out conference ipads to keep notes on and rebroadcast the sessions. I found this to be similar to having a laptop in the classroom. Mostly it just led to distraction.

Things I would have liked to see more in the conference

  • Talk some about Scala
    • There were many mentions of Groovy, but other than the Metaprogramming/AOP they were just mentions
  • Discuss things like Akka or new methodologies
  • Try to avoid boilerplate talks on Spring
  • Label the sessions as Intro/Intermediate/Advanced