Computer science research ideas

Every now and then I get emails from researchers (often students), asking me to participate in their particular study. Sometimes I participate, sometimes I don’t, often I’m thinking: Couldn’t you ask me what you should be researching in the first place? While that is an inappropriate response for these emails, I wanted to write down my ideas for researchers, in public, so that they can either find them on their own or I can at least ps-link to them.

Since I’ve been doing mostly JavaScript development in the last few years, with about 80% of that in the browser, my perspective is mostly from that platform. Though I expect that most of these ideas can be applied to other platforms as well.

If you have ideas that would fit in this list, let me know.

Testing tools

How can better testing tools help write better software? This area seems to have so much untapped potential. Most open source testing tools are developed and improved in very small increments, the “this feature would be with this usecase”, but its rare to find features that make big leaps. While I still haven’t used it, Intern is an interesting tool, because it integrates all kinds of frontend testing usecases into a single suite, and usually integration, especially if we think of it as fusion, can set free extra energy.

One example of a feature in a testing tool that is rather unlikely to happen in regular open source development scenarios is the reordering feature in QUnit. Its not a well known feature, since its behaviour is rather subtle. It might also not be as useful as I’m thinking it is, since I haven’t been able to do any research to verify that. But I think its an interesting example anyway. And since I came up with it (more or less) and implemented it, I can tell you how it happened.

Some years ago, I was listening to a podcast, with Kent Beck, one of the original authors of JUnit, as a guest. He was talking about a project he had been working on for some time, called JUnit MAX. It was a plugin for the Eclipse IDE, providing a better test runner. One significant feature of this plugin was its reordering of tests after previous runs. Kent was talking about how research showed that the odds of a failing test failing again on the next run are much higher then for a passing test to start failing. So for shorter feedback loops, it makes sense to run tests, that previously failed, first on the next run. JUnit MAX would also consider the time it takes for various tests to run, and run the fastest failing tests before the slower failing tests.

After hearing that, I figured that I could implement a subset of that feature in QUnit, reordering test runs, based on previous failures (ignoring the secondary sort on runtime). While it required some rather complicated changes to make the queue flexible enough for the reorder and maintaining the original output order, the result was a faster feedback loop with no additional effort needed by the developer using QUnit. The only time this failed was when tests weren’t atomic, that is, test B relied on test A running first. Non-atomic tests are a significant code smell by themselves, and in way this feature helped uncovering them. In the end, it still required an option to turn the reordering feature off.

I’m optimistic that there are plenty ways to write better testing tools, and academic research could provide ideas and do verification of those ideas.

Error messages

“undefined is not a function” is a terrible error message, but its not even the worst you’d ever run into when writing JavaScript for browsers. “Script error” without a stacktrace definitely is worse, but hopefully not occuring anymore.

Elm is known for spectacularly good error messages, almost obsessively improving the compiler, even with a separate repository collecting “broken Elm programs / data to improve error messages.

I’d love to see a researcher doing some ground work like this for JavaScript, collecting errors across browsers and serverside runtimes, and at least filing issues to improve these messages.

Bug reporting

Consider these two scenarios.

Scenario A: You get an email with the subject “the site doesn’t work”, and no body. You don’t even know which site this refers to.

Scenario B: You get an entry in your issue tracking system, with some descriptive fields, but most importantly, a link. You click that link, which brings you to your app, along with some debugging tool. One element of that tool is a slider that lets you go back in time. It also shows you various relevant variable. Going back in time you can see what interactions the user did before running into the issue they reported. You can quickly identify the issue based on the steps and the state of the system.

Now, which of these two would you prefer if you get paid for solving issues (not so much for spending time on solving them)? Scenario B supposedly is also something Elm provides (or at least helps with). But I don’t see why other platforms shouldn’t be able to provide at least partial support for that kind of error reporting and debugging.

Code Review

If a code review finds no issues, does it mean that the reviewer didn’t bother looking too much? Or that there are no issues? How can you review the reviewer? Are there metrics or tools that could help become better at reviewing? A reviewer that points out a lot of style issues might never catch actual bugs. A reviewer who always ignores styles issues might have a hard time catching bugs due to style issues.

This seems like an area with a lot of untapped potential, but its hard to tell without some research.

Working remote

Collaborating within a team can vary a lot by physical difference, from pair-programming at the same desk, to being on different sides of the planet in wide apart timezones. There are a lot of options in-between those two extremes. Martin Fowler does a great job of explaining the various options and some of their strengths and weaknesses in Remote versus Co-located Work

