10.12.06
It’s pretty simple once you’ve seen the Solution:
public class GlobalizedDescriptionAttribute :
System.ComponentModel.DescriptionAttribute
{
String n;
public GlobalizedDescriptionAttribute(string s) { n = s; }
public override string Description {
get {
return Project.Properties.Resources.
ResourceManager.GetString(n);
}
}
}
public class GlobalizedDisplayNameAttribute :
System.ComponentModel.DisplayNameAttribute
{
String n;
public GlobalizedDisplayNameAttribute(string s) { n = s; }
public override string DisplayName {
get {
return Project.Properties.Resources.
ResourceManager.GetString(n);
}
}
}
You can then use those attributes with your objects properties:
…
[GlobalizedDisplayName("whatever")]
[GlobalizedDescription("whateverthisdoes")]
public int FooBar {
get { … }
set { … }
}
…
Globalizing the Category follows the same Pattern, extending CategoryAttribute.
There are some traps to avoid though:
- Fetching the String in the Constructor does not seem to work.
- If you use the Globalized…Attribute with an Identifier not in your Resources, the Program might throw OutOfMemoryExceptions at startup.
Meine erste Einstellung gegenüber C# war ablehnend. Wozu ein neue Sprache die kaum wesentliche Vorteile gegenüber Java bietet? Nach näherer Beschäftigung mit .NET 2.0 sah die Sache besser aus. Properties? Nice! Anonyme Funktionen? Praktisch!, Closures und Iteratoren? Yay! Langsam schien die Entscheidung doch nicht die verkehrteste zu sein.
Bei der konkreten Arbeit offenbaren sich jedoch allmählich die Unterschiede zwischen Theorie und Praxis:
- Die ganzen coolen Funktionen und Konstrukte verstecken sich hinter einem Wust redundanter Syntax, die nur duch viele automatische Funktionen in VisualStudio 8 erträglicher wird.
- VisualStudio kommt zwar mit einem Debugger, ein Speicherprofiler muss aber extern installiert werden, ein Laufzeit-Profiler kostet extra.
- Wenn ich den erwische der die Idee hatte, XML als Markup für die DocComments zu benutzen…
- Viele der netten Features sind in ihrer tatsächlichen Verwendung nur noch halb so nett. Das Programmieren in streng getypten Sprachen ist eine Qual wenn man einmal mit Ruby gearbeitet hat.
- Die Doku im MSDN ist zwar umfangreich, aber verwirrend und schlecht organisiert. Die Methoden, Properties und Member der Klassen stehen alle auf jeweils einer einzelnen Seite mit unzähligen Links, die irgendwohin führen. Soviel Redundanz führt auch dazu, dass Suchergebnisse selten akkurat sind und die gewünschte Information erst nach ein paar weiteren Klicks gefunden wird.
C# ist im Ansatz eine gute Idee, mein ungutes Gefühl wird aber vor allem duch die Implementierung durch Microsoft verursacht. Man merkt schnell dass man hier mit proprietärer Technik arbeitet wenn viele wichtige Tools entweder nicht verfügbar sind oder Geld kosten (oder kennt jemand einen brauchbaren freien Profiler?).
Dritte Woche PG, so langsam geht es los. Müssen die ersten Entscheidungen getroffen werden, gibt es auseinandergehende Meinungen.
Die Frage: Mit welcher Sprache wollen wir das Projekt implementieren? Zur Auswahl stehen C# und Java. C++ schied glücklicherweise schon in der Vorrunde aus.
Unsere Ausgangssituation sieht so aus, dass alle “so ein bißchen” Java Erfahrung aus dem Sopra haben, zwei Leute über etwas weniger Erfahrung mit C# verfügen. Kriterien die die Entscheidungsfindung erleichern sollten waren
- Verfügbarkeit und Qualität von Bibliotheken
- Performance
- 3D-Grafik Wiedergabe
und zu guter Letzt
- Vertrautheit mit der Sprache
Über die ersten drei Punkte bestand im wesentlichen Einigkeit, am letzten schieden sich jedoch die Geister, zwei Argumente stehen sich jetzt gegenüber:
Gegen C# spricht, dass so gut wie keiner von uns damit Erfahrung hat und dadurch neben den eigentlichen Anwendungsproblemen noch das Einarbeiten in eine völlig neue Sprachumgebung als Aufgabe hinzukommt. Der damit verbundene Aufwand ist nicht zu unterschätzen.
Zur Verteidigung der Verwendung von C# wird angeführt, dass man die PG dazu nutzen wolle, sich neben Java noch eine weitere, auf dem Arbeitsmarkt augenscheinlich momentan beliebte Sprache anzueignen.
Dieses Argument steht allerdings auf keiner guten Grundlage.
Vor allem ist der Wunsch eine neue Sprache zu lernen eine reine Privatangelegenheit und hat eigentlich keinen Bezug zu den Zielen des Projektes. Vorausgesetzt dass Java und C# unter allen erwähnten Kriterien äquivalent oder zumindest ähnlich sind, wird durch die Verwendung von C# nichts gewonnen, im Gegenteil, die Entwicklung wird durch den beschriebenen Lernaufwand noch behindert.
Darüberhinaus gibt es noch eine falsche, zumindest aber zweifelhafte Annahme die dem Argument zugrundeliegt. Leider konnte ich den Hintergrund dieses Gedankens in der Sitzung auf die Schnelle nicht überzeugend formulieren und habe ihn erstmal für mich behalten. Jetzt habe ich mich ein bißchen hingesetzt, nachgedacht und festgehalten was ich genau meine.
Die Idee, mit dem Lernen von C# jetzt seine Berufschancen zu erhöhen ist Unsinn
Aus –im wesentlichen– zwei Gründen:
Wem wirklich etwas daran liegt Sprachen zu lernen, der wartet nicht darauf dass die Uni auf ihn zukommt. Eigeninitiative und die Fähigkeit sich für eine Sache so zu interessieren dass man seine Freizeit darin investiert sind wesentlich mehr wert als C#. Paul Graham erläutert das Phänomen in Python Paradox:
It’s a lot of work to learn a new programming language. And people don’t learn Python because it will get them a job; they learn it because they genuinely like to program and aren’t satisfied with the languages they already know.
Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I’ll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they’ll be able to hire better programmers, because they’ll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don’t learn merely to get a job.
Only a few companies have been smart enough to realize this so far. But there is a kind of selection going on here too: they’re exactly the companies programmers would most like to work for. Google, for example. When they advertise Java programming jobs, they also want Python experience.
Nun bin ich nicht so naiv zu glauben, alle deutschen Personalchefs würden Paul Graham lesen (sehr schade eigentlich), aber wenn man auf sein Engagement und seine Bandbreite an Programmiersprachen hinweist, dürfte es kein Problem sein, jemanden davon zu überzeugen, dass man sich innerhalb kürzester Zeit in jede beliebige neue Sprache einarbeiten kann.
Umgekehrt aber einem der Personalchefs, die Graham kennen, von der eigenen Flexibilität und Begeisterung für Softwareentwicklung zu erzählen, wenn alle Spracherfahrung die man vorzuweisen hat ein bißchen Java und C# im Rahmen halbfreiwilliger Uni-Veranstaltungen sind, dürfte schwierig werden.
28.10.06
Eine möglicherweise halbwegs sinnvolle Anwendung für den Proxy den ich hier vorgestellt habe.
Es wurmt mich manchmal, für das Aufrufen einer einzigen Methode in einem Enumerable dieses hässliche Klammerkonstrukt bemühen zu müssen:
Array#each{ |o| o.method }
Das geplante Symbol#to_proc sieht auch nicht viel besser aus:
%w[dsf fgdg fg].map(&:capitalize) # => ["Dsf", "Fgdg", "Fg"]
Die Lösung:
module Eachable
class EachWrapper
instance_methods.each do |m|
undef_method m unless m =~ /(^__|^nil\?|^send)/
end
def initialize(args)
@target = args
end
def method_missing (method, *args, &block)
@target.each do |elem|
elem.send(method, *args, &block)
end
end
end
def supereach (*args, &block)
if block_given?
self.each(*args, &block)
else
return EachWrapper.new(self)
end
end
end
class Array
include Eachable
end
chars = %w(a b c d)
chars.supereach.upcase!
puts chars.inspect # => ["A", "B", "C", "D"]
Viel schöner.
Problem: das sollte nicht supereach, sondern each heissen. Das wird im moment noch verhindert:
- die Implementierung verwendet selbst
each
- die Art wie Ruby das
include Eachable verarbeitet, verhindert dass Array#each überschrieben wird.
Morgen, wenn meine Augen nicht mehr so schmerzen, finde ich eine Lösung.
16.10.06
Das klingt beeindruckend und ist die offizielle Bezeichnung der Projektgruppe die mich dieses und nächstes Semester beschäftigen wird.
Bei dem Projekt geht es darum, Methoden und Implementierungen zu entwickeln, die es Ingenieuren aus dem Maschinenbau erleichtern, Lösungsmengen heuristischer Algorithmen interaktiv zu untersuchen. Der Witz dabei ist, dass der Lösungsraum wesentlich mehr als 3 Dimensionen haben kann. Aufgabe der Projektgruppe ist es, sich zu überlegen, wie man einen solchen hochdimensionalen Lösungsraum vernünftig navigieren und betrachten kann und eine Implementierung dafür zu entwickeln.
Letzte Woche hatten wir unsere erste Zusammenkunft, eine zweitägige Seminarfahrt in der wir 11 uns gegenseitig über unsere jeweiligen Spezialgebiete informiert haben. Darüberhinaus war die gemeinsame Fahrt natürlich auch “teambildende Maßnahme”, allerdings hätte es einer solchen kaum bedurft: Ich denke dass wir da eine sehr gute Truppe zusammenbekommen haben.
Ich bin gespannt was die nächsten 2 Semester bringen werden.
13.09.06
This is just copied from ruby-talk for archival purposes.
mehr…
03.09.06
Well, there seem to exist numerous cheat sheets for Rails and other stuff out there, yet none for Rdoc. The official Rdoc Documentation is nice and complete, but sometimes it’s handy to have something you can print out on one page and quickly glance over.
I know that this nuisance hindered me to write extensive documentation for my current project so I decided to create a cheat sheet myself in the hope to encourange other newcomers to Ruby and/or Rails to develop a habit of writing good documentation.
»Download Rdoc Cheat Sheet
16.08.06
(see here)
Well, it’s been more than a week but hey, nobody’s reading my blog at this time anyways.
Using the Day Planner has given some interesting results: Unfortunately, the system of planning your day ahead only works if you either know how much time you’ll need for each discrete task or you have big, continuous tasks that you can freely distribute over several days.
None of that applied to my work during the last 2 weeks but I still got some benefits out of using the planner:
You realize, how short a day really is
The sheet has 18 hours, from 6 to 23. I slept from 0 to 8 during the final phase of the preparations for my exam. I tried not to work past 23h, so that left my day with 15 hours. If you have these 15 hours visualised before you and you start filling them up with tasks, using realistic estimates for the time needed for each one, plan in a 1h break for lunch, you see how hard it actually is to get all those things done.
So, you begin to appreciate blocks of time as major slices of your productive part of the day that didn’t seem like much before and were therefore wasted more easily.
Fitting things in comes at a cost
That’s because I didn’t really realize how much time the small interruptions actually take. I would have estimated half an hour for a quick stop at the supermarket.
Well, double that and you’ve got the time it really takes to get the keys, leave the house, get the car, drive, etc.
Ooops, there goes 1/14th of my work-day.
29.07.06
Show me a language where you can pull stunts like this in the same amount of code:
# Pretends to be someone else
class Poser
instance_methods.each do |m|
undef_method m unless m =~ /(^__|^nil\?|^send)/
end
def initialize(args)
@target = args
end
def method_missing (method, *args, &block)
puts "Long lookup operation (missing #{method})"
@target.send(method, *args, &block)
end
def proxied_method
puts "Short proxied operation"
@target.size
end
end
p = Poser.new "Ruby Rocks"
# => "Ruby Rocks"
p.class
# Long lookup operation (missing class)
# => String
p.object_id
# Long lookup operation (missing object_id)
# => 263042
p.__id__
# => 263032
p.proxied_method
# Short proxied operation
# => 10
26.07.06
Day Planner
Procrastination is a Buzzword you hear from software and management people quite often these days. Just about everyone who has some freedom in timing his tasks seems to suffer from it. Students of course also fall under this category and I’ve had this problem since first grade.
Being a programmer, a CS student, an RSS addict and having a lot of time-intensive hobbies, keeping track of what I’m actually doing all day hasn’t become easier since school.
I’m aware of techniques like GTD, which seems to be all the rage right now but I’ve always considered it a bit too extreme for me. I also like to keep it simple, stupid to I’ve been looking for alternatives to suit my style of living and working better.
Yesterday I stumbled upon the Emergent Task Timer from David Seahs Printable CEO Series, which is a sheet to make you keep track of what you’re doing in the course of a day, helping you to discover patterns or problems in your schedule.
I liked the idea very much but it still didn’t really fit my needs. On the one hand, by the layout of the Sheet you are confined to a limited set of tasks, on the other hand, Seahs Sheet only has 12 hours whereas my day consists of up to 18 (6h-23h).
Being wasted from sitting at the desk, staring at the screen all day, I went to bed shortly after 23h last night and turned on the TV for a while. Well, well, as chance would have it, I tuned right into a documentary about procrastination. Watching it, I got an idea about what my solution to the problem could be:
In order to keep me from getting distracted, I had to tightly plan my day, filling it up with tasks the night before and then following that plan strictly. I got up, set down on my desk and planned for today: Getting up, cleaning the hallway, work on the job, learn for EE, lunch, learning and being done at 16:30. I was sceptical how this would turn out, but today at 16:30 I really was done with everything.
For the purpose of not having to waste a fresh sheet of paper each day for my plan, I opened up OpenOffice and designed a timetable of my own, using what I had in the back of my mind from Seahs Table and came up with my Day Planner.
Put in a clear plastic folder and taped to my drawer, I can plan my days with a non-permanent marker, wipe and repeat every day.
I’ll continue to use this for a week and report on my experiences then.
Download:
