Відео

My experience has been that for tasks that I know how to do, AI is a bit frustrating. And I know how to do the majority of tasks in my projects. But others are reporting significant productivity gains, and frustration is often a function of lack of experience, so I’m trying to work through to find the sweet spot.

Thank you! More interesting chat about chat to come.

I appreciate the feedback. I’m trying to feature more actual pairing on the channel, but in the meantime there are quite a few with Dmitry to enjoy

I'll put details in the shownotes too

I did warn you in the introduction!

@@PairingWithDuncan You did.

It's certainly nice to have options, and I've learned a lot by using it.

That’s really useful to know, thank you

So many people I respect report having such good results that I think I must be doing something wrong. Maybe my coding style, choice of language and libraries is just not conducive to AI assistance, or maybe I’m just not patient enough. I hope Stephan will help me work out which.

Me too!

Thank you. How is AI affecting project management?

Thanks for the encouragement - it’s great to hear when people like what I do.

That’s lovely to know, thank you.

Thank you

I don’t plan to change the formula, just the branding. But, sneak peak, next week will be looking at the Devoxx Genie AI plug-in

It’s good to be appreciated, thank you.

Thanks for the encouragement!

There seems to be movement, with both Gradle and JetBrains experimenting with more declarative tools, but you have to really want to be a developer to put up with what we have.

That’s an excellent question, thank you. Personally I find map, filter and reduce come naturally, but fold not so much. I still think in terms of mutation like we did here in the repeat loop, and then once things are working look to remove the mutation, which often involves a fold. But it has taken me a few years of functional head-scratching to see the patterns. If as a team you work to remove mutations, even of local variables or collections, then both the code and the team will naturally become more functional together.

That’s helpful thank you. I still struggle to like Kotest, and changing frameworks just to add property based tests to a codebase is increases the cost of adding them, but I appreciate that many don’t share my opinion. Maybe I should find a way to make a video about it to learn more.

@@PairingWithDuncan I'm pretty sure you don't have to adopt all of Kotest just for the property testing... also in Kotest there's Data-driven testing which is also pretty nice when you just need to create a bunch a situations doing the same thing and don't want to have to create a test for each one separately... It's somewhat like a table of inputs and expecteds.

I suppose that the perceived and actual cost of adoption of a technology is different for everyone as their experience is different, as is the perceived and actual benefit of adoption.

Thank you! The problem with dark and my eyes at least is not contrast but that the pupils dilate to bring in more light, which means that depth of field is lower, which leads to focusing problems.

@@PairingWithDuncan That's interesting. I never noticed lower depth of field. For me (approaching 60) it's more about bright backgrounds washing out text.

That's interesting! When I find trouble reading I always turn the brightness up - I guess that would make things worse for you.

Thanks for a very interesting question. I don't have any philosophical issues with testing private methods. If I can test everything that I want to test through the public interface I will, but otherwise 1. If the private function might be useful later, helps understand what I'm thinking, and isn't revealing things that I really want to hide, then hey, public is fine 2. I do think twice about making things public for test if I'm publishing public libraries. I don't want to not be able to change things because people have started using them and I can't change their code. 3. Inside a company though I can often change functions and just fix up all the callers, so that again means I can care less. 4. If a function really is an implementation detail so should not be public, but it's still convenient to write tests for it, then 'internal' visbility is great. 5. Sometimes we can improve our designs by listening following a rule of not testing through effectively private or internal functions, but we can also make things more complicated, so taste is required. Does that help?

The problem is that, with old eyes, I can’t see dark mode!

@@PairingWithDuncan Haha all good!

Light theme feels so comfy for me, like reading a book

@razvanfilip3735 Curse you - I’ve literally just started recording this week in dark mode to see how it goes!

@@PairingWithDuncan haha goodluck!

Indeed, but at this point I’m trying to point out actions when we have them, and for loops are pretty actiony. I suppose more so in C where we have to write our own ;I++

Thank you, I’m glad it’s useful

Thank you, and yes to your question. You can also capture stderr if you want to see error messages.

Thank you. I have had some very good teachers over the years and hope to pass on what I learned while humans still do this job.

