Orders are not flowing from Magento to our ERP
I’ve been engaged in an ongoing investigation of this nature on a particular project and finally got to the bottom of it today.
The lesson learned…don’t use the config for storing flags.
Let’s take a look at what happened
If you run a Google Search for for “jekyll twitter cards” you’ll come across many articles with instructions for setting up Twitter Cards on a Jekyll blog.
All the posts I’ve read suggest updating layout / template files with the required Twitter Cards
While this is certainly a valid approach, there’s another way to do it that doesn’t require writing any code. Instead this can be handled entirely by jekyll-seo-tag, a GitHub Pages supported Jekyll plugin.
Here’s let’s take a look at how this can be done.
Event Tracking is a useful Google Analytics feature for recording miscellaneous information about how visitors interact with a website.
For example, on this site I use a “taggedPost” event to understand my most popular blog topics by firing an event to report back any tags (e.g. “Security”, “Performance”, “Google Analytics”) associated with a given page.
However, when I first set this up, one thing that I didn’t understand was the impact that firing events has on bounce rate.
Have you ever heard anyone say this?
We turn off logging in production for performance reasons.
Maybe, it’s even something you’ve said yourself?
Over the years, I’ve heard people say many things that effectively throw auditability out the window in the name of performance. Here are just a few…
innodb_print_all_deadlockssetting for performance reasons”
But here’s the thing, while I generally support decisions made in the name of performance, I also know from first hand experience that it’s imperative that your application leave a thorough audit trail in order to solve strange and unexpected production issues.
To demonstrate this, let’s examine the implications of the a couple of the statements listed above…
A while back I wrote a general article about HTTP response header limits. The post was written in response to an issue I was dealing with where a CDN was serving a 502 when the origin served more than 8192 bytes of headers.
Recently, I’ve been investigating yet another issue with HTTP response header size limits, this time specifically with Apache’s mod_proxy_fcgi module. Here, I’ll document my experience and findings…
Code review etiquette is an interesting subject.
A few months back an article was published to CSS-Tricks titled “Code Review Etiquette”. It outlines some general pointers for reviewers to keep in mind when doing code reviews.
In this post, I’ll make some etiquette suggestions that apply to a more specific part of the code review process…addressing code review comments.
We’ll look at this from the perspective of both the reviewer and the contributor.