# Pentagons, Pentagrams, Doodles and Trigonometry

I was in a workshop the other day and I started a doodle which I often do (or some version of it) when I’m in meetings and such:

I Iove drawing pentagrams because they’re so satisfying – five quick lines is all you need, without lifting your pen from the paper.

But whenever I do this doodle, it always bothers me that these are not really pentagrams, and the contained shapes are not pentagons. I often wonder what would happen to the tesselation if I was drawing real pentagons. I also wonder how I could draw proper pentagrams without a protractor.

(For clarity, a pentagram is a five-pointed star. A pentagon is a five-sided shape. And when I say “real” I mean “regular” – ie shapes with rotational symmetry, where every point, every angle, every side is equal. And “tesselation” is a word that describes the way different shapes slot together side by side, with no gaps (I learnt that word in primary school, in relation to Roman mozaics):

Â ).

So during this workshop I did some trigonometry to work it all out. For those of you who were there with me, this is what I was scribbling in the breaks when I was being so antisocial:

The conclusion I came to was that on lined paper, I could get a reasonable approximation of a pentagram using the following proportions:

If you’re wondering what w represents, I drew it on a different diagram when I realised that G and w were not the same distance – they only appeared to be because I was drawing non-regular pentagrams:

Based on these proportions and the dots that each horizontal line was made of, I came up with the following not-bad pentagrams (they’d probably be better if I had a ruler available instead of drawing freehand):

…and now the pentagons are all regular pentagons, and the pentagrams are regular too, but they’re forced to collide with each other as a result.

For the sake of aesthetics I think I prefer the non-regular versions at the top of this post, but the mathematician in me is now happy. đ

# .Net Rocks podcast – “Teaching Experienced Developers”

While I was at NDC London last week I had a lot of fun chatting to â© âŠand â© for the .Net Rocks podcast.

We talked about a lot of things related to teaching and learning: different learning models, standards for education in software and how to create a culture that allows people to not know things.

You can listen to the interview here.

# How to know whether it’s safe to click a button in an email

When I got an “urgent” email the other day from a colleagueÂ asking me to enter some data in a Google form, my warning bells started to go off. Whenever I’m told that something is urgent, I get suspicious.

It turned out to be kosher, but it made me realise I don’t know how to verify whether a request to complete a Google form is valid or not.

The email contained an embedded “Continue” button. I couldn’t hover over it to find what url it was visiting. I tried “View Source” in the browser, but what I got contained several different urls, none of which were easy to recognise, and the whole html chunk was difficult to parse.

When I finally did throw caution to the winds and click on the button, I got a warning: “You are submitting information to an external page. Are you sure?”… but still, I had no idea how to verifyÂ that it was safe.

But of course, the great thing about working for ThoughtWorks is that I have access to a global pool of talented technologists, and it didn’t take long for someone (my colleague Andy Yates:Â https://twitter.com/yrnclndym) to answer my query.

Big proviso: it’s not a simple business to verify these things. If you are not technical, and even if you are, you should report any suspicions to the relevant people in your organisation. They will be happy to help and would rather have a false alarm than miss a malicious phishing campaign targeting your company.

“I believe there are a couple of things that help show that it’s a genuine request:

– the email address that the form is from isÂ thoughtworks.comÂ (and checking the ‘show original’ confirms it really is the from / return-to address, and that there is anÂ SPFandÂ DKIMÂ pass)

– at the top of the email there is a link ‘having trouble: fill out in google forms’ – this *can* be hovered over, and from here you can see it’s a genuine google forms URL

– (personally, if I was suspicious, I’d follow that link, and skip theÂ button, which doesn’t help speed things up anyway)

– if you have developer tools enabled, you can use ‘inspect element’ to see the form that the submitÂ buttonÂ is attached to, and you can check the domain of the URL from here too – I find this is a bit easier thanÂ doing ‘view source’ because it navigates to the right spot

– if / as you do click through, at the very bottom of the form it states “This form was created inside of ThoughtWorks.” (for other domains it would write out the domain in full)

– (you can also check this by trying to open the same form from an incognito window, where (in this case) you won’t be able to access it, as it’s private to our domain)

– (I put this last one in brackets, because I’m not convinced that it is proof of a legitimate message. I think it *might* be possible to create a form for a similar domain and share it to our domain – so it would look to someone incognito like it was domain-private, but it would in fact say something like “This form was created inside of Th0ughtworks.com” instead of “… ThoughtWorks.” to us)”

# How to Protect Your Website Against Attack

These are some very basic notes I took during @TroyHunt’s talk at NDC London yesterday. It was a great talk and these are some very simple tips. Of course if you’re a web developer you may well already know this stuff, but apparently a surprising number of sites do not take these basic measures.

• Protect against cross-site scripting by using the x-xss-protection response header, and also set the extra value that allows you to report on any cross-site attack attempts – you can set it so that attempts are reported but not blocked
• Make sure you build a CSP using the content-security-policy header, and use the report-uri value to report any security breaches
• This will prevent people from injecting innocuous-looking javascript that could be, for instance, capturing CVVs input by users (this is how the Ticketmaster leak happened, and it was via a third party component (from Inbenta), not Ticketmaster’s own front-end code)
• !! I couldn’t verify from a quick Google search that the Ticketmaster breach could have been avoided by the use of a CSP, so I’m not 100% sure I got that detail correct.
• Make sure your site has a populated security.txt which has details of how somebody can alert you if they have detected a data breach
• For instance Troy Hunt has encountered significant problems in getting hold of the correct contact details when alerting site owners of breaches detected by haveibeenpwned.comÂ (see images)