One of the most crucial and important steps in building any Drupal project is determing which modules to use. When you are reviewing your functionality needs you may ask yourself: Where and how can I find the modules I need? Will this module I found solve my functionality needs? Will I need to patch this module? Should I just write my own custom module? To quickly and correctly answer these questions, there are four simple steps you should follow. It's as simple as learning how to R.E.A.D. This session goes over the four steps of R.E.A.D, which can help you to quickly and correctly identify which module fits your functionality needs, if you should patch a contrib module or if you should write your own custom module. This session will use real world examples of using the steps of R.E.A.D to make module decisions. We will also cover the basics and best practices of writing patches and custom modules and how to contribute them back to the Drupal community. This session is geared towrds developer, site builders and functionality decision makers who consider themselves new to Drupal. This session can also prove to be beneficial to experienced drupalists who want to validate/improve habits they have developed.

1. R.E.A.D
How to select the right modules
https://2015.midcamp.org/node/34
MidCamp 2015
#MidCamp

2. Who You Are
New to Drupal.
Want to improve habits.
Session curious.

3. Your Role
A Drupal developer.
A site architect.
Functionality decision maker.

4. What it is all About
How to quickly make smart, informed functionality decisions.

5. What we will Cover
Steps to decide between a contrib, patched or custom module.
Basics of writing/contributing a patch.
Basics of writing/contributing a module.

6. Michael Miles
From: Boston, MA ..a.k.a Planet Hoth
Work: (@WeAreGenuine)Genuine
Exp: Working with Drupal since 2008.
Recently named an Acquia M.V.P
Twitter: @mikemiles86 Drupal.org: mikemiles86
All the Places: mikemiles86
mike­miles.com

7. R.E.A.D
Research what exists.
Evaluate the options.
Analyze the gap.
Determine amount of change.

8. Research What Exists

9. Isolate Keywords
Read documentation, specs, etc...
Pay attention to unique nouns and verbs.
Ask questions!

10. Perform Searches
30k+ Modules available.
Favorite search engine "Drupal [keyword]".
Search on Drupal.org

11. Utilize the Community
Use IRC: #drupal, #drupal­support.
Use Stack Exchange: .
Social Networks: G+, Facebook, LinkedIn.
Even reddit! .
drupal.stackexchange.com
reddit.com/r/drupal

12. Isolate Keywords.
Perform Searches.
Utilize Community.

13. Evaluate the Options

14. Read the Description
What does the module do?
What does the module not do?
What does the module depend on?

15. Community Adoption
Downloads vs. Installs vs. Age.
Activity of issue queue.
Issues are good, not bad!

16. Maintainer Activity
Participate in issue queue?
Accepting of feedback?
Regular commits and/or releases?

17. Read the description.
Check community adoption.
Check maintainer activity.

18. Analyze the Gap

19. Download and Test the Module
Gain a better understanding.
Use a sandbox: .
What is offered out of the box?
simplytest.me

20. Discover Missing Functionality
What does it not do?
Missing 80%? Missing 20%?
Bigger gap = Bigger effort.

21. Check for Community Solutions
Look at the issue queue.
Search "Drupal [module] [functionality]".
Ask questions!

22. Download and test the module.
Discover missing functionality.
Check for comunity solutions.

23. Determine Change

24. Review the Module Code
Does it follow coding standards?
Is it extendable?
Can you figure out what does what?

25. Estimate Effort
How much code to rewrite?
How much code to add?
How much time is there?

26. Extend or Alter
Adding functionality?
Changing functionality?
Changing the modules goal?

27. Review module code.
Estimate effort.
Extend or alter?

29. Examples

30. Scenario #1

31. The Requirements
WHEN SAVING A FILE ENTITY
AND IT IS A JPEG IMAGE
THEN THE EXIF META DATA NEEDS TO BE CAPTURED
AND MAPPED TO CUSTOM FIELDS
AND THESE MAPPINGS NEED TO BE EXPORTABLE USING FEATURES

32. Research What Exists

33. Isolate Keywords
WHEN SAVING A FILE ENTITY
AND IT IS A JPEG IMAGE
THEN THE EXIF META DATA NEEDS TO BE CAPTURED
AND MAPPED TO CUSTOM FIELDS
AND THESE MAPPINGS NEED TO BE EXPORTABLE USING FEATURES

34. Perform Search
We will focus on the keyword "Exif"

35. Search Google

36. Utilize the Community

37. Evaluate the Options
Exif custom seems like best fit.

38. Read the Module Description

39. Look at Community Adoption

40. Look at Maintainer Activity

41. Analyze the Gap

42. Download and Test the Module

43. Discover Missing Functionality

44. Check for Solutions

45. Determine Change

46. Review Code

47. Estimate Effort
Add Features integration.
Alter primary key for mappings.
Time is minimal.

