- push declarations up, in the beginning (wrapper attribute setting, temp
variable). if possible get rid of temp variable altogether
- use partial search (performance)
- extract method. Move all those if-else logic, into a helper library
module. extend the module in the recipe
- break down the first bash resource into separate directory and
- change the second bash resource to an execute statement (use the creates
attribute make it idempotent)
- remove unnecessary logging
- tests (use chefspec for recipe, use raw rspec for module). your readme
and .kitchen config file are conflicting (ubuntu 14.04 or 12.04)
inverse the search requirement. consume the API endpoint as an attribute.
Currently its hard coded. Consumers can set this via role(statically) or
wrapper recipes (dynamically via search).
these are similar to standard refactoring (check the GoF book on patterns,
or jay field’s design pattern in ruby). writing the unit tests upfront will
ease other efforts.
rinse n repeat
On Mon, Feb 16, 2015 at 1:43 PM, Jim Fluke email@example.com
I have been working with Chef off and on for a while now, but mostly just
doing experiments and training. Recently I have gotten more serious, and
have written two cookbooks that install a web API and a web application
that uses the API. They both work, but I would like to get some feedback on
how they could be improved. To that end I have made the application
cookbook public athttps://bitbucket.org/cira-dpc/searchciradata_cookbook
Let me know if you have trouble getting to it.
Note that this is all running inside our firewall, including the open
source Chef server, so I don’t think we need to worry to much about
security, but if you disagree let me know about that too.