piggity

A large part of the issue with pricing on Google App Engine (which is the one that still stings for many people) - was that they were building on a relatively proprietary platform.

The advantage of Docker based compute engines is that your lock-in is a lot lower - providers have to compete on price and features without locking customers in.

Where I work, we're always balancing using new AWS features against how hard it would be to migrate out to another provider or take our solutions on-premises.

There are small things - e.g. you can't do weekly / fortnightly billing.

Once I discovered that I stopped investigating BT for our primary subscription engine. We just hold the card tokens and use BT to charge the card.

It's not ideal, but it does give us more flexibility.

Shouldn't it be the service's responsibility to determine what you are rating as a median score and then recalibrate your scores to their drivers?

i.e. If I always rate 3, but sometimes rate 1; then that might be similar to someone always rating 5 but sometimes rating 1-3.

Except if your target customer isn't a chemist.

I recently went on holidays and was merrily tethered away on 4G to Telstra. Hit the cap limit on my plan - 3GB - called Telstra to get a datapack add-on - "I'm sorry, but you are on the highest plan, we can't add on any more data".

Basically I would have had to sign onto a completely new contract to get more data for the 5 days to end of month. Ridiculous.

Amazon (the mothership) runs at a loss [1]

It is predicted that Amazon AWS runs at a huge margin [2]

Of course it's possible that these number are skewed by some Irish Whiskey Double Dutch Vegemite Sandwich tax avoidance system.

[1] http://venturebeat.com/2013/10/24/red-is-the-new-green-for-a...

[2] http://venturebeat.com/2013/09/05/amazons-mountain-of-margin...

The old Polar series of sports monitoring watches (HRM/speed/cadence etc) used to transmit data using a "Sonic Link".

e.g. client library - https://code.google.com/p/sonicread/

Double opt-in is optional at Mailchimp.

Customers can add emails directly and check a box saying "yes this customer gave me permission".

Aweber uses double opt-in and there is no way around it. But that is a double edged sword when you've got a business to run.

I guess the main issue is that the timeline of events has gone like this:

Snowden/Guardian: NSA is doing X Govt/NSA: We are not doing X Snowden/Guardian: Here are some slide/proof Govt/NSA: Ok we are doing X, but it's for your own good.

Rinse and repeat each fortnight.

So each denial means less and less, and tips believability towards Snowden even where the proof is inconclusive in some cases.

I wonder if the developers get a real handle on the platform and squeezing the most out of it by the time it gets to EOL.

Could be that the active user base of mixpanel has dropped slightly while people are offline to upgrade. Would depend on exactly how their metrics are being gathered.

None-the-less I find it amazing that ~20% of their sample base is already upgraded.

I was using LaTeX => PDF generation, but because I don't do it all the time I found it cumbersome and confusing at times.

Prawn seems to have come a long way since I used it last - and has addressed all the limitations that pushed me towards LaTeX in the first place.

Definitely worth looking at Prawn again in my opinion.

SQL Server Standard is $2K per core - with > 4 cores per socket, things flip around a bit.

I'm not a SQL licensing guru; so perhaps I'm confused as well...

Interesting idea, it looks like you scan the Gemfile.lock (or equivalent) at "deploy" time.

My preference would be to upload that Gemfile.lock to a location, and then it could be scanned as and when new vulnerabilities were detected.

The only question I'm really interested in...

And Linode isn't saying anything new

Monocultures are "bad"

(plenty of other issues too!)

Could be that the passwords were hashed, but something logged a password, or there was leakage somewhere during the login process.

All it takes is one debug log statement to leak through from development and you can be logging plain-text passwords on every login.

Agreed, I don't know if I'd be able to sleep if my status was displayed on anything with less than a 20000:1 contrast ratio

Sales Tax Clearing House as a Service!

Only lawyers think it's a good idea to deploy lawyers into the routing mesh.

Because your sample is so small, the results are easily skewed by a few people. As the sample size increases you'll get a more representative picture of what is happening.

It doesn't invalidate what you've found, but does mean you should now continue on with your experiment to increase the sample size - and help ensure your data wasn't impacted by something else - e.g. vacations / a conference that was attended by many of your subscribers / etc etc.

I could believe this - once you have load balancers, multiple proxies and different servers all over the place - getting the IP address of a request can become difficult.

If there's no business driver in making that happen, then it quickly falls by the wayside and you are left without the "luxury" of that information being available in a readily accessible form (i.e. suitable for a CSR).

You can argue that that isn't acceptable of course.

My motto is - "Where there's confusion, there's contracts"

Nothing wrong with using the cloud as long as you really understand what you're getting yourself into.

* Use a vendor specific extension - e.g. EBS + snapshots to mount customer data volumes - make sure you can work around it easily if you move to another provider. * Backup data inside the same cloud provider? - make sure you backup the backups in case of catastrophic cloud provider failure - not doing that? then you need to understand what your risk profile is? * Only use 1 provider? What is your strategy if they fail, temporarily or permanently? Where is your data? How do you fail if they fail?

So on and so on - these are standard considerations in a business risk analysis / disaster recovery plan - but I many IT shops in the cloud are staffed by people who are great at code, but have never dealt with the vagaries of business practice - not their "fault" - but it is a blind spot I see quite often.

The other issue is that you can have redundant services, but when the control plane goes down - you are screwed.

Every day I have to build basic redundancy into my applications I wish that we could just go with a service provider (like Rackspace / Contegix) that offered more redundancy at the hardware level.

I know the cloud is awesome and all, but having to assume your disks will disappear, fail, go slow at random uncontrollable times is expensive to design around.

If you don't have an elastic load, then the cloud elasticity is pointless - and is ultimately an anchor around your infrastructure.

Nice try, LaunchPad marketing team trying to deflect users from Bitbucket!

I thought that recycling animal waste into the food chain was one of the suspected causes of CJD.

e.g. http://rense.com/general10/MDSS.HTM

It seems like a bad idea to me... (primarily from the unknowns, not the knowns)

Having physical access to the network shouldn't (in a better world) result in such an utter compromise.

With the ability to plug in devices like the Pwn Plug; your network needs to be moderately resilient to attacks from inside.

I don't want different socks every month, I want the same socks all the time.

That way I only ever have 1 mismatched pair (I will concede that I may have several types of socks - boot socks, running socks, cycling socks, business-time socks).

The ladies do not call me fashionable. I can live with that. I am safe in the knowledge that I have matching socks for every* occasion.

* except where prohibited by law