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

Kegerators

A few months ago I bought a kegerator. (I have now reclassified it as a boat, but more on that later.) A kegerator is an appliance that combines a mini-refrigerator with a kit for dispensing beer from a keg. In reality, it is more of a small refrigerator with a beer dispensing kit, but thats a minor detail. I bought it with the full belief that I could go from setting it up to dispensing beer quickly. The whole system appears fairly simple, CO2 pushes beer out of the keg and you get it at the tap. Occasionally you’ll have to clean it, but that’s not abnormal.

However, it is far from the case. To explain why, let me explain the components and how it works.

A kegerator is more of a plumbing problem than it is a group of interconnected items. With a kegerator, you have a cooling box [the refrigerator], a tank full of gas [CO2 or a Nitrogen mix], a faucet, a keg coupler, and all of the piping between. A CO2 regulator is directly connected to a CO2 tank. A keg coupler is responsible for locking on to a keg securely, and mixing the beer and CO2. It also is the central point for connecting the CO2 and beer line.

Any kind of bad connection between any of the components and you have a problem. If you have a bad regulator, you could be leaking CO2, sending in too little/too much gas, or even cutting off the CO2 in general. If you have bad piping or bad fittings at the ends of each of the pipes, you could be leaking CO2, negatively changing the taste of the beer, or even lose beer [due to a leak]. Another issue with this, without washers/O-rings, you will not be able to create a good connection with the pipes. CO2 tanks have to be checked and tested every 4-5 years for safety. Also to note, the coupler, regulator, and the tank itself have safeties built-in to avoid high pressures, however you don’t want to get to the point where you need these.

After you have those basic ideas down, you still have more work to do. You must ensure the beer lines are cleaned periodically. If a keg is chilled properly, a keg can last months, but if you don’t clean the lines, after a while beer can sit in the line and “go sour.” I haven’t found anywhere else that mentions this, but it is an issue. The keg/beer isn’t the problem; it’s the beer that is in the lines. So flush out the lines by pouring a LOT out. Cleaning a beer line can take quite a bit of time. You have to disconnect the coupler, the gas line and the line that goes up to the faucet. Completely disassemble the faucet mechanism, flush the beer line and coupler with water and then cleaning solution. The parts to the faucet must be scrubbed and soaked in the cleaning solution. Then you have to let the beer line and coupler soak with the cleaning solution for about an hour. This is a lot more involved than washing dishes. Many bars have the beer distributer or a service professional handle this. It’s irritating, but it must be done to consistently serve beer from the tap. A cleaning kit can be bought from Kegworks.

Another issue is CO2 leakage. CO2 is an invisible compressed gas. Its presence is visible via condensation at specific temperatures. For large leaks, you can hear a hissing sound and easily identify where it is. But – it’s extremely irritating when you have a small leak. It could drain a CO2 tank within a day or two. I’ve had this happen twice so far. To check for leaks you can do two different things: a bubble test or a water test. A bubble test is a soapy solution that is sprayed on the full CO2 setup. If the solution bubbles up, the bubbles indicate where the leak is. The other option is to put the CO2 system in a bucket of water, with the tank upside down, and look for bubbles. Please check more official guides on doing this as that turning a CO2 tank upside down can be dangerous. If the lines, regulator, and tank are setup properly, there should be no leaks and CO2 exiting out of the end of the CO2 line. To make things worse, you could have an issue with the CO2 tank. Research the tanks before you get one. If you buy a kit, it’s rarely ever disclosed, recently a popular manufacturer produced a defective tank. Refillers tend, and should, check the tank brand, date, and if it was recalled before refilling. Also to note with kits, cheap regulators are not worth the money that they cost. The keg/soda supply store that I recommend used to have a bucket full of the same cheap regulator. If you buy a kit, you’re going to get a cheap regulator.

Beer leaks: these are a bit easier to identify than their CO2 cousin. If you have excess beer pooling on the keg or the in the refrigerator, you have a leak.

