Warning: array_key_exists() [function.array-key-exists]: The first argument should be either a string or an integer in /xxx/webroot/wp-includes/category-template.php on line 176

It turns out that this is caused by the theme that I am using not setting categories correctly due to using functions that have been deprecated in recent versions of Wordpress. Basically, no category is set on the home page, resulting an error when the Wordpress code tries to look up the category name on the home page.

You can fix this by getting a new version of your theme if there is one available, or if there is no new version then change to a different theme. However, if you are particularly attached to your current theme and there is no new version of it (which is the situation in which I find myself) then this error is actually quite easy to fix by editing category-template.php:

Go to line 176, which looks like this:
if(array_key_exists($category, $categories))

and replace it with this:
if(!(false === $category) && array_key_exists($category, $categories))

This checks for the existence of the category variable before attempting to use it. Of course, you will need to do this every time you upgrade as when you upgrade, the new category-template.php will overwrite the one that you have edited. And the line number might change too, but the error message will tell you that.

And don’t forget to make a backup of your original category-template.php just in case the editing goes awry.

Good luck!

An example of coding at the right level: If you were performing a database query, you would either specify the database query as SQL (or another query language possibly) and issue the query, or you would ask your object-relational mapping layer to do it for you. Either way, you are only dealing with querying the database rather than worrying about opening a network socket to the database server, sending the query across the wire in the correct format, marshalling the results, etc, because these operations are at a much lower level and you’ll have a library or database driver to do them for you. Likewise, you wouldn’t decide in the same method which web page to direct the user to next, because that is a much higher level. This is an example of an operation that would happen in a method of a typical DAO object and any non-DAO operations are clearly out of scope.

The same is relevant in other situations. Let’s say we have a web application and have split it up into these layers: web layer (e.g. a Spring MVC Controller or a Struts Action), business delegate layer and DAO layer. In the web layer, all we are concerned with is getting the relevant data from the request, passing it to the relevant business delegate and then forwarding to the correct page depending on the result of the delegate call. At no point should we be worried about performing any business operations ourselves, and certainly at no point should we be concerned about interacting directly with the database. As such, if we had a simple domain-specific web controller language, we could code displaying a product’s information as something like this:

get productId from request
if productId missing then display error 500 page
get productData for productId
if successful then display product page with productData
if permission denied then display error 403 page
if not found then display error 404 page

Which is a fairly typical web request pattern. To convert this into Java, we would get something like this (I had to fight with Wordpress a bit to get it to format):

String productId = request.getParameter("productId");
if (productId == null)
{
..redirect(ERROR_500);
}
else
{
..try
..{
….Product product = productLoadDelegate.loadForProductId(productId);
….request.setAttribute(”product”, product);
….redirect(PRODUCT_PAGE);
..}
..catch (NotFoundException e) { redirect(ERROR_404); }
..catch (PermissionDeniedException e) { redirect(ERROR_403); }
}


We’ve got a bit more syntax here than in our domain-specific language above, but all the concepts are the same. Nowhere are we dealing with database connections. Nowhere are we worrying about network sockets. Nowhere are we worrying about where our product data is stored.

If we can follow the principle of treating each class or method as a domain-specific area and program in Java or our language of choice as if it was a domain-specific language, then our code is much neater and more maintainable. It’s a game to play to enforce separation of concerns.

I’ll probably come back to this at some point when I’ve thought about it a bit more.

Some people rant about Java being bloated architecturally. If you architect correctly then it is not bloated. To some people, “Java” isn’t Java. To some people, “Java” is layers of pointless, bloated EJB and middleware and endless acronyms and buzzwords. To me, Java is a language and you can use it to program at whatever level you choose, given the right frameworks and support. 

However, there are still restrictions that some people do not like. Some people like manipulating hash tables and lists with operators rather than with method calls and don’t like that Java won’t let you do this. My view is that the more obvious that syntax is (i.e. in correctly named method names) the more self-documenting the code is.  Of course, certain symbols such as “[]” for indexing are (almost) universally understood.  But if these can be overloaded in strange ways as they can in some languages, then this universal understanding is watered down.  And how much time is spent actually typing in code when considering the whole process of delivering a project?  Not much.  The few characters that would be saved by typing “var[i]” rather than “var.charAt(i)” are negligible when compared to the thought processes that went into deciding how your method / class / package / application is actually going to function and hold together.

