The friend could easily submit far more answers than 23 if need be. He just needs to go to the toilet.
Step 1: 10 bits information - First 10 answers as seconds from start of exam. After x seconds, friend goes to toilet.
Step 2: Restart counter
Step 3: On return from the toilet, take time taken in toilet. You may want to limit this to 6 bits of information / ~ 1 minute in the toilet. Anything longer might be suspicious.
Step 4: Restart counter
Step 5: Only 7 bits of information to hand over to get 23 questions. Count time till he leaves.
Step 6: Repeat toilet-going process for more answers in different situations.
There should be no suspicions, as the answer-receiver will not go to the toilet.
I like Medium and I DO hope it goes ahead with the subscription model. It will make it easier for me to stop procrastinating and to read something more useful, like arxiv articles.
You are absolutely right, but campaigning for a ubiquitous language in a company has far more benefits than just the application of DDD to your code. In meetings with other teams or stakeholders, we often hear or say things like "can we agree to call this thingthis from now on". We then proceed to clarify exactly what is meant by the terms. It goes a long way.
We have full-blown event sourcing for pretty much everything. The performance on the read side is great (obviously). We have an Event Store and we rebuild the Domain for every new command, so it isn't particularly fast, but we have a situation where commands are only issued a few times every year by a single person, whereas there are millions of reads every day (hence justifying CQRS as a solution). We have a mixed solution around replaying events though, largely around the issues we have with file uploads. Every file upload triggers multiple events (uploaded, processed etc) and we have different solutions for different files. Small files we store in the events as a blob, whereas big file events upload the data to a projection store and will not be replayed, so we don't have the issue of having to keep the original files forever as well as the database. I should probably write a blog post about the project at some point, but I'd like to investigate with my bosses as to how much I can actually reveal about the domain (because it would make the read so much more interesting if I could say everything).
1. TDD is simple enough. Everyone should be doing it. 2. DDD - this usually results in plenty of healthy debates on naming conventions. Acronyms are abhorred and we try to agree with the stakeholders on the meaning of each word they use. 3. CQRS and Event Sourcing - this has required our team quite a bit more of startup time than a CRUD application would have. We have been lucky to have a very understanding Product Owner who gives us plenty of time to deal with tech debt. Although single features may have originally taken us longer (than the time it would have taken to do the same with CRUD) at the start of the project, years on this time and the complexity of refactoring or adding features has not really increased, as any functionality is contained within its bounded context.
The biggest difficulty has been explaining what we are doing and why to senior management. But we haven't had any bad incidents so far, so I think they like us.
I absolutely agree. CQRS and Event Sourcing only make sense in some circumstances. I have heard stories of companies deciding to use them and only afterwards deciding which project to apply them to. For me, Ubiquitous Language and separation of Bounded Contexts are the primary concepts that can and should be applied everywhere.
I refactor my code fairly regularly (as specifications change). The use of TDD, DDD, CQRS and Event Sourcing gives me immense flexibility to be able to refactor a large codebase and then test it through its whole lifespan (with actual data).
Vernon's Implementing DDD is an excellent supplementary book to Eric Evans', but it also works well as a Stand-alone book. I generally refer to them as "the Blue Book" (Evans) and "the Red Book" (Vernon). I still haven't read the Blue Book, but I will in due course. The Red Book has given me more than enough understanding of DDD to put it into practice in the workplace.
I would argue that the fact you are solving problems outweighs what skills you have used to build your projects. Obviously a showcase of skills is great, but most side projects are old and not a good representation of the creators' current skills. However, the fact that they are actively going out of their way to solve problems they face via software tells you a lot about the person.
The way I find side project ideas easily (and get swamped by them) is by:
1. Getting involved in multiple activities - I am part of a choir, I play board games with my friends, I read a lot of books, I take photos of the night sky and I like to do my own statistical research on various topics (e.g. politics).
2. Figure out the problems you face in all of these activities - I have found plenty, such as choir members who can't read music, lack of strategy analysis for various board games, lack of pretty astronomical software, lack of graphical representations of ideas presented in books and vast lack of graphics representing the effect of political policies.
3. Figure out which of the problems can be solved with software.
4. Pick the languages/frameworks/tools you want to learn to use and that will help you with the project.
5. Build an MVP.
6. Invest more into the project, or otherwise repeat 1-5.