Posts tagged as tech
Image
I am now Kloutless.
Why?
It’s not as useful as I thought it would be. The inexplicable score changes for me and others make it an unreliable measure of anything. They’ve proven themselves to be so unpredictable another individual’s Klout score is not actionable.
Note that this opinion is my own: not my employer’s, former employer’s, etc. etc. I just don’t find it useful, and have no intent to proceed with my plan to use Klout scores in Jexy support dashboards.
Text
Fundraising Lessons from The Gambler
You got to know when to hold ‘em, know when to fold ‘em,
Know when to walk away and know when to run.-“The Gambler” by Kenny Rogers
When raising money for a new business, there are times when you find people that you genuinely like. You’d hang out with them, drink beers with them, and certainly go into the trenches with them.
This is all good. It feels great. You’re raising money, and you genuinely like the person you’re pitching! She seems to like you too. Despite numerous articles out there pointing out that investors are not your friends, they’re not supposed to be people you can’t stand hanging out with either.
It feels like it’s all but in the bag. But for one reason or another, it doesn’t come together. It’s tempting to keep pushing, since you’ve got good rapport, to get to a real yes or no answer. Try not to do that.
Instead, take a hard look at the situation. The person on the other side of the table may really like you too. She may believe you’re a capable entrepreneur, she may think you’re smart, she may think you’re great in many ways. But if she doesn’t believe in your business, she won’t pull the trigger just because she likes you.
Don’t get hung up on the bullshit you read about “we invest in people, not ideas”, because that’s just one of the many white lies you’ll hear out on the fundraising trail. Ultimately, it’s bullshit: the investors have limited cash to invest, and they need to see returns. They won’t bet on people who have ideas they don’t believe in, because they’re not in the bank-account-filling business. They’re in the returns-on-investment business, and there are too many people out there who may have ideas they do believe in and are people they ALSO like. Guess where the cash is going?
That’s not a reason to burn the bridge. Remember that it’s a small community, and that in 3-5 years (or less, if she was right about your idea not having legs), you may be back with another idea that she likes better. She’ll probably still like you as a person, and if you didn’t push them into some awkward corner of saying “let’s just be friends”, then she’ll be happy to hear from you.
Read the signals. Identify wrong trees that need no further barking up. Know when to walk away.
Update: A few people have emailed to ask if the subtext in this post is that Jexy isn’t going to happen. That’s not the case: Jexy is happening!
Text
SSL, php-fpm and nginx
Like many switching to the nginx/php-fpm combo, I ran into a situation with some PHP scripts that relied on $_SERVER[“HTTPS”] having a value of ‘on’. As of nginx 1.0.4, this isn’t provided out of the box. Of course, the rest of the $_SERVER[“SSL_*”] values that are present under Apache and mod_php (or php-fpm) aren’t available either.
The closest approximation I could come up with to Apache’s mod_ssl +StdEnvVars for nginx is this: create a file in your nginx config directory (commonly /usr/local/nginx/conf) called fastcgi_ssl.conf. Add the following to it:
# Provide as much of Apache's SSL +StdEnvVars data as possible.
fastcgi_param HTTPS on;
fastcgi_param SSL_PROTOCOL $ssl_protocol;
fastcgi_param SSL_CIPHER $ssl_cipher;
fastcgi_param SSL_SESSION_ID $ssl_session_id;
fastcgi_param SSL_CLIENT_VERIFY $ssl_client_verify;
# _SERVER entries for these will be empty unless you
# rely on client-side certs you've issued
#fastcgi_param SSL_CLIENT_CERT $ssl_client_cert;
#fastcgi_param SSL_CLIENT_RAW_CERT $ssl_client_raw_cert;
#fastcgi_param SSL_CLIENT_S_DN $ssl_client_s_dn;
#fastcgi_param SSL_CLIENT_I_DN $ssl_client_i_dn;
#fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial;
Include this file only inside server {} blocks that are configured for SSL use in nginx, and you’ll find that a environment checks for HTTPS work a lot better from within PHP.
Text
Getting PEAR2 Pyrus Running
I had a heck of a time getting PEAR2’s pyrus.phar 2.0.0a3 running. I downloaded pyrus.phar, ran ‘php pyrus.phar list-packages’ and got nothing.
Turns out the problem was having Suhosin installed as well. Once I added:
suhosin.executor.include.whitelist=”phar”
… to my php.ini directives, ‘php pyrus.phar list-packages’ gave me a list of packages.
I always forget this, but the trick is always remember: if it doesn’t work for some reason, check suhosin settings. Make sure you have suhosin logging turned on, and check the log!
Text
RESTful Routing, LocationMatch, ForceType and SetHandler
For years I’ve been seeing articles about RESTful routing, and watching developers contort their code including route aware this and that. All these gyrations come with a performance penalty, not to mention a code maintenance cost. (More lines to maintain = more pain in the ass.)
There are a few brave souls who’ve bucked this trend and gone with the original tools designed for this job — mod_rewrite and the like.
What I haven’t seen much that makes perfect sense to me is extension-free files with a ForceType or SetHandler directive applied to them.
I know examples with Apache and PHP show that I’m a geezer, but humor me anyway.
In either case, you create a file called ‘foo’ (no extension) in your document root. In it, you put something like this:
How you’d do this with funky new stuff such as Lighty, Nginx, and node.js, I don’t know exactly. I’m sure it’s possible. But, it’s an exercise for those of you fascinated by the shiny and the new.
The point is this: save your CPU cycles for the stuff that actually matters. Leave the easy stuff like routing where it belongs: outside your app.
Text
AWS CloudFront Invalidation Quickie
Got something up on AWS CloudFront that’s not what it’s supposed to be? Use this quickie script to zap those mistakes. No external libraries required, no fancy and overly complex signature routines. Just a simple, quick script that’s not even worth a repo. Copy, paste, tweak, zap, and exhale.
Excessive use of this script may run up a tab at Amazon.
No additional charge for the first 1,000 files that you request for invalidation each month. $0.005 per file listed in your invalidation requests thereafter.
See CloudFront pricing for more details.
Text
Failure Is Not An Option
Gene Kranz was 37 years old when Apollo 13, the space mission he served on as lead Flight Director, launched. A few days after takeoff, the Apollo 13 Service Module exploded, jeopardizing the lives of the three astronauts on board. While he never used the phrase “Failure Is Not An Option” (other than in the film version of the story), it was the attitude of mission control.
In light of the AWS EC2 crisis, which has left some companies with their services crippled or completely disabled for over 24 hours, it’s a good time to reflect on whether or not failure is an option to you. I know that most of us aren’t writing software controlling the launch codes, but we are writing software that businesses, and therefore people’s livelihoods, are dependent upon.
Evan Cooke, Twilio’s CTO, wrote a great post yesterday about how they managed to avoid any downtime. Pay attention to his update at the end of the post regarding how they’ve resisted EBS adoption.
By the way…
At Mashery, we did extensive I/O testing on EBS versus RAID0 striped ephemeral stores, and there’s no comparison. RAID0 blows EBS away on performance. Sure, you don’t get the magical features off-the-shelf that Amazon provides for EBS, but then again … how magical are those features feeling today?
So ask yourself: is failure an option?
The Choice is Yours
(Link)
When you’re designing a system, you make tradeoffs. Choices. You must choose among variables like:
- Development speed/Time-to-market
- Development cost
- Ongoing costs
- Quality
- Performance
- Resiliency
- Durability
… just to name a few. Most people are familiar with the Project Triangle: “Good, Fast and Cheap: Choose any two” … but a simple triangle doesn’t fit today’s projects.
Most of the above items are self-explanatory, but I specifically separated resiliency and durability. A project/site/service may be resilient, which to me means it can go down and bounce back quickly. A durable site, on the other hand, won’t go down. There’s also a variance between the two on whether or not a site can rebound without data loss. A resilient service may bounce back, but suffer data loss … or, perhaps a resilient site doesn’t have any data to worry about. There aren’t many services that have value without some data, but many services provide value with minimal data dependencies.
Heed The Heptmogrifier
As a handy reminder, I give you … The Heptmogrifier. Adjust as you like, but remember that your head will explode if you try to set all sliders to the max.
(I know “performant” isn’t really a word, but it’s used often enough that I’ll deal with those complaints.)
This is what you’re really working with when you deal with “internet-scale” applications.
The traditional good/fast/cheap tradeoffs will dictate the project’s code quality. But those three factors are influenced heavily by the choices you make about the other four.
Sustainable: How much is this thing going to cost to keep running, given the choices made?
Durable: How susceptible is the service to failure? More importantly, how likely is data loss as a result of failure?
Resilient: How quickly can the service recover from a failure? It’s extremely difficult for a service to have zero downtime. So, even if you’re building something durable, factor in what it takes to failover. Example: a DNS TTL of 60 seconds, with an every-30-second health check and a two-strikes policy, might take as much as 120 seconds to detect a failure and switch traffic elsewhere.
Performant: How do the choices you make in other areas affect performance overall? Or, perhaps some aspects of the system will need performance expectation adjustments based on the choices you make around durability?
Not all of these choices are as painful as they sound. A comment on my previous post suggested that latency was too high across regions to consider. This simply isn’t true for most applications. A half-second lag for master-slave replication across the United States is nothing when you consider that you’ll be able to cut over to that other region in 2 minutes, promote that slave to a master, and be back up and running before most people finish reading the TechCrunch article about how the sky has fallen.
Talk to Your Investors/Stakeholders
They probably don’t care about the technical details, but they will certainly care about their investment going down the tubes because the service they invested in goes toes up due to incomplete failure planning. It’s not a popular conversation, and “how will I scale?” is often how questions about uptime and availability are framed.
It’s time to think about it differently. I agree that scaling to millions of users is a nice problem to have — a “high class problem,” as a friend is fond of saying. However, surviving an outage like what’s happening with Amazon EC2 East is an entirely different story. Your service may find it difficult to get to 10,000 users if it faceplants every time an upstream provider has a hiccup. (Investors, please weigh in below — feel free to call bullshit if I’m off the mark.) Make sure you and your other stakeholders are on the same page.
Take control of your destiny.
Reject failure as an option.
In doing so, you’ll not only live to fight another day, you’ll be around to take customers your competitors alienated by choosing … poorly.
Image credits: NASA, Indiana Jones and The Last Crusade
- Older
- Page 1 of 2
