dennisgorelik: 2020-06-13 in my home office (Default)
We are using Amazon SES to send over 10M emails per month.
This is cheap and reliable service, and overall I like it.
However customer support is poor.

Recently, Amazon SES team removed 2 important graphs from their SES dashboard: "Bounce rate" and "Complaints".
Apparently, Amazon SES team decided that customers would be happier to build their own reports on buggy CloudWatch instead of using already prepared report.

I complained that "development" on AWS forum, and here is the reply:
https://forums.aws.amazon.com/thread.jspa?messageID=803845#803845

The proposed solution - does NOT work.

To add an insult to the injury, AWS forum does not allow me to reply yet with a message: "Your message quota has been reached. Please try again later."

Here is my forum reply that I am NOT able to post on AWS forum yet:
===============
@AWSBrentM

1) Thank you for trying to help.
I followed your steps and this produced two graphs to me.
Both graphs have constant horizontal lines at 1.00 level.
So, pretty much, both graphs are totally useless.
https://us-west-2.console.aws.amazon.com/cloudwatch/home?region=us-west-2#dashboards:name=ForumTip

Should I use instead different "metrics" instead of "Bounce" and "Complaint"?
"Reputation.BounceRate" and "Reputation.ComplaintRate" perhaps?

2) Do you know why Amazon SES Team decided to make us (its customers) to jump through the hoops of creating these awkward custom reports instead of just keeping already existing functionality?
This exercise is time-consuming, and while I am troubleshooting cloudwatch app - I am NOT building my own app that pays the bills for all of us.

3) "Your message quota has been reached. Please try again later. " ... this is my second message (and the first message in ~12 hours).
It looks like Amazon SES Team is not eager about receiving feedback...
===============

Accidentally, few days ago I received email from SendGrid rep that suggested me it may be a time to switch away from Amazon SES to SendGrid in order to get a superior customer support.
I asked SendGrid rep what kind of support I may need, got no clear reply. But Amazon SES team seems to be happy to prove their competitors right.

See also: https://dennisgorelik.dreamwidth.org/tag/amazon+ses
dennisgorelik: 2020-06-13 in my home office (Default)
In "Double.NaN != Double.NaN" discussion, [personal profile] ppk_ptichkin linked to Ariane 5 investigation.

My conclusions based on that investigation:
1) Delete unused code from the solution.
2) Make sure that the application is still functional, even in case when an exception happens.
3) Do integration tests.



=======================
http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
e) At 36.7 seconds after H0 (approx. 30 seconds after lift-off) the computer within the back-up inertial reference system, which was working on stand-by for guidance and attitude control, became inoperative. This was caused by an internal variable related to the horizontal velocity of the launcher exceeding a limit which existed in the software of this computer.

f) Approx. 0.05 seconds later the active inertial reference system, identical to the back-up system in hardware and software, failed for the same reason. Since the back-up inertial system was already inoperative, correct guidance and attitude information could no longer be obtained and loss of the mission was inevitable.

g) As a result of its failure, the active inertial reference system transmitted essentially diagnostic information to the launcher's main computer, where it was interpreted as flight data and used for flight control calculations.

h) On the basis of those calculations the main computer commanded the booster nozzles, and somewhat later the main engine nozzle also, to make a large correction for an attitude deviation that had not occurred.

i) A rapid change of attitude occurred which caused the launcher to disintegrate at 39 seconds after H0 due to aerodynamic forces.

.....

m) The inertial reference system of Ariane 5 is essentially common to a system which is presently flying on Ariane 4. The part of the software which caused the interruption in the inertial system computers is used before launch to align the inertial reference system and, in Ariane 4, also to enable a rapid realignment of the system in case of a late hold in the countdown. This realignment function, which does not serve any purpose on Ariane 5, was nevertheless retained for commonality reasons and allowed, as in Ariane 4, to operate for approx. 40 seconds after lift-off.

n) During design of the software of the inertial reference system used for Ariane 4 and Ariane 5, a decision was taken that it was not necessary to protect the inertial system computer from being made inoperative by an excessive value of the variable related to the horizontal velocity, a protection which was provided for several other variables of the alignment software. When taking this design decision, it was not analysed or fully understood which values this particular variable might assume when the alignment software was allowed to operate after lift-off.

o) In Ariane 4 flights using the same type of inertial reference system there has been no such failure because the trajectory during the first 40 seconds of flight is such that the particular variable related to horizontal velocity cannot reach, with an adequate operational margin, a value beyond the limit present in the software.

p) Ariane 5 has a high initial acceleration and a trajectory which leads to a build-up of horizontal velocity which is five times more rapid than for Ariane 4. The higher horizontal velocity of Ariane 5 generated, within the 40-second timeframe, the excessive value which caused the inertial system computers to cease operation.