I’m not going to disagree; but… …I’ve never been on a project where all requirements are tested in acceptance tests. In practice this would just be too painful to run, especially for non-happy path tests where we may need to mock systems in order to show the behaviour. We might if feeling pedantic mark some unit-level tests as showing acceptance, but I’ve never felt the benefit was worth the hassle. And, it’s late here so I’m a bit slow, what requirements are not covered by the unit tests?

@@PairingWithDuncan from 21..98 aren't covered. But I agree, I've always felt that pinch that I had to write acceptance tests to cover all the requirements, but in the real world, I only ended up ever writing integration and unit tests... changing the definition of acceptance testing was new for me (what you showed in this video...), but I'm really wondering where to draw the line, especially in a real world project where things tend to be MUCH more complex. Also it seems you didn't write all the acceptance criteria in the beginning, is that what you would recommend?

Ah interesting. Acceptance tests can't possibly cover all cases. Well, I mean, they could in this case, but we don't test that we can create an account with every possible name. We pick examples and say that if it works for these, it works. So to my mind, examples up to 21 cover the space adequately, with perhaps the additional check that there are 100 results. If I had a product owner, or their QA proxy, who wanted to work to define all the edge cases up-front, then writing all the acceptance criteria at the beginning is good. But how we actually implement the test may change as we implement the implementation - this is an area where Cucumber shines as it decouples the acceptance language from the implementation. In practice though I find that the best is the enemy of the good. Write enough acceptance criteria to get moving - the ones that are obvious. As soon as they become harder to dream up, switch into implementation because the understanding of the domain that code brings will lead to more criteria. Some of those (eg the empty case) may not be acceptance tests, because the spec says 100 lines, but lead to better internal quality and communication to future developers about my mental model.

I don’t think it’s silly, and I wondered about it when I was editing. It might even work out as fast as the long version by the time Hotspot has had a look.

You’re tempting me into a series dammit. There’s a property based version in my head too, and a refactor to a list of predicates to phrases.

Thanks for the suggestion. I assume you mean having the client reuse connections with Keep-Alive? I have been wondering about this, and given that the errors seem to be in making the connection it would have an effect. I suppose that I was trying to gauge how many different clients we can support, not how many requests a smaller number of clients can make.

Duncan, indeed. Both clients have options for connection pooling. That would at least eliminate the network factor and allow us to focus on testing the server stack and application logic.

🤔that’s a persuasive argument. Given that it’s only really differences between Ktor and http4k that I’m interested in, I guess they will not have any clue that requests have been piggybacking on existing connections. Something to investigate for next week thank you.

So a little digging reveals that okhttp pools connections by default. How that works in practice I'm not sure. I _assume_ that it will create a new connection if it needs to because an existing one is still waiting for a response, but it's hard to tell.

@RefactoringDuncan in case of connection pooling open handles limit should not expire.

Thank you. I’m pretty much better now.

I’m not sure it’s that simple, but I do think that it isn’t currently right! The observed behaviour is not simple oscillation, largely I think because other processes can be taking resources and cause errors for a given rate at one time but not another.

Thanks for the review; but I don't think that we have problem there. Firstly we only ever initialise the variable, we don't mutate it. And secondly the variables in runLots are only visible to one thread, the one that is running the test. Actually that second is not completely true, as code in the Callables is run on the executor threads, but that code doesn't access startTimeMs. It does mutate the errors list, which is why we have to make that a thread-safe class. I think! With any multi-threaded code I know that I'm only a single logic-failure away from being completely wrong. As it happens I've just refactored that code, removing the retries and simplifying it a lot. Watch this space on Friday!

Ooh good catch! Reflection is full of these little gotchas. Somewhere in the back of my mind when I was writing the code I was wondering about the implications of Map<K, V?> and how you tell the difference between not there and there but null. I should have listened to that voice.

I think this fixes it val invocationHandler = this.getOrElse(method) { error("No implementation for method $method") } ?: error("Bad default logic for method $method") invocationHandler.invoke(args ?: emptyArray<Any>())

@@PairingWithDuncan sweet! Really enjoying your videos ❤️

Thank you, it’s nice to have somewhere to play and share the joy of it.

I hope you find it useful

also, in my setup fastFun with loom Jetty is consistently slower than the normal ..🤔

Mine is an M2 MacBook Air. Given the saturation I’m seeing I don’t think that the processor should make a difference, but maybe the cores are an issue. Are you seeing the same behaviour where you get a cascade of errors?

