OSS in a Software Development Firm
I have been using Linux as my home operating system of choice for several years. I have used various open-source projects to do practically everything involved in hosting Web sites and databases and serving up e-mail. All of this has been done as a hobby, and I often longed for the day when I would be able to bring open source into the office.
I work for a software development company as a programmer/analyst, developing administrative software for higher education. Our original software was written in COBOL to be run on an HP e3000 using the MPE operating system. A few years back we recognized that we needed to bring our software into the 21st century, so we chose Delphi to migrate our legacy applications to the Windows platform.
Before we were able to migrate our application suite, HP announced the demise of the HP e3000 and the MPE operating system. This left us in a bit of a predicament. At the same time, it presented a great opportunity for the company to take a step back and evaluate where we were going and how exactly we were planning on getting there. We listened to feedback from our customers, talked to our technical gurus and decided to stop the conversion to the Windows platform and investigate other options. Java was mentioned, and we began developing a proof of concept.
During the development of the proof of concept is when the first open-source products started creeping under the door. We started using Eclipse as the IDE. Eclipse was quite popular in the Java world and it was being developed actively. In addition, the support of the user groups and, of course, Google was tremendous. Although many of the developers chose to use Eclipse, others tried NetBeans, EditPlus and various other development environments.
Also during the proof of concept, a product by the name of PerCOBOL was mentioned. PerCOBOL is a product from LegacyJ to convert COBOL to Java. The PerCOBOL IDE was based on Eclipse. By this time we had finished the Java proof of concept, and the response from the higher-ups was positive. We now had to develop another proof of concept, however, using the PerCOBOL product to convert one of our more complicated tasks.
While developing the PerCOBOL proof of concept, it became apparent that we needed to standardize our development tools. One of the major indicators of this was the use of CVS. All of the various IDEs being used at the office handled CVS integration differently. Training the developers on the use of CVS was cumbersome at best. With the decision to use PerCOBOL, we chose to standardize on Eclipse.
I snuck CVS in above because it was the major factor in our decision to standardize on an IDE. However, it was the wide support for CVS of all the major IDEs that allowed us to choose other open-source projects.
Aiming to be as platform independent as possible, we chose to support any J2EE-compliant application server. This decision opened the doors for JBoss and Tomcat. The fact that Jboss recently received the great funding it did gave some validity to our decision to support it. Tomcat was a no-brainer for development reasons: it is fast and lightweight and has a small footprint.
Another no-brainer was Ant. Ant allowed us to streamline the process of compiling and deploying the applications being developed. This also increased the production of code because all of the developers need not know the particulars of deploying on the various application servers. We developed build files that could be used with the each of the application servers. We just as easily could have created one build file with various build targets corresponding to the application servers, but we thought it would be easier to understand and maintain several files directly relating to an application server.
With the proof of concept for both the Java project and the PerCOBOL piece complete and receiving rave reviews, we really began the process of developing our next generation software. Or so we thought.
Our development practices were not the most organized and were not even close to being standardized prior to our Java conversion. The developer wrote the code, tested the functionality of the code and placed the code into production, nothing more to it. Each developer had a specific area of expertise in the huge system we developed. Some worked on a financial aid piece, other worked on the housing piece and still others worked on the registration piece, to name only a few.
We now were faced with an opportunity to cross-train ourselves. We decided to convert the system one module at a time, starting with financial aid. The COBOL programs obviously didn't fit into one Java class. It was at this time that I heard about Struts. Struts is another open-source project that allows for the separation of the business logic from the database and presentation layers. It's more formally known as MVC, or Model/Viewer/Controller.
Around the time that Struts was introduced, after some training presented by Marty Hall, I was presented with an exciting opportunity. Everyone in the office had been listening to me preach about the greatness of Linux and the numerous distributions I use. But now, developing with Java, I could start using Linux as my development operating system. In fact, doing so was encouraged for testing purposes to allow us to be platform independent.
We soon discovered that training our current developers was not going to cut it. Even though we had very talented developers, we needed to hire an expert Java developer to be used shamelessly as a resource by our current team. The new developer was not only a Java expert but also an open-source advocate and a proponent of Linux. Presented with his new laptop he proceeded to wipe it clean, put on a fresh install of Fedora and away he went.
Using Ant on a developer's machine worked well, but in our testing environment, it was cumbersome and time-consuming to grab all the updates from CVS, build each piece involved, notify the developer of any given piece that failed and, finally, deploy on the testing application server. Enter CruiseControl. CruiseControl automates the integration of changes made in CVS as well as the build portion. CruiseControl has saved me, personally, hours of work. The CruiseControl system notifies the developer of any piece of code they have checked in that fails to compile, gives a report of all the pieces updated and sends out an e-mail to all the developers notifying them that a new build is available. With CruiseControl we quickly can locate a problem with new code that has been introduced and either roll back the previously working code or apply patches to the buggy code. Having set our CruiseControl installation to check for updates in CVS every five minutes, we find small problems before they became large problems.
Another feature of CruiseControl is the ability to run JUnit tests and display the results. As I mentioned before, our software development processes up to this point were informal. With CruiseControl and JUnit we could write test cases and have them placed directly into our continuous integration process. So, not only did we have our changes available with any compilation problems found immediately, we also were able to unit-test our code and quickly remedy problems such as database leaks.
With our development processes down and unit-tested code available, it became time to test the functionality of the applications being produced. In the beginning we combined the project management and the testing into one Excel spreadsheet. I am certain you can understand the kind of nightmares this caused. At that time I and another developer gave the suggestion that I install Bugzilla on one of the older desktops. Bugzilla is not necessarily the most attractive bug-tracking software, but it certainly beats using a spreadsheet, freeing us from the hell of someone going to lunch and locking their desktop with the spreadsheet open. Bugzilla has more than enough features for our needs.
The latest introduction of open-source software has been phpCollab. As I previously mentioned, our project management consisted of one part spreadsheet and several parts frustrated developers. phpCollab has allowed us to divide our applications into smaller modules. For example, for those applications requiring user input, we divide the project into three to correspond to the specific piece in MVC standard.
Open-source software has been an aide to our software development firm and as I sit here, writing this article in OpenOffice.org, I can see the use of OSS only growing. When I discussed writing this article with our president, he was fairly surprised by the amount of open-source software in our company. He knew the names of the projects but was not aware that they were open-source. We even joked about putting Linux on his laptop. Some colleagues have expressed interest in installing Linux on their development machines in a dual-boot scenario. Other colleagues use OSS projects on their Windows machines to test user interfaces, validate XML and test office compatibility. We have managed to bring numerous OSS projects into everyone's vocabulary and have proven the reliability and usefulness of OSS in the corporate environment.
Daniel McCarthy is a programmer/analyst for the Computing Options Company.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide