TurboManage

David Chandler's Journal of Java Web and Mobile Development

  • David M. Chandler


    Web app developer since 1994 and Google Cloud Platform Instructor now residing in Colorado. Besides tech, I enjoy landscape photography and share my work at ColoradoPhoto.gallery.

  • Subscribe

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 231 other followers

  • Sleepless Nights…

    October 2009
    S M T W T F S
    « Sep   Nov »
     123
    45678910
    11121314151617
    18192021222324
    25262728293031
  • Blog Stats

    • 996,062 hits

Archive for October, 2009

Free Web conferencing for Windows, Linux, and Mac

Posted by David Chandler on October 31, 2009

Yuuguu.com

I recently needed to share my Windows desktop with a Linux user over the Internet. It took only minutes to install the Yuuguu client and start sharing my screen. Remote viewers don’t need to install anything, as there is a Web viewer. But if the remote participants do install the Yuuguu client, they can also request control of the presenter’s screen.

Yuuguu also gives you a telephone conference line with global dial-in numbers. It is a free service in the US, although you still have to dial long distance.

Yuuguu lets you chat across several instant messaging networks. And it works on Windows, Linux, and Mac.

Funny name, great service!

Advertisements

Posted in PC Tech | Leave a Comment »

AppEngine JDO example #1: retrieve an object by ID

Posted by David Chandler on October 30, 2009

This is the first of a series of posts that will demonstrate a variety of JDO mappings and queries with AppEngine.

For starters, let’s retrieve an object from the Datastore given its ID. Here’s the User object in our domain model:

package com.roa.client.domain;

import java.io.Serializable;

import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class User implements Serializable
{
	private static final long serialVersionUID = -1126191336687818754L;

	@PrimaryKey
	@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
	private Long id;
	@Persistent
	private String firstName;
	...
}

Now we want to retrieve a User object given the ID property obtained from getId(). Easy enough, you think, as the JDO PersistenceManager provides a method for this:

// Doesn't quite work
User attachedUser = (User) getPM().getObjectById(userId);

But there’s a catch. Confusingly, the ID needed by getObjectById is a JDO ID, not the object property named “id” that we’ve annotated as an IDENTITY. You can get the JDO ID one of two ways. Whenever the object is attached, such as just after you’ve called makePersistent() on it, you can call persistenceManager.getObjectId(obj) and keep it in a safe place for later use. Alternatively, you can use a JDO helper method at any time to get the JDO ID from the object ID:

		 // Must obtain the JDO ID first
		 Object idInstance = getPM().newObjectIdInstance(User.class, user.getId());
		 User attachedUser = (User) getPM().getObjectById(idInstance);

Fortunately, if you know the object’s class, there’s a 2-arg getObjectById that does take the object’s primary key property:

User attachedUser = getPM().getObjectById(User.class, u.getId());

Of course, you can always just run a normal query on the object’s ID property, but it’s a bit ugly because the simplest query syntax always returns a Collection and we assume here that there will be only one matching object.

		Query q = getPM().newQuery(User.class, "id == :userId");
		List<User> users = (List<User>) q.execute(u.getId());
		User attachedUser = users.get(0);

Better to let the query language know that we expect a unique object:

		Query q = getPM().newQuery(User.class, "id == :userId");
		q.setUnique(true);
		User attachedUser = (User) q.execute(u.getId());

Finallly, there’s the low-level Datastore API:

		Key key = KeyFactory.createKey(User.class.getSimpleName(), u.getId());
		Entity entity = DatastoreServiceFactory.getDatastoreService().get(key);

Posted in AppEngine, Java Data Objects | 5 Comments »

Notes from CloudCamp

Posted by David Chandler on October 29, 2009

There were about 100 folks at CloudCamp Atlanta last night. Participatns were mostly interested in Amazon EC2 or the upcoming Windows Azure platform (Microsoft was the primary sponsor). A handful of folks turned out for my “show me the code” presentation on AppEngine and GWT+MVP.

My main takeaway is that I’m really, really glad to be a Google AppEngine user. Most of the sessions and discussions centered around how to grow/shrink your Amazon server pool automatically and how to scale MySQL. These are things I don’t have to worry about at all as an AppEngine user. AppEngine is perfect for my application: launching a one-man startup that could go viral (not to mention it’s free to get started!) I’m just plain tired of sysadmin, and I’m willing to trade theĀ  freedom to run any configuration of my choice for the scalability that comes with AppEngine’s constraints.

