Yet Another Programming Blog

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...

This article are just my notes from the book. Finally the one that covers my daily job. Books like Refactoring (by Martin Fowler) or Clean Code (by Robert Martin) are all fine, but also a bit academical. I have never professionally encounter a clean code. The code is never enough test-covered these days (here in Prague at least). And this book is the one that deals with non-tested huge code-base or a legacy code for short. The Mechanics of Change Of course we all read the Refactoring book, which is almost a bible among the developers. So we know that the change is ubiquitous and we can preserve quality of code over time only by refactoring. However there is a catch - code must be tested. That is why we need to put it under the test first. Here is algorithm of change for legacy code: Identify change points . Obviously you have to find the place for your changes on your own. Every programmer must have done this a million times, so there is nothing new to you here. Find test points . De...

How to code better? I collected some tips about self-improvement for programmers. Tips are ordered in no particular order and divided into seven categories. It was hard, but I excluded some cool tips for sake of simplicity. I didn't mention tricks for programming concurrent software, scalable software, and many more. Optimization tricks were unfairly omitted too. General tips These tips are a philosophical counterpart to the rest of this article. Use priority queue to implement user's requirements. - It is better to implement high priority features or the hardest features first. It minimizes risks of being stuck in the middle of the project. Fix bugs before writing new code . This is a special case of the first tip. Read more... Improve yourself . Read books and blogs. There is always something new and useful to read out there. Have quiet working conditions . It is scientifically proved that you can improve your productivity just by removing distractions. Quite workplace is ju...