South By…A First Timers Perspective

Last weekend I got to attend SXSW for the Interactive portion of the conference/festival (SXSWi).  It was also my first time staying at an AirBnB.  I can say both experiences were very memorable and awesome.

Every programmer/software engineer/coder/developer should go to South By at least once because it is truly a unique experience.  I haven’t been to many conferences but this one straddles the line very well between party/festival and conference.  There are probably 100 sessions a day, including lectures, panels, meetups, hackathons, Q&A and competitions.  For the interactive portion, there is a healthy mix of developers, graphic designers, UX people and app developers.  There are so many sessions that looking at the schedule feels like drinking from a fire hose.  Since there are so many sessions, you are free to choose your own adventure.  Don’t like the talk you are at, leave for another session.  Met some cool people after a talk, join them for a drink or at their next session!  There will be many sessions that you will want to attend that are going on concurrently.  Most venues are within a 10 minute walk of the Austin Convention Center which makes it very walkable and easy to get around.

Everyone from the speakers to the volunteers to the organizers, preach about the “hallway magic” that occurs at South By.  They encourage you to leave your friends and try to meet new people.  They encourage you to note the sessions you’d like to attend but to embrace the serendipity of South By – you never know who you will meet and when you will meet them.  At the start of the festival I was a bit timid in meeting people, but by the last day I was arriving at the convention center with nothing to do for 2 hours and just heading to a phone/laptop recharge lounge to chat with random people.  I was even going to the parties at night by myself (first time going to the bar by myself) and trying to meet as many new people as I could.

SXSW is really what you make of it.  You can party from 11am to 1am every day.  Or you can attend sessions from 9am – 6pm and not party at all.  You could even arrive without a official badge and enjoy all the free stuff and network.

My favourite sessions I attended:

• Hackathon for Social Good – got to meet some cool people and do some work!
• Elon Musk Keynote – loved his no bullshit attitude, his humility and bravery
• 100 Mistakes from contributor to CEO – Meebo cofounder Elaine Wherry – so engaging and learned a ton!
• Next Gen Entertainment Entrepreneurs – Vhx.tv, slated.com, blcklst.com – Panel discussion on breaking through Hollywoods barriers

I know I did it right because I wouldn’t really change anything about my trip.  I had a great time.  Now for a list of tips:

1. Don’t hang out with your friends – put yourself in a situation where you have to meet new people
2. Know that you can’t get to everything and be okay with that
3. Drink lots of water because you will be consuming more alcohol than you think
4. For most parties RSVP doesn’t get you anything – I used rsvpster but I didn’t use it once to get in….I still don’t get why they make you rsvp. (I still will probably RSVP next year just in case)
5. You will be disappointed by how bad (or not what you expected) some sessions are and surprised by how good some other ones are – be flexible with your schedule

See you in SXSW next year!

Advertisement

Every Software Engineer Needs Rules To Code By

As software engineers, we make lots of decisions on a daily basis.  It is definitely a skill that you can develop and improve upon.  From my experience, you get much more practice at this skill in a startup.  You get to build a lot of new software with not much guidance.  Many times you need to pick the technology/library/etc before you even start developing a solution.  I feel my decision making has improved tremendously in the year that I have worked for a start-up.  There are many ways you can improve your decision making ability.  One helpful mechanism for decision making, is having a set of rules that you live (design/code/test/implement) by.

Every software engineer should have a set of rules they live by.  Most developers have 0 rules when they finish university and start their first job.  The main reason for this is that we “gather” new rules through experience of screwing things up.  And I am referring to those bugs or time wasters that really cost you or your company time and money.  In school, you usually aren’t working on large pieces of software or mission critical features.  You also don’t own code for a substantial period of time usually.  So you don’t carry the burden of bad code or see the result of bad decisions.

The typical scenario goes something like:

1. Create and release some feature
2. Something very bad happens. (e.g. bug costing thousands/millions, spend 3 days debugging a problem, spend 3 extra days refactoring, etc)
3. You fix it.
4. You think to yourself, how do I not let this happen again.

