13 Matching Annotations
  1. Mar 2020
    1. It is recommended that a library should have one subclass of StandardError or RuntimeError and have specific exception types inherit from it. This allows the user to rescue a generic exception type to catch all exceptions the library may raise even if future versions of the library add new exception subclasses.
    1. Also, make sure your client will handle an unexpected response. Don’t assume that the comment-check API will always return either true or false. An invalid request may result in an error response; additional information will usually be available in HTTP headers. And of course, a connectivity problem may result in no response at all. It’s important not to misinterpret an invalid response as meaning spam or ham.
    1. Then there’s markup inside each paragraph, like links and such. You could do it right in the translation strings, but your translator then needs to know how to handle the markup, and you risk duplicating knowledge if you go as far as to hard-code link URLs. What I do is split up the translations, but keep them under the same key: en.yml1 2 3 4 log_in_or_sign_up: text: "%{log_in} or %{sign_up} to do stuff." log_in: "Log in" sign_up: "Sign up" header.erb1 2 3 4 5 <%= t( :'log_in_or_sign_up.text', log_in: link_to(t(:'log_in_or_sign_up.log_in'), login_path), sign_up: link_to(t(:'log_in_or_sign_up.sign_up'), signup_path) ) %> This way, the translator sees no code or markup (except for the i18n interpolation syntax) and there is no duplication.
    2. You probably don’t want one translation key per sentence, though. It’s helpful for the translator to have context rather than a lot of short strings, and less fiddly on your part.
    1. Translatable strings should be limited to one paragraph; don’t let a single message be longer than ten lines. The reason is that when the translatable string changes, the translator is faced with the task of updating the entire translated string. Maybe only a single word will have changed in the English string, but the translator doesn’t see that (with the current translation tools), therefore she has to proofread the entire message.
  2. Feb 2020
    1. Do Browse like a user wouldTake natural pauses that users would take to consume page contentFocus on the most common use cases, rather than all the possible use casesTake note of pages where forms/logins occur, you will likely need to complete some scripting there
    1. But, let’s be pragmatic for a second, the 80/20 rule states that you get 80% of the value from 20% of the work and a couple of simple tests are vastly better than no tests at all. Start small and simple, make sure you get something out of the testing first, then expand the test suite and add more complexity until you feel that you’ve reached the point where more effort spent on realism will not give enough return on your invested time.
    1. Load Testing Manifesto Simple testing is better than no testingLoad testing should be goal orientedLoad testing by developersDeveloper experience is super importantLoad test in a pre-production environment
    1. I was able to use the "Gift to a Friend" link on HB on a game I already owned and was able to generate an email to a friend. They were able to successfully get the game.Seeing that my Steam account is linked to HB, I was more worried about clicking the "Reveal Your Steam Key" and getting hosed that way.
    1. It's a good practice to create respond_to_missing? if you are overriding method_missing. That way, the class will tell you the method you are calling exists, even though it's not explicitly declared.
    2. In my opinion respond_to_missing? should never return true as default. Instead, it should be something like check_if_method_meet_condition || super . Another thing is that it is usually defined as respond_to_missing(method_name, include_private = false)