Comments for ilker.de http://ilker.de Creative Computing. Tue, 31 Jan 2012 12:27:32 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on Tool Me Under! by Sebastian M http://ilker.de/tool-me-under#comment-15336 Sebastian M Tue, 31 Jan 2012 12:27:32 +0000 http://ilker.de/?p=3195#comment-15336 Hey Ilker! Thanks for your great blog, but this post ... I don't get it! Software development nowadays is so much easier and more comfortable than some years ago. Why? Because of those great tools, plugins, hardware! Why should I put so much effort in my tool I am using to solve my problems, when the tool my collegue is using, does it a lot easier? Because of this reason I always want the best tools! Hey Ilker!
Thanks for your great blog, but this post … I don’t get it! Software development nowadays is so much easier and more comfortable than some years ago. Why? Because of those great tools, plugins, hardware!
Why should I put so much effort in my tool I am using to solve my problems, when the tool my collegue is using, does it a lot easier? Because of this reason I always want the best tools!

]]> Comment on Tool Me Under! by Björn Rochel http://ilker.de/tool-me-under#comment-15123 Björn Rochel Wed, 25 Jan 2012 08:53:08 +0000 http://ilker.de/?p=3195#comment-15123 As always, nice post. I'd like to add an additional perspective on the tools topic, though: Deliberate improvement. Personally I think of tools as supporting cast. I tend to change tools in my day to day work, whenever I get the impression that there're things that could be done with another tool more efficiently (or when I only use a small set of features and don't need the rest and there's a slimmer alternative). Then I try to work with the new tool for a fixed timebox and evaluate whether my expectations were met. If so I tend to stick with the new tool. If not I revert my decision.I've done this with all kinds of things in the past: shells, editors, testrunners, mock-frameworks and have been pretty happy with that so far. Last one was 1 week with Sublimetext2 instead of VIM. Reverted to VIM afterwards since the whole benefit of Sublimetext2 was only shiny UI for me. Cheerio Björn As always, nice post. I’d like to add an additional perspective on the tools topic, though: Deliberate improvement. Personally I think of tools as supporting cast. I tend to change tools in my day to day work, whenever I get the impression that there’re things that could be done with another tool more efficiently (or when I only use a small set of features and don’t need the rest and there’s a slimmer alternative). Then I try to work with the new tool for a fixed timebox and evaluate whether my expectations were met. If so I tend to stick with the new tool. If not I revert my decision.I’ve done this with all kinds of things in the past: shells, editors, testrunners, mock-frameworks and have been pretty happy with that so far. Last one was 1 week with Sublimetext2 instead of VIM. Reverted to VIM afterwards since the whole benefit of Sublimetext2 was only shiny UI for me.

Cheerio
Björn

]]> Comment on The Quest Of The Test by Steffen Forkmann http://ilker.de/the-quest-of-the-test#comment-15004 Steffen Forkmann Sun, 22 Jan 2012 12:03:23 +0000 http://ilker.de/?p=2759#comment-15004 Hi Ilker, I tried to port your solution to F# (http://www.navision-blog.de/2012/01/22/f-legacy-test-implants/). What do you think? Cheers, Steffen Hi Ilker,

I tried to port your solution to F# (http://www.navision-blog.de/2012/01/22/f-legacy-test-implants/).
What do you think?

Cheers,
Steffen

]]> Comment on The Quest Of The Test by F# Legacy: Test implants » Rash thoughts about .NET, C#, F# and Dynamics NAV. http://ilker.de/the-quest-of-the-test#comment-15002 F# Legacy: Test implants » Rash thoughts about .NET, C#, F# and Dynamics NAV. Sun, 22 Jan 2012 11:52:26 +0000 http://ilker.de/?p=2759#comment-15002 [...] super awesome Ilker Cetinkaya published an excellent article about “test implants”. I really recommend you to read this post before you read this one. It’s a really well written [...] [...] super awesome Ilker Cetinkaya published an excellent article about “test implants”. I really recommend you to read this post before you read this one. It’s a really well written [...]

]]> Comment on About by F# Legacy: Test implants » Rash thoughts about .NET, C#, F# and Dynamics NAV. http://ilker.de/about#comment-15001 F# Legacy: Test implants » Rash thoughts about .NET, C#, F# and Dynamics NAV. Sun, 22 Jan 2012 11:52:03 +0000 http://www.gmbsg.com/?page_id=470#comment-15001 [...] code is a problem in all languages, even F#.  Ilker Cetinkaya published an excellent article about “test implants”. I really recommend you to read this post [...] [...] code is a problem in all languages, even F#.  Ilker Cetinkaya published an excellent article about “test implants”. I really recommend you to read this post [...]

]]> Comment on The Quest Of The Test by Sergey Shishkin http://ilker.de/the-quest-of-the-test#comment-14981 Sergey Shishkin Sat, 21 Jan 2012 23:50:43 +0000 http://ilker.de/?p=2759#comment-14981 This reminded me of an idea of a legacy code-retreat, though I didn't attend one. Would also be a great idea for a coding dojo: take some brownfield code and fix a bug in it or implement a new feature. This reminded me of an idea of a legacy code-retreat, though I didn’t attend one. Would also be a great idea for a coding dojo: take some brownfield code and fix a bug in it or implement a new feature.

]]> Comment on The Quest Of The Test by Ilker Cetinkaya http://ilker.de/the-quest-of-the-test#comment-14979 Ilker Cetinkaya Sat, 21 Jan 2012 23:05:22 +0000 http://ilker.de/?p=2759#comment-14979 This is a fictional story. Apart of that, the SUT is a brownfield with a bug. The lambda implant just enables to - well, sort of - verify that the issue has been addressed. No more, no less. I agree with you that this ideally would be the first step on a series of refactorings which would ultimately lead to interfacing the 3rd party service. This is a fictional story. Apart of that, the SUT is a brownfield with a bug. The lambda implant just enables to – well, sort of – verify that the issue has been addressed. No more, no less. I agree with you that this ideally would be the first step on a series of refactorings which would ultimately lead to interfacing the 3rd party service.

]]> Comment on The Quest Of The Test by Sergey Shishkin http://ilker.de/the-quest-of-the-test#comment-14977 Sergey Shishkin Sat, 21 Jan 2012 22:40:30 +0000 http://ilker.de/?p=2759#comment-14977 Creative idea, bit looks like a hack to me. Please, don't call me Fred though :) Why wouldn't you take more time and write more functional tests for the Chronograph and isolate the remote 3rd party service through refactoring. From my perspective the fact that a particular method of a component was called is an implementation detail and thus is not a good name for a test. Creative idea, bit looks like a hack to me. Please, don’t call me Fred though :)