There are a ton of other ways it happens, but from personal experience this is the most common scenario.  So people amass rules depending on the experiences they have had.  Very rarely do we learn from someone else’s mistakes.  One of my favourite quotes:

“Smart people learn from their own mistakes.  Smarter people learn from other peoples mistake.”

I think these rules are important to have because they help prevent mistakes and make decisions easier.  The less questions you have to ask yourself, the less decision fatigue you will experience.  Leave your decision making power to the more difficult decisions.

Without further adieu, some rules off the top of my head.

1. No code change should go untested.  No matter how small or trivial.  I don’t mean unit test every single line of code, but see it work.  Too many times I decided not test something because it was too small or trivial.  Then subsequently it broke in testing or production and I looked really dumb for not performing a basic test.  I have seen this happen to other engineers as well.  It usually is painfully obvious that no testing was done.
2. Don’t try to predict the future.  I have spent too much time thinking of what might come next when developing certain features.  I have been burned implementing extra features (feature creep) and then throwing it all away anyway because the system was going to be used in the way I foresaw.  This is especially true for marketing oriented organizations as they tend to change their mind a lot.
3. When you can’t decide, just pick a route and go from there.  I used to spend a lot of time comparing 2 different approaches to a problem.  Often there wasn’t an obvious winner and I would spend too much time splitting hairs.  Now, when I realize that I am doing this, I pick a solution and go from there.
4. Have more than one solution.  I read somewhere that having only one idea is dangerous.  Too many times I have implemented a feature only to have a co-worker suggest a different (more logical) approach which had me scrap half my code.  Now I try to think of these before I start designing.
5. Behave as if things will go wrong.  I know this is on the “glass half-empty” side, but this sort of thinking has helped me.  How many times have you finished writing a piece of code and went to run/test it and it worked first try?  You will start to ask yourself valuable questions such as; how can this break? If it breaks, how will I know?  how will I debug it?

These are a few that I have learned and wanted to share.  I am still early in my career and I am sure this list will grow!

Make your RSpec tests better

Below is a (non-exhaustive) list of good practices that I developed when writing my RSpec tests.

1. Use context blocks a lot.  TIP: Write your context blocks first and then fill in the tests.  It helps re-use and organization.

GOOD:

context "campaign has locations" do
  context "when locations < 10" do
    ...
  end

  context "when locations >= 10" do
    ...
  end
end

BAD: (notice double context block, doesn’t promote code sharing because you need to setup the same scenario multiple times. Also if someone modifies the code, they will have to modify in multiple places)

context "campaign has locations" do
  context "when locations < 10" do
    ...
  end
end

context "campaign has locations" do
  context "when locations =< 10" do
    ...
  end
end

2. If you have too many context blocks, that MIGHT mean you need to refactor your method to smaller methods.

3. Make sure that cases belong to their proper context block:

BAD:

context "campaign has locations" do
  context "when locations < 10" do
    ...
  end
  context "when locations >= 10" do
    ...
  end
  context "when locations = 0" do #<--- BAD (should be outside context)
    ...
  end
end

4. Write unit tests for single methods first.  You can skip for small “trivial” methods and include tests for small methods in the calling methods.  Worry about integration last.

5. I usually write unit tests will full stubs to verify input and output.  I might throw in a few tests to test the interaction and method chain.

6. Make sure you DON’T writes tests that test other components. Assume dependent components are written correctly and stub them out.  Good example of this is for external APIs.

7. Make sure your test breaks if you make it false.  I can’t count how many times it hasn’t for myself.

8.  For loops, I usually write a test case to make sure everything happens correctly for 1 iteration.  Then I have a test case to test for n (usually between 2-5) iterations.  TIP: extract the entire contents of the loop into its own sub method.

9. In your before block, if you are testing a certain condition on an object.  Explicitly set that, and don’t rely on Factory defaults:

BAD:

context "when campaign budget is NULL" do
  before do
    @campaign = Factory :campaign   #factory sets campaign budget = nil
  end
