SpencerUresk

Infinity Ward/Activision get hit with DMCA notice on YouTube

suresk — Mon, 09 Nov 2009 02:38:51 +0000

Yesterday, I posted about Infinity Ward’s unpopular changes to multiplayer gameplay in Modern Warfare 2. I alluded to allegations by members of the modding community that IW had taken a lot of ideas from mod makers (such as the AC-130 kill streak reward and the tactical nuke) and haven’t even informally acknowledged the influence mods had on Modern Warfare 2. To make matters worse, they have removed the ability to use mods at all in Modern Warfare 2.

In a somewhat humorous development, Activision/IW have had one of their gameplay movies (of said AC-130 in action) on YouTube taken down due to a DMCA request, apparently filed by one of the more popular mod makers, PST Joker (Sam Babbitt).

As of this posting, their video has been replaced with the notice: “This video is no longer available due to a copyright claim by Sam Babbitt. “.

I assume once Activion/Infinity Ward get their lawyers on the case, a counter notice will be quickly submitted and the video will be reinstated within the next day or so. Still, it is kind of funny to see a big company on the receiving end of the DMCA for once, and I’m glad to see people people standing up for PC gamers.

Infinity Ward gives PC users the finger - A sign of things to come?

suresk — Sun, 08 Nov 2009 02:36:58 +0000

I’ve been sick and recovering from surgery the last month or so, so I’ve been kind of out of the loop when it comes to gaming news. Yesterday, I found out about Infinity Ward’s decision to not support dedicated servers in Modern Warfare 2, and instead rely on their new peer-to-peer technology, IW.net. This is horrible news, for a few reasons:

Peer-to-peer supports fewer players. Indeed, the maximum game size has been disclosed as 9v9, which is significantly smaller than what you currently see on CoD 4 servers. Even worse, 9v9 is only available on a few game types - on others, the maximum is a paltry 6v6.
Peer-to-peer is almost guaranteed to offer worse performance than a dedicated server. Dedicated servers are run on dedicated hardware and are connected via business-class internet connections. Peer-to-peer relies on less stable hardware and an internet connection that is less stable, has less throughput, and is subject to QoS and other interference from ISPs.
It kills the community around the game. CoD4, like other games that rely on dedicated servers, has a large community of clans who host public servers. There you can hang out with people who share a similar play style and who you get along with. It is an enjoyable experience to play and hang out with regulars on a server.
Peer-to-peer lacks any kind of policing abilities. Many servers would kick/ban players who used racial slurs or excessive profanity. Players who griefed or caused problems were similarly kicked/banned.
Finally, there is the cheating/hacking angle. IW plans to rely 100% on VAC for this. The problem is that automated cheating/hacking prevention tools are sometimes behind the cheaters. This means there are often a handful of hacks in the wild that are not currently detected by them. On a dedicated server, the admins would be quick to ban someone for this and everyone could go on with the game - on IW.net, you just have to deal with it.

To add insult to injury, the PC game also lacks the popular ‘lean’ feature that was in the original Modern Warfare, lacks any modding tools (a particular slap in the face if you believe those claiming that many of MW:2’s new features came directly from the modding community), and lacks a console for customizing certain aspects of the game.

The worst part is how this whole thing has been handled by Infinity Ward. In a Best Buy Chat with the developers, IW representatives repeatedly sidestepped questions about the dedicated server issues. Some notable (and often humorous) examples:

TRU-Jennifer: Are you considering dedicated servers for the PC gamer in the near future?

Mackey-IW: Our main focus right now is on making sure the game will work well when it is released (on all platforms).

Our secondary focus is avoiding having to answer questions about dedicated servers..

DudezTY: Since we can not kick people in ranked matches, how will we stop hackers who get past VAC?

Mackey-IW: Our goal is to ban hackers from the game.

Well, that sounds like a nice goal! And until you manage to do so, I guess we just deal with them? Awesome.

