Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Hereâs the projects that weâre featuring this week on the front page ofÂ SourceForge.net:
Wireshark is a powerful network protocol analyzer developed by an international team of networking experts. It runs on UNIX, OS X and Windows. (Looking for Ethereal? You’re in the right place. We switched names in May 2006 due to trademark issues.)
Dolibarr ERP – CRM is an easy to use ERP and CRM open source software (run as web php or standalone) for small to mid-sized businesses, foundations or freelancers (inventory, warehouse, order, invoice, shipment, POS, members for foundations, bank accounts…). Dolibarr is also available with auto-installers for users with no technical knowledges to install Dolibarr and all its prerequisites (Apache, Mysql, PHP) with just one package. Available platforms for such packages are: Windows, Debian, Ubuntu, Mint, Redhat, Fedora, OpenSuse, Mandriva, Mageia. Other platform can use the generic distribution. This is a modular product, than can be enhanced with tons of external modules to provide you features not available by default.
Slackel is a Linux distribution based on Slackware and Salix. It is fully compatible with Slackware and Salix but the difference is that it includes the current version of Slackware. So Slackware users can benefit from Slackel repositories. It is available in two editions, KDE and Openbox. Slackel disc images are offered in two different forms, Installation disc image and Live disc image. Slackel developed in Greece by Dimitris Tzemos.
[ Download slackel ]
JabRef is a graphical application for managing bibliographical databases. JabRef is designed specifically for BibTeX bases, but can import and export many other bibliographic formats. JabRef runs on all platforms and requires Java 1.6 or newer.
[ Download JabRef ]
SparkyLinux is a Live Linux distribution created on the “testing” branch of Debian GNU/Linux. Featuring customized light desktops, multimedia plugins and selected set of apps.
rEFInd is a fork of the rEFIt boot manager. Like rEFIt, rEFInd can auto-detect your installed EFI boot loaders and it presents a pretty GUI menu of boot options. rEFInd goes beyond rEFIt in that rEFInd better handles systems with many boot loaders, gives better control over the boot loader search process, and provides the ability for users to define their own boot loader entries.
[ Download rEFInd ]
A 32/64/16-bit Pascal compiler for Win32/64/CE, Linux, Mac OS X/iOS, FreeBSD, OS/2, Game Boy Advance, Nintendo NDS and DOS; semantically compatible with Delphi, Borland Pascal and Mac Pascal (partially) with extra features, e.g. operator overloading.
Our goal is to improve upon VisualBoyAdvance by integrating the best features from the various builds floating around. In order to uncompress the downloaded package, you need WinRAR or 7-Zip: http://7-zip.org/
[ Download VBA-M ]
Win32 build of Subversion. These binaries are built using Visual C++ 6.0 Should work on all flavours of Windows from Win2000 to Win8 and 2008 Server including server variants (not all tested). (1.7.x does not work on NT4 due to APR using new functions). Modules for Apache 2.2.x and 2.4.x (1.7.6 and up) is included. Language bindings are NOT tested. Source code is found at the Apache Subversion site at http://subversion.apache.org/ Code in this project is just a “Build script” and patches for VC6
For our March Community Choice Project of the Month, our community has selected Universal Media Server, a Multi-OS DLNA-compliant UPnP Media Server for streaming videos and other media over a network. The project founder, SubJunk, tells us about the project’s history, purpose, and direction.
SourceForge: Tell me about the Universal Media Server project please…
SubJunk: Our program serves media (video, audio and images) to many devices like TVs, gaming consoles, smart phones and more.
SF: What made you start this?
SJ: I started this project when I was working on another project called PS3 Media Server, so just a quick background on that: I had used PS3MS for years, and the project founder and developer shagrath – who is not only a very talented programmer but also a very cool guy – eventually lost interest since he didn’t use the program himself anymore. I started to make builds of it for myself and published them on the forum, and SharkHunter did his own builds too. Our builds became popular and that led to me and another developer, chocolateboy, being added as official developers to keep the project going. We made some great progress and further down the line more developers were added. Unfortunately this introduced instability in the program and I was spending more time fixing new bugs than anything else, and after a few releases with major bugs I decided to branch the project off to create Universal Media Server (and was joined shortly after by SharkHunter) with more of a focus on stability, and as the name suggests, support for a wider range of devices. Now we have a core team of 6: SharkHunter, valib, skeptical, DeFlanko, Optimus_prime and myself, as well as other frequent contributors who help with code and translations.
SF: Has the original vision been achieved?
SJ: I think so. We’ve fixed a lot of old bugs and implemented better quality control methods into our process which results in better stability, we have manual and automatic tests that are run before new releases, and we have a great community who are generous enough to give us useful feedback when we make a mistake so we can fix it pretty quickly.
SF: Who can benefit the most from your project?
SJ: It’s a great tool for anyone who wants to just use a media server program with no hassle. Many competing programs require you to wait for a media library to be built, which can take hours for those with lots of videos, but UMS is ready to use straight away with no configuration needed. We have lots of advanced features as well for those who want to use them, but I think our biggest advantage is that it just works.
SF: What is the need for this particular media server?
SJ: Aside from the things mentioned above, we have so many advantages! We offer subtitle support on every device, whether it supports subtitles or not, and we even support adding subtitles on the fly so you don’t have to find and download them yourself. We can output full quality DTS audio, which most servers compress, we interface with iTunes and DVDs, and there are many more specific benefits on our comparison page.
SF: What’s the best way to get the most out of using Universal Media Server?
SJ: To take advantage of our ability to stream media at top quality, it helps to have an audio receiver that can take DTS. Having a wired network is also useful for the best stability and quality, since the highest quality videos can sometimes need to be compressed for smooth transfer over wireless networks.
SF: What has your project team done to help build and nurture your community?
SJ: We are very grateful for our community, and our project members use our forums and issue tracker a lot. We give credit where it’s due by featuring the names of community members who help us in our release threads and readme files.
SF: Have you all found that more frequent releases helps build up your community of users? (Please provide insights if this is the case)
SJ: We have definitely found this. There are a lot of media servers out there, and a lot of them have been abandoned or are inactive, so it’s important to us to keep releasing new versions regularly to show our community that we are very active and will therefore be a good investment of their time.
SF: What is the next big thing for Universal Media Server?
SJ: We have been working hard on a web interface, which will allow us to support devices even without DLNA support. There is really no excuse for a modern device to not have DLNA support, but sometimes companies cut corners and that’s not the user’s fault, so we want to remedy those situations. We also have lots of other things in the works!
SF: How long do you think that will take?
SJ: It is already working and we are working on making it better, and will hopefully release a new alpha version with the web interface in the next month.
SF: Do you have the resources you need to make that happen?
SJ: We are a free program and we all do this out of pure motivation to improve the program. Sometimes people show their generosity by donating and thanks so much to everyone who has, it helps to cover our hosting costs.
TypEcs is TypeScript IDE for Eclipse.
IDE provides the following features:
1.5 - New and Noteworthy
Barcoding components plugin for the Eclipse based reporting tool Jaspersoft Studio.
It supports, linear barcodes, QR Code, Aztec code, PDF417 , Maxicode and Datamatrix.
The source is available.
The Virtual Developer Cloud-Connector is a lightweight Eclipse plug-in that allows you to access code generators that run on the Virtual Developer Platform. This single plug-in suffices to use all generators that are available on the Virtual Developer Platform. Generators are not being installed in Eclipse but stay on the platform. The Cloud-Connector sends models to the platform and recieves generated source files in return.
Check out the Virtual Developer Info Site to learn more about Virtual Developer.
Read the Virtual Developer Blog to get to know more about the latest developments.
Register for free on the Virtual Developer Portal to try out the available generators. When you check the "provider"-checkbox during registration, you can develop your own generators and run and market them on the same platform.
The Win32 Disk Imager project is a father (Tobin) / son (Justin) team, plus another developer, Jeff. Tobin is a regular in our IRC channel (Freenode: #sourceforge). This is a pretty cool story. Read on!
SF: Tell us what the Win32 Disk Imager project can do for folksâŠ
Tobin: Â Win32DiskImager is a tool to take filesystem images and raw files and write them to memory devices (USB memory sticks, SD/CF cards, etc). Â It can also read from the device and save the image as a backup.
SF: What was the problem you were trying to solve with this effort?
Tobin: Â This tool was originally developed for the Ubuntu 9.04 (Jaunty) Netbook release, targeting users of Netbooks with Windows preloaded. Â At the time, Ubuntu only shipped CD ISO images and Netbooks don’t have a CD drive. Â This was created as an easy to use solution for Windows users interested in trying the Ubuntu. Â I should note that the program went from concept to working release in a weekend. Â Justin can comment more on this.
Justin: Tobin simply called me up on a Thursday after school (Senior year of high school if I remember correctly), and needed a screenshot by the end of the weekend so they could do preliminary documentation. I sent a screenshot only a few minutes later (gotta love developing with Qt) and then had to learn the win32 API *shudder* and by Friday night I had a fully functional prototype.
SF: Has your original vision been achieved?
Tobin: Â For the targeted release, it went quite well. Â After it was released in April, 2009, Ubuntu changed the format of their ISO images and combined the Desktop and Netbook images, so the tool was no longer needed for this purpose. Â At this time, it was all but abandoned.
Justin: My original vision for it was simply a temporary tool for a temporary problem, that had other uses as well. After being asked to allow Ubuntu to take over the project and turn it into an Ubuntu specific tool, I kindly refused since I wanted to keep it a generalized tool with a wide range of uses. I didn’t quite imagine that that decision is what would ultimately allow it to explode in popularity like it has done.
SF: Who can benefit the most from Win32 Disk Imager?
Tobin: Â Anyone that is using Windows based systems to do development work on embedded systems or users that want to test the latest Cyanogenmod on their Android devices. Â I have also heard from users that use it to just back up their SD cards from their cameras.
SF: Whatâs the best way to get the most out of using Win32 Disk Imager?
Tobin: Â The program is very simple in design. Â The first thing to remember is to backup any important data you may have on your memory device before writing to it. Â And also, read the readme.txt file. Â If you have questions, please ask. Â We try to answer all questions that we can.
SF: What is the Win32 Disk Imager release philosophy; do you all use the release early, release often precept?
Tobin: Â There are currently two people actively maintaining it (Justin is focusing on another project also hosted on SourceForge). Â We also have received a few translations from other users, which is great. Unfortunately, we don’t spend nearly as much time on it as we probably should. Â We try to outline what features or bugs we want to resolve in the next release, then work towards that goal. Â My biggest issues are the constantly changing API’s in Windows, and having to find out how to integrate them in when something breaks.
SF: If not or if so, why?
Tobin: Â Time and resources are the biggest factors here.
SF: What are the key features from your most current release?
Tobin: As of v0.9, we support generating MD5 checksums for image verification (helpful for downloaded images), Drag and Drop images from Windows Explorer, and the ability to define a default directory for images through an environment variable (defaults to the user’s Downloads directory). Â This works quite well in Windows XP, but we have seen issues in newer Windows releases due to API changes.
SF: What did the project team do to make sure these were completed in a timely manner?
Tobin: Â Timely??? Â Due to our sporadic release cycle, just getting an updated release out was challenging enough. Â :P
Justin: As a side note here the first release was dubbed the “Truck Stop” release since one of the guys debugging it was doing so from a truck stop since we had very little time to get the project ready for the initial release.
SF: What was the first big thing that happened for your project?
Tobin: Â It wasn’t until mid-2010 when I had bought a Nook Color from Barnes and Noble that I discovered other interests in this program. Â The guy selling the Nooks was trying to also sell a book on using the Nook. I told him I was a Linux developer and could pretty much figure it out on my own. Â Then he showed me the chapter on “Rooting your Nook”. Glancing through it, I saw a screenshot of our program along with a url to the Wiki page instructions that I had written.
I immediately ran a Google search and found an entire community of users, mainly in the Android Hacker community, but also developers of embedded Linux systems and other types of devices. Â There were also a large amount of open bugs. Â Since Justin had moved on to other projects, I took over as lead maintainer, and along with Jeff, we have cleaned up all of the original bugs and added some new features along the way.
The other major event was moving the project to SourceForge (YEA!!!). This has helped out a lot, both in exposure and in the tools now available to us to make this project more noticeable. Since moving (and subsequently being targeted as a SF Project of the Week), our user baseÂ has grown a lot. Â Last time I was at Barnes and Noble, I found 6 different publications recommending our tool to their target audiences.
SF: What helped make that happen?
Tobin: Â For the first part, word of mouth, I guess. Â I can definitely say that just being on SourceForge has been a big thing.
Justin: It’s quite interesting that this project had received such worldwide fame despite having zero forms of advertising on our part. I guess that’s what you call going viral.
SF: What was the net result for that event?
Tobin: Â I recently received an email from a German magazine editor, saying they were going to write a feature on our project. Â I have also seen countless reviews, blogs, and even several video tutorials on Youtube. Â Downloads are continuously growing week over week (I check the stats daily while sipping my morning coffee).
SF: What is the next big thing for Win32 Disk Imager?
Tobin: Â We have a lot planned for upcoming releases. Â First and foremost is to move to either a newer release of mingw or something equivalent, as there are a lot of new API issues in Windows that aren’t addressed in the release we currently build against. Â Once we get that resolved, we have a wish list of features we want to integrate, starting with image compression/decompression on the fly.
Justin: A couple things I’ve been experimenting with outside of the project was to possibly have the drop-down-box show not only the drive letter but also the label on the device (for example mine might show up as “F: TuxDrive”). This would help a lot of people I think since my own personal experience of safely removing the drive on XP where it only tells you the letter has been annoying when the computer has 3 or 4 different removable devices plugged in. Also, it would be nice to eventually support batch processing of multiple images since the program is now also being used a lot in major tech companies where they’re flashing dozens of cards all hooked up to one system.
SF: How long do you think that will take?
Tobin: Â Hard to say. Â We already missed our soft target of 1.0 for the end of 2013. Â But we doÂ have an installer in the tree now. Â That was one of my goals for 1.0. Right now I am focusing on an updated tool base that supports the newer APIs for Windows 7/8.
Justin: As for the pieces I’d like to see, it might be difficult as I’m tiding up other projects, most notably my Open RPG Maker, before going off to college this fall. However, I may be able to squeeze enough time in there to get those two small parts easily done.
SF: Do you have the resources you need to make that happen?
Tobin: Â We could definitely use more help. Â We are always open to contributions. We have already received a few translations from users, along with some code contributions. Â I would also like to thank Jeff B (skydvr68) for his contributions in both code and with the questions forum.
SF: If you had it to do over again, what would you do differently for Win32DiskImager?
Tobin: Â I’ll let Justin answer the next few.
Justin: I don’t really think there is anything I’d do differently since the initial release, while a bit buggy, was still fully functional.
SF: Is there anything else I should know?
Tobin: If we can get our development environment issues resolved, 2014 will be a great year for new features. Â Hopefully.
Justin: Really awesome to have this project recognized as project of the month, especially seeing some of the other projects that usually get nominated. Feels pretty awesome to have played a part in getting this project there.
As a Model-Based Testing tool, MaTeLo (Markov Test Logic), offers opportunity to improve all the validation life cycle. This innovative solution, built on a mature process of validation, includes an association of models, traceability, evaluation and automatic generation of test artefacts (test cases and scripts).
Thanks to our Model Based Testing (MBT) tool MaTeLo, you can:
- create a usage model from functional requirements
- choose the right test strategy depending on the system maturity level
- automatically generate test scripts and test cases
Benefits: MaTeLo is a entire Test Framework in order to provide a model and control the test benches.
LOGpulse is a log viewer extension for impulse. It allows to analyse logs from pattern or xml based sources.
The logs can be presented along a time-line as well as in tabular form.
The log data can be read from a file, pipe, socket, the output from a process or as combination of multiple inputs.
log4j xml: Version 1.2
Pattern Log: Allows configurations of multiple regular patterns per file.
Sockets: Streams from Tcp socket.
Pipes: Get data from os pipe.
Process: Analyse the output of a process.
Combine multple sources: Combine the above inputs.
Multiple log signal and signal hierarchies: Readers organize the logs in various forms.
Tabular presentation: Select signals in the viewer and get the contents in tabular form (Value Table).
Overview: Get statistical information about a log signal (Signal Table).
This feature is licensed under the EPL. It is build on impulse that is deployed under a different license.
It fetches Java code snippets from few websites based on your search query with the comfort of being within eclipse [Only java editor supported] and displays it as content assist, one press of enter the snippet will be inserted.
Latest version can be downloaded from
This is a guest post from Stephen Connolly,Â CloudBees, Inc.
If you start to push for Continuous Delivery in the context of an open source project, you will often get push-back such as:
âOne of the nice things about Open Source projects is that, well, it’s NOT work, itâs NOT a job.â
â[Open source projects] aren’t factories, churning out releases and code like widgets. We do that enough at our day-jobs.â
These are valid arguments. But they miss some key points.
There is still a transaction going on. It may not be one you can see or account for on a traditional balance sheet… but you can still measure it.
Passion is measured in engagement. When an open source project has lots of passion there are lots of contributors and a vibrant community is built up around it. When an open source project runs out of passion it becomes the tumbleweed of the open source forges: A repository with the last commit five years ago and nobody can checkout and build the code any more.
âIf you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.â – George Bernard Shaw
Passion does not work the same way as money does.
If I spend my passion developing a feature for an open source project and the community grows more passionate because of that feature, then my passion is restored and re-invigorated as part of the community… there is more passion after than before.
If I spend my passion developing a feature for an open source project and it gets dropped on the floor and ignored, however, my passion was wasted.
When you feel passionate for an open source project, then it is your responsibility to help grow the passion of that projectâs community.
There are things we can do to help grow our project’s community and passion, one of those ways is to get releases out more often.
Leaving unreleased features / fixes in your source repository burns the passion of those members of the community who need those features / fixes â and of those who created them. The longer those changes stay unreleased, the more passion you are losing. To put it another way:
Continuous delivery – not just for your day job
Your day job wants continuous delivery because the new features / fixes are like inventory left half finished on the shop floor… it’s consumed resources but still cannot be sold. Itâs overhead.
Your open source project wants continuous delivery because the new features / fixes are like inventory left half finished on the shop floor… it’s consumed community passion rather than growing it.
Now of course these the passion balance sheet works differently than a fiscal one… but there are some things that stay the same:
The decision to run a release through your continuous delivery pipeline has a cost.
A good pipeline is almost completely automated with a few sanity manual checks at the penultimate step. These pipelines are therefore low cost… both in fiscal and in passion accounting terms.
A bad pipeline has lots of manual checks and steps scattered throughout. These pipelines are high cost… and if prone to failure, the cost can grow while you fight to get a release all the way through to the end.
You need to weigh the expected cost of executing your pipeline against the expected net gain you will get by having the new release delivered. Once that measure gives a net gain in your respective accounting metric… then it is time to cut a release.
Every situation is different, so it is no surprise that the balance will play out differently for different projects.
One of the projects I am involved with is the Jenkins CI project. When it started out initially there were releases as often as necessary. There were some occasions where the project got a new release several times during the same day as Kohsuke added a new feature and then people found critical bugs in the new feature. This very fast release cadence was great for getting people engaged with the project… but it came with a cost… people just could not keep up to date with the releases. After a while, Kohsuke settled down to a weekly release cadence. There may not be a release every single week (for example, Kohsuke may not have access to cut a release while travelling abroad) but on average about 48 weeks of the year there is a release.
Is that weekly release schedule right for every project? No, in fact it isn’t even right for everyone in the Jenkins community. If we look at the usage statistics there are a lot of people using the newer versions. There is also a significant group of people in the community who don’t want to live on the bleeding edge but still need bug fixes. The solution is a second, slower train of releases in what is called the Jenkins LTS release line.
The fact that there are regular releases with the Jenkins project has, in my view, helped to grow the community. If somebody finds a bug in Jenkins and provides a patch to fix that bug, there is a very strong possibility that the patch will be applied in the next weekâs release.
â â â â â Excellent: I would contribute again
â â â â â
â â â ââ
â â âââ
â ââââ Poor: I would discourage others from contributing
Part of what makes the weekly releases work for Jenkins is that Kohsuke has heavily automated the release process.
Another project I am involved with is Apache Maven. On the Maven project, our current release process has a lot of manual steps. If we count the steps for releasing Maven itself… I lost count after at least 26 steps. Another issue is that, for legal reasons, the Apache board requires that Apache projects have to vote on releases. So each PMC member casting a vote on releasing has to
â…download the signed source code package, compile it as provided, and test the resulting executable on their own platform, along with also verifying that the package meets the requirements of the ASF policy on releases.â – http://www.apache.org/dev/release.html#approving-a-release
In short, we burn a lot of passion getting a release out the door. The result of that is that it is probably not currently possible for Apache Maven to maintain a release cadence faster than about once every 4-8 weeks… so we are looking into automating as much of the process as we can. It may be that Apache Maven will never have a faster cadence than once every 4-8 weeks… but making it cheaper to release at that cadence can only help grow the community passion.
Continuous delivery is more a collective state of mind than any one, set process or technology. If a project releases at all then it is practicing delivery. To see the benefits of continuous delivery, you just need to up your cadence. Things to look out for are:
Upping your cadence will come with some pain. The point is to identify the causes of the pain and reduce or remove them. If, at a later time, you decide the higher cadence of continuous delivery is not for you, the reduced pain of releasing will still remain as a benefit.
One example is a set of Jenkins jobs that I set up to help cut releases of Apache Maven. They are:
If the downstream jobs are successful, they add a badge to the initial job that kicked them off. When a build has all the badges, then an email is sent to the Maven developers list to notify them that there is something that could be released. This actually removes about 10 of the 26+ steps from the current Maven core release process.
If you want to say you are doing continuous delivery I would suggest you aim for the following levels:
Level 0: A new feature / confirmed fix of a bug committed to source control waits no longer than 3 months before a release with that new feature / fix is available. If you cannot meet this target don’t even try to claim your processes are continuous delivery
Level 1: A new feature / confirmed fix of a bug committed to source control waits no longer than 1 month before a release with that new feature / fix is available.
Level 2: A new feature / confirmed fix of a bug committed to source control waits no longer than 1 week before a release with that new feature / fix is available.
Level 3: A new feature / confirmed fix of a bug committed to source control waits no longer than 1 day before a release with that new feature / fix is available. You are a continuous delivery evangelist, people may hate you. You may need processes to support those in your community who cannot handle such a fast cadence.Summary
Many open source projects have explicitly moved to time-based mostly fixed cadence releases. It may not be right for your project, but you cannot know until you try.
Experimenting with continuous delivery can help your project and may significantly grow your communityâs passionâŠ even if you donât end up using continuous delivery after an experiment!
Stephen Connolly has over 20 years experience in software development. He currently works for CloudBees, Inc as an Elite developer and architect. He is involved in a number of open source projects, includingÂ Jenkins. Stephen was one of the first non-Sun committers to the Jenkins project and developed the weather icons. Stephen lives in Dublin, Ireland – where the weather icons are particularly useful.Â Follow Stephen onÂ TwitterÂ and onÂ his blog.
A leader in research, development and innovation, the CEA, French Alternative Energies and Atomic Energy Commission (Commissariat Ă l'Ă©nergie atomique et aux Ă©nergies alternatives), is active in four main areas: low-carbon energies, information technologies and health technologies, Large Research Instruments, defense and global security. In each of these domains, the CEA relies on a high-level fundamental research and ensures a role of support to the industry.
Within the CEA Technological Research Division, the CEA LIST institute carries out research on intelligent digital systems. Its R&D programs, all with potentially major economic and social implications, focus on advanced manufacturing (robotics, virtual & augmented reality, non destructive testing, vision), embedded systems (computing architectures, software and systems engineering, security & safety), and ambient intelligence (sensors, instrumentation & metrology, communication & sensory interfaces, data processing & multimedia). By developing cutting-edge technological research with applications in the industrial markets of transports, defense and security, manufacturing, energy and health, the CEA LIST helps its partners to enhance their industrial competitiveness thanks to innovation and technology transfer (www-list.cea.fr/en).
Safety Architect is a tool achieving risk analysis of complex systems using functional or physical architectures from usual modeling tools (for example SysML or UML).
It provides support to the implementation of FMEA and automatically deducts the FTA corresponding to the identified feared events. Mains functionalities of the tool: import models, locally analyse the risk, spread to feared events, generate fault trees, export enriched models.
Main advantages of the approach: compliance with all engineering loops, automation, fats detection of critical parts, easy handling of corrections/evolutions.