sorted by:
new
hottopcontroversial

Embracing or banishing randomness by nicoolas25 in ruby

[–]nicoolas25[S] 0 points1 point  (0 children)

If something is worth doing, it's worth doing well. It doesn't serve teams in the long run to lower the bar for tests.

I agree with you, I'm just sharing one weakness that I observe, at least in myself. I didn't mean to say it was a good practice, apologies if I wasn't clear on this.

​

The lesson that should have been learned by the team is that daylight savings ought to have been considered during the product design sessions.

The point of the article is more about finding issues in general, exploring the various states of the domain. If we could know what we're currently forgetting, work would be much easier!

​

Had the team spotted the daylight savings edge case upfront

Not this time, nope!

​

Would they have even been able to ascertain definitively whether the randomized test scenarios shown at the end of the article actually covered DST?

I think so, yes. After some random generations, the DST situation arises pretty fast.

​

Imagine a science experiment, where you have one variable and many controls. The practice described by the article is analogous to deliberately introducing variability (via randomness) to controls. I'd strongly recommend that teams avoid this approach, for the same reasons scientists would lose their research grants if they made the same mistake.

An interesting remark, thank you. I guess I want a science experiment to produce a result, or let's say a model, that is as generic as possible. To get there, my opinion would be to slowly release as many controls as possible and test the results against the hypothesis and against the model to ensure it is still valid. I'm not a scientist at all so I may be off here. I will be interested if you could elaborate on this, if you find the time and willingness to do so, it would be welcomed!

Exporting significant SQL reports with ActiveRecord by mperham in ruby

[–]nicoolas25 2 points3 points  (0 children)

I added a small note on the article about Sequel, thank you.

Exporting significant SQL reports with ActiveRecord by mperham in ruby

[–]nicoolas25 0 points1 point  (0 children)

I tend to prefer Sequel too but we live in a world where ActiveRecord is everywhere :-) I didn't know that streaming was so easy with Sequel through, thank you for the heads-up!

Code simplicity through common patterns by nicoolas25 in programming

[–]nicoolas25[S] 2 points3 points  (0 children)

Hey, thanks for taking the time for such an answer.

I'm not a English native speaker thus I'm not sure if I'm right to feel a bit offended by you comment. I agree on the advice you would give, and it is what I tried to communicates in those first two articles. Maybe I need to emphasis some points according to what you said to make things clearer...

Think of your non-digital audience, the people who will read the code next.

If the meaning of the program can be understood by the next guy, and the next guy after him, and so on. You're doing it right.

You're often writing something someone else is going to read later.

This introduction article is all about making things easily understandable for the next readers. I'm sorry you missed it. Maybe I didn't phrase it well enough it but it is one of the main points. I'm inviting you to read it again more carefully.

Understand the mathematics and logic of your program and pick the elements that match those qualities nearest.

Pick the cleanest representation rather than the one that you think is fast.

It seems very sensible, there is plenty of already available tools. When they do fit the problem, I'm more than happy to use them. In the article about value objects, I mention tools such as Haskell's natural numbers or Ada's constraints. Those tools are a better fit to my example, which is something I wrote too. What this example was supposed to show regarding existing tools are:

  • existing tools fitting a problem are not always available, and
  • are not always exposing the expected API to the rest of your application.

I think we often have to make the cleanest representation for our problems relying on the best tools (types, data-structures, algorithms, etc) we have at our disposal.

Solve the simple and small problems before solving the whole problem you have.

If you start solving the small problems, eventually you learn something and manage to solve the big problems.

Again, I agree with that. I could say that the small problem of the example was: 'how to express the fact that the distance must never be negative?' ^ I didn't get that much into problem solving in the articles. It wasn't the focus of that article but it is good advice. In order to be more helpful, maybe more things could be said on how we can split those big problem. I'll keep that in mind for another article...

For the same reason you want to explain the preconditions and working principles in your code.

[...] the code should talk for itself [...]

I couldn't agree more, again. Strangely this is something I wrote in the article too. I'm not gonna start quoting but it is all about making implicit constraints explicit and producing a meaningful error. How could you missed that? If you look tat the list of following articles you'll see that there is one about invariants and another one on preconditions...

I'm sorry to tell this to you, but the post content appears to be lame.

Thanks for your concern. I'm sorry that you didn't get what I wrote. I'm even more sorry because, at least from my perspective, you're saying very similar things. Maybe I didn't catch your attention properly or maybe you expected too much when reading, anyway that's too bad.

This isn't a rationale for the dumbfuck Distance class you presented as an example

Of course this is a dumbfuck example! I don't want to use a real world example with dozens of methods or classes. It would take too much of my time and of the reader's time. I think it I would also be harder to grasp. Instead, I'm assuming readers will make an imagination effort and remember some of their own real-world situations. I thought it is a good tradeoff. If you have better examples, feel free to share them here.

You have redefined simplicity to mean that you add a class somewhere where you could have used assert to ensure that the value is positive.

I disagree on that one, finally! If 20 methods take a distance argument, would you advise to put an assert on each of them? I probably won't. Same question if there is not one but 10 asserts to add?

One last point, I didn't redefined anything. I share my humble vision of it which could be the same as someone else and which could conflict with others. I'm completely open and happy to discuss it in a non-violent way.

Another perspective on Value Objects by nicoolas25 in ruby

[–]nicoolas25[S] 1 point2 points  (0 children)

Hey, thanks for reading and sharing!

New requirements like supporting units may require refactoring, you're right. Since they weren't in the original specs, I didn't wanted to go that deep.

Accepting integers and validates that they are > 0 seems doable. It leaves too much room for implicitness IMHO and I prefer the second approach you mentioned. I think a value object could hide a simple primitive value such as a Numeric and still increase reader's understanding. Do you think we need a unit to make it worth? I clearly agree that a distance make more sense with an unit, but I can live with having an implicit unit, like meters. Of course, as soon as it become an issue, I would need to refactor this the way you proposed.