end

GOOD:

context "when campaign budget is NULL" do
  before do
    @campaign = Factory :campaign, :budget => nil
  end
end

The Ruby Way == Idiomatic Ruby

Almost 1 year ago, I joined a great start-up Thinknear (acquired by Telenav).  From a software engineer’s standpoint I did a complete 180 in the direction I was heading (outside of the fact that I was dabbling in Project Management at my old company Vistaprint).  

My previous company, Vistaprint, was a .NET shop for the most part.  I worked with C#, VB.NET, ASP.NET, IIS and MS SQL Server.  When I joined Thinknear, it was completely different.  We used Java, Ruby on Rails, Heroku, Apache Tomcat, Memcached, etc (the list could go on for awhile).

Anyways, I took learning Ruby to heart.  It had be awhile since I learned a new language and it was quite different than anything I had done before.  As I mentioned in earlier posts, I started from the ground up with tryruby.org.  I had about 3 weeks between knowing I got the job and starting the new gig (mainly because I had to transfer my visa).

I remember my boss (if you can call him that on a 3 person dev team), told me you can always spot a new Ruby person who came from an OO language.  It was hard for me to understand at the time, but now I get it.  I feel I am in a position to help the Ruby new comers.  So I want to introduce you to the “The Ruby Way” (a.k.a “Idiomatic Ruby”).

When I first started at Thinknear my code reviews were painstaking.  My teammates didn’t let up in learning Ruby and they made sure I would do everything properly.

The one thing that helped me the most was writing done every non-idiomatic mistake I made on code reviews and made sure I looked over the list before I submitted to GitHub.  I made very few mistakes more than 3 times, which believe me…was a HUGE step up from where I was coming from.

I am only 1 year into Ruby, but I am loving it!  It is a very natural and concise language.  It also helps you focus on the core algorithms and problems instead of a lot of other nuances in other languages.  I will be soon be ready to read my Metaprogramming in Ruby book, which will be fun and probably mind bending.  But here are my list of Ruby/Rails Idioms that I learned early on (low hanging fruit):

1. Ruby Style Guide – essential if you want to contribute to projects
2. Your best friend which you will be using a lot: http://ruby-doc.com/
3. Your best friend which you can try anything: irb
4. Do not use for i = 0; i < array.size, i++ etc…. use iterators!
   • Iterate over each element array.each { |element| puts element }
   • Iterate over each element, but transform each item: array.map { |element| element + 1 }
   • So many cool iterators: select, reject, inject
5. Do not use array.length > 0 or array == nil
   • array.present? is the bomb! It checks for nil AND to see if there are any items in the list (Rails only) – this also works for hashes
   • Checking for nil on any object? Use object.nil?
   • Checking for emptiness? array.empty?
   • Opposite of empty? = array.any?
6. Worried that something might be nil? try is your friend! Especially useful for hashes: Instead of hash.has_key?('missing-key') && hash['missing-key'] == value you can use hash.try[:[], 'missingkey') == value). Try will return “nil” if it can’t return anything.
7. Need the opposite of a condition? Do not write if !condition ... end , but instead use unless! unless condition ... end
   • Bonus points for writing conditionals on single line: do_something if condition

That is all I can think of, but I wanted this to be short and sweet and introduce some glaring Ruby newbie mistakes.  There is so much to offer in the language and I hope you have as much fun as I do!

JUL vs Logback vs Blitz4j

Over the last little while I have been trying to improve the performance of our java web app running on Tomcat.  Over the past 2 days, I decided to test our current logging framework against a few other competitors.  There are many blog posts about which is the fastest but nothing beats your own testing!

We current use SLF4J which is great because it makes exercises like this one much easier.  It basically allows you to plug and play many java logging libraries without changing any code (you just need to add certain JARs to the classpath).  Our current implementation uses java.util.logging (JUL) a.k.a JDK14 logging.

Our goal: Find the fastest java logging framework that can be switched to in < 2 days of effort.  We operate in a very low latency environment where speed is everything.