There isn’t a simple dichotomy of remote versus co-located work, instead there are several patterns of distribution for teams each of which has different trade-offs and effective techniques suitable for them. While it’s impossible to determine conclusive evidence, my sense is that most groups are more productive working in a co-located manner. But you can build a more productive team by using a distributed working model, because it gives you access to a wider talent pool.

In my experience, once you’ve built a team where everyone can work remotely, you get the benefits of that model even if parts of your team are (sometimes) together in one room. For example, assuming a core team of 5 people shares an office. Every other week one of those people needs to work from home, to take care of family, dealing with home repairs, or one of many other reasons. Usually these activities don’t need an entire day off (and they’re not real vacation!), so being able to work from home just as effectively as in the office makes this much less of an issue.

That said, how to actually build an effective non-co-located team has no clear answers. There are various technical solutions that I found working quite well, but I’ve never done any research to evaluate the ones I’m using or studying alternatives. Coming up with a list of options and ways to evaluate them seems like an interesting research topic to me. Only some of this is specific to software development. For example, communication tools that can properly format and highlight code snippets or error logs are more specific for developers.

History

All of the above have changed over time, and the bug reporting scenario B I described above has supposedly been possible with Smalltalk years (decades?) ago. I suspect that there’s a lot of history to study in software development even in just the last 10 years. From a historian’s perspective, the whole industry might be too young to study effectively, but that shouldn’t prevent studying trends like “best practices” in architecture, tools, project management, design, or any of the topics mentioned above. A good example is the Born for it article on martinfowler.com, looking at “How the image of software developers came about”.

A big thank you to Enes Fazli for reviewing drafts of this article.

OSX software, five years later

In November 2010, before my first MacBook even arrived, I asked Twitter for “must-have” OSX software and collected the results in a blog post. A year later, I posted an update with a list of OSX software I was actually using. A few more years have passed since then. Last year I switched from my original MacBook Air to a MacBook Pro (a very good decision) and used the opportunity to do some cleanup. About 9 months into using the MBP, I figured I could do another list. An asterisk indicates something I didn’t have on my list in 2011.

General

  • Chrome, as my regular browser and part of my web development environment, with these extensions:
    • 1Password
    • uBlock Origin*, currently the most decent adblocker. Will see how long it can stay independent.
    • RSS Subscription, restores the RSS icon
    • BrowserStack Local*, provides tunnel for testing local files
    • Pinboard*, quickly add open tab(s) as bookmarks. Also using Pinboard on my phone.
    • Social Fixer for Facebook*, makes a few features on Facebook a lot less annoying. Hasn’t been updated since December 2014 and accordingly falls short in many places, but even and outdated and sometimes broken extension is still preferable over vanilla Facebook to me.
  • Keynote, these days used very rarley. My last few conference talks were all web-based, with probably too much time spent on customizing the template I used.
  • Twitter for Mac, runs only when I need it. Mostly reading Twitter on my phone.
  • 1Password to generate and mange passwords. Chrome integration is nice, runs also on Windows PC and Android phone.
  • Tunnelblick for VPN connections. Depends on the project I’m working on, has seen lots of use more recently.
  • DaisyDisk*, quickly tells me where most disk space is used. This was very useful on my old MacBook Air, where the 256 GB SSD was full way too often. With 512 GB this is much less of an issue.
  • Dropbox*, weird that it wasn’t on my previous list from 2011, I’m pretty sure I’ve used that before.
  • ScreenFlow*, pretty decent software for capturing screen casts. I’ve mostly used it to record screenreader sessions for my Talk to Me – Making websites accessible presentation. I also used it to record that presentation, since its able to capture both the camera input and the projector screen output.
  • Very special purpose:
    • Seil* (formerly know an PCKeyboardHack), for remapping the capslock key to toggle iTerm2. To do this, use Seil to change capslock to keycode 105 (also follow the instruction for turning off the default behaviour). Then in iTterm2, go to Preferences -> Keys, under “Hotkey”, check “Show/hide iTerms2 with a system-wide hotkey”, click on the input and hit your remapped capslock key. It should enter “F13”. Then close Preferences and give it a try.
    • SizeUp*, for maximizing windows and moving them from one desktop or monitor to another

