2 min to read (201 words)

Clean Code: Error Handling, Boundaries, Unit Tests

Tags: rails | content-planning | ruby

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

Less than 1 min to read (24 words)

Link: Stop Using Tail -f

Tags: rails

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

3 min to read (397 words)

Clean Code: Comments, Formatting, Objects and Data Structures

Tags: javascript | rails | ruby

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

Less than 1 min to read (58 words)

Leap Year

Tags: rails

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

6 min to read (1054 words)

"If-then" Planning for Coding

Tags: content-planning

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?

1. I am tired. a) Try to code in the beginning of the day, if only for 5 minutes. I can start a draft title/outline in 5 minutes. I can structure the steps for coding my feature in 10 minutes. b) Power through and code for 5 minutes anyways. I've done other things when I'm tired (if I had to). If I am tired, I still go to work. Daily practice of my craft is not so different. DO NOT go to sleep and plan to code after waking up. That is procrastination and it usually does not work!
2. I am on vacation and do not have my computer or an ideal programming environment. When I go out of town, I usually bring my work computer instead of my personal computer. To continue to program, I can write content in a notebook or my phone. I can practice coding techniques (like using new gems) on new Rails projects generate on my work computer. (I like to have a clean separation of work and personal, so I will not clone this repo on my work computer.) When I am doing something fun, the "I'm tired" excuse also happens a lot, so I will try to code daily before doing fun out-of-town stuff! I can also watch tutorials on Treehouse and write about them for content. That requires less mental energy than coding.
3. I don't feel like it. This one is vague and a catch-all. The reason I require that I code every day is I don't have to ask myself, "Am I supposed to code today?" If my requirement is a small amount of investment (~20 minutes) every day, then I don't have to bargain with myself that I will code tomorrow (TWICE as much, even!) instead. So if "I don't feel like it" comes to mind, I will just remind myself that progress is the cumulative effects of my effort, not a one-time Herculean effort. How many times have I thought that my life would be better had I only started a year ago? My one-year older self will thank my present self I continue this daily coding habit!
4. I do not feel inspired. To be honest, some of the code I have added to this site is pretty standard -- as of this writing, I do not even have comments on each individual post! Some days I feel more invincible than others, so if I have a less-inspired day, I can think of blog layouts that I like (ex: Medium, Instagram, Nutrition Facts (.org)) and see how I can add aspects of their UI and design to this blog. Or, I can add a case study to the site, wherein I think of how the database tables of a popular site is structured (ex: Airbnb, Pinterest, Yelp, Youtube).
5. I do not feel smart. This is a big one. I do not have a degree from a Computer Science program, and it is intimidating to go through all the Computer Science literature out there, when I have 25% of the formal training of a CS major. However, I can think of others who have obviously learned outside of school (Bill Gates, Mark Zuckerberg), and even dropped out of formal programs to pursue their CS interests. I can tell myself that if I do not practice, I will be even worse off than learning a microscopic amount every day. I can watch a short video on Treehouse to jump-start the process. When I visit my parents, I will bring back some computer science textbooks I purchased online. If I read through actual textbooks, it will make my learning feel more legitimate.
6. I would rather do a social activity with my friends. Have you ever heard: "On your deathbed, you'll never regret not working more. What you will regret is not spending time with the people you love." When I was in high school, I worked all the time. I worked more as a high schooler than I do as an adult. The reason I worked so hard was because I wanted to be the best student in the school, and go to a good school. It became part of my identity and my parents, friends, and teachers saw me as a serious student. That effort took a lot from me and I rebelled by spending more time with friends and on social activities. But now, as a more mature person, I know that I can achieve a balance of both. I have friends already -- the hard part of making them is over! I just have to reach out to them to maintain those friendships. I have more money now, so it's easier to maintain friendships by spending money to go to restaurants. I can make time for coding by expediting transportation to friend activities. Currently, I take the bus, or walk, to meet my friends. Perhaps I can call a car and get there faster, and it will allow me more time to code. Or I can say 'No' to some invitations because I know my friends will still be there if I have to spend time time to myself every now and then.

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

Less than 1 min to read (139 words)

Non-Zero Days

Tags: content-planning

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