Archive for the ‘Software Development’ Category

Reimagining the Implementation of TeX (and the Luxury of Modern Programming Methods)

January 24, 2015

Glenn Vanderburg, Engineering Director for Architecture at LivingSocial (@glvhttp://vanderburg.org), has a personal project underway to implement TeX’s algorithms in the Clojure programming language. His work was recently described in an article published on InfoQ. Glenn also presented his work at the Clojure/conj conference last year in 2014, his excellent talk is posted on YouTube.

The InfoQ article and YouTube presentation provide a high-level summary of the state of technology and software development capabilities available in the early 1980’s which influenced (really restricted and confined) the creativity and results of a programmer at the time. By implementing TeX in Clojure, a functional programming language with capabilities for multi-threaded processing, Glenn applies modern methods, and makes several now-and-then observations along the way, to the implementation of a large-scale programming masterwork created by Professor Knuth more than 30 years ago.

“The ways we can program today are luxuries made possible by decades of small advances.”

Glenn also describes the potential benefits for reuse that would be available with a modern implementation giving several examples of how Web publishing and eBook readers might take advantage of using TeX’s excellent typesetting algorithms creating beautiful page layouts and more natural reading experiences.

References

Agile is not fast, it’s frequent.

July 23, 2010

The principles (and the intention) of Agile Development are often confused with the word agile which people interpret to mean fast (in the sense of being quick and doing things other than in a thorough way). Of course that is an incorrect interpretation. Agile methods are not intended to be fast, if anything Agile teaches us to be iterative, repetitive, and to break down larger problems into smaller pieces that can be more easily understood, completed with higher quality, and delivered on an expected schedule. From that perspective, Agile teaches us to be Frequent in the way we approach our work.

So Frequent may in fact be another principle of Agile Development. As a principle it doesn’t only have to apply to software development work. We can apply Frequent methods to other disciplines too.

Playing iTunes .m4a Files on a Squeezebox2

May 30, 2010

I encountered a problem playing iTunes .m4a files on Squeezebox2 devices. It was interesting that from the same Squeezebox Server the files played fine on a Squeezebox3, but when attempting to play on a Squeezebox2 an error appeared on the Squeezebox Server’s Web interface, “Problem: Can’t open file for: <file>.m4a”. Other files, such as .mp3 filetypes, played fine.

I validated that the .m4a file existed in the music directory and there were no permission issues. To troubleshoot the problem I activated debug logging for os.files, os.paths, player.source, player.streaming, and scan.scanner and then restarted the Squeezebox Server; the logging messages were recorded in the server.log file. The problem was straightforward:

Slim::Player::TranscodingHelper::checkBin (242)   Found command: [faad] -q -w -f 1 $FILE$ | [lame] –silent -q $QUALITY$ $BITRATE$ – –
Slim::Utils::Misc::findbin (100) Looking for executable: [lame]
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/share/squeezeboxserver/Bin/i386-linux/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/share/squeezeboxserver/Bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/kerberos/bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/local/bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/local/bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/libexec/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/sbin/lame
Slim::Utils::Misc::findbin (130) Didn’t find binary for lame
Slim::Player::TranscodingHelper::checkBin (265)    couldn’t find binary for: lame
Slim::Player::TranscodingHelper::getConvertCommand2 (421) Error: Didn’t find any command matches for type: mp4

So it seems that lame is needed to stream music data from an m4a file to a Squeezebox2 device. (But lame is not used when streaming music data to a Squeezebox3. That’s interesting too.)

I needed lame for Redhat Linux, it’s an open source project maintained on SourceForge here. After downloading the source, run a ./configure, make, and make install. And that fixed the problem.

Move Messages to Folders with Outlook VBA

March 27, 2010

Let’s say your email management approach is to save important messages to a folder other than your Outlook Inbox. You might save messages from outside vendors to a folder named “Vendor Documents” or messages related to corporate policy to a “Policies” folder. Here’s an Outlook VBA macro that helps to file those messages from your Inbox in a single click:

Sub MoveToFolder(folderName)

 mailboxNameString = "Mailbox - Firstname Lastname"

 Dim olApp As New Outlook.Application
 Dim olNameSpace As Outlook.NameSpace
 Dim olCurrExplorer As Outlook.Explorer
 Dim olCurrSelection As Outlook.Selection

 Dim olDestFolder As Outlook.MAPIFolder
 Dim olCurrMailItem As MailItem
 Dim m As Integer

 Set olNameSpace = olApp.GetNamespace("MAPI")
 Set olCurrExplorer = olApp.ActiveExplorer
 Set olCurrSelection = olCurrExplorer.Selection

 Set olDestFolder = olNameSpace.Folders(mailboxNameString).Folders(folderName)

 For m = 1 To  olCurrSelection.Count
    Set olCurrMailItem = olCurrSelection.Item(m)
    Debug.Print "[" & Date & " " & Time & "] moving #" & m & _
                ": folder = " & folderName & _
                "; subject = " & olCurrMailItem.Subject & "..."
    olCurrMailItem.Move olDestFolder
 Next m

End Sub

Some customizations are necessary to make this all work for your email system. First, copy-and-paste the program to the Visual Basic Editor in Outlook (which you can open with Alt-F11). You’ll need to create a new VB Module (use the Insert->Module menu choice) to hold the macro if you don’t already have custom Outlook macros defined.

Second, the text highlighted in the blue bold font needs to be edited for the name of your Exchange mailbox; you can usually find the name of your mailbox on the left side of the Outlook window at the top, it starts with “Mailbox” like in the example above.

Third, you’ll need to add other VBA macros which call the MoveToFolder() macro with the correct folder name passed as  a parameter. For example, we might create two additional macros one each for the Vendor Documents and the Policies folders; the macro for Vendor Documents might be called MTV() and the Policies folder macro MTP():

Sub MTV()
 MoveToFolder ("Vendor Documents")
End Sub

Sub MTP()
 MoveToFolder ("Policies")
End Sub

(Note, the destination folders should already exist in your Outlook folder list.)

The last step is to assign the macros to Outlook toolbar buttons so you can move the selected messages in your Inbox to the appropriate folders with a click. If you’re managing multiple destination folders, and you created multiple macros (one for each folder), you can also create a new toolbar to organize all your MoveToFolder() macros. Here’s a Microsoft Knowledge Base article that describes how to assign Outlook VBA macros to toolbar buttons: How to Assign a Macro to a Toolbar Button.

The MoveToFolder() macro will work on a single selected message, or a group of messages selected in a sequential range (with a Shift-Click), or a non-sequential range (with Ctrl-Clicks). Also, an activity message will be written to the VBA Editor’s Immediate Window (which is opened with Ctrl-G) so you can go-back and view MoveToFolder() activity. A total win for email convenience, give it a try.

A Creative Look at Pair Programming

March 15, 2009

I follow John Mayer the singer and songwriter on Twitter. Besides being a fan of his music, on Twitter Mayer (@johncmayer) is creative, funny, and he provides some transparency into his musical projects which are interesting. Mayer also writes the Battle Studies Mid-Action Report blog where he uploads videos and photos that are referenced in his Twitter postings.

A few days ago Mayer made a statement on Twitter, in @reply to a question from a follower, which I found intriguing. He replied:

I still write in front of a mirror.

You can view the full post, which also includes the original question here.

I was struck by the statement since, for me, it is completely counterintuitive to what you would expect the creative writing process to be. Writing is a very intellectually internal process. You typically hear of writers having a quiet workplace in the woods, or in an attic, separated from people and activity in order to create an environment to be alone with yourself and your thoughts. The process of creating words from thoughts, emotions, or feelings (whatever they may be) is usually considered to be a very individual process requiring deep introspection and contemplation achieved by developing an ability to see yourself from within.

So, I would think that writing in front of a mirror is opposite to being introspective. To me it seems as close as you can get to introducing a second person into the process without having someone else in the room. The mirror then is a tool to externalize the creative process, to forcefully move creativity outside of yourself, or possibly an attempt to see yourself as someone else in order to develop a collaborative process when there is only one person involved. That scenario is so contradictory to the way that I think about creative writing, it is so out-of-the-box and unexpected, that I frankly find it brilliant.

There is also a creative process that occurs in software development and programming. I’ve always related to the description that Fred Brooks gives of the software development process in his book The Mythical Man-Month. Brooks, referring to the book The Mind of the Maker by Dorothy Sayers who identifies creativity with three stages, the idea, the implementation, and the interaction, says:

A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author. It is realized in time and space, by pen and ink, and paper, or by wire, silicon, and ferrite. The creation is complete when someone reads the book, uses the computer, or runs the program, thereby interacting with the mind of the maker.

Brooks then goes on to describe computer programming using the short phrase:

The programmer builds from pure thought-stuff.

The statement describes a computer program being built (or developed, created, written) from the thoughts (or ideas, concepts) of a single individual.

Several years ago, and together with a close colleague, we implemented the eXtreme Programming (XP) software development methodology at aluminium.com. The methodology was popularized by its author, Kent Beck, in the book eXtreme Programming Explained: Embrace Change. The premise behind XP is to take all the things that people generally consider to be good for creating quality software and to do those things to the extreme. For example, everyone generally considers testing to be directly related to quality; the more you can test a program the fewer errors it is likely to have. So in XP testing is done to the extreme by writing the tests for a program before the program is actually written. The “test first” approach, or sometimes called “test driven development,” can be viewed as being radical by someone who is used to working in a more traditional software development methodology where tests are written after the program is created.

Another principle of XP usually considered to be radical is “pair programming.” When pair programming two people sit together to write a program. In XP Explained Beck describes pair programming as follows:

Pair programming is a dialog between two people trying to simultaneously program (and analyze and design and test) and understand together how to program better. It is a conversation at many levels, assisted by and focused on a computer.

When I was first learning about XP I clearly remember having a deep and surprising reaction to the concept of pair programming: How can something as personal as writing software, transcribing my thoughts, my concepts, and my ideas, my pure thought-stuff, be shared with someone else simultaneously? How is it possible that writing a program, which can be an intimately creative process for an individual, can be accomplished by working with someone else? For programmers who haven’t done it before, the concept of pair programming can be radical, out-of-the-box, and counterintuitive, which was exactly my initial reaction to Mayer’s statement about writing in front of a mirror.

Pair programming introduces a second party into the creative process. It’s an activity that forces you to communicate, to share and verbalize your thoughts and ideas, and to collaborate in a completely different way. When pair programming, someone else, a second person, is there with you while you’re going through the activity of creative expression. Both people experience intellectual and personal benefits as a result of that collaboration and there are significant benefits to the overall quality of the product, the computer program or the software application, they produce together.

If writing in front of a mirror, as Mayer does, has a similar effect to introducing a second person into the creative process, then the mirror becomes the tool that enables Mayer to “pair program” with himself. Mayer is generally considered to be a gifted artist and it would seem that he is leveraging the pairing concept to make himself, and his art (his music), better.

Knowing that Mayer uses a mirror in the writing process makes the pair programming concept appear less radical. Perhaps when we work alone we limit the expression of our creativity to our own individual experiences. Perhaps collaboration with another person, the second person effect, is required to really broaden the possibilities of our own individual creativity. And perhaps when we pair program to create computer software the second person is really the mirror.