Hey everyone, I often see questions regarding best practices, and examples that people can reference so they know how to structure and accomplish certain objectives they’re facing. So, I wonder if anyone is open to collaborating and creating documentation on best practices to get things done.
I’m not completely sure of the best route to doing this, but perhaps people can raise their hands to what they’re good at, and also what best practices they’d want to see be built out. Based on consensus, I can take care of the organizing, but I still feel that I’m a super newbie at Elixir despite having 1 year of experience still, so I’d have to rely on the community (you) to help with the actual knowledge part of the how to.
An example for me is showing the best practice of multi select such as fly.io’s article here but to give more detail in how to implement and update embedded schemas in a clean and reusable way. (Ecto is still a struggle for me with these things)
I think this can empower the entire community because they can have a reference on how to structure, write high-quality code, and also build confidence as an Elixir developer. The more livebeats like examples the better.
I was thinking it could be a maintainable GitHub project where people can do some PRs and then have a simple static site.
Also, I’m willing to make some youtube videos with anyone open to it, so we have both written and video documentation.
Would love everyone’s thoughts on this, and apologies if this has been discussed before.
Though it would be cool if we can have some default way of doing authorisation that can scale, just like Ecto library, and default Authentication generator along with an awesome Admin panel, CMS, plus anything else that Startups can use to jump start projects.
I completely agree with this example being a best practice reference. Perhaps we can disect and document what code snippets of live beats are best practice and build some written understanding of how it works, how to implement it, etc.
Then also do that for other repos that are also considered to have best practices.
Are there any specific examples within live beats that you would consider worth mentioning for best practices?
I’d love to see a Phoenix Recipes book - I’ve posted about this in a few threads now:
I think it would be great if José and Chris were involved too, not necessarily as the people writing it, but as co-authors overseeing what is/isn’t included and maybe adding their thoughts on things every now and again.
It’s no longer in print, but this is what was in Rails Recipes:
Part I — Database
Recipe 1. Create Meaningful Many-to-Many Relationships 2
Recipe 2. Create Declarative Named Queries 7
Recipe 3. Connect to Multiple Databases 11
Recipe 4. Set Default Criteria for Model Operations 19
Recipe 5. Add Behavior to Active Record Associations 22
Recipe 6. Create Polymorphic Associations 26
Recipe 7. Version Your Models 31
Recipe 8. Perform Calculations on Your Model Data 36
Recipe 9. Use Active Record Outside of Rails 39
Recipe 10. Connect to Legacy Databases 41
Recipe 11. Make Dumb Data Smart with composed_of() 44
Recipe 12. DRY Up Your YAML Database Configuration File 48
Recipe 13. Use Models Safely in Migrations 50
Recipe 14. Create Self-referential Many-to-Many Relationships 52
Recipe 15. Protect Your Data from Accidental Mass Update 56
Recipe 16. Create a Custom Model Validator 58
Recipe 17. Nest has_many :through Relationships 61
Recipe 18. Keep Your Application in Sync with Your DatabaseSchema 63
Recipe 19. Seed Your Database with Starting Data 68
Recipe 20. Use Helpers in Models 70
Recipe 21. Avoid Dangling Database Dependencies 72
Part II — Controller
Recipe 22. Create Nested Resources 76
Recipe 23. Create a Custom Action in a REST Controller 80
Recipe 24. Create a Helper Method to Use in Both Controllers and Views 83
Recipe 25. Trim Your REST Resources 85
Recipe 26. Constrain Routes by Subdomain (and Other Conditions) 88
Recipe 27. Add Web Services to Your Actions 90
Recipe 28. Write Macros 94
Recipe 29. Manage a Static HTML Site with Rails 98
Recipe 30. Syndicate Your Site with RSS 100
Recipe 31. Set Your Application’s Home Page 108
Part III — User Interface
Recipe 32. Create a Custom Form Builder 112
Recipe 33. Pluralize Words on the Fly (or Not) 116
Recipe 34. Insert Action-Specific Content in a Layout 118
Recipe 35. Add Unobtrusive Ajax with jQuery 120
Recipe 36. Create One Form for Many Models 125
Recipe 37. Cache Local Data with HTML5 Data Attributes 131
Part IV — Testing
Recipe 38. Automate Tests for Your Models 136
Recipe 39. Test Your Controllers 141
Recipe 40. Test Your Helpers 145
Recipe 41. Test Your Outgoing Mailers 148
Recipe 42. Test Across Multiple Controllers 151
Recipe 43. Focus Your Tests with Mocking and Stubbing 157
Recipe 44. Extract Test Fixtures from Live Data 163
Recipe 45. Create Dynamic Test Fixtures 168
Recipe 46. Measure and Improve Your Test Coverage 172
Recipe 47. Create Test Data with Factories 176
Recipe 51. Roll Your Own Authentication 198
Recipe 52. Protect Your Application with Basic HTTP Authentication 203
Recipe 53. Authorize Users with Roles 206
Recipe 54. Force Your Users to Access Site Functions with SSL 211
Recipe 55. Create Secret URLs 212
Recipe 56. Use Rails Without a Database 216
Recipe 57. Create Your Own Ruby Gem 221
Recipe 58. Use Bundler Groups to Manage Per-Environment Dependencies 224
Recipe 59. Package Rake Tasks for Reuse with a Gem 226
Recipe 60. Explore Your Rails Application with the Console 228
Recipe 61. Automate Work with Your Own Rake Tasks 230
Recipe 62. Generate Documentation for Your Application 235
Recipe 63. Render Application Data as Comma-Separated Values 236
Recipe 64. Debug and Explore Your Application with the ruby-debug Gem 239
Recipe 65. Render Complex Documents as PDFs 244
Part VII — Extending Rails
Recipe 66. Support Additional Content Types with a Custom Renderer 250
Recipe 67. Accept Additional Content Types with a Custom Parameter Parser 253
Recipe 68. Templatize Your Generated Rails Applications 256
Recipe 69. Automate Recurring Code Patterns with Custom Generators 259
Recipe 70. Create a Mountable Application as a Rails EnginePlugin 266
The only issue really is Phoenix is moving pretty fast atm, so such a book might become outdated quickly (in which case a Recipes section here on the forum could be worth exploring, a bit like our ‘how would you’ type section, or adding something to the Phoenix site itself…)
Based on my experience with this sort of thing, any such resource (either as a book, website, repo, livebooks) has to have a full test suite that runs regular on CI, and “looks ahead” to the language’s master with unlocked deps to get ahead of changes.
Also clearly documenting the pub date and versions of software used in all code examples.
TBH this is one of my main struggles with Livebook right now; there’s no way to externally and programmatically drive its execution as a project dependency. Makes me reluctant to use them as a form of primary documentation for anything.
There’s cheatsheet feature in ExDoc, and LiveBooks can be embedded into the generated docs.
So we can read the LiveBooks when away from machines and then run it when possible.
I liked @AstonJ’s idea. I am beginner in backend dev, so I was thinking a cookbook for building SaaS related features would be great. (Not beginner algorithms and challenges, that can be its own book!)