Junilu Lacar

4. Using .also scope function for inline debugging statements

If I format them right, I can use IDEA's rectangular (column-wise) selection feature to easily add debugging statements:
   fun part2(input: List<String>): Int =        input               .also { "input -> $it".println() }          .asCards()        .also { "asCards() -> $it".println() }          .processWins()    .also { "processWins() -> $it".println() }          .sum()
When I don't need them, I just rectangular highlight the .also parts and delete or comment them out.

Just did this for Day 4 Part 2, which I just got done solving.

Who needs sleep when you can code in Kotlin all night!  

Having lots of fun re-upping my Kotlin skills with this year's AoC.

Here are some things I've done that I think are shareable.

1. Testing without JUnit - I'm trying to avoid using JUnit and just testing with check(), like so:
   val expected = 30  // as stated in puzzle's example    val actual = part2(testExample1)    check(expected == actual) {        """            FAILED Part 2            input -> $testExample1            expected [$expected]            but got  [$actual]        """.trimIndent()    }

I just discovered the check() has a lazyMessage parameter, which is nice. At some point I might cave and start using JUnit but doing this still helps me do TDD well enough.

2. Declarative/functional programming is nice!

I'm starting to settle on a problem-solving approach that's kind of "bass ackwards" but very much in line with TDD philosophy: Start with the end in mind. I'm working on Day 4 Part 2 right now and here's what I started writing:
fun part2(input: List<String>) =   input              // take the input      .asCards()      // parse to a list of Cards      .processWins()  // process the winning cards      .sum()          // how many cards we end up with
That's it. To get the answer, I work my way backwards and implement each of these steps, breaking each one down into smaller problems when necessary.

3. Kotlin makes it easy to create DSLs (Domain Specific Languages)

Extension functions really help for declarative/functional programming. Here's what the asCards() function ended up being:
fun List<String>.asCards(): List<ScratchCard> = map { ScratchCard.of(it) }
and ScratchCard is a data class with the of() factory function/method as a part of its companion object. This does the heavy lifting of parsing the input.

There are a few more things I'm playing around with but this is getting long and I have to get back to solving Day 4 Part 2. I'm falling way behind with all the reflection and playing around that I'm doing, but it's fun.

Darcy DeClute wrote:

Junilu Lacar wrote:Apologies for the contrarian tone...

I always find it is best to support people and encourage others when they are interested in pursuing a new career path, and I'd never discourage anyone from pursuing an accreditation in the field of their choosing.

Please don't get me wrong, I have nothing against trying to better yourself and open doors for opportunities. Certified Scrum Master was in fact the first non-developer certification I took, way back in the mid-2000s. I've never re-certified. Years later, I would become colleagues with my CSM trainer, Brian. The company we worked for was a relatively small but competitive (back then) boutique Agile consultancy which was acquired by one of the Big Three consultancies. Our little group of about 100+ had many people who were very highly regarded in the industry, even by those who liked to rail against the so-called "Agile Industrial Complex."

Many trainers and authors are actually very good agilists. Again, there's nothing wrong with getting a competitive edge in the job market; I've done it, too. But there are certain certifications I'd rather not take, even just for the sake of being able to tack on another "official" designation to my signature. It's safe (wink, wink) to say though that CSM is not one of those I'd tell people to avoid if they can.

Hope you have a good week with us, Darcy, and apologies again for starting out on a sour note.

Apologies for the contrarian tone...

Becoming a Scrum Master has nothing to do with certification. There are many bad Certified Scrum Masters out in the wild, just as there are many (and increasingly more) bad licensed drivers out there on the road. Both are equally dangerous to your health and well-being.

If you take the certification process seriously and apply what you learned and continue to learn, then you might one day become a (good) Scrum Master. Unfortunately, the certification alone doesn't make you one.

Completed Day 1 & 2 in ugly Kotlin. Must brush up on my collections operations. Part 1 on both days were pretty straightforward but the Part 2s were a little rougher than I expected.