One of the best things that this kegerator kit has given me is the refrigerator that is formed to strap in the CO2 and the hole for the beer tower. However, I feel that I would have done better financially if I had bought the mini-fridge individually and stripped it down. If you do buy a mini-fridge ensure that it can hold a full sized US keg [half barrel]. Also to note, find a good keg distributor before building/buying a kegerator. Most stores won’t hold kegs and require a 7+ day notice to acquire a keg.

All and all, I wish I had built my own kegerator and bought all of the parts. The downside to doing this is that it appears to be a lot more expensive than a kit. However, I believe that I would have had much less trouble than I did.

Why is my kegerator a type of a boat? It is well known that a boat is something someone enjoys the day they buy it and the day that they sell it. It requires more maintenance than expected and requires quite a bit of monitoring.

Some of the products/companies that I strongly recommend:

·         NFC Chicago – These are the guys who deal with keg systems, and do CO2 refills. They’re good people and have been very patient and helpful. They’re local and they will sell you all of the parts, minus the refrigerator to build a kegerator.

·         Kegworks – These guys are an online keg store that sell all of the parts you need. Buy a cleaning kit from them before you tap your first keg.

·         Binny’s Chicago – These guys have a direct line to the beer distributors and can help you get the keg that you want. Total Wine and More may also help you with this, but I’m not sure about how convenient it is.

Protip of the Day: Always Delay your Email From Being Sent

This is a rather simple and should be obvious pro-tip: Delay all email from being sent. This helps to catch emails that have the wrong tone, message, audience or content before it’s sent. This tip has saved me from sending an badly formed email, or to the wrong audience many times. Just today I caught a work email that was missing information. It makes a difference from sending a brief and context email into sending a fully detailed email.

 

Why does this work really well?

I believe that this works really well because, like unit testing, it causes the author to separate the content creation with the later review. It forces one to reflect on what was created rather than to falsely believe what was written was perfect. It also gives us a chance to give more meaning and promotes a stronger signal to noise ratio in your messages. From my person experience little is gained from responding and sending anything immediately. Delays are a well accepted and expected situation when dealing with human to human communication.

 

That’s nice, but how would I do that?

Whats on your bookshelf?

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

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

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

 

This Week I Learned [19 May 2013 Edition]

This week I learned about:

  • There is a new change to how network devices are named. This may change your network device from eth0 to something like env10p0.
    http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
  • Archlinux is very similar to Gentoo, but it is based on a script to install everything.
  • 2to3 is a python script that will convert a python script from a version Python 2.0 to a 3.0 compatible script.
    • One major difference between 2 and 3 is that the print statement became a function, thus requiring parenthesis.
  • It is easier to hard code the Python 2 environment, rather than to convert the script into a Python 3.0 script.
    • #!/usr/bin/env python2.7 [or whatever Python 2 environment that is installed] should be used in the shell definition of the script.
  • OpenVAS– Open Vulnerability Scanner: I haven’t tried this yet, but this is a neat utility that can help you keep tabs on the software you currently have installed and the possible vulnerabilities that they may have.
  • Always snapshot your VM after you finish major installs. [This saved my butt this week]
  • Ansible –  This looks like a nice Open Source version of HP Operations Orchestration.

The Problem with Resolutions

I guess you could technically claim that I didn’t fail at the resolutions I made earlier this year. The year isn’t over, however I believe that having long term goals such as these may be a bad idea. At this point, I believe that many of the resolutions I made [I.e. Learning R, meeting people who dealt with airline systems, and learning GridGain] may not be the best use of my time.

It might be a better use of my time to do periodical reviews of my current skillsets and recent tasks rather than to push forward blindly.

I’m not giving up on learning new things. I’m just not going to limit myself to a list.

Some of the technologies/tools I’ve been learning lately:

  1. OpenStack
  2. ArchLinux

Some technologies I would like to learn:

  1. Storm
  2. Ansible

Getting Over Writer’s Block

A while ago, Tim Ferris was asked how he was able to accomplish the task of writing books of considerable length. The advice that he was given was: Write 2-3 sentences every day. I cannot recall who was the interviewer or the advisor. Note to the reader: It is possible to find this video on the internet, but I have no idea where it is. More help: It was after the {{4 Hour Chef}} was released. This is great advice and has helped me. I have difficulty writing at times. When I’m faced with a large writing task I tend to become unmotivated. Writing two sentences is an easily accomplished task, reduces stress, and creates very manageable goals. This becomes incredibly helpful for when you are passionate about the subject, but your motivation for writing is lacking or your worry of getting your message across effectively is important. If you are extremely passionate about the subject I believe that you’ll find that after writing those two sentences your writing will transform into pages of text.

