Tri Nguyen

Standing Desk

I’ve heard of the idea of a standing desk setup being tossed around lately (some people took pictures of their own setup on Twitter), but never really gave it much thought. Last night at the after party of WordCamp Providence, I had an interesting discussion with Jon Desrosiers about a DIY standing desk setup that involves getting parts from IKEA.

Amused, on my way back from the conference, I stopped by Home Depot to see if they had any sort of frame I could use to create a make-shift experimental setup. I ended up getting a cheap shelf ($10) that was at a perfect height to stack on my desk.

A few nice things about this setup:

• The screens are at a good height – I need to tilt down a little while standing, but they’re good to be viewed at when I’m sitting on a chair too (being new to this whole thing, I’m worried my legs will give up early)
  -It actually clears up my table surface and gives me more space to work on non-computer-related, paper-based stuff, like writing

While this seemed to be a really nice setup, a few things about it bugged me.

• First, even though the keyboard is at the perfect height, it is too far from where I stand that I had to extend my reach considerably to type. This I imagined would be painful to my wrist after typing a long time.
• The stack of irregular books I used to elevate my second monitor just makes the whole thing look messy – destroy the purpose of the nice, minimalist white shelf.

After pondering for a while, I decided to do another experimental setup.

I utilize the top surface of my current shelf to house the monitors as it is at the perfect height for me. The keyboard and mouse are stored on the shelf right below it, which is also at the right height for my hand.

As I’m able to stand closer to this shelf than in the table setup above, my hands are a lot closer to the keyboard. Unfortunately, this also means that I’m looking at the big screen from a much closer distance.

While neither of these setups are perfect, the second ones gave me certain advantages:

• It separates my computer from the desk, thus allowing me to focus more on my paper-based tasks without the distraction of the Internet.
• It doesn’t involve any clumsy stacking of books and at the same time free up precious surface space for my desk.
• This is tangential (but quite important), this shelf is right across from my bed, so I can watch movies using the big screen cozily and comfortable now.

So I’ve decided to stick with the second setup for now and see how it goes. I will update any benefits and drawbacks I might run into as I go along.

Another option, as I mentioned above, is to follow this guide on how to set up a standing desk for $22 (or even less if you buy cheaper parts). I’m very tempted to try it out but it costs a little bit more and the height of the side table is gonna be too high for 5’5″ me.

There are many fancy standing desk setups out there that cost an upward of $500 to $5000, ones that allow you to adjust the height easily and look really nice and all that. But for a DIY, affordable setup ($10 for my first experiment, technically $0 for the second), I think that being creative will help achieve the same goal – to get you off your butt and be more healthy while working long hours in front of the computer.

Git and GitHub: checked!

Today marks an important milestone in my developer career: I have successfully managed to get started with Git and Github, including creating my first repo and pushed changes to it.

Here’s a quick rundown of how I did it (references for my future self).

1. Install git

I downloaded the Git Mac installer and run the install.
First challenge: Mac by default uses its own version of git, which is stored in /usr/bin, while the git installer install git in a different directory /usr/local/bin/git/bin.

Note

• You can check out which version your Mac is using by typing this into Terminal git --version and which git.

I couldn’t really figure out how to change this to make it work. So what I ended up doing was delete the default git file by rm /usr/bin/git and create a symbolic link from the new git to the old git ln -s /usr/local/bin/git/bin/git /usr/bin.

However, even without creating the symlink, Terminal will still search /usr/local/ by default to find git.

##2. Get started using git

I used Chris Coyier’s screencast tutorial on how to get started using Git by cloning a local project, created a new repo on github.com and upload the local project to the remote repo.

##3. Deploying from git

The first git repo I created was a website project I’ve been developing locally. I wanted to use git so that other people could start helping me work on it.
The natural next step for me was to figure out how I could deploy my git commits to a remote server through FTP.
My first thought was using a git hook post-receive, but it seemed awfully complex and difficult.

Dandelion is a much nicer and easier tool to use to deploy. I followed the guide to install it on my Mac and created the config file for each git repo.

Note:

• Use sudo gem install dandelion, and not just gem install dandelion
• For the exclude files in config, there should be no tab before the dash – character or it won’t work.
• The first deployment might take a while, depending on the size of your repository. But after that, Dandelion is smart enough to only deploy the files that have been added/ changed/ deleted, so it is really quick.

4. Workflow

Now, my new work flow includes:

1. Making changes to my working directory
2. git commit -m 'commit message'
3. git push origin master
4. dandelion deploy

