Get the public / local IP of your EC2 instance via command line

While you can get the public and private IP address of your Amazon EC2 instance via the AWS Console, it may be extremely useful to query it from anywhere you can make an HTTP request, such a shell script. The operation is really simple, just make a GET request to the following URL from within your EC2 instance:

Local IP:

curl http://169.254.169.254/latest/meta-data/local-ipv4

Public IP:

curl http://169.254.169.254/latest/meta-data/public-ipv4

I often use this feature to pre-configure services and update configuration files, as in EC2 you get a new IP Address each time you reboot.

 

Fixing java.lang.OutOfMemoryError: PermGen space in Tomcat

If you have ever used Tomcat for development purposes for more than 10 minutes (especially within Eclipse), you certainly have encountered the infamous messag “OutOfMemoryError: PermGen space”, and the only solution was to restart Tomcat.

Despite the fact that you should be aware that such message may indicate a deeper problem, there is an easy’n dirty solution via JVM options. I have come to the fix after browsing the Interwebs for a while, and your luck may vary. The solution consists in setting up the following set of JVM arguments:

-server
-XX:+DisableExplicitGC
-XX:MaxPermSize=256m
-XX:PermSize=256m
-XX:MaxNewSize=256m
-XX:NewSize=256m
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled

I have added them all for the sake of laziness, although the last three are said to be used with caution (especially the last one)

Setting up within Eclipse

Even in 2012 I still use the Sysdeo Tomcat Plugin because of its simpliciy over Eclipse’s WTP Servers. Open Window -> Preferences (Command + , if you are using a Mac) and go to Tomcat -> JVM Settings -> Append to JVM parameters.

Setting up Tomcat standalone

Another approach is to add the arguments directly to Catalina.sh. Locate it in Tomcat’s bin directory and set the JAVA_OPTS variable, like this:

JAVA_OPTS="-XX:+DisableExplicitGC -XX:MaxPermSize=256m -XX:PermSize=256m
-XX:MaxNewSize=256m -XX:NewSize=256m -XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled"

Just restart Tomcat and you should be good to go.

Why SELECT * is bad (or could be)

I have always been told that SELECT * FROM some_table is a bad thing, but as a lazy developer that I am, it was just easier to select everything than to care about such thing. I also think that a lot of people face this statement as some kind of heresy, but I have my doubts that they really understand what it means. One of the worst examples one can provide to defend against star selects is this:

SELECT field1, field2, fieldN FROM some_table

where field1, field2 and fieldN are ALL fields from some_table. Sure it is declarative programming, but you can’t get much more than that.

It is not hard to find a lot of reasons and explanations against SELECT *, but one does not simply understands the impact of something before having problems with it. It is the same thing for everything, from Design Patterns to fire and children: a developer can’t just read GoF and try to apply it “everywhere” without facing the hard way the effects of bad software design. It does not work that way. Also, a child will not understand what his parents truly mean when they say “don’t put your hand in the fire, it will burn and hurt a lot” without doing it.

So, when can SELECT * be bad? As I see it, it could have huge impacts in either disk and network I/O, and memory. The explanation is simple: the more data you ask for, the more the server has to read from the disk and transfer the data over the network to your application, and you could end using much more memory than you need for any given operation.

See the following graph from a DB server, showing I/O usage:

See the two big gaps? The disk I/O dropped when some queries were optimized to return only what the application really needed for each operation. Before that, the server I/O was hitting around 80.000 ~ 100.000 blocks per second, which for this setup is a lot. Not surprisingly, the web server was wasting a lot of memory as well.

In the end, you will have to list the pros and cons about each strategy, and remember that the application size matters – one may not see big improvements in small services.

And always remember that premature optimization is the root of all evil.

Setting up JMX for JConsole / VisualVM on EC2, plus Jetty Configuration

Inspecting applications via JMX can be a very valuable tool in order to keep track of Memory, CPU and any other kind of information that are provided by the MBeans of the remote Java application. However, to get it working correctly can be tricky, specially if you haven’t play with it before, as the documentation is a little sparse.

Before going into the details, here are some very valuable links:

In order to get VisualVM or JConsole working with remote applications you will need to set some JVM properties on the application you want to track. In the list below are the ones that worked for me, but keep in mind that you may have different results depending on the application and the Java version (yes, it happens). In a nutshell, you’ll need to pass these properties to the JVM:

-Dcom.sun.management.jmxremote
 -Dcom.sun.management.jmxremote.port=<port>
 -Dcom.sun.management.jmxremote.authenticate=false
 -Dcom.sun.management.jmxremote.ssl=false
 -Djava.security.policy=<policy file>
 -Dcom.sun.management.jmxremote.local.only=false
 -Djava.rmi.server.hostname=<your public hostname>
 -Dcom.sun.management.jmxremote.password.file=<password_file>

