I am a software developer with a broad background and lots of experience with various technologies. I am someone who can quickly master new technologies. I usually do things that have never been done before, where my skills and background can bring new ideas to life in software. Nothing I run into surprises me, and I am able to make technology work. These days, I mainly work in web development and Android.
E-mail: scott@skwc.com
Gmail: scott1329m@gmail.com
Bachelor of Science degree in Computer Science • 1994
UNCA is unique as a public university which provides a liberal arts education to all students. At UNCA, my primary area of research interest was with studying the transmission and processing of e-mail. My senior project was the implementation and production use of a Majordomo-like mailing list automation package written in Perl.
Software Developer • 2011 - Present
After working part-time for SermonAudio.com almost two years, I joined full-time in November 2013. I work on enhancing and maintaining the SermonAudio Android app, Android apps for individual broadcasters, the back-end API endpoints, and other areas.
Senior Developer • August 1994 - October 2013
I worked at SoftBase for almost twenty years, in a variety of different roles including software development, system administration, building the company's web presence and customer portal, creating an automated product release system, maintaining the software build system, and software testing. I was involved with almost every aspect of the company's technical operations. The founder sold the company in 2011 to a private-equity firm, and the new management terminated my employment in October 2013.
Software Developer • 1998 - 2005
I worked in a part-time capacity with SKWC for a number of years, helping them with software development projects which were beyond their scope as web designers. By the mid-2000s, they were using the turnkey Miva package and weren't doing custom programming, so my direct involvement ended.
Software Developer • 1993 - 1994
Computer Answers was a VAR for the Medical Manager package, and I was hired to write reports while I was in college. At the time, MM's built-in reporting utility was primitive (basically a screen of row-column fields which had to be in a rigid order), so I wrote a program in C which allowed me to draw reports (similar to using Perl's format strings) and directly modify the underlying Btrieve files rather than using the primitive report utility.
I have done a wide variety of projects using many different programming languages, platforms, and tools. Too many to make a comprehensive list. These days I primarily work with back-end database code, particularly creating REST-ful API endpoints. I also write apps for Android.
Here is the SermonAudio Android app that I maintain and develop.
I also maintain and develop apps for individual broadcasters, too many to list, but here is a representative broadcaster app.
A port of the SermonAudio Android app for the Amazon Kindle Fire is also available.
For now, this is the original WORKOUT sample. When I get time, I want to redo it to use the newer Gradle build tool and maybe host the project at GitHub.
WORKOUT is intended to be a large-scale example of my work. I put this example together to have a large, cross-platform project that I designed, specified, and implemented. I wanted an example with full source code, since software developers are judged mainly by their ability to produce functional code. The code is not finished (since I only work on it in my spare time).
WORKOUT is a test program designed to do a lot of SQL. The original version (implemented in C) came about because I needed to do load testing on an SQL monitoring tool, and I wrote a small program that did a lot of SQL for the tool to monitor. The code has been useful in many other scenarios, such as generating specific program runs to populate the SQL monitor's database with data I could run reports against.
The core of WORKOUT consists of a small set of database tables with referential integrity, and a group of commands to do SQL with those tables. WORKOUT has a fairly simple set of commands, with the intention of being embedded in a scripting language for control structures.
The parser is a sample of low-level C code I wrote, which I found on an old backup. I wrote this to be called by another program which wanted a parsed-out representation of a COBOL 01 level so it could generate test records. Anyhow, parsing COBOL is not simple, even limited to 01 levels. The OCCURS was a challenge, since they can be nested inside each other. The LBR/RBR defines relate to bugs with how terminal-emulator software handled square brackets, a perenninal issue. My parser got retired once IBM essentially included the LE COBOL compiler with z/OS, at which time the COBOL compiler itself was used to get the necessary information. I've left the code as-is, other than reformatting it. (Being moved from platform to platform over the years left the code in a state of bad formatting.) It's real-world code meant to solve a problem within time constraints.
Here are a few samples of technical writing that I have done.
Until January 2013, I had never heard of a Fizz-Buzz test program. From what I understand, this test is used to determine a programmer's ability to write a simple program similar to Hello, World but with some rudimentary logic for decision making. The Fizz-Buzz test seems to have been popularized by this Coding Horror article. I am amazed that so many programmers are unable to complete this simple test.
Jython is awesome. Let me tell you why, and demonstrate Jython in action.
Jython preserves your sanity. Right now, there are too many scripting languages. Each one is similar, but different. (To see what I mean, try making a list of ways to get the length of a string in various scripting languages.) I would rather concentrate on the problem I am trying to solve than try to remember the syntax of programming languages. Because Python is available on the command line, and Jython is available to Java programs, I need only to remember one syntax. To me, that is the most compelling reason to use Jython and Python.
Jython encourages good design. If you use Jython, you will naturally construct modular Java code so your objects can be used in Jython scripts. The key to good design is creating an object model that contains the the functionality that is unique to your program. The object model can be manipulated by web pages, graphical user interfaces, or Jython scripts.
A command-line utility program can be designed around MVC as easily as a web page. Your Java objects are the model (M), and Jython scripting gives you the controller (C) for free. While a utility may not have a user interface, per se, the input and output of the utility is a view (V) of the data which the utility processes.
Jython is great for testing. Tests written in Jython can be constructed and run interactively without having to rebuild Java code. (Of course, you have to compile your Java object model if it changes.)
Creating tests is critical for developing solid code. I construct software by creating the smallest functionally complete Java classes, and then I test my classes with scripts to make sure they work. I find the key to managing complexity is to start with small classes, and then use them to build complex applications, trusting that each class has been tested and does what it is supposed to do. Jython makes this process easy.
Jython is great for scripting. One time I embedded Jython in a project and had the graphical user interface generate Jython scripts. I wanted to let users run the same scenarios without having to recreate them, and allow power users to modify the generated scripts. So my stakeholders suddenly wanted a non-interactive mode in addition to the GUI, and asked me how long it would take to add one. I surprised them by saying I already had one available. Adding Jython as a scripting language gives any application the flexibility to work in ways never imagined during the original design phase.
That is enough for starters. Let's use Jython. First, of course, you will have to install Jython. You can download the distribution from jython.org. Then add jython.jar to your Java CLASSPATH. The specific steps for your build environment will be different, but since I use ant I will show how to set up a run target for a Jython script.
First add Jython to your classpath to your ant build file:
<path id="classpath">
<fileset dir="${jython.dir}" includes="jython.jar"/>
...etc...
</path>
Where, obviously, the variable jython.dir is set to the location of where you installed Jython.
Then create a target to run the Jython interpreter with a script file (which we will create in a moment) as the argument:
<target name="jytest">
<java classpathref="classpath"
classname="org.python.util.jython"
fork="true">
<arg line="scripts/jytest.py" />
</java>
</target>
Let's make a Java class which we can call from Jython:
package net.scottmcmahan.jythonstuff;
import java.util.Random;
/** This test object is designed to be called from Jython. */
public class TestModel {
/** Random number generator. */
private Random random = new Random();
/** Integer variable to store random number. */
private int rnd = 0;
/** Empty constructor for bean. */
public TestModel() {
// do-nothing ctor
}
/** Generate the next random integer. */
public void setRnd() {
rnd = random.nextInt();
}
/** Return the current random integer. */
public int getRnd() {
return rnd;
}
}
This sample TestModel class is about as minimal and uninteresting as a Java class can be. The intent is to make a trivial class that is easy to understand and which does not have any mistakes. Classes like this are what I use as scaffolding while constructing software. If this trivial class works, I can create complicated, domain-specific classes later.
The TestModel class is designed to look like a Java bean, since testing beans with Jython is something I often do. Jython scripts are ideal for testing all of a bean's code paths. For me, I prefer to use POJOs (plain old Java objects) because testing is much easier if the bean is self-contained. Persistence and other stuff can be factored out into XML files.
And also note that I am not showing my build target for TestModel, since that is boring ant XML.
Let's call the Java class from Jython:
from net.scottmcmahan.jythonstuff import TestModel
rndthing = TestModel()
for i in xrange(1, 100):
rndthing.setRnd()
print i, ": ", rndthing.getRnd()
print "Done!"
Notice here that we are using a Python-style import statement, but using the usual Java package name. Jython makes Java objects look just like Python objects. the Jython interpreter itself is embedded in a Java program. I normally use Jython in this way. With Jython, your program gets a complete scripting language for free which can manipulate your object model. This design allows software to be extended in ways never anticipated during the original design, and most successful software eventually needs to be used and extended in ways the original designers never imagined.
Does Jython have any drawbacks? Right now, Python 3 is an issue confronting all Python and Jython developers. Since Python 3 breaks compatibility with Python 2, developers are in a state of flux as they plan the transition. Unfortunately, Jython does not support Python 3 at this time. (I have not begun using Python 3 because I use Jython as much as I do Python.)
I hope this brief introduction to Jython has stimulated interest in the Jython language, and in approaches good software design.
Technical WritingThe default behavior of GNU Emacs 24 under X11 has changed to paste (yank) from the clipboard rather than the primary selection. Almost all of the time, this is the behavior most users will find most convenient. All modern X11 applications on today's Linux distributions, such as the Fedora distribution which I use for software development, support the clipboard.
Some older applications which run under X11, however, do not use the clipboard. When a selection is highlighted in these applications, the selection is available only as the primary selection.
In my case, I use the mainframe terminal emulator x3270 extensively, and often need to paste parts of a terminal screen into an Emacs buffer. I often need to record error messages, output from commands, and JCL snippets in an Emacs buffer. Initially, the behavioral change in Emacs 24 was distressing, until I discovered a switch controlled from which source Emacs would yank.
Writing an Emacs LISP function to yank from the primary selection is simple. The switch can be temporarily set using let, so the change is active only within the function. The clipboard can be used most of the time as the source for yank, but a special function can be defined to override the source and use the primary selection.
In the .emacs startup file, first define a new function with defun:
(defun primary-yank (&optional arg)
"Yank from the primary selection instead of clipboard in X11."
(interactive "*P")
(let ((x-select-enable-clipboard t)
(x-select-enable-primary t))
(yank arg)))
Then bind the new function to a key with define-key:
(define-key global-map (kbd "C-S-y") 'primary-yank)
I chose to bind the function to Control-Shift-y, which is similar to the usual Control-y yank command in Emacs, which makes the new command easy to remember.
To begin using this new facility immediately, highlight the defun and define-key commands, and use M-x eval-region. (Doing this is a good way to syntax check the LISP code.) Because these definitions are in the startup file, they will be available every time that Emacs is started.
Additional notes: I do not have any problems pasting what I highlight in Emacs into the x3270 window, so I do not have a corresponding command to copy text to the primary selection.
Also, other X11 applications which use the clipboard usually can't paste from the primary selection. Emacs is a good intermediary in this situation, since the primary selection can be yanked into a temporary Emacs buffer, and then copied to the clipboard with set-mark-command (typically Control-space) and kill-ring-save (typically M-w). This is how I would include x3270 output in, say, an e-mail message.
Technical Writing