hunvreus

58 ms·

631.
by hunvreus 13y ago
It's not a matter of taking the gamble you'll stay small. It's that there are different kind of big, only 1 times out of 1 billion there is a single player (Google, Facebook, Amazon) who reach an insane scale. By then, you&#x
632.
by hunvreus 13y ago
I keep on hearing these arguments of scale. I haven't ever experienced such issues. Now yes, if you're running Facebook infrastructure you may run into issues. Though honestly, who here manages more than a few hundreds hosts? I ca
633.
by hunvreus 13y ago
We haven't experienced such kind of latencies. Quite the opposite actually.
634.
by hunvreus 13y ago
Haven't used it personally and hope my colleague can weight in on that one, but it was on the list of tools we evaluated end of last year while working with Chef. It use agents ("minions") and is architected very differently.
635.
Ansible Simply Kicks Ass(devo.ps)
185 points by hunvreus 13y ago|153 comments
636.
Mod, a Chinese Grunt by Tencent(madscript.com)
1 points by hunvreus 13y ago|0 comments
637.
Shanghai: Hackers + Founders this Thursday(us2.campaign-archive1.com)
3 points by hunvreus 13y ago|0 comments
638.
Github: Investigating an increased number of unicorns(status.github.com)
50 points by hunvreus 13y ago|22 comments
639.
MSA: Micro Service Architecture(yobriefca.se)
1 points by hunvreus 13y ago|0 comments
640.
Shanghai Open Source meetup [June 29, 2013](shanghaios.org)
2 points by hunvreus 13y ago|0 comments
641.
by hunvreus 13y ago
I can't talk for my colleague Alex, but we tend not to work with CS very much. I'm not gonna open the troll gates on that one, we've heard the arguments from both sides enough already. We tend to prefer writing stuff in regul
642.
by hunvreus 13y ago
Subscribe to the newsletter, we're opening up soon and will have a free tier for a couple servers.
643.
by hunvreus 13y ago
You're welcome. We're launching (publicly) soon and are in the process of releasing a half a dozen such projects, from AngularJS dashboarding tools to full-fledged node.js frameworks. Stay tuned :)
644.
by hunvreus 13y ago
We haven't done a great job at updating the main site; we have a whole bunch of changes that will be pushed in the next week that should make things much clearer. The core idea of our service is to go a bit further than Puppet and Chef
645.
by hunvreus 13y ago
We caught that one right before posting; I believe it should be fixed now.
646.
Goodbye node-forever, Hello PM2(devo.ps)
138 points by hunvreus 13y ago|31 comments
647.
Automation And Friction(devo.ps)
4 points by hunvreus 13y ago|0 comments
648.
by hunvreus 13y ago
I asked the same thing to my teammates; it seems to be the plan ultimately, but upstream contributions are not necessarily easy to get in, especially on big pieces of code.
649.
I Can Haz Init Script(devo.ps)
14 points by hunvreus 13y ago|14 comments
650.
Team Dashboard(team-dashboard.herokuapp.com)
1 points by hunvreus 13y ago|0 comments
651.
by hunvreus 13y ago
I was merely outlining that the acquirer hasn't displayed a pattern of being very interested in defending the privacy of its users. There's a difference between complying with the law and what the big telcos have been doing.
652.
by hunvreus 13y ago
At the risk of sounding trollish: isn't the acquirer (Savvis aka CenturyLink) a major US telco who is pretty friendly with the NSA snooping (and who somehow also acquired Qwest which resurfaced a few times through the NSA maelstrom)?
653.
Shanghai Hacker News Meetup Reboot(devo.ps)
2 points by hunvreus 13y ago|0 comments
654.
by hunvreus 14y ago
I don't think it is as much about "early" as it is about "intense and constrained batches of work". The "early" part of things is just a sound advice to avoid missing deadlines, but doesn't really help increase the quality of your work or r
655.
by hunvreus 14y ago
Something that we're used to see in China (China Telecom is regularly pissing me off with injected ads), but that I would not expect to see in the US. Though I seem to remember seeing such kind of practice once in San Francisco. What are th
656.
by hunvreus 14y ago
We used a similar approach with Bones ( https://github.com/developmentseed/bones ) for a while and ended up dropping it for a more decoupled architecture (API on side and static client on the other). I remember chatting with Spike about thi
657.
by hunvreus 14y ago
I had left them out for a future post as I wanted to focus on quick guidelines to get started. Mea culpa for not mentioning them at least: will rectify in a couple days with a follow up post properly framing this.
658.
by hunvreus 14y ago
There are ways to do that, I usually find them cumbersome. There are also ways to "easily" maintain API references (Swagger, I/O Docs). I posted something about why we don't use these tools not too long ago: http://devo.ps/blog/2013/02/07/
659.
by hunvreus 14y ago
I was planning on diving in deeper in my next post. This was more of a quick and practical list of things you should follow for your API not to suck too much. But yeah, I agree.
660.
Designing a RESTful API That Doesn't Suck(devo.ps)
67 points by hunvreus 14y ago|73 comments

More ›