Yet Another Programming Blog

The first look into the contents of the book was a bit scary. Some of these things were already explained in Robert Martin's previous books. Then I found out they are explained from a different (software architect's) perspective. Overall, I liked this book better than Clean Coder, but it was less useful for me than Clean Code book of the same author. Part I - Introduction The foreword contained two useful antipatterns: Too authoritative and rigid architecture. Speculative generality in software architecture. The main point of the preface is that not much changed for the last 50 years in software architecture. The rules of software architecture are the same regardless of any variable (time, type of project, ...). When you get the architecture of the software right, you magically don't need horde of programmers maintaining it. Chapter 1 - What is Design and Architecture? There is no difference between software design and architecture. There is a continuum of...

This book's main theme is software developer's professionalism. I like this book much less than Uncle Bob's Clean Code book (the first of the series). That said, it is still a worthy read. Robert C. Martin introduces his book as a catalog of his own errors. He says we are in dire need for professionalism in our software developer profession. Chapter 1 - Professionalism Professionalism is all about taking responsibility. The first rule is to do no harm. As it is virtually impossible to create a bug-free code, the first thing to learn is apologizing. The code has to be tested. Then tested again. The tests must be automated. Basically the QA should find nothing. Uncle Bob demands 100% code coverage by tests. At the very least, your automated tests should assure you that the code will most likely pass the QA. If you find a code which is hard to work with, do the refactoring to make the change easier next time. This is the Boy Scout rule: "Always check in a module clea...

These are my personal notes about the Robert C. Martin's book Clean Code. Chapter 2 - Meaningful names The book starts with an advice that we should use intention-revealing names . E.g. elapsedTimeInDays vs d . Of course we should avoid disinformation and non-informative names. Uncle Bob then explains what he means by using meaningful distinctions. E.g. variables message and theMessage next to each other do not make sense. We should obviously use pronounceable names ( generationTimestamp vs genymhdhms ) and searchable names (e.g. MAX_CLASSES_PER_STUDENT is more searchable than 7 ). We shouldn't be cute (e.g. whack method). We should be consistent with names per concept. E.g. decide between fetch , retrieve and get and stick to it.   We should avoid encodings, as the modern programming languages have strong typing, making them unnecessary. E.g. prefix " I " before interfaces names is wrong. Better is no prefix for interfaces and some suffix for implemen...

I stumbled upon a great article of Ken Rockwell called How to Afford Anything . Since the article is quite long, here are the points that helped me the most, i.e. were the least obvious to me. Priorization In short - buy things that you really want. Don't buy things just because it is so easy. Never buy a new car - as it is one of the worst investments. New car losts a notable value just by you buying it. Don't buy a big house - instead, try to live just below your means. Why? Because then you will always have more money than you need. This can be abstracted to the rule - try to spend just below what you have, e.g. the 99% and you won't know what to do with the money. The problems raise if you spend just a little above, e.g. 101%. Real estates not always make you money - you pay lots of things around the house. So buy the apartment only if you intend to live in there. Patience Find plenty of time to research products that you intend to buy. Thrift "A ...

Removing distractions especially at work can boost your productivity, so they say . I gathered some tips from other blogs and added some more to improve your distraction-freeness productivity. Close all applications and tabs you don't need . I cannot work when I see 30 windows and always have to think where to click. I have an average number of 2 windows in the taskbar and I am a programmer. I find myself periodically killing windows/tabs, when their numbers exceed 5. Have a zero mailbox . I have it empty for 10 years now and I still live happily. Move your e-mail from your inbox when you're done with it. Try to read each of your e-mails just once. Take the wanted action (reply, fix something, etc.) and try to immediately decide if you will delete it or archive it. Have a quite workplace . If you must listen to music, many people find it better to listen to instrumental music only (no vocals). Clear your desk . I'm a minimalist, so I like my desk clean. I think this coul...

As always, I've written this article for myself. It is about how should I approach when I have a website idea, but no motivation to start. I took an inspiration from Craig Larman's book: Applying UML and Patterns 3rd edition. The title sounds like UML book, but its in fact more about doing software right. So where do I start? Vision and Business Case This is a high level and terse text document about what I am developing. It should consist of: Problems of stakeholders being solved. Competition of mine. Features of the new system. Other chapters may include: Description of Stakeholders, Users, Goals of Stakeholders, Users, Summary of Benefits, Constraints, Cost and Pricing, Licencing and Installation, ... Please note that this document will probably not be finished on a first try. It will be revisited after use-case analysis is mostly done. This applies to all following documents. They are just started earlier than othe...