Java Developers getting started with Linux

These days it’s helpful for developers to have a base set of skills with Linux, and it’s easiest to learn something with a goal in mind. For Java developers getting started with Linux, I recommend they try installing Linux on a virtual machine and setup a Tomcat service as a starting point. The high level steps are listed below.

duke-tux-luv

This is intended to be a starting point for further searching (i.e. Google-guided learning).

  1. Install VirtualBox – a great open source platform for running virtual machines.
  2. Build a Linux virtual machine from ISO image. You’re likely using Redhat in production, so CentOS is a good place to start.
  3. Connect to the VM using SSH. Windows users will need Putty here.
  4. Do some reading around the importance of running applications under a user account other than root.
  5. Install the Oracle JDK instead of OpenJDK which comes bundled.
  6. Install Tomcat under a dedicated user account. You should be able to access Tomcat via port 8080 from a browser on your host machine. This may require configuring the built-in Linux firewall.
  7. Configure Tomcat to run as a service (so if you reboot the machine, it starts automatically).

Beyond this, it’s worth knowing how to do the following at the command line.

  • Install ntp via YUM.
  • Change file ownership (chmod / chown).
  • Create symbolic links.
  • Edit files using vi (or, learn a convoluted set of keyboard commands).
  • Check running processes / kill a process.
  • Extracting tar.gz and zip files.
  • Get files using wget and curl
  • Upload files via scp.
  • Modify environment variables in your bash profile.
  • Search using find and grep.
  • Follow a server log using tail.

Whilst I’m no expert, knowing the above has always helped me get around Linux. Hopefully it provides a good starting point for others.

Dropwizard with SSL

If you’re looking to build a web service in Java, Dropwizard is a great place to start. Unfortunately the docs aren’t explicit on how to configure SSL and the example project (for version 0.6.2) doesn’t cover it, so I did slightly fight to figure it out. This is how I did it:

1. Put the example keystore from here into the root of your project.

2. Make sure your configuration file includes the following:

http:
   connectorType: nonblocking+ssl
   port: 8443
   ssl:
      keyStore: ./example.keystore
      keyStorePassword: example

Note: This only applies to the latest released version of Dropwizard (0.6.2 at the time of writing). The SSL config is changing in the upcoming 0.7.0 release, and the 0.7.0 example project covers it.

Following your digital footprints

I’m pleased to find myself back to building teams of late, in my role heading up Ecommerce Software Development at Pearson Technology. Specifically, I’m recruiting Java developers right now. It’s always good to talk tech with someone new, and a good way to learn about tech I’ve not had a chance to play with, so I’m always learning something new (crash, bang).

always-learning-cmyk-green-lo

A nice change since my last bout of intense recruitment (a couple of years back) is that candidates are increasingly providing links to their digital footprint, which makes the process of reviewing candidates more insightful, and actually fun, opposed to simply staring at a black & white two-pager.

In particular, I like seeing links to:

  • Stack Overflow – A link to a profile is very useful. It’s not all about the reputation score (I’m a paltry 191 to date) – I’m looking for insightful, concise, well considered answers, which may indicate an ability to coach others, without being preachy or high-and-mighty.
  • GitHub – Any examples of side projects or contributing to open source projects are very useful when deciding if this is someone we should be talking to. Some candidates are setting up ‘showcase’ repositories, which I’m on-the-fence about. But these still have their uses.
  • Blog – If they’re writing a blog which is relevant to their profession, this is always interesting to read ahead of a conversation. A good writing style, ability to articulate an idea in a concise manner, balanced argument, being opinionated (in a good way). All helpful things towards the process.

None of the above are essential, but definitely help one get a better handle on the capabilities of a candidate right at the outset, and demonstrates a willingness to collaborate with others.

The Hula scripting language

I’ve been tinkering with a scripting language for writing web applications for a while now, which I’m calling Hula. 

Hula came about because I figure there must be an easier way for web applications to glue together incoming requests and the underlying service layer. In the past 10 years I’ve seen quite a number of different Java MVC frameworks which attempt to solve this, to varying degrees of success. And I’ve seen implementations of those frameworks, with varying degrees of success. And also a fair amount of evil.

The glue part can be a bit boring at times: You’re marshalling/demarshalling parameters from a request, calling services, storing stuff in the session, dealing with cookies, etc. It’s all boilerplate stuff.

Also, alot of what’s happening in the application layer (glue) has been done countless times before. Signups, Login, Logout, Registration, Forgotten Password, Subscribe to Newsletter. Why code it again?

My ideal would be to drop pre-built components from a library, straight into my app.

Some other things that irk me in writing web applications:

  • When they don’t follow a configuration by convention approach.
  • Having to recompile, redeploy for simple routing mistakes (though JRebel helps).
  • Lack of isolation from the platform, leading to issues with thread-safety, multi-tenancy.
  • Not having an out-the-box approach for clean URLs

I could go on, but sticking with positives, I went with implementing a scripting language for a variety of reasons:

  1. As John Pavlus says, programming languages could be more intuitive, and I couldn’t find a language I liked for this job.
  2. Scripting is one way to get around recompiles.
  3. By using a purpose-built scripting runtime, scripts are easy to pass around, well isolated from the container, and better at multi-tenancy.

So what did I end up with? Below is an example Hula script for an ecommerce site, for looking up the customer cart details, for display.

GetSession as session
If $session = null OR $session.cartid = null
   Redirect nocart
