Hobby-hacking Eric

Showing posts with label idea. Show all posts
Showing posts with label idea. Show all posts

2010-09-22

Early Career Researcher: the computer game

Here's an idea for a computer game called Early Career Researcher. The simple version being a fairly mindless turn-based RPG-esque deal. Nothing earth shattering in terms of game mechanics, but perhaps an amusing toy.

You have
  • personal attributes (eg. writing, social skills, initiative)
  • inputs (eg. ideas, papers to review)
  • daily resources (eg. time, energy)
  • actions (eg. check email, write paper, write grant proposal, lab work [or some generic term for "actual" research leg work], take nap, go to pub)
  • outcomes (eg. paper accepted, grant awarded, contract extension)
  • light bulbs (XP)
The goal of the game is just to maximise light bulbs. The basic model is that every turn consists of a "day" (a day should take about 5-10 minutes to play). In each day, you can do any number of actions, but the kinds of actions are limited by the inputs and daily resources you have. For example, you could do write a paper, but in order to do so, you'd need a paper-topic resource to consume, not to mention time. Likewise, you could check your email and it may only take a few minutes, but it could also use up a lot of your energy. Actions may result in outcomes, but whether or not they do so depends on a combination of personal attributes and luck. For example, writing a paper may result in paper accepted, depending on writing skills, research-fu and the dice roll. Going to the pub (presumably chatting with colleagues) may result in Ideas depending on social skills and creativity and the dice roll. Outcomes generate inputs (eg. ideas) and Lightbulbs (XP). If you get enough XP to level up, you can use your lightbulbs to purchase personal attributes.

As the game develops it should become clearer that it's important to choose your actions wisely, and also to pay attention to the notion of balance. Spending all your time doing lab work or writing grant proposals may seem like a good idea, but if you fail to spend enough time in the pub or take sufficient naps, you may not generate sufficient idea resources to make very much progress. Or maybe if you're too lazy and spending all your time just trying to be inspired, you just don't make sufficient practical progress to get anywhere.

So if anybody wants to code this up as a little exercise...


2008-12-30

riot is almost a Haskell mail client

In case anybody wanted to write a mail client in Haskell, I should point out that Tuomov's riot (Riot is an Information Organisation Tool) outliner
  • provides a sort of mutt-like user interface and
  • stores its outlines as mailboxes (using in-reply-to to treat outline ancestry as thread ancestry).

So that's some of the work done for you :-)


2008-11-07

timesheet helper

I wish there was a simple, no-fuss command line timesheet helper in the spirit of cabal-install and twidge. The kind of interactions I imagine are:

09:00 # timesheet start work draft 3 of the paper
10:00 # timesheet start darcs dwn
10:45 # timesheet start work regression test for ppack
12:00 # timesheet stop
12:30 # timesheet start darcs roadmap
13:15 # timesheet start work regression test for ppack
16:30 # timesheet start darcs patch review
17:00 # timesheet start work meeting
18:30 # timesheet stop

18:30 # timesheet summary
Today 2008-11-07
-------------------
darcs: 2h
work: 6h 30m

18:30 # timesheet details
Today 2008-11-07
-------------------
darcs: 2h
* dwn: 30 m
* roadmap: 45m
* patch review: 45m
work: 6h 30m
* draft 3 of the paper: 1h
* regression test for ppack: 4h
* meeting: 1h 30m

(Note the assumption here that you are never working on two tasks at the same time; clocking in to a new task automatically clocks you out of an old one). The key to this application is simplicity. In its present state, gpe-timesheet (0.32) uses too many confirmation dialogues to be really useful. Loggr is nice and simple, but if I close my browser window, I lose track of things. Another property I would like to have is for the application to be forgiving to mistakes. If it stored timesheets in a simple text format, for example, I could just edit out my mistakes in a text-editor.

For Haskellers, I also wish that we had a common library for writing command line applications with subcommands and switches. This would be useful for darcs, cabal-install, twidge, this timesheet application, and more.


2008-07-22

encodings-aware hex editor

Here's another coding-project idea: I would like to see a hex editor that knows how to display characters in other encodings than ASCII (specifically: I want to debug messed up UTF-8 text files).

Google and apt-cache search reveal no such editor, at least not in the free/open-source worlds, nowhere in Linux or MacOS X freeware land. On Debian based systems, there are a couple that handle some Japanese encodings, but nothing that deals with UTF-8.

Likely features:
  • toggle between an ASCII-only mode and a show-as-UTF-8 mode
  • good UI for the fact that UTF-8 characters have a variable length in bytes
  • graceful handling of encoding errors


Haskellers could possibly do this as a part (plugin?) of Yi, or maybe just a completely standalone product.

