Disqus - Latest Comments for r_klemme

Re: neverworkintheory.github.io: Abbreviated vs. Full-Word Identifier Names

Robert Klemme — Mon, 04 Dec 2017 11:22:19 -0000

Interesting! It seems, specific terms evoke ideas and probably form mental expectations which lead to some things not being looked at. The abbreviation is more cryptic and needs more brain CPU to process so people seem to resort to a more methodical problem detection process.

On the flip side: I guess, if "named" code does exactly what it advertises, then it can be read and comprehended much faster. So neither is better than the other but it depends on the trade offs we want to make.

Re: 10 frequently asked Java Interview Questions | Tuturself.com | Tutu'rself

Robert Klemme — Sat, 15 Oct 2016 16:10:18 -0000

Now you made item 4 identical to 2. I would define "abstract class" like this
1. (as above)
2. In contrast to a regular class can contain any number of abstract methods (including zero).
3. In contrast to a regular class cannot be instantiated.

Other than that it has the same properties as a regular class.

Re: 10 frequently asked Java Interview Questions | Tuturself.com | Tutu'rself

Robert Klemme — Sat, 15 Oct 2016 11:34:49 -0000

"5. It doesn’t support multiple inheritance, whereas an abstract class does." That sentence does not make sense in this context.

Re: What is the difference between a Process and a Thread? | Tutu'rself

Robert Klemme — Sat, 15 Oct 2016 10:27:17 -0000

"But the heap is not thread-safe and must be synchronized for thread safety." There are multiple ways to achieve thread safety and synchronization access to the variable is not a requirement. The most obvious way is if object 1's methods do synchronization internally where needed (e.g. Vector, ConcurrentHashMap). Another case is immutable data structures.

Re: What is the difference between a Process and a Thread? | Tutu'rself

Robert Klemme — Sat, 15 Oct 2016 05:00:39 -0000

"When a method is called then a thread is automatically created to execute the method." This is plain wrong.

"And all the local variables of a method are stored in that stack and are kept thread safe from other threads." This is technically correct but misleading in Java world since most variables are references to objects on the heap. Only variables of primitive data types are actually thread safe (more precisely: thread local) on the heap.

Re: The Ruby Community and Reputation | AkitaOnRails.com

Robert Klemme — Sun, 21 Aug 2016 07:00:37 -0000

I think it has not become clear what I meant. I was talking about this three step approach in general. And the more freedom you have in step 1, the more painful architecture errors are which are detected later. When using a framework many / most architectural decisions have been done already so that limits the freedom (these are the "rails") and as well the architectural mistakes you can do. That still does not protect against the discovery "Oh, we picked the wrong framework because it targets a completely different class of applications than the one we need to build."

Then, the comparison with Rails was just with regard to the extremism of like and dislike and the general trend in our industry (or maybe even more globally) to oscillate between "awesome" (a word I have grown to hate because of it its indiscriminate overuse) and "sucks".

Re: The Ruby Community and Reputation | AkitaOnRails.com

Robert Klemme — Fri, 19 Aug 2016 15:17:49 -0000

> The strategy is definitely:
> Make it work,
> Then make it right,
> and, finally, make it fast.

Yes, but there is a large grain of salt to apply: if you take the wrong architectural decisions in step one, at the time you get to step three it might be too late - or you pay a tremendous price. How big the risk is, of course depends on the application at hand. I am just always cautious when I see these seemingly simple recipes to success - probably because I have seen them applied mindlessly too often.

Actually there is a similarity between these recipes and software like Rails: people tend to be total fans or hate it and by doing that they forget that everything has its two sides and all software has strengths and weaknesses - and often there are good reasons for them. I find these heated debates boring because they often digress so far from the factual level into opinion land that they are not even useful at highlighting pros and cons any more. The just serve to illustrate gullibility of human beings.

Re: Printer: Canon MG5350 | OpenPrinting - The Linux Foundation

Robert Klemme — Fri, 19 Feb 2016 11:01:44 -0000

