Roger Cuddy

We’re still a bit undecided on whether to use the library website to post items intended only to the dev team. For now dev items will be posted on my SourceForge site and at Poor’s site both.

Poor and I have tried to structure the build process to minimize special requirements on any developer’s machine . So far at least we’ve been able to keep it pretty mild, especially if you only have the developer role. Most developers will already have everything they need installed.

To develop and build

• Text Editor of your choice. Use whichever tool you normally do but DO NOT check IDE specific files into the source repository.
• Subversion (and a GUI if you wish)
• JDK 1.6 SE
• Ant 1.7.1
• Optional – PMD installed for use by Ant, ant task doc

If you will be working on the website then you need to add a little more

• Pushing to the website via the build script requires that your ssh key be registered with sourceforge. We very much do not want any user ids and passwords embedded in the script at any time. It’s just too easy  to forget and check in build.xml with your id / pw now publicly available.
• Pushing from Ant requires you have optional library JSch installed.

That’s it for now anyway. Changes will be posted as new articles so they are easy to catch.

Can you really run a functioning WordPress blog on Source Forge’s user space? We’re going to find out. My first thought about installing was admittedly ‘this is going to hurt!’. Once setup it will be accessible at Rog’s SF Notes

<edit>The install went well. You can read about it at the follow up post <end edit>

Goals:

1. Be able to install themes and plugins.
2. Responsive enough that it drives readers mad waiting on pages to render.
3. Support sitemaps
4. Easy to backup/restore both the database and the file system.
5. Allow multiple contributors

Quite modest but if I can get that much working I’ll be pretty happy. #1 itself rules out using SF’s Hosted Apps as it won’t be possible to use any themes or plugins.

Will post soon on how it all went.

Recently there have been several occasions where I have needed an application to use an embedded driver but also needed to allow for the occasional login to the database externally while the application is executing. Derby works wonderfully for this and starting a server within the application is exceedingly simple. Here I will give just a brief example that should be enough to demonstrate the method. The code fragments here are admittedly simplistic but they work and show the principles cleanly.

//First a method to get an embedded connection:

public Connection getConnection() {

    try {

        return DriverManager.getConnection("jdbc:derby:"+dbPath);

    } catch (SQLException e) {

        log.error(e.getMessage(),e);

        return null;

    }

}

//Now a method to start the server for external connections.

private void startDBServer() {

	try {

		server = new NetworkServerControl(InetAddress.getByName("Localhost"),1527);

		server.start(null);

	} catch (Exception e) {

		log.error(e.getMessage(),e);

	}

}

//And lastly let's add a shudown hook to ensure the server gets a chance to exit clean.

private void setShutdownHook() {

	Runtime.getRuntime().addShutdownHook(new Thread() {

		public void run() {

			log.info("**** Application ending ****");

			try {

				server.shutdown();

				} catch (Exception e) {

					log.error(e.getMessage(),e);

				}

			}

    } );

}

That’s the basics and it doesn’t get much easier.

The Singleton Pattern is quite simple but at the same time extremely useful. If you have done any serious programming then there is a good chance that you have fudged the behavior into a class or forced a class to act as a singleton without knowing the pattern. In this very short article we will examine the common method to construct a singleton.

Read the rest of this entry »