Viewing profile — nexneo
nexneo
HN member- Joined
- Fri, Apr 10, 2009, 4:26 PM UTC
- HN karma
- 729
- Public activity
- 153 items
- HN profile
- View on Hacker News ↗
About nexneo
Recent public activity
- story
- story
- story
- story
-
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…
- story
-
comment
Comment #21603917
20 years late but finally it started to feel like we are living in 21st century.
- story
- story
- story
-
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.
-
comment
Comment #9145160
PhantomJS 1. But nothing is tide to phantomjs, wkhtmltopdf should work as well. (I'm planning to test with PhantomJS 2)
-
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…
-
comment
Comment #9143966
Sure. I did :) One question: Why you mentioned RubyMotion as alternative for server application?
-
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…
-
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…
-
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…
-
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…
-
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…
-
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…
-
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.
- comment
-
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…
-
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…
-
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…