Amount of profanity in git commit messages per programming language

I spotted this blog page from a list I subscribe to the other day, those sensitive to profanity should look away now others can see the stats here...

Amount of profanity in git commit messages per programming language

Given that C# and Java are similar in many ways and are often used for the same things it is amusing that they both induce exactly equal levels of profanity in their developer communities.

The figures for different languages are significantly different (with C++ being the most sweary language to work in it seems) so I feel like this data is trying to tell us something.

And who are the nicest people to program with? PHP developers it seems (with Python not far behind).


Visual C++ Redistributable Licensing: I'm just not seeing it

As part of putting together the latest builds of the QTI Migration tool I have had to repackage the updated tool into a new installer.

The migration tool is written in python and uses the py2exe tool to convert the Python script into a set of binaries that can be distributed to other Windows systems as a ready-to-run application without requiring Python (and various other packages, including wxPython: used for the GUI) to be installed first.

The output of py2exe is a folder containing the executable and all its supporting files ready to package up.  Originally this was all done by Pierre, my co-chair of the QTI working group.  I'm happy to report that updating the installation scripts went fine and I've been able to create a new Windows Installer using InnoSetup.

There is a recipe for using py2exe with wxPython published on pythonlibrary.org called "A py2exe tutorial".  However, I did have one problem with this recipe - I too had trouble with MSVCP90.dll but I needed the help of stackoverflow (thread: py2exe fails to generate an executable) to actually get the build going. Once done, I was concerned with the warning messages about the need to have a license to redistribute the DLL in my installer.  I found another blog post on distributing python apps for the windows platform which spelt out my options.  As I don't personally own a Visual Studio license it seems like I need to use the redistributable package which can be downloaded from Microsoft.

Unfortunately, when I download this file the license in the resulting installer does not appear compatible with packaging it into my installer for distribution with my tool.

Several people on the net seem to suggest that the DLL is off-limits but the 'redistributable' does exactly what it says on the tin.  Indeed, if you don't run the package it isn't clear what license you signed up to by downloading it but once you run the installer it clearly says that "You may make one backup copy of the software.  You may use it only to reinstall the software." and that you may not "publish the software for others to copy".  So I've played safe and am crossing my fingers that my users will have already installed these wretched DLLs on their system before they try the migration tool.

Previous versions of the migration tool installer were built by Pierre and he did have a Visual Studio license so could do the build and redistribute the software.

My experience and the time I wasted trying to find an answer to this question eventually turned up one discussion thread in which the complex issues that the team within Microsoft faces are exposed: see VC++ 2005 redistributable.  Although this thread is a little old now the replies from Nikola Dudar are helpful in providing deeper insight into the issue and the conflict that having a chargeable development platform creates.  On one hand Microsoft would like it to be easy for people to create software for their platform but they also have a paid-for development tool chain in Visual Studio.  The existence of Visual Studio Express edition (a free lightweight development environment) appears to be suitable only for personal hobbyists and not for anyone wanting to build software for redistribution.  There are lots of replies to the above article but if you search down for "release team" there is a reply that emphasises the difficulty of finding the balance between paid and express editions and a link to a blog post relating to the creation of the free to download redistributable packages.  I like these types of forum discussions as they show that even 'evil empires' like Microsoft are full of ordinary people just trying to do their jobs.


Getting ready for HTML5: Accessibility in QTI, img and alt text

Last night I was playing around with David McKain and co's excellent MathAssessEngine site.

I tripped over an interesting error with some test data produced by the QTI migration tool.  I was converting a basic MCQ with four images used as the choices.  On loading my content package into MathAssessEngine I got four errors like this:

Error: Required attribute is not defined: alt

I went off in search of a bug in my XML generation code from the migration tool but discovered that what MathAssessEngine is really complaining about is an empty string being used as the alt text for an image.  Actually, empty alt text is allowed by the specification (my QTI v2 files validate) and it is also allowed by HTML4 so I think it is more a bug in the MathAssessEngine, but it did force me to go and check current thinking on this issue because it is so important for accessibility.

According to the current editor's draft of HTML5 the alt attribute "must be specified and its value must not be empty" so it looks like QTI-based tools will need to address this issue in the near future.

The problem with the QTI migration tool is that it only has old scrappy content to work with.  There isn't even the facility to put an alt attribute on QTI version 1.x's matimage which, incidentally, is another reason why the community should be moving to QTI version 2.

So is there any way to set the alt text automatically when migrating version 1 content?

One possibility is to use the label attribute on matimage as the alt text for the img element when converting to version 2.  The description of the label attribute in QTI version 1 is a 'content label' used for editing and searching.  This might be quite close to the purpose of alt for matimage because a text string used to find an image in a search might be a sensible string for use when the image cannot be displayed.  However,  editing sounds like something only the author would do so there is a risk that the label would be inappropriate for the candidate.  There is always the risk of spoiling the question, for example, if the label on an image contained the word "correct" then candidates that experienced the alt text instead of the image would be at a significant advantage!

Another common way to auto-generate alt text is to use the file name of the image, this is less likely to leak information as authors are more likely to figure that the file name might be visible to the candidate anyway.  Unfortunately, image file names are typically meaningless so it would be text for the sake of it and it might even confuse the candidate - especially if the names contained letters or numbers that might get confused with the controls: just imagine a speech interface reading a shuffled MCQ: "option A image B; option B image C;  option C image A" - now our poor alt text user is at a serious disadvantage.

