Computer Games, Games

Medieval Total War 2

So I got through the tutorials last night and today resumed control on the Kingdom of England after many months away or playing the Welsh in the Viking Invasion.

My first impressions were made up of two elements. Firstly there is the usually shoddy Creative Assembly QA. Trying to set the game’s resolution to my LCD screen’s resolution crashed the game. Not mind you before a pop-up appears warning me that a graphics problem has occurred. The second is that soldiers seem a lot faster than before. Total War Rome felt a lot faster than the original Medieval but this is faster again. I’m not sure if this is simply to do with the feeling of gameplay. There was a lot of marching and counter-marching before.

The AI also feels a lot smarter. In my first battle a group of spearmen pounced on a group of my knights that I had carelessly parked on the outskirts of a village in the assumption that the spearmen would not want to be drawn away from the main body of their troops. That said though pathing through gateways is still bloody awful and sieges still end with an ungodly scrum in the centre of town. That made more sense in Total War Rome but it is a bit of a joke during the Medieval period and seems to reduce sieges to some strange parody of Saturday night drinking and fighting in the town centre.

One definite improvement is the graphic feedback and individualisation of the warriors within the units. Battles are a lot more fun to watch and the introduction of injuries gives the whole thing a bit more drama.

Overall though this is feeling like a incremental improvement at a cost of a lot of machine resources.

Standard
Java, Web Applications, Work

Configuration Woes

I’ve had two big problems recently that both stemmed from configuration files. During my first weeks at my new job I just couldn’t get JSP Expression Language (commonly known just as EL) to work. Despite following the examples and the tutorial to the letter the results were always garbled and never quite what was described. However when I generated a new web application and deployed it the EL worked fine.

The answer turned out to be the servlet version specified in the web.xml (which is generated by XDoclet rather than being a single file that could have been checked immediately). Specifying version 2.3 in a version 2.4 container apparently just results in flaky rather than disabled behaviour.

Failing at the time to get EL to work I decided to stick with the Struts Tag Libraries as while I was no more familiar with them than the new JSP functionality, it is more likely that an entirely container-independent solution will work across platforms and containers.

However Struts gave me my second problem with the issue of having a 1.1 Struts jar but a DTD specifying 1.0. What I noticed about both problems is that there was no clear kind of error message or clue as to what was going wrong. I only noticed the issue with the Struts config when I had a clear example of 1.1 compliant behaviour that was not present in the app. With EL it was almost entirely random as I was actually looking at the construction of the Security element of the Descriptor.

My latest example of configuration creating as many headaches as it can solve come from a very simple source. I forgot one word (“jsp”, if you are curious) from the URI of a Tag Library and as a result wasted an afternoon trying to get something as simple as Number formatting to work. Apparently JSTL 1.0 didn’t allow you to specify an EL expression as a value to format. Which is both silly and confusing. The syntax for both was identical and because I was using a 1.1 implementation the code introspection implied I had the whole tag correct, it just threw a massive exception trail at runtime.

In all these cases what I found frustrating was that there was no issue at all during the build and development of the application. All the issues were found at runtime with a need for the whole system to be configured and functioning before I could test whether I could locate a variable or not. The other is that there was no real error message that conveyed the fact that I was trying to do something that was illegal for the version declared but possible for at least one of the versions available. Instead the developer has to have a strong knowledge of the feature set of each standard version and the way each feature is configured in either the container or the application.

Configuration of application runtime via XML is a powerful tool but without a way of validating that what you are specifying is correct prior to actually using the application it is actually a massive hindrance.

Standard
Java, Web Applications

Learning Struts

In my new job I have been having to catch up on a lot of web tier technology that quite frankly I have not had much to do with for the last two years of Swing and EJB. I looked at Struts two years ago while doing an intranet application and thought that it was very heavyweight and would add to the development not subtract. However I did adopt the Front Controller idea along with the idea of views (although I think I may have munged the Models, I can’t remember now).

