1. Check your code into Subversion (or CVS or whatever SCM of your choice - this guide assumes Subversion, however).

2. Add a build directory on your prod box (I have mine at /home/build/) - then check out individual projects under it (ie, /home/build/wiifit/).

3. In each project, add a property to application.properties for the deployment directory (ie - deploy.dir=/home/tc6/server/wiifit).

4. In grails, you can add groovy scripts to the /scripts/ directory, and then run them with grails , ie, ProdPush.groovy can be called with ‘grails prod-push’. Let’s add a script in to do the following things:

- Do a subversion checkout to get our latest changes.
- Build the war
- Copy it to our directory

This is what I came up with:

Your script can have multiple targets. If you specify a ‘default’ one, like I have above, it is what will be run if you supply no target (which is what we want).

5. Now I have a simple shell script on my server to setup the environment variables and run the build.

This script can then be re-used for all projects on the server.

6. To update our app, we simply do the following:

- Check our changes into Subversion
- SSH into our server and go to our /build/ directory
- Run the build script (ie, ./build.sh wiifit)

Our new app is live in less than a minute and we don’t kill our home internet connection :)

This solution may not be very good for high-usage, critical apps - if I were building (and leaving code) on a production app server at my day job, I’d be fired (and deserve it!) - but for small apps like I build, it is a good solution. This solution is pretty simple, but I’m working on a full deployment plugin for grails - fewer setup steps, tomcat management, etc.. If you have any suggestions or ideas, let me know.

This application is fairly simple - it displays a google map view that is centered on the user’s location, and inserts a marker where they are located. I am using MaxMind to turn an IP into latitude and longitude coordinates. They cost money and you may be able to find a free one, but they aren’t that expensive (something like $20 for 50,000 lookups) and I’ve been pretty happy with them so far.

There is a GWT+Grails plugin that makes it easy for Grails and GWT to work together. I am also using GWT-EXT to make it look nice, and to make the GoogleMaps integration a little easier. If you want to see this app in action, you can see it here (it may not match the example exactly - I’m actively developing it). I’ve also made the entire project available for free, here.

1.Create a new Grails application (grails create-app findme)

2.Install the Grails + GWT plugin (grails install-plugin gwt)

3.Create your Grails Module (grails create-gwt-module net.uresk.FindMe)

4. Create your page (grails create-gwt-page main/index.gsp net.uresk.FindMe, answer yes when it asks if you want it to create the controller)

