My daughter was working on a book talk. This was a homework task in which she had to read a whole book and make some notes for every chapter. Because she is usually a little bit unorganized I gave her the following idea: Take a 3×5 index card. Write as a header line the following information: book title, author, and some kind of classification.
Now go on with the following three parts: prediction, events, and questions. Whereby predictions would be one sentence about what will happen in the next chapter. Events is a list with the main events. And questions will be every open question regarding this book.
She did this very well. I hadn’t seen her to complete such a task in a short time. And the most astonish thing was: she had made her notes by the way and could use it to finish this task.
I found the main idea for this kind of notetaking in the book ‘A Manual for Writers of Research Papers, Theses, and Dissertations, Seventh Edition: Chicago Style for Students and Researchers’ from Kate L. Turabian. I am not sure if this citation is really all necessary to find the rest of this stuff. But, you should find this book on Amazon for example. Unfortunately I can’t tell you the page reference for this kind of notetaking. I read this book on my Kindle.
This are my thoughts about the Code Kata’s introduced by Dave Thomas or PragDave. I will work through this Kata’s during the next few days. Ok I will perhaps need rather weeks than days. But essentially I will work on them to get more understanding of some aspects of programming which I wouldn’t touch otherwise.
Most of the idea what a Code Kata is will be covered with the first Kata. Feel free to read it on the website of Dave Thomas. The idea(s) behind Code Kata’s are very impressive and logical for me. So far the hardest point for me is to find the time to do it as expected. Quick, fast, reliable, and produce output which will cover my own expectation of a program.
The second Kata is called ‘Supermarket Pricing’. I believe that all questions asked here can fill a whole book. And even worse some will be different to answer in other countries. For example does rounding exist? For me the answer is sure. But I’m not sure if this will be the fact in Canada. Why I’m sure? I’m grown up in Switzerland and there all prices are calculated to 5 Rappen. If you will compare this value to dollar this will be 5 cent. Everything has to be rounded to an end value of 5 or 0. What will the formula be? It depends on the customer. Will he earn the difference or will he give the difference to his customer? A simple calculation we sell 1’000 eggs with a price of 0.52 sFr. If we sell it 0.50 sFr we will loose 20.00 sFr. If we sell it for 0.55 sFr we will win 30.00 sFr. Now take this game further to every article you will sell … Quiet now Canada is in the process to loose the 1 cent coin. There are several rounding rules on it. The result will almost certain be that more people will use plastic money more. Dear customers what is better use plastic money (and look that the credit card companies earn money with each transaction) or use money and help the shop to spare the transaction to earn more by them self?
This where some thoughts to this theme. For me the answer will be in a pragmatic sense: the customer should be involved in the project team and help the team with the correct decision. I talk out of my experience. I had to re-implement this rounding problem several times in my career.
I am looking for the right place to validate the input in a textfield basically in Java. This is specific for a MVC based construct. The main question to be answered is: is the validation part of the model or the view. Let’s have a look at the view.
What are the advantages if the validation is in the view? What are the disadvantages?
One of the advantages is the relative easy and quick access to the UI component, e.g. a JTextfield. With the according listener it is possible to react on each character entered into the field. This would led to a fast solution. The big caveat would be to violate the principle of the MVC pattern. We would have business logic in the view component. When I think more about this behavior we would even be against the single responsibility principle. A class should have only one reason to exist.
One further caveat will be to enter the validation code for every component, I think here of forms, in this view as a inner class. This would led to a violation of the DRY principle. DRY stands for Don’t repeat yourself. One of the advantages of this is that the view don’t has to communicate with the according model over a server or something like an internal messaging system this would led to a simpler implementation of the system.
What would happen when the validation occurs in the model?
Advantages of this is a clear separation of the behavior. It would be possible to reuse all the validation code for various view parts. What is the price to get to this point? There would be an overhead to get to this point, e.g. we need some kind of a message system to use to communicate between the view and the model. This will be needed in every case because of the nature of this kind of pattern. If the system is huge we can run in some timing problem when the server connection isn’t fast. But in a local system it should be an appropriate way to communicate. In my opinion and with my knowledge I would consider the right place for the validation somewhere in a model component.