Less than 1 min to read (164 words)

Testing Body Detail Estimate In Minutes

Tags: rails

These last two days I added a feature to the blog, which is to estimate the time it takes to read the entry. I added a table called BodyEntryDetail with EntryId as a foreign key. Then, I added Entry#word_count and Entry#estimate_in_minutes to compute how long it would take to read the entry; the estimate is based on the number of words in the entry body.

I made sure if the entry updated, then its body entry detail would update as well. I've been noticing article estimates at Medium and Slate, so I am excited to add it here!

How might I improve this feature? I might add JavaScript to my blog manager tool to indicate a growing word count (and time estimate) as I continue typing. I want to make sure that any tools I build keep getting technically better as well. It's more fun to see immediate visual changes, but remember -- better tools help with output!

posted 2015-04-27 23:08:36 -0700 by Belda


2 min to read (297 words)

Notes from "Clean Code", Chapter 2

Tags: algorithms

At work, I am part of a developer book club. This is a great idea because all professionals should be in the habit of getting better. My homework was to read Chapter 2 from Clean Code, which is about naming.

Clean Code is a well-argued work, which may be why it remains a classic. The rules seem so simple -- why focus an entire early chapter on naming? Because it's the foundation to our code work, and developers who think they have a handle on it could still learn more.

Sprinkled throughout the chapters is the theme that our code has to be handed down to newer colleagues, as well as future versions of ourselves. Names are one way we communicate -- more so than comments themselves. With effective names, we need fewer comments.

Quoted from Chapter 2:

  • "A name should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent."
  • "If a variable or constant might be seen or used in multiple places in a body of code, it is imperative to give it a search-friendly name."
  • "Shorter names are generally better than longer ones, so long as they are clear."

We have to process so much when reading code. Names need to help us understand. Bad names do worse than not help us -- they prevent us from understanding, or lead us to misunderstanding. Surely ZYXXY is meaningless, but what if you saw a variable named productIdsList that was actually a mapping of product ids to their respective descriptions? (True story, by the way!) Not only does the name not help you, it actively encourages you to misunderstand it!

posted 2015-04-22 20:09:27 -0700 by Belda


2 min to read (303 words)

Admin Notes

Tags: content-planning

After months without updates, I decided to spruce up this blog. I am a big fan of the Sean Wes podcast. Today, I listened to an episode that really spoke to me; it is called "Taking Action", which is what I am doing now.

The big takeaway from the podcast episode is to be a creator, not a consumer. Be a Creator. Do not be a Consumer. My reaction is that being a consumer leads to feeling at the whim of other forces. Being a creator helps with personal growth, gives me control, and allows me to inspire. It is easy and passive to consume. It takes initiative and planning to create.

One excuse for not creating is being "busy". I have serious doubts that people are as busy as they say. For example, I spend at least an hour a day reading the Reddit front page (entries and comments). That is what I have chosen to do with free evening time. After listening to the podcast, I wondered, "What if I spent half an hour improving my blog? I still have half an hour for Reddit."

After a few months, my blog would be much improved. How it could be better:

  1. Better content. I could have detailed articles about tech concepts I know (or want to learn). I frequently seek information from Stack Overflow, but do not contribute. I want to give back some of that knowledge karma.
  2. Better graphics. I am using a Lilly Pulitzer graphic (and a twee title). That was a placeholder from over a year ago. I want to replace with something better.
  3. Better personal site. This blog is a part of beldachan.com. I would like to update the features available there to reflect my current interests and technical skill set.

posted 2015-04-21 22:26:14 -0700 by Belda


3 min to read (433 words)

The 7 Deadly Whiteboard Opps

Tags: algorithms

In the spirit of trying new things, I signed up for the debate team during freshmen week. I still have great memories of playing board games into the night of our common room. Many of us freshmen were new to debate, so we went to novices training each week.

In some ways, standing up to be judged for a debate speech is not that different from white board interviewing. In APDA-style debate, the opposition (interviewee) does not know the topic in advance, though there are many common topics (questions/algorithms). In one training, we learned the "7 Deadly Opps" that can take down nearly any proposed case. I wish I had my handout from all those years ago, but the arguments included "too expensive", "bad implementation", "think of the children/elderly/etc". They were cliche arguments that provided a handy crutch for the leader of the opposition to construct a speech in the 7 minutes it takes for the first team to lay out their case.

White board interviewing definitely exercises some of those same skills, as well as inspiring the same nerve-wracking anxiety. In the spirit of debate's "7 Deadly Opps", I present my version of the "7 Deadly Whitboard Opps".

  1. If you are given an array or hash and are not sure what to do, try iterating through the items of the array/hash.
  2. If you do not remember how to implement something, such as a search or sort, factor it out to helper method. It gives you time, plus the interviewer may tell you not to bother writing it out.
  3. Could there be a recursive solution? If yes, think of the base case to stop the recursive calls. If recursion makes you sweat, try an iterative solution -- recursion is elegant but not necessarily efficient.
  4. Before you start code, draw out the problem on the board. The interviewer may correct misunderstandings you have about the problem.
  5. If you are stuck, do not ask for a hint. Talk out loud. Preface with "I am thinking right now", "This may be a solution", etc to signal that it's not your final answer.
  6. This tip is from Gayle McDowell, author of Cracking the Coding Interview: when in doubt, think hashmaps/associative arrays/dictionaries/hashes/whatever it is called in your language of choice. Lookup is O(1) once you've sorted the elements.
  7. If you look confident at the board, you'll feel more confident. Bring your own whiteboard marker with a fine tip. You will fit more code on the board and do not have to worry about dying markers. Seriously impressive.

List to be updated as I think more.

posted 2014-03-08 12:54:23 -0800 by Belda


← Previous 1 2 Next →

Belda Blog

Documenting learning about computers.

linkedin.com/in/beldachan

Entry Archive

Clean Code: Error Handling, Boundaries, Unit Tests

Link: Stop Using Tail -f

Clean Code: Comments, Formatting, Objects and Data Structures

Leap Year

"If-then" Planning for Coding

Non-Zero Days

Testing Body Detail Estimate In Minutes

Notes from "Clean Code", Chapter 2

Admin Notes

The 7 Deadly Whiteboard Opps