My first experiences with Struts was very poor, it was everything I feared it would be. Heavyweight, huge learning curve, lots of coding, all the code having to be completed up front before you could test things like the URL mapping. Everything you try to avoid in web programming these days!

In addition all the books and documentation I have been reading give a very poor idea of how to implement basic web applications with Struts. They present a very particular view of how Struts should be used and instead of focussing on the Front Controller pattern and the decoupling of components they tend to focus on gathering up and validating user input.

However today I felt like I had a breakthrough. I was trying to get a DynaBeanForm to work and I suddenly noticed that my MyEclipse XML editor was not presenting the options I was expecting from the documentation. A sudden brainwave and I was checking the DTD definition. Sure enough someone had upgraded the Struts code to Version 1.1 but left the DTD at 1.0. Cue much misery on my part trying to figure out how things were meant to be put together.

With DynaBeans and DispatchActions up and running I probably found myself being more productive in the last 12 hours than I was in the previous week.

The jury is still out on Struts for me but I have realised that I can’t take too much from just one experience of a product, particularly in an installation you haven’t been involved with.

Standard
Games, Software

DefCon

Introversion‘s new game was $10 (plus tax etc.) on Steam so I pre-ordered and waited for my files to be decrypted. First time I try and play the game, the authorisation fucks up and I’m stuck in an irritating demo mode. After some grinding of teeth and futile emails to Steam Support I read on Introversion’s forums that deleting a file called authkey allows Steam to take a second stab at authenticating the game.

Sure enough deleting the file does authorise me and I spend a pleasant half hour going through the tutorial. First impressions are good, the sound is completely fantastic, thoroughly atmospheric and I am going to have to find out who composed it. Game is retro graphics again but very atmospheric. The menu screen is a work of total genius.

I’m looking forward to longer but “null points” to either Steam or Introversion for their customer support. You have an issue that can be solved simply so why don’t you stick a notice on your forums and pre-empt some pissed off customers.

Standard
Work

New Job!

Woohoo! The big news is: new job. I started a couple of weeks ago and it is a welcome change from the old place. For a start the commute is not as big and while it is still a programming job the sector is very different and the “department” consists of exactly four people. Which is quite a bit different from the corporate jobs I’ve had before.

It’s also great not to be working in an industrial estate bounded by a dual carriageway and a railway. After two years of amenity drought I keep forgetting that I can pop into a supermarket, bank or post office if I need something done now.

Standard
Uncategorized

REST Authentication

After reading Rusty Elliotte’s blog for a while I have been interested in finding out more about REST implementations. The hardest thing to get my head round is that there is not a standard implementation or standard for it. Take for example this weekend’s REST task which was to find out about how a REST application would handle authentication. Authentication for a public service is probably the key element to a useful real-world Web Service application and in my past experience it is a vexed and complex issue that involves head-splitting implementation details.

As this tutorial points out authentication is hard. So why try to implement it yourself? The tutorial instead suggests relying on the HTTP authentication that should already be part of your webserver implementation. This is what blows me away about REST so far, it uses what you already have and already know to achieve something new. It has the hallmark of any truly useful technology or methodology in that what it does is push the boundaries of what you can do with what you already know.

I’ve run into HTTP authentication once before when a previous company I worked with restricted web access to a select few. I ended up writing a proxy that spoofed the Authentication that my authorised login was using. The proxy worked so well that in the end I was asked to shut it down and full access was restored to the rest of the team (the point being well-taken) however I didn’t learn much about Authentication except how to literally reproduce a valid response.

Clearly the time has come to learn more.

Standard
Software

US PDF – or the curse of the Letter