Communication

  • Skype, still using it almost daily to chat, talk, and sometimes pair-program via screensharing. Something like once a month someone can’t hear me, but restarting Skype always fixes that issue.
  • Gitter* is like Slack (I guess), but focused on coding projects, with very tight GitHub integration. Currently using it with multiple chat rooms to work on sloppy.io. I created a jquery-validation channel, but it has seen very little use. I’m looking forward to the day where they’re rewriting it as a native app, or at least fix the performance. Switching channels shouldn’t take several seconds for the new channel to render.
  • LimeChat* as IRC client, using isaacs’ theme
  • Telegram*, using the “native” OSX app, which supports secret chats, something the cross-platform Telegram Desktop app doesn’t have.

Development

Media

  • iTunes for music playback. Overall its still decent, even with the tons of irrelevent features cramped into the same app. I’ve never found an alternative just for playback of tagged mp3s files. I often listen to all albums of a single artist in chronological order or shuffled albums (not just songs). Would need at least these features to be able to replace iTunes.
  • VLC for video and occasional audio file that I don’t want to add to iTunes.
  • Picasa for photos, a quick import and edit while traveling. May need to find a replacement, since the desktop app won’t be updated anymore.
  • Fission*, for cutting MP3s very efficiently. Unlike a lot of other software, Fission can cut compressed audio files, without decompressing them first and recompressing them later. Great to cut rehearsal room recordings down to the relevant parts.
  • Guitar Pro*, for writing down songs. A very recent addition, and a bit weird to use a current version after using Guitar Pro originally about 10 years ago. They’ve added a bunch of emulated instruments, unfortunately all on top of midi instruments, which mostly sounds pretty terrible. Still useful to pin down the little details of songs and share them with the rest of the band.

Thanks to my friend Enes for reviewing a draft of this post.

Release: Validation Plugin 1.15.0

I’m happy to announce the 15th release (discounting various patch releases) of the project, bringing it up to 1.15.0. This is the first release managed by Markus Staab, who took over the maintenance for the foreseeable future.

A lot of people (26!) helped out to get this new release out of the door by a whooping 100 commits.

Kudos to all of you guys, namely: Alok Saldanha, Brahim Arkni, Christopher Bauer, Daniel Orner, Denisson Padilha, dorner, Ehsan Abidi Ashtiani, Filip Mares, Jörn Zaefferer, Julio Spader, KJ, Lars Skjelbek, Lukasz Wozniak, Markus Staab, Martti Laine, Michal Moravec, netzkind, rasstislav, sadj, Salahuddin Hairai, Saldanha, silovski, Thomas Gohard, Wojciech Walek, Štefan Baebler.

This release would not have been possible without the help of Brahim Arkni. He supported Markus in triaging bugs, cleaning up the bugtracker, reproducing reported issues and also provided a lot of patches. Thank you! It is a pleasure to work with Arkni, we are looking forward to work with him on future releases.

The release itself brings a lot of small improvements and fixes a lot of old and outstanding bugs. The most important addition is a new normalizer callback which allows you to modify the values provided by the enduser, before validation takes place. For a full list of all the changes, check out the changelog below.

Download this release.

If you use the plugin, please donate or ask your boss to make a donation! This helps to run the plugin site and makes releases like this one possible.

Click here to lend your support to: jQuery Validation Plugin and make a donation at www.pledgie.com!

  • Please post questions to the official Using jQuery Plugins Forum, tagging your question with (at least) “validate”. Keep your question short and succinct and provide code; a testpage makes it much more likely that you get an useful answer in no time.
  • Please post bug reports and other contributions (enhancements, features, e.g. new validation methods) to the GitHub issue tracker

The full changelog:

All

  • Fixed code style issues