While it is true that I can’t use automatic deployment with dandelion, I actually prefer to deploy manually like this. I think this would come in handy if I realized that I had made a mistake after a push, I could still go back and make changes before deploying it to my web server.

Another advantage to using this method is that I am deploying from my local git repo. This means that I could push certain files to the server without having them included in the public repo.

Resources:

• A great collection of resources by Brad Frost on Git/Github

Java’s public static void main(String[] args)

or “what the hell have I got myself into?”

As a new Java programmer, I keep asking myself, what does this line of code public static void main(String[] args) that is at the beginning of every Java program means?

After poking around, I found out the answer for this on a Java Forums. Here’s the answer in short:

The method is public because it be accessible to the JVM to begin execution of the program.

It is static because it be available for execution without an object instance. you may know that you need an object instance to invoke any method. So you cannot begin execution of a class without its object if the main method was not static.

It returns only a void because, once the main method execution is over, the program terminates. So there can be no data that can be returned by the Main method

The last parameter is String args[]. This is used to signify that the user may opt to enter parameters to the java program at command line. We can use both String[] args or String args[]. The Java compiler would accept both forms.
— arefeh from Java Forums

This might seem like a trivial post, but I wanted to have it here to remind me of what it means later, and as a quick way for me to reference it.

UNIX Command Line Prompt Color

a.k.a. first blog post on this site.

Foreword (you have been warned!):

I have decided to keep the design of this site simple and use the blog to keep track of my learning and exploration on the computer world.

I will try my best to categorize and organize the post into some sort of order, but it’s hard to do that starting out without an overkill of empty categories and tags. This space is mostly going to be for myself to look back and document what I have learned though, so I think a certain degree of flexibility is allowed.

Anyway, let’s get started.

My first post is dedicated to how to change the color of your Command Line Prompt. In this case, I am using both Terminal.app and iTerm2.app on Mac OSX Mountain Lion.

My terminal, for the longest time, looks like this:

I was getting tired of it, because, as a visual person, I find myself spending a lot of time trying to figure out which line was my prompt and which was the code. So I went on a Google search hunt to figure out the solution to change the color of my prompt.

After poking at a few places, I came across this StackExchange question “In bash how can I change the color of my command prompt?”. The first two answers were kinda helpful, but the third one really caught my eyes. So I copied the simple code prompt into my terminal:

PS1='[e[1;31m][[email protected]/*  */ W]$[e[0m] '
						

And it worked! The answerer also provided a quick breakdown of what the code meant, which is great.

However, this only works for that session of terminal. Once you close the current terminal window and open a new one, it’s back to the default plain old white text.

Luckily, at this point, after reading about 10 different sites on guides how to do this (none of which made a whole lot of sense to me, given my level of expertise with bash), I had an idea of copy and paste this line of code into a file and named it .bash_profile in my root folder (cd ~).

And then, tadaa! It worked, again! (Tri: 2, computer: 0). At this point I was ecstatic because the change is now permanent. My new terminal windows looks pretty like this:

So that is my attempt at changing the command line prompt color. If you are trying to do the same thing, give this method and try and see if it works. Let me know too if you think I’m doing something wrong or have a better way at doing it, because I would love to learn more about bash.

Last but not least, here are a few notes and questions I still have lingered after this small exercise:

Notes:

1. You might recognize that the content of my prompt looks different. This is because with that single line of code, it also rearranges my standard command line output. It used to look like this:

Tris-MacBook-Air:~tringuyen$
						

which is in the format of h:W u$, which means host: current working directory user and $. (you can get the current format of your bash command line by typing in echo $PS1).

1. If you have been trying to research on this for as long as I have, you might ask yourself “What the hell is the difference between a .bashrc file and a .bash_profile file?”. I was stumped with this question for a while, before coming across this great explanation by Josh Staiger about “.bash_profile vs .bashrc, which fully answered my question (the main difference is that they’re config files for login and non-login shell – that’s all I can say, if you want in-depth explanation, read the article).

Questions

So I still have a few questions about this whole process:

1. It seems to me that bash use a different color declaration convention than I am used to. I read somewhere that it is some sort of pair value, where o; 31 means red and use 1 instead of 0 means a lighter red (which is what I used to the picture above). Would be great to find out a list of different colors I can make with this and try them out.

2. I am still not sure what tput is and what it does, but it is used in the most popular answer in the stackexchange article above. I will need to wrap my head around that some time.

3. The next challenge for me would be to further customize the terminal using the config file. An example of this would be to change the color of the actual code itself, other than just the prompt.

If you have any question/ comment/ suggestion, please leave a comment.