When you receive a diagnosis of diabetes, it’s the beginning of new chapter in your life that involves continual monitoring of your blood sugar. Software can help you manage that task. GNU Gluco Control (GGC) is one free, open source option.

A programmer named Dieter created GGC in 2001 or so, but Slovenian developer Andy Rozman joined the project in 2004 and took it over. “At the time,” Rozman says, “I was looking around for diabetes software, but each application had its own problems. (Now we have a lot more to choose from, and most solutions are quite adequate.) I am a Java programmer, so I was looking mostly for Java solutions. When I first time saw GGC I was not impressed with it. It was crude with almost no functionality, but I decided it was the one I could help develop.”

Rozman used Visual SlickEdit for a while to work on the Java code, until about year and half ago, when the project made its first official release. “Fellow developer Reini and I started thinking that now that we were ‘out,’ more people will try to use it and help us, so we need to write documentation on how anybody can help. Our first step was selection of an official tool that could be used by anyone. Reini had used Eclipse for a few months at that time and he promoted it to me. Eclipse is now official development environment for GGC.”

The project promotes the software on diabetes web sites and forums. “Whenever I find any new forum or web site that covers diabetes software, I send mail and ask people there to add it,” Rozman says.

GGC maintains food and meals databases; the one from the USDA is imported, and users can build their own. “We support many diabetes devices: we support about 25 different glucose meters from five different companies, and we currently support one pump, and two more are in works. We are trying to add more devices, and also work on tools. For instance, we have a so-called Bolus Helper, which helps determine how much insulin must be injected. This is the function I use the most, since my pump doesn’t have this integrated.

“We have a lot of features planned for future: Extensions to the pump tool with new devices, adding a continuous glucose monitoring system (CGMS) tool with basic support for CGMS devices, a database tool (GGC supports many (almost all) JDBC-supported databases, but currently we don’t have automatic install of tables and initial data to user -selected databases), new graphs for all features, possibility of online upgrade, appointments, stocks, and many many more.”

Rozman says he welcomes help with programing, ideas, translations, and testing – “everything. We have some developers who drop by and do some stuff and then take their leave. Some stay for a longer time, but not many, so most of work is still on my shoulders.”

In software terms, anything more than a decade old is usually obsolete – but not always. Xye was inspired by a 1992 Windows shareware game called Kye that Bolivian developer Victor Soliz Kuncar found when he was 12 on a computer magazine’s CD-ROM. From that base Soliz Kuncar added several elements and objects, until Xye evolved into a challenging puzzle game that also includes levels in which dexterity with the keyboard is more important than the puzzle. The goal of the game is to gather gems in each level, but there may be traps, monsters, and hard puzzles in your way. This week, in honor of the season, the project is releasing a Christmas level pack.

Starting the Xye project in 2005 gave Soliz Kuncar a chance to practice C++ programming and game development. “I first used Haaf’s Game Engine (HGE) and Code::Blocks with MinGW32,” he says. “However, I wanted the game to be cross-platform and ended up moving to Simple DirectMedia Layer SDL. I eventually moved from Code::Blocks and MinGW32 to just a makefile and text editor and g++ because it was simpler to code from different Linux machines using those tools.”

When Soliz Kuncar first released Xye, it was not especially user-friendly. “It first was just a list of level files that you could click, but I kept making changes and eventually added a simple GUI. However, it is still not optimal. I’d like to add things like a main menu that would take you to tutorials and official levels, and add some graphical instructions. I’d also like Xye to remember what levels you have already solved. Adding support to the editor so that it allows you to create multi-level files would be also helpful.”

Then there’s the issue of the game’s look and feel. “My brother has been in charge of the art, and he was making a new look that was more stylish. Unfortunately, we have not been able to focus on Xye as much as we’d like recently.” The most recent release was in August. Soliz Kuncar says he usually makes updates in the first months of the year and between August and October.

Soliz Kuncar says the project could use more level designers. “We need interesting levels that are suitable for basic-intermediate level players; I tend to make levels that are too complex.” If you’d like to help, the best way to contact the project is by email.

There’s a whole nosql movement these days looking to replace relational database management systems, with “something else,” where that something else can be anything from key-value stores to document databases to flat files and map-reduce frameworks, or column-oriented databases.

Here on the Geeknet engineering team, we’ve got a lot going on with our sites SourceForge.net, Slashdot, freshmeat, and fossfor.us. We’ve been using relational databases Postgres and MySQL for a variety of things for a long time. But we have various needs where the new non-relational datastores make a lot of sense, so we’ve been investigating a number of these nosql systems.

MongoDB at SourceForge

