In my previous article on How to run Teamspeak3 onDigital Ocean the instructions have you create a teamspeak3 user and change ownership of the files. I noticed in some of the comments over there that people noticed it was running as root, not the greatest thing for security.

I noticed my server was also running as root, here’s how to fix it if you used my instructions:

The Inspiration

We just switched to Slack at work and a friend created some integrations using PHP. This reminded me of a personal PHP project I’d worked on and thought I should dig it up.

The Setup

Back in 2005 I was doing C# WinForms work for a day job and just dealing with falling out of love with Perl. I hadn’t done any serious web development since college. I got into GTD pretty heavily and was looking around for tools that I could use anywhere. Of course a web app was the best solution for that time since there really wasn’t much in the way of smart phones or devices out1.

I found a great project run by BSAG2 called Tracks. It was built using Ruby on Rails. I didn’t know Ruby or Rails so of course the logical thing to do was to rewrite it in PHP.

I’ve been using Rails off and on from 2008 to 2012 and from 2012 mostly full time. Ruby is now one of my favorite languages and I think this project helped me understand what a good web framework Rails is.

Let’s see what gems we can discover in this treasure trove of old code.

Overall

Overall this code doesn’t match my current sense of code cleanliness. There’s a mix of tabs and spaces everywhere and tons of trailing whitespace. There’s lots of dead code, mostly around database access. It looks like I was working on multiple different techniques at once.

About the only thing I have going for me in this code is that I’m doing variable replacement in my SQL statements properly so it’s at least not one giant SQL injection attack.

Project Structure

Man, I had no concept of organization in this thing.

The tpl files are actually just PHP files I was using as templates, I guess the idea is that they were kind of like erb’s. I remember thinking how clever I was to use PHP as the templating language (because that’s what it was developed for) and not something like Smarty.

So… there’s really no division between models and views. I have one giant model that sets up the queries, the views actually execute it and use the raw results.

I remember trying to figure out why people needed models since if I wrote them it would basically just be querying the database and filling in an object with what I already had in my associative array.

My controllers at least load the view and combine some of the data and inject it into the views. I can appreciate some of the magic that Rails does by automatically matching views to controller actions after seeing how much boiler plate code is copied everywhere in here (not that I couldn’t have done better with the language that I had…).

my IndexController.php3 contains a giant nested if statement that handles all the routing for the site. I remember one of the issues I ran into was trying to figure out where I was. If I was hosted at http://lolindrath.com/gtd/ vs http://gtd.lolindrath.com I had a global offset variable to figure out where the parts of the URL I cared about started (i.e. /todo/12). I spent a good bit of time reading CakePHP source code trying to figure out how they did it (I obviously never got around to fixing that up).

Death of a Project

I abandoned the project sometime in 2010 then I learned Ruby on Rails and how to deploy it. I used the main Tracks project for quite a while until I setup a task syncing system using gitdocs. Now I’ve moved onto using Taskpaper and Dropbox.

Conclusion

I’ve obviously come a long way in my development as a programmer / software engineer / software architect.

It’s nice to keep these bits of old projects around as yard sticks with which to measure growth and progress.

I hope I see just as much growth in my coding style in another couple years.

I was at my last company for seven years. I moved between locations, projects, positions and responsibilities but I was at the same company for seven years, not really even thinking about moving.

I worked for one of the major defense contractors and at the time it was fun and we were doing interesting work. It was mostly short lived research contracts for the service labs and the DoD so it was always something new. It stopped being fun though when the money started to dry up and belts started to get tightened. I could see the writing on the wall and it was time to make a move1.

My interview skills were rusty, my resume was completely neglected and it took time to get everything in line before I started breezing past the phone screens and into interviews at companies I could really work for.

Looking back now after a year working at my new company here’s what I would’ve done differently.

1. Know the Companies in the Area

Keep up with what the great companies are in the area, the technologies they use and the kind of positions they look for the most. Shop for companies that match what you want as far as benefits, culture and your skill set. If you target a specific set of companies you know already match what you want you will save a lot of time by not peppering Monster with a million resumes and getting a ton of replies from people who don’t know how much you’re worth.

Go to the user groups in your area. If you want to stay in the same technologies or branch out, it’s a perfect way to find out who is in the area. Many companies sponsor these as a way to recruit new employees. This is also a great way sharpen your presenting skills. You can start with a lightning talk and move from there.

2. Interview at Least Every Other Year

You might not be ready to leave your current company but you should at least stay in practice. Most programmers have enough recruiters calling that you could answer the phone every once in a while and do a phone screen and see how it goes.

Doing this regularly helps you overcome the interview jitters.

3. Practice

Find a sample interview programming question on the web and work through a few with a timer.

Review the Big-O notation of some of the common algorithms.

Work with a whiteboard to talk through an overview of some software you wrote recently.

4. Perfect Your Pitch

You know the companies now, you’ve talked to a few people, now change your pitch.

Incorporate what you’ve learned from your practice interviews. For me people were worried that I worked on some ancient radar system mad had no relevant skills. I emphasized that I worked for a research group and worked on new technology like Ruby on Rails and did networking research.

Another important area I had to work on was how to concisely describe the projects I worked on and how to taylor that description to technical and non-technical people. This is where face time is great, if you start seeing someone’s eyes start glazing over while you’re telling them about the distributed test infrastructure you setup and the long list of all the technologies you used you know that you have to change tact.

5. Time Your Move

Don’t leave a job you love for no good reason but also don’t blindly trust that they are paying you what you’re worth and will take care of you for the next forty years. Dan Benjamin of 5by5 and Quit! fame emphasizes this point: when push comes to shove, if they have to let you go they will.

If you see the business going downhill or in a direction you don’t agree to you can make your move quickly before everyone sees the writing on the wall and starts peppering local companies with resumes. You won’t have to blindly apply to all the job board postings you can if you’ve already established good contacts in your local user groups and know exactly for which companies you work.

6. Wear a Suit

Make more excuses to wear a suit or get dressed up. This will make you feel more comfortable and less out of place when you do have to put one on to go to an interview. It will also limit the surprises when something doesn’t fit or the TSA zipped your suit pants into your suitcase ruining your favorite suit 2.

Conclusion

Being on top of the above items can save you months worth of hassle and get you onto your next job more quickly and painlessly.