“com.sun.management.jmxremote.port requires the port number to listen for remote RMI connections. Make sure you specify an unused one.

java.rmi.server.hostname” is the public hostname (like example.com) of your server, without HTTP or anything else. You cannot use an internal address, otherwise you won’t be able to remotely access the service.

com.sun.management.jmxremote.authenticate” will require an username and password if set to true, otherwise anyone that knows (or discovers) the addres will be able to connect to your JMX registry.

com.sun.management.jmxremote.password.file” is only necessary if you set authenticate=true, and you should specify the full path of a text file with the username and passwords (in plain text) that are allowed to connect to your instance. More information about the sintaxt at http://docs.oracle.com/javase/1.5.0/docs/guide/management/agent.html#auth.

java.security.policy” is the path of a Java Policy File with the rules you need. For the sake of simplicity, you can create one with the following contents:

grant {
 permission java.security.AllPermission;
 };

You may or may not need to set the policy file (I didn’t).

You don’t need all of these properties in order to the remote JMX working. As I said before, it will depend of your luck. In my very own case, I used only these:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.local.only=false
-Djava.rmi.server.hostname=example.com

You should pass these values when starting your java application, like

java -Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9001 [.....] -jar myapp.jar

Setting up EC2
The most important thing to set when running JMX on Amazon’s EC2 is to open the TCP ports to the IPs you will connect from, otherwise the client application won’t be able to reach the Agent. For the sake of simplicity, open all TCP ports from 0 to 65535, get it working and then keep open only the necessary ports. This approach is easier because the RMI registry that JMX uses (may?) create random ports of its communication, so you’ll have to inspect it (I am no expert on the subject, in other words).

On EC2 you configure the ports in the “Security Groups” section of the AWS Management Console.

Setting up Jetty
As a bonus, here’s how to get JMX working with Jetty. The process is fairly simple, it’s just a matter of adding the configuration keys to the right files.

First of all, you need to edit the file “start.ini” (located in Jetty’s root directory) and uncomment the line that has “etc/jetty-jmx.xml“, which is probably located at the end of the file, as shown in below:

Then, add each of the JVM properties in a different line in the same file (it doesn’t matter where). It should look like this:

Please note that “–exec” is a property specific to Jetty, and necessary to make it understand the other VM properties. “-Xshare:off” disables class data sharing, which is necessary to make VisualVM work correctly. The other settings are the ones described earlier.

The last step is to configure the file “etc/jetty-jmx.xml” to instruct it to automatically create a RMI registry and set the RMI connection properties, which are essential to remotely connect to it. My configuration file (based on Jetty 8) is below:

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
  <Call id="MBeanServer" class="java.lang.management.ManagementFactory" name="getPlatformMBeanServer"/>
  <New id="MBeanContainer" class="org.eclipse.jetty.jmx.MBeanContainer">
    <Arg>
      <Ref id="MBeanServer"/>
    </Arg>
  </New>
  <Get id="Container" name="container">
    <Call name="addEventListener">
      <Arg>
        <Ref id="MBeanContainer"/>
      </Arg>
    </Call>
  </Get>
  <Call name="addBean">
    <Arg>
      <Ref id="MBeanContainer"/>
    </Arg>
  </Call>
  <Get id="Logger" class="org.eclipse.jetty.util.log.Log" name="log"/>
  <Ref id="MBeanContainer">
    <Call name="addBean">
      <Arg>
        <Ref id="Logger"/>
      </Arg>
    </Call>
  </Ref>
  <Call name="createRegistry" class="java.rmi.registry.LocateRegistry">
    <Arg type="java.lang.Integer">1099</Arg>
    <Call name="sleep" class="java.lang.Thread">
      <Arg type="java.lang.Integer">1000</Arg>
    </Call>
  </Call>
  <New id="ConnectorServer" class="org.eclipse.jetty.jmx.ConnectorServer">
    <Arg>
      <New class="javax.management.remote.JMXServiceURL">
        <Arg type="java.lang.String">rmi</Arg>
        <Arg type="java.lang.String">ec2-177-71-143-137.sa-east-1.compute.amazonaws.com</Arg>
        <Arg type="java.lang.Integer">0</Arg>
        <Arg type="java.lang.String">/jndi/rmi://ec2-177-71-143-137.sa-east-1.compute.amazonaws.com:1099/jettyjmx</Arg>
      </New>
    </Arg>
    <Arg>org.eclipse.jetty:name=rmiconnectorserver</Arg>
    <Call name="start"/>
  </New>
</Configure>

That’s all. When you start Jetty, it will log (to the console or file, depending of how you configured it) the JMX address you will need to use in order to connect to it from your local machine. Please see the following image:

