Professional Software Consulting

• Home
• Philosophy
  • Introduction
  • Delivery
  • Maintenance
  • Teamwork
  • Expectations
  • Automation
  • Conclusion
• Background
  • Introduction
  • ASDC
  • Young Systems
  • Bennett
  • Premiere
  • AT & T
  • @IS
• Areas of Focus
  • Introduction
  • PHP
    • Sample
  • CakePHP
    • Sample
  • HTML / CSS
  • Apache/MySQL
  • FreeBSD/CentOS
  • RealBasic
    • Sample
  • AWS Cloud
  • C / C++
    • Sample
  • Shell Scripts
    • Sample
• Sample Projects
  • AWS S3
    • s3_bucketContent.php
    • s3_bucketCreate.php
    • s3_bucketDestroy.php
    • s3_bucketList.php
    • s3_fileDelete.php
    • s3_fileDownload.php
    • s3_fileInfo.php
    • s3_fileUpload.php
  • DB Backups
    • backupDb.ksh
    • backupTable.ksh
    • restore.ksh
    • getSchema.ksh
    • showUsers.ksh
    • showDatabases.ksh
  • Get Field
    • getField()
    • getFieldMB()
    • getLocationMB()
    • countFieldsMB()
    • utl_memStr()
    • Conventions
  • Digits to Words
  • Time Logs
    • Listing
    • Import
    • Export
• Contact

Digits To Words RealBasic GUI

The linguistic run-time engine I developed for @International Services has a variety of linguistic capabilities, including dealing with numbers. For example, given the input "12", it would return "twelve" if the language was English, "douze" if the language was French, and so on. Linguistics is a messy business from a programming perspective; for example, in French, the number "92" is "quatre-vingt douze," literally "eight twenties twelve" - i.e., (8 x 20) + 12. These are the sorts of things that make localization of software very time-consuming, and why the run-time engine was developed: to eliminate this logic from the developer's purview.

To ensure that the correct results were returned from the run-time engine, I wrote some reports in C. The one I'll focus on here is the one concerning numbers, although there were others regarding dates, times, names, locations, and fixed data, to name a few. The goal was to create a report that a linguist could look at and say "yes that's good" or "no, what you have for 1,304 isn't right." So I did what seems perfectly natural to a programmer: I wrote a program that used a loop to feed parameters to the run-time engine, thereby exercising every possible scenario.

Exercise Report Number Selection Screen

Well, that didn't go over well with the linguists. They didn't care to look at a report that contained ten thousand entries (for reports that went from 0 to 9999), each of the entries slightly different. Add to the fact that they weren't comfortable with standard text files; they needed MS-Word format. Right from the start, I was creating 40 MB text documents, which, it turns out, MS-Word doesn't handle very well when it tries to open them and convert them to Word format.

It was an eye-opening experience. For me, a document with a million lines in it is just that. To the linguists, a document with a million lines is an unusable file that locks up their computer. So I modified the program (I called it an exercise program, because it exercised the run-time engine) to get its list of parameters from a configuration file instead of using a loop, thereby reducing the number of test cases dramatically. Instead of testing every number from 0 to 9999, now the base numbers (0-20, 100, 1000) and numbers known to be tricky (80, 90, 301, etc.) could be checked. Granted, this wasn't a true test of the capabilities of the run-time engine, but it was a sufficient quality control from a statistical perspective to enable the linguists to confidently say that things were proper.

I had the same issue with the configuration file as I did with the million line text file: it was too technical for the linguists. For me, a comma-delimited text file is the essense of simplicity, but getting someone who lives in a world where MS-Word is the only editor they know, training them how to create a configuration file wasn't workable. And so I had the idea for this program.

Exercise Report Output Screen

The basic architecture is that the back-end program still does the exercising, and still uses a configuration file for input. However, instead of requiring the user to manually create the configuration file, this program will collect the users decisions, generate the configuration file, call the C program, delete the configuration file, and display the report output in a useful manner.

The original GUI program was never used in production, so I modified it and trimmed it down for this example scenario. Because the run-time engine and its linguistic algorithms are proprietary, I have replaced them with a simple C program that converts numbers to words: 556 is converted to Five Hundred Fifty-Six. The modified version of this I have named Digits To Words, indicating its very specific use. The original GUI was developed as a generic front-end selection program for a wide variety of back-end programs, each of which could generate multiple output files that the user might need to view.

Even with the scaling back of functionality, the program is still quite complex, and there is no manual. Therefore, I have recorded tutorials to demonstrate how this program is used. I don't expect anyone would actually be able to use this program, but you are free to try, or you can even contact me if you would like it modified for use in your organization. The purpose of this program is to showcase one of the interfaces I designed for a desktop application.

Contact Us

Something wrong with this page or this site? Let the webmaster know by clicking HERE

This website designed, implemented, and maintained by Corey Dulecki © 2009-2012, Corey's Consulting LLC