Thoughtless Banter – John Bellone

Technology

May

Towards A Better Code Editor

Posted by JB at 10:35 pm

Most of my day is spent staring at the blinking cursor of my text editor. This is true for many people nowadays as most office work happens on the computer, but for programmers – the very same individuals whose creativeness are the building blocks for software – can’t seem to find a workflow that feels right. As a developer I find myself getting frustrated every time that I have to reach across my desk for a mouse, switch to a separate application to look up some documentation, or drop into a terminal window for some quick bash kung-fu. I am a firm believer of using the proper tool for the job, but I have been writing code for over ten years now and have yet to find something that fits the purpose.

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.

Jan

Why Android Pisses Me Off

Posted by JB at 11:16 am

After a few years of iPhone ownership I made the mistake that has become signature of clumsy Apple owners as of late. The seemingly innocent mishap where your phone slides out of your hands and contacts with a surface, creating a spider-like hairlike crack across the glass screen, but rendering your phone still usable until you poney up the benjamins to replace the screen. At the point that this happened my phone was already two years old, I was eligible for another contract extension, but I refused to sign my life away to the behemoth that is AT&T for another two years. I got a really good deal on an Android phone, off contract, so I went down that route and for the first few months fought many battles that, I thought, were eventually won.

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?

Nov

Got Code To Paste In A Haste?

Posted by JB at 11:34 am

Haste
Tools

A very close friend of mine released a new type of pastebin that has some very fancy features that really make it shine over any other interpretation on this type of idea. The client, which is written in Ruby and open source, is quickly installed through the use of the standard Ruby Gem installation approach. At this point you can immediately echo any code that you wish into the haste command on the terminal and it will be pushed up to a node.js powered backend which stores it, syntax highlighted, and returns a URL back down to you.

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:

It’d be nice to allow for a quick shortcut for tab spacing. I work in C/C++ every day, and like to have a little bit more tab that you have there by default. More tab please!

In the future when the Gist API becomes public it’d be really awesome to allow for forking, and pushing back up to your Gist.

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!

Nov

Learning to Rock: Video Game Style

Posted by JB at 11:30 am

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!

Nov

Speeding Up With Apache With Nginx

Posted by JB at 11:30 pm

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.

Nov

Visual Studio, WPF and XAML

Posted by JB at 5:30 pm

The last time that I touched C# was about four years ago. I had just finished my first semester at NJIT as a sophomore transfer, and I took a summer course with Daniel Boston where we developed a payment gateway for the Vector newspaper. Since neither of us had ever used any of the .NET languages, and one of our requirements was that this had to run on a Windows server, we figured it would be a very good learning experience. We taught ourselves the ASP.NET and C# syntax in only six weeks, working tirelessly during the nights over Skype (we both had summer jobs), to complete our project on time and present it to the class. Needless to say, we succeeded, but got burned a few times by how much a pain in the ass ASP.NET was back then.

A couple of weeks ago I had the opportunity to get familiar with one of our developer tools at my day job, which is written with C# and WPF, and I have to say that I am quite impressed. Microsoft has identified a key point in the application development pipeline, and as far as I can tell, made a valiant attempt at solving it: the user interface should not be tied directly to the application (business) logic, and using WPF with XAML you give designers the ability to modify the layout of the application through the use of themes. This approach is very similar to how the web development process, through the use of HTML and CSS, allows for web designers to not affect the application logic that sits in the “backend.”

WPF 4 Unleashed

This has been a huge help learning WPF and XAML.

I haven’t yet spent enough time with WPF 4.0, but from what I can tell this is the way to be developing all future Windows-based applications. After a little searching it unfortunately looks like that the team behind Mono will not be supporting WPF in the near future. It would be nice to be able to use XAML and C# to quickly develop cross-platform applications which would use the native API for each platform. That means Aqua for Windows (Vista/7), Cocoa for Mac OS X and either Gnome or KDE for Linux/Solaris/Unix. Not to mention each time that I get a chance to use Visual Studio I feel like any other software development IDE pales in comparison, but I have felt that way for awhile now.

If you’re interested in getting your hands into WPF 4.0, XAML, and the whole caboodle, head on over to Amazon.com and pick up Adam Nathan’s WPF 4: Unleashed which is the first programming book that I have seen that has high quality, full color, code samples. You won’t be disappointed!

Jul

C++ Async HTTP Server

Posted by JB at 12:00 pm

A few days ago to the sweet, sweet melodies of Billy Joel, I woke up in the wee hours of the morning to code up a very crude C web server. Of course, I tried to pass it off as a C++ implementation, but in reality I was pulling the wool over your eyes – the only C++ was used to build error messages, and the actual message to send down to the client. Not to mention it was a very crude, basic, implementation of socket handling in C. Nothing fancy.

Yesterday I was talking with some kind folks at the re:build 2011 conference in Indianapolis, and it got me to thinking that there aren’t enough examples of C++ applications talking to the web. You know, actual C++, using the boost libraries and what not. So this morning, after grabbing my amazing breakfast burrito at Henry’s in downtown Indianapolis I scoured the Internet and re-wrote my example application in Boost.Asio.

The code is much simpler, straight forward, and just damned better to look at. As always it is up and available at my Github account for consumption. If you’re interested in seeing the actual difference in implementations than go no further than right here.

I have a few more ideas on web services written in C++, but that’s for another day. Let me know if you have any questions. As always, enjoy the code and report any bugs.