If only I knew this trick in college.

Additionally I don’t find that this trick works 100% of the time, but the writing becomes much easier when you create a framework for what is to be written beforehand. This is also true with writing code.

Progress on Tech Resolutions of 2013

Earlier this year I made a few resolutions for this year.

So far I have completed the following:

  1. Finished and reviewed “Groovy In Action”
  2. Refresh on networking

Despite this not being much, I have learned many new things about disk storage, and Maven. Also, I’ve created a new GitHub repository for a ogg2mp3 script that I created.

Things left to learn/do:

  1. Finally get around to learning GridGain.   [I would love to see a well published book, or at least a Kindle eBook to get some headway on this] HazelCast would also be interesting, but GridGain has more of what I’m looking for.
  2. Finally understand how network routing works.
  3. Get more experience with DNS, and DNS tools
  4. Master NMap [not just learn the basic uses of it, but to really excel with the tool] This would be similar to the reading up on SSH I did last year.
  5. Get up to conversational level German. [Living outside of German speaking nations makes this incredibly difficult]
  6. Finally develop some strong time management habits.
  7. Learn how to use Python [to the point where you can do some cool stuff with it]
  8. Learn R [rather than haphazardly hack]
  9. Meet/talk with some of the gurus of airfare scheduling/decoding, and the famous Tom Stuker.
  10. Learn how to use GraphViz [This is one of the odd ones here, but it’s interesting]
  11. Get better with Erlang and to find/make real world uses.
  12. Learn/Create a GUI in Apache Pivot
  13. Create a web interface with either Stripes and/or Wicket.

 

Things I would like to Learn/Experience/Improve-Upon This Year [2013]

Since this is the time of the year that many making resolutions relating to self improvement, here are a few of mine:

  1. Finally get around to learning GridGain.   [I would love to see a well published book, or at least a Kindle eBook to get some headway on this] HazelCast would also be interesting, but GridGain has more of what I’m looking for.
  2. Finish the massive tomb that is “Groovy In Action”
  3. Finally understand how network routing works.
  4. Get more experience with DNS, and DNS tools
  5. Master NMap [not just learn the basic uses of it, but to really excel with the tool] This would be similar with the reading up on SSH I did last year.
  6. Get up to conversational level German. [Living outside of German speaking nations makes this incredibly difficult]
  7. Finally develop some strong time management habits.
  8. Learn how to use Python [to the point where you can do some cool stuff with it]
  9. Learn R [rather than haphazardly hack]
  10. Meet/talk with some of the gurus of airfare scheduling/decoding, and the famous Tom Stuker.
  11. Learn how to use GraphViz [This is one of the odd ones here, but it’s interesting]
  12. Get better with Erlang and to find/make real world uses.
  13. Learn/Create a GUI in Apache Pivot, and a web interface with either Stripes and/or Wicket.

How am I planning to accomplish these things? Having goals, and putting them on my task list.

Currently, I am reading up on Maven, and Groovy. I read a book on GIT, and got some practice w. A review of the strengths and weaknesses may be coming up in a later post on this blog.

To the 1.5 readers left reading this blog: What are your goals for the New Year? Leave the response as a blog post linking back to this post or in the comments below.

I’m a student, what [language, framework, API, concept] should I learn?

Part one of a continuing series.

There are two ways to learn something. The first way is to learn from another’s advice [the easy way], and then there is the hard way [through experience and making mistakes]. When starting out in a Computer Science degree, learning the material and concepts will require a lot of effort. [the hard way] It’s not a wrong way to go about it. The hard route helps to reinforce the material. However, not everything in your journey to become a software developer has to be difficult.