And if you want a slightly simpler project, a UTF-8 hex dumper would be good. Hmmph... come to think of it, maybe it would have been more productive to just go write that instead of this blog post.

Edit: Well, I went ahead and made a stupid little dumper for my needs. Here is the output on some sample corrupted UTF-8
20 28 5b 47 65 6f 72 67 69 61 6e                     ([Georgian
3a 20 e183a1 e183 3f e183a5 e183 : ს«e1 83»?ქ«e1 83»
3f e183 20 e18397 e18395 e18394 e1839a e183 ?«e1 83» თველ«e1 83»
3f 5d 0a ?]
20 28 5b 47 65 72 6d 61 6e 3a 20                     ([German:
44 65 75 74 73 63 68 6c 61 6e 64 Deutschland
5d 20 5b 49 50 41 3a 20 cb88 64 c994 ] [IPA: ˈdɔ
c9aa 74 ca83 6c 61 6e 74 5d 29 2c 20 ɪtʃlant]),
6f 66 66 69 63 69 61 6c 6c 79 20 officially
74 68 65 20 46 65 64 65 72 61 6c the Federal
20 52 65 70 75 62 6c 69 63 20 6f Republic o
66 20 47 65 72 6d 61 6e 79 20 28 f Germany (
42 75 6e 64 65 73 72 65 70 75 62 Bundesrepub
6c 69 6b 20 44 65 75 74 73 63 68 lik Deutsch
6c 61 6e 64 2c 20 5b 49 50 41 3a land, [IPA:
20 cb88 62 ca8a 6e 64 c999 73 72 65 70 ˈbʊndəsrep
75 62 6c 69 cb 3f 6b 20 cb88 64 ubli«cb»?k ˈd
c994 c9aa 74 ca83 6c 61 6e 74 5d 29 2c ɔɪtʃlant]),
20 69 73 20 61 20 63 6f 75 6e 74 is a count
72 79 20 69 6e 20 43 65 6e 74 72 ry in Centr
61 6c 20 45 75 72 6f 70 65 2e 20 al Europe.
0a
Highlighting by hand. I should probably go figure out how to colourise the corrupted characters. Or maybe I should just go ahead and package this, put it up on hackage? Make it available via darcs? I would need a decent name. So far, I have hexy-xxy and hexdump-utf8 neither of which are that great :-/


2008-05-05

lingscore

A little bit work-related. In a mail that I'm about to send out to the Corpora mailing list:
We're looking for implementations of scoring algorithms for coference resolution. Specifically, the algorithms we are interested in are MUC-6 (Vilain et al., 1995), B-CUBED (Bagga and Baldwin, 1998), and CEAF (Luo, 2005).

Our hope is to compare a few pieces of coference resolution software. Does anybody have preferably standalone software that we could use to calculate these scores?


I am sorely tempted to just sit down for a few moments and create these (scoring) tools myself.

It'd be a small Haskell package called 'lingscore', probably a library and an executable. I'd stick the scorers under the 'NLP.Evaluation' package. The library would be dedicated to NLP evaluation algorithms. No actual NLP, just the scoring algorithms for evaluation campaigns. Should not be difficult, and would very slightly advance the agenda of making Haskell a viable platform for NLP-hacking.

I quite like the idea of using Haskell for the stupid reason that type signatures make it a bit clearer what kind of inputs we're expecting and what kind of outputs we can produce.


2008-02-08

checkquick

Darcs needs a benchmarking tool. After 'stopwatcH', this is the first name I came up with, horrible as it is. I was thinking that surely, this is a general problem, so we should throw something up on hackage. The basic wish is to be able to run a program N times (comparing it with a different version of the same program).

Can you help? If you've got code to share, put it up! If not, and you want to contribute to project, comment on this blog. If nobody gets moving [and gives me a better name] I guess I'll create a 'checkquick' project, probably using code.google.com and code.haskell.org. If nobody submits anything and I really do have to start this project (note: I do not want to), I am hoping for a liberal commit model, where we pretty much hand out push rights to anybody who wants them.

I've already a little description written up, just in case:
Checkquick is a tool for comparing the performance between two versions of the same program, on a series of benchmarks that you design.

Checkquick aims to be easy to use, almost as easy as running 'time your-program arg1..arg2'. Ideally, it should be easy for outsiders to write timing tests for your programming project and contribute them as part of your performance testing suite.

It is written in Haskell and named after the illustrious, though wholly unrelated, quickcheck.


2007-07-13

what's in season?

Another programming project for those of you who are just itching for something to code. Basically, I want a website which can tell me, given my current location, what fruits and vegetables are in season right now.

Some thoughts, questions and requirements
  • The site must be dead simple to and very pleasant to use. This is not something you should have to read documentation to figure out.
  • This kind of thing could be easily international, so I want pictures. Maybe you can grab them from the Wikimedia Commons. I guess it would be fair to give you bonus points if you localise the thing, or maybe let me play with the language settings so I learn how to say 'rutabaga' in Arabic.
  • How does the user tell you where s/he lives? As a default, it would be nice if you auto-detected it, but what might be nicer also is if I could play around and plug in different locations. How would you pick a location? By pointing at a map of the world? Also, maybe you don't just want a single point in the map, but a region of N kilometers around me. The question is basically, what grows N kilometers from where I live, where I get to specify
  • Likewise, what do you do about the current date? It would also be nice if I can play around with this, asking not just 'what's in season right now' but 'what's in season during wintertime?'
  • Where is all of your data coming from? How are you going to store it and look it up? What kind of data do you really need?
  • If you want to get really really fancy, you can make the site adapt to current events. Maybe parse newspaper texts to find out that it's really not a good year for mangoes.
This is not necessarily a Haskell project (although in my silly, silly eyes, everything is potentially a Haskell project), but this might be a fun way to learn how to do web stuff and maybe play around with databases. In fact, such a project might also be useful for building a Haskell web tutorial, a kind of site that we can build together. Simple objectives that everybody can understand, and actually useful for something.

This project might also be a good way to learn about building user interfaces. Or maybe if you're not interested in working on that stuff, it would be a good opportunity to partner up with somebody else. They worry about the UI stuff and you worry about the code. I don't know anything about UI, except that I think it's important to get it right. If it helps, I greatly enjoyed Donald Norman's The Design of Everyday Things, as well as Bret Victor's Magic Ink.


2007-07-05

mediawiki code projects

Three more projects to practice your Haskell with, and produce something useful while you're at it:
  1. a mediawiki writer for Pandoc (should be a piece of cake)
  2. a mediawiki reader for Pandoc (perhaps less easy, note that there is also some HTML to deal with)
  3. a mediawiki template engine : given a set of mediawiki pages on the local filesystem, convert mediawiki input into mediawiki output, with all templates interpreted
My super-seekret reason for suggesting these projects is so that we can one day convert the Haskell wikibook to LaTeX, or something else, and produce a nice PDF. Naturally, it would also be useful for the other wikibooks, many of which have crappy PDFs, or none at all. But that's not for you to worry about :-)... just have some nice exercises to play with.

(#3 might be a bit of work... and also, it's not clear that this is exactly what we want for converting wikibooks. It seems that the point would not be to expand the templates, but to convert them to something else. If I have a template called HaskellExercises, I don't want to expand it to a bunch of div tags or whatever; I want to convert it to something else)


2007-07-01

haskell for reprap?

Another potentially fun and probably big project for Haskellers: software for the RepRap project. The goal of RepRap is to build an open-source 3D printer for under $500 and with the ability to print out its own parts. Their control software is written in Java... borriiing.

Maybe this is the kind of niche that Haskell could jump in to, something a little unusual (like darcs and xmonad), and very useful at the same time (like darcs and xmonad). My rough thought was that we could similar successes with xmonad, building solid and minimal code for something that is real world (you don't get any more real than physical objects).


2007-05-06

iron coder

There ought to be something like Iron Chef for programming. Naturally, the Iron Coders would each represent a different paradigm: functional, imperative, object oriented, declarative. Actually, I have no idea how this would work and suspect it probably would not very entertaining at all. I just like the idea of summoning IRON CODER FUNCTIONAL! The guy rises with a platform and it's got a little lambda on it...


2006-12-10

rewriting PLEAC Haskell?

One complaint I have heard about the Haskell cookbook is that it is rather unidiomatic and thus not very helpful for people trying to learn Haskell. For example, one particularly shocking thing the implementation does is to shadow (.) operator to make more "object-like": o . f = f o (reverse dollar? euro?). This leads to snippets of code which, as one of the wikibook commentors put it, are barely recognisable as Haskell:
s''' = s1.split " ".reverse.join " "


PLEAC Haskell in its present form is not very suitable for educational purposes, but what if the Haskell community ran through and cleaned it up? Only the first two chapters are implemented anyway, so it doesn't seem to be all that much; the only substantial thing to rewrite perhaps being in soundex code. I personally cannot invest any time in this, being already behind in other projects like darcs and wxhaskell, but it might be a fun project for Haskell enthusiasts, or even yellow-belt Haskellers trying to come to grips with the language.

If interested, you should probably subscribe to their mailing list and maybe bounce around some ideas on the Haskell café. Another thing to consider is contacting the original author Yoann. It would be good to get him on board, maybe with a little gentle persuasion. I mean, he probably thought it was a good idea to make the language more recognisable to newcomers. Nice thought... but maybe he would now agree that newbies would be better off with more idiomatic Haskell.