Contenders: JUL, Logback, Bllitz4j (not log4j b/c of reasons below)

If you poke around “common knowledge” on the internet is:

– Most people use log4j

– Logback is 10x faster than log4j

– Blitz4j (Netflix’s improvement to log4j) is 3x faster than log4j

So going into the experiments I was expecting to see Logback or Blitz4j to come out on top.

The real problem was that I couldn’t find any articles that compared (and the reason why I wanted to post this article) JUL logger to other frameworks.

So I setup a dummy endpoint that would flex all the logger muscles, nothing too complicated as below. (the idea is the same, some syntax for the loggers had to be changed a bit)

logger.debug("Debug Message");logger.info("Info Message");logger.warn("Warn Message");logger.error("Error Message");logger.trace("Trace message");logger.error(aShortString);if (logger.isDebugEnabled())  logger.debug("Debug Message With Check");if (logger.isInfoEnabled())  logger.info("Info Message With Check");if (logger.isWarnEnabled())  logger.warn("Warn Message With Check");if (logger.isErrorEnabled())  logger.error("Error Message With Check");if (logger.isTraceEnabled())  logger.trace("Trace message With Check");logger.error(aLongLongString);

I deployed my app to an EC2 host (m1.large) running on Apache Tomcat 7.  Versions were:

– JUL 1.4, LogBack 1.0.9, Blitz4J 1.18, SLF4J 1.7.2

For our performance testing we use JMeter.  I used both JMeter and Cloudwatch to gather the timing metrics.  I used 4 JMeter hosts which each had 3 threads making requests, so I could make sure that the logging framework could handle concurrent requests well.

Below are the results and as you can see, JUL took the cake!  I definitely didn’t expect that to happen and it was by a large margint the victor!  Since I didn’t test just plain old Log4J, I didn’t test the claims by Logback or Blitz4j.

A. Average request time (single iteration per request)

• JUL 1.4 – 5 ms
• Logback 1.0.9 – 15 ms
• Blitz4j 1.18 – 18 ms

B. Average request time (100 iterations per request)

• JUL 1.4 – 761 ms
• Logback 1.0.9 – 1412 ms
• Blitz4j 1.18 – 1267 ms

 

Anyways, thats all.  It was just a small test but I was very surprised to say the least.  I know Netflix’s library can probably take a lot more load than this, and might not have been a fair comparison.  Looks like we will be sticking with JUL for the short-term unless something comes up that warrants a switch.

VisualVM Profiling Apache Tomcat through SSH Tunnel

So I had the job of trying to setup profiling of our Apache Tomcat instances on EC2.  There were a lot of instructions out there that I tried to cobble together for a solution.  The tricky part with profiling on a remote host are the firewall rules, since the RMI server will pick a random port to use.

The method I used was to open an SSH tunnel to the running machine and pretend like everything is local.  I finally got my monitoring up an running so wanted to share.

Props to Thiago for having a nice write-up which had details that many people ommitted.

1. First download the proper version of the catalina-jmx-remote.jar from the apache archives.  We were running on 7.0.23 so I downloaded: (you can just change the version on the link below)

http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.23/bin/extras/

2.  Copy the JAR to your Tomcat’s lib dir.

3.  Open server.xml in Tomcat’s conf dir (mine was /opt/tomcat7/conf/server.xml) and add the following listener.  You should have a group of Listeners in the file already so just add to the bottom:

<Listener className=”org.apache.catalina.mbeans.JmxRemoteLifecycleListener” rmiRegistryPortPlatform=”10001″ rmiServerPortPlatform=”10002″ useLocalPorts=”true” />

– The two ports listed here are arbitrary (you can pick your own).  By specifying both ports, you set which ports the RMI server uses instead of the server arbitarily picking them.

– IMPORTANT: Many walkthroughs for SSH tunneling forget this part.  You need to set this to true.

4. Add the following params to startup:

-Djava.rmi.server.hostname=localhost

-Dcom.sun.management.jmxremote

