846 karma · joined May 15, 2010
https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/ValueOf
Half the time I pick a good solution and half the time I've rushed in and picked the wrong one.
If I have picked the wrong one, I know within 30 mins that it is a flawed approach, but have usually explored the problem sufficiently to pick a good solution. The interview unfortunately ends after 30 mins.
I should also add that I'm not much better at this after 13 years of professional development than I was when I left uni, when it comes to manipulating linked lists and arrays. My systems design is a lot better though.
If you are worrying about URL readability you aren't doing REST.
It's would be great if there was some kind of full version trial so people could try it with full intellisense and package manager support.
Each type has a `.Match` and `.Switch` methods, in to which you have to pass lambdas to handle each case `.Match(Func<T0, TResult, ..., Func<Tn, TResult>`.
I don't know if this would work in Java, given the generic type erasure, but it might...
The thing is, if you use well-known terms, your client will work against ANY API that uses those terms, not just the one that you coded it to work against.
Not only that, but the APIs will have flexibility to move things around, or delegate functionality to other hosts by linking through.
As for the cost of walking the chain, once a target resource has been found the can be cached, and you only need to rewalk if the resource 404/410s.
Well there's this: JavaScript Object Notation (JSON) Pointer RFC https://tools.ietf.org/html/rfc6901
Rather than "arrange", "act", "assert", I've taken to writing the Gherkin spec inline with the test code, e.g.
@Test
public void onlyExistingEmailsCanResetTheirPasswords() {
//Given an email address which is not in the database
String email = "unknown@example.com";
when(userRepository.findByEmailAddress("unknown@example.com"))
.thenReturn(null);
//When a password reset is requested for that email
UserServiceImpl userService = ...
userService.startResetPasswordProcess("unknown@example.com");
//Then no password reset notification should be sent
verify(notificationService, never()).sendResetPasswordNotification(any());
//And the user should be given a success message so they can't determine if the email address is already present
verify(userInterface, once()).sendMessage("You have been sent Please check your email.");
}
This way you preserve the intent for the programmers that will come after you, but you don't need a complicated Gherkin runnerSince then, I have always suspected it was still a problem in large financial institutions, although the few times I mentioned it to people they looked at me blankly. Now I feel vindicated!
Out of interest, does the Financial Industry use any analogues to source control and unit testing for spreadsheets?
It's cool you could encode your name into your genes and then it would live on as long as humanity.
Also, ValueUtils (https://www.nuget.org/packages/ValueUtils/) is nice for making value types.
*or one of the many alternatives (https://www.nuget.org/packages?q=discriminated+unions) e.g. SuccincT, DiscU