hey, exoscale CTO here. As mentioned in another post, we are doing a special pricing for startups and SaaS businesses available here: https://www.exoscale.ch/pricing-target/ and we encourage you to try the service out with the WELOVEHN coupon for extra initial credit.
If you're looking for a provider already out of beta, I'd encourage you to check-out https://exoscale.ch (disclaimer: I'm the CTO there).
We have object-storage, a heroku compatible PaaS and our cloudstack based IaaS.
We also contribute a ton of dOSS things whether in existing projects (riemann, collectd, graphite) or home grown projects such as http://pithos.io
If you're keen to try out, you can register with the WELOVEHN coupon which will get you started with a few more credits than the usual CHF20, we also do special prices for startups, available here: https://www.exoscale.ch/pricing-target/
The right thing to do in this situation is refrain from commenting in the thread at all.
Whoever "cloudscale" is, I'm sure it's a big deal to get on the front page of HN and having a competitor sneak in their promo codes in the comment thread to snipe potential customers probably puts a damper on things.
Whatever the ethics of it, actually I am currently looking for a Swiss based hosting provider that looks a lot like cloudscale/exoscale. However Cloudscale is just "coming soon" and Exoscale isn't, so knowing about it was rather useful. Actually I had no idea that you could get advanced app hosting platforms like this that were regional. I thought Heroku was it.
Exoscale would get more money from me if they had hosted postgres as well as mysql though.
pyr from exoscale here. we operate a service that is similar to DO and linode, and are really proud of our uptime, our efficient support and the simplicity of our console - we want to be the best cloud platforms for people build SaaS applications.
I'm obviously biased, but I think we're definitely worth trying out :-)
``Angular modules can be declared in various ways, either stored in a variable or using the getter syntax. Use the getter syntax at all times.''
It would have been nice to know the reasoning behind this. It does make minification marginally easier (but later on in the document, the DI notation is not used for $routeProvider which prevents minification from hapening anyhow), apart from that I fail to see any advantage to that approach.
Well, "dependency injection" is a pompous term. This just relies on two simple clojure features: protocols and namespace introspection to easily configure a program. It's definitely not a framework, but I see how using the term DI can be a bit scary and off-putting.
I'd like to think it's common for programs to need extensions & plugins, without it deriving from "the point of of clojure".
DI isn't scary sounding, it's just unnecessary most of the time I've seen it, especially in public facing APIs that third party developers use. Most classes don't have so many varied amounts of diverse dependencies where you have to resort to convoluting the constructors for the sake of testing. You could just use inheritance.
Dependency injection takes a thing that should be one line of code and makes it twenty lines. It requires third party developers to have know all kinds of unnecessary implementation details. DI is a piece of shit that should be a measure of last resort and if you find yourself resorting to it often maybe question your entire architecture.
I have yet to meet one person to convince me that DI is not unnecessary in most cases. It always boils down to making writing tests easier. Well you should not shit all over your public APIs for the sake of testing.