Hi, I looked around the website and it looks like a cool service.
But I was unable to figure out;
1. What countries are supported for sellers.
2. What countries are supported for buyers.
376 karma · joined November 28, 2016
Are you tired of looking at metrics in datadog and then switching over to another website to track your applications exceptions?
errorShip is a python library that sends exceptions/errors generated by your application to your datadog account.
email: support@errorship.com
But I was unable to figure out;
1. What countries are supported for sellers.
2. What countries are supported for buyers.
You could also try gumroad.
- We are using the default test framework that comes with Go; go test.
- We usually follow Postel's law which translated to Go, would be: `Accept interfaces, return concrete types`[2] This enables us to pass in fake interfaces during tests. I haven't checked what kind of performance cost(if any) we may be paying by passing around interfaces instead of concrete implementations; but performance has not been a problem so far so we are just happy with our approach.
- We do not use any http web frameworks, we are just using stdlib's net/http. We pair that with certmagic[3] for automated TLS certificate issuance and renewal.
I like the performance of Go, it is easy to pick up and it comes with a pretty great stdlib.
What I do not like is the fact that it has nil pointers, and you tend to run into one or two nil pointer dereference errors once in a while.
You can email me if this interests you (email is in my bio)
So instead I now pick things that I find to be fun to me to work on. Instead of solving customer pain points, I try and solve a pain point that I have. I'm liking it thus far
Bonus points if you call the plan, the wireguard plan; and 90% of the payments go to Jason Donenfeld.
I would be interested in a demo of the logs AI stuff using real data. Something like, https://www.honeycomb.io/play/ would do.
Do you have such?
If this is something you are interested in, hit me up.
Currently doing about $1k/month
You might want to consider redirecting requests for your IP address to go to your domain name.
Something like:
server {
listen 443 default_server ssl http2 reuseport;
listen [::]:443 ssl http2 reuseport;
server_name doorbell.io;
# redirect IP address requests to https domain
if ($host = '192.241.177.143') {
return 301 https://doorbell.io$request_uri;
# you might want to use code 307 in place of 301 if you care about POST requests etc
}
}
It started out as a side project but it has grown to a point where we are now doing it full time.
Hi, sorry about that. We'll fix the comparison page.
> Why not support TLS/amqps at all pricing levels?
When we started out, we were offering AMQPS/TLS for all plans through certificates from letsencrypt[1]. However, it became hard to manage certificate renewals, since we had to renew them on one machine and scp them to the respective RabbitMQ servers. This was too labour intensive and not worth. We however still have plans to roll out TLS for all plans at no extra cost.
What you have described is not negative at all. It is just what it is with RabbitMQ. I can remember the first time(many years ago) when I experienced my first RabbitMQ node split and I was so disappointed with it. But reading on their documentation, I was able to realise that, that is just the way RabbitMQ handles partitions.
> A managed service has to solve the hard problems(high availability) to be compelling.
We hear you. And are working very hard to try and come up with high availability solutions/plans that do not have the same failure modes that currently exist in RabbitMQ. But we believe that those problems need to be solved in RabbitMQ itself. So we are looking to see if we can come up with other failure handling modes, apart from the 3 outlined in[1]. We cant make any promises, however.
If you are already running your own node and are looking for HA solutions, then we might not be right for you, yet. But we still believe we can offer you value by taking over the headache of running the node from you so that you can concentrate on other things.
Thanks for checking us out!
The only reason why we are not offering a clustering plan is because when you experience a network partition in such a case, you will loose data. And we do not want to be in a situation where we are explaining to our customers that there data has been lost through no fault of our own, but because that's the way RabbitMQ works.
We would rather have single node plans where failure modes are much easier to deal with.
I think you are referring to Compose[1].
We differ with/from the alternatives in a number of ways: - We have No rate limits. We do not limit the number of messages you can queue, the number of queues or any other artificial else. - All our plans are on dedicated server. We do not setup shared RabbitMQ servers(vhosts). - We do support HiPE (High performance Erlang).
We have a comparison page[2] where we list more of these differences.
1. https://www.compose.com/databases/rabbitmq 2. https://www.amqphosting.com/us-vs-them
As a developer I usually find the marketing side of things to be a bit tricky to do. So as a workaround I usually carry out marketing during my 40minute commute to my day job.