After hours of wrestling with what should have been a trivial integration with facebook (facebook share button), have finally worked out what was going wrong for me.
Facebook share ends up calling a url (what looks like a php page - sharer.php) which is provided with a u param for the url you are trying to share (there’s also a t param for the title, but see below).
Many people are probably using this to integrate as a widget into their wordpress or other blog, for which the rest of this is largely irrelevant, but If you are trying to integrate facebook share into a localhost runinng app, then there are certain anomalies.
If facebook can’t access the url being shared, but the url ends in a typical extension (like .html) then the url appears as normal (as above). However if it looks like a path, it doesn’t include the url.
I assume this is to do with not being able to guess the mimetype of the document. When facebook can access the url, then it connects to the server (to grab meta tags which override the t param for example), and can then include the document.
Simple fix, but hard won - unfortunately I went through a number of other possible problems (unicode issues, javascript conflict) before the lack of extension hit me as the obvious solution.
Another reflection after listening to Seddon on “Rethinking Lean Service”
Seddon argues that you need to let the actual problems (that disrupt your delivery of value) dictate what activities you perform, and what processes you set up. This implies that you need to be brave enough to allow problems to occur (and have a way of catching and solving them). It means (in software terms) that you must not pre-optimize (of course!) but also not pre-solve, problems you haven’t yet had (even if these occur in 90% of similar projects), and also not pre-create functionality you haven’t yet found a request for (again even if these occur in 99% of similar projects). This is related to the software principle of YAGNI (You ain’t gonna need it) and DTSTTCPW (Do the simplest thing that could possibly work).
This problem-oriented flow is similar to the principle that Seddon characterizes as “Demand-driven” development, for which he stipulates that it is critical to differentiate which kinds of demand represent value, and which actually flow from “defects” and represent waste. For me, in software design, this is an understanding of user/customer/client requirements - these are demands, and some of them follow from the need to generate extra user-value (a needed feature), but some of them actually indicate defects in the existing system. It’s critical as a software designer to be able to differentiate these two, or you may end up building a monstrosity where new features are introduced to correct old mistakes. (I could give common examples but instead will choose one that I find really instructive: the example of the No Kahuna team who chose to remove a feature to fix an apparent defect in their webapplication - This is the right and brave decision even if I personally relied on that feature, and my team didn’t see a defect - and as Nathaniel pointed out in his comment - a very rare event in software development)
(adapted from part of my post on The Connected Republic)
Thanks to Mark for encouraging me to listen to this great podcast of John Seddon rethinking “Lean” and going back to its roots in the Toyota / Japanese miracle
Some notes:
- Customer pull, worker pull. Let workers improve (and own!) the processes.
- Let the problems you encounter determine the processes you set up.
- The measures in use must relate to the customer (“For any flow, we measure the end to end timing as it is experienced by the customer”).
- Let demand drive the system. Which kinds of demand represent value, which waste (that determines your response).
- Study your organization as a system
Really fantastic and very valuable for working out what I have been learning over the last two or three years.
I remember trying this out before though. “Study your organization as a system.” But what if you discover a system that is not consonent with how the organization represents itself to its customers, or worse (and more likely) to itself.
