Digital Marketing & Communications

We've seen 1s and 0s you wouldn't believe

Tagged: java

Doing things better: relaunching our online Undergraduate Prospectus

  , , , , ,

📥  Communication, Design, Development, Marketing, Team, Tools

BBA-blog
Our current online Undergraduate Prospectus launched back in February, after a year's worth of hard and rewarding work. From that time there were two key aspects of the project that gained us huge successes, which I will be outlining in this post.

Focus Group sessions

Something that we'd started with the redesign of our homepage, we continued and enhanced with the revamp of the prospectus. I cannot understate the value in carrying out this activity. Suspend your cynicism that this is a vapid, marketing focused (well, it is but actually it's more consumer focused) assumption affirming, lip service to finding out your user's needs. This is the only time you gather qualitative data from your target group. Otherwise you're mostly guessing.

I mentioned affirming assumptions. That's actually a good thing. Our Esteemed Designer wasn't sure about the pink highlighter circling around the Apply button, but when we took it to our first focus group at a nearby school we were pleasantly surprised by the enthusiasm and positive reception. This was a group of Gifted and Talented young people in year 12, very much amongst our target demographic. They felt that our colourful design was right for 16-17 year olds and not "dull like other universities, who treat us like we're 30".

The colourful design is right for us as 16-17 year olds and not dull like others, who treat us like we're in our 30s

Another session a few weeks later (this time with around 60 students - a logistical triumph!) repeated this sentiment: that the colours and the pink highlighter on Apply resonated with them.

What's interesting is that we could easily have ditched that design element. Because we didn't feel sure, or our stakeholders in their 40-50s might have objected. The feedback from the focus groups gave us the confidence, and the evidence, that it was The Right Thing To Do.

This was the first time I'd personally been involved in running a focus group and interacted directly with our "clients". Having feedback that what you're doing is good, is deeply rewarding. Since then I've also been involved in running focus group sessions for the School of Management website. I hope to be involved in more of these.

The Play Framework

This point is on the technical implementation of the prospectus, but one worth stating. Up until now we would be using some heavyweight, enterprise level software frameworks to build our systems with: Struts 2, Spring and Hibernate. The very same toolset that blue-chip companies will use. But in being so heavyweight for a small team of developers it means, excuse the pun, a lot of weightlifting to get small things done. For example we would have to do a lot of work on configuration and setup to support the features we want to build. This was a burden that got in the way of achieving the goal of building the actual feature. And would also be hard to maintain.

We had plenty of experience to go by that lead us to this conclusion, like building the previous prospectus with this toolset.

Before starting this project last year we were assessing a new Java web-app development framework called Play. Our first reaction was that it felt a lot like Ruby on Rails, but this is no surprise as Rails espouses "convention over configuration" and Play is simply following good conventions.

The main things we love about Play are:

    The focus we can place on building features compared to our previous working practises
    The plugin system where commonly required features are already implemented which you can (ahem!) plug in.
    But mostly it's the rapid deployment during development.

The traditional workflow for Java requires an intermediary compilation step and you have to sit there while you wait for it to finish. With Play you simply refresh your browser as soon as you've saved your file.

These two aspects of the the online Undergraduate Prospectus project have helped to make it the success it is now. Play made getting something up and running quicker than we have in the past - by allowing us to not burn time on startup costs. Running the focus groups has ensured that we are delivering to our prospective students what they desire and require. Two ingredients we'll be using again in future projects.

Deploying Struts2

  , ,

📥  Development

Hello and Happy New Year to you all!

As a followup to Kelvin's post on the topic, I thought I'd expand on some of the trials and tribulations we had adopting a new Java framework.

We've been developing all our most recent Java applications in Struts2. This has brought both tears and laughter but among the biggest problems we faced was that once we'd deployed a few of our apps to our live Tomcat server we realised that we couldn't deploy new a version without shutting down the entire instance, and therefore making all our other apps unavailable at the same time. Yikes!

It turned out that Spring, which we use for dependency injection, was holding onto a couple of our jar files even when we were undeploying the application. We'd seen this on some Windows development machines before but not on Linux or our Solaris deployment machines. This time however, the problem didn't occur at all under Windows, about half the time on Linux and 100% of the time on Solaris.

The way we'd dealt with this previously was to get the Windows-based developers to add antiJARLocking="true" to a hard-coded Context in their server.xml which keeps the problem nice and localised.

That wouldn't work for our live servers since, as the documentation says, "applications that are outside the appBase for the Host will cause the application to be deleted on Tomcat shutdown." which means that for our configuration each time we stopped Tomcat would result in a number of applications being completely deleted!

We eventually solved the problem by writing application-specific META-INF/context.xml files that specified "antiResourceLocking=true". This means that we can now deploy new versions of our applications and shut down our server without it deleting everything.

This was a reasonably pesky bug to track down since of course I couldn't use my local machine (where the bug didn't appear) or any of our standard development Tomcat instances since I could very easily be deleting people's applications every time I restarted the server. Lesson learnt though and we'll be paying more attention to the deployment configurations we use in future!

Testing controllers with Struts2

  , , , ,

📥  Development

We started using Struts 2 for the first time in our eProspectus project. In fact we're using Hibernate/JPA+Spring+Struts2.

To me, one of the most obvious advantages that Struts 2 gave us was the ability to unit test our controllers. Before now, our project architecture usually consisted of Hibernate+Servlets+JSTL JSPs. We were only unit testing our model and DAO. Though there are ways for us to unit test Servlets, it's not as straightforward as simply instantiating an action class and chucking a load of data at it. Servlets would require mocking up a request for example.

What I didn't like though, was keeping track of what parameters were being passed in and what objects were loaded in the action classes. I often fell foul of writing tests that passed and seeing errors in the web app. It was simply because the params or the objects loaded for the action classes in the tests didn't match up with the web app.

I think it's simply a reflection of some of our (my!) action classes. Not breaking the OGNL debugger console would have probably really helped. We really liked that console.

The eProspectus project was also my first opportunity to use Java Annotations. Support for annotations were provided by Spring, Hibernate's implementation of JPA and in Struts 2 action classes. Obviously, you're no longer writing XML for your most of your configs (just a couple). So there aren't masses of xml files that accompany each of your model classes for example - halving the number of files you'd have. The biggest win for me is being able to instantly see the config for a class in the code itself, rather than opening up a separate XMl file and switching between the two files. It just made life so much easier.

There was some pain in getting to grips with Struts 2, especially when we ignored the warnings in the docs that said certain features were experimental (I actually can't remember what that was now...) but we've built up a significant amount of new knowledge and I'm especially happy to have Spring and JPA under my belt.