About Me

Tuesday, April 15, 2014

Affordable Standing Desk Workaround

I have been using a portable laptop standing desk for a while but I also wanted a larger standing to use at home -- something that could hold my large monitor and the like. I didn't want to spend over $700 or need computerized memory settings that allow it to be put back down to seated position easily. I've heard of too many people just putting their desk in sitting mode from old habits. I also didn't want anything that was difficult to put together.

I'm sure I am not the only one to think of this, but what I decided to do was get a relatively cheap table with adjustable height legs from Ikea ($155). Then I extended the legs high enough for it to act as a standing desk. The table top was $35 and is by Linnmon and is 59 x 29 1/2 inches. The adjustable legs are by Gerton and are $30 each.

Since I knew from experience that I would not want to stand up all of the time, I purchased a comfortable swivel barstool with backrest ($140), from Living Spaces and is made by Moscato. I also found this really cool leaning seat called a Mobile Mogo ($99) made by the company Focal. It gives you the comfort of sitting but while you're mostly standing, which takes a lot of pressure off of your feet.

But I don't always want to lean against a human kickstand, so I grabbed this anti-fatigue mat by Stanley from amazon.com ($50).

Warning: I'm exactly 6 feet tall and I have the adjustable legs as high as they can go. So my desk is around 41" high. If you're taller, this won't work. Also, at this maxed out height, the table is a little wobbly so you won't want it if you want a completely sturdy desk. It's not too wobbly for me but if you have anything flimsy on your desk it will wobble somewhat.

Make sure to get a full height barstool and not a counter barstool. Mine is a 30" barstool, meaning the seat is about 30" high.

Because my desk is higher off the ground, some cables to my surge protector didn't quite reach. To remedy this, I put my power strip on my desk and inside of a little container made to hide it from dust and view. This cost $30 but was worth it to me, but you could probably easily make your own if you wanted.

Total price for everything (tabletop, adjustable legs, barstool, leaning seat, anti-fatigue mat, and power strip cover): $485. Just the standing desk: $155.

Monday, March 17, 2014

Headless Dropbox

You can install Dropbox on a Linux server or any Linux system that doesn't have a monitor or a GUI Windowing System.

I recently installed Dropbox on my Digital Ocean Droplet, running Ubuntu 12.10 server. I did not figure this all out on my own. I read the sources mentioned at the bottom of this post. However, some of the information was incomplete or contained broken links, and I ran into other issues. So this this blog post is more of about how I got it working, in hopes that you won't encounter the same issues that I did.

First, you will need to link your Linux machine with your Dropbox account by downloading and running a Dropbox server script called dropboxd:
    $ cd  # changes to your $HOME directory
    $ wget -O - "https://www.dropbox.com/download?plat=lnx.x86"|
      tar xzf -
    $ ~/.dropbox-dist/dropboxd

    Use the above command if you're running "uname -m" says i686.
    $ cd
    $ wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64"|
      tar xzf -
    $ ~/.dropbox-dist/dropboxd

    Use the above command if "uname -m" says x86_64.
The running dropboxd command should output a link for you to paste into a browser to link that system. I had issues with this at first and just had to keep rerunning the command over time and leaving it running until it finally started saying something. This was probably due to connection issues that you hopefully won't have. You can then verify that it's linked by logging into your dropbox web account and going under the "Security" tab to see linked devices.

The link uses a token so you don't have to store your Dropbox password on the Linux instance.

Once Dropbox is linked you should see see your ~/Dropbox directory starting to sync. At this point you can temporarily stop the syncing by hitting ^C (Control-C) to stop dropboxd. Don't worry we'll finish syncing in a minute.

Let's download a nice python script to help us manage Dropbox better:
    $ wget -O ~/bin/dropbox.py "http://www.dropbox.com/download?dl=packages/dropbox.py"
    $ chmod 755 ~/bin/dropbox.py
and download a bash script that we'll use to start and stop Dropbox:
    $ wget -O ~/bin/dropbox_temp "https://gist.githubusercontent.com/benhedrington/\
    $ chmod u+x ~/bin/dropbox_temp