-Dcom.sun.management.jmxremote.authenticate=false

-Dcom.sun.management.jmxremote.ssl=false

– Many walkthroughs on the net tell you to set the “java.rmi.server.hostname” variable to the public IP.  But since we are using SSH tunneling this should be localhost.

 

5. Restart Tomcat and check to make sure that your Tomcat instance started with the params from step 4: ps -aux | grep tomcat

6.  Also verify that its listening on the 2 ports from Step 3: netstat -nlp

7.  Now you should be ready to connect with Visual VM.  Drop catalina-jmx-remote.jar into the VISUALVM_HOME/platform/lib directory.

8.  Create a SSH tunnel on BOTH ports.  Sub in your EC2 instance (and potentially change the user)

ssh N -L10001:localhost:10001 -L10002:localhost:10002 ec2-user@<EC2 public ip>

– Many instructions on the web only tell you to use 1 port, but you need both.

9.  Start VisualVM.

10.  Right-click on Local and and add a new JMX Connection and use the following service URL:

service:jmx:rmi://localhost:10002/jndi/rmi://localhost:10001/jmxrmi

 

– Notice that the ports must match up with the ports you specified in Step 3.

And that should be it!  You should now be able to profile your application.

 

 

Remote Java Profiling on EC2

Had to do some profiling and there are a bunch of articles strewn across everywhere, so thought I would help the cause for people trying to find them. 

Props to Mriddle: http://rukuro-blog.heroku.com/2011/07/26/running-visualvm-through-an-ssh-tunnel

Another good article by Neil Figg: http://neilfigg.blogspot.com/2011/07/remote-jvm-profiling-on-amazon-ec2.html

I didn’t use Neils because I didn’t need to go deeper in my profiling at this stage.  I ran into a bunch of gotchas which Mriddle helped with and some comments:

1.  Create an SSH tunnel and make visual VM proxy through that:

– sudo ssh -i .ssh/yourkeyfileifyougotone.pem -D 9696 your.ip.goes.here

(options to add to jvisualvm)

-J-Dnetbeans.system_socks_proxy=localhost:9696 -J-Djava.net.useSystemProxies=true)

2.  Command to check if jstatd is listening:

sudo netstat -nlp | grep jstatd

3.  Look at startup command for tomcat

ps aux | grep tomcat

4.  VisualVM looks at temp directories for process info, so make sure that you start jvisualvm and specify the proper temp dir (you can see it from step #3):

(option to add to jvisualvm)

 -J-Djava.io.tmpdir=/opt/tomcat7/temp

 

Things that I read but didn’t work/didn’t try:

1.  Make sure the java bin you are using matches that on the remote server.  Apparently, there is a difference between the jre java bin and jdk java bin.

 

2.  Open the proper ports after your instance comes up on EC2.  Since jstatd picks a random port, you need to add the port to your security policy.

 

ec2-authorize <security_group> -p <port> -s <your ip>

 

My env on EC2:

OpenJDK Runtime Environment (IcedTea6 1.11.4) (amazon-52.1.11.4.46.amzn1-x86_64)

OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

Linux version 3.2.12-3.2.4.amzn1.x86_64 (mockbuild@gobi-build-31003) (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) )

Apache Tomcat/7.0.23

Locally:

VisualVM: 1.6.0_33 (Build 110613); platform 110613-unknown-revn

Mac OS X (10.7.4) , x86_64 64bit

1.6.0_33; Java HotSpot(TM) 64-Bit Server VM (20.8-b03-424, mixed mode)

 

After Lynda.com Ruby Essential Training

After reading around for the best way to learn Ruby and Ruby on Rails I found many people advocating for people to get a better grasp on Ruby.  So I decided to try the Ruby Essential Training on Lynda.com.  I paid $25 for the monthly subscription, which I think is well worth it.  I figured I might be able to try the essential Rails training.  It was listed as beginner but I thought I would do it anyway.  I didn’t get the exercise files and you definitely don’t need to upgrade to premium for the files for this one.