5. Download GWT-EXT (http://gwt-ext.com/download/), put gwtext.jar in your project’s lib/gwt directory (ie, $PROJECT_NAME/lib/gwt). You’ll also have to put it into the plugins/gwt-0.2.4/lib directory.

6. We’ll then have to hack _Internal in the /plugins/gwt-0.2.4/scripts/ directory (hopefully this won’t be necessary in the next version of the plugin). Around line 89, you’ll have to add in another include entry after the others:

Include(name: ‘gwtext.jar’);

We’ll also need to go down a few more lines, and before ‘pathElement(location: “${basedir}/${srcDir}”)’, add ‘pathElement(location: “${basedir}/lib/gwt/gwtext.jar”)’.

Lastly, if you get an error about heap space, you’ll need to give the gwt compiler more heap space. Do this by adding in ‘jvmarg(value: ‘-Xmx256M’)’ a few lines down (around line 102), just above where the other arg() lines start. Not sure if this is related to using gwt-ext, running on Mac OS X, or what, but I did run into it a few times.

7. Download EXT 2.0.2 (http://yogurtearl.com/ext-2.0.2.zip), copy the ‘adapter’ and ‘resources’ directory, along with the ‘ext-all.js’, ‘ext-all-debug.js’, ‘ext-core.js’, and ‘ext-core-debug.js’ into your project’s /web-app/js/ directory.

8. Download mapstraction (http://mapstraction.com/svn/source/mapstraction.js) and copy it into your applications web-app/js directory as well.

9. Open up your Grails project (I prefer IntelliJ for Groovy/Grails development at the moment, btw) and find the FindMe.gwt.xml file (it is in /src/java/net/uresk directory). Add in the following:

<inherits name=“com.gwtext.GwtExt” />
<stylesheet src=“/findme/js/resources/css/ext-all.css” />
<script src=“/findme/js/adapter/ext/ext-base.js” />
<script src=“/findme/js/ext-all.js” />

10. Add the following entries in:
Create your Google Maps keys for localhost and for your production domain. To make things easy, I added a config property in called ‘googlemaps.key’, and then added this into my controller to get it for the right environment:[key: grailsApplication.config.googlemaps.key]12. In your index.gsp, add in the following:

A reference to mapstraction: <script type=”text/javascript” src=”/findme/js/map/mapstraction.js”></script>

The google maps js include: <script type=”text/javascript” src=”http://maps.google.com/maps?file=api&v=2.x&key=${key}”></script>

13. Now create a service called something like LookupService, and add in the following code to access MaxMind:

class LookupService {

        static expose = [‘gwt:net.uresk.client’]

        Double[] getLatLonFromIp(String ip){

                if(!(ip ==~ /bd{1,3}.d{1,3}.d{1,3}.d{1,3}b/)){
                        ip = defaultIp
                }

                def res = “http://geoip1.maxmind.com/b?l=${maxMindKey}&i=${ip}”.toURL().text.split(“,”)
                Double[] result = new Double[2]
                result[0] = Double.parseDouble(res[3])
                result[1] = Double.parseDouble(res[4])

                return result
        }
}

You can swap out MaxMind with any other service. I added a maxMindKey config property in Config.groovy, but you can easily hard-code it.

14. Now create your GWT client code, something like this:

GoogleMap mainPanel;

    /**
     * This is the entry point method.
     */
    public void onModuleLoad() {
                createPanel();
            new Viewport(mainPanel);
            updateLatLonFromMaxMind();
    }

        private void updateLatLonFromMaxMind(){
                LookupServiceAsync myService = (LookupServiceAsync) GWT.create(LookupService.class);
                ServiceDefTarget endpoint = (ServiceDefTarget) myService;
                String moduleRelativeURL = GWT.getModuleBaseURL() + “rpc”;
                endpoint.setServiceEntryPoint(moduleRelativeURL);

                AsyncCallback callback = new AsyncCallback() {
                  public void onSuccess(Object result) {
                    Double[] latLon = (Double[])result;
                        setLatLong(latLon[0], latLon[1]);
                  }

                  public void onFailure(Throwable caught) {
                    // do some UI stuff to show failure
                  }
                };

                myService.getLatLonFromIp(callback);
        }

        private void setLatLong(Double lat, Double lon){
                LatLonPoint llp = new LatLonPoint(lat.doubleValue(), lon.doubleValue());
                Marker m = new Marker(llp);
                m.setInfoBubble(“<div>You are here!</div>”);
                mainPanel.setCenterAndZoom(llp, 10);
                mainPanel.addMarker(m);
        }

        private void createPanel(){
                mainPanel = new GoogleMap();
                mainPanel.setTitle(“Spencer’s Google Map Page”);
                mainPanel.addLargeControls();
        }

15. Now, we need to create the stubs for this service so that GWT can use it. Do this by running ‘grails run-app’.

16. Unfortunately, there currently isn’t an easy way to get at the HttpRequest object inside our service. There is a JIRA item open for this, and I’m working on a potential solution. In the meantime, we’ll have to do a bit of hacking.

First, we’ll need to open up the LookupService and LookupServiceAsync java files that the plugin generated – they are in /src/net/uresk/client in this example. Modify the method signatures so they don’t take a String object (the IP). They should look like: java.lang.Double[] getLatLonFromIp(); and void getLatLonFromIp(AsyncCallback callback);

Next, we’ll need to modify the GrailsRemoteServiceServlet (in /plugins/gwt-0.2.4/src/groovy/org/codehaus/groovy/grails/plugins/gwt). On line 53, we are going to modify the method call so that it explicitly passes in the ip address, by changing it to say this:

def retval = service.invokeMethod(serviceMethod.name, this.getThreadLocalRequest().getRemoteAddr())

If you are using this behind a proxy (ie, behind Apache HTTPD with mod_proxy), getRemoteAddr() won’t work – you’ll have to instead get the X-Forwarded-For header value.

This is a nasty hack, and will break all your other GWT RPC calls, so if you are going to do more with this example, you’ll have to do something a little smarter to inject the IP (contact me if you want some ideas, and also keep an eye on the JIRA item mentioned above). Hopefully it won’t be necessary much longer.

You should be able to run your application now! Do ‘grails run-app’ again and browse to http://localhost:8080/findme/main.

Let me know if you have any questions or suggestions. I also hang out on the #groovy IRC channel on the evenings and weekends (GMT -700) if you need help.

Have fun :)

Special Thanks to Abhijeet Maharana who provided an excellent how-to for using GoogleMaps with Gwt-Ext.

Update: Sorry, I forgot to include the GWT client code in the original post. It is in there, step 14 now. Let me know if I missed anything else.

For goal #1, Grails is clearly fitting the bill. I spent the last year or so developing Rails apps, and Grails feels almost as productive. The community around it is getting quite active and there are some excellent plugins.

Reaching Goal #2 is going to be a bit trickier, but I think we are getting close. I am able to deploy 3 or 4 Grails applications on a 256 MB VPS now, and they work reasonably well. The good thing is that VPS’ are getting quite cheap, and a VPS with 256 MB of memory can easily be had for less than $20/month. (Shameless plug - I am putting together a site - VPS hosting reviews - that lists vps providers, their plans, prices, and reviews. And it is developed with Grails and running on a VPS :) )That said, you wouldn’t want to do this if your applications get a ton of traffic, and hosting a Java application will never be as cheap as hosting PHP applications.

Getting several Grails/Java applictions deployed on a server with only 256 MB of RAM (and on a VPS, no less, where getting a big block of contiguous memory can be tricky) takes a bit of work, so I’ve decided to detail a few things I’ve learned. This is specifically for Grails applications, although most of the tips should be helpful for any other Java application deployment as well. It also assumes you are using Tomcat as your app server.

1. Dump Apache HTTP server

A lot of people (including me for the longest time) would use Apache to forward requests to Tomcat. There is nothing wrong with Apache HTTP server itself, but in this setup, it can eat up a bunch of memory and really isn’t necessary. You can use iptables or xinetd to forward requests from port 80 to your app server. A good tutorial for these options can be found here. Doing this should free up a bit more precious memory for your app server.

2. Make sure you are using the server JVM

This is easy to forget to do - HotSpot will automatically choose which vm to run based on server attributes, so on a real production box, it will choose the server vm automatically. On a VPS, you’ll need to manually do this by adding “-server” to CATALINA_OPTS.

3. Give you server more PermGen space

Groovy uses a bit more PermGen space than normal, due to all the classloading it does. This means you’ll probably want to configure your vm to use a bit more PermGen space than usual by doing -XX:MaxPermSize=m. On my server, setting this to about half of the overall memory allocated seemed to be the best, but your results may vary.

4. Experiment

Ideally, you’d just upload your apps and not worry about tuning, but when you are trying to squeeze the most out of a VPS, this isn’t the case. Play around with different memory settings and other vm options to see what gets your particular setup the best performance and stability. Feel free to share what works well for you :)

Ah, the smell of a fresh codebase.

I’m certain most software developers who have been around for any amount of time have had to work on “The Project”. This project has probably been going for years, has had a fair amount of turnover on the development team, and has had a handful of architects (with their own way of doing things).

Projects like this may work wonderfully and be very successful from a business standpoint, and the individuals working on them are likely quite competent. Yet, from a development perspective, they are a nightmare. They contain difficult to understand code, lots of unused (or commented out) code, little testing, little adherence to good development practices, few comments, and a general feeling of brittleness.

Code like this may work exactly as intended, but when a codebase gets disorganized, chaotic, and sloppy it can lead to other problems, such as:

• An unpleasant experience for developers

• High cost to refactor code

• More bugs

I’ve worked on a few projects like this over the last 5 years or so, and was naturally excited when I found we were going to be starting with a fresh codebase. At last, all of this cruft that has accumulated over the half a decade this project has been going will no more!

Imagine my surprise (and dismay) a month after the new project started when I found most of the symptoms of “The Project” starting to present themselves in the new codebase. Looking through our project and the reports we generate (PMD, CPD, Clover), I saw:

• Lots of untested code

• Lots of bad practices and sloppy coding (as shown by PMD – we really pared down the ruleset so we don’t get a ton of false positives)

• Unused code (already, after less than a month!?)

• Commented-out code

• Methods that were too big, hard to understand, or uncommented

Part of this was due to spikes being done for the new project, which led me to conclude that spikes or experimental work of any kind should always be done in a branch. I also became interested in how code gets to this state so quickly, and of far more importance, how to keep it from reaching this state.

I don’t think this happens because people are bad developers necessarily, but because it requires a large degree of diligence and policing to keep a codebase clean and well-organized. It is easy to let organizational or quality issues fall to the wayside when working on functionality, and timelines sometimes leave little time for these tasks.

Some people offer up pair programming as a way to avoid this, but I don’t particular care for it (see my comments on pair programming). I think situational pair programming is an excellent practice, but I think full-time pair programming is, besides a terrible waste of time, largely ineffective.

After doing some research and analysis of how we work, I’m beginning to think that peer reviews are an excellent solution and practice. They provide most of the benefits of pair programming with few of the drawbacks. You still have someone examining your code, asking questions, and offering feedback, but instead of doing it for an entire iteration or whatever (where one of you will likely be bored for a good portion of the time), you do it for an hour or whatever is necessary. The only potential drawback is that if someone is totally off on their approach and it isn’t noticed until the end, it could be costly to refactor (so costly, in some cases, that it may be left in its sub-optimal state).

With that in mind, I set out to attempt to come up with good practices for conducting code reviews, and also best practices we should be following to keep our codebase clean and easy to work with. I’m wondering what other organizations are doing for peer reviews, and what I can do to improve the stuff I came up with.

It should be noted that a peer review is largely orthogonal from a QA review – a particular block of work can pass the QA review with flying colors and totally fail the peer review. The way I see it, QA reviews inspect the interface, peer reviews inspect the implementation.

Here is the document I came up with:

–

The peer review should occur prior to resolving a story or bug. At least 30 minutes should be set aside for a peer review, to allow for a thorough review. Once the review has been completed and the reviewer is satisfied, they should leave a comment on the JIRA entry stating that they have peer reviewed the unit of work.

Besides following this checklist, you both should go over all the code you wrote for this story. The reviewer should not hesitate to point out how something could have been done in a better way. If the reviewer cannot figure out what a particular piece of code does in a relatively short amount of time, it should be re-written or comments should be added in the code.

1. Metrics / Standards

- (any coding metrics – code coverage, static analysis, etc)

- Test coverage should be meaningful – ie, don’t just check that a method executed without throwing an exception

- Use the right kind of test for your code (ie, some code may need just unit tests, others may need integration tests, and some might need functional tests)

- Business logic is properly tested with unit tests

- If this is a bug, was a unit test specifically for that bug created?

2. Code Style

- Properly formatted Java code

- No commented-out code

- No unused code

- JPA standards followed (we have a separate document for this)

- If you have to explain a piece of code to your reviewer, that piece of code should be documented

- If your code is meant to be re-used throughout the app (ie, a utility class) it should have descriptive and useful JavaDocs

- Classes should be fewer than 500 lines of code, and any over 250 lines should be scrutinized closely

3. View

- All JSF controls have explicit ids

- Everything works in IE (firefox support is strongly recommended, as well)

- All fields validate properly (ie, no 500 errors when you put in invalid values)

- JSF pages named consistently

–

This is part policing – making sure people are following best practices we’ve set forth, and that part of it kind of sucks. It is also part informative, however. Ideally, both the reviewer and the developer are learning from the experience. The reviewer may see a way to do something better and thereby make the code better and increase the skill of the developer. The reviewer may also see something that educates them as well.

In the limited testing I’ve done with this, it has worked well. I personally like having someone look at my code with me and let me know what I could have done better, or what piece of code is not quite as intuitive as I thought it was (everything I write is totally intuitive – to me!). I’m curious as to what other people’s thoughts and experiences with regards to peer reviews are, however.

import groovyx.net.ws.WSClient

def proxy = new WSClient(“http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl?”, this.class.classLoader)

def req = proxy.create(“com.amazon.webservices.awsecommerceservice._2008_04_07.ItemSearchRequest”)

req.searchIndex = ‘Books’
req.keywords = “Groovy and Grails”

def search = proxy.create(“com.amazon.webservices.awsecommerceservice._2008_04_07.ItemSearch”)

search.AWSAccessKeyId = “your id here”
search.request.add(req)

def res = proxy.ItemSearch(search)

res.getItems().each {it.getItem().each {
println it.getASIN()
}}

If you’ve downloaded the GroovyWS jar and put it in your GROOVY_HOME/lib, that should work. I think it is kinda cool how quick and easy it is you can get something simple working with GroovyWS, but if you are going to be using Amazon Web Services a lot, it is probably easier to grab the Java Library that Amazon provides and use it. Here is the code for using that in Groovy:

import com.amazonaws.a2s.model.*;
import com.amazonaws.a2s.*;

class AmazonSearch {

String key = ‘your key’
String tag = ‘your associates tag’

def doSearch(String keywords) {
AmazonA2S service = new AmazonA2SClient(key, tag)
ItemSearchRequest request = new ItemSearchRequest()
request.searchIndex = ‘Books’
request.keywords = keywords
processRequest(service, request)
}

private processRequest(AmazonA2S service, ItemSearchRequest request) {
ItemSearchResponse response = service.itemSearch(request)
response.getItems()[0].getItem().each {
println it.getASIN()
}
}

static void main(args) {
AmazonSearch search = new AmazonSearch()
search.doSearch(“Groovy and Grails”)
}

}

To give you an idea of why I think telecommuting is feasible (and attractive), here is my typical day, which isn’t too terribly different from that of many other IT workers:
- Get ready for work, throw my laptop into my backpack, and head out the door.

- Drive the 15 or so miles to work. Usually I am lucky in the morning and it only takes 30 min or so to make the drive.

- Unpack and dock my laptop, and get to work.

- Throughout the day, much of my interaction with my co-workers is done via IM and email. People are too spread out (different floors, different buildings, etc) and often too busy for real-time human interaction all the time.

- Work ends, throw my laptop back into my bag, drive the 15 or so miles home (this trip takes me 45 - 60 minutes).

So, each day I drive 30 miles and spend roughly 1.5 hours commuting to and from work. Over a week, that is 150 miles and 7.5 hours - almost a full workday! Thankfully, the new train is starting to run next week, so some of this will be mitigated, but it is still a fair amount of time and money spent commuting. Add to this other problems that are common for many companies - lack of space, parking issues, and other facility issues.
So, why not have employees telecommute a handful of days per week? Think about the benefits:

Employees

- Less time in traffic
- Less spent on gas and maintenance
- Ability to focus on your tasks for a few days (I get far more done on the rare days I work from home)

Employers

- Happier employees
- Less need for parking space
- Less floor space needed for employees

Society, the economy, and the environment

- Less gas being used
- Less pollution being created
- Roads that are less congested

I understand as well as anyone the need for people to be at work in-person and to have face-to-face time with other employees. I don’t think this needs to be every day, though. In fact, I think many of us would benefit from less time available for meetings - people scheduling them would have to think hard about whether or not a full-blown meeting was necessary, or whether whatever they are trying to accomplish could be done with a few emails.
If a large percentage of IT workers worked from home just 2 or 3 days per week, the impact could be quite large - think of all the time and energy savings. There is no good technical reason for not encouraging such policies - technology exists to allow this (many companies already have it in place and use it to a small extent), the nature of our jobs is very conducive to working off-site, and several companies (ie, RedHat), already do it to a large extent with great success.

One argument against telecommuting is that it makes it hard to keep people accountable. I’d argue that it is pretty easy to see who is getting their stuff done and who isn’t, regardless of where they are working from. If you are paying someone $100k per year to write code for you and don’t feel like you can trust them enough to let them work out of your sight for a few days, you have far bigger problems. It also kills me when companies have no problem outsourcing projects halfway around the world to people they don’t know (and can’t communicate with very well), but balk at letting employees work from home a few days per week.

I don’t see why more companies aren’t pushing this, why government at various levels isn’t pushing it, and why more employees aren’t clamoring for it. Yeah, it takes a little extra work, requires some trust on the part of the employer, and may cost a bit in initial setup (VPN, security, bigger pipes to handle the traffic, etc), but to me, it seems like it pays of well in the long run.

Reading through the instructions, I found that I needed to be a registered iPhone developer - and pay $99 for the privilege. Not a big deal, but after I signed up (I wasn’t asked to pay), I was told I would be contacted when I could complete the registration and (presumably) get my certificate.

I don’t really mind paying $99, but having to wait around for them to let me in is kind of a let-down. Bummer.

Development Platform

One unfortunate aspect of the iPhone SDK is that it is limited to computers running OS X - no development on Windows or Linux. This isn’t a problem for me personally - I do most of my development on a Mac anyway - but I don’t really like vendor lock-in like that. Indeed, this is one of the biggest reasons I have stayed away from Microsoft’s .NET platform. Also, the iPhone SDK uses Objective-C and Android uses Java - so if you have experience with either language, you’ll have a leg up on the corresponding platform.

Openness of platform

I have to admit, the iPhone SDK is nowhere near as locked down as I expected it to be. I was expecting it to be locked down roughly on par with how AT&T locks down JavaME development on their network, but was pleasantly surprised by how much you have access to. Still, it is hard to beat Android’s openness, and Android clearly wins in this category.

Market

This is one area where the iPhone clearly wins - there are already millions of them currently being used, whereas Android currently has 0 devices even available for purchase at this point. Apple’s distribution model for iPhone apps is very compelling as well - they handle sales, processing, and hosting and you get to keep 70% of the price. It remains to be seen what Google will do in these area, but if there is one thing Apple does really well, it is marketing. I was about ready to ignore development for the iPhone, but this single factor alone is making it worth a second look to me.

The real issue is going to be - who does Google team up with as a carrier, and how many phones are they able to sell? All the cool features in the world won’t mean much if you don’t have a very large market.

Cost

A lot has been said of the $99 cost to get into Apple’s iPhone developer program. It would be nice if this were free (like Android), but in reality, $99 isn’t too bad compared to the cost of getting certificates for JavaME apps. Plus, if you are selling apps, the $99 is a pretty cheap way to take advantage of Apple’s marketing and distribution services.

Investment in the Platform

It is clear that both platforms are being heavily invested in. Google is giving out $10 million in prizes, whereas Apple has partnered with VC firm Kleiner Perkins to offer $100 million in funding for iPhone apps.

Features

I would expect both platforms to be fairly similar here. Both platforms will support touch screens. Android apparently will support 3G out of the box, whereas the iPhone doesn’t currently. There is speculation that Apple will release a 3G enabled phone sometime this year, however.

Features are one area where Google’s platform can beat Apple’s - since there will likely be a wide variety of models available. Need more accurate location services? Get an Android-based phone with a built-in GPS.

The last issue is the ability of applications to run in the background. iPhone applications cannot do this, which rules out any sort of IM client, for example.

Cool Factor

Nobody does cool like Apple - the device itself is sleek and attractive. The visual effects are nicely done, and you can tell the level of attention paid to detail.

In conclusion, it is an exciting year for mobile development. Just last year, I was lamenting the state of mobile development due to carriers locking down access to useful APIs. It now appears that the platform is being freed to a great degree, and we now have two excellent platforms to choose from.

The important thing to understand is why people who are both Java and Mac enthusiasts are upset. It isn’t because Java 6 was not included in Leopard, rather it is due to the complete lack of information regarding Java 6 on OS X. Do I need Java 6 right now? No. But I will need it in the future, and it would be nice to know what Apple’s plans are with Java before plunking down $6,000 for hardware. Is that unreasonable? Is that “whining”?

A lot of people have claimed “that is just how Apple works”, as though it were some cute habit that was merely annoying, and that we are silly for even worrying about it. Why is it that people accept that? I guarantee you, if Microsoft did something similar, they wouldn’t get the free pass a lot of people are giving Apple. Here is what I don’t get - Apple does pre-announce a lot of features they intend to add, and there is no competitive reason to be so secretive about its Java plans - why can’t they say something like “Yeah, Java 6 didn’t make it into Leopard, too bad. We are working on it, and will have it out within the next X months.” How hard would this be? It would mollify most critics. Yet the response so far has been silence. Deafening silence.

As my good friend Mike Heath astutely reminded me the other day, IBM too is quite often behind supporting new versions of Java (indeed, it was nearly 2 years after Java 5 came out that we were able to get a version of WebSphere that supported it), and this is probably even more inexcusable than Apple being behind. So, I don’t think it is fair to be hard on Apple for not releasing Java 6 for OS X yet, especially given the improvements they’ve made to Java 5. I do, however, think it is totally fair to wonder why they are saying absolutely nothing about it. It doesn’t make a bit of sense.