@@PairingWithDuncan no I had no errors

@nicolafarina1544 I really wish I didn’t. I think all bets are off all the time we are getting them. I’m hoping that they go away when I slow down the responses- watch this space.

Thanks for your kind words. In testing we might use a proxy in place of a production object because it is easier to set up, or doesn’t launch missiles or somesuch - these are mock objects. In a couple of episodes’ time I think we will use a proxy that just slows down requests to the InMemoryCustomers in order to help test throughput. There are lots of places where we might want to augment existing functionality - see the decorator pattern.

You are welcome! handlerFor is developed in the previous couple of episodes - starting at Refactoring to Higher-Order Functions - Creating a declarative API for http4k ua-cam.com/video/I4NRT--Bj3Q/v-deo.html

I’m pleased you found it useful.

I would have said sick job, but thank you

Hmm, good question - it's led me to some experimentation. Is your suggestion that getDeclaredMethod would prevent us from having to trawl the supertypes, or that we should trawl the supertypes, but use getDeclaredMethod on each?

@@PairingWithDuncan Former. Check it out, let me know if I was wrong

I’m afraid that you are, but I had to check! getDeclaredMethods specifically doesn’t look in supertypes.

I could call getDeclaredMethod on each type in the hierarchy, which would avoid getDeclaredMethod looking up the type hierarchy, but I suspect that I’ve accidentally done the right thing.

@@PairingWithDuncan not the first time I was wrong 😁

Thank you. I’m pulling through!

Wow, that’s a bit extreme. Even if you would rather be writing something else, without Java there would be no JetBrains or Kotlin! Personally I find the language itself to be frustrating these days, but the JVM is an amazing technology and often the right tool for the job.

I also don't use Java anymore, but it's a bit daft to diss it so much. If it was that bad it wouldn't have been the biggest language in the world for fifteen years. Duncan, how's it going? We used to work together at Sony with Richard Care. Jim Morrison. Great channel by the way.

@jimmorrison2657 Wow blast from the past! I was, coincidentally, just chatting with Richard when I saw your message.

@@PairingWithDuncan Aha, ok nice one. That's good to hear. All the best!!

You can get away with the one passed to the invocation handler if your wrapped object implements the interface, but not otherwise?

@@PairingWithDuncan Right - that makes sense - and because we were faking the structural subtyping you needed to look up the method from one interface into the other interface. Makes sense now!

Next week's video shows that sometimes we have to look harder, down the back of the sofa, inside shoes, all sorts of places.

Thank you. I have a big bike ride planned this summer, so there will be more cycle attire!

@@PairingWithDuncan enjoy! And thank you for these videos. They are a great way to see another developer’s workflow and thought process.

I think you’re right, and I’ve heard of other codebases with the same policy. Which is a real shame, because suspend functions are definitely harder to test and I assume less efficient to call. I wonder if, if they had their time again, the language designers would have made suspend a context, with special compiler handling, but at least passing the hidden CoroutineContext that way. Is there not a refactor to propagate suspend up the call hierarchy when you find you need it?

@@PairingWithDuncan I don't think passing the context would be enough since suspend functions are either compiled to a state machine or to continuations (I work mostly with C# where state machines are used, not sure about Kotlin). In C#, once you find something `async` you either force it to be sync (losing the benefits of async in the first place), our you need to propagate the async all the way to `main`. In my experience the best thing is to just start with `async`/`suspend` from main and move on. In languages like Scala or Haskell you can abstract this away since you have access to "generics of generics" (aka higher kinded types), allowing you to write interfaces where the methods/functions are parametrized over some "context" (ex. `fun foo(s: String) -> m Int`, where `m` can be a sync/async context)

Kotlin compiles suspend to a state machine too, that’s the special compiler handling that would have to come with the context. As I understand it, that means that every invocation of a suspend function from a suspend function requires the extra code, which means that we pay a performance and code size price. Kotlin’s context receivers, (soon, irritatingly, to be context parameters) will allow us to pass the async context kind of implicitly, but given the state machine issue, that doesn’t really help to generalise the calling, as you say.

I agree Kotlin has no way to abstract over function 'coloring'. In my mind, this is a good argument for http4k over ktor. Ktor is more complicated than http4k but in most cases there's no practical benefit.

Certainly - its github.com/dmcg/ktor-documentation