I like Java. It makes me feel comfortable. It makes me feel safe in a particular way: That if I write my Java code clearly and with a minimum of complexity then there is (hopefully) only one way in which a random, possibly underqualified support programmer can interpret it when (s)he attempts to change it in three years time.  This is, unfortunately, a large proportion of many applications’ life cycles.  Jumping on the bandwagon of shiny new technologies when they appear on the horizon can end up costing your organisation or customers a lot of money when they need to find people to maintain them.  To ignore this reality is tantamount to intentionally producing an unmaintainable product.  Maybe in a few years there will be a critical mass of capable, trained and relatively inexpensive Ruby programmers available and it is at that point that producing a significant government application in Ruby becomes a workable proposition.

While I am sure that I and a number of my colleagues would be more productive writing in a higher-level language than Java, that is not the only consideration in software.  Also, we get good at bending Java to our will. All those frameworks and tools that are out there - if you find a small set of good ones that you know how to use then they can help a great deal.   

We can go on about how brilliant we are and how we can produce brilliant code and how we can maintain it without too much trouble. But it is not the brilliant “we” who are going to be maintaining that code and that is what we need to be wary of.

In retrospect, I found it interesting in that not many of the discussions focussed specifically on Java; most of them were about what an architect does and how an architect interacts with the rest of the team and organisation. This could be due to the fact that most of the attendees described themselves as programmers who were interested in becoming architects, rather than people who were already architects and were therefore more interested in the architect’s role in general rather than about specific points. I was hoping that more of the people that had attended the first one would attend the second so that the discussions could pick up where they left off, but it was mostly a different group of people so that didn’t happen as much as I had hoped.

It could also be due to the fact that the term means different things to different people and, importantly, to different organisations. Some organisations have a very well defined architect role, but this definition can vary between organisations. Some organisations don’t have official architects and either don’t realise that architecture needs to happen or think that it will just happen automatically. Other organisations do recognise the role of the architect, but do not have people with that specific title; rather the responsibility of the architecture falls to someone who also has a number of other responsibilities. Mine is in the last of these groups but I am trying to change that.

People agreed on a number of points over the two days though. Those that have stuck with me are these, all of which I feel are important:

1. Having somebody who plays the role of the architect is important to successful project delivery. This person might not have the title of architect, but they must have the relevant experience and must have enough available time to devote to defining the architecture amongst whatever other responsbilities they have on the project and elsewhere.
2. A good architect is usually someone who has already been a relatively senior developer. This gives him an essential wealth of knowledge and experience on which to draw when making architectural decisions.
3. An architect should still get time to do development. There are various reasons for this, which I’ll discuss more fully later.
4. Successful implementation of an architecture can depend on whether or not the architect is part of the team on an ongoing basis. This allows him to see whether or not the decisions he made are the right decisions and also to ensure that the programmers in the team are using the architecture in the way it was designed to be used. This ties in with point three.

People seemed to agree on these points at both sessions. Or maybe the people who disagreed just kept quiet.

To expand on points three and four above: there are a few different ways in which the architect can be involved in development and ongoing projects. These each have their own reasons for them and benefits gained from them. We got to discussing these more fully in the latter part of the second session. These are a combination of my own thoughts and those that came out of the session:

An architect can develop architectural spikes (or “tracer bullets”) early in the project as a basic check that the architecture that he has defined is suitable for the task. This is a proof of concept task and is important as an early verification of the architecture. However, the architect can still be involved in day to day development on the project on an ongoing basis after this task is completed.

Being involved in this manner allows the architect to get first hand experience of how his architecture works in practice and learns from his mistakes and also from his good decisions. He also learns from the mistakes of the developers using the architecture. These mistakes might be on the side of the developer, in which case the architect can guide them to using the architecture in the way it was intended, or they might be on the side of the architecture, in which case the architect considers adjustments that can be made and learns a valuable lesson for next time. It also increases the chances of the architect gaining the respect of the developers on the project because they see that he is willing to work with his own architecture. This is important to get the developers to “buy in” to the architecture rather than having them disregard it as an annoyance that is being imposed on them by an external party.

An architect also needs to keep up to date with new technologies, products, libraries, etc, and this is best done by experimenting with them. If he can not get R&D time in which to do this, then he can try to get a few small tasks on another project using the technology or on an internal project if there are any available.

In my organisation, the architect is almost always the “tech lead” of the project which is a combination of the roles of architect and that of technical team lead. I prefer to be involved in development - either helping people fix bugs, picking up a few tasks here and there or pairing with different developers for short periods - but find it important not to have actual development tasks assigned to me. If I do, then these usually get in the way of my architectural and team leading responsibilities.

I have written a lot more than I had planned to and, in doing so, have some up with a number of other topics that I would like to cover but I’ll decide that I’m finished now and address those in other posts soon.