For me the printer works well - printing and scanning via network.

Re: Der Postillon: Handspiel in der 33. Minute: Wird Deutschland jetzt der EM-Titel aberkannt?#more#more

Robert Klemme — Mon, 01 Feb 2016 13:17:27 -0000

So schlechte Augen? Wow!

Re: Der Postillon: Handspiel in der 33. Minute: Wird Deutschland jetzt der EM-Titel aberkannt?#more#more

Robert Klemme — Mon, 01 Feb 2016 11:47:43 -0000

Jodeldidö oder Jodeldida?

Re: Der Postillon: Handspiel in der 33. Minute: Wird Deutschland jetzt der EM-Titel aberkannt?#more#more

Robert Klemme — Mon, 01 Feb 2016 11:46:43 -0000

Kann nicht sein: Postillon ist eine absolut vertrauenswürdige Nachrichtenquelle. Oder willst Du etwa behaupten, dass RT dahinter steckt?

Re: Der Postillon: Handspiel in der 33. Minute: Wird Deutschland jetzt der EM-Titel aberkannt?#more#more

Robert Klemme — Mon, 01 Feb 2016 11:17:34 -0000

Das geht gar nicht! Wird jetzt echt so langsam mal Zeit für den Videobeweis im Handball!

Re: Ruby Best Practices - Full Book Now Available For Free!

Robert Klemme — Sat, 10 Oct 2015 06:48:06 -0000

Can you please be more specific which links are broken? I tried various links and so far none was broken.

Re: Ruby Best Practices - The Double Dispatch Dance

Robert Klemme — Wed, 22 Apr 2015 14:21:40 -0000

As soon as two types are needed in order to decide which code must be executed you have double dispatch. How that is technically solved is another question.

Re: Wie glaubwürdig ist Varoufakis noch?

Robert Klemme — Mon, 16 Mar 2015 08:14:42 -0000

Dass jemand ein Interesse an etwas hat, bedeutet ja nicht automatisch, dass es auch passiert.

Ich mache mit bei Herrn Varoufakis eher an anderer Stelle mehr Sorgen um seine Glaubwürdigkeit: offensichtlich kommt er ja nicht mit Sanierungskonzepten zum abgesprochenen Zeitpunkt über und was er vorlegt, hat nicht sehr viel Hand und Fuß, nach allem, was ich so sehe.

Re: 4 Essential Lessons for Your Self-Improvement

Robert Klemme — Mon, 26 Jan 2015 08:40:01 -0000

I believe the pendulum has swung too far to the self optimization side. We are _not_ programs, not even machines. Putting the pressure on everybody to constantly self improve will and does have an adverse effect. For example, for item 1 precondition is that you are not satisfied with yourself. That is a big door for self-doubt and insecurity. Look at all these teenagers who suffer from eating disorders - that's a direct consequence of the self improvement program broadcasted everywhere - and especially in advertising.

Note that I do not say, you should not improve! But there is a fine line between healthy improvement and the never ending struggle towards perfection that haunts so many fellow humans.

Re: Ruby Best Practices - LRU Integration explained

Robert Klemme — Fri, 05 Dec 2014 08:46:13 -0000

Thank you! You are very welcome.

Re: Class: Array (Ruby 2.1.1)

Robert Klemme — Fri, 07 Nov 2014 07:40:57 -0000

Surprising as it may seem to you people using Ruby do not take an issue with this. We even value it as a strength (-> duck typing). If you think Ruby's dynamic nature is a design flaw then you will probably be more happy with a different language.

Of course you can "fix" this by introducing static typing into Ruby. I will assume though that the result will have very few resemblance to Ruby.

Oh, and btw: even in statically typed languages you do not know what methods actually do. Define an interface in Java, create a method with such a beast as argument which invokes methods defined in the interface. The situation with Eiffel may be a bit better with pre and post conditions being automatically checked. In practice this additional level of safety does not seem all that important.

Re: Does Task Automation Improve Code Reviews?

Robert Klemme — Thu, 12 Jun 2014 09:10:39 -0000