service:jmx:rmi://ec2-177-71-143-137.sa-east-1.compute.amazonaws.com/jndi/rmi://ec2-177-71-143-137.sa-east-1.compute.amazonaws.com:1099/jettyjmx

In my case, the address that I should use in VisualVM is the address of my EC2 instance (ec2-177-71-143-137.sa-east-1.compute.amazonaws.com):

If the connection is successful, then you can right click on the remote host name and insert the address of the RMI registry, like shown below:

If you were lucky enough, you should be able to instrument Jetty remotely:

Setting up SQL logs in Rails 2 and 3 console

When developing Rails applications, it is often desirable to see what ActiveRecord is doing behind the scenes when using the console. By default, log messages in script/console (Rails 2) or rails c (Rails 3) are only sent to log/development.log, which I find quite annoying to keep an eye on. Much better would be if it the messages were sent directly to the console itself.

It turns out that it is very simple to achieve that. Add the following code to your ~/.irbrc file:

# File ~/.irbrc
require 'logger'

# For Rails 2
RAILS_DEFAULT_LOGGER = Logger.new(STDOUT)

# For Rails 3
ActiveRecord::Base.logger = Logger.new(STDOUT)

Simple as that. Restart the console and load any AR model, and the SQL statement should appear right before the data. For the same of simplicity, I set woth RAILS_DEFAULT_LOGGER and ActiveRecord::Base.logger, even because I had sittuations where only having one of the configurations didn’t work so well (for an unknown reason to me)

Changing the mouse cursor in Swing for the entire application

It is quite easy to change the mouse cursor in a Java Swing application, but most documentation and examples available only demonstrate how to change the cursor for a specific component. However, in an application I am developing – which has a fairly complex component hierarchy – I needed to ensure that the cursor would remain the one I set no matter where the mouse were (the most common example is the “busy / waiting” cursor, although that was not my case).

To change the cursor in a application wide fashion, you have to access the Glass Pane and set its cursor, and then make the glass pane visible – otherwise, it has no effect at all.

Take the following code as example:

int cursorType = Cursor.S_RESIZE_CURSOR;
Component glassPane = ((RootPaneContainer)someComponent.getTopLevelAncestor()).getGlassPane();
glassPane.setCursor(Cursor.getPredefinedCursor(cursorType));
glassPane.setVisible(cursorType != Cursor.DEFAULT_CURSOR);

In the previous code, “someComponent” is any JComponent you have, it doesn’t matter which one (can be a JLabel, JButton, JPanel.. just take one). The trick is to access the RootPaneContainer, and then get the glass pane from it.

The last part is to make the glass pane visible only when the cursor is not the default one. That’s all.

Complete XCode 4 keyboard shortcuts reference

XCode has had a major redesign starting in version 4. Not only the UI and Compiler have changed, but many keyboard shortcuts did too, and for those used to develop using XCode 3 the transition is a bit hairy. While Apple does not provide a complete reference guide for all the shortcuts (none that I know), some handy developers out there do.

The XCode 4 Keyboard Shortcut Reference Guide has a very complete and extremely useful list of all shortcuts, organized in a pretty PDF file. The download links are:

The status of Swing in 2011

I always have been a Web developer in my career – well, most of the time, as since the iPad was released I have been doing some heavy development on iOS, specially in the field of digital readers. Nevertheless, is the Web platform that I am most familiar with. Being a solution centric professional, it was not surprise that last month I was requested to develop a new tool that could run on Mac and Windows desktops, in order to allow newspaper and magazine publishers to create rich content issues for mobile devices and possible web readers.

The company I work for was a long time user of Microsoft solutions (only because that when they started over 11 years ago, it was easier to find Action Script developers that could do some ASP coding, thus the migration to the .NET platform was some kind of natural for them), but for the past couple of years the transition to Rails and now Java is taking place over .NET (which is something to be discussed another time), and using Java for the new tool seemed the best way to go through, as Java is a very mature platform, with plenty of developers and documentation available, and not to have to maintain totally different base codes of Mac and Windows was a very good argument.

However, I didn’t have so many good opinions about Swing (the Java GUI Toolkit), even though it is the standard approach to do desktop programming with Java. Sure that there are other toolkits out there, like SWT and QT, but I had to consider that other people would be working on the software later, doing bug fixing and general improvements, thus if it required extra training it could be a problem.

All my experience with Swing was limited to some small programs or books I read, but it was enough to let me know that:
- I’d need to deal with layout managers
- That layout managers can get quite complex or verbose very easily (or both)
- That Swing didn’t have any major upgrade for years (if any)
- I had a clue that there weren’t so many third party components
- And definitely that I wasn’t willing to do hand coding of the GUIs. A GUI designer was vital.