There was some discussion regarding the cloud and SLAs (or lack thereof). Someone said they needed five nines, not three. I don’t know where they got either number, but .999 reliability is definitely good enough for me. I have a consumer-facing app that doesn’t involve money, and I’ll be ecstatic if I have only 8 hrs 46 minutes downtime in the coming year. It’s clear that cloud offerings (especially AppEngine) appeal more to lone developers and small startups than to enterprises, although Amazon seems to have made great inroads in this area. It’s always going to be easier to start in the cloud than to move an existing data center. What excites me most about AppEngine and the like is that ONE developer can realistically create and deploy a scalable application. This has the potential to unleash a whole new wave of entrepreneurial energy on the Internet, and will make it possible for smaller companies that could never afford a data center to nevertheless get custom software for their needs. Which means we software engineers should get to do more coding and less sysadmin. Yay!

Other takeaways:

Lots of folks were happily using RightScale to manage Amazon EC2 instances and automatically grow or shrink the server pool based on load.

IBM provides Amazon machine images of its popular products like WebSphere FREE for development use (other than Amazon charges, of course).

Posted in AppEngine | Leave a Comment »

How to clean up muddy water

Posted by David Chandler on October 29, 2009

in Photoshop, that is…

  1. Select the muddy water using the quick selection tool.
  2. Create a new Hue/Saturation adjustment layer using the selection as the mask.
  3. In the Hue/Saturation dialog, select the Yellow channel.
  4. Set saturation way down and luminance way up.
  5. Now people will think your photo was taken in the pristine waters of the Rockies instead of Georgia…

AfterBefore

 

 

Posted in Photography | Leave a Comment »

CloudCamp Atlanta tonight

Posted by David Chandler on October 28, 2009

I’m planning to do a short unconference session on securing AppEngine services with gwt-dispatch and unit testing with AppEngine and gwt-dispatch at tonight’s CloudCamp Atlanta.

I’m looking forward to meeting some local AppEngine developers, as I’ve been feeling awfully close to the bleeding edge lately. I routinely find that solutions have been posted on AppEngine forums just eight days ago, and sometimes don’t exist yet. I really need TaskQueue in order to send out emails, which is still experimental in Labs, and would even more like to use deferred.defer (less than two weeks old), but alas, it’s currently only available for Python.

Posted in AppEngine | Leave a Comment »

Writing common test data services for gwt-dispatch with Guice

Posted by David Chandler on October 28, 2009

The way it stands now after my last several posts on unit testing is that each test method in a JUnit TestCase runs its own context, including its own PersistenceManager injected with Guice. Because I’m initializing the AppEngine test environment with LocalDatastoreService.NO_STORAGE_PROPERTY = TRUE, any test data I create in one test is not available to the next test method, even in the same TestCase class. This is typical behavior for JUnit test cases, and generally a good thing as each test should be independent, but it does mean we need a convenient way to create test data. My current strategy is twofold:

  1. Create test data used by all tests in the TestCase setUp() method that runs before each test
  2. Create common test data (used by multiple TestCases) in test data generator services

The first problem to solve is how to get access to a dispatch service and PersistenceManager inside the test data generators. Both are now being injected by Guice as covered in previous posts, so I’ve written a BaseTestDataService that does the Guice magic:

package com.roa.test.service;

import net.customware.gwt.dispatch.client.standard.StandardDispatchService;

import com.google.inject.Guice;
import com.google.inject.Injector;
import com.roa.server.guice.ServerModule;
import com.turbomanage.gwt.server.PMF;
import com.turbomanage.gwt.server.guice.DispatchTestModule;

public class BaseTestDataService
{
	protected static Injector inj = Guice.createInjector(new ServerModule(),
		new DispatchTestModule());;

	protected static StandardDispatchService getService()
	{
		return inj.getInstance(StandardDispatchService.class);
	}

	protected static PMF getPMF()
	{
		return inj.getInstance(PMF.class);
	}
}

I’m intentionally using a static getPMF() method to make it as simple as possible to use the test data services in a unit test via static methods. Alternatively, I could have used instance methods and constructor injection, but then you’d have to create a new instance of a test data service in each test, which is just that much more code to write… Also, constructor injection is not possible in this case because the TestCases themselves are not instantiated by Guice, so instantiating a new test data service from a test case would not involve Guice, either.

It does not matter that the BaseTestDataService and BaseTest (below) are both calling Guice.createInjector() and thereby creating multiple Guice contexts, each having its own PMF instance. The important thing for these database tests is that they’re all going against one Datastore, not one PersistenceManager.

Here’s a simple test data generator that extends BaseTestDataService and provides a method to add a test user:

package com.roa.test.service;

import com.roa.client.domain.User;
import com.roa.shared.rpc.AddUserAction;
import com.roa.shared.rpc.AddUserResult;

public class UserTestDataService extends BaseTestDataService
{
	public static User addTestUser() throws Exception
	{
		// Create new user
		User u = new User();
		u.setEmailAddress("test@example.com");
		u.setFirstName("Test");
		u.setLastName("User");
		u.setGoogleAccountId("testAccountId");
		AddUserResult userResult = (AddUserResult) getService().execute(
			new AddUserAction(u));
		u = userResult.getUser();
		return u;
	}
}