48. Extend or Alter
Adding features support.
Not changing what module does.
Extending.

49. Which Path to Choose
Use module as is.
Patch module.
Write own module.

50. Patch!
Module meets 90% of needs.
Small gap, small effort.
Extends module.

51. What is a Patch?
.
A structured list of changes to files.
Re­appliable to files.
Focused on a single change.
drupal.org/patch

52. Creating a Patch

53. Clone and branch module git repo.

54. Make changes to code.

55. Test your changes.

56. Generate patch file.

57. diff --git a/exif_custom.features.inc b/exif_custom.features.inc
new file mode 100644
index 0000000..243bbe2
--- /dev/null
+++ b/exif_custom.features.inc
@@ -0,0 +1,158 @@
+<?php
+/**
+ * @file
+ * Features file for the exif_custom module.
+ */
+
+/**
+ * Implements hook_features_api().
+ */
+function exif_custom_features_api() {
+ return array(
+ 'exif_custom' => array(
+ 'name' => t('EXIF Custom mappings'),
+ 'default_hook' => 'exif_custom_export_maps',
+ 'feature_source' => TRUE,
+ 'default_file' => FEATURES_DEFAULTS_INCLUDED,
+ 'file' => drupal_get_path('module', 'exif_custom') . '/exif_cus
+ ),
+ );
+}
+...

58. Submitting a Patch

59. Create/comment on issue queue.

60. Attach your patch.
Follow patch naming standards
[module]­[description]­[issue­number]­[comment­number].patch

61. Watch for feedback.

62. Wait for merge. (hopefully)

63. Giving back to the
community

64. Scenario #2

65. The Requirements
WHEN SITE USES WORKBENCH TO MODERATE CONTENT
THEN CAN CREATE MULTIPLE TRANSITIONS BETWEEN STATES
AND TRANSITIONS ARE EXPORTABLE USING FEATURES
WHEN EDITNG A CONTENT REVISION
THEN CAN SCHEDULE A TRANSITION
AND CAN SELECT DATE FOR FIRST STATE
AND CAN SELECT DATE FOR SECOND STATE

66. Research What Exists

67. Isolate Keywords
WHEN SITE USES WORKBENCH TO MODERATE CONTENT
THEN CAN CREATE MULTIPLE TRANSITIONS BETWEEN STATES
AND TRANSITIONS ARE EXPORTABLE USING FEATURES
WHEN EDITNG A CONTENT REVISION
THEN CAN SCHEDULE A TRANSITION
AND CAN SELECT DATE FOR FIRST STATE
AND CAN SELECT DATE FOR SECOND STATE

68. Search for Existing Modules
We will focus on the keywords "workbench schedule"

69. Search Drupal

70. Evaluate the Options
Look at Scheduler Workbench Integration.

71. Read the Module Description

72. Look at Community Adoption

73. Look at Maintainer Activity

74. Analyze the Gap

75. Download and Test the Module

76. Discover Missing Functionality
Unable to create different transitions per type.
Unable to select per revision.
No features support.

77. Determine Change

78. Review Code

79. Estimate Effort
Refactor creating schedules & transitions.
Decouple transitions from content types.
Add Features integration.
Will take time.

80. Extend or Alter
Changing how transitions/schedules are created.
Changing purpose of module.
Altering.

81. Which path to choose?
Use module as is.
Patch module.
Write own module.

82. Build a custom module!
Too big/complicated to be a patch.
Would alter module goals.
No other module exists to support use cases.

83. Writing a Module
.
Follow Drupal coding standards.
Make use of hooks and APIs.
Test your code!
drupal.org/developing/modules

84. Contributing a Module
Ask yourself:
Could others use this?
Seriously, is it abstracted enough?

85. Name module appropriately.
Namespace based on dependencies.
Be clear, not clever.
Should indicate what module does.

87. Provide a detailed description.
Explain what module does and does not do.
Outline any dependencies.
Help fellow R.E.A.D­ers.

89. Be a good maintainer.
Bugs are badges not bruises.
Participate in the issue queue.
Update, release and improve.

91. Let's review

92. Remember to R.E.A.D
Research what exists.
Evaluate the options.
Analyze the gap.
Determine amount of change.

93. Slides & Notes
bit.ly/midcampREAD
bit.ly/midcampREADslides
bit.ly/drupalREAD

94. Sprint Sunday 09:00-17:00
The Nerdery, 300 N Elizabeth St., Suite 500C
http://2015.midcamp.org/schedule
Learn through contribution
Contributors of all skill sets and levels are
welcome and encouraged

95. Feedback
https://joind.in/13791
Speaker Name: @mikemiles86
#MidCamp

96. #MidCamp R.E.A.D / Michael Miles
Thank You!