Most web and application developers that I know are using proficient in many text editors. The editor that they are using is either a result of the product that they are working on, or past experience using a particular piece of technology (extension, script, plugin, etc) that makes the daily grind a little better. I rarely find a developer who doesn’t have a problem with some facet of the text editor that they are using, and many of which feel that they are stuck for one reason or another with a particular editor because of the feature set it offers.

One thing that seems to be a common theme among these editors is that they sit somewhere between a simple text editor, providing only basic functionality of text formatting, and a full-blown suite of tools which is offered by enterprise packages such as Microsoft’s Visual Studio which costs thousands of dollars and only works on the Windows platform. Each has its specific use case, and I would never suggest creating a Visual Studio project file to edit a README file using the Markdown syntax, but every time that I have the opportunity to use Visual Studio I always walk away feeling let down the next time I drop into Emacs.

A key feature that I think is necessary in a development environment is the ability for the software package to support live documentation. This means that I want to be able pull up a quick blurb about a particular API call that I am about to make, either be it in a standard library that ships with the language of my choice, or the application project that I am working on. The discoverability of documentation needs to be in depth, but not something which clutters my code window.

The editor software needs to be able to be extended on a per project basis. There are often cases where a particular set of tools is necessary for one web project, let’s say something like CodeIgniter which uses the Sparks package management system, and another application that is written with Ruby on Rails and using the RubyGems system for extensions. And it is not merely easy just to say that all PHP applications will use the mode for PHP, and all the Rails projects will use the mode for Ruby, because often there is a frontend component which shares context between the two and is written in a language such as JavaScript (or more recently, Clojure).

Testing each project now becomes an absolute pain in the ass. I may need to manage the version of Ruby that I am running, or perhaps bounce the Apache instances so that my new configuration is picked up, or even worse the web application needs to be executed from a browser, I need to tail a log file, and pray that the browser debugging software is updated. That’s way too many context switches.

I believe that there can be a much better way of handling the day to day workflow of software development. There is a simple solution to this problem that seems to have been overlooked with fancy editors designed to be visually pleasing on the Mac. What do you think your ideal development environment would be? All developers hate writing documentation, but it is the first that we reach for when we want to understand how to work with a library or call a standard API. We cry out aloud when our text editor doesn’t index the code that I am writing and provide autocomplete. And we bitch when extending the editor becomes a chore which sometimes rivals the problems we’re trying to solve.

There is a better way to handle this.

Most smart phones nowadays have battery problems. Even the brand new iPhone is plagued with issues regarding the battery life draining away that Apple is trying to solve with software patches. But I feel that because of the large differences in software stacks that are shipped with phones it is much harder for Google, and the device manufacturers, to solve these problems across the board. Every single Android device that I have ever seen has some kind of battery issue. Luckily this is solved quite well with the JuiceDefender application that is available from the market place.

Another issue that I’ve run into is that some of these standard, “best of the breed” Google applications, just plain old fucking suck. There are at least three different mapping applications that shipped with my phone that I can count. This may be a result of the bundled software that HTC installed, but from what I’ve been able to ascertain Google owns at least two of them. What the hell is the difference between Locations and Maps? I have never had an instance when I wanted a map where I did not want to find the fucking location of a business and get walking, subway or driving directions.

My phone came with a Navigation application that Google maintains. In my opinion this has to be the best navigation software that ships standard with a phone that I have ever seen. When it works it is much more accurate than any GPS navigation unit that I have ever owned. The turn by turn directions are almost aways spot on, and the features that come out of the box work as advertised. There is one catch. Often it can take five to ten minutes to pick up a signal with the GPS satellite, and by that time you’ve probably turned around several times because you lost your fucking way. Often rebooting the phone and launching the application again will solve this problem.

By far my largest complaint is the fact that Google can’t seem to hire proper employees that can actually design a framework to make these generic applications flow. It feels like the workflow of the applications were all thrown together without any foresight into the context of where I may have been before it launched. The speed of launching new applications is generally slower than the iPhone counterpart, and responsiveness of the system needs to be beefed up. My phone is by far not a slug, but why am I waiting for Google’s own applications to chug along, hang, and finally open up another application because the mapping application doesn’t actually incorporate the navigation software?

Google needs to work on the cohesiveness of the user experience across the whole system. The software is top notch. I love being able to synchronize my contacts, calendar, and e-mail between all of my Google services seamlessly. But I can’t turn a blind eye to the fact that someone over there doesn’t seem to understand that we need to have synergy between the workflow and the interface. The fact that this doesn’t exist and the software is plain old fucking slow is making me want to go back to Apple.

I purchased a screen replacement for my iPhone 3GS and plan on spending some time this week to bring it back to working order. I think my experiment with Android is done for now. You can release hundreds of phones a year with your software, get thousands of activations every day, but if you can’t make the software and the hardware work seamlessly what is the fucking point?