Edit ~/bin/dropbox_temp in Vim (or whatever editor you like) and change DROPBOX_USERS="user1 user2" to whatever user(s) on your system you want to run dropbox clients for.

Now move dropbox_temp script:
    $ sudo mv ~/bin/dropbox_temp /etc/init.d/dropbox
and have it start when we boot:
    $ sudo update-rc.d dropbox defaults
Close the dropboxd script if you still have it running manually: ^C.

Check if dropbox is running, if it's not then start it:
    $ sudo service dropbox status
    $ sudo service dropbox start
If it's is running then run:
    $ dropbox.py status
If the status command says Dropbox is now downloading or syncing a ton of files, you might want to remove some directories from being sync'd to this linux machine by using Dropbox's Selective Sync.

Selective Sync allows you to exclude certain folders that you don't want to sync to your linux server, e.g., maybe you don't need all your photos on it:
    $ cd ~/Dropbox
    $ ls
    Photos Projects Public iphone-photos
Let's exclude the photos and Public directories:
    $ dropbox.py exclude add Photos
    $ dropbox.py exclude add iphone-photos
    $ dropbox.py exclude add Public
    $ ls
At this point I would wait until dropbox.py status says "Up to date" before editing files in your Dropbox folder. Just to make sure nothing gets corrupted. Once Dropbox has finished downloading everything, you should should try to sync files to AND from Dropbox. Make sure to test both directions and also test nested directories and your most important directories. I had an issue once where files in ~/Dropbox/Projects/notes/ wouldn't sync outgoing, yet ~/Dropbox/Projects/code/ files would. If it doesn't, you'll need to reinstall Dropbox (instructions are below). It shouldn't be a firewall issue because the docs specify that Dropbox runs on port 80.

Alright, if you made this this far and everything seems working, the great!