Core

  • resetForm should also remove valid class from elements.
  • Unhighlighting field if already highlighted when using remote rule.
  • Bind the blur event just once in equalTo rule
  • Fixed error when calling .rules() on empty jquery set.
  • Fix handling of error messages with input groups.
  • Fix TypeError in showLabel when using groups settings
  • Adding a way to pass method name to remote
  • Validation fails to trigger when next field is already filled out
  • Required rule take precedence over number & digits rules
  • Error hidden but input error class not removed
  • Remote validation uses wrong error messages
  • Fixed field highlighting with remote validation.
  • Fixed :filled selector for multiple select elements.
  • Added doc reference to jQuery.validator.methods
  • Move message processing from formatAndAdd to defaultMessage
  • ErrorList should contain only the errors that it should
  • Extract the file name without including “C:\fakepath\”
  • HTML5 step attribute support. Fixes #1295
  • Added support for “pending” class on outstanding requests
  • Added normalizer (#1602)
  • Split out creditcard method
  • Escape errorID for use in the regex, not to build aria-describedby
  • Escape single quotes in names avoiding a Sizzle Error being thrown
  • Instead of using validating field’s value to skip api call, use the serialized data object of the request
  • Add support for contentEditable tags

Additional

  • BIC: allow digits 1-9 in second place of location
  • Accept method regex should be escaped properly.
  • Case-insensitive check for BIC
  • Correct postalCodeCA to exclude invalid combinations
  • Make postalCodeCA method more lenient

Localization

  • Added Macedonian localization.
  • Added missing pattern message in Polish (adamwojtkiewicz)
  • Fixed Persian translation of min/max message.
  • Updated messages_sk.js
  • Update Malay translation
  • Included messages from additional methods
  • Improving pt_BR translation and fixing a typo on the ‘cifES’ key.

Release: Validation Plugin 1.14.0

The first stable release of the jQuery Validation Plugin, 1.0.0, came out in June 2007, making the project now a little over 8 years old, pretty seasoned for a JavaScript library. According to builtwith.com, its the 25th most popular JavaScript library, with over 1.3 million websites using it. I’m happy to announce the 14th release (discounting various patch releases) of the project, bringing it up to 1.14.0. While a lot of people contributed to this release in some form, I’d like to give Markus Staab a special call out. He’s been helping with ticket triage along with addressing some issues himself, overall being a big help in keeping the project alive.

The release itself brings a lot of small improvements and fixes, along with several new localizations. The plugin now relies of jQuery’s .on() and .off() method, making jQuery 1.7.0 the minimallay supported jQuery version. For a full list of all the changes, check out the changelog below.

Download this release.

If you use the plugin, please donate or ask your boss to make a donation! This helps to run the plugin site and makes releases like this one possible.

Click here to lend your support to: jQuery Validation Plugin and make a donation at www.pledgie.com!

33 people contributed to this release. A big thank you to: a-barry, Ajay Singh, Brahim Arkni, Calinou, Carles Jove i Buxeda, Daniel DeGroff, Darshan Jani, David Weston, dnomak, Florent, hanumanum, Igor, James, jered, Jesus, Maks, Maks3w, Manuel Dalla Lana, Marek ‘saji’ Augustynowicz, Markus Staab, Merab Tato Kutalia, Michael J, Nadi, Pietu1998, rskm1, Ryley Breiddal, sekander, Shimmy, Shonetow, Stefano Stoduto, wozzo, Yair Sladowsky, Zen Chua.

  • Please post questions to the official Using jQuery Plugins Forum, tagging your question with (at least) “validate”. Keep your question short and succinct and provide code; a testpage makes it much more likely that you get an useful answer in no time.
  • Please post bug reports and other contributions (enhancements, features, e.g. new validation methods) to the GitHub issue tracker

The full changelog:

Core

  • Remove unused removeAttrs method
  • Replace regex for url method
  • Remove bad url param in $.ajax, overwritten by $.extend
  • Properly handle nested cancel submit button
  • Refactor attributeRules and dataRules to share noramlizer
  • dataRules method to convert value to number for number inputs
  • Update url method to allow for protocol-relative URLs
  • Remove deprecated $.format placeholder
  • Use jQuery 1.7+ on/off, add destroy method
  • IE8 compatibility changed .indexOf to $.inArray
  • Cast NaN value attributes to undefined for Opera Mini
  • Stop trimming value inside required method
  • Use :disabled selector to match disabled elements
  • Exclude some keyboard keys to prevent revalidating the field
  • Do not search the whole DOM for radio/checkbox elements
  • Throw better errors for bad rule methods
  • Fixed number validation error
  • Fix reference to whatwg spec
  • Focus invalid element when validating a custom set of inputs
  • Reset element styles when using custom highlight methods
  • Escape dollar sign in error id
  • Revert “Ignore readonly as well as disabled fields.”
  • Update link in comment for Luhn algorithm

Additionals

  • Update dateITA to address timezone issue
  • Fix extension method to only method period
  • Fix accept method to match period only
  • Update time method to allow single digit hour
  • Drop bad test for notEqualTo method
  • Add notEqualTo method
  • Use correct jQuery reference via $
  • Remove useless regex check in iban method
  • Brazilian CPF number

Localization

  • Update messages_tr.js
  • Update messages_sr_lat.js
  • Adding Perú Spanish (ES PE)
  • Adding Georgian (ქართული, ge)
  • Fixed typo in catalan translation
  • Improve Finnish (fi) translation
  • Add armenian (hy_AM) locale
  • Extend italian (it) translation with currency method
  • Add bn_BD locale
  • Update zh locale
  • Remove full stop at the end of italian messages