Earlier this year I was part of a rewrite of the project pages on SourceForge.net. We wanted a document store that would allow us to save all the data we needed for a project page render in a single record. Our tests lead us to MongoDB, which is fast and has simple, easy to use replication. Mongo has allowed us to serve all of the project pages on SourceForge.net without any page level caching.

I first posted about our use of MongoDB on my personal blog about six months ago. Now I’m happy to announce that we’ve re-factored out the bits of our MongoDB helper infrastructure that are generally reusable into a separate Python package called Ming. It’s the code that runs SourceForge.net’s most popular pages, and which we are using to build several interesting new projects.

Ming rules Mongo

If you’re developing Python applications where a document style database makes sense, Ming provides a clear way to interact with MongoDB. It allows you to attach to multiple MongoDB sessions, do work in each, which makes working with replicated databases easier. It helps with data migrations, and can help you to enforce some schema on your Mongo documents so that you can make assumptions about document structures in your code.

We’re very happy with it, and it’s pretty well tested, both in terms of unit testing, and in terms of use on high volume, high traffic sites.

Ming borrows a lot of ideas from SQLAlchemy , and we think that Ming and SQLAlchemy are two great tastes that taste great together.

Some data fits the document-oriented view of the world really well, and at other times it makes a lot of sense to store data in an RDBMS where you get all the data integrity and transaction processing help that an RDBMS provides.

More to come…

We’ve never stopped providing free tools to open source projects, promoting open source, or working with open source tools. Nearly all of the engineers here contribute to various open source projects. Our individual commitment to various communities has always been high. But we haven’t been very organized about it, and that’s something we’re trying to change. Among other things we’ve started actively looking for internal stuff that we can open up for the rest of the community. Ming is our first release.

A common etiquette rule warns people not to discuss politics or religion in polite company. That may be good advice, but when you want to have a serious discussion about sensitive topics online, you can turn to VIF (VIrtual Forum), a web-based discussion forum application designed especially for discussions of complex and controversial matters.

When faced with with an increasing number of contributors, Internet-based discussions scale better then face-to-face discussions. However, in typical forum applications, the quality of discussions can rapidly degrade if the discussion turns to complex or controversial matters. The VIF discussion model deals with this problem by providing a structured hierarchy of questions and followups by registered community members, with each contribution reviewed by a randomly selected other participant. VIF forum contributions are written using wiki style for text markup.

Swiss software engineer Benno Luthiger began developing VIF in 2002. “I use the Eclipse IDE for the development. With Release 0.9 earlier this year I changed the application’s architecture to a very modular design, leveraging the OSGi component architecture. I’m able now to provide different skins for the application, and it’s much easier to extend the application, to add new functionality.” Luthiger released version 0.9.2 last week.

Luthiger says that only the few features listed on the project’s roadmap remain to be implemented before the official 1.0 release. He expects to continue making releases once or twice a year. He says he chose to put the project on SourceForge.net because “SourceForge is up-to-date and a very credible player in the open source arena. Therefore, projects hosted on SourceForge can benefit from high traffic.”

For organizations that want to test the software, the project offers a version of the application that contains both an embedded web server and database. You can download it, expand it into any directory, and start a script to fire up the web server and populate the database. Then you can log into the application and walk though its features. If you find it suits your needs, you can then delete the directory into which you extracted the software and download the regular application version.

Luthiger welcomes help from other SourceForge.net developers, beta testers, and evangelists. “Besides contributing to a project in many ways, the members of the community bring in new ideas, thus driving the project along. And last but not least, they can make a project popular. People can get in touch with me directly or the project’s mailing list.”

Today we are making some important changes to the Community Hub. Our goal has always been to ensure open, clear communication between our user community and the SourceForge engineering team. Part of having an open process is making sure that information is easy to find, which wasn’t always true in the past. To improve the dialog, we decided that the best solution was to simplify the Community Hub.

Our blog will be at the center of the new design. Lee Schlesinger will continue to provide his interesting stories about projects on SourceForge. We’ll also use the blog to communicate with you about ongoing development on the site, so you can keep up with changes as they come. As we push out enhancements and new features, we’ll use the blog to let you know about them.

You can also follow us on Twitter for real-time engineering updates.

The event calendar and forums have been removed. We felt that these features weren’t contributing enough to the site, and they caused information to be spread out in too many places. We think the overall experience will be improved for everyone by focusing the discussion in fewer places.

We are committed to an open process, and community involvement has always been a critical part of SourceForge. If you have any feedback or questions, you can always contact our development team directly by submitting a ticket, sending an email, or jumping on IRC. We look forward to building and improving SourceForge with your help.