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

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
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.
18. Lesson #3: Volunteer to maintain a project even if you are not the best person for the job.
19. ombushop styleguide
21. ombulabs styleguide
23. fastruby.io styleguide
25. Lesson #4: You can organize your CSS code in a way that is easy to maintain.
26. Atomic Design by Brad Frost
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?
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)
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?
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?
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
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?
81. rubycritic
82. How can we visualize the churn vs. complexity graph of a Ruby app?
85. bundler-leak
86. How can we know if one of our dependencies is known to have a memory leak?
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