krm2014: Will the IWNET multiplayer system compensate for the undoubtly low ping that the host computer will have for the other players, or will the host have an advantage over the other players? Also, going back to clans…Is there a way to have more than 18 people in a server, because my clan has at least 100 members and we like to get 20-30 on our servers at the same time.

Mackey-IW: Games cap out at 9v9. The software has great latency tolerance. See above!

Performance is not going to be a problem! Just trust us, it’s great! (insert Baghdad Bob picture)

zach426: What was your guy’s logic behind removing the lean feature for PC, a feature that was a mainstay from all of your previous call of duty titles?

Mackey-IW: The game is not balanced for lean.

Not balanced for lean? Wtf does that mean?

Torinir: How does IWNet plan to address serious griefing, such as intentional teamkilling, voice/chat spamming, and other unwanted behaviours in public matchmade games? This includes organized griefing from groups like myg0t.

Mackey-IW: You can easily mute players, and hardcore (friendly fire enabled ) SD has “ricochet” which makes you hurt yourself instead.

Way to avoid answering most of the question.

Vince-IW: Multiplayer is incredible, you should not be worried!

Just trust us! It will be awesome! If not, oh well, at least you can return the game, right? Oh.

maniac1969: Vince, there are 178,000 voices that say you need dedicated servers for the PC. COD4 is the bigest online game in history! Why in the world would you take away dedicated servers and change the whole MP experience for us? And Mackey, the PC version with dedicated servers is already the best experience the way it is!

Vince-IW: All I can say is that we changed it to make it a better and easier experience. Also, not all of the names on that list are legit. :smileywink:

Mackey-IW: 402 signed it 4 times I heard.

They try to cutely sidestep the issue of a large number of PC users being pissed off. Are some of the signatures on the petition fake? Undoubtedly. But a large number are, in fact, real. They need only step into their own forums, or the forums of popular clans to see how many people are unhappy about this.

Axen: Please explain how a 9v9 match is a multiplayer experience? I’d have more fun serving lunch at a local nursing home.

Vince-IW: Sounds like are a very compassionate and giving person. I hope the people at the nursing home appreciate you.

Ok, that was kind of funny :)

Moriarte: Ignoring IW.net, is the PC version a direct port of the console version?

Mackey-IW: No, PC has custom stuff like mouse control, text chat in game, and graphics settings.

Umm.. Isn’t that basically the definition of a port? Who the hell let these idiots represnt IW? This is the last quote I’ll use, because it brings me to another quote from fourzerotwo:

Call of Duty: Modern Warfare 2 is actually the biggest investment Infinity Ward has ever made into the PC version of our games. It’s also the most feature-rich PC version we’ve ever made.

Really? So the biggest investment you’ve made in a PC game so far is adding “… custom stuff like mouse control, text chat in game, and graphics settings.” These two statements, both made by people representing Infinity Ward, don’t make very much sense. One has to assume that fourzerotwo is referring solely to the addition of IW.net. If this is the case - that Infinity Ward invested a huge amount of money into a multiplayer setup that is actually a giant step backwards for PC gamers - then that is absolutely hilarious. It appears as though they’ve decided to approach the PC market in a similar way to the console market, which is a huge mistake.

This brings me to the greater concern I have - that this is the beginning of a new trend. Shitty P2P lagfest games, lots of DLC, and the destruction of communities around PC gaming. id Software recently announced that they are likely not going to support dedicated servers for their newest title, RAGE. If this becomes the new thing for PC gaming, many of the benefits of the platform are gone for good.

Why URL shortening services suck

suresk — Tue, 11 Aug 2009 05:29:13 +0000

The closing of tr.im has, for a day at least, shone a little bit of light on the URL shortening industry. It has also shed light on one of several problems with URL shortening - an idea with good intentions, but potentially bad results.

When tr.im shuts down for good on December 31, 2009, any links that were created using it will cease to work. Actually, that is the best-case scenario - the worst-case would be the domain falling into the hands of folks with malicious intent and old links suddenly becoming a trail to malware. One would hope that the people behind these URL shortening services have the foresight to register the domain for several years and allow it to just sit there dormant. However, if there are creditors involved, it won’t be that simple - a domain with thousands or millions of links pointing to it has a fair amount of economic value and would be sold off to help satisfy debts.