Note the call to getService() on line 17. Thanks to Guice, test data generator services can invoke gwt-dispatch ActionHandlers the same way as the tests themselves.
Finally, here’s a test case that calls the above service to create a test user in the Datastore:

package com.roa.test;

import java.util.List;

import javax.jdo.Query;

import com.appenginefan.toolkit.unittests.BaseTest;
import com.roa.client.domain.User;
import com.roa.test.service.UserTestDataService;

public class UserTestCase extends BaseTest
{

	@Override
	protected void setUp() throws Exception
	{
		super.setUp();
		UserTestDataService.addTestUser();
	}

	public void testUserAdded() throws Exception
	{
		// Run tests here
		Query q = pm.newQuery(User.class, "emailAddress == e");
		q.declareParameters("java.lang.String e");
		List<User> users = (List<com.roa.client.domain.User>) q.execute("test@example.com");
		assertEquals(1, users.size());
		User user = users.get(0);
		assertNotNull(user.getId());
	}
}

I should probably show my BaseTest method, too. I’m using AppEngineFan’s BaseTest as discussed in previous posts and modified the setUp() method for Guice injection as follows:

	/**
	 * Sets up the App Engine environment.
	 */
	@Override
	protected void setUp() throws Exception
	{
		if (initializer != null)
		{
			throw new UnsupportedOperationException(
				"setup may only be called once!");
		}
		super.setUp();
		initializer = new TestInitializer(getEnvironmentOrNull());
		initializer.setUp();
		Injector inj = Guice.createInjector(new ServerModule(),
			new DispatchTestModule());
		this.testSvc = inj.getInstance(StandardDispatchService.class);
		this.pm = inj.getInstance(PMF.class).getPersistenceManager();
	}

Thanks to Guice, we can now get access to the PersistenceManager and call ActionHandlers via a dispatch test service even from static methods in test data generators. This greatly streamlines unit testing.

Posted in AppEngine, GIN / Guice, Model-View-Presenter | Leave a Comment »

More on unit testing with an injected JDO PersistenceManager

Posted by David Chandler on October 27, 2009

Regarding my previous post, it turns out that I needed a TestPMF implementation sooner than I thought. The reason is the way I’m injecting a DispatchTestService in my unit tests (as described in this post). I’m calling createInjector() in the setUp() method, which gets run before each test method:

	@Override
	protected void setUp() throws Exception
	{
		super.setUp();
		Injector inj = Guice.createInjector(new ServerModule(),
			new DispatchTestModule());
		testSvc = inj.getInstance(StandardDispatchService.class);
		// This pm is needed only for code in this class that calls a PM directly
		// ActionHandlers are injected with the PMF singleton from Guice
		pm = inj.getInstance(PMF.class).getPersistenceManager();
	}

Since setUp() gets called before each test method, Guice is initialized for each test method, and therefore Guice calls the constructor for my DefaultPMF class for each test method. Repeated from the previous post, the DefaultPMF class looks like:

package com.turbomanage.gwt.server;

import javax.jdo.JDOHelper;
import javax.jdo.PersistenceManager;
import javax.jdo.PersistenceManagerFactory;

public final class DefaultPMF implements com.turbomanage.gwt.server.PMF
{
	private final PersistenceManagerFactory pmfInstance = JDOHelper
			.getPersistenceManagerFactory("transactions-optional");

	public DefaultPMF()
	{
	}

	@Override
	public PersistenceManager getPersistenceManager()
	{
		return pmfInstance.getPersistenceManager();
	}
}

Because DefaultPMF creates a named PersistenceManagerFactory, JDO complains that the named PersistenceManagerFactory has already been created. My solution for now is to replace the DefaultPMF with a TestPMF that uses a Properties map to initialize the PersistenceManager, just as the AppEngineFan TestInitializer does. Here’s a working TestPMF:

package com.turbomanage.gwt.server;

import java.util.Properties;

import javax.jdo.JDOHelper;
import javax.jdo.PersistenceManager;
import javax.jdo.PersistenceManagerFactory;

public class TestPMF implements PMF
{
	private final PersistenceManagerFactory pmf;

	public TestPMF()
	{
		Properties newProperties = new Properties();
		newProperties
			.put("javax.jdo.PersistenceManagerFactoryClass",
				"org.datanucleus.store.appengine.jdo.DatastoreJDOPersistenceManagerFactory");
		newProperties.put("javax.jdo.option.ConnectionURL", "appengine");
		newProperties.put("javax.jdo.option.NontransactionalRead", "true");
		newProperties.put("javax.jdo.option.NontransactionalWrite", "true");
		newProperties.put("javax.jdo.option.RetainValues", "true");
		newProperties.put("datanucleus.appengine.autoCreateDatastoreTxns",
			"true");
		newProperties.put("datanucleus.appengine.autoCreateDatastoreTxns",
			"true");
		pmf = JDOHelper.getPersistenceManagerFactory(newProperties);
	}

