15 Matching Annotations
  1. Last 7 days
    1. Rather than write new tooling we decided to take advantage of tooling we had in place for our unit tests. Our unit tests already used FactoryBot, a test data generation library, for building up test datasets for a variety of test scenarios. Plus, we had already built up a nice suite of helpers that we coud re-use. By using tools and libraries already a part of the backend technology’s ecosystem we were able to spend less time building additional tooling. We had less code to maintain because of this and more time to work on solving our customer’s pain points.
    2. The problem domain and the data involved in this project was complicated enough. We decided that not having to worry about unknowns with the frontend end-to-end testing stack helped mitigate risk. This isn’t to say you should always going with the tool you know, but in this instance we felt it was the right choice.
    3. This particular project team came in with a lot of experience using testing tools like RSpec and Capybara. This included integrating with additional tools like Selenium WebDriver, Chrome and Chromedriver, data generation libraries like FactoryBot, and task runners like Rake. We had less experience doing end-to-end testing with Protractor even though it too uses Selenium WebDriver (a tool we’re very comfortable with).
    4. There are times to stretch individually and as a team, but there are also times to take advantage of what you already know.
  2. Feb 2021
    1. The fact we’re using ActiveRecord (or something looking like it) doesn’t mean Trailblazer only works with Rails! Most people are familiar with its API, so we chose to use “ActiveRecord” in this tutorial.
  3. Jan 2021
    1. Familiar interfaces borrow from well-established patterns. These should be used consistently within the interface to reinforce their meaning and purpose. This should be applied to functionality, behavior, editorial, and presentation. You should say the same things in the same way and users should be able to do the same things in the same way.
  4. Dec 2020
  5. Nov 2020
    1. It's friendlier to contributors. Dart is substantially easier to learn than Ruby, and many Sass users in Google in particular are already familiar with it. More contributors translates to faster, more consistent development.
  6. Oct 2020
    1. If the react cargo cult didn't have the JSX cowpath paved for them and acclimated to describing their app interface with vanilla javascript, they'd cargo cult around that. It's really about the path of least resistance and familiarity.
    2. The only "issue" it has is that its unfamiliar. People have been working with HTML for years and are comfortable with it. That's basically the only reason that people find it more readable. If you make an effort to spend sometime with hyperscript, it becomes as familiar and readable as jsx.
  7. Sep 2020
  8. Jun 2020
  9. Apr 2020
  10. Dec 2018
    1. But the reason I wanted to go back in that moment was the same reason students want to stick with familiar grading systems: I know how it works, I know how to communicate about it, I know how to get the best results from it, and it sticks within the letter-grading system I’ve used for 20 years as a teacher and longer as a student. I can recite all the dangers and disadvantages of letter grading, but because it’s the system I’ve known for pretty much my entire life, there’s still a certain comfort to it, and whenever things get weird or challenging or unpredictable, I get an atavistic desire to go back to what is familiar.

      This is beautiful - acknowledging discomfort on the part of both teacher and student.