Why wouldn’t you take more time and write more functional tests for the Chronograph and isolate the remote 3rd party service through refactoring. From my perspective the fact that a particular method of a component was called is an implementation detail and thus is not a good name for a test.

]]> Comment on Context In Model Is Evil by Ilker Cetinkaya http://ilker.de/context-in-model-is-evil#comment-14969 Ilker Cetinkaya Sat, 21 Jan 2012 10:18:28 +0000 http://ilker.de/?p=3007#comment-14969 Steve, was ist denn in dem HTTPContext alles drin? Ein Request, eine Response, ein User, eine Session uvm. Bei so vielen Verantwortlichkeiten bleibt einem ja gar keine andere Wahl, als so eine "Sammlung" von HTTP-Zeug auch HTTPContext zu nennen. Man könnte es auch gleich in HTTPZeugs umbennenen und es wäre genau so aussagekräftig. Hätte MSFT nicht so viel weiteres Zeug zum Request/Response dazugepackt, wäre es einfacher gewesen, einen passenden Namen zu finden. Spontan fällt mir z.B. "HTTPChannel", "HTTPCommunication" oder "HTTPDialog" ein. Natürlich ist es besonders im Framework-Bereich nicht einfach das passende Gleichgewicht zwischen angepasster Granularität der Klassen und expliziten Verantwortlichkeiten zu finden. Dennoch: wenn etwas "Kontext" heisst, dann hat es für mich schon den Smell, dass der Autor entweder nicht gut genug über das Design nachgedacht hat, oder dass man sich mit dem Kontext ein Sammelsurium an konzentrierten Verantwortlichkeiten erkauft. Als geringstes Übel - aber dennoch Übel - sehe ich es noch, wenn ein Kontext als bessere Hashmap zum tragen von State durch die halbe Anwendungslandschaft geschliffen wird. Steve,

was ist denn in dem HTTPContext alles drin? Ein Request, eine Response, ein User, eine Session uvm. Bei so vielen Verantwortlichkeiten bleibt einem ja gar keine andere Wahl, als so eine “Sammlung” von HTTP-Zeug auch HTTPContext zu nennen. Man könnte es auch gleich in HTTPZeugs umbennenen und es wäre genau so aussagekräftig.

Hätte MSFT nicht so viel weiteres Zeug zum Request/Response dazugepackt, wäre es einfacher gewesen, einen passenden Namen zu finden. Spontan fällt mir z.B. “HTTPChannel”, “HTTPCommunication” oder “HTTPDialog” ein.

Natürlich ist es besonders im Framework-Bereich nicht einfach das passende Gleichgewicht zwischen angepasster Granularität der Klassen und expliziten Verantwortlichkeiten zu finden. Dennoch: wenn etwas “Kontext” heisst, dann hat es für mich schon den Smell, dass der Autor entweder nicht gut genug über das Design nachgedacht hat, oder dass man sich mit dem Kontext ein Sammelsurium an konzentrierten Verantwortlichkeiten erkauft. Als geringstes Übel – aber dennoch Übel – sehe ich es noch, wenn ein Kontext als bessere Hashmap zum tragen von State durch die halbe Anwendungslandschaft geschliffen wird.

]]> Comment on Context In Model Is Evil by Steve Wagner http://ilker.de/context-in-model-is-evil#comment-14901 Steve Wagner Thu, 19 Jan 2012 10:01:04 +0000 http://ilker.de/?p=3007#comment-14901 Und wir würdest du dann so etwas wie den HTTPContext benennen? Oder wie würdest du dies anders lösen? Und wir würdest du dann so etwas wie den HTTPContext benennen? Oder wie würdest du dies anders lösen?

]]>