In Gnome (Gnome 2.28, Ubuntu 9.10), opening a file does not always yield the same result. Depending on where the file is double-clicked on, a different viewer might be displaying it. Here some idea how to get this right.
I wanted to open PDF files using Acrobat Reader instead of Ubuntu's default reader Evince. For Nautilus (and the Desktop), file associations can be changed using the file's property menu. This then resulted in PDF files to be opened with Acrobat Reader when double-clicked on in Nautilus and with Evince basically everywhere else: Firefox, Eclipse, ...
It turns out that Nautilus allows to specify custom associations, overriding Gnome's MIME-based system. So, to establish Acrobat Reader as the default editor for PDF files, open ~/.local/share/applications/defaults.list (i.e. in your home directory) and add the following entry to the [Default Applications] section.
application/pdf=AdobeReader.desktop
If there is no such file, do create it and paste the following content:
[Default Applications]
application/pdf=AdobeReader.desktop
Done. Double-clicking a PDF in Firefox now starts Acrobat Reader.
For inspiration on other mime types (and the global settings), see the file by the same name in /usr/share/applications.
Monday, December 14, 2009
Monday, October 12, 2009
FMC stencils for Dia
A friend and I are coding FMC stencils for Dia, which is Gnome's modeling tool to fight Visio. Looks pretty promising so far, and hopefully we'll get them finished in a month or so. Along with the actual stencils, we are producing a tad of documentation. It'll be made public somewhere, and if it is, I'll post a link here.
Friday, September 25, 2009
Private member variables in Python
Today, I stumbled upon the "Module Pattern" in the enlightening JavaScript: The Good Parts by Douglas Crockford. Using nested scopes and closures, one can have real private member variables for JavaScript. For the fun of it, I tried it with Python and it works, too. At least, kind of.
Have a look at the following piece of code. In it, we create an object of Quote. Since the class has been declared in a factory method, it has access to its local variables, "txt" in this case.
Since it is not a variable of Quote itself, "txt" is not accessible from the outside. Yet, Python keeps those variables around, even after create has returned. The script delivers the following output:
Now, what about changing the value? Let us add a simple setter method.
Seems straightforward enough, but results in the following undesired output.
Apparently, Python does not use lexical scoping when doing a name lookup for write access. Instead, it creates a local variable - which is discarded the same moment the setter-method returns.
Read access works though, and we can use this for a work-around by modifying objects instead of assigning values to names.
This produces:
All things considered, this is pretty ugly. Python is all about openness, and privates are not. Also, the class definition is hidden because of a technical necessity. This is bad.
Summing it up: Nice that you can do it, but ... please don't.
(Full code here.)
Have a look at the following piece of code. In it, we create an object of Quote. Since the class has been declared in a factory method, it has access to its local variables, "txt" in this case.
def create(arg):
txt = str(arg)
class Quote:
def get_txt(self):
return txt
return Quote()
quote = create("My tables! Meet it is, I set it down, ...")
print(dir(quote))
print(quote.get_txt())
Since it is not a variable of Quote itself, "txt" is not accessible from the outside. Yet, Python keeps those variables around, even after create has returned. The script delivers the following output:
['__class__', '__delattr__', '__dict__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'get_txt']
My tables! Meet it is, I set it down, ...
Now, what about changing the value? Let us add a simple setter method.
def create(arg):
txt = str(arg)
class Quote:
def get_txt(self):
return txt
def set_text(self, quote):
txt = quote
return Quote()
hamlet = create("There is something rotten in the state of Denmark.")
print(hamlet.get_txt())
hamlet.set_text("I'll make a ghost of him who lets me.")
print(hamlet.get_txt())
Seems straightforward enough, but results in the following undesired output.
There is something rotten in the state of Denmark.
There is something rotten in the state of Denmark.
Apparently, Python does not use lexical scoping when doing a name lookup for write access. Instead, it creates a local variable - which is discarded the same moment the setter-method returns.
Read access works though, and we can use this for a work-around by modifying objects instead of assigning values to names.
class Privates:
pass
def create(arg):
privates = Privates()
setattr(privates, "txt", str(arg))
class Quote:
def get_txt(self):
return privates.txt
def set_text(self, quote):
privates.txt = quote
return Quote()
hamlet = create("There is something rotten in the state of Denmark.")
print(hamlet.get_txt())
hamlet.set_text("I'll make a ghost of him who lets me.")
print(hamlet.get_txt())
This produces:
There is something rotten in the state of Denmark.
I'll make a ghost of him who lets me.
All things considered, this is pretty ugly. Python is all about openness, and privates are not. Also, the class definition is hidden because of a technical necessity. This is bad.
Summing it up: Nice that you can do it, but ... please don't.
(Full code here.)
Sunday, August 9, 2009
Finished Profiler4j Fork
Some days ago, I started on my fork of the Profiler4j project. Now I'm done and the fork can be used. There even is documentation.
Monday, July 20, 2009
org.mockito.exceptions.misusing.UnfinishedStubbingException
Mockito is a great tool for mocking. It also showed me how readable Java code can look if done right (readable for Java code that is, of course). But every once in a while Mockito produces one of those very informative error messages and I spend some time figuring out how to avoid the mis-behaving code. (Run-time code generation ftw)
Lets have a look at an example. It "works" with Mockito 1.7. We start with the code to be tested. Have a look at the following class definition, with Opera and Hero being dummy classes. (Full source code available below)
Intuitively, CoverCreator produce a cover for a given opera. To be able to do that, it needs, among other things, call a prepare method which returns void.
To test this behavior we define a helper method that creates a mocked opera and stuffs it with another mock of type Hero. Since it is used by many tests, we don't stub any "real" methods here.
The test in question creates such a mocked Opera object and stubs the prepareToPrint() Method (to do nothing, in this case).
When run, this test produces the following UnfinishedStubbingException. The line pointed to by the exception is the highlighted one.
This is not so great, especially since it is not immediately clear, why. The argument provided to the method is definitely a mock. This can be verified in the debugger or by extracting the result of opera.getHero() manually.
The problem is that opera in this case is a mock also. At this point, mockito is somehow confused by the mocked call, which is very similar to the usual stubbing pattern when(some_mock.call()).thenReturn(some_return_value).
So, what needs to be done is to extract the mock before. And everything is fine.
Full source code here: java, pretty printed html
Lets have a look at an example. It "works" with Mockito 1.7. We start with the code to be tested. Have a look at the following class definition, with Opera and Hero being dummy classes. (Full source code available below)
static class CoverCreator {
public Cover print(Opera opera) {
// magic
opera.getHero().prepareToPrint();
// magic
return new Cover();
}
}
Intuitively, CoverCreator produce a cover for a given opera. To be able to do that, it needs, among other things, call a prepare method which returns void.
To test this behavior we define a helper method that creates a mocked opera and stuffs it with another mock of type Hero. Since it is used by many tests, we don't stub any "real" methods here.
private Opera createMockedOpera() {
Opera opera = mock(Opera.class);
Hero hero = mock(Hero.class);
when(opera.getHero()).thenReturn(hero);
return opera;
}
The test in question creates such a mocked Opera object and stubs the prepareToPrint() Method (to do nothing, in this case).
public void testFails() {
// setup
Opera opera = createMockedOpera();
doNothing().when(opera.getHero()).prepareToPrint(); <--
// run
Cover cover = new CoverCreator().print(opera);
// assert
assertNotNull("Correct input must result in a cover object!", cover);
}
When run, this test produces the following UnfinishedStubbingException. The line pointed to by the exception is the highlighted one.
org.mockito.exceptions.misusing.UnfinishedStubbingException:
Unifinished stubbing detected!
E.g. toReturn() may be missing.
Examples of correct stubbing:
when(mock.isOk()).thenReturn(true);
when(mock.isOk()).thenThrow(exception);
doThrow(exception).when(mock).someVoidMethod();
Also make sure the method is not final - you cannot stub final methods.
at UnfinishedStubbingTest.testFails(UnfinishedStubbingTest.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
This is not so great, especially since it is not immediately clear, why. The argument provided to the method is definitely a mock. This can be verified in the debugger or by extracting the result of opera.getHero() manually.
The problem is that opera in this case is a mock also. At this point, mockito is somehow confused by the mocked call, which is very similar to the usual stubbing pattern when(some_mock.call()).thenReturn(some_return_value).
So, what needs to be done is to extract the mock before. And everything is fine.
public void testSucceeds() {
// setup
Opera opera = createMockedOpera();
Hero hero = opera.getHero();
doNothing().when(hero).prepareToPrint();
// run
Cover cover = new CoverCreator().print(opera);
// assert
assertNotNull("Correct input must result in a cover object!", cover);
}
Full source code here: java, pretty printed html
Profiler4j fork
I've begun a fork of Profiler4j on github to add a few exporting and visualizing features I need.
Long live open source - as in free - software ...
Long live open source - as in free - software ...
Documentation Beyond Tests
Recently, I encountered an interesting, if twisted, interpretation of the "Tests as Documentation" principle. Reviewing some more-complicated-than-usual code, I asked the responsible colleague, if there was some documentation and, if not, that it would a be good idea to add some. He quickly responded that, of course, he'd provided good test coverage for the code at hand and since we worked under the "tests as documentation" principle it was all there. Indeed, he did write neat, compact tests, who will do their job, and still, in my opinion, he missed the point.
Coming from agile development methodologies, the idea behind this phrase is to minimize unnecessary and inflexible documentation in favor of tests. The latter are maintained anyways and ideally describe the code's behavior precisely. From my point of view, a more specific meaning depends on the kind of test we are talking about and what is documented by it.
Acceptance / customer tests belong to a class of checks, that verify on an abstract level that the system meets its business requirements. Here, the detailed implementation is irrelevant: The question is /if/ and not /how/ the business value is achieved. At this level, the documentation basically is a list of features that are hopefully of importance to someone. In case of larger systems, where there are tons of otherwise forgotton features, this is valuable knowledge.
In the area of unit tests the focus lies on documenting (and fixing) the behavior of a piece of code. By just looking at the tests, it should immediately follow what the code requires as input and what it will produce as output. This is even more so in the case of white-box tests that make the interface of the component precise. As a consequence, the test should be /readable/, in the sense that it ought to come as close to natural language as is feasible. This kind of low-level description is what my collegue meant, and he was right in the sense, that his tests did deliver this.
So, these two kinds of tests fix, define and therefore document behavior (and structures) of a system. Unfortunately, none of them considers /why/ something has been done in a particular way (or at all). Of course, this is by design - the tests do their jobs nicely. My point is, that there is knowledge, that - while absolutely essential - is not and cannot be provided by these tests alone.
Interestingly, on the business side this idea is well understood. If a company does something, there needs to be a good reason to do it and to do it this way. Each of the features that the acceptance tests verify, will be either part of a customer contract or a strategic plan from management. Requirements engineering has found nice solutions for this, e.g. user stories. Because, in the end, cost-effectiveness and accountability are of the essence.
At the level of code, this notion has not yet surfaced equally. If I see some complicated piece of code, I don't only want to know what it does, and if it does it. I want to know why we need it, why the developer chose this particular implementation, and why it must be so complicated.
I believe that the tests above are not capable nor intended to answer these important questions and plead in favor of good ol', natural language, classical documentation.
Coming from agile development methodologies, the idea behind this phrase is to minimize unnecessary and inflexible documentation in favor of tests. The latter are maintained anyways and ideally describe the code's behavior precisely. From my point of view, a more specific meaning depends on the kind of test we are talking about and what is documented by it.
Acceptance / customer tests belong to a class of checks, that verify on an abstract level that the system meets its business requirements. Here, the detailed implementation is irrelevant: The question is /if/ and not /how/ the business value is achieved. At this level, the documentation basically is a list of features that are hopefully of importance to someone. In case of larger systems, where there are tons of otherwise forgotton features, this is valuable knowledge.
In the area of unit tests the focus lies on documenting (and fixing) the behavior of a piece of code. By just looking at the tests, it should immediately follow what the code requires as input and what it will produce as output. This is even more so in the case of white-box tests that make the interface of the component precise. As a consequence, the test should be /readable/, in the sense that it ought to come as close to natural language as is feasible. This kind of low-level description is what my collegue meant, and he was right in the sense, that his tests did deliver this.
So, these two kinds of tests fix, define and therefore document behavior (and structures) of a system. Unfortunately, none of them considers /why/ something has been done in a particular way (or at all). Of course, this is by design - the tests do their jobs nicely. My point is, that there is knowledge, that - while absolutely essential - is not and cannot be provided by these tests alone.
Interestingly, on the business side this idea is well understood. If a company does something, there needs to be a good reason to do it and to do it this way. Each of the features that the acceptance tests verify, will be either part of a customer contract or a strategic plan from management. Requirements engineering has found nice solutions for this, e.g. user stories. Because, in the end, cost-effectiveness and accountability are of the essence.
At the level of code, this notion has not yet surfaced equally. If I see some complicated piece of code, I don't only want to know what it does, and if it does it. I want to know why we need it, why the developer chose this particular implementation, and why it must be so complicated.
I believe that the tests above are not capable nor intended to answer these important questions and plead in favor of good ol', natural language, classical documentation.
Tuesday, June 16, 2009
Handy Tools for Java Development
Some links to basic, but nevertheless interesting tools for java development, especially in larger projects. All of them are available as eclipse plugins.
Code quality
FindBugs: Very useful to detect (potential) bugs, deficiencies and general ugliness.
UCDetector finds code that is not referenced and therefore (possibly) not used anymore. (Even points out that something is referenced by testing code, only.) Works on classes as well as on more fine-grained levels. Also proposes to reduce visibility of structures, e.g. to make things private.
EclEmma is a java code coverage tool. This becomes a powerful utility in combination with JUnit-Tests. Running the unit-test using the coverage starter lets EclEmma analyze the tested code. After the tests complete, the code covered by your tests is visualized in the editor window. (Green for covered, red for not.) This lets you easily identify code fragments that no test ever "visited".
Testability Explorer: Reports on the testability of your classes in terms of a number. Gives a quick overview of which classes definitely need some work.
Debugging
VisualVM: Stand-alone program that allows you to connect to a running java-prog and dump its heap. The latter can then be opened for analysis, e.g. by the Memory Analyzer (see below). An interesting feature is to let VisualVM automatically dump the heap in case the program under scrutiny receives an OutOfMemoryError. This way you don't need to sit next to the screen all the time, until the memory leak occurs.
Note that you need to use the *Java 6 JDK*. Both VisualVM and the inspected program need to use it. If your default is another Java installation, then you need to point to the Java 6 JDK using the command-line argument "--jdkhome".
Memory Analyzer (MAT) does just that: It loads a heap file that might have been created by VisualVM for instance. Then, it tries to detect classes responsible for a memory leak and more. See the home page for details.
Management
Projectset: Manages dependencies between multiple projects. Takes versions / branches of VCSs into account. The adaptor to CVS is included, the ones for SVN are available from the project's homepage.
Code quality
FindBugs: Very useful to detect (potential) bugs, deficiencies and general ugliness.
UCDetector finds code that is not referenced and therefore (possibly) not used anymore. (Even points out that something is referenced by testing code, only.) Works on classes as well as on more fine-grained levels. Also proposes to reduce visibility of structures, e.g. to make things private.
EclEmma is a java code coverage tool. This becomes a powerful utility in combination with JUnit-Tests. Running the unit-test using the coverage starter lets EclEmma analyze the tested code. After the tests complete, the code covered by your tests is visualized in the editor window. (Green for covered, red for not.) This lets you easily identify code fragments that no test ever "visited".
Testability Explorer: Reports on the testability of your classes in terms of a number. Gives a quick overview of which classes definitely need some work.
Debugging
VisualVM: Stand-alone program that allows you to connect to a running java-prog and dump its heap. The latter can then be opened for analysis, e.g. by the Memory Analyzer (see below). An interesting feature is to let VisualVM automatically dump the heap in case the program under scrutiny receives an OutOfMemoryError. This way you don't need to sit next to the screen all the time, until the memory leak occurs.
Note that you need to use the *Java 6 JDK*. Both VisualVM and the inspected program need to use it. If your default is another Java installation, then you need to point to the Java 6 JDK using the command-line argument "--jdkhome".
Memory Analyzer (MAT) does just that: It loads a heap file that might have been created by VisualVM for instance. Then, it tries to detect classes responsible for a memory leak and more. See the home page for details.
Management
Projectset: Manages dependencies between multiple projects. Takes versions / branches of VCSs into account. The adaptor to CVS is included, the ones for SVN are available from the project's homepage.
Wednesday, June 3, 2009
PDDL Examples
Going to collect some examples for PDDL, problem collections from competitions, especially interesting configurations, etc.
For PDDL being the primary language of planning, there are way to little (centralized) resources on the topic, so this is my lil' contribution to help people find something and get started.
For PDDL being the primary language of planning, there are way to little (centralized) resources on the topic, so this is my lil' contribution to help people find something and get started.
Thursday, May 21, 2009
pyASP
In order to understand ASP better, because I like Python and - last but not least - because I felt like it, I started pyASP. It's a solver (or will be) for answer set programs that focuses on an easy implementation. The point is to make the principles of solver implementation easily accessible, not to provide an efficient solution. (There are plenty of solvers for that.)
The pyASP project itself can be found at github, so I can play with git as well. The project page, i.e. all the stuff that doesn't fit nicely with github, is with me.
The pyASP project itself can be found at github, so I can play with git as well. The project page, i.e. all the stuff that doesn't fit nicely with github, is with me.
Wednesday, May 20, 2009
ANTLR v3 grammar for PDDL with Python as target
I modified the grammar from Zeyn Saigol to generate Python code. More changes might be included, as I begin to parse more complex PDDL files.
The grammar can be found on my site for ASPplan, or directly here.
The grammar can be found on my site for ASPplan, or directly here.
Sunday, May 3, 2009
PyWeek 8
Two collegue students and I participated in the eighth installement of PyWeek. This is actually a lot more fun, than it sounds, with the challenge being entirely for fun, with only some loose constraints. It's all about coding a game with python in one week.
We somewhat finished in time and delivered a playable tower defense game, named "Spawnmower Lawn Defense". It's implemented using pygame.
Need to lower my Club Mate consumption to healthy levels and get back to work ...
We somewhat finished in time and delivered a playable tower defense game, named "Spawnmower Lawn Defense". It's implemented using pygame.
Need to lower my Club Mate consumption to healthy levels and get back to work ...
Monday, March 9, 2009
Rapid Prototyping and Software Engineering?
Today, somehow, I stumbled upon 3d printing, a form of Rapid Prototyping. This reminded me of a talk, delivered by Bre Pettis at 25C3 last year. Again, I began to wonder where this might not only be cool - which it undoubtfully is - but where it also could be useful. (This is not so obvious.) So, as expected, I thought about where to use rapid prototyping at work, i.e. in software engineering. And I think I've identified a spot where it might come in handy. (There are likely to be many more, and I'll post about them, if they come to mind.)
Some time ago, I had an idea to better understand where bad code eats up manpower in terms of support. I figured, given an architecture in adequate detail, it might be useful to print it on a sheet of paper and put that on a pin board. Then, using for example colored pins, we could get an impression of where problems lie. For example, one might want to remember performance bottle necks, occurrences of bugs or black holes in the code, regions that no one understands nor wants to touch.
I've been too busy studying lately to actually put this forward, but still think its a good idea. Easy to use, trivial to evaluate. The only drawback is that it really doesn't look all that nice. (There is worse, but still ...) And here comes 3d printing and saves the day.
Take a look at the following FMC diagram, depicting an architecture of a (still) fictitious browsergame.
Now imagine this as a 3d model, as architects either show them on screen or build them in miniature. The blocks (agents) would rise, the nested ones even further above, the bubbles (storages) would actually be round. Well, the channels might just pose a problem, but anyways! Using materials like polystyrene or plaster, we would be provided with a model of our system that we could make use of as discussed before. With pins, we will be able to mark hot spots and so on. Only this time, it will look cool.
Unfortunately, the 2d solution would work just as fine. So, we're back at square one, having found ourselves a neat solution (to a problem, actually) - but is it actually useful?
If I find out, I'll do another post.
Some time ago, I had an idea to better understand where bad code eats up manpower in terms of support. I figured, given an architecture in adequate detail, it might be useful to print it on a sheet of paper and put that on a pin board. Then, using for example colored pins, we could get an impression of where problems lie. For example, one might want to remember performance bottle necks, occurrences of bugs or black holes in the code, regions that no one understands nor wants to touch.
I've been too busy studying lately to actually put this forward, but still think its a good idea. Easy to use, trivial to evaluate. The only drawback is that it really doesn't look all that nice. (There is worse, but still ...) And here comes 3d printing and saves the day.
Take a look at the following FMC diagram, depicting an architecture of a (still) fictitious browsergame.
Now imagine this as a 3d model, as architects either show them on screen or build them in miniature. The blocks (agents) would rise, the nested ones even further above, the bubbles (storages) would actually be round. Well, the channels might just pose a problem, but anyways! Using materials like polystyrene or plaster, we would be provided with a model of our system that we could make use of as discussed before. With pins, we will be able to mark hot spots and so on. Only this time, it will look cool.
Unfortunately, the 2d solution would work just as fine. So, we're back at square one, having found ourselves a neat solution (to a problem, actually) - but is it actually useful?
If I find out, I'll do another post.
Subscribe to:
Posts (Atom)