This is a scene that is likely to be replayed many times in the future - there are a plethora of URL shortening services, and no apparent ways to make money off the concept. This in itself could be another entire post, but let’s just leave it at “Hmm… Where have I seen this pattern before?”

This isn’t the only problem with URL shortening services - if it were, they wouldn’t be so bad. A lot of these services see the most use on Twitter, where the average link has a shelf life of about 38 seconds (I made that up), which mitigates the problems that occur when they die out to a degree. Lots of the links do hang around in other places, however, so we can’t ignore this problem, but let’s look at a few more:

1. They obscure what you are clicking on

This is probably the worst problem. For any given hot Twitter topic, there may be hundreds of tweets flying by per minute - many of them containing links. It would be easy for someone to slip in a link to that says “Click here to see pics from the Iranian riots”, but is really a link to porn, a rickroll, or some malware. When you see the actual URL of the website, there is a small amount of security in being able to see where you are heading. By every link looking exactly the same (ie, bit.ly/ followed by a few random characters), this first line of defense is circumvented completely.

2. They are an extra link in the chain

There are no shortage of things that can go wrong and make your website inaccessible to end-users. Power outages, network outages, hardware problems, DNS issues - just to name a few. Adding a URL shortening service into the mix is just one more link in the chain where a user can be frustrated by a website that doesn’t load.

An important lesson for webmasters and web framework developers

If anything, the fact that an entire industry has sprung up around shortening URLs so they aren’t impossible to even copy & paste effectively should serve as giant clue to web developers everywhere - your URLs are too damn long. We should be mindful of this when designing websites, web frameworks, and web applications (ie, CMS apps). A lot of new frameworks already are - Rails, Grails, an Lift all spring to mind as having nice facilities for making reasonably short URLs.

Some websites have necessarily long URLs because that is how they maintain state - this is unavoidable in some cases, but you can still provide a nice button or something in a prominent location on every page that has a shorter version of the link for people to use.

Small measures like these can help alleviate the need for URL shortening services and the problems that accompany them.

Using run mode and properties in Lift

suresk — Tue, 14 Jul 2009 20:38:03 +0000

I’ve been using Lift and Scala for a few weeks now to build my scala job site. I’ve been incrementally adding features ever since I first opened the site a week ago. Two of those features I added today involved utilizing the runtime environment support in Lift, so I thought I’d write up a quick tutorial on how you can use it. Making your web application behave differently based on whether it is in development or production is incredibly important, and fortunately Lift makes it easy.

The first thing I had to add was a Google AdSense ad box. My designer left room for ads on the website, but I didn’t initially implement them and instead just mapped them to a snippet that returned a comment. Now I’d like to put the ads on the page so I can start earning my internet millions. However, I don’t want them to show in development mode because they will throw off my stats and because Google and/or the advertisers don’t appreciate me racking up thousands of ad impressions while developing my own site. Let’s see how we do this:

def ad(in: NodeSeq) : NodeSeq = net.liftweb.util.Props.productionMode match {
case true =>
case false =>
}

This calls the funcion productionMode on the Props class that is part of Lift. This tells us whether we are in production or not - if true, it will show an ad, otherwise it just sticks a comment in the HTML. But, how does Lift know if we are in production or not? Good question. When you run the application you can tell it what environment you are in by setting the run.mode property. If you run Lift with mvn jetty:run, it will assume you are in the default (development) environment. If you run Lift with mvn jetty:run -Drun.mode=production, it will assume you are in production. On my production Tomcat server that this app runs on, I just added a startup property to set the run mode to production.

Now let’s move to something a little more complicated. Whenever a new job is posted, I want to update the Twitter status for my site (@scalacareers) so that everyone following it will know that there is a new job to check out. In development mode, I don’t want to post to the same Twitter account, though, as that would really confuse and frustrate my followers! I created another account (scalacareersdev) that my app will use in development, but how do I make sure the app is using the proper account? Here is where the property support comes to the rescue. Lift will load property files based on my environment - it will look in /default.props for the default (development) mode, and in production.default.props for production. So I create both of these files, and in default.props I put:

twitter.account=scalacareersdev
twitter.password=devpassword

in production.default.props, I use:

twitter.account=scalacareers
twitter.password=realpassword

Now, how do we use these? I have a twitter actor that updates the status:

val session = new AuthenticatedSession(“scalacareers”, “realpassword”)
session.updateStatus(“New Scala job posted - “ + job.jobTitle + ” - more info at: “ + job.buildUrl)

I just need to refactor it to not have a hardcoded username/password, and instead get the values from the Props class:

val account = Props.get(“twitter.account”).open_!
val password = Props.get(“twitter.password”).open_!

This will look up the properties correctly for the environment, and I will be posting to the proper Twitter account. Note that by using open_!, my app will fail if the properties aren’t there, which is probably sensible in this case.

As you can see, the property support in Lift is quite easy to use and is incredibly useful when you have functionality that needs to change based on the environment.

Scala Job site + My experiences with Lift

suresk — Tue, 07 Jul 2009 04:16:26 +0000

I’ve played around with Scala off and on for over a year now, and also looked at Lift once or twice during that time. After going to David Pollak’s session at JavaOne about Lift, I decided to buckle down and actually create something with Scala and Lift, as I usually learn new things best by trying to create something useful. Looking around, I noticed there weren’t any Scala-specific job sites and thought it might be nice to create one.

The site is here: ScalaCareers.com, and you can follow on Twitter for announcements of new jobs posted and other things @scalacareers

In my opinion, jobs for a new language are extremely important in helping it get to the next level of adoption. Scala is already pretty popular and Lift is gaining in popularity, so I hope we start to see a lot more jobs that involve Scala and Lift.

I’m going to be posting some short tutorials and other things related to my experience in the coming weeks, but I thought I would share a few quick, high-level thoughts.

1) Lift is a solid, production-ready framework. I was able to learn enough of it to build a functional, albeit small, web application over the 4th of July weekend. Despite using a snapshot of the 1.1 release, I didn’t run into any bugs or severely out-of-date documentation. I mention this because it has been a slight problem when I’ve been an early adopter of frameworks in the past.

2) The Lift community is incredibly friendly and helpful. Going back through several months of activity on the Google Group, they are generally accepting of criticism, quick to offer help, and even commit changes to the trunk quickly to help folks out. A good community is very important to newcomers to a new language or framework.

3) Using Lift requires a good knowledge of Scala to really be effective. Don’t get me wrong - learning Scala is well worth the effort - but it was a bit of a change for me, coming from Grails where I was able to sort of ease into it.

4) IDE support for Scala is still a little disappointing. Even though I love Groovy, I generally prefer static typed languages to dynamic typed ones, which is why I was interested in Scala in the first place. One of the big benefits of static typed languages is that you can theoretically get better IDE support. I shelled out a few hundred bucks for IntelliJ for this purpose, and while it was marginally better than the others, I still found lots of cases where auto-complete simply didn’t work and plenty more cases where it didn’t catch compile errors. It probably cost me a few hours on the project. A good IDE doesn’t make you a better developer, but it does make you faster :)

Overall, I think Scala and Lift have bright futures and are worth checking out.

Bad API examples: java.util.Calendar

suresk — Sat, 16 Aug 2008 22:28:33 +0000

Take a look at the following code, and try to guess what is printed:

public static void main(String[] args) {
Date today = new Date();

Calendar c = new GregorianCalendar();
c.add(Calendar.DAY_OF_YEAR, 10);

System.out.println(c.after(today));
}

What is printed?

1. true
2. false
3. It doesn’t compile
4. Runtime error

From a logical perspective, #1 is right - 10 days from now is after now, so you’d expect to see ‘true’ printed. From a language perspective, you may think “you are passing in a java.util.Date to a function on java.util.Calendar, so it wouldn’t compile”, and choose #3. Neither of these are correct - the block of code above completes normally and prints ‘false’, which is not what we wanted.

