Toxic Elephant

Don't bury it in your back yard!

Very Simple Nautilus Plugin to Show Deletion Date

Posted by matijs 18/05/2009 at 09h14

Gnome’s file manager, Nautilus, does not natively support showing the deletion date for trashed items. This has annoyed me, and others, for a very long time.

Long story short, I created a very simple implementation in Python as a Nautilus plugin. You can find it in its github repository.

This solution has one drawback: Nautilus plugins can only add string columns, so to make it sort right the date is not in a very user-friendly format. I like to think of it more as proof-of-concept.

What’s next? Nautilus has hard-coded support for sorting by each of its possible date columns. It would be nice to make that more generic so as to allow adding arbitrary date columns, or columns with the sort key and user-visible text separated.

Tags no comments no trackbacks

Some Links

Posted by matijs 26/03/2009 at 12h11

These can all be seen as being about art: Art of programming, video, sound.

Pascal Costanza’s Highly Opinionated Guide to Lisp. A real guide:

Something like “Lisp for experienced programmers”

Just what I needed. Convinced me that Common Lisp will be the next programming language I learn.

Datamoshing: from _why’s article (with examples), to a practical guide (itself datamoshed). The technique uses accidental properties of current video compression: The compression partially separates motion from color, so we can combine the color from one still image with completely unrelated motion from another clip. Perhaps this can be cleaned up by:

  • Fully separationg motion and color information (the compression algorithms only do partial separation)
  • Allowing partial recombining of the color, creating the possibility of a ‘fade-in’ of the ‘correct’ color, or other effects.
  • All this supported by your favorite non-linear editor program, of course.

This would give more control, but less interesting unexpected artifacts. It’s a trade-off.

And finally: sCrAmBlEd?HaCkZ!, automatically recreates one audio track (music, mainly), by glueing together similar-sounding pieces from another track (or set of tracks). Very impressive. Be sure to watch the explanatory video.

Tags no comments no trackbacks

The Arc Challenge

Posted by matijs 17/02/2008 at 21h14

Hm, so Arc is here, and Paul Graham gives the Arc challenge. The answer in Arc is short indeed. First, let’s see an answer in Rails (loading a framework is allowed according to the challenge), with said_controller.rb:

class SaidController < ApplicationController def index; end def click; session[:it] = params[‘what’]; end def show; end end

and some templates, for the first page, index.html.erb:

<% form_tag ‘/said/click’ do > <= text_field_tag ‘what’ > <= submit_tag > < end %>

second page, click.html.erb:

<%= link_to ‘click here’, {:action => ’show’} %>

third page, show.html.erb:

You said <%= session[:it] %>

The Rails answer may be a little longer (although by how much is hard to say due to the different syntax — is end a token?), but it not a case of the same but longer.

First, the Rails version is in temporal order, the Arc version is not. Perhaps there’s a way of reading the Arc version that makes this order natural, but right now, it looks confusing.

But the most striking difference is that it is based on a completely different philosophy of how web applications should be developed. The Arc answer is great if you want a web application based on continuations. The Rails answer is what you would use if you want to use REST.

I’m definitely in the REST camp, which makes this example meaningless as a demonstration of Arc. It shows me that Arc can be used to write a short program that does something I don’t want to do.

The ultimate question of course is whether brevity (in terms of number of tokens, not characters) is the single best metric for language power.

Update: Someone wrote a Ruby version that is about as short as the Arc version, uses the same paradigm, and is in temporal order:

