Procedural to Mach-II Tips/Advice
Joe Campbell
I've been following Mach-II ever since we migrated to CF7 at work.
Right now, I'm trying to convert a complex and lengthy procedural CF
application into a Mach-II prototype for testing. We have just begun
to notice how difficult it is to maintain our application. One change
potentially could "break" any number of other parts of the
application. This leads to many bugs and many more hours of
regression testing to the point of driving my team insane.
Are there any good guides/tutorials/advice out there for making the
transition?
I do have experience working with UML and C++; is there any example
projects in Mach-II with design documentation available as well as
source code? This would likely help me the most as I learn better
from pictures.
I am a bit worried about Mach-II's framework overhead but I plan on
doing test cases with the prototype in order to hopefully justify this
overhead. For example, one of the cases would be changing one of the
business requirements. I'm trying to show my team there is a better
way and an end to this madness they call procedural programming.
Thanks, can't wait to see version 2.0.
Matt Woodward
On Fri, Mar 28, 2008 at 10:27 AM, Joe Campbell <green...@gmail.com> wrote:
> I am a bit worried about Mach-II's framework overhead
Overhead in what sense?
--
Matt Woodward
mpwoo...@gmail.com
http://www.mattwoodward.com
Please do not send me proprietary file formats such as Word,
PowerPoint, etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html
sli...@gmail.com
resources page. Unfortuantly there aren't too many UML diagrams out
there to help in that sense. I guess more specificly I would look at
Adrian J. Moreno's mach-ii and OO primers. Also I would take a look at
the MachBlog application and try to break that down. This is how I
learned most Mach-ii and OO programming in CF. Not to mention this
group is a great resource when I comes to having questions. Anyway,
here is a few links for you.
http://www.mach-ii.com/index.cfm/go/resources/
http://www.iknowkungfoo.com/blog/
Joe Campbell
In the sense of initial startup/load. My team is very picky when it
comes to startup/load times. The application is very data oriented
and thus designed for reasonable response times.
Most of my team if not all of them believe doing things the OOP-way
will increase the response times in our application. I have heard
there is some overhead when using OOP in CF. I assume there is also
some overhead when using Mach-II since it uses quite a bit of CFCs.
According to Sean's blog back in 2006 this overhead is about the same
as hand-coding a CFC solution, correct me if I'm wrong but this is
still overhead when compared to a procedural application.
I need to be able to justify this overhead with cost/time savings on
maintainability, re-usability, etc...
I'll be sure to change the CONFIG_MODE before I do any formalized
testing/comparisons.
On Mar 28, 9:59 am, "Matt Woodward" <mpwoodw...@gmail.com> wrote:
> Just thought I'd address one thing ...
>
> > I am a bit worried about Mach-II's framework overhead
>
> Overhead in what sense?
>
> --
> Matt Woodward
Joe Campbell
I looked at AppBooster and Litepost (I believe that was the correct
name) but didn't think to look into MachBlog.
On Mar 28, 10:10 am, "bpick...@forumcomm.com" <slim...@gmail.com>
wrote:
> resources page. Unfortuantly there aren't too many UML diagrams out
> there to help in that sense. I guess more specificly I would look at
> Adrian J. Moreno's mach-ii and OO primers. Also I would take a look at
> the MachBlog application and try to break that down. This is how I
> learned most Mach-ii and OO programming in CF. Not to mention this
> group is a great resource when I comes to having questions. Anyway,
> here is a few links for you.
>
Matt Woodward
> In the sense of initial startup/load. My team is very picky when it
> comes to startup/load times. The application is very data oriented
> and thus designed for reasonable response times.
Startup and load times are two different things. I'm not sure why
anyone would be concerned about the initial startup time of an app,
but even in huge (and I mean HUGE) Mach-II apps, I rarely hear of
startup times longer than a minute or two. I'm sure there are some
extreme cases out there though. After that all the non-transient
obejcts are cached so everything's lightning fast. In my typical
"medium-sized" Mach-II apps the startup time is a few seconds.
Load time to me indicates the page load times, which is something
altogether different than the startup time.
> Most of my team if not all of them believe doing things the OOP-way
> will increase the response times in our application.
Well, in a very narrow (and therefore very meaningless) sense this is
true. Procedural code can run faster. Is OO "slow" or even
"unreasonably slower" than procedural code? Absolutely not, and
compared to poorly written procedural code, I suspect that a Mach-II
app would actually run faster.
If performance is your #1 concern, then sure, avoid using objects. I'd
argue, however, that if performance is your #1 concern your priorities
are out of whack, or you're writing real-time systems, in which case
CF isn't a good choice anyway. You should be writing for
maintainability, not performance, unless performance becomes an issue.
It's the old "don't optimize prematurely" rule.
I suppose if I'm sounding a bit curt it's because I tire of having the
"procedural vs. OO" argument over and over. That's a dead issue from
my perspective. You should be writing OO applications (regardless of
whether or not you use Mach-II) period, and to make a decision not to
do so using a rather baseless overhead/performance argument simply
doesn't fly.
> I have heard
> there is some overhead when using OOP in CF. I assume there is also
> some overhead when using Mach-II since it uses quite a bit of CFCs.
Again, overhead is such a generic term that it's hard to address. The
non-transient objects, meaning where all your business logic lies, are
cached after their initial creation, therefore no overhead for
creating the objects after the initial startup of the application. The
transient objects obviously have to be created in the application as
they're needed, but it's not as if this brings your app to a crawl. It
sounds like you have people on your team who are OVERLY concerned with
performance. Yes, we all want our apps to run fast. Mach-II is very
fast, and runs some extremely high-load, high-performance
applications. In a pure sense, plain ol' cfml pages will run faster
than an OO application, but again, that shouldn't be the primary
concern, and the speed differences are not enough to warrant choosing
not to do OO.
> According to Sean's blog back in 2006 this overhead is about the same
> as hand-coding a CFC solution, correct me if I'm wrong but this is
> still overhead when compared to a procedural application.
CFC creation in CF 8 is far faster than it was in 2006. Yes, it's
overhead, and I know I'm beating a dead horse at this point, but
overhead should NOT be the #1 concern when building an application.
Worry about overhead and performance when you have to. It's not as if
by choosing OO and Mach-II you're making a bad decision to sacrifice
performance and resigning yourself to a slow-performing application,
and what you gain in the process is a tremendous amount.
> I need to be able to justify this overhead with cost/time savings on
> maintainability, re-usability, etc...
Honestly they should have to justify why a miniscule amount of
additional performance (if it exists at all) is more important than
building a well-architected, easy-to-maintain application. The
argument shouldn't be the other way around.
> I'll be sure to change the CONFIG_MODE before I do any formalized
> testing/comparisons.
And make sure to turn off "report execution times" in the CF
administrator debug section as well.
I'm happy to give you whatever ammo you need to win this (ridiculous
in my mind) fight, but it is frustrating to me (as you could tell by
my tone through much of this) that people will make such hideously
poor decisions based on vague performance/overhead concerns. All
you're going to wind up with is an app that may perform milliseconds
faster if at all, but once that's harder to maintain. Remember too
that hardware is cheap so if you need those extra few milliseconds,
it's easy to throw more hardware at the problem. I'd be willing to
wager that if you take the millisecond clock off of things, from the
standpoint of your users, they won't even notice any speed difference.
--
Matt Woodward
mpwoo...@gmail.com
Peter Bell
1. If performance is your number one concern, you're in the wrong language.
Depending on your requirements you might be better with Java or (if
developing massively parallel systems) look into something like Erlang which
isn't fast per see but is incredibly scalable.
2. Consider writing OO code. It'll be much easier to maintain. If
performance is a real issue, look into caching strategies that'll take your
maintainable OO code and either pre-parse a lot of the heavy lifting into
memory or compile down to generated procedural code. I've played
successfully with both approaches, but usually you're better to just design
your apps to cluster and then throw more machines at it.
To put things into context, what kinds of loads are you currently
experiencing, what software do you use for your load testing, and within
your current apps, when you profile them, what are you finding the actual
choke points to be? Often tightening up your SQL will save a lot more time
than trying to optimize the performance of your CF code.
Matt's right. There are reasons not to write OO code (trivially simple
applications or dev teams that simply don't have the skill set to maintain
an OO code base), but performance isn't one of them - especially if you're
in ColdFusion. If you *really* need the performance, ditch CF and write OO
Java code.
Best Wishes,
Peter
Peter J. Farrell
> To put things into context, what kinds of loads are you currently
> experiencing, what software do you use for your load testing, and within
> your current apps, when you profile them, what are you finding the actual
> choke points to be? Often tightening up your SQL will save a lot more time
> than trying to optimize the performance of your CF code.
>
Just wanted to follow that there are other places that overhead can
occur at that a lot of developers forget. These include:
* Webserver configuration
I did some optimization for a client this past year and we looked at the
Apache settings. I was able to knock off half of the total time to
serve a page by change eTags, adding in gzip/deflate compress of files
and sending cache until headers. The cache until stuff did require a
change to how we deployed the application (we moved to ANT to automate
the process) because we tell the browser to cache JS files. We ended
using ANT with some regex and renamed all the JS (and CSS) files when we
deploy a new version to point from the generic someJS.js file to
someJS_184.js file and Regex those names our .cfm files.
* JS/CSS optimization / minified
At the same client, we started using JSMin to minify JS files when we
deployed them to production. For example, the version of Prototype we're
using -- un-minified is 45KB after it's minified it's 35KB and after we
use mod_deflate to compression the file when sending it to the browser
it's 8.5KB. That about 1/5th of the original size. Times that by all
the other JS files that are being used and that is a savings that is
very obvious in the terms of speed in the browser.
* CF server configuration
I seen a lot of people complain that OO on CF is so slow. However there
is significant overhead associated with having CF's debugging turned on.
Another thing is that people don't turn on template caching which makes
things run much faster in production on CF (yes, you need that off for
development).
Food for thought,
.pjf
Jatin Nanda
Joe Campbell
programming. My background is mainly from C++ and Java but have lost
the edge on OOP since at work we used only CF5 up until a year ago.
I even suggested we moved to CF7 so I could even use a function of all
things let alone objects. One of the lead programmers said, and I
quote, "why do we need functions? Our code works just fine without
them".
So this is the environment I find myself in and without ammo to fight
these types of attitudes I might as well not even try.
I do agree overhead is a generic term and shouldn't have blamed it on
Mach-II but rather using objects in general. My #1 priority is
usability for our users. Let's face it, the customer comes first. My
#2 priority is maintainability due in large part to the fact that this
is usually the longest phase in the software life cycle. Obviously my
team does not agree with me on these priorities.
To sum it up:
How do you teach a monkey to use a tool ("Mach-II") instead of their
bare hands ("procedural programming")?
Didn't intend to frustrate you =(
On Mar 28, 11:17 am, "Matt Woodward" <mpwoodw...@gmail.com> wrote:
Jatin Nanda
>>bare hands ("procedural programming")?
Seriously - sometimes there is no explaining to people. Its 'cos they are not willing to consider anything new. That said, new is not always good. There is also a tendency of changing apps for the sake of change.
If, for example, your organisation allocates budgets to the development of the application, it may be as simple a Project Manager saying "as this application has already been paid for - pls justify I i need a new budget to change a fully functioning app?"
I currently have a similar situation but at least my lead is open to change ;-)
Hope all goes well in your fisticuffs
Peter J. Farrell
> Don't get me wrong I'm all in favor or using OOP instead of procedural
> programming. My background is mainly from C++ and Java but have lost
> the edge on OOP since at work we used only CF5 up until a year ago.
>
> I even suggested we moved to CF7 so I could even use a function of all
> things let alone objects. One of the lead programmers said, and I
> quote, "why do we need functions? Our code works just fine without
> them".
>
faster in the terms of performance so I don't understand why they
wouldn't want to upgrade.
Sometimes my response to this is find a new job where the company
appreciates employees that want to improve things instead of working to
keep the status quo.
> So this is the environment I find myself in and without ammo to fight
> these types of attitudes I might as well not even try.
>
> I do agree overhead is a generic term and shouldn't have blamed it on
> Mach-II but rather using objects in general. My #1 priority is
> usability for our users. Let's face it, the customer comes first. My
> #2 priority is maintainability due in large part to the fact that this
> is usually the longest phase in the software life cycle. Obviously my
> team does not agree with me on these priorities.
>
I'd argue that maintainability of an application should come first
because if you are up to your eye balls in maintenance then you'll never
have time to work on GUI, new features, etc. When you reach this
threshold, it easy to compound problems because new enhancements are
layered on top of poorly written code which never gets the time it needs
to become better. Basically, maintainability contributes to how much
time you have to spend on user functionality and usability. They are
highly linked in my mind.
> To sum it up:
>
> How do you teach a monkey to use a tool ("Mach-II") instead of their
> bare hands ("procedural programming")?
>
Well, we're sounding our own horn here, but you could send them to the
two-day Mach-II workshops before cf.Objective. It happens on April 30 -
May 1 in Saint Paul, MN.
Info here (discounts available for groups of 5 or more from the same
company):
http://www.mach-ii.com/index.cfm/go/training/
There is also a detailed PDF of the workshops:
http://www.mach-ii.com/resources/cfo2008TrainingInformation.pdf
Also a shorter version for Managers:
http://www.mach-ii.com/resources/cfo2008TrainingInformationManagers.pdf
Best,
.pjf
Matt Woodward
off that way. It's just that it's 2008 for crying out loud and if
you're still coding like you did in 1998, there's something seriously
wrong. ;-) It does disturb me greatly that your "lead programmer" says
that your apps work fine without functions. There's a better way to do
things (trust me and others on that!) and it sounds like the guy in
the position to make the decisions isn't the guy that should be in the
position to make the decisions. This isn't "new for the sake of new,"
this is "get with the times and build better, more maintainable apps."
I'll even go so far as to say that once you get the hang of it,
building OO applications is infinitely easier that building procedural
applications. I'm finding that more true every day.
You're totally right to focus on maintainability. If you write your
app well and it's doing its job, it'll be in maintenance for a long
time. If you make bad architectural decisions now, you'll pay for them
every day during the life of the application. It doesn't need to be
that way.
I think there are people who are teachable, meaning it will just take
time and some convincing to get them to jump on the OO bandwagon, and
there are people who are unteachable. If you're in a situation where
the people in charge insist on coding like they did for CF 5, then I'd
consider them unteachable and quite frankly if they're that stubborn
it's not worth wasting your breath trying to convince them, sad as
that is to say.
There are, however, plenty of seemingly stubborn people who will see
the light, but sometimes they just have to reach a point of extreme
pain in the maintenance of an app before they get it. For some people
until they experience the true hell of working on a brittle
application and being afraid to touch it for fear of breaking
everything, they may just be unwilling to change.
About the only thing I can say if you're working with unteachable
people is a) find another job, or b) try to introduce OO and Mach-II
on a small app. Maybe your company needs a new phonebook lookup, or
something small like that. Offer to do it in your spare time if you
have to. Build it right, and then as people say "Oh, that's great, but
I'd like to do this ..." and you can change it in a few minutes
without fear of the entire app coming crashing down around your ears,
people will start to see how good life can be.
Just some ideas--I'm sure others will chime in with their experiences.
To put another fine point on things, NOT doing OO in this day and age
is career suicide, and if you're in a situation where you'll never get
to do OO, I'd seriously start looking for another job. You can only
avoid it so long before you find that you just don't have current
skills anymore. OO's been around since the 1960s and it's high time
CFers stop avoiding it.
Thus endeth the sermon. :-)
--
Matt Woodward
mpwoo...@gmail.com
Joe Campbell
I'll be busy dissecting the MachBlog application this weekend. If
anyone does find any helpful UML diagrams please let me know. For
some reason I learn twice as fast if I draw or see what's happening in
the application. I'll probably go through and make some diagrams of
MachBlog this weekend.
I'm odd I guess =(
Thanks for all the replies...
-Joe-
>
> read more »
Matt Woodward
to be cvsdude) here:
http://code.google.com/p/machblog/
No zip so you'll have to use an SVN client. I've just reorganized
things in a bit better way in that version, and we're about to start
working in earnest on version 2.0.
--
Matt Woodward
mpwoo...@gmail.com
Kurt Wiersma
Kurt Wiersma
Cozmo Trouble
http://www.laputan.org/mud/
Anyone who has been in he trenches knows this *all* too well.
hth
G
iKnowKungFoo
I was recovering from Lasik on Friday when I saw your post. I was
hoping to reply then, but I couldn't exactly type clearly yet (xanax
is a hell of a drug). :)
I made a presentation on Object Factories at the DFW CFUG last year. I
just uploaded the slides, sql and CF code to their Google Group. The
PowerPoint file contains some UML diagrams that may help you. They
cover inheritance, composition and how the CFCs relate to each other.
http://groups.google.com/group/dfwcfug/web/ColdFusion_Object_Factory.zip
The User model in that example is based on how user information is
organized at my company. It will most likely not reflect how you need
to represent your user data.
We converted our site from a procedural code base to a shared object
oriented architecture. We have about 6 Mach-II applications and over a
dozen non-MVC applications. The non-MVC applications still use objects
to handle data transmission. There are no inline queries and everyone
uses shared objects instead of reinventing the wheel.
Our old site had over 6000 files in our source control repository. The
new OO site has less than 1400 files. We added about 50% more features
to the new site and almost every application was torn down and rebuilt
before it went live.
Since we were able to reuse code everywhere, new functionality could
be shared across applications with little effort. For instance, we had
built an Ajax widget that verified if an insurance policy number was
valid and if that policy number was accessible by the logged in user.
We built it for our payments application, but we needed the
functionality in 6 other applications. We moved the code from the
payments application to a global Ajax library and *BAM!* 7
applications could now validate policy numbers in an afternoon.
As we went to QA and Beta with the site, we were able to turn around
bug fixes in record time. After the site went live, we went nearly a
month before the first non-data bug report. The site is much faster,
load much more quickly and new features can be added in a fraction of
the time it took on the old site. For instance: a new feature was
spec'd out at 120 hours on the old site's code base. We decided to
hold off on that feature until the new site went live. We re-spec'd
the feature on the OO code base and I was able to implement the new
feature in an afternoon.
Old site: 120 hours.
New (OO) site: 2.5 hours.
I'm not even kidding.
Almost every new feature we've added since then has taken considerably
less time to develop than it would have taken on the procedural code
base. There have been periods of time where we haven't had much to do
other than the odd bug fix I mean, I learned Flex one week because I
was bored.
I should mention that everyone here is very competent with CF, but
only a few had ever done any OO programming before and I don't think
anyone else had done OOP to the level that we were heading towards. I
had to drag some of our developers into the OO world kicking and
screaming, but once we all got there, everyone was much happier.
HTH,
Adrian J. Moreno
Senior Web Developer
Unitrin Specialty
http://www.iknowkungfoo.com/
http://www.iknowkungfoo.com/blog/index.cfm/OOP
http://www.iknowkungfoo.com/blog/index.cfm/MachII
>
> read more »
Joseph Campbell
The UML diagrams were a help and should help my team if they switch to OOP. I'm starting to get the hang of it I think. In the near future, instead of converting a complex application from the start I think making some simple Mach-II applications would benefit me more.
As my C/C++ professor said, you can never learn a language until you learn how to program "Hello World".
Thanks again all,
Joe
sli...@gmail.com
from the model already or is this purely a function that should be
kept in the model, i.e. using the object factory.
Also, I think I've been doing a fairly good job writing OO with out an
object factory, but I'm curious how an object factory would help me
with the design of my model, or would it be more of a function of
application performance (i.e. object caching)?
>
> read more »
Ernest Breau
Sean Corfield
> Sometimes my response to this is find a new job where the company
> appreciates employees that want to improve things instead of working to
> keep the status quo.
Yes, that was my first reaction when I saw Joe's comment about his
"lead programmer" - and we wonder why CFers in general have such a bad
rep? :)
Since Joe invoked my name regarding performance, I'll say that bad
architecture is responsible for more bad performance than anything
else. Most of the CF part of adobe.com runs on Mach-II so it can
certainly handle high traffic loads acceptably. Maintainability and
ease of enhancement should be top concerns, along with good
architecture (which Mach-II has in spades). There are lots of ways to
improve the performance of a well-design application - IF it needs it.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
iKnowKungFoo
Property. This is going to be the subject of the next few Mach-II
Primer entries.
However, instead of creating a Property for each DAO, Gateway, Service
Object, etc. you can create a single property for an Object Factory
and let that handle the creation and caching of objects. Rather than
create an Object Factory on their own, many people turn that task over
to the ColdSpring framework. http://www.coldspringframework.org/
If, however, you're building a site with both Mach-II and non-MVC
applications, you might want to avoid having a set of objects cached
by Mach-II and a set cached by the rest of the site. In this case, you
could let the Object Factory or ColdSpring handle caching objects
outside of any one application and then build a Facade object so that
you can access the cached objects from Mach-II.
HTH,
Adrian
On Mar 31, 4:35 pm, "bpick...@forumcomm.com" <slim...@gmail.com>
wrote:
>
> read more »
Patrick Santora
I am trying to get the machblog code from the below address and I am getting an error.
URL: http://svn1.cvsdude.com/mpwoodward/machblog/
ERROR: Could not open the requested SVN filesystem
Am I blindly missing something. :-)
Prem Radhakrishnan
" Just a quick comment on machblog--get the latest from googlecode (soon
to be cvsdude) here:
http://code.google.com/p/machblog/
No zip so you'll have to use an SVN client. I've just reorganized
things in a bit better way in that version, and we're about to start
working in earnest on version 2.0."
A programmer is a device to turn coffee into code
http://www.premsweb.com/blogpro
http://www.39dn.com
Patrick Santora
Let me know what I should no.
Patrick Santora
URL: http://machblog.googlecode.com/svn/trunk/
Is this correct?
Prem Radhakrishnan
and you can check out the code
Prem Radhakrishnan
Patrick Santora
Prem Radhakrishnan
Peter J. Farrell
> From his last email Matt said
>
> " Just a quick comment on machblog--get the latest from googlecode (soon
> to be cvsdude) here:
> http://code.google.com/p/machblog/
>
> No zip so you'll have to use an SVN client. I've just reorganized
> things in a bit better way in that version, and we're about to start
> working in earnest on version 2.0."
>
>
> It may still not be on cvsdude
valid either.
The new official (and permanent) home of MachBlog is:
Trac: http://greatbiztoolsllc-trac.cvsdude.com/machblog/
Svn: http://greatbiztoolsllc-svn.cvsdude.com/machblog/
MachBlog is now an official project of the Mach-II.
Best,
.Peter
Prem Radhakrishnan
Thanks
Patrick Santora
Need to update the blog site itself with the new SVN site :)
Prem Radhakrishnan
Patrick Santora
Matt Woodward
latest latest go here:
http://greatbiztoolsllc-svn.cvsdude.com/machblog/
"Trunk" is the current development code which includes a partially
revamped admin console. Much of this is half-implemented so beware
errors, etc. This is bleeding edge.
The 1.0 version is in branches/1.0
The stuff in GoogleCode is still there, and it's a post-1.0 revamp of
the code organization but with all the same functionality in 1.0.
Actually I think I'll pull that down and make it 1.1 or something just
to avoid confusion (like there isn't enough already).
We also have a Trac site so you can see tickets, development progress, etc.:
http://greatbiztoolsllc-trac.cvsdude.com/machblog
Finally for MachBlog specific issues, please join the Google Group for MachBlog:
http://groups.google.com/group/machblog
Which apparently I will have to turn moderation on for (at least for
new members) since it's currently clogged with all sorts of nice spam.
Matt Woodward
version to cvsdude as branches/1.1 but I'll let you know when it's up
there. Note that I WILL be deleting all the code over on google VERY
SOON so don't rely on it being there long.
--
Patrick Santora
sli...@gmail.com
coldspring a chance for our application. My supervisors think that one
framework is enough to deal with for now. But I came across an object
factory made publicly available at nictunny.com. Here is what he has
to say about it:
"It takes a page from ColdSpring and provides an XML configuration
file, but is extremely lightweight (only two files). It handles
default constructor arguments as well as composition. It also caches
singletons."
It can be found here http://www.nictunney.com/index.cfm?mode=entry&entry=6DACBE6F-65B8-F252-76EC106E89049009.
Has anyone here had any experience with this? I think that I am going
to give it a spin.
On Apr 1, 10:47 am, iKnowKungFoo <amor...@iknowkungfoo.com> wrote:
> That all depends. Mach-II can cache objects by creating them as a
> Property. This is going to be the subject of the next few Mach-II
> Primer entries.
>
> However, instead of creating a Property for each DAO, Gateway, Service
> Object, etc. you can create a single property for an Object Factory
> and let that handle the creation and caching of objects. Rather than
> create an Object Factory on their own, many people turn that task over
>
> read more »
Peter J. Farrell
http://status.cvsdude.com/status/2008/04/node11-unrespon.html
.Peter
Patrick Santora said the following on 4/1/2008 12:36 PM:
Matt Woodward
Don't think of CS as a framework in the same sense as Mach-II--if all
you're going to use it for is dependency injection then the learning
curve is very small and it will save you TONS of headaches. Pushing
back by saying "one framework is enough" is kind of missing the point
of CS since it's not something you really have to spend tons of time
learning. I taught the basics of it to my team at work in about 2
hours and they all seemed to get it.
--
sli...@gmail.com
to happen at least for now. Once we make the full move to OOP (right
now Im the only one doing it) I'll be able to make a better case for
its use. But until then I'm hoping this bean factory that I found will
do.
On Apr 1, 2:42 pm, "Matt Woodward" <mpwoodw...@gmail.com> wrote:
> Honestly if you don't use ColdSpring you're doing things the hard way.
> Don't think of CS as a framework in the same sense as Mach-II--if all
> you're going to use it for is dependency injection then the learning
> curve is very small and it will save you TONS of headaches. Pushing
> back by saying "one framework is enough" is kind of missing the point
> of CS since it's not something you really have to spend tons of time
> learning. I taught the basics of it to my team at work in about 2
> hours and they all seemed to get it.
>
> <slim...@gmail.com> wrote:
>
> > Unfortunately at this time I don't have an opportunity to give
> > coldspring a chance for our application. My supervisors think that one
> > framework is enough to deal with for now. But I came across an object
> > factory made publicly available at nictunny.com. Here is what he has
> > to say about it:
> > "It takes a page from ColdSpring and provides an XML configuration
> > file, but is extremely lightweight (only two files). It handles
> > default constructor arguments as well as composition. It also caches
> > singletons."
>
> read more »
iKnowKungFoo
http://www.iknowkungfoo.com/blog/index.cfm/2008/4/1/Who-hard-codes-Object-Dependency
http://www.iknowkungfoo.com/images/blog/fun/ap_coldspring.jpg
On Apr 1, 2:42 pm, "Matt Woodward" <mpwoodw...@gmail.com> wrote:
> Honestly if you don't use ColdSpring you're doing things the hard way.
> Don't think of CS as a framework in the same sense as Mach-II--if all
> you're going to use it for is dependency injection then the learning
> curve is very small and it will save you TONS of headaches. Pushing
> back by saying "one framework is enough" is kind of missing the point
> of CS since it's not something you really have to spend tons of time
> learning. I taught the basics of it to my team at work in about 2
> hours and they all seemed to get it.
>
> <slim...@gmail.com> wrote:
>
> > Unfortunately at this time I don't have an opportunity to give
> > coldspring a chance for our application. My supervisors think that one
> > framework is enough to deal with for now. But I came across an object
> > factory made publicly available at nictunny.com. Here is what he has
> > to say about it:
> > "It takes a page from ColdSpring and provides an XML configuration
> > file, but is extremely lightweight (only two files). It handles
> > default constructor arguments as well as composition. It also caches
> > singletons."
>
> read more »
Matt Woodward
<sli...@gmail.com> wrote:
>
> Yeah, I understand that and I wish I could use it but It's not going
> to happen at least for now. Once we make the full move to OOP (right
> now Im the only one doing it) I'll be able to make a better case for
> its use. But until then I'm hoping this bean factory that I found will
> do.
I guess I'm just having a hard time wrapping my head around the
resistance to taking a couple of hours, or heck even a couple of days,
to learn something that will make everyone's lives so much easier. Why
the resistance? Why the micromanagement? (I know, probably questions
you can't really answer. ;-) They'll let you use a bean factory
beacuse why, it's just a couple of files, as opposed to a complete
killer solution like ColdSpring? Boggles the mind. ;-)
sli...@gmail.com
dont have write privilages to the right folder in order to install it.
Nor do I have access to the coldfusion admin. I'd have to explain to
my system administrator why I need the files there, which would turn
it into a big deal even though I know its not a big deal at all. But
like I said, once the whole development team makes the switch (my work
is basically the guinea pig for OO programming here) they will see the
need.
It's a miracle that they allowed me to do our new cms in Mach-ii in
the first place. Especially when you take into consideration that I
just graduated from my two year college program this past fall
semester and have been working here only since January.
On Apr 1, 4:09 pm, "Matt Woodward" <mpwoodw...@gmail.com> wrote:
> On Tue, Apr 1, 2008 at 4:35 PM, bpick...@forumcomm.com
> <slim...@gmail.com> wrote:
>
> > Yeah, I understand that and I wish I could use it but It's not going
> > to happen at least for now. Once we make the full move to OOP (right
> > now Im the only one doing it) I'll be able to make a better case for
> > its use. But until then I'm hoping this bean factory that I found will
> > do.
>
> I guess I'm just having a hard time wrapping my head around the
> resistance to taking a couple of hours, or heck even a couple of days,
> to learn something that will make everyone's lives so much easier. Why
> the resistance? Why the micromanagement? (I know, probably questions
> you can't really answer. ;-) They'll let you use a bean factory
> beacuse why, it's just a couple of files, as opposed to a complete
> killer solution like ColdSpring? Boggles the mind. ;-)
> --
> Matt Woodward
Matt Woodward
<sli...@gmail.com> wrote:
>
> To tell you the truth I would just go ahead and use coldspring, but I
> dont have write privilages to the right folder in order to install it.
> Nor do I have access to the coldfusion admin. I'd have to explain to
> my system administrator why I need the files there, which would turn
> it into a big deal even though I know its not a big deal at all.
Wow--not to harp on another point here but you do develop locally,
right? As in on your own workstation/laptop?
--
Matt Woodward
mpwoo...@gmail.com
sli...@gmail.com
testing code, we each have our own public folders on a cf dev box that
we have to test our code. The mach-ii installation is above that in
terms of the folder structure making it non-public as well as me not
having permissions to the folder. We don't don't have cf installed
locally on our machines if that is what you were getting at...
On Apr 1, 4:46 pm, "Matt Woodward" <mpwoodw...@gmail.com> wrote:
> On Tue, Apr 1, 2008 at 5:27 PM, bpick...@forumcomm.com
> <slim...@gmail.com> wrote:
>
> > To tell you the truth I would just go ahead and use coldspring, but I
> > dont have write privilages to the right folder in order to install it.
> > Nor do I have access to the coldfusion admin. I'd have to explain to
> > my system administrator why I need the files there, which would turn
> > it into a big deal even though I know its not a big deal at all.
>
> Wow--not to harp on another point here but you do develop locally,
> right? As in on your own workstation/laptop?
>
> --
> Matt Woodward
Matt Woodward
<sli...@gmail.com> wrote:
>
> We don't don't have cf installed
> locally on our machines if that is what you were getting at...
Yep, exactly what I was getting at. Another thing I'd strongly,
strongly recommend. I'll leave using a bug tracker and version control
system for another day. ;-)
--
Matt Woodward
mpwoo...@gmail.com
sli...@gmail.com
go this route. My guess would have to do with being able to connect to
our dev db for testing, and keeping our development areas as much of a
clone of our live box as much as possible. Version control we use, and
if a ticketing system is the same as a bug tracker then we use that
too.
On Apr 1, 5:24 pm, "Matt Woodward" <mpwoodw...@gmail.com> wrote:
> On Tue, Apr 1, 2008 at 6:02 PM, bpick...@forumcomm.com
> <slim...@gmail.com> wrote:
>
> > We don't don't have cf installed
> > locally on our machines if that is what you were getting at...
>
> Yep, exactly what I was getting at. Another thing I'd strongly,
> strongly recommend. I'll leave using a bug tracker and version control
> system for another day. ;-)
> --
> Matt Woodward