My review:

1.  Very basic introduction mainly aimed for non-developer.  As a developer who has done a bunch of tutorials, I was able to skip by at least 50% of the material (through fast forwarding).  

2.  But Kevin does talk a lot about “gotchas” and special cases that I tried not to miss by fast forwarding.  These were probably my biggest takeaways from the course.

3.  I wish he would have had a larger piece on the “yield” keyword.  I imagine he didn’t because it is a beginner lesson, so probably fine.  I feel I know it decent enough but won’t fully appreciate it until I see it many times.

4.  The project at the end was the best part.  I learned a lot by trying to implement the methods before he did and seeing the differences.  Since he implements them in the “traditional” Ruby way, I started to learn on how things are usually done.  I think this will be the biggest learning curve for me.  I decided I am going to try to implement some other libraries and compare my code to real Ruby devs.

5.  Kevin explains everything very well and goes step by step.  He does things in different ways to show you how it can be done and never assumes anything.  As a teacher, he is awesome!  He shows you things the long way first so that you know what is going on underneath the covers.

 

Some things I learned/neat tidbits:

1.  The || operator for null assignments x = y || z (similar to ?? in .NET)

2.  Ruby Constants start with a capital letter.  They CAN be changed but you will get a warning.

3.  splat operator (*) turns a range into an array

4.  I love how Ruby allows Mix-ins… saweet!

5.  “require” only loads the file once, “load” loads it each time

6.  Opening up core classes and adding methods seems very powerful! – keeps code clean and flexible

 

Things I really need to learn how to use more often:

– unless keyword

– labels (i.e. :name vs @name vs “name”)

– inline array initialization (idk what its really called yet…like @name, @city = person_array)

– array.shift

 

Overall I think this course was maybe a bit too basic for someone with programming experience.  But even for me, I think learning some of the gotches and basics of some of the things I didn’t know as well were well worth it.  And the final project was a good first piece of Ruby code to develop (not web too!)

 

RubyMonk

So I finished the RubyMonk.com tutorial.  Overall a pretty good tutorial.  It holds your hand quite a bit, but it tries to give you a good understanding of the fundamentals.  Of course I won’t really know if they missed something until I gain a better understanding of the language.

Some criticisms I have:

– There are too few problems.  They should just have problems after each stage.

– They try to push you to the problems page every chapter or 2 (there are only 6 chapters).  And the problems page has all the problems listed.  There is no ryhme or reason why they take you there.  Even if you have solved all the problems you can at this point (each problem has a set of skills associated with it), they still are all just listed there (albeit with checkmark for accomplished ones).

– (Somewhat a continuation of the point above) The navigation sucks.  They force you to the problem page sometimes (even if you don’t have to go) and then from the problem page there is no way go to the back to the list of lessons.  The only way around this, is to use the browser back button and then hit the breadcrumb link at the top of the lesson pages.

Overall a good tutorial that gives you some basics in about 1-3 hours of time.  Got a better understanding of the yield keyword for sure.

So noob its sad

Decided I need to start learning Ruby.  Seems like a good language to learn to build web applications quickly.  There is such a large community out there and tons of help.  I first tried TryRuby.org which was a very very simple warm-up.  Really targeted towards people who know nothing about development.  Good just to get a small taste.  Small interactive tutorial which pretty much holds your hand.  I got lost once or twice when I tried to test some other things out.  The tutorial got weird, so I needed to back up sometimes.  I guess I should just follow the path….

I signed up for a free online Ruby course at http://rubylearning.org/class/login/index.php.  It starts in a week, so my goal is to get familiar enough with Ruby to go through this course which will teach me more about how Ruby is used with other technologies.

Now I am on to RubyMonk.com and going to go through their 54 exercises.  I am hoping I can blow through these in an hour or 2 to gain a better footing around the syntax.  Then I am going to go through RailsForZombies perhaps.  I also heard http://railstutorial.org/ is good, so probably going to go through that after these to get some concepts down.

Wish me luck!