End
GetCart $session.cartid as cart
SetView cart

I hope it’s pretty obvious what this script is trying to do, but I would say that. To be clear, the intention was:

  1. Gets the customers session
  2. Checks the session exists, and they have a cart identifier. (If not, it redirects to another script called nocart).
  3. Looks up the cart by the identifier (from the session)
  4. Specifies which page should be rendered

Syntactically, each line starts with a command, plus an optional set of parameters, and an optional return value. More here. The idea behind this is to encapsulate any boilerplate code, such as getting a session, setting the view to render, in the command.

I’m pretty confident that, following good application design principles, the range of operations one performs in the application layer should actually be quite limited – the majority of which could be serviced by a relatively small number of commands.

When building an application with Hula, one may need to build a set of commands to provide access to their application-specific services from Hula, however this is likely code you’d need to write anyway, and these commands would be reusable throughout the Hula scripts.

It’s early days, but Hula is available on GitHub as two projects:

  • Hula-lang – the parser and runtime for the Hula scripting language.
  • Hula-web – an implementation of Hula for web applications.

Moving your iPhoto Library to the cloud Part 2

In follow-up to my previous post on this subject (here), I’ve recently moved away from using Dropbox for backing up iPhoto libraries, and switched instead to Crashplan.

The main reason for this is that I decided to slice up my single, monolithic iPhoto library into several separate libraries to improve performance of iPhoto, however I soon found (after a 100GB sync to Dropbox. Yeah) that the newly-created iPhoto libraries were using symbolic links again, and this time differently to the fix I used last time. I thought this was only something earlier versions of iPhoto did? Anyways, since Dropbox still don’t support symbolic links (please vote for this feature!) and backups are supposed to be something you can set and forget, I decided I needed a more fitting solution.

Crashplan was recommended to me by two people separately off the back of my previous post, so that’s how I came to it. I haven’t got much to say about Crashplan yet (except maybe upload of my initial backup seemed slow) but I do like their iOS app. More when I’ve had a chance to play with it a bit more.

Using Decorators in Velocity without SiteMesh

Many posts on the subject of using decorators with Velocity do this using SiteMesh. I’ve been using a custom Velocity Directive that I thought I’d share. The Directive looks like this:

public class Decorate extends Parse
{
   public String getName()
   {
      return "decorate";
   }
   public int getType()
   {
      return BLOCK;
   }
   public boolean render(InternalContextAdapter context, 
                         Writer writer, 
                         Node node) throws IOException, 
                                           ResourceNotFoundException, 
                                           ParseErrorException, 
                                           MethodInvocationException
   {
      StringWriter sw = new StringWriter();
      node.jjtGetChild(1).render(context, sw);
      // store the contents against the variable
      context.put("body_content", sw.toString());
      return super.render(context, writer, node);
   }
}

This is wired into Velocity during initialisation as follows:

Properties p = new Properties();
p.setProperty("userdirective", "your.package.Decorate");
Velocity.init(p);

Now you can create a Velocity template called layout.vm:

<html>
   <body>
      $body_content
   </body>
</html>

This layout can be reused by multiple Velocity templates by nesting content within the decorate directive:

#decorate("layout.vm")
   <h1>Page Title</h1>
#end

That’s it – a nice simple decorator that doesn’t require any extra scaffolding or libraries.

Configuring SSL for Tomcat 7 on Windows

There are dozens of guides for getting SSL working on Tomcat, but I never find one that quite fits the bill, so here’s my super-short guide to configuring Tomcat 7 (7.0.37) on Windows to serve SSL-encrypted requests for testing purposes only.

1. Install & Setup OpenSSL

You need OpenSSL to generate a certificate and a server key. You can download a binary release of OpenSSL from here: http://slproweb.com/products/Win32OpenSSL.html (I used the light win64 version).

During installation I opt to install binaries in the OpenSSL installation directory (The OpenSSL binaries (/bin) directory) to keep things tidy. 

Open a command prompt and add OpenSSL to the path to make it easy to work with:

set PATH=%PATH%;C:\OpenSSL-Win64\bin

Tell OpenSSL where its configuration file is:

set OPENSSL_CONF=c:\OpenSSL-Win64\bin\openssl.cfg

2. Create Certificate & Key

2.1: Generate a server key file:

openssl genrsa -des3 -out server.key 1024

I specified a password of ‘changeit’

2.2: Generate a Certificate Signing Request (CSR):

openssl req -new -key server.key -out server.csr

Supply the password you just created, and press enter through each option.

2.3: Remove the pass phrase from the server key:

copy server.key server.key.org
openssl rsa -in server.key.org -out server.key

2.4: Generate the self-signed certificate:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

You’ll now have the following files in your directory:

server.crt
server.csr
server.key
server.key.org

3. Configure Tomcat 7

Copy server.crt and server.key to your tomcat conf directory. Configure the SSL connector as follows:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
 maxThreads="150" scheme="https" secure="true"
 clientAuth="false"
 SSLCertificateFile="..\conf\server.crt"
 SSLCertificateKeyFile="..\conf\server.key"
 SSLVerifyClient="optional"
 SSLProtocol="TLSv1"/>

Tomcat will now support SSL for the connector listening on port 8443. When you go to an https URL your browser will warn you that the certificate is not trusted because it’s a self-signed certificate, but you’re just testing right?

Thanks to these guys for their related posts: