WordPress 4.0 Menu Behavior Change

September 9, 2014

I recently upgraded a site to the new WordPress 4.0.  As usual, there were no noticeable hiccups… until I looked at my main navigation more closely a couple of days later.  I have a couple menus defined but one called “Primary Navigation” – a pretty typical set up.  I’ve written my own theme, as I have for many, many sites and have used the same menu code for as long as I can remember:

// after_setup_theme callback
register_nav_menus( array( 'primary' => __( 'Primary Navigation',
           'somethingidontrememberwhyitisshereandcantfinditinthedocs' ), ) );

// in template menu 
wp_nav_menu( array('menu' => 'Primary Navigation' ))

This was causing a different menu to show up in the location of the wp_nav_menu.

A quick web search showed I wasn’t the only one running into this as well as no obvious indicators of changes in the behavior of wp_nav_menu. There was a hint, and I followed it, that changing to the actual name of the menu would fix this – and it did. My code now reads:

wp_nav_menu( array('menu' => 'Main Navigation' ))

“Main Navigation” is the actual name of the menu I defined inside of my site.

This doesn’t seem quite right having to know the exact menu name instead of allowing a menu to be abstractly identified and then mapped.

I also tried:

  • switching to using register_nav_menu
  • switching to using the menu identifier/slug “primary”
    • WordPress codex for wp_nav_menu says the menu parameter “accepts (matching in order) id, slug, name”
    • Reminder that the second parameter for register_nav_menu is a “description” not a “name”

Only using the actual menu name worked. 

Integration Testing, Maven, and GAE

September 8, 2013

I’m starting to use REST-assured for integration testing my REST APIs.  It provides a nice clean way of writing integration tests and, of course, I’d like them to be run automatically.

Maven Integration Tests

While unit testing is pretty much ready to go out of the box in Maven, integration testing isn’t.  It is not too hard but there’s a couple of things that need to be done. First, you have to pull Fail Safe into Maven with:
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-failsafe-plugin</artifactId>
  <version>${maven.failsafe.version}</version>
  <executions>
    <execution>
      <goals>
        <goal>integration-test</goal>
        <goal>verify</goal>
      </goals>
    </execution>
  </executions>
</plugin>
Now, when you execute the maven verify goal, test classes of the pattern IT*.java or *IT.java are automatically executed. This works well until you realize that real integration tests require a bit more setup than unit tests do.
 

GAE Dev Server and Integration Testing

In particular, I want the GAE dev server running before the integration tests run.  So all we should have to do is get the GAE plug-in to execute the devserver_start goal during pre-integration-test and the devserver_stop goal to execute during post-integration-test.
<plugin>
  <groupId>com.google.appengine</groupId>
  <artifactId>appengine-maven-plugin</artifactId>
  <version>${appengine.target.version}</version>
  <executions>
    <execution>
      <id>start-gae</id>
      <phase>pre-integration-test</phase>
      <goals>
        <goal>devserver_start</goal>
      </goals>
    </execution>
    <execution>
      <id>stop-gae</id>
      <phase>post-integration-test</phase>
      <goals>
        <goal>devserver_stop</goal>
      </goals>
    </execution>
  </executions>
</plugin>
Now, executing mvn verify will run your integration tests once your unit tests pass and the GAE dev server should start and stop around the integration tests as well.

Adding Jersey to a GAE Maven Project

September 3, 2013

Continuing from my post yesterday, Getting Maven, GAE, and Eclipse Working Together, I’m adding Jersey to my test GAE project to finish proving the Maven integration and test that I can get my favorite REST library up and running both locally and as a full fledged GAE project.

Adding Jersey

Jersey is one of the few “magical” (read: annotation) libraries I use.  I really don’t like magic in my code.  It is great when it works, and miserable when it fails… and it always fails at inopportune moments…

We start by adding a new dependency to the pom file:

<dependency>
    <groupId>org.glassfish.jersey.containers</groupId>
    <!-- if your container implements Servlet API older than 3.0, use "jersey-container-servlet-core" -->
    <artifactId>jersey-container-servlet-core</artifactId>
    <version>2.2</version>
</dependency>

The artifactId started out as “jersey-container-servlet” but since GAE only supports the Servlet 2.5 spec we follow the comment and append “-core”.

Next, we quickly write a test Jersey class:

package mavengaetestproject.mavengaetestproject;