I have mixed feelings about layout managers. I understand why they were created, but you had to know them all in order to make a fairly complex program, as each one of them accomplish a very specific task. Also, any documentation (including books) date back to 2004 or 2005 at most, which leads one to think that it was abandoned, but this feeling goes away after some time, as Swing has almost all (if not all) major components one may need to create any program, and it is possible to create your own components if needed. Swing is mature as well, and the fact it does not get a major upgrade in years may only means that there isn’t that many stuff to have.

Ok, I may being a little too optimistic here, as certainly the API could be improved a lot and more components could be available by default, but Sun was never good at designing easy to use APIs, far from that, and the failed Java FX thing only proves that the guys over there had no clue at all of what to do.

When searching for documentation, you often will find articles dated back to ’98, ’02. This frequently helps to keep alive that feeling that you are dealing with a dinosaur and using something that will die soon – even it will not (I hope). Sure that any example code that it’s not for Java 1.1 is very welcome when you know nothing.

The complexity of doing even simple things is something you will face constantly. The Java API was never known for its friendliness – it appears that very different teams at Sun, that did not talk to each other, were developing the base class library, thus creating a lot of inconsistency across the API -, but Swing goes a step further to make your life harder. Maybe it’s because I am more confortable with web programming, but I have done a lot of WinForms and Silverlight (.NET) coding, and by far Swing is harder. Take for example Drag and Drop over a JList or (worst) a JTree: it is insanely hard to make it work, even after reading hundreds of source code lines from open source projects and discussion forums. The event dispatching system is another thing that the more I read the less I understand, and many times I found myself doing some sort of implementation of the observer pattern instead of sticking with Swing’s own classes (I ended with a somewhat simple but very effective ‘EventCentral’ class).

As for third party components, there are some, but not many, not to mention those that does not work very well. Conversely, the WinForms API of .NET (here I go again, sorry) still get plenty of stuff today, although not as many as it did once, and you can’t stop thinking about it occasionally.

In conclusion, at the end of the day Swing it’s the only choice you have if you are going to use Java for desktop development, and albeit it has a lot of bugs and a weak, non-active community, it gets the job done. I have looked at SWT and JavaFX, but the former it still even more restricted, and the latter’s first release was a fiasco, but apparently Oracle is trying to respawn it with a 2.0 version.

Manually restoring a WordPress theme after a crash

WordPress is a great blog engine, used by millions of people around the globe, and one of the best things (and probably also one of the main reasons for its success) is an easy to use and huge database of plugins and themes. With just some clicks, you can change the theme or install a cool new plugin to enhance your blog.

However, sometimes not everything works well, and you may end with a non-working blog if you installed a problematic (or old) theme. You see, my girlfriend loooooves themes, so much that she tries a new one every day. But sometimes one of those themes doesn’t work, thus trashing hers blog, including the admin area.

There is a way to manually fix it, but you will need access to the database (be it via a terminal, or something like phpmyadmin). Open the database where wordpress in installed in, and find the values you’ll have to change:


select * from wp_options where option_name like '%current%' or option_name = 'template' or option_name = 'stylesheet';

It should return something like this:

+-----------+---------+---------------+--------------+----------+
| option_id | blog_id | option_name   | option_value | autoload |
+-----------+---------+---------------+--------------+----------+
|        45 |       0 | template      | Ledgy        | yes      |
|        46 |       0 | stylesheet    | Ledgy        | yes      |
|      5810 |       0 | current_theme | Ledgy        | yes      |
+-----------+---------+---------------+--------------+----------+

In this case, “Ledgy” is my problematic theme, and I want to change to another one that I know that works (like the Default theme, or the previous one, if you remember the name). In order to find the available themes you have, go to the wp-content/themes of your wordpress installation. Each of the directories there represents the theme’s name you’ll use to update the options table. In my case, I know that the “SP142″ works fine. 

In order to update the table, execute the following statement:

update wp_options set option_value = 'SP142' where option_id in (45, 46, 5810);

Just make sure to use the correct IDs, and you are done!

Setting up Git colors in the terminal

I am adding this here so I won’t have to try to remember once again which colors I’m used to use with Git. If you already didn’t know, it is possible to set up git so that it colorizes the statuses, logs and so on when working via a terminal, which is much better than the plain old monochromatic scheme.

Add the following to your file ~/.gitconfig:

[color]
branch = auto
diff = auto
status = auto

[color "branch"]
current = yellow reverse
local = yellow
remote = green

[color "diff"]
meta = yellow bold
frag = magenta bold
old = red bold
new = green bold

[color "status"]
added = yellow
changed = green
untracked = cyan

Now, when you use a command like git status, it will use colors to differentiate the information.