Design Hack

Julian Brown ran the Design Hack session. He was willing to take on the herding of the cats and scribe what the group discussed.

We used the suggestion made by Michael R. Davis, even though he was not available.

I'm big on packaging. I would love to see a PSGI Web server package for centos that literally all you have to do is add an INI file to a /etc/psgi.d folder and it's running. I cannot imagine how hard it is to get a plack app running in an enterprise manner.

Since we did not have access to the customer, the team had to use only this text as our target. Much of the design discussion revolved around simplifying our ideas by stripping out pieces that were not required to meet the stated goal. In some ways, this worked better than it might have if we had a customer to talk into more complicated ideas.

One decision we made early on was to specify a target audience for the final tool:

• A programmer who is not skilled in setting up a webserver, but is savvy otherwise.
• erformance is not crucial to this, if it were they would have hand configured it themselves.

The group consisted of people with wide-ranging experience. We had people with many years of experience and only a few. The people with testing experience provided some unique insight into our discussion, that balanced out the developer-heavy discussions.

We made quite a few simplifying assumptions (only centos, only Apache support, etc.) to define an MVP. Each time we moved away from the simple design, someone would point out that we could always make the change configurable in the next pass. Surprisingly, we managed not to over-engineer the design very much during the session.

In the end, we had a fairly reasonable set of requirements, that should have met the goals described. While we were finalizing the design, one of the attendees made a proof-of-concept that matched our design goals and actually appeared to to work.

The general consensus seemed to be that the session went well. The discussion was pretty constant (and civil), involving everyone in the room.

Final Product

Julian documented the results of the session.

• The final product would be a "script" that would read your INI file.
• We only would support, in the first iteration of the script, CentOS 7.
• The script would do a "use 5.14" just to make sure we were not on some ancient system.
• CentOS 7 comes with 5.16 out of the box so that should not be an issue.
• The first thing the script would do is run a set of yum commands to make sure all the packages we need would be on the system.
• Then it would install a bunch of CPAN modules that we need.
• The script would then configure an Apache vhost (based on port in INI) for this app.
• It would be configured with fastcgi.
• It would then have a "base" dispatch.fcgi.
• The base dispatch.fcgi would read the INI file on every request and determine routing from the INI to your target app (psgi, dancer).
• The INI file can support multiple routes.
• This would allow the INI file to be modified real time.
• Apache would only need to be bounced if you modified the port number.

Lesson's learned

• Julian conducted this as an open discussion.
• There were many questions about the "Acceptance Criteria".
• So if we choose to do this again we would:
  • Appoint a PO/Stakeholder who would need to be present so we could ask appropriate questions to clarify what the goal was.
  • During the meeting the PO would prepare the Acceptance Criteria, hopefully early in the meeting so that we could get on with it.

Conclusion

Everyone seemed to agree that this was a good exercise for a meeting. We would definitely be interested in doing it again, but not too often. We agreed that it was a fun exercise, but very tiring. Special thanks to Julian Brown for keeping the group on track and documenting the whole process. Also thanks to Michael R. Davis for providing the initial design idea.

We had 9 people attending this month. As always, we'd like to thank HostGator, LLC for providing the meeting space and food for the group.