开云体育

Hello All, In case anyone is interested, here is a video in which Nat Pryce and I are doing a diamond kata at KotlinConf https://www.youtube.com/watch?v=I0OgA4OcXOY Regards, Dmitry

Right! I have found teaching a team right when (or immediately after) they run into an applicable problem is most effective and rewarding - in other words, active, hands-on coaching. After years of

Indeed! We often get *taught the solution before even experiencing the problem*. That's coming from my experience in Belgium. Where I got my drive to learn about more-than-just-working-code was from

I also like the diagram in GOOS, page 42, where the authors add an additional step, right after "write a failing test": "Make the diagnostics clear."

I’m saying spending the time upfront/real-time to make the code maintainable is faster and cheaper in the long term. Coupling directly to anything outside of the business logic -> that I found more

My team recently had to switch from Hapi to Express (or from Hapi 14 to the new version of Hapi which has some major breaking changes) because Express has a better security update policy for us. The

Faster and cheaper to program does not mean easier to maintain, especially if the long term owner of the code is maintaining dozens of applications written by different teams with different ideas

In my experience the separation of application logic and externals is much faster and cheaper than most think. Even more including any long-term benefits when things change. It’s just one of the

We should listen to our paying customers who may have some thoughts on the future of their company and their application. They may not want to pay for the extra time and effort to abstract a framework

All frameworks change eventually, or stop working when say OS version is updated. Many of us have learned that the hard way … . Inventing a new RDBMS interface – that means leaking RDBMS world

That raises an interesting general question. "The technology" is a web framework and its linked database framework. The risk of those changing in a way that breaks a lot of old code is pretty small.

I am not seeing that, but I don’t use Gmail. Could it be because of my habit of trimming quoted text?

I see it as well. I've noticed other threads being split as well. wrote:

I don't know why, but it seems this thread is completely separated, at least in my Gmail inbox, from the original Brian's one. Am I the only one seeing this? :|

So this is definitely required behavior and it will be your own, so it needs to be tested. On the other hand, it's a very specific implementation detail which could change when the technology changes

Very helpful, thanks. I'd pair with you but I don't need a cold. :) R Ron Jeffries ronjeffries.com <http://ronjeffries.com/> I'm really pissed off by what people are passing off as "agile" these days.

By the way. I’m happy to pair with people on this codebase. I’m using it to learn, and pairing would help me learn. And I do hope someday to explain what I learn, and pairing would be practice for

I hope this makes sense. I have a bad cold, and the old brain is not working well. TL;DR: You gave me the idea that the non-mocking solution to the problem would be: 1. The `put_updatable_fields`

Yes.

Hi Brian, I certainly don't know ... I'll think aloud and in terms I understand and see what happens. I know less than nothing about Elixir. I'm pretending that I just sat down to pair with you, all