Live data from Hacker News

Viewing profile — nexneo

nexneo

HN member
Joined
Fri, Apr 10, 2009, 4:26 PM UTC
HN karma
729
Public activity
153 items

About nexneo

[ my public key: https://keybase.io/nexneo; my proof: https://keybase.io/nexneo/sigs/sBLmfkeJfU4KQQQug0mjzkHpPjDaoW_LAAaLqbAa65Q ]

Recent public activity

  1. story
  2. story
  3. story
  4. story
  5. comment
    Comment #39589535

    Entire press release sounds like Spotify is some biggest company and Apple is a startup being crushed by Spotify. Apple's attitude towards developers complaining about App Store wa…

  6. story
  7. comment
    Comment #21603917

    20 years late but finally it started to feel like we are living in 21st century.

  8. story
  9. story
  10. story
  11. comment
    Comment #9176684

    Good thing about bleve is that it's a library. Probably it's early but I'm looking forward to use it.

  12. comment
    Comment #9145160

    PhantomJS 1. But nothing is tide to phantomjs, wkhtmltopdf should work as well. (I'm planning to test with PhantomJS 2)

  13. comment
    Comment #9144104

    You have to make all code threadsafe that execute from Job or you have to decouple Job code and App code.(which probably be required anyway because I'm not sure sidekiq supports ol…

  14. comment
    Comment #9143966

    Sure. I did :) One question: Why you mentioned RubyMotion as alternative for server application?

  15. comment
    Comment #9143587

    Without Ruby we couldn't have build lots of features with such a tiny team. We don't regret and we are not replacing Ruby entirely (just few parts) 85% of our server codebase is st…

  16. comment
    Comment #9143582

    wkhtmltopdf and phantomjs both worked similarly, currently I'm using phantomjs. And I'm not splitting pdf but splitting html generation work load, and then create individual pdfs f…

  17. comment
    Comment #9143544

    As fast as twilio can accept and process without throttling, beyond that its not much useful. Unicorn forking benefit is overrated, we used it and we don't see much benefit for lon…

  18. comment
    Comment #9143363

    Thanks, you explained it very well. Edit: Our requirement was to process this queue as fast as possible and that means more workers. With process based concurrency that is very cos…

  19. comment
    Comment #9143356

    Our ruby application had memory problems and thats why it needed overhaul, but instead of changing architecture and rewriting same thing in Ruby I choose Go. Sure, rewriting made i…

  20. comment
    Comment #9143319

    Exactly right any language could have worked, and we didn't replaced Ruby, just few part of our big application is rewritten. I did in Go not because of language is better, ecosyst…

  21. comment
    Comment #9143308

    Problem is I don't know Java. But I know enough Java to know that it will take lot longer for me. And I might not have simple deployment benefits, thats important feature of Go.

  22. comment
  23. comment
    Comment #9143095

    You exactly captured my sentiment, when I started doing this I don't realized all benefits. Because of Go's simplicity in deploying and maintaining, many small apps doesn't add muc…

  24. comment
    Comment #9143085

    Exactly, Ruby app was monolith so it was consuming much more then this single feature would require. Now there is double benefit Go already uses lot less memory and its microservic…

  25. comment
    Comment #9143068

    I agree that line bit confusing, Ruby app doesn't connect with Go service directly, every requests goes through balancer and then nginx router. Nginx routes then using simple locat…