The latest book club discussion was on three chapters of Clean Code dedicated to error handling, boundaries, and unit tests.
The main take-away from error handling was to anticipate an error and write your try/catch/finally statement. What occurs in the catch block so your program can run smoothly, without throwing an ugly exception? (Though you may want that exception to occur in a development or test environment.)
For the boundaries chapter, my colleague pointed out an good use case. Consider that you are working on code that relies on input ... that is not finalized. As your team and the other team work, your team has to make assumptions about the input. One solution is to view that as a natural boundary. What helps you cross the boundary is a method you write that processes team 2's finished product into the structure you were expecting while your team coded.
Unit Tests. This chapter highlighted good testing practice. As a developer, I should value test code as much as production code. In practice, that doesn't always work out. I plan to write some tests for this app and return with a better entry about unit testing.
posted 2015-08-09 11:50:24 -0700 by Belda
I use tail -f for Rails server log files. Today I came across this article from Brian Storti: Stop Using Tail -f (mostly)
posted 2015-08-08 23:25:41 -0700 by Belda
On Friday, we discussed Clean Code for developers' book club at the office.
Here are my thoughts on chapters 4, 5, 6:
Chapter 4: Comments
The best comment is one that is not written. With scripting languages like Ruby and Python, writing readable code is easy. People often say that they like writing Ruby code because it is so readable.
However, just as there are good writers and writers who need improvement, there are clean coders (like the book is trying to promote) and coders who need improvement. I am realizing that there is a difference between knowing a lot about computers/technology and actually organizing code for your fellow human colleagues to reuse/understand.
Chapter 5: Formatting
This chapter discusses another technique for code organization, via formatting. There is mention about horizontal space (< 120 characters across) and vertical space (file length in lines). And most importantly, agreeing on a formatting style within the workplace.
At this point, I asked about editing the code style to match in a file. We do not have a company-wide agreement on code style, and file by file we may have single quotes, double quotes, no space after a brace {, 1 space after a brace, etc. The conclusion was that we should have a meeting at a later date to determine.
Chapter 6: Objects and Data Structure
This was a higher-level chapter. It discusses the Law of Demeter, which can be summarized: a method should touch friends' variables, not strangers'.
I will also quote an interesting observation from this chapter:
[T]he fundamental dichotomy between objects and data structures:
Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.
The complement is also true:
Procedural code makes it hard to add new data structures because all the functions must change. OO code makes it hard to add new functions because all the classes must change.
What a lot to think about! I think that if you are working in an existing codebase (with all its strengths and faults/needs-improvements), implementing these newly-learned processes one-by-one -- even as new code is written -- should improve both your codebase and your coding style. A codebase is a living thing, so it's never too late to make the code cleaner!
posted 2015-08-02 00:35:07 -0700 by Belda
I wanted to start Github Gists with this simple coding kata I just did. One critique I have of my code is that the naming of the divisible_logic? method is unclear. However, this problem is confusing to read. It was only when I tried out the samples they mentioned that I understood what the question meant.
posted 2015-06-28 20:08:21 -0700 by Belda
I love Gretchin Rubin's books on happiness, and now habits. Her new book is called Better Than Before, which describes strategies for maintaining habits for four distinct personality types. I am an Obliger; Obligers are more likely to do things for other people, and require external accountability.
I consider this blog a form of external accountability, because it is public. Even my code is public on Github. The blog and public element of this project is good for my progress.
Today I am going to work on an "If-then" exercise described by Gretchin in her Strategy of Safeguards -- ways to protect a new habit. I used to think that life was supposed to be effortless -- because its best practitioners make it appear so. But my newer point of view is that mistakes and unintended situations appear, and we should be prepared to handle those.
What should I do if the following situations prevent me from coding or adding content to this site?
If I think of more excuses, I will post them here. For now, I will re-read this entry if I need to inspire myself!
posted 2015-05-10 13:15:50 -0700 by Belda
I am trying to work on this blog every single day. Some days are easy, when I easily spend an hour thinking about the next feature. Other days, like today, are hard. I have plans with friends, or plans to cook an elaborate dinner, or just feel more tired.
I am balancing adding more features by programming and adding more content by adding blog posts and more projects. Today I decided to contribute by posting more.
I am currently listening to a videocast about processes on Treehouse. Additionally, I am adding this link to Practical Unix, an open-source online class, because I want to improve my z-shell.
Related to computers, but not specifically to programming, I also spent a lot of time today doing what I call "digital decluttering". Hopefully this time investment will improve my productivity!
posted 2015-05-06 00:14:38 -0700 by Belda
Documenting learning about computers.