.....

4. RECOMMENDATIONS

On the basis of its analyses and conclusions, the Board makes the following recommendations.

R1 Switch off the alignment function of the inertial reference system immediately after lift-off. More generally, no software function should run during flight unless it is needed.

R2 Prepare a test facility including as much real equipment as technically feasible, inject realistic input data, and perform complete, closed-loop, system testing. Complete simulations must take place before any mission. A high test coverage has to be obtained.

R3 Do not allow any sensor, such as the inertial reference system, to stop sending best effort data.
=======================

http://juan-gandhi.dreamwidth.org/4017681.html?thread=111407633#cmt111407633
dennisgorelik: 2020-06-13 in my home office (Default)
Couple of weeks ago we noticed that the same C# code executes differently under MSTest and in Visual Studio 2017.
In particular, Uri constructor crashed on invalid input in Visual Studio, but did not crash in MSTest.

Then, several days later, we found that ASP.NET allows to modify collection that we iterate through, but the same code crashes in a unit test with "System.InvalidOperationException: Collection was modified; enumeration operation may not execute".

We decided to investigate and found that the culprit is in a different value of "httpRuntime targetFramework" attribute.

Bad naming and documentation
Microsoft .NET Framework team chose a bad name for that attribute and wrote a misleading documentation:
---
https://msdn.microsoft.com/en-us/library/system.web.httpruntime.targetframework(v=vs.110).aspx
The version of the .NET Framework that the current web application targets.
---

When most developers (including me) read that - they think that "targetFramework" attribute defines what version of .NET framework would execute.

But actually that attribute has a very different meaning and should have been named either compatibilityTargetFramework or quirksTargetFramework.

What httpruntime targetframework actually means
Fortunately, levibroderick wrote a clarifying blog post, that now is the first result for httpRuntime targetFramework search:
https://blogs.msdn.microsoft.com/webdev/2012/11/19/all-about-httpruntime-targetframework/

With new versions of .NET framework, Microsoft .NET team introduced some breaking changes (especially for .NET Framework 4.5).
So then they created "quirks" to fix these breaking changes.

So, "targetFramework" attribute pretty much defines what set of quirks to use (the older the targetFramework version is - the more quirks you would get).
The total number of quirks seems to be around 10 (could be a little bit more or less, but not by a lot).

Practical impact
In the past, our Web.Config did not contain any mentioning of targetFramework in <httpRuntime> element.
That meant that we got all the quirks, so postjobfree.com did not break.
Then yesterday we turned off "legacy compatibility mode" by setting
<httpRuntime targetFramework="4.6.2" />
We lost all the quirks that way and, as a result, got two bugs:
1) "WebForms UnobtrusiveValidationMode requires a ScriptResourceMapping for 'jquery'. Please add a ScriptResourceMapping named jquery(case-sensitive)." crash on every page that contains <form> element.
2) Encrypted validationKey in <machineKey> element changed its meaning, so all users authentication cookies expired.
Several hours of research and development later - we fixed these issues and now our web site runs in a quirks-free mode.

What was your experience in converting legacy .NET app to the new .NET Framework version?
dennisgorelik: 2020-06-13 in my home office (Default)
I asked a developer on my team to commit code frequently: at least once per day or more.
Even if feature is not ready - commit parts of this feature, prototypes, or even mixture of draft code and draft notes.

The developer objected that:
1) Not every feature fits into one day of development. (I agree with that).
2) Commiting raw code, and especially committing raw notes - effectively publishes them.
And publishing raw ideas - makes them to prematurely solidify, which, in turn, negatively affects future research, because there is a bias toward solid ideas, while alternative solutions are more likely to lose even if they are good.
(I kind of agree with that effect, but only partially. Publishing ideas solidify them a little, but that effect is more positive than negative).
3) Commiting/publishing raw notes violates developer's privacy, because raw notes represent unfiltered train of thoughts.
(My thinking is that since these notes were created as an attempt to find a solution to a work problem - there raw notes are very unlikely to contain any personal secrets. Raw notes can still contain weird thoughts or even silly mistakes, but that is OK - there is no need to be ashamed of mistakes in early research thoughts).

My main reasons to have code committed frequently is:
1) Check that work goes in the general direction that is likely to satisfy business goals.
2) Review new research and code in reasonably small chunks, so that code reviewer is able to understand them.
3) See not only final polished solution, but also mistakes and research dead ends along the way. That helps learning more.

What do you think: is trying to commit code at least once per day - too frequent or a good goal?

Profile

dennisgorelik: 2020-06-13 in my home office (Default)
Dennis Gorelik

June 2025

S M T W T F S
1234 567
891011 12 13 14
15161718192021
22232425262728
2930     

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 6th, 2025 09:44 am
Powered by Dreamwidth Studios