But: if the file is linted, there are some classes of issues you do not have to look for during the code review. And: if you look at the test while doing the code review it might be easier to spot the potential issues to look for by thinking about which tests might be missing or what feature might not be tested.

Re: Practicing Ruby - Issue #15: Duck Typing in Practice (2 of 2)

Robert Klemme — Mon, 26 May 2014 09:35:48 -0000

Yes, absolutely. Good catch!

Re: Practicing Ruby - Issue #8: Uses for Modules (1 of 4)

Robert Klemme — Mon, 28 Apr 2014 09:38:22 -0000

Yep! That looks like an even better approach for the use case of only methods. However, if you also want to define classes or modules int that very namespace you will need to use a module (or class).

Re: Practicing Ruby - Issue #8: Uses for Modules (1 of 4)

Robert Klemme — Mon, 28 Apr 2014 02:29:03 -0000

I've shown above that the module itself as well as any class including (or instance extending) it will carry state. There is nothing particular about instance or singleton methods that would make the instance immutable. It's the specific implementation (i.e. not modifying instance variables) that creates an immutable.

To complete the example from above:

irb(main):001:0> module M
irb(main):002:1> extend self
irb(main):003:1> attr_accessor :foo
irb(main):004:1> end
=> nil
irb(main):005:0> class C
irb(main):006:1> include M
irb(main):007:1> end
=> C
irb(main):008:0> c = C.new
=> #<c:0x00000002230be8>
irb(main):009:0> c.foo
=> nil
irb(main):010:0> c.foo = 99
=> 99
irb(main):011:0> c.foo
=> 99
irb(main):012:0> c.instance_variables
=> [:@foo]

My point is that be doing "extend self" you end with a module that has a bunch of singleton methods (the one that you primarily intend to use) but can also be included in a class or used to extend an object (which is inclusion in the singleton class). I prefer to do exactly one OR the other - but not both at the same time. The reason is clarity. Both uses are different concepts and I like to keep things separate to reduce potential confusion and errors.

Re: Practicing Ruby - Issue #8: Uses for Modules (1 of 4)

Robert Klemme — Sun, 27 Apr 2014 18:00:51 -0000

Probably I wasn't making myself clear enough.

irb(main):001:0> module M
irb(main):002:1> extend self
irb(main):003:1> attr_accessor :foo
irb(main):004:1> end
=> nil
irb(main):005:0> M.foo = 123
=> 123
irb(main):006:0> M.foo
=> 123
irb(main):007:0> o = Object.new.extend M
=> #<object:0x00000001220a00>
irb(main):008:0> o.foo = 456
=> 456
irb(main):009:0> o.foo
=> 456
irb(main):010:0> M.instance_methods(false)
=> [:foo, :foo=]
irb(main):011:0> M.singleton_methods
=> [:foo, :foo=]

See, M contains instance methods foo= and foo as well as the same pair as singleton methods. And there is nothing immutable.

Re: Practicing Ruby - Issue #8: Uses for Modules (1 of 4)

Robert Klemme — Sun, 27 Apr 2014 17:54:09 -0000

Well, I find it more ugly that your approach essentially defines instance methods and singleton methods at the same time. I rather spend the effort of that bit of extra typing. The important part is the reading of the code (as I've written elsewhere) - not the writing. If you read "def self.foo" all the time you know immediately that the module is used as a namespace for "functions" while the "extend self" at the top can be easily overlooked.

Re: Practicing Ruby - Issue #8: Uses for Modules (1 of 4)

Robert Klemme — Sun, 27 Apr 2014 11:48:08 -0000

You do not need "extend self" here:

irb(main):001:0> module Thingi
irb(main):002:1> def self.do_this(x) puts "foo #{x}" end
irb(main):003:1> end
=> nil
irb(main):004:0> Thingi.do_this "bar"
foo bar
=> nil

I prefer to either define methods on the module instance OR define instance methods. Your "extend self" trick does both and you can still mix in the module somewhere.