The web interface is simplistic, yet beautifully crafted to allow for inline text editing right in your web browser. Shortcut commands exist to create a new piece of code, save one, and tweet it immediately. In a single day it has climbed among the top spot on Hacker News, and is already getting some very constructive feedback. The fact that both the server and the client are open source allow for internal implementations to be rolled out without any worry to proprietary code being leaked to the outside.

I know he’ll be reading this post so I’ll gripe a little, and give my wish list:

An emacs plugin would be nice, but since I know at the main site itself, and of course, go download the client and the server and deploy it at your nine-to-five today!

]]> http://thoughtlessbanter.com/2011/11/30/got-code-to-paste-in-a-haste/feed/ 0 http://thoughtlessbanter.com/2011/11/28/learning-to-rock-video-game-style/ http://thoughtlessbanter.com/2011/11/28/learning-to-rock-video-game-style/#comments Mon, 28 Nov 2011 16:30:03 +0000 JB http://thoughtlessbanter.com/?p=827 When I was younger I spent a year or so not-so-admirably trying to learn how to play the saxophone. Like many people at that ripe age there were many other things on our mind: playing with friends outside, video games, and basically anything other than the prescribed homework-esque music. I can’t remember actually ever understanding music, like most things in my life I think I probably guessed and slid through the class, but for some time I have always wanted to learn how to play music. I don’t want to study music, in fact, I hate looking at it. It hurts my brain much in the same way that mathematics does, but that does not mean that I lack respect for music (and mathematics, for that matter).

When I first touched Guitar Hero I thought it was very fun. My roommate and I spent hours upon hours staying up, not doing our class work, and battling each other with the game rifts. But it wasn’t like playing a real guitar. I’ve strummed my digits, fumbled with the frets, but was never able to spend the time to actually learn how to play. This is where Rocksmith enters the picture.

My axe.

This past Thanksgiving I drove down to Virgina to spend it with an old friend. We headed out that night and checked out Best Buy in hopes to figure out if we wanted to spend our hard earned money on some Black Friday swag when we first ran across Rocksmith. If that store in Reston, VA wasn’t able to find an Xbox 360 controller I probably wouldn’t have taken the red pill. My buddy, Drew, has been a guitar player for years and he was quite impressed with the game. Rocksmith is what Guitar Hero should have been. You plug in your guitar to the console, and strum along to the song with the actual notes, thereby learning how to play the song on the guitar. It is genius. Futhermore, Rocksmith includes video tutorials, a digital amp, and downloadable content to keep you rocking along for perpetually.

The game tracks your progress and will dynamically make the songs harder when your skill level increases (or easier when it decreases). This means that you will always be challenged, but not enough to get discouraged and put the instrument down when you can’t feel that you accomplished something. Additional game modes allow you to master individual verses of the song, replay them at a slower speed, and even rock out to a friend that has purchased the game. Unfortunately, as far as we were able to tell, it does not include Xbox 360 (or Playstation Network) support for multiplayer, so your buddy has to actually come over to jam.

I’ve only been playing the game for a few days but I already know much, much more about playing the guitar than a did a few days ago. The obvious initial cost is a bit more steep than your normal video game if you don’t own a guitar, but there are two avenues you can go: the bundle that includes a guitar (PS3) [~$200]; just the game if you already have your axe (PS3).

Since Drew and I stumbled upon an awesome Gamestop sale on the game, we were able to get it for about $25 dollars off the retail price, which allowed me to save about $40 off the price of the bundle when I went to Guitar Center to buy the instrument. But obviously if you already have a guitar, or are able to purchase one second hand, it would still be cheaper just to get the game in the box. It should work with any six string guitar, and future downloadable content to the game promise a setting for bass rifts. This was my late birthday present to myself, and I’ve been enjoying it for a few days now. I hope you’re able to enjoy it, too!

]]> http://thoughtlessbanter.com/2011/11/28/learning-to-rock-video-game-style/feed/ 0 http://thoughtlessbanter.com/2011/11/27/speeding-up-apache-with-nginx/ http://thoughtlessbanter.com/2011/11/27/speeding-up-apache-with-nginx/#comments Mon, 28 Nov 2011 04:30:08 +0000 JB http://thoughtlessbanter.com/?p=842 For the past year or so I have been using nginx as a proxy in front of my Apache instances on the server that runs this blog, and a few other websites that I manage. The virtual machine itself is running an older LTS version of Ubuntu, and most of the applications on here are a traditional LAMP setup with a few C/C++ testing tools scattered around. For the most part it is operating as web server with a small work load. But as I’ve been adding a few more services running in the background I have noticed a little slowdown with WordPress.