	@Override
	public PersistenceManager getPersistenceManager()
	{
		return pmf.getPersistenceManager();
	}

}

Now simply bind PMF to its TestPMF implementation in your Guice module for tests (DispatchTestModule in the setUp() method above), and each unit test method will run with a freshly created PersistenceManager.

Posted in AppEngine, GIN / Guice, Model-View-Presenter | 1 Comment »

Unit testing with JDO PersistenceManager injected via Guice

Posted by David Chandler on October 26, 2009

This is a follow-up to last week’s post on unit testing ActionHandlers with Guice. David Peterson pointed out on the gwt-dispatch mailing list that I could inject a PersistenceManager into my ActionHandlers in order to provide an alternate PersistenceManager for unit testing. I don’t actually need an alternate PM yet as it is handled transparently by my AppEngine test environment, but I thought it would be easier to do it sooner rather than later, so here goes.

I’ve created an interface called PMF (in order to avoid confusion with JDO’s PersistenceManagerFactory).

package com.turbomanage.gwt.server;

import javax.jdo.PersistenceManager;

public interface PMF
{
	PersistenceManager getPersistenceManager();
}

My default PMF implementation works exactly the same as before:

package com.turbomanage.gwt.server;

import javax.jdo.JDOHelper;
import javax.jdo.PersistenceManager;
import javax.jdo.PersistenceManagerFactory;

public final class DefaultPMF implements com.turbomanage.gwt.server.PMF
{
	private final PersistenceManagerFactory pmfInstance = JDOHelper
			.getPersistenceManagerFactory("transactions-optional");

	public DefaultPMF()
	{
	}

	@Override
	public PersistenceManager getPersistenceManager()
	{
		return pmfInstance.getPersistenceManager();
	}
}

The DefaultPMF gets bound in my Guice ServerModule:

	@Override
	protected void configureHandlers()
	{
		...
		bind(PMF.class).to(DefaultPMF.class).in(Singleton.class);
		...
	}

And finally, the PMF is injected into an ActionHandler:

public class AddUserHandler implements
	ActionHandler<AddUserAction, AddUserResult>
{
	@Inject
	private PMF pmf;
	private PersistenceManager pm;

	@Override
	public AddUserResult execute(AddUserAction action, ExecutionContext context)
		throws ActionException
	{
		this.pm = pmf.getPersistenceManager();
		...
	}
	...
}

Now, when the need arises for a test implementation of PMF, I can easily bind a different implementation in my Guice TestModule as shown in the earlier post.

Update: I did not test this thoroughly before I posted, and the need for a TestPMF arose just hours later. See my next post for the solution.

Posted in AppEngine, GIN / Guice, Model-View-Presenter | 1 Comment »

Run Linux and Windows together without dual booting

Posted by David Chandler on October 24, 2009

Welcome to “the Saturday evening post.” This will be a more-or-less weekly PC tech post in addition to my daily Java-related postings throughout the week.

There are two programs I can’t live without under Linux: Quicken, which I first installed on 3.5 inch floppies and has run my financial life ever since, and RoboForm, which manages nearly 100 mostly-generated passwords for me. As much as I would like to run Ubuntu and OpenOffice exclusively, I am unwilling to dedicate another PC to the task or to be constantly rebooting.

I was therefore delighted to find that you can run Ubuntu right within Windows as a virtual machine using the free VMware Player. Here are the steps to install Ubuntu on a clean virtual machine.

  1. Download and install VMware Player
  2. Download the Ubuntu ISO image
  3. Go to easyvmx.com and fill in the blanks to create your virtual machine definition file. Check the LiveCD ISO-image box and enter the path to the downloaded ISO file. When you run VMware Player for the first time, it will boot from the ISO image just as if you had put the CD in the drive, allowing you to run or install Ubuntu in the virtual machine.

That’s all there is to it. Granted, with this approach, you still have to deal with Windows, but being able to switch back and forth between operating systems with Alt+Tab sure is handy.

A very cool thing about virtual machines is that all the data for the VM exists in a few files under your VMX directory. Which means you can copy the VMX files to a portable hard drive, plug it into any computer with VMware Player installed, and voila, you’re right where you left off. That is one painless backup strategy.

Theoretically, you can also run the other way around, by the way, and install Windows in a virtual machine running under VMware Player for Linux. However, I have not tried this.

Posted in PC Tech | Leave a Comment »

JSF Quick Reference available again

Posted by David Chandler on October 23, 2009

At long last, I’ve resurrected the JSF quick reference that I used to host at learnjsf.com. It’s on the JSF page above.

Posted in JavaServer Faces | Leave a Comment »

 
%d bloggers like this: