She is one of the speakers at the CFObjective Conference and a long-time ColdFusion developer, having worked with CF since the Allaire days, and for many years she authored and sold one of the most popular eCommerce platforms for the language, CFWebstore. Today she works for CFWebtools as a Senior Developer, continuing to support and build large eCommerce websites.
- Why every CFer should be doing error logging
- CF error logging
- Global Error Handler
- Capturing Different Scopes
- Preventing unwieldy numbers of error emails
- Logging to capture larger amounts of data vs. emailing all errors
- Tracking User Actions
- Per user history of pages accessed held in session scope
- Shopping cart contents
- User account info
- JS/Ajax error logging
- Ajax tracker in user session
- Track Ajax request parameters
- Log Ajax response and/or success
- Ajax tracker in user session
- SQL Server error logging
- Stored procedures errors
- Log table to log SP params and info
- Unexpected NULL values
- Strategies for debugging errors on live sites
- Variety of open source and 3rd party solutions for error logging
- Using site analytics to track and fix issues on their live sites
- 404 errors
- 301 redirects
- Log events in analytics
- Search results events
- Full Stack Application performance management tools
- Full user interactions tracking
- Reporting on performance too
- All in one place
- Why are you proud to use CF?
- WWIT for you to make CF more alive this year?
- More developer outreach to bring in new developers – we are still developing it, cool new features
- What are you looking forward to at CFObjective?
Mentioned in this episode
- Mary Jo’s full custom CF error handler
- Only emailing on unique errors
- BuglogHQ – open source CF tool
- FusionReactor for slow CF pages and SQL queries
- Source maps for minified production JS code
- CodeKit (for Mac)
- Jenkins build server
- JSON structure saved to server and displayed with JSON viewer
- Solr search
- Browser Hawk
- Cisco Appdynamics
And to continue learning how to make your ColdFusion apps more modern and alive, I encourage you to download our free ColdFusion Alive Best Practices Checklist.
Because… perhaps you are responsible for a mission-critical or revenue-generating CF application that you don’t trust 100%, where implementing new features is a painful ad-hoc process with slow turnaround even for simple requests.
What if you have no contingency plan for a sudden developer departure or a server outage? Perhaps every time a new freelancer works on your site, something breaks. Or your application availability, security, and reliability are poor.
And if you are depending on ColdFusion for your job, then you can’t afford to let your CF development methods die on the vine.
You’re making a high-stakes bet that everything is going to be OK using the same old app creation ways in that one language — forever.
All it would take is for your fellow CF developer to quit or for your CIO to decide to leave the (falsely) perceived sinking ship of CFML and you could lose everything—your project, your hard-won CF skills, and possibly even your job.
Luckily, there are a number of simple, logical steps you can take now to protect yourself from these obvious risks.
No Brainer ColdFusion Best Practices to Ensure You Thrive No Matter What Happens Next
Modern ColdFusion development best practices that reduce stress, inefficiency, project lifecycle costs while simultaneously increasing project velocity and innovation.
√ Easily create a consistent server architecture across development, testing, and production
√ A modern test environment to prevent bugs from spreading
√ Automated continuous integration tools that work well with CF
√ A portable development environment baked into your codebase… for free!
Learn about these and many more strategies in our free ColdFusion Alive Best Practices Checklist.
Mary Jo is a long-time ColdFusion developer, having worked with CF since the Allaire days, and for many years she authored and sold one of the most popular ecommerce platforms for the language, CFWebstore. Today she works for CFWebtools as a Senior Developer, continuing to support and build large ecommerce websites. In her spare time, she enjoys a wide variety of hobbies, including dog training and showing, sewing, knitting, board gaming, origami, handbell choir and other musical pursuits, and is a reviewer for Amazon products via their Vine program. She is a cancer survivor and suffers from fibromyalgia as well as various RSI issues from years of computer work so encourages young developers to pay attention to their ergonomics and learning how to ensure a healthy work environment. She enjoys cosplaying and attending conventions and runs a Facebook group for Cosplay with Disabilities which helps advocate and support people who cosplay with disabilities and the challenges that entails.
(* WWIT = What Would It Take)
Strategies you can use for debugging errors on a live site. We'll look at some open source and third party solutions for error logging, and how you can use site analytics to track and fix issues on a live site. Also, we'll look at some full stack application performance management tools you may not have used yet that are really handy. So, welcome Mary Jo.
Mary Jo Sminkey: Hi Mike!
Michael: Hey, so let's start off with the 64,000 pound elephant in the room because I bet not everyone listening is doing error logging, and why should they be doing it?
Mary Jo Sminkey: Well, basically when you get customers from emails, from your … Sorry from your customers, or your clients, usually they have absolutely no detail. They just say your website sucks, it's broken, I can't check out. They give you no detail at all. If you've ever tried to get some details from your customers, it usually fails miserably. My goal has always been how can I get enough information about what's happening for the users on the website that I can debug those errors without having to ask them for help because they are going to be absolutely no help at all.
In old days, a lot of us would just check ColdFusion error logs, or email the CF error dump to ourselves. Our applications have gotten a lot more complicated. There's a lot more components to it, so this is often not enough information. My goal has been to continually, gradually, incrementally improve what I'm doing for my, not just my error logging, but the way I notify myself of errors, what's included in that information, and how I can collect enough information about what's going on that I can figure out what the problem is, and fix it.