def said aform(input(“foo”), submit) { w_link(“click here”) { “you said: #{arg :foo}”}} end

Tags 2 comments no trackbacks

Aaargh!

Posted by matijs 14/02/2008 at 21h35

I’m upset. I’m so upset that I was originally going to call this entry “Fuck you, Python”. Now, I realize that’s not a very nice thing to say, and actually, Python can’t really help it anyway. Except by not existing1.

Why, why, why must every other new language created these days have significant indenting? You see a new language, like Cobra, you read the overview of features, and you go, cool, great runtime performance, static and dynamic typing, and contracts, too. So you browse on to the hello world example, and boom! the absence of end-of-block tokens hits you in the face like an iron fist.

Now, in Python’s case you can tell from the reasoning2 and the implementation that somebody actually thought this through, but Cobra has the following rationale for using this method of block structuring:

Cobra uses indentation to denote code structure since adept programmers do this anyway in languages that don’t even require it (C#, Java, C++, etc.)

Wow. I’m going to make a language that uses the comma-space token to separate function arguments, since adept programmers put a space after the comma in languages that don’t even require it.

Look, if you use indenting for block structure because you like Python, just say so already.

Oh wait, there’s more:

In Cobra, one INDENT is accomplished by one TAB or four SPACES.

Huh? Because adept programmers indent four characters anyway even in languages that don’t require it? Because adept programmers use one tab per four spaces anyway even in editors that don’t require it?

Sheesh.

I feel much calmer now.

1 See how reasonable I am. I’m not actually calling for the non-existance of Python.

2 I don’t agree with that reasoning either, but at least it’s, you know, reasonable.

Tags 3 comments no trackbacks

Hello New Year!

Posted by matijs 23/01/2008 at 06h36

It’s a new year! Time for more resolutions. I can’t believe that’s actually two years ago.

Yes, my blog has been neglected, but not for want of anything to write about. Oh, there are so many things I have an opinion about. But always, it’s the question, is my opinion interesting, new, well informed, etc? And can I write something sizable about it? Not conductive to writing every monday (recently replaced by sunday, but I bet you hadn’t guessed). Maybe I should try less hard to be reasonable.

Oh yeah, e-mail is getting better, mainly thanks to the Inbox Zero articles.

What I really want to be doing: I still don’t really know, but let’s look at what I might blog about:

  • Size is the Enemy, leading to the issue of abstractions in programming languages.
  • 80/20, or the problem of getting your average Java/.NET programmer to really learn and use new things (e.g., new methods of abstraction).
  • Lots of new languages are popping up, all running on some VM or other (e.g., Scala, Nemerle, Boo). Where’s the development in regular compiled languages?

This surely points in some direction, but some weighted average will have to be taken to find out what that direction is.

I did manage to quit the job that was definitely going in the wrong direction, so there’s a plus.

Oh, you wanted new resolutions? Hm, let’s do some:

  • Uncluttered house
  • Learn Japanese
  • Finish more software so it’s releaseable

Tags , , no comments no trackbacks

The Beauty of Git

Posted by matijs 10/11/2007 at 18h57

After my struggles with svk, working with git is a breath of fresh air. It has great support for branching and merging, and putting even the smallest of throwaway projects under version control becomes as simple as:

git init

Gone are the days of the “oh i’ll just make ten copies of this script here because setting up a repository takes too long” style of version control.

Tags no comments no trackbacks

I'm Not a Mockist

Posted by matijs 04/11/2007 at 13h56

Let’s talk about mocking.

It apparently is the hot new thing in Rails land. And like earlier silver bullets, it’s becoming a religion: Acolytes would rather write ten lines to set up a mock object than one to instantiate an actual one.

Honestly, I have tried to understand the benefits of mocking, but I just don’t see them1. Then I thought I would have to write a long article about how mocking is flawed, and would you people please all see sense already. Luckily, Martin Fowler did it for me, and with a lot more objectivity. Go read his Mocks Aren’t Stubs. In addition to explaining the difference between Mocks and Stubs (a difference often overlooked by the religious), he explains why you might not want to use what he calls “mockist testing”.

So, in the spirit of religious tolerance, I can now say: I’m not a Mockist.

My particular reasons?

  • Mockist testing is not DRY: Each class’ behavior is now defined in its code, its unit tests, and each time it is mocked.
  • Mockist testing tests a particular implementation of behavior, making refactoring harder.
  • Mockist testing makes writing your tests more work, inviting you not to test.

Next time you find yourself complaining that setting up your mock objects is such a lot of work, ask yourself: “Am I a Mockist?”. Maybe you’re not.

1 Well, one minor benifit I can see that you can start writing and testing your views before having written your models. I never seem to want to do that anyway, though.

Tags no comments no trackbacks

Undressed Ruby

Posted by matijs 14/10/2007 at 12h14

In Ruby, there is really no compile time. There is parse time, and then there is run time. All class and method definitions are done at run time.

class Foo def bar puts “Zoo!” end end

is basically1:

Foo = Class.new do self.define_method(:bar) do puts “Zoo!” end end

See, we just removed the class and def keywords from Ruby. What else? Ah yes, method calls. That’s just sending messages. In fact, you can replace any method call foo.bar with foo.send(:bar), like so2:

Foo = Class.send(:new) do self.send(:define_method, :bar) do self.send(:puts, “Zoo!”) end end

How much syntax can you remove like this? How far can Ruby be undressed? And can you come up with a macro system to put the clothes back on?

Some ingredients: Why list macros are cool, RubyToRuby.

1 Actually, it’s not the same, since the define_method way creates a closure, so you can do like this

2 Yes, I know I’m using method call syntax here. But this way I do expose the message-passing view on OO that Ruby has. If you want, you can replace it with send_message(object, method, *args), and assume Ruby defines send_message somewhere.

Tags no comments no trackbacks

We don't need another Arial

Posted by matijs 16/09/2007 at 13h00

Some time ago, RedHat released the Liberation set of fonts. They are intended as metrically identical replacements for Microsoft’s Arial, Times New Roman and Courier New fonts.

Sounds great, doesn’t it?

Well, apart from the license issues, there’s another problem: Metric equivalence isn’t everything. Arial is already the metrically equivalent substitute for Helvetica, and look at it: Arial is basically Helvetica’s ugly twin sister. So, will Liberation be any better?

Linux already has a set of fonts that are not only metrically equivalent to, but actually look like Helvetica, Times Roman and Courier: The URW
fonts
. To see them on the screen, instead of the ugly jagged bitmap versions, you’ll need to make them available to X, and turn off bitmap fonts in fontconfig1.

But the URW fonts themselves look ugly too, because their hinting is bad. Liberation would solve that, wouldn’t it? No it wouldn’t, because
Liberation’s hinting isn’t done yet:

The first release is a set of fully usable fonts, but they will lack the fully [sic] hinting capability […] provided by TrueType/FreeType technology.

So why not spend the effort on providing good hinting for the URW fonts, so we can have actual nice looking real Helvetica on our Linux screens?

1 On Debian, and probably Ubuntu, that’s

sudo aptitude install gsfonts-x11

and

sudo dpkg-reconfigure fontconfig-config

respectively. Answer no to using bitmapped fonts.

Tags no comments no trackbacks

Disqualified by Advertising

Posted by matijs 23/08/2007 at 16h36

I was enthousiastic about noobkit for about a week. Finally an alternative to the rough style of Ruby’s standard API documentation.

Until I actually wanted to use it.

Most pages have a full width block of Google ads above the main content. This is just too much. For some methods, the text is one line. The ad block then is five times as big.

I’ll go back to using the old version, thanks.

[Also, the search function is not geared towards API documentation, but instead uses a generic Google-like method. Why not highlight the search results that actually describe the method or methods with the searched name?]

Tags no comments no trackbacks