Finally, adding a general word like 'image' is perhaps the safest thing and something I might experiment with in the future for the QTI Migration tool but clearly the word 'image' needs to be localized to the language used in the context of the image tag, otherwise it might also be distracting.  I don't have a suitable look-up table to hand.

So in conclusion, content converted from version 1 is always likely to need review for accessibility.  Also, my experience with the migration tool reaffirms my belief that developers of QTI 2 authoring tools should start enforcing the non-empty constraint on alt for compatibility now to get ready for HTML5.


QTI on the Curriculum

01NPYPD - Linguaggi e Ambienti Multimediali: "qui"

It is amazing what you stumble upon when you use Google alerts. I was intrigued to see these course materials which include a 62-slide introduction to QTI version 2 alongside such esteemed subjects as HTML5, SVG and CSS.

The slides are in English by the way!


Reports of Mono's Death are Greatly Exaggerated...

This post was provoked by fears that following the acquisition of Novell by Attachmate the Mono project faces an uncertain future.  I've documented my thoughts on the Java/C# schism and what it might mean for my attempts to get my own Python modules working in these environments.

Mono is an open source project that implements C# and the supporting .Net framework allowing this language to be used on platforms other than Microsoft's Windows operating systems.

The schism between C# and Java is (was?) very harmful in my opinion and represents a huge failure of the technology industry back in the 1990s when the key commercial players were unable or unwilling to reach an agreement over Java and Microsoft redirected their efforts to developing C#.  (Just imagine where we would be if the C language had suffered the same fate!)

Since then, Java programmers have smugly assumed that their code would always work on a wider variety of platforms and represented the more "open" choice.  I always felt that Mono did just enough to enable the C# community to retain its credibility even though it would be hard to argue that it was a more open choice, especially given the absence of any standard in versions 3 and 4 of the language.  However, Oracle's acquisition of Sun has created a sense of uncertainty in the Java community too.

In both cases it seems natural to use the word 'community' because programming languages do tend to foster a community of users who interact and share knowledge.  In the case of open source communities they also share code by contributing to the frameworks that support the language's users.  This latter point is critical to me, the Java community goes way beyond the core framework.  Java without the work of the Apache foundation would be significantly less useful for programming web applications.

That said, there is a new community of Java developers emerging because of its use on the Android mobile platform.  This programming community may share the same syntax but could easily become quite distinct.  In some ways it is a return to Java's roots.  Java was invented as a language for embedded devices where the types of programming errors C/C++ developers were making could be fatal.  The sandbox was a key part of this, ensuring a higher level of security for the system and protecting it from rogue applications.  These are just the qualities you need on a mobile phone or consumer electronics device where the cost of bricking your customers' favourite toys is an expensive repair and replace programme.  C# is also in this space, in this recent article on The Death of Mono notice that the knight in shining armour is driven by a mobile-based business case.

So if you want to use C# and .Net to develop web applications it seems to me that you are better sticking with Microsoft's technology stack and playing in that community because running your code on other platforms is likely to get harder, not easier.  And so the Java/C# schism lives on in the web app world.

Python and the Java/C# Schism

Given that the C# and Java communities seem to be a playing out an each to their own strategy it got me wondering about the Python community and how IronPython and Jython fit in.  Python started out as a scripting language implemented in C/C++.  There is typically no virtual machine or sandbox, it is just a pleasant and convenient way to spend a few days writing programs that you would have previously wasted years of your life trying to implement in C++.  The Python framework is a blend of modules written purely in Python with some bare-to-the-metal modules that wrap underlying C++ code.

Given that both Java and C# provide C/C++ like environments with the added safety of a sandbox and garbage collection, implementing Python on these platforms was a logical step and Jython (Python on Java) and IronPython (Python on C#) have even caused the word CPython to enter the vocabulary as the original Python interpreter.

In an earlier blog post I described my first steps with IronPython and described how previous attempts to implement PyAssess and my QTI migration tool had failed on Jython.  With hindsight, I shouldn't be too surprised to see that the IronPython developers have made the same decisions and that my code fails on IronPython for the same reasons it fails on Jython.  The technical issue I'm having is described in this discussion thread, which raises concerns of a schism in the Python community itself!

Actually, the trajectory of CPython towards Python 3 should solve this problem and Jython, IronPython and CPython should converge again on the unicode vs string issue, though when that will be is anyone's guess because Python 3 is not backwards compatible.  Not only will code need to be reviewed and, in some cases, rewritten but the conversion process will effectively fork most projects into separate source trees which will make maintenance tricky.

As with the Java and C# communities, the framework is just as important as the language and probably more so in defining the community.  Even if the basic language converges on the three platforms it seems likely that the C#/Java schism will mean that most projects for IronPython will exist as a more pleasant and convenient way of implementing a C#/.Net project rather than as a target platform for cross-platform projects.  For example, Python frameworks like wxPython (a GUI toolkit for desktop apps) rely on the commonality of an underlying framework (the C++ wxWindows) so are unlikely to emerge while the Java/C# schism remains.