One Big Fluke
onebigfluke.com · Personal blog · on HN since 2010
Brett Slatkin writes about software engineering, web protocols, and functional programming, drawing on work on PubSubHubbub, App Engine, and Camlistore.
What HN saysCommenters point to his credentials in building web infrastructure when responding to his HTTP and templating posts, and link his WebFist and functional programming posts.
36HN people shared it
13linked it in comments
68stories submitted
1.4Kstory points
3 years agolast shared
2010people per year2026
Most-shared posts
- 1Experimentally verified: “Why client-side templating is wrong” (2015)5 people · 87 points · first shared 2015 · 40 comments on HN
- 2You only get 1,000 lines of code a week2 people · 127 points · first shared 2014 · 82 comments on HN
- 3Let's remove verbs from HTTP 2.02 people · 115 points · first shared 2013 · 136 comments on HN
- 4The case for dynamic, functional programming2 people · 99 points · first shared 2022 · 114 comments on HN
- 5What's awful about being a {software engineer, tech lead, manager}?2 people · 25 points · first shared 2016 · 2 comments on HN
- 6Why am I building a new functional programming language?2 people · 3 points · first shared 2023 · discussion on HN
- 7Simplest explanation of the math behind Public Key Cryptography2 people · 3 points · first shared 2013 · discussion on HN
- 8Bootstrapping WebFinger decentralized discovery with WebFist2 people · 3 points · first shared 2013 · discussion on HN
- 9Homepage2 people · first shared 2013
- 10Go's power is in emergent behavior1 people · 222 points · first shared 2014 · 133 comments on HN
- 11Realistic alternatives to Apple computers1 people · 197 points · first shared 2016 · 357 comments on HN
- 12It is ridiculously easy to refactor Go1 people · 149 points · first shared 2013 · 88 comments on HN
- 13Overcoming burnout1 people · 53 points · first shared 2012 · 16 comments on HN
- 14Why cohort analysis?1 people · 43 points · first shared 2012 · 1 comments on HN
- 15Dyeing the cheese orange – Beware of benchmarks1 people · 35 points · first shared 2013 · 16 comments on HN
What HN people wrote when they linked it
dewitt · 2013-08-09
"And thus spoke someone who has never built a REST API"
Here are Brett's projects: http://www.onebigfluke.com/
Maybe you've heard of some of them? PubSubHubbub, Google App Engine, Camlistore, Google Consumer Surveys.
karmakaze · 2023-03-05
This other "The case for dynamic, functional programming"[0] post may offer hints. So I suppose it will be more like Elixir/BEAM.
> Theoretically, functional programs should: have fewer bugs, be easier to optimize for performance, allow you to add features more quickly, achieve the same outcome with less effort, require less time to get familiarized with a new codebase, etc. With a dynamic, functional language you could enjoy all of this simplicity.
In my experience use of static typing has fewer bugs and better performance than my usages of dynamic languages on all but small or short-lived projects.
I suppose this will round-out Google languages: Go, Dart, and _, until they make their own scripting or an actual systems language.
[0] https://www.onebigfluke.com/2022/11/the-case-for-dynamic-functional.ht…
epaulson · 2020-11-16
This would break a cool indieweb "hack" with DKIM - webfistbump, which lets folks participate in webfinger even if their email provider doesn't support webfinger, like gmail:
https://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfi…
(I suppose you could just re-opt into webfistbump every time your email provider is about to publish their DKIM key)
josephscott · 2019-10-28
Notes on the new edition from the author - https://www.onebigfluke.com/2019/10/i-wrote-a-new-edition-of-my-book.h…
catwell · 2018-10-15
The talk that had the most influence on how I write software is Robert 'Uncle Bob' Martin's "Architecture: The Lost Years" [1]. Being a Ruby conference keynote, it helps if you know how Ruby on Rails works, but the lessons apply to all software.
Another one would be "Let It Crash! The Erlang Approach to Building Reliable Services" by Brian Troutwine. [2]
I don't know if you would call it "technical" but Brett Slatkin's talk on Cohort Analysis is something anyone interested in tools to analyze how our users behave should watch. [3]
[1] https://www.youtube.com/watch?v=WpkDN78P884
[2] https://www.infoq.com/presentations/erlang-reliable-services
[3] https://www.onebigfluke.com/2013/05/video-cohort-analysis-talk-at-goog…
icebraining · 2016-11-01
Reading the earlier post, it seems the extra need is an escape key, which probably wasn't explicitly written since, you know, it's not exactly a differentiator among non-Apple laptops.
http://www.onebigfluke.com/2016/10/lamenting-progress.html
jimbokun · 2016-04-28
That article is here:
http://www.onebigfluke.com/2016/04/whats-awful-building-software.html
Referenced from this article.
jhpriestley · 2016-03-29
The premise that server-side HTML generation is faster than client-side HTML generation is simply false. See here for experimental confirmation: http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-…
Why would offloading computation to a heavily-taxed central server speed anything up? It doesn't make much sense. Nor is HTML generation a bottleneck in most realistic applications.
DocSavage · 2016-03-12
Brett Slatkin wrote a positive review from the perspective of an experienced Go programmer:
http://www.onebigfluke.com/2016/03/book-review-go-programming-language…
talyssonoc · 2015-04-09
Yes, there is: http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-…
The server-side render can't be cached. I guess it is only possible if the component is using the PureRenderMixin (https://facebook.github.io/react/docs/pure-render-mixin.html). Feel free to create a PR/issue about it in the repo !
EugeneOZ · 2015-02-14
Try to use minification and concatenation, then it will be just 1 js file.
Blanket assumptions about server rendering are not enough close to reality: http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-…
bslatkin · 2013-08-22
Full stack or die. Over specialization is the curse of our profession. http://www.onebigfluke.com/2012/11/over-specialization-is-curse-of-our…