はてなブックマーク

With simple and easy-to-understand examples in F# and Haskell. Eve Ragins recently published an article called Why you should use truth tables in your job. It's a good article. You should read it. In it, she outlines how creating a Truth Table can help you smoke out edge cases or unclear requirements. I agree, and it also beautifully explains why I find algebraic data types so useful. With languag

An alternative solution to the FizzBuzz kata. A common solution to the FizzBuzz kata is to write a loop from 1 to 100 and perform a modulo check for each number. Functional programming languages like Haskell don't have loops, so instead you'd typically solve the kata like this: isAMultipleOf :: Integral a => a -> a -> Bool isAMultipleOf i multiplier = i `mod` multiplier == 0 convert :: (Integral a

How do you design good abstractions? By using abstractions that already exist. When I was a boy, I had a cassette tape player. It came with playback controls like these: Soon after cassette players had become widely adopted, VCR manufacturers figured out that they could reuse those symbols to make their machines easier to use. Everyone could play a video tape, but 'no one' could 'program' them, be

Service Locator is a well-known pattern, and since it was described by Martin Fowler, it must be good, right? No, it's actually an anti-pattern and should be avoided. Let's examine why this is so. In short, the problem with Service Locator is that it hides a class' dependencies, causing run-time errors instead of compile-time errors, as well as making the code more difficult to maintain because it

A difficult task may be easier if done sooner. You've probably seen a figure like this before: The point is that as time passes, the cost of doing something increases. This is often used to explain why test-driven development (TDD) or other agile methods are cost-effective alternatives to a waterfall process. Last time I checked, however, there was scant scientific evidence for this curve. Even so

Making a good Pull Request involves more than writing good code. The Pull Request model has turned out to be a great way to build software in teams - particularly for distributed teams; not only for open source development, but also in enterprises. Since some time around 2010, I've been reviewing Pull Requests both for my open source projects, but also as a team member for some of my customers, do

Avoid 204 responses if you're building a HATEOAS application. This is a lesson about REST API design that I learned while building non-trivial REST APIs. In order to be as supportive of the client as possible, a REST API should not return 204 (No Content) responses. From the service's perspective, a 204 (No Content) response may be a perfectly valid response to a POST, PUT or DELETE request. Parti

If you take the SOLID principles to their extremes, you arrive at something that makes Functional Programming look quite attractive. You may have seen this one before, but bear with me :) The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pit