[This post was split off from here: https://coderanch.com/t/777818/java/Mocking#3555275]

Some of the reasoning behind using underscores and making test names more readable:

- Tests should test a story - they should have a beginning, a middle, and an end. If you use JUnit nested classes, you can also structure the story told in the test report:

RestaurantTest
   OperatingHours
         should be open between opening time and closing time
         should not be open before opening time
         should not be open after closing time
   Menu
         should include drinks
         should include desserts
         should include lunch specials
         should include daily specials
   Reservations
         should allow reservation for current day
         should allow reservation for future date


- If your tests are going to tell a story, the test names should give you a "overall" view of that story.

- Tests should serve as examples for how to use the class under test. Tests should help you understand the API and its design.

- Tests should help you quickly find where problems are happening in your code

Tim Holloway wrote:
testIsOpen_weekdays()
testIsOpen_weekends()
testIsOpen_late_night() (or testIsOpen_lateNight())

Why still prepend "test" to test method names? The @Test annotation marks a test method and the "test" prefix is unnecessary and redundant.

Your class under test is the Restaurant class and yet you're mocking it. You NEVER mock the class under test. You don't test a mock. This is a very common mistake.

Mocks are meant to replace dependencies that are difficult to work with.

One thing you could do is provide a package private method that allows you to inject a time provider. In your test, you can then inject the Mock as the time provider.

public class Restaurant {   private ChronoLocalDate localDate = ...;  // use a real one by default   public boolean isOpen() {        // use this.localDate here   }   // use for Test purposes only!   void setTestLocalDateProvider(ChronoLocalDate deterministicLocalDate) {       this.localDate = deterministicLocalDate;   }
I try to avoid mocks though so one way you can do that is using a partial fake class. This employs a subclass and polymorphism. You'll have to introduce a protected getLocalDate() method:
public class Restaurant {    protected ChronoLocalDate getLocalDate() {         return defaultLocalDate;  // set default to real LocalDate object    }    ... } public class TestRestaurant extends Restaurant {    private ChronoLocalDate testLocalDate;    @Override    protected ChronoLocalDate getLocalDate() {         return testLocalDate;  // provide setters for this so you can control value    }    void setLocalDate(ChronoLocalDate testDateTime) {          this.testLocalDate = testDateTime;    } }
In your test, you'd use the TestRestaurant instead of an actual Restaurant object. You're still testing the actual Restaurant class method, but you're using the TestRestaurant to provide test-specific data.
       
       

Campbell Ritchie wrote:Don't use underscores in method names.

Tests are a different animal.  Using snake case for test names is actually quite popular, so popular in fact, that JUnit includes support for it by way of the DisplayNameGenerator.ReplaceUnderscores decorator:
@DisplayNameGeneration(DisplayNameGenerator.ReplaceUnderscores.class) class MyTest {    @Test    void this_name_is_more_readable_in_the_test_report() {        ...    } }
I would say that if you're going to use the method name being tested in the test name, use that name as is:
@Test void isOpen_should_return_true_if_current_time_is_between_open_and_closing_times() {   ... }

Also, notice that Map does not extend Collection. What does that tell you about its relationship to Set and List?

kevin Abel wrote:
The Key shows extends and implements.

Is there a lot of importance for me to know which Collections extend or implements ?

You're overthinking this.

Collection is an interface. Set is also an interface and it happens to extend Collection, as does the List interface.

All that does is establish a hierarchy of contracts, with Collection being the base contract and Set and List being more specific contracts that add specific behaviors on top of Collection. Essentially, it says any Set or List is also a Collection.

Iain Ritchie wrote:... looking at things differently now and take more consideration into the objects and relationships between them and hoping this will better inform my code. ... I will start reading up and studying more source code as I think it would help demystify the workings of larger programmes.

Read up on design principles and code smells. This will give you a better grounding on what is good and what isn't when you read other people's code.

Some books I'd recommend:

Understanding the four rules of simple design by Corey Haines

Refactoring: Improving the design of existing code by Martin Fowler

Refactoring to Patterns by Joshua Kerievsky

Working effectively with legacy code by Michael Feathers

These are just a few of the books that helped me improve the way I organize my code to make it readable, maintainable, and testable.

Iain Ritchie wrote:
I was hoping to get some feedback on best practices,..One of the things I was most interested in was that I made the Cart class an inner class of the Store class and I'm not sure if this is good practice or not as I am struggling to understand the benefits of inner classes and not sure if they are used much so wanted to experiment to find a use for them and this made sense as the when the cart is instantiated it automatically adds itself to the list of Carts belonging to the Store.

One guiding principle in design is that of Least Knowledge which states that a module or component should only interact with a limited set of other modules or components, and only in a well-defined way.

Ask yourself if a Cart really needs to "know" about the existence of a Store. What responsibilities does a Cart object have that make it necessary for it to interact with (i.e., invoke methods of) a Store? I don't see any.

I can see a Store needing to be aware of Carts and needing to invoke Cart methods, but not the other way around.

That said, I see no reason at the moment to pull Cart out of Store and make its own entity. As you have declared it, the design is saying that a Cart object cannot exist independently of a Store. In other words, the only reason a Cart exists is because there is a Store that needs it. For me this is fine for what you appear to be trying to do.

Programming in Java requires you to think about relationships between ideas like a Store and Cart and how they interact with each other. Creating a two-way dependency by making each one aware of the other complicates your design, and in this case I think it's unnecessary. A one-way relationship with Store being aware of Cart is simpler.

Another principle to keep in mind is that of simplicity. The simpler you keep your design, the easier it is to understand, change, test, and make it work. Always start simple and add on complexity only when you have a simple working system.

kevin Abel wrote:I don't see an author named Singleton in the third editon of the HFJ.

Singleton is the name of the design pattern, not a person.

Singleton design pattern