[cfaussie] Re: SeeFusion / Fusion Reactor
Hi Dave, Thanks for the reply. This is strictly for monitoring the production server. I have managed to do a little more reviewing of the two, woo - since I posted. At the moment we are having a play with the trial version of Fusion Reactor. So far it looks it pretty good - and certainly does all tat we currently need too. Thanks again. Gavin. On May 6, 12:53 pm, Dave davidame...@gmail.com wrote: We prefer FusionReactor for monitoring production servers - we don't use enterprise features. Mainly the metrics flash screen, as well as running requests, and stack trace all features. Not sure if SeeFusion's has equivient screens as it's been a long time since we considered using it for production monitoring. SeeFusion can be handy on dev workstations for seeing what queries your code is executing - it can append the queries to the bottom of the page. dave On May 6, 11:33 am, Gavin Baumanis beauecli...@gmail.com wrote: Hi Everyone, We run CF Standard edition and so don;t have access to the built-in server monitor, yet found ourselves requiring a monitoring tool. I have spent some time over the past few dats reviewing the SeeFusion and Fusion Reactor sites - and also did some Googling for reviews. The reviews with side-by-side comparisons of those two all seem to be a few years old - and I am betting there have been quite a few additions to both products since then. My summary so far seems to be; Fusion Reactor has more stuff and we really like the Enterprise version's ability to run a script in case of a failure, too. However, SeeFusion does everything we Currently need for cheaper. Thus my email here. Without starting a flame-war I am hoping people might be able to give me their opinion on which product we should purchase. It is my current thinking that the nice to haves in FR may at sometime become have to haves and thus make the extra cost a worthwhile investment. But then again is that ever likely to happen? We have managed all this time without any monitoring / troubleshooting tools at all. Cost is important - but it is not entirely a money-based question if a dearer product is indeed better for us. Thanks in advance for any insights! Gavin. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
[cfaussie] Re: Strange Issues with IE8 / iframes and sessions.
Hi again, We have manages to find a few blogs / technical articles about Iframe issue in IE8. And while they all seemed like plausible solutions to our problem have failed to deliver a successful result. So now - instead of trying to code around the issue, we're thinking of something a little more radical... Something along the lines of; Getting rid of session-based tracking altogether and using something else. Which is where all you fine people come into play :) My initial thought is to simply go and do a search / replace for session.userid with request.userid. See what breaks - and fix any issues as they appear via some testing. (we have some unit test for new / recent work we've been doing... but that still leaves an awful lot of un-exercised code) What I am after, I suppose is; Do you think the proposed solution will deliver, or is there something else we should be considering before we go headlong down this path? As always - Thanks! Gavin. On May 3, 1:12 pm, Gavin Baumanis beauecli...@gmail.com wrote: Hi there, Our application has a header and menu in the one page - while the pages content is an iframe. Consider a User admin page; We have the user's basic details in the header and an edit form in the iframe. When we choose User A, we get user A's details in the header and the iframe. In IE8 only; When I select a new user, we see user B's details in the header, correctly - but occasionally the contents of the iframe are the details of the user previously edited / viewed. From a disconnected search page - we set the session.userid variable. Then query the database for the users basic details that go into the header correctly. We then requery the databse via the code run in the iframe - depending on what you want to view / edit. The iframe also does it's SQL filtering based on the session.userid - but as described above, the iframe is not always reflective of the current session.userid set from the search screen. We do NOT have this issue with FireFox / Google Chrome. I have visited Mr.Google and can't seem to find anything specifically suitable, but for confirmation that session handling was altered completely in IE8 from previous IE versions. I'd welcome any ideas that anyone might have. Gavin. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
[cfaussie] How to choose the right one : Design Patterns
So, In a follow-up of sorts, to my last email to the ist about how to get rid of the session scoped ID that is used throughout our application - I have a question about design patterns. I have the Head First Design Patterns book in my hot little hand. But... Short of re-reading the entire book, How do I possibly know which design pattern to use for any specific problem? Is it simply a case of practice? Is there a guide somewhere - because Mr.Google can't seem to illuminate me any - that reads something like; Design Pattern A: good for tasks 1,2.3 Design Pattern C and E, good for 10,11,12 Mind you just re-reading my own typing - that is exactly what the Head First book provides - it is just so damn verbose Gavin. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] How to choose the right one : Design Patterns
On Mon, May 9, 2011 at 5:08 AM, Gavin Baumanis beauecli...@gmail.com wrote: How do I possibly know which design pattern to use for any specific problem? A design pattern includes forces and trade offs so several design patterns might apply to address a specific problem and which one you pick would depend on which trade offs you wanted to make. Is it simply a case of practice? Pretty much. Is there a guide somewhere - because Mr.Google can't seem to No, because of the nature of design patterns. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] How to choose the right one : Design Patterns
On Mon, May 9, 2011 at 1:06 PM, Sean Corfield seancorfi...@gmail.com wrote: A design pattern includes forces and trade offs so several design patterns might apply to address a specific problem and which one you pick would depend on which trade offs you wanted to make. And it's also worth pointing out that some design patterns are language specific or at least apply more to certain languages than others. Books like Core J2EE Patterns include quite a few generic patterns but also a number of patterns which solve problems that are caused by Java itself. Singleton is a good example of this. The core of the Singleton pattern is global access to a known, single instance of an object, with a single well-defined point of initialization. This is *incredibly* hard to achieve correctly in Java (in a fully thread safe manner) but it's something we have built into CFML: Application.cfc: onApplicationStart() - well-defined, thread safe point of initialization; application scope - easy global access to the single instance, created in onApplicationStart(). All the rest of the nonsense you see in Java implementations is because Java forces everything to be a class so the only global way to access an instance is via the class name and therefore a static method - and then you get all the nasty thread safe initialization issues cropping up. Java doesn't have any concept of an application starting up. So you need to be careful when reading design pattern material - a lot of it is fairly Java-centric, at least in its implementation (Gang of Four excepted of course, since it uses C++ and Smalltalk for examples). A lot of people think you need interfaces to implement design patterns but Smalltalk does not have interfaces (and C++ doesn't either, at least not in the way Java has them). Java interfaces are an artifact of the way the Java language was designed and some of the dogmatic decisions made early on not to follow C++. In a dynamic language like CFML, many design patterns become somewhat unnecessary or have much simpler implementations. It's also worth pointing out that not much has been written about design patterns for truly dynamic languages yet: metaprogramming is a very powerful technique that provides a radically different way to approach some of the traditional design patterns as far as implementation is concerned. At the risk of sounding my own horn, you might want to read my Design Patterns preso http://corfield.org/blog/page.cfm/presentations (or watch one of the several recordings - where I tend to go off on rants about what can go wrong when you slavishly follow design patterns :) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
