jcoby

Turns out I was remembering wrong. The A- downgrade was from not supporting forward-secrecy in all reference browsers which is an issue with openssl than the recommended cipher suites.

AFAIK it's also impossible to get an A+ if you want to support older browsers and OSs (the intermediate and old settings from this site) due to BEAST. Seems like XP, Vista, and IE <= 9 were all affected by using the modern cypher suite from Mozilla (they all got a F).

I wasn't able to find a way to do server-side BEAST mitigation that didn't involve re-enabling RC4 ciphers (which is a far worse option). SSLLabs automatically downgrades any site that doesn't do BEAST mitigation to an A-.

I also was unable to get forward-secrecy working with all reference browsers using the intermediate setting.

The Falcon 9 still has to deal with heat cycles, vibration, and soot/chemicals byproducts from the engines. The heat cycles and vibration lead to work hardening and cracking or softening of components. Soot can and will get into everything and destroy bearings and connectors.

Even the spray from the ocean combined with the heat from the latent heat in the craft can lead to accelerated corrosion.

They're shooting for a final touchdown speed of 2m/s which seems fairly slow but that's still a lot of mass to stop very quickly. The ocean helps soften touchdown for sure.

It would not surprise me if the turn around procedure was to r&r the entire bottom third of the craft and (possibly) the fuel tanks. The removed components could get inspected and rebuilt and flown again.

It won't be anywhere near the scale of the shuttle turn around but it won't be as simple as hosing it off and fueling it up.

SpaceX has of course considered all of these things and it will be an amazing thing for space travel if they pull it off.

Thanks, but that's a wholly separate issue from what I was talking about.

When you have UTF8 data in the IPN, PayPal translates it to win1252 in the IPN. But it verifies the IPN against the original UTF8 data. The only way to fix it is to go into the profile and change the IPN format to use UTF8. There is no programmatic way to set the encoding for IPNs to be sent in and there are no workarounds that I am aware of.

If you never see international names or addresses with accents and diacritics you won't run into the problem.

Google Checkout was awful to work with. It was hard for the vendor to setup and use. It was hard to program against. It was hard for the customer to use. It was hard to test. And of course it had Google's famous lack of support.

Speaking of support, we qualified for the integration reward ($1500 or so; maybe more). We tried to claim the reward for over a year. Every time they'd say "yeah you totally qualify!" and we'd ask how to claim the reward and then silence. Of course every email response took 3-7 days. A few months later we'd go through the same process. Still waiting on that check to arrive.

We supported it for about a year and eventually gave up. Payment notifications could take up to a minute to arrive. You couldn't specify the tax (or shipping from what I remember) for an order in any sane way. For a while it was over 50% of our support tickets while being used by less than 10% of our customers and less than 1% of all transactions.

I was so happy to delete it from our codebase. And we won't support any payment processor they have to offer anytime soon.

IPNs are annoyingly difficult to use.

Some accounts simply will not send them until an IPN URL is set, even for transactions that include the notify_url in the request. You cannot even see the IPN history until you enter an IPN URL, even if it was used through the notify_url param.

IPNs that include UTF8 characters will not validate by default in most PayPal accounts. PayPal defaults to Win1252, translates the UTF8 content to Win1252, tells you it's Win1252 and then seems to validate the IPN against the original UTF8 data. I have never been able to validate a Win1252 IPN that had UTF8 content. I've tried iconv, stripping bits, and plain substitutions (ü -> u). Nothing seems to work. This seems to be getting better though.

For about 2 months last year they forgot to include a field that had to be added in order to verify the IPN. And you had to iterate through a few different values to see which one was correct. So we got a rash of support tickets asking why our customers were suddenly getting notifications of issues verifying PayPal purchases and were having to manually approve orders. I submitted a ticket after a day of dealing with the issue and got a response about 2 weeks after they fixed the issue. There was no indication of the problem on their status site.

The IPN verification service randomly returns INVALID for valid data or simply doesn't work. Sometimes IPNs are delayed.

