Archive for the ‘programming’ Category
Proof of Concept: Google Docs Mail Merge Form with Text and HTML #wordpress
I needed a way to be able to shamelessly plug the posts I recently bundled into the booklet “Write Something” again.In a similar way to the last time I did it in Proof of Concept: Google Docs Mail Merge Form
As I explained before I have set up a system to automatically mail somebody when the enter their address in the form, my issue was that I wanted to add a unique blogpost which they would only be able to get by signing up. Naturally I wanted to style it in the same way the posts are styled in this blog. Again I turned to the documentation, specifically the Class MailApp which I was using to send the mail. Using this documentation I had a starting point. I wanted three changes to the current script:
- keep the plain text
- add HTML message
- add inline images
Just Finished Reading: How Doctors Think #books
My daughter’s Godmother is studying to be an MD, and has started her internship. Starting her internship coincided with her birthday, which meant that many of the presents she received were related to medicine. One of the gifts, which she gracefully allowed me to borrow before she read it was How Doctors Think
Groopman’s book covers one subject which I love: heuristics and bias. Heuristics are the stuff the practice of medicine is made of, which makes it a little strange that this isn’t always taught. The influence of the intuitive, fast, effortless System 1 thinking versus the slower, conscious, System 2 thinking is reasonably well known. System 1 allows us to unconsciously come to conclusions based on the information at hand, as Groopman says: “When you hear hoofbeats, think horses, not zebras.” The practice of medicine is such that most of the diseases encountered fit into a nice pattern, however it is also a burden which make cognitive bias possible. When a doctor sees nine patients who are suffering from flue symptoms, System 1 will quickly come to the conclusion that the diagnoses of the tenth patient with these symptoms is also flue, and will even ignore facts to the contrary. Read the rest of this entry »
Proof of Concept: Google Docs Mail Merge Form #wordpress #updated
I needed a way to be able to shamelessly plug the posts I recently bundled into the booklet “Write Something“. I want to build a list, and offering something which adds value for the subscriber is a good way to do this. There is a host of good material which you can use to help, so I won’t elaborate on that in this post.
I have a hosted WordPress.com blog, which means that I can’t run a local script to collect the mail addresses and mail them, so I turned to Google Docs’ Form functionality for the entry form, naturally I give them the option to download the booklet there, and I wanted to send the subscriber a message to thank them. In the Google tutorial: Simple Mail Merge they explain how to do a mail merge using the Script Editor. I wanted to go a little further and have it send a mail with thank you note and a link to each subscriber as soon as they filled in the form.
Dealing with Software Vendor Failure for Vendors #risk
I have a confession, I am a former software vendor, I’ve worked for software vendors as a consultant, and I’ve been guilt of delivering a solution which didn’t work as advertised. This is sadly an all too common occurrence which can be due to many things which I will not be discussing here. Here I will identify some of the common pitfalls that all vendors face, and what can be done to reduce and mitigate the risks these pose.
There are a number of pitfalls that a vendor can fall into when addressing the issue or the customer, Groopman calls[1] these the 3 A’s: Read the rest of this entry »
Design – Re-Inventing the Wheel #agile #scrum #xp
Everybody tells you not to reinvent the wheel, and I am going to explain why everybody is wrong and you should start re-inventing. Programming paradigms and design patterns are the staple of all new programmers, and they enable everybody to communicate in a common language which can be easily understood when their rules are strictly adhered to. The issue is that beginner developers have cursory knowledge, expertise and familiarity with the design patterns they are required to implement.
A recent practical example a group of relatively inexperienced programmers with the Model-View-Controller paradigm found that the controller they were using didn’t make their life easier, so in some specific cases they deviated from this and implemented their own heuristics. This caused the underlying database to get more SQL queries that even Facebook reports it gets. At the point the website ground to a halt a simple investigation revealed that they bypassed the controller and model to access the database. Common heuristics would usually point to scaling vertically or horizontally.
If it looks like a duck, it walks like a duck, and it quacks like a duck, guess what? It’s a duck.
A Duck?
It is not always a duck. Current thinking is that common things are common, and common problems have common solutions. This isn’t always the case, Henry Ford summed it up best: “If I had asked people what they wanted,” he said, “they would have said a faster horse.” By living in the constraints of their knowledge when people hear hoofbeats, they think horses, not zebras. And “[w]hen faced with a result that doesn’t go according to plan, a series of perfectly effective short-term tactics are used until the desired outcome is achieved.”[2] Some developers believe that once this hurdle has been taken all will be well, I can tell you the light at the end of the tunnel is an oncoming train.[4]
When you are in a hole, stop digging! That is exactly how we got into the mess in the first place.
How do you stop digging?
You have become increasingly convinced of the truth of your misjudgment, developing a psychological commitment to it. You have become wedded to this distorted conclusion.[1] Realizing this is your first victory. “In the material world, the unknown is a place of uncertainty and potential risk … [b]ut we make a mistake when we attribute the same qualities to the world of our thinking.”[3] The second victory is having the courage to throw out everything you have done up to now, baby and bathwater.
“There is a wonderful story of a group of American car executives who went to Japan to see a Japanese assembly line. At the end of the line, the doors were put on the hinges, the same as in America. But something was missing. In the United States, a line worker would take a rubber mallet and tap the edges of the door to ensure that it fit perfectly. In Japan, that job didn’t seem to exist. Confused, the American auto executives asked at what point they made sure the door fit perfectly. Their Japanese guide looked at them and smiled sheepishly. “We make sure it fits when we design it.” In the Japanese auto plant, they didn’t examine the problem and accumulate data to figure out the best solution—they engineered the outcome they wanted from the beginning. If they didn’t achieve their desired outcome, they understood it was because of a decision they made at the start of the process.”[2]
Clean Slate
Starting with a clean slate learn to question everything you know and are told, especially what I tell you. Learned heuristics can be good, but they are only as good as your teacher. You own experience is key to be able to implement anything. Having a prototype or an example can help you, and a prototype is only as good as the developer who wrote it. Don’t be afraid to start over rather than refactoring, there is little to lose and everything to gain by ignoring the old paradigm: “If it ain’t broke, don’t fix it.“
- How Doctors Think
– Jerome Groopman, MD
- Start with Why
– Simon Sinek
- Effortless Evolution – Jamie Smart
- Wall Street proverb
Image source: Sebastian Fritzon
Recognizing Signals #scrum #xp #agile #lifehack
Signals come from everywhere, they are tell us something about our environment. Whether it’s hot or cold, wet or dry, and painful or pleasant. These signals are rarely binary, there are gradients in the signals. And we have signals with which we aren’t dealing at that moment, which we’ll call noise in that instance. Feedback is also a signal, perhaps it causes a painful sensation or it causes a pleasant sensation. Whatever the sensation it causes that sensation too is another signal which we can choose to regard as noise.
Painful Facts For Developers #programming #foss
I recently saw a note from the Tech Journalist Russell Holly who calls on the Scumbags of the Internet to stop making demands of developers from whom they get their free software:
You don’t demand ETA’s on shit you aren’t paying for. You don’t get angry when something doesn’t work quite right on an Alpha or Beta build of something you didn’t pay for. You don’t start shooting off at the mouth about how you are going to move to someone else’s free software if this developer doesn’t fix the software you didn’t pay for.
I was naturally in agreement with the spirit of what he said. And I think that he and these developers miss a number of simple facts: Read the rest of this entry »
Coriolanus Effect and Wakoopa Stats #productivity #timemanagement
I first started writing about Wakoopa in 2009, when I wrote the article Time Spend, is Time Earned on using it for time management, it has mostly been running in the background to give me some statistics on the way I use my time behind my computer, and whether it is used effectively. Recently I started a new projects with new computers and again installed the Wakoopa Tracker to measure the effective use of my time. Naturally the Parato principle still holds, roughly 80% of the effects come from 20% of the causes.
Coriolanus effect: n. the act of going around in ever decreasing circles until one vanishes up one’s own backside.
–Glaswegian expression
For Sunday it is possible to see the amount of time I spend creating a Christmas card, and I see that – split over Mac and Windows – I seem to be spending the productive 62% of my office time on development, documentation and mail. Again I can also immediately see correlations between any dips in time – such as Monday – and real events, in this case meetings. Furthermore the relatively short time spend on development on Monday can be seen to have a ripple effect that continues on Tuesday and Wednesday. I’m sure that had the statistics been available for Thursday this line would continue.
Using my calendar I could get a similar graph, and although the details of how long I was “researching” a recent XKCD joke are still lots be lost, Wakoopa enables me to see the usage of my time slightly better and the collection is entirely passive.
Image source: Wakoopa
User Stories: How small is too small? #scrum #xp #agile
I like a User Story to be precise and target a specific functionality, a Use Case or a logical vertical of a Use Case. This means that a finely scoped task of 2 or 3 hours could be called small. It also depends at what time in the SCRUM backlog a certain User Story is implemented for it to be a small or large User Story.
At the beginning of any development project all User Stories are large, they include many additional variables everything from setting up the initial design patterns, to drastic refactoring to allow for stackable functionality. This means that a task which might take 2/3 hours once there is a working vertical to build on could take considerably longer when everything needs to be build from scratch. Ron Jeffries – SCRUM God – says Read the rest of this entry »
Code Review in SCRUM? #xp #agile #mathematics
Recently I was asked by a client to make some estimations regarding a review of a code review for a programming project. The aim of the project is to refactor the existing code for efficiency, check the security and add new functionality. Having done code reviews in the past I had an idea on how it should be done, and little idea on how to quantify the work into an estimate.