You may also want to delete any cached deleted files from the exclude step (NOTE: don't even try this unless you need it and at least until you're sure dropbox is already working):

    $ sudo service dropbox stop
    $ rm -rf ~/Dropbox/.dropbox.cache/*
    $ sudo service dropbox start
Don't delete the .dropbox.cache dir itself, just its contents.

If you ever need to delete the dropbox instance:

     - ^C to stop the dropboxd daemon

     - rm -rf ~/.dropbox* ~/Dropbox

     - Revoke the token that was issued for your sesion by clicking 'unlink' next to your Droplet's host name at https://www.dropbox.com/account#security

It's important that you actually delete the ~/.drobox* folders, because your old key is stored there, and you have to generate a new one next time you run the original wget commands. So don't think of keeping it around as a shortcut to reinstalling.


Sunday, March 2, 2014

The Path to Homebrew

The home page and documentation for Homebrew show how to install and use Homebrew. However, they currently don't seem to explain exactly how pathing works. This can trip up a lot of newcomers, who might give up on Homebrew or fumble around the internet and land on bad advice - such as using sudo and editing /etc/paths. All of this is unnecessary and potentially dangerous.

You just really need to understand a few basic concepts:
  • Never run brew as sudo. Not "sudo brew install" nor "sudo brew link".
  • The "Cellar" is a place that all your "kegs". Homebrew installs packages to their own directory (in the Cellar) and then symlinks their files into /usr/local/.
  • Change /usr/local/* to be owned by $USER, not root, so you can have write permissions and not need sudo.
  • The $PATH entry for /usr/local/bin should occur before /usr/bin.
Here's an example of installing Python and setting paths correctly. I'm using OS X 10.9.2 (Mavericks) and Homebrew 0.9.5:
    $ sudo chown -R $USER /usr/local/*
    $ brew doctor
    $ brew update
    $ brew install python --with-brewed-openssl
    $ ls /usr/local/Cellar/python
    $ python
    >>> 2.7.5
Wait, I expected to see python 2.7.6 now. What happened?
    $ which python
But the Homebrew docs said we will be using a symlink from /usr/local/bin/ that points at the Cellar instead of using /usr/bin:
    $ ls -l /usr/local/bin/python
    lrwxr-xr-x 1 rkulla admin 33 Mar 2 06:37 /usr/local/bin/python ->
Aha. So it must be a PATH issue:
    $ echo PATH

    $ cat /etc/paths
When using Homebrew, we actually now want to change the position of /usr/local/bin to be before /usr/bin in $PATH. But don't edit /etc/paths. Instead edit ~/.bashrc and prepend /usr/local/bin to $PATH, like:


Next, run:
    $ source ~/.bashrc
    $ echo $PATH
    $ /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
Don't worry that there's duplicate entries for /usr/local/bin. It doesn't matter. What matters is that you've modified your PATH safely and ultimately cleaner than the other ways.
    $ ls -l $(which python)
    lrwxr-xr-x 1 rkulla admin 33 Mar 2 06:37 /usr/local/bin/python ->
Yay! And if you ever want to use the old python you can just run: /usr/bin/python.

Best of all from now on whenever you need to install anything with brew, you can just run:
    $ brew install whatever
and not have to fumble with permissions or worry about overwriting any global system files.

I also like to source ~/.bashrc from ~/.bash_profile. For why see: .bash_profile vs .bashrc

Monday, January 2, 2012

The Wallpaper Algorithm Using HTML5 and JavaScript

There's a fun little book called The New Turing Omnibus - 66 Excursions in Computer Science from 1993. An omnibus is "a volume containing several novels or other items previously published separately". The first item in this book is the following algorithm:

1. input corna, cornb
2. input side
3. for i ← 1 to 100
     1. for j ← 1 to 100
       x ← corna + i x side/100
       y ← cornb + j x side/100
       c ← int (x² + y²)
       if c even
         then plot(i, j)

All that is needed to translate this algorithm to a running computer program is to have a Turing-complete programming language and a way to plot pixels on a display. So if you want to try it out for yourself first before seeing one solution, stop reading now and try it. I'm going to demonstrating how I implemented this algorithm by using JavaScript and HTML5's canvas element. The book only shows one implementation using Pascal so I thought I'd do something a little more modern.

We'll be creating two files. The first one will be the html5 content:
<html lang="en">
  <meta charset="UTF-8">

  <button id="myButton">Show Wallpaper</button>

  <canvas id="myCanvas">
  Your browser does not support the canvas element.

  <script src="wallpaper-algorithm.js"></script>

Next create a file called wallpaper-algorithm.js with:
document.getElementById("myButton").onclick = function () { 

function wallpaper() {

  var browserWidth = window.innerWidth;
  var browserHeight = window.innerHeight;
  var canvas = document.getElementById("myCanvas");
  var ctx = canvas.getContext("2d");
  var corna = 0;
  var cornb = 0;
  var side = 345;
  var xmul;

  canvas.setAttribute('width', browserWidth);
  canvas.setAttribute('height', browserHeight);
  document.body.style.background = 'black';
  for (var i = 1; i <= browserWidth; i++) {
    x = corna + i * side / 100;
    xmul = x * x;

    for (var j = 1; j <= browserHeight; j++) {
      y = cornb + j * side / 100;

      if (i % 2 == 0) {
        ctx.fillStyle = 'white';
      } else if (j % 2 == 0) {
        ctx.fillStyle = 'lime';
      } else {
        ctx.fillStyle = 'purple';

      if (Math.round(xmul + y * y) % 2 == 0) {
          ctx.fillRect(i, j, 1, 1);



As an exercise, the book says to write the algorithm using three colors instead of two. That was easy enough so above I had it use four colors (black, white, lime and purple).

The book also says to make corna, cornb and side as user inputs, but for the sake of example, I hard-coded them. The variables corna and cornb represent the lower left-hand corner of the square of interest. The variable side is the length of the square's sides. Try side values of 5, 25, 33, 41, 45, 51 and 325 for some neat patterns.

Feel free to experiment with the algorithm and have fun with it. All-in-all it's a great example of what can be done with a simple algorithm and screen graphics. It's also a great demonstration of HTML5's canvas element coupled with JavaScript.

For exact details on how the algorithm works, buy the book. I think Google Books has a free version online as well.

Tuesday, December 6, 2011

I See Dead Code

I recently removed a lot of dead code from our code base at work. There were several similar directories, dead files, and unused code within live files.

All this unused code was a major nuisance for over a year. It would cause grep to show too much information -- most of it meaningless -- and it would even cause your IDE to jump to the old unused class file, rather than the one you actually wanted.
People were afraid to remove this code for fear of breaking things. After all, it was tied to our main shared library that could cripple over 200 of our websites at once. But enough was enough. I decided to embark on removing it. I have a lot of experience with removing dead code but rarely this high of a risk and with so much of it. I had only one day to figure it out, delete it, and test it. Otherwise, it would have to have be rolled back, for who knows how long, until anyone would attempt to remove it again.

Before removing code like this, I ask myself if it's good code that we might want to start using soon - or even right now under a configuration option. If it's useful code I wouldn't just delete it. Rather, I'd extract it out into classes that could become part of our library.

In my case it really was all just useless code. Some programmer from long ago had been a little too happy to copy and paste code to new files, leaving the old dead files lying around.

Some other code was living in live files but was effectively in a "dead block" because it would only happen under a condition that would never happen. I decided to remove this as well because such code will only confuse programmers every time they see it. In fact, I was about to spend time converting it to work with our new platform. What a waste of time that would have been! Fortunately, dead code like this is often easy to determine as dead, because you go to refactor it and can't figure out how to get it to run under that condition from the user interface. This is why it's we shouldn't rely solely on unit tests.

A coworker suggested that I keep the condition in the code at first, replacing the body of useless code with code to log a message such as "This condition should never happen." This way we could monitor the logs once it was deployed for a while, and really make sure the code wasn't being used by anything.

The easiest dead code to spot is commented-out code. Go ahead and remove this any time you see this. It will only sit there forever, no one will ever uncomment it, and if they really do need it that's what source control is for.

For those times that it's hard to tell if code is dead or not, the main tool I used to figure it out is grep. More specifically I use ack-grep. The key is to trust your grepping abilities and be extremely thorough. If you can prove that certain code isn't being referenced via other files, that's a huge step toward having the confidence to remove it.

Of course, it's not always that easy. Sometimes the code is referenced but that's okay; replacing it to use the proper files instead is certainly worth the effort.

Once you have removed the code, and all is working in your development sandbox, it's time to deploy it. It really isn't much different than writing new code or refactoring existing live code. Any time you commit code it could cause other things to break. This is why we do regression testing.

I highly recommend that you wait to push this kind of change out when there's no other important code that needs to be deployed too. If the "new" code is found to not be in a working state, then your code removal attempt will be the first source of blame and you will likely have to rollback and risk never getting to try again -- even if it wasn't the problem.

So go ahead and remove that dead code the next time you see it. You'll thank yourself later and so will your coworkers.

Sunday, November 20, 2011

Math and Algorithm Programming with Project Euler

If you're a web developer or other type of programmer that doesn't require much math, you might be pretty weak with math based programming. Doing Project Euler problems will help to strengthen your math and algorithm programming abilities.

From the official website for Project Euler:

Project Euler is a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve. Although mathematics will help you arrive at elegant and efficient methods, the use of a computer and programming skills will be required to solve most problems.

The way it works is you register for free on the site then it gives you problems such as "Calculate the sum of all the primes below two million." Your task is to implement an algorithm in the programming language of your choice to give you the answer. Once you have the answer, you paste it into the web site and then it tells you if you got the answer correct or not. If you answered correctly it gives you the ability to view other programmer's source code for how they did it and even submit your own if you want to.

I recommend doing some of the problems as code katas. A code kata is a way of practicing typing out low-level programming problems over and over until it becomes second nature to you--just like doing doing martial arts katas helps martial artists. I still remember some of the katas from martial arts that I haven't done in over 10 years. Repetition truly is the mother of all skill.

Another thing that doing Euler problems will help you with is learning how to optimize algorithms. The speed of the machine your program runs on will largely affect the speed of your programs, but you often don't realize it until you're doing an algorithm on some large numbers. Fortunately, many Euler problems will really push you and your machine.

You optimize the algorithms by benchmarking the program and refactoring it to run faster and faster. Sometimes you'll need to use a different math library to speed things up. For example, bcmath is a lot faster than the regular math functions in PHP for me.

How do you benchmark? The easiest way is to use the time command, which is available for Unix-like operating systems such as Linux and OS X:
$ time ./my-program
You should also try profiling your solutions. Ruby comes with a built-in code profiler if you give it the -rprofile argument, but it's rather slow. I prefer to install ruby-prof. So I can profile with:
$ ruby-prof ./my-program.rb
Profiling is great because it will tell you exactly which part of your code is taking the longest to run, so you can focus on optimizing just the bottlenecks.

I highly recommend solving the same problems in different languages. This will not only help teach you other languages, it will show you how much faster or slower a language is compared to other languages. It will also show you how expressive one language is compared to another. Sometimes I use the exact same algorithm in C as I do in PHP, and the syntax is almost completely identical, only the C version runs light years faster, of course.

It's worth running your solved problem using different versions of the same language. For example, PHP 5.3 solves my Euler problems a lot faster than php 5.2. Ruby 1.9 solves them a lot faster than 1.8, and so on.

I solved a lot of Euler problems between 2007 and 2010. When I recently looked back at some old problems I solved, one thing that I'm really glad I did back then was write comments to myself in each source file telling me: 1) How long it took me to solve the problem 2) How fast it ran on whatever machine and language version I was using at the time and 3) which language I solved it in first.

One last thing; make sure you go to projecteuler.NET and not the .com. The .com is a really annoying spam website.

Thursday, October 27, 2011

Learning CoffeeScript With Unit Tests

CoffeeScript is a language that transcompiles to JavaScript and has syntax that looks more like Ruby or Python. In other words, it allows you to write JavaScript without writing JavaScript and with a lot less code. The generated JavaScript code even runs as fast, if not faster, than if you had written pure JavaScript.

I don't mind writing pure JavaScript but since I really like Python and Ruby, I figured I'd give a try since the syntax is familiar. CoffeeScript can even make jQuery even easier to write than it already is.

My Coworker Danny turned me on to using Koans to learn Ruby, and when he mentioned there's a CoffeeScript version, I immediately jumped on it.

Koans can aid in learning a new programming language. They're a Behavior Driven Development approach that turn learning into a kind of game where you fill in the blanks to make tests pass.

A CoffeeScript Koan consists of CoffeeScript code with Jasmine unit test files. The tests look like:
  # Sometimes we will ask you to fill in the values
  it 'should have filled in values', ->
    expect(FILL_ME_IN).toEqual(1 + 1)
You then compile the file (in this case AboutExpects.coffee) using the command-line coffee tool:
$ coffee -c AboutExpects.coffee
which in turn creates the corresponding JavaScript file (in this case AboutExpects.js). If we were just writing CoffeeScript code, we could then run the .js file in a Web Browser, as usual. Or even execute the JavaScript file without a browser, if you have node.js installed, which we'll do in a minute:
$ node yourFile.js
However, since we're doing Koans, we'll load the file using the bundled "KoansRunner.html" file, which loads our compiled .js file using the Jasmine Behavior Driven Development framework. This let's us know if our tests passed or failed.

Let's start by installing the CoffeeScript and the command-line compiler. Note that modern Ruby on Rails installs should already have CoffeeScript. For this tutorial I've only tested the following in Ubuntu Linux, but it should work for most Unix-like Systems. But you're always free to check for bundles for your system if you want to make it a little easier on yourself.

The coffee command-line tool is dependent on Node.js, so we'll need to install that first. Currently, the best way to install Node is to compile it yourself. So download it via the tarball or github repository, then run the usual:
$ ./configure && make && sudo make install
Now that Node is installed, we'll install the Node Package Manager (NPM):
    $ cd /tmp
    $ curl -O http://npmjs.org/install.sh
    $ sudo ./install.sh
Now you can install the coffescript command with:
$ sudo npm install -g coffee-script
Once installed, typing coffee should show an interactive prompt like:
Type Ctrl-D to exit.

You're now ready to install the CoffeeScript Koans from the github repository. Assuming you're working from ~/src/:
    $ mkdir ~/src/koans
    $ cd ~/src/koans
    $ git clone https://github.com/sleepyfox/coffeescript-koans.git
    $ cd ~/src/koans/coffeescript-koans/
In the above screenshot image in this article, you can see I've split my Linux screen in half, with the top half a Web Browser running KoansRunner.html. The bottom half is AboutExpects.coffee open in Vim.

Note that the answers to the first two Koans are already filled out in my example. They're so overly simplistic that just by understanding those two answers you'll have learned as much as you otherwise would have, so don't feel cheated.

So now it will be your job to open koans/AboutExpects.coffee and fill in a test method with what you assume is the correct answer. Then compile it with:
$ coffee -c koans/AboutExpects.coffee
and move the generated JavaScript file to the lib/koans directory and reload the KoansRunner.html file to see the new test results. Once you complete all the Koans in AboutExpects.coffee, you'll move onto the next Koans file, AboutArrays.coffee, and so on.

There are a couple of tips for making compiling and reloading easier. One tip is that at the root of the Koans directory, you can run a command called "cake", which was installed earlier during the coffee install process. You can verify this with:
    $ file $(which cake)
    /usr/local/bin/cake: symbolic link to `../lib/node_modules/coffee-script/bin/cake'
    $ file -L $(which cake)
    /usr/local/bin/cake: a node script text executable
$ cake build
will compile all of the tests in the koans/ directory and automatically cp them to the lib/koans directory. This allows you to add a Vim keyboard mapping to your ~/.vimrc file, such as:

    nmap <Leader>c :!cake build<CR>

which lets you recompile the Koans by simplying typing \c in Vim. The "Leader" key on my system is a backslash, YMMV. Just make sure to run the shortcut from the root of the Koans directory so it can find the build file.

If you have Ruby and RubyGems installed, there's an even easier way to do this, using a "watch" command. The coffee command-line tool comes with an option called '-w', which watches for modified timestamps of files and then re-compiles the files automatically when they change. And the Koans come with a nice extension to this by including Ruby files called koans-linux.watchr, koans-win.watchr and koans-mac.watchr, respectively. To use it you need to install the watchr gem:
$ gem install watchr
Now, if you were on a Linux machine, say, you would run this in a terminal:
$ watchr koans-linux.watchr
Now you can edit and save your CoffeeScript koans and just hit refresh in your browser. The cake build step is taken care of automatically by the watchr!

Another thing that's nice to be able to do, is check our CoffeeScript code for syntax errors before we try to run it. This is known as "linting". The coffeescript command-line tool comes with an option called "-l" that lets you lint your files, but only if you have jslint installed first. So install it with:
$ npm install jslint
At this point, you're breezing through the Koans and you start learning enough CoffeeScript that you actually start using it to write your JavaScript, and you open a coffee compiled .js file and you notice the JavaScript looks a little verbose. As a simple example, say you had written a Hello World function called hello.coffee like:
    sayHi = (name) ->
      return "Hello " + name

    console.log sayHi("Ryan")
and you compiled it and opened the .js file and noticed it looked like:
(function() {
  var sayHi;
  sayHi = function(name) {
    return "Hello " + name;
As you might suspect, it's just there by default for global namespace cleanliness. You can either manually remove it, or compile your coffeescripts with "-b, --bare". Which would then look like simply:
var sayHi;
sayHi = function(name) {
  return "Hello " + name;
There is other verbosity such as it always declaring all variables with the var keyword. However, there's no good reason to take them things out since it's actually great to have CoffeeScript do all the tedious things for us that we often skip doing.

That's all for now. Please visit the main CoffeeScript and CoffeeScript Koans sites for more information.