Hi All,

Thanks to everyone who tested our alpha release of 1.6, we’re releasing 1.6 Beta. You can get it on the downloads page.

We’ve made only two significant changes since the alpha:

• We’ve implemented “core modules” properly, meaning that we may now have modules that are required by core, and OpenMRS will not start up if they are not present. (The purpose is to make it easier for feature development to happen independently. Logic is the only one of these at the moment.)
• We had switched the role name from “System Developer” to “Administrator” but we’ve switched that back. It will change to Administrator again in the future, but not until we have added an integer primary key to the table so that we may correctly rename the role, instead of deleting and re-adding it. (Thanks Mark Goodrich for testing with the Patient Flags module and catching this.)

You can see the additional trivial changes in the release notes.

We still need to see some further testing of Beta release before we’re ready to move onto a release candidate. And I’m actually going on vacation for a week. So…go ahead and test away so that when I get back we’ll be all set to release.

-Darius

It's been a while since I last updated on the progress of the Facility Data Module. So without farther adieu here we go:

• The relation between the FacilityDataFormSchema and FacilityDataFormSection is now Many to Many meaning that sections can now be re-used between several form schemas (or reports).
• It now runs without errors on OpenMRS 1.5.x
  

1. Allow for sections to be re-ordered within the schema (this is currently not possible and is a show-stopper.
   
2. Fix up the calendar management pages -- those are horribly ugly, but this is after all a first pass, so that is to be expected right?
3. Currently, it does not validate inputs for Numeric data types -- It need to.
   
4. There still needs to be the ability to analyze the data that exists in the system to submit to funding sources; those pages need to be implemented but that is phase two of the project.
   
5. There are likely other sore spots that exist that I do not see at this point and time that will be fixed at a later date.

Hi OpenMRS Community,

Our first alpha preview release of OpenMRS 1.6 is ready!

First off, I’d like to thank the 35 developers who contributed code to this release: Agnor, arthurs, ayeung, ball, bmckown, bwolfe, cliff.mcintosh, dfuterman, djazayeri, dthomas, emendez, ewolodzko, hkwathome, jamesm, jmiranda, Keelhaul, Knoll_Frank, luzhuangwei, madanmohan, mkopinsky, mogoodrich, mseaton, msheley, n.nehete, nribeka, Pascal, r0bby, rarcos, rcrichton, samrajni, sunbiz, suneeth, tmdugan, upul, yatitandon

You can read the release notes here or, if you’re impatient, you can go straight to the prerelease downloads page.

Note that this is a PRE-release, intended for testing, and not for production deployment. The changes made in 1.6 are much less invasive than those we made in 1.5, so I expect there to be far fewer bugs, and I expect us to be able to get to beta, or even to a release candidate, within a couple weeks. But to do that we need your help. We need people to install 1.6 alpha, play around with it and look for bugs.

There are three specific things I’d really like to ask for help testing:

• Everyone, even if you don’t have time for thorough testing, should try making a copy of their database, upgrading it by running this 1.6 alpha war, and reporting any failures
• People who use logic should test their code and make sure it still works now that most logic code has been pulled out into a module
• If you want to have Patients-who-are-Users then that is now possible. Please test it!
• Module owners should re-test their modules, because of a small number of unavoidable non-backwards-compatible changes. HTML Form Entry is broken, for instance.

A week from today I would like to release an alpha-2 or a beta release, so do your testing sooner rather than later.

Thanks,
Darius

In order to improve the performance of mysql when dealing with large databases, there's a couple of settings that can be tweaked in your my.cnf file (or through a MySQL administration tool). The following line has proven to be the most useful.

innodb_buffer_pool_size = 1G

I've been meaning to write about this improvement for the last few weeks, but I wanted to test it myself first. So far I'm very pleased with the performance improvement (database restore time is down from about 3 hours to about 45 minutes on a ~1.2G database). I haven't tested how this setting affects MySQL during normal execution, but it certainly helps improve performance during backups and restores. So if you find yourself backing up and restoring large MySQL databases, you should test this out. You should (obviously) not set innodb_buffer_pool_size to a value greater than the available memory on your machine.

Thanks to Marc Harrison for the tip.

If you want to read some more about this configuration, I found a couple of blog entries from a few years ago Enjoy!

http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/

I just bought the new Mac Mini from Apple. It's my first Mac since the Mac Plus of the early 90's and I have to say ... it feels good to be back. I still love doing development on Ubuntu, but Mac OS X is easy to get used to and a lot of fun to play around with. Nothing compares to "apt-get install ..." (on Ubuntu) when getting a development environment set up, but this tutorial for Tomcat 6 probably saved me a couple of hours of agony of going it alone.

More to come ...

Here's the procedure I used to move an existing "dumb" subversion project to one that follows the subversion convention (trunk/branches/svn). It's a combination of the two ideas presented in the articles below. More steps then I was hoping for, but it's a pretty simple-to-follow solution and much less aggravating than the Eclipse approach.

(this procedure assumes that you are using Linux, but the process would be similar on Windows or Mac)

// 1. Checkout a fresh copy of your project
$ svn co http://svn.myproject.com/myproject myproject

// 2. Change directories to make it easier perform svn operations
$ cd myproject

// 3. Add the new trunk directory
$ svn mkdir trunk

// 4. Locate all files/dirs in the current directory and svn move them to the trunk directory
$ find . -maxdepth 1 ! -name trunk -exec svn mv '{}' trunk \;

// 5. Double check that all files have been svn move'd (.classpath, .project, build.xml, etc)
$ ls -la trunk

// 6. Commit all changes
$ svn ci -m "myproject: moving all files from myproject into myproject/trunk"

// 7. Switch your local copy of the module to
$ svn switch http://svn.myproject.com/myproject/trunk myproject


Resources:

• http://www.ramblingengineer.com/2009/08/03/fixing-subversion-branch-and-trunk-directories
• http://stackoverflow.com/questions/345683/svn-creating-trunk-directory-on-existing-repository

OpenMRS Developers Conference in Latin America

The following document was used by the developers/trainers at the OpenMRS Developer's Conference in Lima, Peru. We kept track of the agenda and topics we discussed during the week in order to possible create a curriculum for future training sessions. I'd be glad to discuss this with anyone who is looking to create training manuals for both short and long-term training sessions on OpenMRS-related technologies.

This document is still pretty raw, but feel free to use bits and pieces if you find them useful.
http://docs.google.com/View?id=dnc9s5q_10gb5qb4dn

OpenMRS is planning a Meet-and-Greet at AMIA 2009 in San Francisco on Tuesday, 17-November, at 7:30 pm.  We will meet for drinks at the Urban Tavern next to the Hilton.