ndemoor

Here is also a non-exhaustive list of websites using cloudflare: https://index.woorank.com/en/reviews?technology=cloudflare

I don't understand how this could be flagged as a dupe. I agree both articles cover Portainer.

But one goes deep into how to set it up with deep integration on Docker Machine and DigitalOcean on a more expert level.

While the other provides a very simple beginner level Play with Docker setup and then goes on how to install an entire application stack, with frontends, databases and workers.

Yeah, the gist of the article was just to show some of the capabilities. In essence, Portainer is just a wrapper around the Docker API. So I wouldn't use it as a management tool, much rather as a quick and dirty checkup tool.

The only other term I could come up with was 'label' or 'tag' but that sounds so boring. ;)

I only read TC when their linkbait titles end up on the frontpage of HN.

Stopped following their feed, once I came to the same conclusion as the OP: being overly funded is (almost) the only way to go get featured on TC, these days. The times of roaming the edges of startup-land and posting about the nitty gritty startup struggles are long forgotten.

There are 2 options which I use(d) when developing/deploying DynamoDB: - Have a separate (sub)account for dev/test/... in which you create your tables. Since one of the latest changes to their policy you are now able to configure the lowest read/write capacity possible: 1/1 - Join everything under one account but prefix your tables with dev_, test_, prod_*

I prefer the former as it enables me to have the dev/test env as similar as possible to the prod environment: same naming, and both env's are separated, when one gets compromised at least the other one doesn't suffer. Security rules are also easier as you don't have to create per-table rules, when you want to lock out some team-members from production tables, but not dev/test tables.

Digging further in 3), if your app is proven to be in the 'good' quadrant, have you ever considered contacting Twitter directly and requesting a higher API limit rate.

I can imagine they are ok with that if your app provides value to their ecosystem.

Brussels, Belgium (I know, chances are low ;)) - Woorank.com - Frontend dev/iOS dev

We are looking for people: * loving to put 100's or 1000's of datapoints into nice and shiny dashboards

* have expertise with PHP/Node/MongoDB/Redis

* familiar with versioning svn/git/mercurial

* eager to question everyone and everything if he or she thinks something can be done better/different and enhance the experience

Feel free to contact me at nils@woorank.com with your github profile/portfolio/blog

Couldn't have said it any better. Being TC'ed is cool to put on your websites homepage (I know, we did ;)), but appart from having a huge spike in your Google Analytics dashboard, the direct results/conversions are minimal(especially for B2B products).

On the other end, it might get you a little extra cred to prove your rising traction.

Better to go for more specialized blogs, they are better for overall conversion.

As a current customer of Recurly, I am very dissapointed in the way they communicate. I know it's all hands on deck now to fix this problem, but putting communication aside is not the way to go.

For us this is also a very stressful situation, because if the worst case scenario becomes a reality...

"Some customers will be required to reach out to (some or all) of their customers to have them re-enter billing information."

... we can spend days contacting clients to get the payment credit card (which in some cases they should go to their boss for), and go through the billing process again, only to hope to get the list as near to a 100% recovered as possible.

Time for Billing Provider Redundancy?

S3 is also used as intermediary data storage when running Elastic MapReduce queries over data in your DynamoDB tables.

http://aws.typepad.com/aws/2012/01/aws-howto-using-amazon-el...

Well, the downside of using multiple DB stores is that the logic of keeping everything consistent is in the hands of the developer. So you have to make sure that everything is written correctly.

For instance, if you write to MySQL and Mongo, but your Mongo is down, you'll either have to queue the data item somewhere for a write once the system is back up, or you have a migration system in place that gets everything from MySQL since the downtime and writes it back to Mongo.

Depending on the type of data we have a few easing factors: for some data stores it is not that big of a deal if it doesn't get written to it's 2nd layer (eg. cache) as we can rewrite it the next time it is requested in layer 1.

In the stack I am working on we have a variety of databases all serving a different type of data storage:

- memcache: for caching of data that doesn't persist - redis: caching of data that needs a to be persisted short term but not on the longer term (eg. sessions) - MySQL: for user-like data (account details, addresses, projects, ...) - DynamoDB: for millions of data points that only needs to be queried in 1 dimension, so are not related or compared to one another. eg. give me all values from this table containing a given datatype, between 2 dates - MongoDB: for millions of datapoints that need to be queried on deeper levels - etc.

"Instead, they keep a Thing Table and a Data Table. Everything in Reddit is a Thing: users, links, comments, subreddits, awards, etc. Things keep common attribute like up/down votes, a type, and creation date. The Data table has three columns: thing id, key, value."

I hope they introduced some NoSQL sweetness by now.

My bad, indeed, the bookmark is still viciously looking at me every day, so I was under the impression I'd still might finish it this weekend.

So spoiler alert suggestion revoked...

To have a legitimate replication setup, an arbiter node is highly recommended: http://docs.mongodb.org/manual/administration/replication-ar...

Although I am a heavy user/believer of MongoDB, one caveat that is overlooked in this article is the administration part of Mongo Clusters.

Even the simplest replication needs 3 servers, add sharding to the dance for extra performance and the server counter jumps up. For startups this is a major decision to consider as a full-time ops guy isn't always affordable. Luckily, PaaS services as MongoLabs and MongoHQ save the day.

For a quick grocery list of servers and costs, to show your team/boss/... in a meeting, this works just fine.

Can you also add a daily (next to hourly) amount input? Because in our case (and I guess other companies/users) a big chunk of servers is running non-stop throughout the day and it is easier to get your mind around this figure.

"For the entire month, we set aside all nonessential product work (everything besides customer service and keeping our servers running)"

Who did they offload the work to then?

I genuinely agree. In a former life I was promoted from software developer to lead dev/scrum master, and I can tell you the dev part of the job moved completely to the background, making room for something more of a secretary job: planning poker roundups, doing the scrum board task dance, doing the numbers game on estimated and effective man-hours, etc. Overhead.

I don't say agile development is a bad thing. But some managers tend to be led by cool buzz words and obey the manifesto way to strictly.

Agile development is different for every team and situation, not a one-stop-shop everyone should adhere to.

True, mobile is another thing I didn't cover in my comment. The trello app on iphone works like a thrill, given the fact it's a daunting task to get all the information on a small screen.

Asana had constant issues with syncing the data.

At Woorank we gave both of them a spin and a must say that for our team (8 people = 4 tech/2 CS/2 Allrounders working closely together) Trello works best, even with only 2 boards.

We've put up the Trello board on a big screen in the office and after some tweaking (eg. cutting the tasks in smaller bits) it's amazing how productivity rose, just because people are pushing the enveloppe for getting a ticket from the left to the right.

Also for a workflow of a ticket having several states (planned, in progress, done, reviewed, pushed, live), and going back and forth a lot, we just didn't find a nice way to do this in asana, without having lots of projects with several sub-lists, having to reconsider the workflow again and again, etc.

Asana looks more promising to me, when used in bigger companies (20+), having several departements, using there own projects or workspaces, with their own flows and way of working.