ColdFusion in Baltimore Rotating Header Image

About

ColdFusion in Baltimore is for code sharing by The Site Studio developers. Check us out at http://www.thesitestudio.com

4 Comments

  1. Belkis says:

    what to provoke what. If you’re beettr than it, you will act beettr than it. There’s a big difference between what is being said/done/reported on both the “CFML” (aka OSS engines) and Adobe respectively.As a ColdFusion developer (I refuse to see any difference between the two today, because in the beginning ColdFusion is all there is as a unique syntax), I see this divisiveness as immature and frankly leaves me wondering if CF devs are really this bored with having conquered web apps that other languages are bothering catching up to.Instead of spreading the neat and great things we can build with this wonderful language and ecosystem that has made all of us profitable, we’re playing target practice with each other?It’s shameful. It’s wonderful we have options in the CFML interpreter space. It’s unacceptable that anyone, decides to speak from a “side”. We’re all one language. This tribe within a tribe is disgusting and the cause of all poison that spreads through human relationships.I hated/loathed/bored of programming until I found ColdFusion made by the Allaire brothers. Let’s all try to remember the day we found ColdFusion (or it found us) and we had our first aha moment. The feelings, the inspiration we all have felt should be lending it self to creating conversations full of respect, not letting ankward anti-social geekish tendencies to be curt with our words and then get into a downward spiral of being hurtful. Anyone who does this does not deserve to hurt an entire community, nor have the right to take on the decision of how to poison that community.How about we just try to be the ColdFusion community. It’s not that hard. If you need something to make you feel significant, let it be what you build, and not what you build it with that makes you feel special.

    1. Hirokazu says:

      Can only agree.. thank you!Sadly I see a new trend which is that any open-source/community-driven projects are cool, “corporate” pruotcds are evil. Not sure if I should laugh about it or start worrying: both “worlds” are great and probably none of them could exist without the other one Another fact: to eat you need money (well in a modern world) and as time is money, again sadly something we can’t deny, if people have some free time to dedicate to the community to create free/open source pruotcds, that’s wonderful, especially when you see the quality of some of them! But some others are paid to create the same kind of pruotcds, so it can be free. Stop asking for all pruotcds to be free, it’s non-sense!

      1. Derek says:

        thanks for the patch denny. by way of update, mxuint is now pretty darn close to working on railo. your fix for the objectcache, it turns out, is going to be unnecessary. the reason is that there’s a bug in railo with structget() overwriting existing structures. I submitted this a few days ago and it’s now in progress. So to get the objectcache working properly, i essentially did what you did, but I’ll be removing that code and reverting to the original when the 0004 release of railo comes out and that bug is fixed. the current status (reflected in subversion, not a recent release) is that we have about 25 tests failing or erroring in railo that pass in CF. a few will start passing when the 0004 release of Railo comes out. a few are due to the CF-specific junk that either already is or will be deprecated anyway (stuff using the cfide componentexplorer, for example). The other bugs are largely related to differences in how CF and Railo treat java stuff (like javacast). I’m punting these to Bill since they’re his babies, but we’ll either find that a) we need to change the implementation or b) there are bugs/incompatibilities in railo for which we’ll file bug reports, or c) a mix of both. There will probably always be handful of outside cases that don’t work in Railo but do in CF. But nothing that would be show stoppers. And I gotta say: the railo guys have been super to work with. It’s funny: normally, when i hit bugs in a product I think “oooh, f**k” because I just know it either won’t get fixed or, if it gets fixed, it’s going to take a long time. But my experience with railo is quite the opposite. When i hit a bug, it’s like hitting a bug in my own software. I just submit a big report, maybe provide test cases, and i know it’ll get fixed. it’s, like, just not a big deal. As for the CFCProxy bill, you listening? anyway, long story short: the latest commits to subversion get mxuint and the plugin largely working with the 0003 release of railo.

  2. Akis says:

    I understand what you mean, but for the pusrpoes of the Tiobe index do they actually make those same distinctions when analysing other languages? If built-in image manipulation functions are part of the framework and not part of a discussion about the programming language that they belong to then similarly every C# article that mentions a native package or Windows API should be excluded from the index but I highly doubt they are excluded. But this isn’t really my point When someone talks about ORM in ColdFusion 9, interfaces in ColdFusion 8, or CFC-based custom tags in Railo they are talking about “the language”. All these things would be excluded from the Tiobe index because they are being pointlessly pedantic about the use of the word “ColdFusion” or “Railo” or otherwise. The fact is we all say “ColdFusion” far more than we say “CFML”, even when we mean “the language not the application server”. Chances are someone at Tiobe just doesn’t like ColdFusion and thought it would be funny to only rank it based on “CFML” and “CFScript”, and we all fall for it every time.

Leave a Reply

Your email address will not be published. Required fields are marked *