If you take a look at the javadocs for java.util.Calendar, it is easy to see why. The signature for after (and before) is public boolean after(Object when), but if you pass anything but a java.util.Calendar in, it will *always* return false. This is an unfortunate api design problem - it is reasonable to expect that you could pass in a java.util.Date, or even a long representing a timestamp to compare to the Calendar instance and it would work normally. The fact that either of those options compiles and runs without error can cover up the flaw in your code, and be difficult to track down (which is how I came across it and decided to write this post).

I am stumped trying to come up for a good reason for the method to accept Object (which means anything can be passed in - even primitives from Java 5 on) only to return false if it is anything other than java.util.Calendar. The method signature should be public boolean after(java.util.Calendar when), so that you get a compile error instead of a silent failure at runtime.

Now, this library has been around since JDK 1.1, so I’m not exposing a new design flaw or anything. I am, however, curious as to how something so clearly anti-idiomatic Java (and anti-static typing) made it into a core Java library. Anyone have any ideas? The Date/Time APIs in Java are generally pretty bad anyway, but this seems especially poorly done.

I mostly write business code, and not much in the way of API code, but I have been reading the 2nd edition of Josh Bloch’s Effective Java and it has given me a better appreciation for the thought and effort that goes into creating useful APIs. It is always interesting to see some of the really good *and* really bad examples of API design in the core Java libraries.

Quickly Redeploying Grails Apps

suresk — Wed, 02 Jul 2008 06:30:53 +0000

I’ve been developing a bunch of small Grails apps lately, and I end up deploying them to my production box fairly frequently. This is kind of annoying because the upload speed on my home internet connection is terrible - it sometimes takes 7 or 8 minutes to upload a new WAR and during that time, my internet connection is unusable for anything else. I wanted a simple way to push new code to production without uploading a new WAR every time, and I know a few other people were looking for something similar, so here it is. It is pretty boring but it does the job. In my case, I deploy all of mine as ROOT.war, because they are always the default app for their domain. If yours is setup different, just replace ROOT.war with whatever your war should be named.

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:

grailsHome = Ant.project.properties.“environment.GRAILS_HOME”

includeTargets << new File ( “${grailsHome}/scripts/War.groovy”)

target(‘default’: “Push a war to prod”) {
println “svn up”.execute().text
war()
Ant.copy(todir:Ant.antProject.properties.‘deploy.dir’, overwrite:true) {
fileset(dir:“.”, includes:“ROOT.war”)
}
}

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.

#!/bin/bash

export GROOVY_HOME=/usr/share/groovy
export GRAIILS_HOME=/usr/share/grails
export JAVA_HOME=/usr/java/jdk
export GWT_HOME=/usr/share/gwt

cd $1

$GRAILS_HOME/bin/grails -Dgrails.env=production prod-push ROOT.war

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.

Grails + GWT with GWT-EXT + GoogleMaps + MaxMind sample application

suresk — Sun, 15 Jun 2008 06:04:38 +0000

I’ve been playing around with Grails and a bit of GWT lately, and it sure is a lot of fun. I’ve made some applications that use Grails, GWT, and GoogleMaps (see: Find A Wii Fit), and thought I’d write a quick tutorial on how to do it - it can be a little tricky.

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:


name=“com.gwtext.GwtExt” />
src=“/findme/js/resources/css/ext-all.css” />
 src=“/findme/js/adapter/ext/ext-base.js” />
 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:

The google maps js include:

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(“You are here!
”);
                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.

Running Grails applications on a VPS

suresk — Fri, 13 Jun 2008 04:02:49 +0000

For some time, it has been one of my dreams to see Java-based web applications be more viable for small websites. This means two things: rapid development capabilities (like Ruby on Rails), and inexpensive, reliable, and economical hosting options.

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 :)

Avoiding unpleasant code with peer reviews

suresk — Mon, 26 May 2008 23:07:20 +0000

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.