Showing posts with label Abram Adams. Show all posts
Showing posts with label Abram Adams. Show all posts

Tuesday 17 May 2022

If yer a CFML dev, you should consider financially supporting


I'll keep this on-point today.

If you are a CFML developer, you will be aware and likely use Whenever I have an issue with some CFML that needs to be demonstrated to someone else; eg: I'm asking for help on Slack or Stack Overflow, or demonstrating an answer to someone else's question: I create a portable / repeatable repro case on I use it to demonstrate bugs and behavioural differences to Adobe or Lucee when both vendors don't give the same result from the same code. I use it every day.

I believe is the handiest resource available to CFML developers.

Until now Abram has done all the work to create and maintain at his own expense, both financially and with his own time. I reached out to him a coupla days ago wanting to see if I could help-out financially, and he has set up a Patreon page for this very reason. His blurb is:

And the Patreon link is:

If you don't want to do a monthly payment, there's also an option to flick him some dosh on a one off basis:

Both those links are on the homepage.

Go give him some money. If you're the purse-string holder at a company: consider giving him some money on behalf of your company too, to make yourselves better CFML Community participants.


Whilst I'm talking about money, don't forget you perhaps also ought to be supporting Lucee. I wrote about this before: If your company (or yourself) makes money using Lucee… you should throw them a bone. Consider supporting them as well if you haven't already.



Thursday 18 December 2014

Book review: Adam Tuttle's newest book

Adam's been busy recently. You'll've heard about his new book "REST Web APIs: The BookREST Assured: A Pragmatic Approach to API Design" which is being released soon - I'll have a review up and a competition to win a copy next week - but he's also released the first book dedicated to ColdFusion 11's newest marquee feature: CFClient.

I know I have derided CFClient a lot, but it does have its good bits, and Adam has worked through them all and put a fairly accessible book together. Granted it's not very long, but for something that focuses on a single tag, I think that's fair enough. It's free and open source, so you should go get it, and give it a read. It might make you think again about whether or not to use CFClient. I have to admit it did give me pause for thought.

Go grab it from it's official website now (it's just a PDF): "CFClient The Good Parts".

I think Abram Adams (of fame) said it best in his review when he said:
I felt like I was looking into the minds of Adobe engineers
It's exactly this attention to detail Adam Tuttle captures in this latest book.

CFML doyen Mark Drew had this to say:

I have been looking everywhere for an in-depth look at the useful features of the cfclient tag and I have to thank Mr Tuttle for providing it!

I am not good at reviews but I should say that this is not only The Good Parts, it is also the definitive guide.


I'll get back to you about the REST book next week (here it is: "Book review: REST Web APIs: The Book (win a copy here)"). The CFClient book'll keep you going until then.



Monday 9 December 2013

One of our CFML community colleagues has dun good. Abram Adams has created a site, which deserve our attention and our support. It's based on the same concept as, which is also a handy site. Basically it offers CFML tutorials, which one completes interactively and in-browser, with a built-in CFML edit / execute window.

Thursday 11 April 2013

onApplicationEnd() usage survey results

I've had a reasonable number of results on my survey asking whether or not you use onApplicationEnd(), and if so: how so. It's telling a predictable story: the answer is "no, not really".

I've had 42 responses, and 38 of them are "no".

Four were "yes", with the following comments:

Current application uses onApplicationEnd to write to a log file that the application has shut down.

for some projects I work on we have to do audit records almost everything. So that's one of the things that's triggered on Applicationend. Other stuff I've used it for was for general cleanup of data.

I've used this to clear a shopping cart for a reservation app. I'm not convinced it was the best solution. I also used it for a large streaming app with thousands of users to save the last channel they were listening to when their app timed out. So at their next login it remembered. It does delete the structures & I had a lot of issues with blowing up memory with session variables.

Record page views for cart tracking / checkout progress.
I think the logging situations make sense, although perhaps it would be more robust to put it in onApplicationStart(), because an application will always start, but it might not end: for example if the box itself crashes, or the JVM gets tangled-up (sorry about the technical jargon there). So there's a chance of missing some metrics doing it at the end. I understand, though, in an auditing situation "what makes best sense" is not necessarily one of the requirements. And also there's merit to be had in a "belt 'n' braces" approach.

I'm not sure about the shopping cart ones. Aren't shopping carts generally session-centric, not app centric? Also an application can time out without a session timing out. If the application times out and restarts, it will re-acquire any sessions that were still around when it timed out. Obviously it'd be unusual in the normal sequence of events for the application to time out before its sessions, but it's possible if say one calls applicationStop().

Still: I will not base any sort of judgement from a quick comment in a survey, obviously I know stuff-all about the environments / codebases in question.

There were a coupla good comments on the survey article too:

Abram Adams said:
I've never used onApplicationEnd (and indicated so in the survey), but that got me thinking of what I could use it for. Perhaps as a mechanism to keep an application alive and fresh? One of our larger projects uses a custom framework that does some data/object caching, etc... The first request (if app has expired) can take around 5-10 seconds to complete while subsequent requests take <1-2 seconds. Perhaps I could hook into the onAppEnd and re-init the framework so that it doesn't become stagnant, but is always ready...

I've prototyped the idea in my dev environment and it does seems to work nicely, though there may be hidden gotchas that I'm not aware of. Any thoughts to that approach?

And Jose Galdamez said:
I've rarely had a need for OnApplicationEnd. The server should be handling garbage collection of application-scoped variables, so one shouldn't have to write that sort of logic. When I see OnApplicationEnd in lessons I usually see examples where applications log information such as the date/time when it ended. Personally, I can't think of anything useful to log when the application ends. If you really want to keep track of the application lifecycle you could always log that within OnApplicationStart and leave it at that. I'm curious to see what people say in your survey!

Both good observations.

I think with the application timeout thing - I've had similar thoughts in the past - the easiest way to mitigate it is to have a really long application timeout. This removes the issue. Bear in mind that by the time onApplicationEnd() runs, the application has already timed out, so I think if one is after continuity, then making sure it never times out, rather than re-init-ing it if it does time out is a better approach.

Also if an application must be up, then there should be some sort of "are you up?" check going on to alert [someone] if the answer is "no". And the act of asking the question will reset the time out timer anyhow.

Unfortunately there were no responses with some really excellent thing we can all take away thinking "hey, that's cool". But I think we all probably suspected that would be the case anyhow.

Thanks for filling out the survey, to all those that did.