Dealing with the PayPal APIs are far, far harder than their sales sites would have you believe.

I've heard that starting pay for ATP or cargo is somewhere in the low $20s and schooling is in the mid $100s. Is there any truth to that?

True. Or they bought the plane 20+ years ago and still own it.

When I go to EAA meetings I'm the youngest by 15-20 years and I'm in my 30s. I don't think I've ever seen a privately owned certified plane that was newer than 25 years old.

It's all around a bad situation for general aviation.

The private pilot is a dying breed. Skyrocketing costs make it all but impossible for most people to get into. Even getting your private pilot's license often costs $8k-$10k. And then you are looking at $150/hr to fly a 20-30 year old C172.

These skyrocketing costs make it so the fleet ages and becomes less reliable. So people get out. Or they die because they can't fly enough to get experience or the aircraft has a problem because it isn't flown enough.

And costs rise further because there is no market. It's a downward spiral. And it seems that the FAA is completely happy with the situation.

I've been out on beautiful days (low 80s, calm, 10 mi vis) and the CTAF is all but dead. Even 5 years ago there would have been 2-3 in the pattern and I would have heard a steady stream of traffic around the other 5 airports in the same frequency.

In the US an ultralight has to be under 254 pounds and does not require any training or licensing to fly. In most other countries an ultralight is more like the sport class in the US.

At 254 pounds you want light and simple. FBW requires actuators. And controllers. And sensors. And power. And then you have to double up everything for redundancy. You would easily eat up 50 lbs or more making a reliable FBW system and it would cost 3-4x what the entire aircraft cost.

Even with normal light aircraft a FBW system is both unneeded and overly complex. Cables and pulleys are extremely reliable. They are inspected every year (along with the engine and various other pieces of the aircraft).

I don't think body shops will much care either way once they get over the initial shock and how to prep for paint. Most body work these days is remove & replace of large panels. Instead of welding they will have to use adhesives (or train their workers to use a TIG) and they will need to have a dedicated set of abrasives for the aluminum work.

Aluminum damage to the structural (sub)frame is a whole different beast than in the (non-structural) body panels. Aluminum work hardens when bent. When it hardens it become brittle and can crack from stress and vibration. Any damage has to be completely replaced with fresh metal.

Corrosion is still an issue with aluminum though it tends to self-protect itself. If you really want to mess up something aluminum add some mercury..

FAR 91.21 is the rule that is being enforced:

(a) Except as provided in paragraph (b) of this section, no person may operate, nor may any operator or pilot in command of an aircraft allow the operation of, any portable electronic device on any of the following U.S.-registered civil aircraft: (1) Aircraft operated by a holder of an air carrier operating certificate or an operating certificate; or (2) Any other aircraft while it is operated under IFR. (b) Paragraph (a) of this section does not apply to— (1) Portable voice recorders; (2) Hearing aids; (3) Heart pacemakers; (4) Electric shavers; or (5) Any other portable electronic device that the operator of the aircraft has determined will not cause interference with the navigation or communication system of the aircraft on which it is to be used. (c) In the case of an aircraft operated by a holder of an air carrier operating certificate or an operating certificate, the determination required by paragraph (b)(5) of this section shall be made by that operator of the aircraft on which the particular device is to be used. In the case of other aircraft, the determination may be made by the pilot in command or other operator of the aircraft.

Advisory Circular (AC) 91.21-1B is the recommended implementation of FAR 91.21 and includes the take off/landing and operation below 10,000 rules and seems to be what everyone is using.

I assume that it's AC 91.21-1B that is being modified. Its text is too big to paste here but you can read it here: http://www.faa.gov/documentLibrary/media/Advisory_Circular/A...

A few things really stand out for me:

1) I am shocked how slow EC2 is and how expensive. A m1.large is $0.240/hr or ~$175/month. And it's 7-10x slower than a $350/mo dedicated box. You would be spending $1500/mo to equal one dedicated box (not including bandwidth and S3 fees). A reserved instance is cheaper of course.