import javax.ws.rs.GET;
import javax.ws.rs.Path;

@Path("/jerseyws")
public class TestJerseyWS {

    @GET
    @Path("/test")
    public String testMethod() {
        return "this is a test";
    }
}

And then update the web.xml:

<servlet>
    <servlet-name>Jersey Web Application</servlet-name>
    <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
    <init-param>
        <param-name>jersey.config.server.provider.packages</param-name>
        <param-value>mavengaetestproject.mavengaetestproject</param-value>
    </init-param>
    <init-param>
        <!-- speed up initial Jersey loading by deactivating WADL -->
        <param-name>jersey.config.server.wadl.disableWadl</param-name>
        <param-value>true</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>Jersey Web Application</servlet-name>
    <url-pattern>/context/*</url-pattern>
</servlet-mapping>

Finally, run the appengine:devserver maven target, and once the server is up and running open a browser to http://localhost:8080/context/jerseyws/test ; You should see the “this is a test” message.

And there we have it: Maven, Eclipse, GAE and Jersey all working nicely together.

Deploying to the GAE

That’s all well and good, but I want this thing actually in the cloud, not on a dev server.  It may seem obvious, but I failed to do this first: you need to create your project in your GAE account.  You might need to update the application tag in the webapp/WEB-INF/appengine-web.xml to match the GAE application identifier.

At this point you should be able to run the Maven appengine:update target.  If working from inside Eclipse, it is probably easier to log into Google beforehand, AND you WILL need to configure the Eclipse Run As configuration for UpdateApplication to use the external Maven environment (see the other post if you need a refresher on why).  If running Maven from a command line, it will pop open your default web browser, prompt you to log in, and then provide a code to put back into your console/shell to allow it to continue.  For me, it worked cleanly from both environments (once I had the Maven config corrected in Eclipse) and my REST servlet was up and running easily.

At this point I’ve completed everything I intended to accomplish.  It took a little longer than planned and with the mish-mash of tech that didn’t always line up correctly I hope this helps others out.

Getting Maven, GAE, and Eclipse Working Together

September 3, 2013

Today, we turn to some “fun” making Maven, Google App Engine, and Eclipse work together nicely.  I like Eclipse I lot.  I know its not everyone’s favorite, but it is my choice of IDE.  Similarly, I know Maven isn’t everyones… ok, its no one’s favorite, but it does solve a number of problems quite well and I peacefully co-exist with it right now.  Maven and Eclipse are enough to make people complain loudly to me at work, but today I wanted to build a GAE project, in Eclipse, and using Maven to manage my dependencies (I’m going to have a number on this little project of mine and its good for what I need).

Google certainly has a nice Eclipse plugin for managing GWT and GAE projects, but it doesn’t conform to Maven conventions.  After trying several times to coerce a GAE project into a Maven structure I gave up and did some searching.  I found https://developers.google.com/appengine/docs/java/tools/maven to be generally useful but it required some modifications for the current versions of things.  Here is what I had to do to get everything working together:

Steps

Starting Environment

  • Eclipse Java EE IDE for Web Developers, Version: Kepler Release, Build id: 20130614-0229
  • Maven 3.1.0 installed outside of Eclipse (in my devtools folder if it matters)
  • JDK 1.7.0_25
  • Windows 7

Target Implementation

A basic REST servlet using:

  • GAE 1.8.3
  • Jersey 2.2
  • Final WAR deployed into my GAE account

Step 1: Add the External Maven to Eclipse

I didn’t realize it was going to be important to have an external Maven installation but it turns out that it is (reasons later).  In the Eclipse Preferences, search for Maven, and look for the Installations tree node.  Add a new installation by browsing for your devtools equivalent location.  Once added, make sure the checkbox is on the External one.  You may also need to update where your settings.xml is pointing both here in the Installations, and/or in the User Settings.  I have both pointing at the settings.xml in the external maven configuration folder.

Step 2: Update Eclipse Maven with Remote Archetype catalog

In that same Maven area above, look for the Archetypes tree node.  Add a remote catalog providing http://repo1.maven.org/maven2/archetype-catalog.xml in the catalog file box (name it if you want, I didn’t).

Step 3: Create the project stub

Using the Eclipse project wizard create a new Maven Project.  The second step in the wizard selects an archetype, look for com.google.appengine.archetypes:skeleton-archetype.  Select your group and artifact ids (I choose “mavengaetestproject” for both) and it will create a nice stub GAE project. Note that the artifact id becomes the Eclipse project name. That annoys me because my Eclipse project names don’t always match my maven artifact names, but considering what we’re trying to accomplish, I’ll let this one slide.  If I’ve missed where I can name the project, please let me know.

Step 4: Fix up the default pom.xml

The default pom is set up for GAE version 1.7.5 so change the appengine.target.version property to 1.8.3 to pull in the latest GAE environment.

Step 5: Test out the basic war

One of the nice things about the skeleton-archetype is that it comes with appengine-maven-plugin already set up.  That gives us some maven goals that help make up for the lack of the GAE Eclipse plugin.

Right clicking on the project node, Run As, Maven Build…, set the goal to be appengine:devserver and then run it.

Boom!

As of the time of this writing there’s a problem:

[ERROR] Failed to execute goal com.google.appengine:appengine-maven-plugin:1.8.3:devserver (default-cli) on project mavengaetestproject: The plugin com.google.appengine:appengine-maven-plugin:1.8.3 requires Maven version 3.1.0 -> [Help 1]

Eclipse Kepler is running Maven 3.0.4 internally, and in one of those warning messages I never read on the Maven Installations configuration dialog it says “Note: Embedded runtime always used for dependency resolution…”.  Basically, by default, any Run As, Maven command is using Eclipse’s embedded Maven configuration.

This can be fixed by going into the Run As, Run Configurations… dialog and searching for DevAppServer, click on it. At the bottom there is a Maven Runtime combobox, select the external Maven entry.  Apply and then run.  This time it should work better.

Open a browser to http://localhost:8080/_ah/admin to prove that its working.

One annoying side effect: killing the process inside the Eclipse console doesn’t seem to kill the real process so I have to manually kill it when I’m done testing.  Any suggestions on this would be welcome.

Conclusions

At this point we have a working GAE project that does nothing.  But, it is Maven-ized and working in Eclipse.  In the next post, I’ll pull Jersey in and make sure Maven and Jersey and everything are all working correctly.

Striving for Unit Tests with 100% Coverage

October 9, 2010

I’ve found Emma to provide some real insight into what is actually getting tested.  While trying to bolster a suite to 100% coverage that I had though was pretty good already (it was ~85%) it showed me an interesting problem.

I have a method that looked something like this:

public MyMessage parseXMLtoMyMessage( final Reader reader ) {
    MyMessage msg = null ;
    try {
        final JAXBContext context = JAXBContext.newInstance(MyMessage.class);
        final Unmarshaller u = context.createUnmarshaller();
        final SAXSource src = new SAXSource( new InputSource(reader) );
        msg = (MyMessage) u.unmarshal(src);
    } catch (JAXBException e) {
        e.printStackTrace(); // yes I do better exception handling than this...
    return msg ;
}

I can pass in any kind of  Reader I want to for my tests and the JAXB2 code is isolated in one area of responsibility.  This worked great until I found out the real  XML was coming in with a namespace (that fact is not in the provided message spec) and that namespace isn’t reachable… nice.

So, I needed to disable namespace checking.  A quick bit of research turns the method into the following (changes noted in red):
public MyMessage parseXMLtoMyMessage( final Reader reader ) {
    MyMessage msg = null ;
    try {
        final JAXBContext context = JAXBContext.newInstance(MyMessage.class);
        final Unmarshaller u = context.createUnmarshaller();
        final XMLReader xmlReader = XMLReaderFactory.createXMLReader();
        xmlReader.setFeature("http://xml.org/sax/features/namespaces", false) ;
        final SAXSource src = new SAXSource( xmlReader, new InputSource(reader) );
        msg = (MyMessage) u.unmarshal(src);
    } catch (JAXBException e) {
        e.printStackTrace();
    } catch (SAXException e) {
        e.printStackTrace();
    }
    return msg ;
}

Emma had originally reported that there are no test paths through the exceptions.  OK, it is pretty easy to force the JAXBException by sending in an incomplete or otherwise improperly formatted XML stream. However, because of the need for the XMLReader to disable namespace checking I now have a SAXException that is generated completely internally to the parse method.  There’s no way to mock out the XMLReader without injecting it.  My options are:

  1. I can provide an injection point.  Sorry, no – I don’t think any client to the method should have to know about the namespace problem and exposing the XMLReader in any way amounts to that.
  2. I can alter the system property “org.xml.sax.driver” to point at something invalid,.  Unfortunately, also no.  That wrecks all other tests since I can’t return it to its original null value after the test and the tests shouldn’t be order dependent (i.e. try to make this the last test… of the entire suite).

So here I sit, unwilling to provide an injection point for XMLReader and unable to write a test to cover a specific branch.  I’m open to suggestions.

The other side of the tunnel

August 17, 2010

This period of transition for my family is finally nearing its end.  It has been a hard.  I will have missed four of the five birthdays, and I will miss my anniversary (today).  I have never not been home for my anniversary.  Sure there have been years we may have played it down and not done much, but I’ve always been home… not this year.

Along the way these few months I’ve learned that I really don’t care about anything unless my family is involved.  Maybe if I wasn’t married, and didn’t have kids I’d make something different of the situation, but I am, and I do.  Even writing for this blog – I should have had lots of time to write, but it wasn’t fun.  Recently, I went hiking and it just seemed pointless.  It brought to mind a memory of being 18 or 19 and biking around Mount Desert Island and thinking I really wished I had someone with which to share the experience.  Fortunately, two years later I did.

These few months I’ve been able to see God work things out exactly how they needed to be, but in ways I could not have predicted.  Having to leave ahead of my family completely removed me from being able to help sell the house.  I was personally unable to directly affect what was going on at home.  I had to depend completely on God to work it out… and I had to be patient all the while.  I’m bad at being patient… I’m worse at giving up control… and I had to do both.

We had so many no-show showings I lost count.  The hours of work that would go into getting the house ready for someone to see, and have them not bother even calling to cancel the appointment was gut wrenching.  I know the effort that goes into showing a house – as hard as it is, its important.  But with almost no “real” showings we eventually settled on a plan for if the house didn’t sell.  I wasn’t sure I could last thought the plan – I missed my wife and my girls (the dogs not so much).

That weekend, the house sold.

Suddenly, all of my time driving and exploring was vitally important.  We had to move in six weeks and find a house to buy in one.  But God was ahead of me again.  He had put at my finger tips the contacts and references and good people necessary to help us find the house that would be best for my family right now.  Its a good house, one that will suit us well for the next five years or so… its hard to even consider what comes after the oldest three are in college… all in the next five years or so…

In a few more weeks we will all be together again, the transition complete, with the challenge of adapting to a new area directly ahead.  I look forward to it.  God has been faithful to us throughout this season and while the process of adapting is going to have its own challenges I am going to (attempt to) patiently wait on His timing and enjoy the season.

The Furthor Adventures Of…

May 20, 2010

Its been quiet on the blogging front for a few very good reasons.  Primarily, it is due all that want into my resigning from RIT. We are very excited to announce we are moving to the Cary, North Carolina area so that I may start my new position with Deutsche Bank Global Technologies. It has been hard not talking about what we’ve been doing – only a few close personal friends knew about what we were trying to do.  The waiting was very hard… it required lots of patience

Of late its been all about selling our house in Walworth, NY – it is the last major detail of this move to work out.  If we can’t sell the house in the new few days I’ll have to move down without the family… that’s not the ideal plan, but I am confident that God has a buyer out there for us – everything else has worked out just fine… we just have to be patient…

It is hard to put into words what it means to leave RIT, Rochester, and New York… all at the same time.  The implications are enormous to me and my family.  For example, I am finishing up writing this while proctoring my last final exam for SE361 – a class I love to teach.  We leave some very good people who have been fun to be with (retrieving a bicycle from the canal depths comes to mind) and helpful beyond measure over the years (our last move was a bit crazy).  Also, I am stepping down from my position on the leadership team at Word of Life Christian Fellowship – not a minor deal to me.  I have really enjoyed working with the other members of WOLCF.  However, I do think this is allowing me to step back from a number of responsibilities and reassess what God wants me to be doing.

Another implication is that we are focusing on significantly lightening up our possessions.  Its hard enough to have clothing for seven people in the house let alone anything else… but the general idea is that we need to be ready to do what ever God asks us to do.  Being tied down to so many possessions is counter that idea; it impedes our flexibility and agility to respond when He calls.

In a sense we’re getting a chance to start many things over. This is a very exciting time for us and we are really looking forward to the move (going from 7.3″ snow/week to 7.5″ snow/year also isn’t hard to take).  We pray now for the timely selling of our house so everyone can move at the same time. But more, we pray for the patience to walk in God’s timing knowing that we’re on the right road, but unsure of the exact path the road is taking…


The post title is a nod to a jam track on the very first CD I ever owned of Phil Keaggy‘s : Revelator.

My wife and I thought and prayed… and thought and prayed… and then finally in January, acted.

Applets, Flex and JavaScript

April 10, 2010

I’ve been doing web programming for a very long time.  In the past I’ve done large Swing clients in applets (long before Swing was part of the standard JDK) and lately I’ve been using Adobe Flex to build Flash and AIR applications.  I enjoy how the Flex framework and structure makes Flash work for a mere programmer whereas time-line programming never really worked for me.  All along the way there’s been JavaScript; a misnamed language that has nothing to do with Java and as many platform dependency problems as CSS and HTML.  Throughout my career I’ve carefully avoided its annoyances.  I suppose that’s what’s previously pushed me at applets and Flash – they are technologies that have let me avoid JavaScript.

Recently, I had to develop a prototype that revolved around Google Maps.  One of the requirements was that it had to work on the iPhone.  As we all know, the iPhone (currently) does not support Flash.  So, since no one was jumping up to go buy me an iPhone and a Mac to build my app on, my only real option was JavaScript.  The prototyping went well – the project has been approved to be developed for real.  While I still don’t prefer JavaScript (the faked out object definitions and prolific use of anonymous functions is just ugly) I found the GoogleMaps API to be well designed and the JQuery library to be nearly redeeming of JavaScript in general.

If JavaScript had features like JQuery back in the beginning I probably wouldn’t have had to endure all the craziness of deploying signed applets.  I’ve often lamented the lack of mathematical expressions in CSS.  I understand why it is not there, but there have been so many times I wanted to size something as 100% minus  “whatever that width over there is”… now I can.

I like having good tools available to me so that I have the maximum amount of flexibility when I need to solve a problem.  I’m not throwing away my Flex anytime soon (though I did toss applets away a good while ago), if you’ve been like me, avoiding JavaScript at almost any cost, you might want to check out JQuery. It makes JavaScript programming much more reasonable.

Reading List for March 2010

March 30, 2010

Testing

Databases

  • Open Source NoSQL Databases – a nice list of NoSQL DBs. I don’t think they solve all problems, but I think they have a real place in our tool kits.

Java

Programming

User Interface Design

Process

The Start of a New Quarter

March 7, 2010

This week starts a new quarter at RIT and so I’ll be teaching another edition of SE 361. I love teaching 361. The class moves fast; every lecture is on a different topic.  The course concepts are taught “just in time” for their use by the class.  This week I’ll be teaching on teams, processes and planning.  By this time next week, newly formed teams will have their roles ironed out, team wiki set up and be thinking about the first set of assignments due next Wednesday.  In four weeks there’s an exam, two weeks later the first team presentation, two weeks later another exam, and two weeks later another presentation.  We’ll have covered process, requirements, design, acceptance testing, unit testing, integration testing and UI design issues in the five weeks leading up to the first presentation.  The class moves fast. I feel blessed and honored to be able to influence the next generation of developers.

While I love teaching, I would never give up my day job as a software developer.  I love writing software. I love making these annoying simple, and yet so wickedly complex, pieces of electronics do useful things. I like having a customer come ask me what they think is an impossible or unreasonable task and telling them “sure thing, no problem, I can do that”.  I come from an embedded systems background where we really do make electronics do interesting things, like broadcast and decode radio waves, or spin motors for conveyors…  These days as a software architect my focus is on business efficiencies; integrating various data systems to achieve previously unrealizable operational goals by navigating through the insanely complicated and disconnected operational rules of multiple organizations. While its easy to get lost in the details of the insanity, quality is paramount.  Balancing security with operational requirements and achieving reliable and trustworthy systems… that is what I love to do on a daily basis and that, in a nutshell, is problem solving.

Teaching is not problem solving.  It is a means of sharpening my problem solving skills by trying to be better prepared, more up-to-date… anticipating the next question.  It pushes me to know more about my craft, to reflect on how I perform  it, how do I want to improve it, how can I apply my craft to better achieve my business’ needs. I love teaching, but I’m hard pressed to walk away from the rush of resolving a problem that seemed impossible yesterday and yet now sets the bar a little bit (or a lot) higher for the next problem being sent my way.


Follow

Get every new post delivered to your Inbox.