You can listen to the podcast and read the show notes here
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.
Michael: Okay, so sounds like it's a good thing to be logging errors. Dumb question here, why not just use the default error screen where it displays the error on the screen?
Mary Jo Sminkey: Well, that's going to again appear for the client. It's only going to dump out a certain small amount of information from the ColdFusion error. It may not include everything that happened up to that problem to cause that problem. It's not gonna include all your different scopes of information that you need and it's gonna rely on that user actually sending you that error whereas a lot of times they're just gonna say, “Screw this site, I'm gonna go shop somewhere else where I don't have a problem.”
So not only do we need to show them a friendly error and let them know that okay we're aware there's a problem and that we need to fix it but we need a way to collect all the information of what happened to cause that error and its even a lot more complicated these days cause a lot of times there's several steps that lead up to that error occurring that we want to know about as well.
Mary Jo Sminkey: Yeah exactly, and that error may happen in an Ajax call as part of that and the users not even gonna see anything they're just gonna have to have a big spinning wheel on their website cause something's not [inaudible 00:03:42] and they'll just be like, “I don't know what to do”
Michael: Right, so sounds like you been doing error logging for a long time, do you have any idea how many more errors it captures versus just assuming your users are gonna tell you about errors? Is it like 10 times as many or 100 times as many or …
Obviously it's gonna depend on how much you do in terms of how you log your errors, what you're going to log and what you've done previously doing that.
Michael: Is this something we should only be doing on public sites or you should do it on Internets … an enterprise system as well?
Michael: Let's start when looking at ColdFusion error logging. How do you suggest people do that? Is that a try-catch or CF error or something else?
Mary Jo Sminkey: Well I actually did a presentation at cf.Objective a couple years ago and I started doing a series of blogs. Blog articles that went out on my full scale error handler that I use. And the number of things that I do with it, one is that I dump out all the different scopes that are available. A lot of times if I'm debugging a particular error that occurs inside a [CFC 00:06:11] I'll even take my local scope and copy that into request scope inside my CF cache so I have access to that data as well. Then I have a whole notification process that happens with that so that, let's say I do something on my website that causes an infinite loop, I don't want to suddenly get millions of errors being emailed to me. It keeps tracking application scope of errors that have already been sent to me by email and it only notifies me if it starts seeing multiples of those come through.
That way I don't get an email for every single instance of an error that occurs. What I did-
Michael: That's really smart. And that was a real problem I had with this.
Mary Jo Sminkey: Oh [crosstalk 00:06:52].
Well that's what a lot of developers are not paying attention to their ColdFusion errors even if they do have an email notification system because they get too many of them and they just don't want to read through them all. By just doing something as simple as keeping track of which ones you've already emailed yourself that day and only emailing if you start getting lots of multiples so that you do know if there's a problem occurring and you suddenly get multiples. It makes it a lot easier to take care of these errors and not let them pile up.Just something simple like that can really help you in terms of your error management.
That used to be all I did but then one of the issues we have on our current sites, we have certain errors that we know occur frequently. We don't have control of the database and they house their database on a completely other end of the country from the website. We tend to get time outs and that's just something we cannot do anything about other than make sure we don't get lots and lots of them. Then we know there's a problem. I don't really care about getting email notifications for database timeouts so I started integrating into this system, lists of errors that I don't want to get notified about. Its important that if something does happen where I need to go back and take a look at a specific error, I need to have them logged somewhere so I can see how many of these are we getting per day. Is there a particular one that I need to investigate a little closer.
If I'm not emailing them to myself, I want them still logged somewhere. That's where we started looking at logging these errors as they occur. Like where there's other places where I use my email handler within CF caches and a lot of times I just want to catch that error log it, I don't really need to get notified about it for that particular reason cause I know that that's something I already handled but I do want to know about that error again so that we can keep track of how often these are occurring and if there's some other way that we can handle them.
Logging gives you a little bit more flexibility in terms of what you can do with your errors so that you don't have to be dumping them all out into email or into logs or other types [inaudible 00:09:07]. But you can still collect data on them and see how much certain types of errors are occurring.
Michael: That sounds like a clever way of doing it Mary Jo, so do you have any other things you do with CF errors? You say you're emailing them but are you also sticking the in a log file? Or somewhere else or …
Michael: What the third party logging system you use?
What's cool about it is if you can send out something via a REST call, you can log it in there you can create your own collector basically pour something in it. Prior to using Bugsnag, we used BugLogHQ, which is a open source ColdFusion tool for logging errors it's really quite nice and as far as know, that's still out there and available to use.
That as well, you don't have to only use it for ColdFusion errors but it is specifically built for ColdFusion errors and again it can use just a REST call, so you just collect all the data you want to send into it and I just built that into my whole ColdFusion global error handler as part of … if I'm gonna email it or if I'm gonna log it or if I'm gonna do both I just collect all that data, [inaudible 00:11:05] it out to a JSON and then send it to [inaudible 00:11:09] whichever notifier that's collecting that data.
Michael: So Bugsnag is a way of collecting bugs, a kind of bug tracking database app? It that right or …
Mary Jo Sminkey: Yes, basically. So it's a third party system. I think they do have a free version you can use to a certain degree. We do pay for the service because of the amount that we use it. The nice thing too, is when you use these logging systems like Bugsnag or BugHQ, oh BugLogHQ, generally they have a email subscription service as well in terms of how often you want to get notified of your errors. If you're working in a company where different developers are working on the projects, its nice that they can be able to handle themselves, which projects they want to subscribe to, getting bug notifications from and then they're done working on that project they can unsubscribe from those.
You can customize how often you want to get notified you can get notifications the first time a bug happens or for every X number of instances of that bug. In Bugsnag you can mark bugs as fixed and then if that bug occurs again, be re-notified of it. You can get a daily digest of all the bugs. It will notify you of a certain project is suddenly seeing a big increase in bugs, which is nice to know about when you're pushing out new releases, it will let you know if there's a sudden increase in errors occurring.
There's a lot that these systems can do. Then a lot of the data is searchable as well. So if I have a particular customer complaining of errors, I can look up their IP address in my bug system and find out, are there any errors logged for that particular user.
Michael: Well that's nice, so you can, if they manually notify you they're having [inaudible 00:13:08] you can go in and see all the stuff that's being [inaudible 00:13:11] for that particular person.
Mary Jo Sminkey: Yes, correct.
Where we really had to work on how we were gonna capture bugs was in our Ajax calls. For one thing we want to … we're calling ColdFusion on the back end but then it's integrating into this Ajax call. We need to figure out what's going on in there. What data is being sent to ColdFusion and still handle it has on a friendly way for the user. I kind of do integration of Bugsnag along with ColdFusion where I'm using the session to kind of track what's occurring in Ajax layer on the ColdFusion side and then sending out that whole structure to Bugsnag when an error occurs.
So when, in my Ajax error handling, I'm doing a call out to Bugsnag where I collect all that ColdFusion data and then send that out as part of the error trapping inside of the Ajax call and then I just present a friendly error to the user.
Michael: They actually get to know that there's an error happening instead of the thing just spinning away there.
Mary Jo Sminkey: Yes exactly. And my … our Ajax, since we do tend to have these database timeouts I basically do three attempts on any Ajax call. If it's timing out, to give it a couple extra tries to make sure there's just a time out issue and that will usually be enough but if it fails on the third attempt then it's gonna log the error out and then notify the user that there was a problem.
Then again if they notify me that, then what I can do is I can take that IP address, look it up in Bugsnag and then what I'm gonna find is this whole big structure that tells me, here's the Ajax request that was happening and here's whatever I logged in terms of my ColdFusion and I may log just the request to the Ajax, or I may log the response or I may just log was it a success or was there a time out, or what happened that cause it to fail. That's all gonna be part of this ColdFusion structure.
Then I often bring in metrics on the user as well, what browser they were on, you know all that kind of stuff that can often be a part of what's happening in terms of your errors. What OS and browser they were on usually had the most important stuff where they logged in at the time.
Then the other thing that I do that has become a real important thing with my, not just my error handling but just my overall strategy for how well the website is working in terms of being able to respond to customer complaints is in the session, I keep track of the last … I think I'm currently tracking the last 20 page request that the customer does. A lot of times if my-
Michael: Oh you have a session variable that tracks that so you can see what their navigation through the site was and how they got to the error?
Mary Jo Sminkey: Correct, correct. So if you're doing anything like an [NBC 00:17:00] where everything goes to just the central controller, it's just a matter of setting up this session, variable and then just each page request pushing in what that was and you know if its over 20, pushing out the last one.
Then that … not only do I drop it into my errors handling, we push all our users to a single contact page, like most people do, but if you don't do that, you're missing out on being able to do a lot of cool stuff, putting a lot of cool information into the emails that your customer sends us.
So if they send me something and say, “Your site search sucks, I can't find what I'm looking for,” I can go right down into this debug and say well here, I can see what their searches were, and I can see “Oh you misspelled the word you're searching for, idiot.”
I can write back to them and say, “Okay well that's not how you spell that word and that's why our search can't find it.”
I'll say it a little nicer so. I can actually see what they were doing that's causing them to have problems on the search and then likewise in … what I'm looking at the actual, if there was an actual error that occurs I can kind of see these were the steps they took prior to this occurring.
A lot of times that is such critical information to have in terms of why things occur on a website. But yeah, if you have a site that uses, like searches … like you have a eCommerce site, that can be such critical information in terms of helping your customers out. Then the other thing I dump into every customer email is their shopping cart. That again can help you out if you're trying to debug why their checkout isn't working. A lot of times that's related to what's in their shopping cart.
I have [inaudible 00:18:47] that information in there, just automatically for every customer email. It saves us a lot of back and forth with the user trying to figure out what's happening. If they're logged in, I'll put in all their contact information, their address and stuff like that so … Anything about the user, got to be helpful for me to figure out why things are not occurring properly for them is helpful. And it's very helpful for the support staff that generally handles these emails often. I don't generally always deal with customers directly. I will generally screen a lot of the ones that come through for webmaster type issues and login issues or problems checking out, things like that.
Michael: That sounds a great way to do it cause otherwise you have to be asking the customer for this info and they wouldn't remember it anyway.
Mary Jo Sminkey: Right, right. Again, customers are useless to help you debug your website unless you can convince them to get on a conference call with you where you can open up your developer console. Most of the time, they're just not gonna be any help with these kind of full stack applications that we do. All they can tell you is that it doesn't work. That's generally what the emails [inaudible 00:20:00] say. Usually along with that your website sucks kind of comment.
That's my goal and a lot of times if I'm doing a new website for a client, they love when they're doing stuff as an admin and something goes wrong and before they even notify me, I email them and say, “I saw the error that came through and it's fixed, you're cool.” So they don't even have to let me know about it and a lot of my clients just don't even let me know about errors cause they know I'll be on top of them. It really helps, it really helps with your client communications so that they don't have to try and explain what's happening in terms of the errors that come through.
Michael: Right, you mentioned you also have some SQL Server error logging. Tell us about how you do that.
Mary Jo Sminkey: Yeah, this is just a small thing that I'll show in my talk where we've had some issues with, to be honest we still quite haven't figured it out. We use stored procedures a lot and we had to make a change with a particular stored procedure, we kept getting this really bizarre error where it was pretend … it would seem to be still running the previous version of the stored procedure.
We went round and round. Was it ColdFusion causing it, was it SQL Server causing it. We couldn't figure out where the problem was occurring. The only way we could determine whether this error really was occurring for the users or not was to start logging … create a log table in our SQL Server and then during our stored procedures actually log what was occurring. And we still don't know why we get the error. All we know is that it's not actually happening for the user. We still get this error and I just ended up trapping it and ignoring it and it's been happening for like a year and we still don't know why. By logging it, we could see that the SQL Server was getting the correct data, it was completing the insert or the update that we were asking it to do. Just for some reason SQL Server returns this error to us regardless.
We even tried renaming the stored procedure to something new and we still get the error so it's the most bizarre … We've had SQL Server experts look at it. It's crazy but the logging allowed us to track the problem and we continue to use that for other things where we need to kind of see what's occurring. We've had some issues with our checkout as there's this really crazy shipping process and sometimes you would get like a null value you didn't expect to get. We use this logging table to log the steps of the checkout process and where each of these shipping variables get sent and then if we get an error, we can go into the log table for … and see what exactly happened and where … which was the variable that wasn't set properly and so forth.
It's definitely very useful in terms of if you're getting kind of cryptic errors or errors in your stored procedures that you aren't really sure where they're occurring. It's very different to debug those sometimes. In terms of … if you're getting an error, you're getting a null value for a variable inside your stored procedure and you don't know where that's occurring.
Its fairly easy to debug it yourself if you're running through you can print out the variables but if it's happening on the live site, and you're not able to replicate it, this gives you an additional tool to figuring out how that's happening.
Michael: Basically you just have an insert statement into the log table somewhere in the stored procedure [crosstalk 00:23:56] logging it. Is that right?
Mary Jo Sminkey: Yeah basically.
Michael: That's great work, is a really clever idea, so and I assume it just puts any other information you have like the date and time. I don't know that you necessarily know the IP address of the client in this case.
Mary Jo Sminkey: Yeah, no unless[inaudible 00:24:14]
Michael: [crosstalk 00:24:15] stored procedure.
Mary Jo Sminkey: No, just generally your date and time … whatever you pass into it you can log it. If you're using it for multiple stored procedures you will … put in the name of the stored procedure that's running so we know all that.
Michael: Great. And then what about things like slow queries or deadlocks? Do you log those in some way as well or …
Mary Jo Sminkey: No, fusion reactor does a pretty good job on those in terms of checking for that kind of stuff. That is a tool that we're generally using on all our enterprise sites. Really can't beat that too much. I mean, these other tools that we're starting to look at for some of this full stack. Monitoring and reporting what we call application performance management tools can do some of that as well but we're just kind of starting to dip our toes in on those. I'm not sure I would [crosstalk 00:25:22]
Michael: Well we'll talk about the tools for full stack management in a moment but tell us … you say you do have some strategies for debugging errors on lives sites. Tell us a bit about how you do that.
Mary Jo Sminkey: Yeah again, that's where we're relying a lot on the Bugsnag as well as the emailing out of errors that occur. I think we pretty much covered that in terms of what we're doing on live sites the logging of what users are doing in terms of a page tracker an Ajax tracker into the session so that we have more information on what the user doing. That's pretty much what-
Michael: I was hoping you had some magic method that would pinpoint the line of code causing the bug.
The other thing that I'll show in my presentation that we kind of ran into is … so I'm creating this big giant structure of all my pages and then all the Ajax calls that are happening and then all this additional data about my user. Its this big JSON nested structure and I'm sending that out to Bugsnag. Unfortunately, Bugsnag just prints it out like a big piece of text. It's really hard to make sense of it in terms of having this big nested structure with arrays of objects and stuff.
What I do for my ColdFusion errors that get logged out to Bugsnag is … when I go to do this notification I also copy that JSON to my server and then in Bugsnag, it actually has a URL that takes me to a little JSON display, what would you call it … it's like one of those tools that you can drop your JSON in and it generates the whole little structure for you. That's what I did, I took one of those tools. I made a copy of it that sits on the server and then you just tell it the file to show and it brings it in and gives you the whole little nested structure that you can open and close each part of the structure. That's a neat little way to get a easy to read version of that big JSON structure that the bug handlers system doesn't know what to[inaudible 00:30:12] It doesn't know it from a piece of text. That allows you to kind of make it readable.
I use that tool for other stuff too. Once you have it, it's really handy to just have available. We use Solr search on our website so I can, I'm having trouble with something indexing properly, so I can just throw out my JSON structure into that tool and read through it that way.
Michael: That's great, and that lets you navigate through the JSON structure I'm guessing or …
Mary Jo Sminkey: Yeah, exactly. Exactly.
Michael: Or just displays it, yeah, right. If think[crosstalk 00:31:43]
Mary Jo Sminkey: Yeah, it's for navigating through [crosstalk 00:31:44] it can expand and collapse the different parts of it basically.
Michael: Any other tools you use for error logging, either open source or third party ones?
Mary Jo Sminkey: Not currently. Those are … I think I mentioned pretty much all the ones that we've used. I have used, if you're familiar with BrowserHawk.
That is what we had initially started with was the BrowserHawk one and then we found Bugsnag and it just gives us so much more. That's what we use now.
Michael: Then, what about the CFlog tag or log box. Those are two other things I know, I've heard of people using for logging. Didn't hear you mention them and I just wondered if there was a reason.
Mary Jo Sminkey: Yeah, I mean the main reason is that I got to go on the server. That's a pain in the butt I don't go on the server. I will use it occasionally for some things. I generally am only using it for scheduled tasks to log … my scheduled tasks are occurring. Things that I don't need to check very often but if I have some kind of problem I want to go see if of they are occurring or not. I'll go … I'll use the CF log for that. In terms of the error handling I won't be able to just do that without having to mess with getting on the server and looking at stuff.
Particularly since I have to kind of remote these servers a lot of times, it's a hassle so …
Michael: Right. Then, I've heard some people using LogBox for logging cause they, it doesn't have to go into a database if you're using [inaudible 00:33:59] containers can be useful because you might not have access to the database in that container.
Mary Jo Sminkey: Right, right. Yeah, yeah I've played with LogBox a little bit but it's not something I got a whole lot of familiarity with. A lot of the idea behind my presentation is get people thinking about this. There's definitely all kinds of different ways to accomplish it. What works and what I need for applications or for my clients might not be … I do a lot of eCommerce, that's kind of my particular forte so there are certain things that I do for eCommerce sites that … like the page tracker that is so important for eCommerce sites, it may not be as important for other types of sites.
It's more just to get people thinking about what are they doing and can they do a better job of this or are they even bothering with emails for errors? Do they pay attention to those? Do they know what kind of errors that are occurring on their sites.
A lot of times if you're not even looking at the error logs you don't know what's going on. Customers are just, they just don't tell you a lot of times when there are problems on the site they go somewhere else.
Michael: I find that if I let the errors keep on happening, it makes it harder to … you know I just say I try and … if someone says, oh these are not important errors, the problem is that they get in the way of seeing the ones that are important
Mary Jo Sminkey: True. Yes.
Michael: I always think it's best to get rid of all the errors even if they're quotes, “not important”.
Mary Jo Sminkey: Right, right. Well and that too. Like I said, it really means a lot to your clients when they see that you're taking care of those errors and staying on top of them. Because to them, that means that you care about their site and how well their site is working. Versus them having complain about it, them having to figure these kinds of things out. When you're able to say, “Oh, I noticed this error came through and I took care of it,” that's showing them you care about their site that really can help with getting them, trusting that you're really working hard to keep your site working as good as possible.
Michael: Can you proactively tell people you fixed errors even if they haven't told manually or know their IP address [inaudible 00:36:26] or …
Mary Jo Sminkey: End users, no, I'm generally doing it … unless they actually written and complained about it, then I'll let them know when it's gotten fixed and that's only if the client is having me do that webmaster type of interaction with clients, I mean with customers. A lot of them don't really want you emailing their customers or they want you to CC them in.
I'm talking more about admin actions where your actual paying client has an admin section of the site that they use for doing admin type actions. If I see an error come through from something they were doing, then yes I will email them and say, “I noticed that problem I took care of it, it should work fine now.”
Michael: Cool. Now you mentioned earlier that you used the analytics to help with tracking down and fixing some errors. Tell us a bit about that.
Mary Jo Sminkey: Yeah, again, this is because I do not necessarily log all of my errors and also there are some errors that are more, like again we're doing searches on the website so it may not necessarily be an error so much as a problem. We use both, Adobe Analytics as well as Google Analytics and there's a lot of ways obviously … all these types of analytic sites will trap statuses so you could see you 404 errors for one. You want to keep track of those. If you're hitting a lot of 404's. We do a lot …. with eCommerce sites you don't want to ever lose customers so if there are, if you're doing a big rewrite on the site where your URLs are all changing, on an eCommerce site you need to have redirects in there. You cannot just say, “Well google will figure it out eventually.” You got to put redirects in there.
After any big relaunch we always are tracking those 404 errors and making sure we hit all the redirects we need to do. Likewise, people will post stuff in forums that might get to your sight in some way and you might not even know about those URLs. You might think [inaudible 00:38:47] down the road I can get rid of these redirects. Those logs will let you know that, nope there still sites out there that are directing users to your site so.
Then I look at things like search errors. I want to look at, if my user ran a search, did they get any results back. I might set up a particular event for searches that didn't return any results up and then another one I often look at are how well is my search working. Do my users have to search like three or four or five times before they add something to the cart. I want to see real low numbers for analytics like that so that I know that my search relevancy is working really well.
There's a lot of different ways you can use analytics to look at the performance of your site, not just errors but just problems. If a customers got to search five or six or seven times on your site before they put something in the cart, they're probably having trouble finding things and you might need to look at that.
Michael: Well that's a smart way to do it, Mary Jo. You mentioned earlier you used some full stack application performance management tools. Can you tell us, which ones you used and why did you use them?
Mary Jo Sminkey: Yeah okay so these are new products that are becoming even more popular in enterprise sites as we start getting more and more layers to our applications where things like the client side layers becoming more important to us as we use more of these client site tools and AngularJS sites and stuff where a lot more of the code is happening on the client's site.
What's really cool about these tools is they generally are gonna monitor and report on every layer of your stack from the database layer to the application layer, your server layer your client site layer. It's gonna do everything. A lot of times the pricing is not really too bad for these. Compared to what you might think they would be. The one that we really been looking at is called, Dynatrace. Couple other really popular ones, Cisco has bought out one called AppDynamics that is available as well.
You generally are paying for how many different plugins you need for it so with ColdFusion there's a java, JVM plugin that uses to monitor the ColdFusion layer. What's really awesome about it a lot of times is that you can specifically search for a particular user and it can be either IP address or in the system, if you log your user ID that's associated with them or a lot of times you'll have a cookie for your user or something like that.
It's really an incredible tool that I think that a lot of more enterprise sites are gonna start using because it can be used by both the developer as well as the actual customer or customer service people even can possibly use it to track issues.
It will do a lot of reporting as well. All kinds of reporting on how your applications performing so you can see slow performing pages it will report on things like that. It's so … what's nice about it is that everything is in one place so you don't have to go one place to find out, okay I have to go my analytics to see if how my searches are performing. I got to go into google [inaudible 00:43:53] to see where all my slow pages are things like that. Where are my 404's it's kind of all, everything in one big tool. So it's really worth looking at for your enterprise level clients.
Michael: That sounds really exciting Mary Jo. Good luck in your talk[inaudible 00:44:15] got a few more questions I'm asking every speaker.
First one is, why are you proud to use ColdFusion?
Mary Jo Sminkey: Proud to use ColdFusion. You know I think it's just still a really fun product to work with. I mean I've been doing it pretty much my entire adult life as a developer. I certainly work with other products but it's still my first love kind of … that I still really, really enjoy working with. We tend to get a lot of different clients that … I'm able to really improve their websites, get them working better, getting them running a lot faster and error free. That just makes them happy about ColdFusion too, cause a lot of times they're being told that ColdFusion's the problem and we can show them that it's not the problem. There's so much that we [inaudible 00:45:16] for them to get their sites running fast and well and you know that makes me really happy.
Michael: Great. Take to make ColdFusion even more alive this year?
Mary Jo Sminkey: Excuse me?
Michael: Some people have said that ColdFusion is dying, they been saying this for so long it's a little hard to believe but what would it take to make ColdFusion even more alive this year?
Mary Jo Sminkey: Even more alive. You know, there just isn't enough outreach to developers. I really wish Adobe would do more to reach out to new developers and to bring more developers in. Cause that's, in my mind, just the biggest problem, is that … because there is that conception out there, we don't get a lot of new developers unless they have to do ColdFusion for a job or something. There's not a whole lot of developers that pick it up and I would just like to see more outreach from Adobe in that respect. In terms of letting the community know we're still developing it. We're still making it a great product and we want to bring you guys on board. Outreach at colleges and stuff. That kind of thing.
Michael: [inaudible 00:46:33]Suggestion. What are you looking forward to at cf.Objective this year?
Mary Jo Sminkey: Well I'm thrilled it's in DC frankly cause that where I work. That's where I learned ColdFusion I worked for so many years I grew up in Maryland so I'm just really excited to get to go up there and visit family and friends and all.
Yeah I haven't gone to cf.Objective in a couple years so I'm really gonna enjoy going to a lot of the other talks as well.
Michael: Great. If folks wanted to find you on the internet, how would they do that?
Mary Jo Sminkey: Well I will say that after my last talk at cf.Objective on error handling, I started working on a series of blog articles. I don't maintain a blog myself but my CEO at CF Webtools, Mark Kruger does maintain a CF blog that I will send my articles to and have them posted on. You'll see my articles show up there from time to time.
I'm certainly on Twitter under @mjsminkey although I'm rather political so … I probably should separate my ColdFusion twitter stuff and my political twitter stuff but that's me I just throw everything into one big bucket and of course I'm on LinkedIn as well.
But yes, CF Webtools is my company so you can always find me through them as well.
Michael: Fabulous well thanks for much for being on the podcast today.
Mary Jo Sminkey: Yeah, my pleasure. Thanks for having me.