I am in Dallas for a customer meeting tomorrow, and took the opportunity to speak to the local CFUG this evening. The room was packed with a standing room only crowd, and two developers even drove in from Tulsa for the event (over 4 hours each way). The meeting was hosted by Aidmatrix (who showed their impressive CF+Flash app used to facilitate donation drives and donation allocation) in one of the nicest facilities I have seen (complete with three gigantic screens and auditorium style seating with plush armchair like seats). The presentation was on event gateways (with examples of asynchronous processing, IM integration, and SMS applications). Lots of good questions, both on and off topic, as well as requests for “Scorpio” functionality.
Dallas CFUG Report
11 responses to “Dallas CFUG Report”
-
Ben;
Thanks for coming out. I’m one of the fledgling CF individuals that was in the audience. I wish I had more questions to have asked you on the level that everyone else was, but I really enjoyed listening to you speak. A lot of the material was a bit over my head, but it really provided a wealth of information on just where I can go in developing my CF knowledge. Thank you very much for taking time out of your busy schedule, it was truly a joy.
Tommy "Elfster" -
Hi Ben,
We were glad that you could make it for your talk, I really enjoyed it.
Thanks
Sophek
Aidmatrix -
Ben.
Thanks for stopping by and chatting about Event Gateways with us. I can’t wait to mess with the source code that is available to us. I have managed to get a AIM bot running from the CF Server I have installed on my laptop. I’m running into a problem where my co-workers can add the bot to their buddy list AND it appears online to them, however they cannot successfully issue commands. Any ideas? -
It was well worth the drive from Tulsa.
Thanks for a great presentation. I am really looking forward to trying enterprise gateways (especially for IM) now. -
Did they talk about the speed of initiating the an async gateway? Unless you’re doing tremendous work, which most likely you won’t with an async gateway, you might as well forget about even using one, since you’ll be wasting more milliseconds initiating it than running the code within it.
Everybody says use gateways for logging browser stats, details, etc. Yes, well, I think I rather run a split microsecond insert into a database rather than running an async gateway (which takes 5ms to initiate on my hardware), then running the code within it, which ofcoarse still uses up cpu, just doesn’t process on the same thread, and uses a useful report thread.
Unless there is something wrong with my installations, async is worthless unless something tremendous is being executed. It’s the truth. -
Report thread replace with gateway thread. Made a mistake there.
-
Matt,
I don’t think the point of asynchronous requests is that they lower total execution time. I think the point is that you don’t have to make the user wait for the operation to complete. This, of course, only makes sense in some circumstances – but could be very nice where it applies.
That being said, Ben’s demonstration did show an increase in speed for several operations on one page where each could take several milliseconds to run (because each operation can run in a separate thread at the same time). -
Believe me, I understand the point of the async gateway. And as I said, if the process is ran over 5 milliseconds, then it would be a wise move to run the gateway, other than that, the initialization of the gateway takes 5 milliseconds. Therefore, the client is waiting 5 ms for the gateway to initialize before executing the rest of the code.
And as I’ve explained, Macromedia recommends logging data via a gateway, and I recommmend not doing that, because logging data definetely will not take 5 ms. You have to be doing something wrong.
Now this is according to the hardware that I have and compared to everything else. -
Ben,
Thanks for speaking at the DFWCFUG this week. Over the past 9 years, I have managed two different cold fusion web teams and have loved the results that cold fusion offered web developers as well as the closeness of the Cold Fusion community. The Dallas area has many CF users and they really respect and eagerly anticipate your new books and your dedication to the CF movement.
Over the past several years, I’ve been moving away from the CF world and moving to ASP. However, after listening to your presentation on Wednesday, in spite of one of the biggest storms for DFW this year, I am now considering moving our company’s web sites to Cold Fusion. I now work as a webmaster for company that designs and manufacturers Land Mobile Radios for first responders. My job as a web team of one is to design and manage all the web sites for the company. Currently the sites are all in ASP, but after hearing all the changes and improvements to Cold Fusion, especially with CF 7, maybe it’s time to return to CF.
Thanks again for taking the time out of your busy schedule. It was great to finally meet you and hear what you had to say. It was also fun to see how YOU outlasted the audience, answering questions to the point that we ran out of questions!
Pamela Van Hook
pvanhook@efjohnson.com
EFJohnson
Irving, Texas -
Pam, that’s great to hear. I’m glad that you enjoyed the presentation, and appreciate you sharing your thoughts.
Matt, yep, there is overhead. Asynchronous processing is not appropriate for every scenario, you need to test it for yourself. If you were to add the total time spent on processing by all asynchronous requests, then sure, it’ll likely always be greater than had it all been processed sequentially in a single thread. The key is not the performance of individual threads, but whether or not the actual set of operations is completed quicker, and whether or not the initial thread can be ended sooner. Sometimes it’ll pay, other times it won’t. -
Switch to Ruby on Rails folks, it’s a lot easier…
Leave a Reply