2) The multiple queries test would seem to be the best one to really simulate real-world usage. JSON-serialization is mostly testing the language.

This test pretty much puts most of the interpreted languages on a full stack framework together at the bottom. Although django seems to come out at the bottom of the pack for some reason.

Then come the "raw" tests and JIT languages running full stack frameworks. And at the top are the compiled languages. Not really surprising there.

3) I'm surprised php-raw did so well. And that go did so poorly.

You will know when it becomes a problem. The helpdesk gets flooded. Servers go down. You get white pages and 500 internal server error pages. The entire site folds because a mouse farts.

You add new servers and they get crushed. You scrutinize every line of code and fix algorithms and cache whatever is possible and you still can't keep up. You look at your full stack configuration and tune settings. You are afraid of growth because it will bring the site down. THEN you know it's time to consider switching frameworks. And even then I would try to find the core of the problem and rewrite that one piece.

Rewriting an app in a new framework can kill a company. Be leery of starting over. I personally know of one company who started over some 4+ years ago because the old app was too hard to maintain and only started rolling out the new app last year to extremely poor reception (even with about 1/2 the features of the old app). The reception was so bad that they had to stop rolling it out until it was fixed. They could have easily spent a year improving the old app and would be miles ahead.

That's not to say that all problems are due to the framework either. I've had web servers go unresponsive for 20+ minutes because apache went into the swap of death because KeepAlive was set to 15s and MaxClients was set to a value that would exceed available RAM. The quickest solution was to cycle the box. This was 10 years ago though and I think I had a total of 1GB of ram to work with.

I went through your list and know the answer to nearly all of them. Hell I've run into most of those problems and more. (Except for the motorcycle battery; I have used my charger on my bike battery several times at the 5A 12V setting with no problems. I remove it completely during charging though.)

I was taught by my dad. He was taught by his dad. I learned to rebuild an engine at around 11 and I helped build two houses by the time I was 16. I have rebuilt two cars and fixed (and broken!) countless others. I have done general construction and carpentry.

I'm happy to share my knowledge. But I've found that the people who could learn the most are the most resistant to learning. They get offended when I ask if they did something. Asking questions is how you avoid mistakes. They feel like it's an affront to their manhood when I offer to help. That they should be able to do it on their own.

I don't understand it. I know I don't know everything and am happy to learn from those who know more than I do.

PS, don't forget to use a hammer drill with that masonry bit or you'll be there a long, long time. And to put some plumber's putty behind that faucet flange (but leave a gap at the bottom for water to run out). Your studs are 16" on center unless they're 20" or 24". Tap tap tap. Unless you are working with plaster & lathe. My area has a hazardous waste facility that's open to anyone living within the county. Antifreeze, solvents, paints, etc are all welcome.

Why would you brine a chicken breast for 24 hours!? Wouldn't this account for the difference in texture? With the surface area to mass ratio as one breast has that would be like brining a turkey for a month (maybe more).

Everything I've ever read says that 30-60 minutes is plenty for a breast. Even Alton Brown's fried turkey recipe [1] recommends 8-16 hours for a whole 13-14lb turkey.

The other thing not addressed in the article is the target cooking temperature and rest time. Did he pull them at the USDA-recommended 165° or did he pull them earlier and let them come up to 165°? Were the cuts allowed to rest?

1: http://www.foodnetwork.com/recipes/alton-brown/deep-fried-tu...

It's a limitation of MySQL unfortunately. MySQL does schema changes by creating a new table with the new schema and copying the old data into it and doing an atomic switch over. The table gets locked for obvious reasons.

Percona has pt-online-schema-change [1] but I have no experience with it or if it works on RDS.

There are other solutions. The most simple is doing the table rewrite yourself (but risking losing data). The more complex is to have a buffer/queue that can hold requests until the migration completes but this only works in certain specialized situations.

