Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Lessons Learned from Open Source

Lessons Learned from Open Source

10+ years contributing and maintaining open source projects. Here are my top lessons learned.

Also, a non-exhaustive list of all the open source projects we maintain at OmbuLabs and FastRuby.io

F77032adcbe77d2777bb0e0c30873159?s=128

Ernesto Tagwerker

June 11, 2021
Tweet

Transcript

  1. Lessons Learned from Open Source Ernesto Tagwerker (@etagwerker) OmbuLabs, June

    10th, 2021
  2. 🇦🇷 Hi, I’m from Argentina 🦅 I live in Philadelphia

    👨💻 I ❤ Open Source
  3. Lessons Learned & What You Can Learn About All Of

    Our Open Source Projects
  4. Open Source Contributor & Maintainer Since 2009

  5. None
  6. None
  7. Lesson #1: Some people will implement your solution in a

    better way.
  8. Open by Default When starting a project, we should ask

    ourselves: “Is there any reason to make this a closed source project?” There must be a solid reason to start a new closed source project. Otherwise, our projects should be open by default.
  9. database_cleaner

  10. How can we make sure that our database is clean

    between test runs?
  11. 1 RSpec.configure do |config| 2 3 config.before(:suite) do 4 DatabaseCleaner.strategy

    = :transaction 5 DatabaseCleaner.clean_with(:truncation) 6 end 7 8 config.around(:each) do |example| 9 DatabaseCleaner.cleaning do 10 example.run 11 end 12 end 13 14 end
  12. email_spec

  13. How can we test email behavior in our test suite?

  14. 1 describe "Signup Email" do 2 include EmailSpec::Helpers 3 include

    EmailSpec::Matchers 4 5 before do 6 @email = UserMailer.create_signup("jojo@yahoo.com", "Jojo Binks") 7 end 8 9 it "should be set to be delivered to the email passed in" do 10 expect(@email).to deliver_to("jojo@yahoo.com") 11 end 12 13 it "should contain the user's message in the mail body" do 14 expect(@email).to have_body_text(/Jojo Binks/) 15 end 16 end
  15. Lesson #2: Even simple libraries can get complicated with different

    ORMs, testing frameworks, and multiple databases.
  16. Both database_cleaner and email_spec were inherited by me.

  17. None
  18. Lesson #3: Volunteer to maintain a project even if you

    are not the best person for the job.
  19. ombushop styleguide

  20. None
  21. ombulabs styleguide

  22. None
  23. fastruby.io styleguide

  24. None
  25. Lesson #4: You can organize your CSS code in a

    way that is easy to maintain.
  26. Atomic Design by Brad Frost

  27. None
  28. OCA-epak

  29. How can we communicate with the OCA API?

  30. MercadoPago

  31. How can we communicate with the MercadoPago API?

  32. Lesson #5: You should stub your API requests in your

    test suite.
  33. Lesson #6: You can detect a security hole if you

    don’t stub your API requests.
  34. rails_stats

  35. How can we measure the size of a Rails app

    without having to install its Rails environment?
  36. None
  37. Lesson #7: Proactively reaching out to maintainers of abandoned projects

    could make you a maintainer.
  38. rails_upgrader

  39. How can we build gems to automatically transform code? (e.g.

    strong params)
  40. None
  41. Lesson #8: Writing code transformations is not as easy as

    it sounds.
  42. points

  43. How can we keep track of our blind estimation process?

  44. None
  45. None
  46. None
  47. None
  48. Lesson #9: We could add planning poker feature to make

    it easier to (not blindly) estimate.
  49. dash

  50. How can we see all the things we need to

    do in Pivotal Tracker _and_ GitHub?
  51. None
  52. None
  53. None
  54. harvesting

  55. Is there a Ruby gem to communicate with the Harvest

    API?
  56. Lesson #10: Building API wrappers is quite easy to do

    if you have built a few.
  57. skunk

  58. What if we could combine complexity and code coverage metrics?

  59. Maintainability 1. Code Coverage (SimpleCov) 2. Code Quality (RubyCritic)

  60. Signal #1 Code Coverage

  61. Signal #2 Complexity

  62. Signal #3 SkunkScore

  63. SkunkScore = f(code_quality, code_coverage)

  64. Complex files which lack tests should be our top priority

  65. Maintainability 1. Code Coverage (SimpleCov) 2. Code Quality (RubyCritic) 3.

    SkunkScore (Skunk)
  66. You are here:

  67. Skunk Score Your compass to get out of the tar

    pit
  68. Time SkunkScore Average 100 (days) 0 1 100

  69. None
  70. Lesson #11: Churn vs Complexity is not enough to see

    the whole picture of tech debt.
  71. benchmark.fyi

  72. What if we could share benchmark-ips reports easily?

  73. skunk.fyi

  74. How can we share our skunk score information with colleagues?

  75. SHARE=true skunk

  76. next_rails

  77. How can we set up dual booting and keep track

    of deprecation warnings?
  78. metric_fu

  79. How can we run a bunch of static code analysis

    tools in our codebase?
  80. None
  81. rubycritic

  82. How can we visualize the churn vs. complexity graph of

    a Ruby app?
  83. None
  84. None
  85. bundler-leak

  86. How can we know if one of our dependencies is

    known to have a memory leak?
  87. None
  88. None
  89. What project do you feel more passionate about?

  90. What project do you find more challenging?

  91. Lesson #12: Pick a project that intrigues you, challenges you,

    interests you, and/or you feel passionate about.
  92. Thank you! @etagwerker 92 Thank you!

  93. Resources 1. https://github.com/whitesmith/rubycritic 2.https://github.com/colszowka/simplecov 3.https://github.com/metricfu/metric_fu 4.https://www.fastruby.io/blog/ruby/quality/code-quality-ruby-gems.html 5.https://www.reddit.com/r/ruby/comments/2bq092/rubycritic/ 6.http://jakescruggs.blogspot.com/2008/08/whats-good-flog-score.html 7.http://ruby.sadi.st/Flog.html 8.http://ruby.sadi.st/Flay.html

    9.https://www.fastruby.io/blog/code-quality/intruducing-skunk-stink-score- calculator.html 10.https://www.ombulabs.com/blog/security/mercado-pago-security-vulnerability.html 11.https://www.fastruby.io/blog/bundler/memory-leaks/introducing-bundler-leak.html