When I first started out in web development, I worked directly on the server. I had an FTP client and I’d download files, edit them, and re-upload them. If it was a “serious” project, I might even use source control. I thought this was a pretty handy way to work… Looking back on that workflow, I’m embarrassed, but the thing is, I know people who still work that way. I’m not going to go into the merits of having a dedicated development environment, automated builds and tests, etc… Just take it as a given that you need them. With that being said, however, it’s always a pain trying to set up a new development environment, and having an environment already set up on my laptop doesn’t guarantee that it’ll be the same environment that the next client has in production. If you’re on a different machine, it’s a problem. I’m going to talk about how I’ve solved this age old problem using Vagrant, Puppet and VirtualBox.
This is the second post in my series on the Kohana php framework. For more, see:
One of the simplest, and most basic security precautions that you can take is to move your application’s files into a non-public area of your webhost. Having your applications code and configs sitting there in your document root is just never a good idea. An attacker could very easily gain access to the source code of your application, as well as configuration. Next thing you know, there’s empty beer cans all over your apartment and the silverware’s missing. In general, this applies to any kind of web based application, but I’m going to be dealing specifically with Kohana, as part of my series on Getting Started with Kohana.
In a recent post, I looked into powerline, a bash status line utility. Powerline looks pretty cool, and I really wanted to run it, but try as I might, I just couldn’t get it working with my set up. Specifically, it doesn’t work really well with tmux. If you spend as much time on the command line as I do, them tmux is indispensable for serious work. That’s another post, but what I really want to talk about is how I emulated some of Powerline’s features using just the native tmux configuration. In addition, there’s a great Vim plugin, airline, which is sort of a vim only powerline. Using the combination of tmux and vim-airline gives me a status line that I’m really happy with.
I’ve been messing around with my terminal display, trying to church it up a little. I tried Powerline, but didn’t have great luck with it. So, I’m going old school and just adjusting conf files for the applications that I use all the time, mainly tmux and vim. I’ve been banging my head against tmux all day. I added some flashy stuff to the tmux statusline, but I just could NOT get the colors right. I know that there are lots of settings and tweaks for getting 256 color support right, but no matter what I did, I couldn’t get tmux to display properly.
I finally ran across a random forum post from a couple of years ago. Basically, my terminal (XFCE terminal) is set up for 256 colors, but tmux always starts with the default of 80 colors. The answer? Instead of starting tmux with
I just start it with
which forces tmux to run with 256 color support. Problem solved, and my badass statusline is working perfectly.
UPDATE: As promised, I’ve added a post about how I configured my tmux to emulate some of the features of powerline. You can read it here.
I spend almost all of my time on the command line and I use Tmux and Vim obsessively. Like a lot of people, I want my environment to be pleasing, so I was excited when I found out about Powerline, a status line / prompt utility that works with bash prompts, Vim, Tmux and a whole slew of other tools.
My first impression is that Powerline is just really cool looking. It’s nice to have something that lets you simply customize your tools in a simple way without having to dig deep into each individual tool. Unfortunately, it has some big shoes to fill and it doesn’t quite make it all the way.