There are some obvious advantages to this set up: Nginx can serve up all of the static content very, very quickly without having to send it down to the Apache instances to process. This frees up those daemons to only serve application logic, which in this case is the WordPress PHP application, but would work for nearly anything that you have set up with it. I will give you a quick example of the configuration that I have set up for this site.

This is the main configuration file for the Nginx application. Most of the commands here I have plucked from various tutorials across the internet, specifically dealing with the gzip settings, and as you can see there are a few connection and process related settings. These can all be tweaked at your desire, but I find that they work best on my low load cloud virtual server. The information to note here is the location of the proxy server (127.0.0.1:8080) that the requests will be sent to, as well as some folders for errors, logs, etc. These are all standard with the Nginx installation from aptitude and should be modified to suite you. Note the section where we include any scripts that are in /etc/nginx/sites-enabled/* which is similar to the set up of the Apache portion of the LAMP stack.

/etc/nginx/nginx.conf

user  op;
worker_processes  2;
 
error_log  logs/error.log warn;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;
 
pid        logs/nginx.pid;
 
events {
    worker_connections  1024;
}
 
http {
    include       mime.types;
    default_type  application/octet-stream;
 
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
 
    access_log  logs/access.log  main;
 
    gzip on;
    gzip_http_version 1.0;
    gzip_comp_level 2;
    gzip_min_length 1100;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
    gzip_buffers 16 8k;
    gzip_disable "MSIE [1-6].(?!.*SV1)";
    gzip_vary on;
 
    include /etc/nginx/sites-enabled/*;
 
    server {
        listen       80 default;
        access_log  logs/host.access.log  main;
 
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
 
        location / {
                 include /etc/nginx/proxy.conf;
                 proxy_pass http://127.0.0.1:8080;
        }
    }
}

This configuration file sets up the particular domain inside of the Nginx proxy. It covers both the fully qualified domain name and the alias, and provides the root directory for serving up the static content. If there is content that you do not want to be served up (e.g. you have a public folder) make sure to point this only to your assets directory. We set up the path for logs to be written to (you’ll have to mkdir -p those directories) as well. The real gem here is the regular expression that specifies what static content will not get fielded off to the apache daemons. Obviously you can make any corrections here that you see fit. When you are done set up a symbolic link in /etc/nginx/sites-enabled/.

/etc/nginx/sites-available/thoughtlessbanter.com

server {
 server_name www.thoughtlessbanter.com thoughtlessbanter.com;
 root /path/to/thoughtlessbanter.com/;
 
 access_log /var/log/nginx/thoughtlessbanter.com/access.log;
 error_log /var/log/nginx/thoughtlessbanter.com/error.log warn;
 
 location ~* ^.+.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ {
              access_log off;
              expires 30d;
 }
 
 location / {
              include /etc/nginx/proxy.conf;
              proxy_pass http://127.0.0.1:8080;
 }
}

This little tidbit is necessary to send over the header information from the HTTP client to the Apache daemon. These proxy settings, with this configuration set up, will affect every single web request, so be careful with what you modify here. There are additional parameters involving the maximum size of a payload, send, connect, and read timeouts, etc. These can all be looked up with a quick Google search and modified freely.

/etc/nginx/proxy.conf

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Last you’ll need to modify your virtual host for all of the websites to now accept the connection on the new port, 8080, which is were Nginx will proxy the requests to. Be sure to set the server alias for both the fully qualified domain, and the shortened one. I am not an Apache configuration guru here, so some of the other options may not be applicable, but they seem to do the job for me. Most of my domains are further configured appropriately in the .htaccess in the document root directory.

/etc/apache2/sites-available/thoughtlessbanter.com

<VirtualHost *:8080>
              ServerAdmin jb@thunkbrightly.com
              ServerName thoughtlessbanter.com
              ServerAlias www.thoughtlessbanter.com
              DocumentRoot /path/to/thoughtlessbanter.com
              <Directory />
               Options FollowSymLinks
               AllowOverride All
              </Directory>
              <Directory /path/to/thoughtlessbanter.com>
               Options Indexes FollowSymLinks MultiViews
               AllowOverride All
               Order allow,deny
               allow from all
              </Directory>
 
              ErrorLog /var/log/apache2/thoughtlessbanter.com-error.log
              CustomLog /var/log/apache2/access.log combined
</VirtualHost>

When you have made all of the changes feel free to restart the services and test your website. Once all the instances are bounced you should be able to point the browser to the location and still bring up your website. If you check the logs located in /var/log/nginx/ and /var/log/apache2/.log you should be able to see your static content requests hitting nginx, and being served up right from there. The apache daemons will now only serve the application logic.

Let me know what you think. I’m sure I’ve made a few mistakes.

]]> http://thoughtlessbanter.com/2011/11/27/speeding-up-apache-with-nginx/feed/ 0