HN user

piggity

145 karma
Posts1
Comments71
View on HN

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.

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.

Mailchimp's pricing 13 years ago

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.

Project Shield 13 years ago

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.

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.

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.

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.

Status Board 13 years ago

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

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.

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.

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