Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

StripeCon New Zealand 2017 - Danae Miller-Clendon - Building SilverStripe modules to represent your company


Published on

As a web developer at Toast, Danae is immersed in the open source community both as a contributor and user. Danae talks about building SilverStripe modules to best represent your company.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

StripeCon New Zealand 2017 - Danae Miller-Clendon - Building SilverStripe modules to represent your company

  1. 1.
  2. 2. Building SilverStripe modules to represent your company Danaë Miller-Clendon
  3. 3. Who am I? ● SilverStripe developer for just over four years ● Currently work for Toast ● Developing with SilverStripe since ages ago
  4. 4. Building SilverStripe modules to represent your company
  5. 5. Who is this for? ● Freelance developer making your own modules ● Developer working for a company ● Someone from a company
  6. 6. Presentation purpose Making modules and slowly upgrading them is almost a given for anyone working with SilverStripe. ● Add-Ons directory ● Open source ● GitHub issue tracking ● Community
  7. 7. Presentation overview Choosing which style works best for you and your company ● Open Source vs Private ● Brand ● Maintenance and ongoing development
  8. 8. Open Source
  9. 9. Open source modules Benefits ● Available to the community ● Others can make suggestions ● Pull requests for improvements and bug fixes ● Increase brand awareness with good modules Drawbacks ● Available to the community ● Others can make suggestions ● Pull requests may never come ● Bad modules can tarnish your brand
  10. 10. Licensing ● How restrictive do you want to be? ● BSD License ● Use one that works for you and your company
  11. 11. Maintenance
  12. 12. Maintenance
  13. 13. Semantic versioning ● Practical for even the simplest projects ● Push tags when you see fit ● Follow guidelines on ● Always make a major version change when modifying database fields
  14. 14. Issue tracking ● Be thankful when you get an issue report ● They are helping you ● Be polite and friendly ● At the end of the day, you can ignore them
  15. 15. Issue tracking
  16. 16. Allowing contributions ● file ● Smaller changes are easier to automatically merge ● Larger pull requests require some QA
  17. 17. CI Tools ● Unit tests ● Scrutinizer / Travis ● Add-Ons rating
  18. 18. Private modules
  19. 19. Private modules Benefits ● Can have very specific features to suit particular projects ● More control over the general direction of the project Drawbacks ● No one else but you and your team can fix bugs ● Services need to be self-managed ● Less control over the general direction of the project
  20. 20. Licensing ● Can be more restrictive than open source ● Depending on your client, it may need tweaking ● LGPL-3.0 ● Other GNU General Public Licenses
  21. 21. Private modules ● Private repository ● Access ● Package manager Structure
  22. 22. Private repository ● GitLab ● BitBucket ● Private GitHub
  23. 23. Satis ● Install Satis on your server ● Give access between Satis server and your private repositories ● Poll for changes with Satis ● Add a reference in your composer.json to your Satis website URL
  24. 24. Public or private? Choose which method will work best for your team, brand, and company. Private modules for client-specific functionality Public modules to contribute to the community :)
  25. 25. Brand
  26. 26. Voice Consider the language you use, how you present yourself, and how colloquial you choose to be
  27. 27. Documentation ● Resolves issues before they are raised ● Professional look ● Regularly updated documentation makes for a fantastic module ● Keep it lighthearted and friendly ● Tell and show your readers what to do
  28. 28. Markdown/Linking within GitHub ● Cater your index page to all skill levels ● Go into detail in separate sections ● Use screenshots in CMS documentation, and code snippets in user reference
  29. 29. API Documentation Accurate, detailed, to-the-point ● Simple API’s can take advantage of Markdown tables ● Automatic API reference documentation works well for more advanced modules
  30. 30. API documentation examples Lever API Good interface, specific examples
  31. 31. API documentation examples
  32. 32. API Reference Resources documentation-handbook
  33. 33. Documentation imagery ● ScreenToGif ● Use icons and images ● Screenshots for CMS documentation Dedicated website Brand in issue tracking and response ● Be helpful and polite ● Assume the user has minimum experience Extra additions
  34. 34. Working on modules
  35. 35. Module direction ● Who determines the direction of your modules? ● Take clients into consideration Workflow ● Roadmaps ● Pivotal ● Agile workflow
  36. 36. Losing track How to avoid burying modules Put aside time each week or month to work on modules Keep your in-progress modules front-and-center.
  37. 37. Working with releases ● You can push as many tags as you like ● Mark releases as pre-release if they aren’t stable ● Don’t lock your dependencies down unless you need to ● Keep on top of your dependencies
  38. 38. In conclusion Life happens.
  39. 39. References
  40. 40. Thanks! Toast Ltd Linda at Toast for the slide design for icons