I'd love to find a better solution to migrations in MySQL. I've had migrations take 15 minutes on a relatively small table (2M rows). I'm a little scared to try pt-online-schema-change for fear of corrupting the db.

I would switch to PostgreSQL (nothing but love for that database from me) but the ORM I'm using has issues with identifier quoting and I can't use my "user" table with it.

1: http://www.percona.com/doc/percona-toolkit/2.1/pt-online-sch...

This was pretty much the only thing SendGrid could have done in this situation. I haven't seen this much stink over a person's actions at a conference in a long time.

I do have to wonder: does this open SendGrid up to litigation by publicly announcing her termination? Affecting future employability, etc (not that she isn't at fault for that here).

That first link looks like exactly what I need, thank you!

I've tried Fedora in the past. I found it unstable and broken and I don't like RPM very much. It's undoubtedly improved since I last tried it (c. 2005-2006) but I don't miss RPM at all.

That's pretty much exactly what I try to do. I grab the sources for the package and upgrade the underlying php version. I usually have to grab the PHP sources from a newer version of Ubuntu and modify it until it builds.

Consistency. I use the system packages right now and Ubuntu does some tricks with the config that I'm used to.

There is no real compelling reason for me to upgrade. The short array syntax is nice but it's not worth spending a day or more interrupting everyone's dev environments and building packages and introducing (potential) instability into something that I live off of.

Personally, I always wait at least one year before upgrading PHP. There are always segfault or security issues or odd problems in a 5.x.0 release. It's around 5.x.4 that it becomes just stable enough to use.

About a month or two before I decide to upgrade I run the newer version locally while I'm developing (but being sure to not use any newer features). This usually weeds out any major incompatibilities and fix new warnings.

That said, I'm running 5.3 in production and have no real plans to upgrade to 5.4 anytime soon.

There is a PHP 5.3.7+ implementation of the password API here: https://github.com/ircmaxell/password_compat

I went on a framework binge over the past two weeks to see what the state of web development was. I looked at a dozen or so frameworks including Go frameworks. I came to the same conclusion you did.

Revel was the most promising Go web framework that I saw though very immature.

Go ORMs aren't ORMs. They are object persistence frameworks (at best). None of them really provide the "R" in ORM. Most of them basically do "SELECT * FROM table WHERE id=12" and dump that into a struct. There goes the "M" as well.

The Go language itself is very nice to work with though. It's a great language. Give it 2-3 more years and a truly usable ORM and web framework will crop up.

NULL is one of the most powerful features of SQL. It simply means a lack of data. This means it is neither equal nor not equal to anything else (including NULL). NULL is not a value; it's a state of non-existence.

So, for example, if you were providing a survey with an optional question with a yes/no answer. NULL would mean "no answer", false would mean "no", and true would mean "yes". Storing the "no answer" as a false would be incorrect since they did not answer the question.

It could also happen if you were adding a new column. Existing rows do not have data and would deserve a NULL unless you had a deterministic way to fill in a true or false value.

I watched this for three minutes and in that time its value went from 37 to nearly 40 and back to 37 again. Several times.

How in the world can you use a currency that changes value by almost 10% every 60 seconds?

I would think that without thrusters that it would be unable to dock with the ISS.

According to http://www.spaceflightnow.com/falcon9/005/status.html

    SpaceX says one thruster pod is working, and two are "preferred" to deploy solar arrays. Four thruster pods are on the Dragon spacecraft.

    "We are working to bring up the other two in order to plan the next series of burns to get to station," a SpaceX spokesperson says.

And at 11:40 EST:

    "Thruster pod 3 tank pressure trending positive. Preparing to deploy solar arrays," Musk just tweeted.

    At least two thruster pods are needed to deploy the power-generating solar arrays, which stretch 54 feet tip-to-tip.

So it's looking positive that they'll recover from this.

Oh wow, that's even worse news. Hopefully the override works.

People seem to think it's an issue with the solar panels on twitter. It's looking like the solar panels didn't deploy.