H

Heroku Engineering Blog

engineering.heroku.com · Company blog · on HN since 2014

Heroku's engineering team writes about Rails and Ruby performance, Erlang operations, TLS, routing, and reliability.

What HN saysHN commenters list it among notable company engineering blogs; the given comments give no opinion on it specifically.
22HN people shared it
2linked it in comments
26stories submitted
597story points
10 years agolast shared
2014people per year2026

Most-shared posts

  1. 1
    Patching Rails Performance
    4 people · 109 points · first shared 2015 · 26 comments on HN
  2. 2
    Introducing React Refetch
    3 people · 11 points · first shared 2015 · 1 comments on HN
  3. 3
    Stuff Goes Bad: Erlang in Anger
    2 people · 294 points · first shared 2014 · 51 comments on HN
  4. 4
    Incremental Garbage Collection in Ruby 2.2
    2 people · 79 points · first shared 2015 · 7 comments on HN
  5. 5
    Improved production stability with circuit breakers
    2 people · 10 points · first shared 2015 · discussion on HN
  6. 6
    How We Sped Up SNI TLS Handshakes by 5x
    2 people · 7 points · first shared 2016 · discussion on HN
  7. 7
  8. 8
    Heroku Engineering on Retrospectives
    1 people · 8 points · first shared 2014 · discussion on HN
  9. 9
    Heroku API has migrated to ActiveRecord 4
    1 people · 6 points · first shared 2015 · discussion on HN
  10. 10
    Heroku Proxying Becomes Free Software
    1 people · 5 points · first shared 2015 · discussion on HN
  11. 11
    Hutils – Explore your structured log data
    1 people · 5 points · first shared 2014 · discussion on HN
  12. 12
    Stuff Goes Bad: Erlang in Anger
    1 people · 4 points · first shared 2015 · discussion on HN
  13. 13
  14. 14
    Instrumentation by Composition
    1 people · 3 points · first shared 2014 · discussion on HN
  15. 15
    Heroku Metrics: There and Back Again
    1 people · 2 points · first shared 2016 · discussion on HN

What HN people wrote when they linked it

schneems · 2015-08-28
> There is actually a lot of complexity to hashes in Ruby. I agree here > So if you construct a valid hash, then call three functions passing them the hash, you have no idea if the hash is still valid for the second and third functions without reading the code for all the preceding functions. I don't find that to be true, even in the Rails codebase. You pass a hash to a function (method) and expect that it won't be mutated. If you're writing a method and you mutate a hash, you're expected to dup the argument so it won't be mutated. This is the convention. There are times when hashes are mutated, but generally that's reserved for methods who's purpose are to mutate its arguments. Where Rails gets into trouble in its functional passing of hashes isn't in the mutability of the hashes, it's in the composability of the functions. I've never written about this problem before, so i'm not sure I have a great example but it's definitely a problem. One example in rails is `url_for` it takes a hash argument. The problem is that there's multiple `url_for` methods that all do slightly different things. Some are needed for generating links in email, while some work in your views, and others are designed for you to use programmatically outside of a view context. One of the hardest things about this method is that one `url_for` can call another `url_for`. Since we can never be guaranteed the order of the calls it is really it makes things like having default values, or optional keys.…

Keyboard shortcuts

/Search
j kNext / previous blog
EnterOpen selected blog
vVisit the blog site
fFollow / unfollow
lSwitch grid / list view
dSwitch dark mode
g hHome
g pTop posts
g tTopics
g fFollowing
g lLiked
g yHistory
g qFAQ
EscBack / close