One of the most frustrating things for a student, when in a Computer Science program, is producing a deliverable to submit. Many students, outside of the introductory course, quickly find out that a few quick hacks won’t get the highest grade available. Many professors require documentation, specific file layouts, compliable code, funky submission instructions, build instructions, shout-outs in the comments (1), or even coding conventions. These extra/non-technical requirements add to more complexity and make assignments more difficult. However, they do have merit and “build” the student’s technical character. In academia, there are very few courses in the US that will teach the tools of the trade, this is something that the student is left to learn on his or her own.

So what does this have to do with answering the question: What should I [as a current Computer Science student] learn? Build systems. Learning how to consume a web service to Facebook or writing the next twitter client is great, however learning how to use a build system will make your professor’s, and your life much easier. A build system is an external tool [usually separated from an IDE] that defines the instructions on how to build an application. In addition, it makes your life easier when questioning if your attempt was worthy enough to submit. Did the build system pass and produce a deliverable? If you have all of the rules and unit tests configured to run, the answer is easy… Yes! Once you are confident that the assignment was completed to satisfaction, you can go party err study ‘social algorithms.’

So let’s imagine that you have the following requirements from a professor:

  • Build a chat system [One client, and one server]
  • Include unit tests for every method used
  • Include Java Doc
  • Email to: professor@university.com
  • FTP The resulting zip file to: ftp server.
  • Create a readme at the base, and include your name and the word “Screaming Monkeys” within the readme file.
  • Include instructions on how to build your software
  • Use the following file format:
    • /
    • Readme
    • BuildDoc
    • Doc/
    • Source/Client/*….
    • Source/Server/*…
    • Binary/*…

Building a working chat client and server solution may be difficult for someone that has just learned about sockets and lacks experience. The non-technical requirements could become overwhelming. However the assignment never required all of the non-technical instructions to be performed manually. I have NEVER heard of a professor that will take points off for using these tools. If anything, using a build tool will improve your grade. It allows for you to plan for these requirements ahead of time, and let software handle the rest for you.

“But hey! That looks like a lot of work to do a few simple steps!” You’re right; all of those steps can be performed manually and probably quicker. However, if you screw up part of your final deliverable , you’ll have to perform all of those menial tasks all over again. With all of those tasks, Ant can perform those automatically by just typing in “ant.” You can configure ant to build the software, run all of the unit tests [and stop the build if one fails], configure the output of the java doc, run utilities [to confirm that your name is there, and the “special word”], perform all of the file manipulation and deliverable locations, and even submit the result [ftp, email, source control]. If there is an ant task for the action, you can use ant to do it.  Another benefit is that it can even run the source code through a “coding convention” checker. Have a professor that requires you to use the K&R coding convention? No problem, just add a check or reformator in the build environment. Problem solved.

In summary, assignments in computer science are difficult with the shear amount of demands. Reduce the potential for mistakes by automating the tedious tasks. Learn a build system early in your education. It will help ensure consistency in your code, get rid of annoying non-technical requirements, and make your work a lot simpler.

Need another reason? Do it for getting a job after you get out of school. There are very few students that have even used a build system prior to entering the work world. Most students entering the work world have to learn at least one build system as soon as they start their first job. The software industry thrives on build systems. If they aren’t working, the developers are unable to progress. Hey, worst case scenario: Let’s assume that you’re not a very good CS student, and you barely pass with your CS degree. If you know a build system extremely well, you can still proceed with a career of being a “Build Systems engineer.” Those guys can still make quite a lot of money. [Indeed claims that a build engineer starts at $50k and has a sizable amount of jobs that will earn $130k+ a year]

Some of the build systems that are currently in use:

  • Ant [Good for nearly every language out there]
  • MSBuild [Good for the MS supported language (VC++, VB?, anything .NET)]
  • Maven
  • Gradle
  • Make [Good for C++, and bash]
  • Apache Ivy

(1)    In my prior work as a teaching assistant I am guilty for supporting the shout-outs rule. The requirement was for the student to include his or her name in the top of the file. This was mentioned on the grading rubric (included in the assignment writeup/specs).  It’s a simple request to complete, and it makes the grader/professor’s life a lot easier. It’s akin to asking elementary school children to write their name on top of the assignment. A lot of new students don’t add their name to their code.