No more TV

I've decided to take another step towards improving the quality of my life: giving up my TV!!!

The implications
Aside from donating my 42" LCD 1080p TV to my grandparents to replace their aging TV, I also am donating my DVD player, and the hardest donation: my PS3.  Someone in my family will be the lucky recipient of my PS3: 2 wireless controllers, 3 games (rock band, call of duty 4, and grand theft auto 4).  Consequently, I've also downgraded my Netflix account from a 3-at-a-time BluRay plan for $23.99 down to the online only viewing plan for $7.99.


Why are you ditching your entertainment center?
Because it was a real time waster for me.  There was a period in my life when I didn't own a TV, and I was such an avid reader.  But then I got a big LCD TV, and TV is always an easier choice than reading to relax, and over the years reading became less of a desire.

It all comes down to willpower, and I don't have it when temptations are in my home.  I've noticed this weakness in myself even in other aspects of my life: like eating right, or exercising.  When an easier/simpler choice is available, I always prefer that to the better choice.  Going to exercise is a harder choice than sitting at home.  Eating fruits and veggies is a harder choice than eating potato chips and ice cream.  But the harder option is usually the better option.

Use agents to screw with non-protected JVMs

The title is mostly for shock value, but it is true that you can do some pretty awesome stuff to any un-protected JVM.

I ran across this little piece of information as I was reading the source code for JConsole to see how it managed to monitor any JVM running on your box (assuming you have user permissions).  It's an extension of the java.lang.instrument agent functionality added in Java 1.5.  NOTE: This example is specifically for Java 6 and later.

So in Java 6, the Attach API was introduced, and it provided a new way to add agents to JVM: after the JVM already started running.

So let's start by creating a simple little app:

And let's start this app with: java SomeThreadedApp  No special arguments, just typical start.

Now, the JVM is running.  But now we want to modify the JVM in flight: I wanted to kill some threads in the running JVM.  With the agent Attach API, we can inject any code we want into a running JVM that isn't protected by a SecurityManager:


The agent code needs to be in a JAR with a MANIFEST.MF entry for "Agent-Class" set to the class that defines the public static void agentmain method.  More info can be found on the Oracle Java Instrumentation page.

And the last step to actually get the agent code into the target JVM, so the agent code actually run on the target JVM, I use a little JRuby:

Rails2 -> Rails3 && Capistrano->Inploy

Move over Capistrano, you had your time with Rails2, here comes Inploy.

Inploy does NOT work with Rails2.  It's was built recently targeting Rails3 exclusively.  In fact, the top level inploy.rb is a Railtie, so you just install the gem and Rake files are automatically loaded by the Railtie.

Configuration
Still uses a "config/deploy.rb" file, but it's much simpler than Capistrano.

Requirements

• Only works on Rails3
• Only works with Git version control
• Assumes you're using either: Mongrel, Passenger, Thin, or Unicorn as web servers

modrails for development

This has got to be the best way I've ever seen to run Rails in development.  I admit I used WEBrick for way too long for development.  Setting up modrails is so simple, and doesn't require any special root privileges:

gem install passenger

My personal preference is for Nginx, so just run:

passenger-install-nginx-module

This will download the source code for latest stable version of Nginx (0.8.53 at time of writing) then build and configure it for you. All you need to do is setup v-hosts for all the Rails projects you are currently developing with the following snippet added to nginx.conf:

server {
listen 3000;
server_name localhost;
root /your-rails-project/public;
passenger_enabled on;
rails_env development;
}


Tips:

• During Nginx install it in your user's home directory.
• Run Nginx under your own username.
• Remove any server configurations that listen on any port < 1024 to avoid root privileges.
• root MUST point to the public directory of your Rails project.

Starting over with a new blog

I used to maintain a blog, but I just let it die: http://vaskoz.blogspot.com/

This time I'm going to take the time to write down the interesting things I learn, mostly for myself, so that I can always find the information again.  Also, I can practice quickly and clearly writing, which is a skill a software guy like me always needs to develop.  More to come, I promise. :)