Category: Developer Tools

Anything that helps you write great code

  • Simple vs Easy

    This blog post is inspired by a wonderful and entertaining video called Simple Made Easy by Rich Hickey. It explains the difference between easy & simple, and why we’re obsessed with the wrong one. It’s a sentiment I’ve known for a long time but I’ve never seen it put in to words before. The rest of this post is just my brief take on the subject, watching the video is highly recommended.

    Simple is the opposite of complex, it implies there won’t be a big cognitive overhead involved in what’s being done. It doesn’t imply that what’s being done will be quick or require only a little effort. Easy is the opposite of hard or difficult, it implies that only a little effort will be needed. It doesn’t imply things are going to be straight forward or understandable. Both these terms are subjective but the difference is very important and they are often used the wrong way round.

    SimpleVsEasy The trade off is that easy is very quick to get going with, “Hey look, I typed these commands in and now I have an app” but two months in to the project understanding the app will take more time than it should; “What’s this dependency for, do I have to use xml for my data?!”. The video I espouse above contains this diagram, it illustrates the point well. Simple tools, languages, frameworks etc… may be slower to get stuff done with initially but in the long run they will be faster as everything makes sense and the app isn’t getting bogged down in increasing complexity as time goes on.

    As a software engineer I often find myself working with easy and complex tools, languages or frameworks but I’d much rather use something simple and put in a little hard work to build something that is itself simple. Simple code is easier to debug and maintain, especially for people new to it. I think something can be both simple and easy but a lot of the time people probably just have a lot of experience and deep knowledge about something complex that makes it seem simple to them. I’ve often noticed how new software comes out and people love it as it’s simple while still doing something useful. Then they want to make it better, they add features, which is fine, but unfortunately they also try to make it easier to use. In doing so it becomes complicated and eventually requires people to climb a steep learning curve to understand it. The video makes this point (probably better than I do) and other related points but this one really stuck out for me. Now go and watch the video.

  • Firefox extensions with Travis CI

    Developing an extension for Firefox is no different than developing anything else and CI is a good idea. It’s actually very easy to use Travis to run your test suite. For those that don’t know, Travis is a great resource for running CI on your open source projects for free.

    Travis will install any version of Firefox you need and as it has them cached it’s much quicker than downloading it yourself. Specify the version with an addons element. The commands in the before_script section setup a headless window service and unpack Firefox. The tar command uses a wildcard to match the Firefox version requested, less to remember when updating the version. The environment variable JPM_FIREFOX_BINARY tells jpm where to find Firefox. This should be all you need to run jpm on any jpm based extension with Travis.

    language: node_js
    env:
      global:
        - DISPLAY=:99.0
        - JPM_FIREFOX_BINARY=$TRAVIS_BUILD_DIR/firefox/firefox
    addons:
      firefox: "38.0"
    before_script:
      - sh -e /etc/init.d/xvfb start
      - tar xvjf /tmp/firefox-*.tar.bz2 -C $TRAVIS_BUILD_DIR/
      - npm install jpm -g
    script:
      - jpm test
    

    You can see this in action with a little project of mine over at Travis.

  • Sample Apps for Cloud Foundry

    Working on the Java Buildpack means lots of testing with unit (over 99% coverage) and integration tests but we also have a suite of sample applications to do complete system wide testing. They are all tested during our CI builds and might be useful for people that want to play around with different application types on Cloud Foundry. Find them here in GitHub. The project has a good README so I won’t duplicate it but we have various apps for Spring Boot, Grails, Groovy, Java Main, Play, Ratpack and Spring MVC. Each app supports a number of URL end points that allow exploration of the environment the application is running in from the classpath and environment variables to bound services. These are also all well documented. Getting the applications running is simple. The cf cli tool is required to push applications from the command line, install instructions are here.

    git clone https://github.com/cloudfoundry/java-test-applications.git

    cd java-test-applications

    ./gradlew

    cd ***-application

    To give the application a more descriptive application name the manifest.yml file should be modified.

    cf push

    That’s it. The console output will show the URL the app is bound to. It’s now possible to start looking at the endpoints documented in the README and exploring the applications environment and any bound services.

  • Cloud Foundry Video Shorts

    Firstly, CloudFoundry has a shiny new logo. It’s a little more abstract, harder to understand at first glance but I like it, much cleaner.

    CloudFoundryVertical-2

    I’ve done two short videos demoing some new features in the Cloud Foundry Java Buildpack with my finest monotone voice. The first is about using New Relic, it’s now easy. Bind you application to a New Relic service instance and the Java Buildpack will take care of the setup in your application. The second video is about DBaaS auto-reconfiguration. You can rebind your application to different data sources and provided the right Spring beans are available in your application they will be changed to connect to the new database automatically.

    http://youtu.be/qIYU3uOVqTc?list=UU0ZYS0Y7b5oiVLvxGf4magw – DBaaS auto-reconfiguration (1:32)
    http://youtu.be/UMwPj1nTm3U?list=UU0ZYS0Y7b5oiVLvxGf4magw – Binding New Relic to Applications (1:52)

    Enjoy.

  • Monitoring Node Apps on CloudFoundry

    CloudFoundry-1

    There are a few options for monitoring Node applications including NewRelic and NodeTime but I’ll be looking at StrongOps (previously known as NodeFly) by StrongLoop. It’s easy to get up and running with both NewRelic and NodeTime but the StrongLoop offering is particularly easy on CloudFoundry thanks to its custom build pack for deploying applications on Cloudfoundry, more on that later. They also have a lot to offer Node projects in addition to monitoring, check out their website for all the details. StrongLoop also do a lot of work on Node itself so arguably they know more about Node than most.

    Creating an application

    To get started you need an account at StrongLoop and to download their suite. This includes a command line tool slc which includes extra helper commands to get the most out of their offerings including some sample applications. I’ll use a simple instant messaging application to get started.

    slc example chat my-chat
    cd my-chat
    slc install
    node app.js

    The application should start and be available at http://localhost:1337, try opening it in several windows and talking to yourself.

    Monitoring with StrongOps

    Now there is a working application let’s get it running with StrongOps locally before deploying to Cloudfoundry. Create a StrongOps account if you haven’t already and then on the command line use slc to associate the application with StrongOps. Staying in the root of the application.

    slc strongops
    Please enter your: email address:
    Please enter your: password:
    You are now logged in. Welcome back, cgfrost.
    Your StrongOps credentials were written to: ./strongloop.json

    A strongloop.json file will be created in the root of the application that contains all the details needed to talk to the StrongLoop servers. There is an option to use package.json instead if you wish. Running the application again would send monitoring information to the StrongOps console but lets keep going and deploy to Cloudfoundry first.

    Running on Cloudfoundry

    Login in to your favourite Cloudfoundry provider, I’m using Anynines which currently have a free public beta. They are running on Cloudfoundry V2, it is not possible to run StrongOps on Cloudfoundry V1 as V1 doesn’t support custom buildpacks. Buildpacks are originally a concept that Heroku came up with, it is a piece of code that deploys and starts certain application types on a PaaS. It’s through buildpacks that PaaSs like Heroku and Cloudfoundry can support so many different runtimes. To use Anynines the best way to get going if your new to Cloudfoundry is to install their a9s Ruby Gem, see here for details. Once you have an account start by targeting and logging with the cf command line tool.

    cf target https://api.de.a9s.eu
    cf login

    Create a manifest.yml file to tell Cloudfoundry how to deploy the application. The cf command can create an application manifest but some of the config required will be missing. This is the manifest required for the sample chat application.

    ---
    applications:
    - name: chat
      memory: 512M
      instances: 1
      host: chat
      domain: de.a9sapp.eu
      command: node app.js
      buildpack: https://github.com/strongloop/dist-paas-buildpack.git
      path: .

    This manifest contains come common Cloudfoundry config such as memory and the number of instances as well as specifying the start command and buildpack to use. The command configuration should give the same command used to run the application locally, it’s required as Cloudfoundry isn’t able to detect every type of application and this ensures the Node application will actually be started. The buildpack configuration tells Cloudfoundry to explicitly use a buildpack from StrongLoop. This provides the StrongLoop Suite including the same version of Node as you have locally for development as there is no guarantee the version the Cloudfoundry provider has in its Node buildpack will match.

    cf push

    Once the application is pushed, go to your browser and test that the application is running (http://chat.de.a9sapp.eu with the above manifest). Talk to yourself some more to generate some traffic. There should now be traffic reported in the StrongOps console, http://strongloop.com/ops/dashboard. I found there is a minute or two of lag so be patient.

    StrongOpsDashboard

    Have a look around the console to see what metrics are available and try out the memory/CPU profiling. The metrics will be a little limited by the simple sample application but it will give you a good idea of what’s there. There are also some features only available to the paid plans. Happy monitoring.

  • Eclipse Summit Europe 2010

    Between moving house and going on a long holiday my personal projects went a little quiet but I’ve been at the Eclipse Summit in Europe in Ludwigsberg this week so I thought I’d write up my thoughts.

    This was my first ‘big’ Eclipse event, on the one hand it’s nice to have so many knowledgeable people around but on the other hand I felt the level of presentation had to much higher than normal to impress. I certainly enjoyed all the ones I went to.

    I talked about Eclipse Virgo as a part of the RT tutorial and gave a new talk about our Snaps prototype for modular web apps. I even managed to shift give away 50 memory sticks with Vrigo and STS on. This was really well timed due the new release of Virgo going out this week.

    I think the things I’ve taken away from the sessions are:

    • Go and have a play with EGit, seems to have come a long way, will be interesting to see if I start using it day to day after getting so comfortable with the command line Git and GitX.
    • Jetty is really cool! Seems to have a lot of work done to help it scale & perform well, wonder how v8 will stack up against Tomcat 6 in the performance stakes. Really looking forward to using it in Virgo and maybe playing with some of the newer features for the Virgo Admin Console.
    • The Emma code coverage tool hasn’t been worked on in years but there is a new project keeping the good work going, EclEmma. The thing that really got me interested in the Ant integration.  I’m wondering if it can be integrated in to the CI build and fail it if the code coverage is too low.
    • Finally, integration into Eclipse 4.x of OpenSocial gadgets. Made me smile. I’m trying really hard to think of a good gadget that I will want in Eclipse. Maybe something that looks up web based docs for various languages…

    Overall I had a great time and the social side was fun too. Good to put faces to names I’ve been talking to but never met in real life. There was some interesting dancing going on with the band on Wednesday night. Looking forward to Eclipse Con 2011 now.