Tips on Traveling to Hong Kong

Recently, I took a trip to Hong Kong and there were a few things I would have liked to know about before going:

  1. 1The MTR (Main trains) are fantastic, and fairly cheap. The Hong Kong dollar is about about $7 HKD to 1 USD and many of the rides that you’ll need are around $15HKD each. What you’ll need to do is to get an Octopus card (It’s a value store system) at the airport after you leave customs. (Along with a SIM card) Make sure to put at least $250 on the card so that you can leave the airport express train.
  2. You have to wave down the bus that you intend to get on.
  3. Most places accept Visa cards, this is good, but make sure to bring cash.
  4. The food in Hong Kong is fantastic, and comparatively cheap. (You can get out of Bread Street by Gordon Ramsey paying less than 100$ USD.)
  5. See the Tian Tan Buddha on top of Nong Ping. Also, if you have the money, get the clear bottom cable cars. They tend to have less of a line to get on.
  6. Go to the markets and haggle. Never use your CC and bring a diverse amount of bills. Most of the places will give you a price and another “special price.” Always make sure that you counter, and meet in the middle. If you’re looking to buy multiple items, settle on a low single unit price, then ask for a discount for multiple. See the Youtuber Colin Abroadcast for examples on some of the bargaining.
  7. Stay in Kowloon. There’s no need to be in Hong Kong City. The train runs all night and it’s very fast.
  8. Connecting through the airport: The airport is a pretty efficient airport for transferring you though. Getting through security shouldn’t be a problem. (There is a special area for transiting and you don’t have to go through customs if you’re flying from one country to another in the airport).
  9. See the Peak Tram/Victorias Peak. But check before hand on the best times to go. This can be a very busy place.

 

You can Either Try or not (Scala: Try, Either)

One of the things that I recently discovered in Scala is Try and Ether statements. They’re extremely cool to work with!

To Try

In the order I learned about them, I’ll explain what a Try is. It is a method that wraps the incoming and handles all exceptions that come out of it. If an exception comes out of it the value that is represented by the Try will be returned as Failure([exceptionvalue]). If the result was a success then the object Success([result value]) is returned. Pretty cool right? This means you don’t have to setup a Try/Catch everytime that you have an exception thrown. Combined with pattern matching, this will allow for you to simplify your statements that have Try/Catches. Even better: Try:Success is an option.

An example of this is:

class demonstration {
  def getGoogleResults(keyword: String) = {
    var googleClientResult = null
    try {
      val googleClient = new GoogleClient(authKeys)
      googleClientResult = googleClient.query(keyword)
    } catch (exception: Exception) {
      System.err.println(s"Error: $exception")
      throw exception
    }
    System.out.println(s"It found   $ {googleClientResult.size}")
  }

  def getBetterGoogleResults(keyword:String) = {
    val googleClient = new GoogleClient(authKeys)
    val googleResults = Try(googleClient.query(keyword))

    googleResults.success.map(v => System.out.println(s"It found ${v.size}")
      googleResults.failure.map(e => {
      System.err.println(s"Error $e")
      throw e
    })
  }
}

The getGoogleResults method shows the Java style of doing this. The getBetterGoogleResults shows the shorter functional try way of going about this. It reduced a bit of boilerplate and made the code a lot easier to read. Something to note: success and failure coming off of the Try object are Options.

How does this work? (Either it does or it doesn’t)

Try is a case of a language feature called Either in Scala. Either is a way to return two possible non-common objects. In other words, you can return either a String or an Integer from a method. Either uses generics to type each case (the left or the right), and it handles the direction of what object that comes back.

Since there is a possibility of different types, it’s not possible to have a single method to get the results of the try. (That would be possible in Groovy!) You have to work with both possible types (as we showed with the success and failure responses in the example above). Luckily, the left and right values coming off of the Ether are Options, which makes this less painful.

Going back to the Try vs. Either reference: A try is and Either object defined as having a Success and Failure object. The other difference is that Try handles exceptions, and it has special names for success and failure added to the class.

References

Some of the things that I’ve been up to in the last few months (March-June)

Some of the things that I’ve been up to in the last few months:

  1. I saw Metallica for the first time a few days ago! That was pretty awesome. I would say that was either my third or second best concert that I’ve ever seen. The first best was Rammstein at the Open Air Festival last year.
  2. I learned about Try/Ether in Scala. That’s pretty awesome. Expect a blog post coming out about that
  3. I started doing the X Effect challenge for 50 squats a day over 49 days. So far I’m 40 days in and I’ve only missed 3 days. That’s pretty awesome.
  4. Wearing sunglasses when it’s sunny is a good idea. It helps to prevent your eyes from straining. I feel like I should have learned this a long time ago. Doh.
  5. I’ve been experimenting with turning my phone off while at work and during social events. This has helped my concentration and focus immensely. Although, it has been a learning experience with quick attempts to check the phone.
  6. I’ve taken a hiatus from side projects for the last 4 months. It’s been nice to have a life back and not worry about getting a huge project done.
  7. My parents came up to Chicago and we visited Davenport, IA. We got to see the Mississipi River. 
  8. I got a fantastic new camera: the Lumix LX10. I love the thing. It’s been taking some great pictures.
  9. I’ve recently started planting more house plants. I added more snake plants, bird of paradise, cactus, and an aloe plant. Outside: I replaced a large weed with an annual Lilly.
  10. I learned how to make side cars with the brandy that my friend Erik gave me for my birthday.
  11. I learned about how amazing Oaxacian tamales are. I had these at the Taste of Little Village Festival

I’m sure that I’ve been up to more, but that’s all that comes up to mind

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.