PDF is a fantastic format, its portable, readable, widely adopted and it is way too tightly linked to physical documents. Most American PDFs are produced on a Letter sized template, a paper-sized used exclusively in the US and which is both expensive and find to hard in the UK. Despite some good efforts by the Adobe people to try and get a Letter document to stretch to other formats the truth is that printing out a Letter document onto a A4 results in a less than satisfactory print that just looks weird. Trying to print a document to something like A5 for quick reading or to get a booklet version of the document is even worse.

For any e-publisher who wants to sell to customers outside the US please provide an A4 version of your product!

And PDF software providers, please stop putting so much effort into locking a PDF into a read-only format and start looking at a rendering that is independent of the paper size.

Standard
Java, Software

Eclipse Type Handling

One of the nicest features of Eclipse is it’s tools for searching through a large complex project. Even if you don’t use Eclipse as your main IDE it is worth loading your code into Eclipse so that when you are asked the inevitable questions about what a particular piece of code does (or more often and harder to answer still, which piece of code does what) you can dive right in and let Eclipse guide to the answer.

Eclipse 3.2 turbo charges the existing functionality as far as I am concerned. It already had a powerful regular expression matching but this improved now with a split list of likely matches coming before a broader list. It is also incredibly fast, even for a huge legacy application. As far as I’m concerned Eclipse is the number one Java source browser around at the moment.

Standard
Software, Work

Good enough never is

In my recent job I have come across an attitude of “good enough” more than once from various people. It’s never one I have subscribed to or agree with. I have a healthy agreement with the idea that perfection is the enemy of action but that is a different argument. Better something than nothing but once you have something more than nothing I don’t see the point in giving up and doing nothing more.

In fact I don’t understand the mentality that leads to the idea of good enough. There is a touch of the fatalistic about it, that we shouldn’t try and expect more than what has been achieved so far. Then again this could also be a variation of Panglossian pessimism: in this imperfect world we have the best imperfect solution we can hope for.

Personally I’m rarely satisfied with my work and the urge to revisit it and improve it is one of the attractions of permanent employment rather than contract work. Sometimes the revisitation is to fix issues of time and resource constraint during the initial work. Other times it is to revisit old work in the light of new experiences, to transfer the lessons of work done well to earlier projects. Sometimes it is just pure dissatisfaction, the knowledge that something could be better than it is. I always like to build in huge margins of performance and capacity (in fact some of my recent software has perhaps a 200 to 300% margin) which some people might criticise as being over-engineered however the important thing is that if you had a choice of a margin of 30% or 100% for the same budget, which would you choose? Ambition is what drives the search for that additional 70% and people who believe in “good enough” don’t have the ambition to find that little bit extra from their work.

My views are formed by my experience with SMS billing where no-one really foresaw or predicted the phenomenal growth in texting and text services. It took us all by surprise and if the software had a margin of 100% excess then it could be used in a quarter with exponentially more needed for the next quarter.

I think it is worth approaching every project as if it has the potential for being a huge success. I don’t think every project should be budgeted as if it might be a huge success because 90% of ideas never pan out quite the way anyone hopes (WAP is a good example of this). If you don’t think a project might result in a big success then there is a question about why you are doing it in the first place. If you, the implementer, don’t believe in a project then why the hell would else believe in it?

Even if you design for success you should always be prepared to return to a project and make improvements. My favourite example are web-based applications. Every time I come to a web application project it seems that the technology involved has evolved and all manner of new solutions to previously difficult problems are now available. What took weeks of effort in the past is now part of some standard library or tool, the weeks of effort can now be spent on getting way beyond the basics of the app and providing some reason why your application is going to stand out from the rest. I always enjoy ripping out some half-hearted custom solution to a problem that was written in-house with a standard piece of technology. For me change is progress and progress requires change.

Ultimately in business software you have to provide your own impetus for change and innovation or your competitors will. Someone will come and eat your lunch if you give them the chance. Perhaps that my problem with “good enough” is that it smacks of the fatal complacency that leads to losing contracts, losing jobs to cheaper labour countries and ultimately losing the lead in innovation and ideas.

Standard