Model-Glue Training avaliable
Doug Hughes
Please pardon the spam-like nature of this message. I just figured
that a collection of people interested in Model-Glue might also be
interested in the fact that onsite (and soon offsite) training for
Model-Glue is available from Alagad.
Here's a blog entry with more information:
http://alagad.com/go/blog-entry/enterprise-coldfusion-with-model-glue-training-available
For what it's worth, Alagad employs 43% of Team Model-Glue. You can't
get much more experiance than what we have to offer.
If you're interested, please drop me a message off list.
Again, sorry for the spam.
--
Doug Hughes, President
Alagad Inc.
dhu...@alagad.com
888 Alagad4 (x3)
Office: 919 550 0755
Cell: 571 243 7924
Sean Corfield
> For what it's worth, Alagad employs 43% of Team Model-Glue.
Hmm, but you don't employ the author and originator of Model-Glue and
you seem to be pushing your MG expertise pretty heavily lately...
--
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
Doug Hughes
The last thing in the world I want to start is an argument here. I'll
try to contact you off list later and see if there's something I'm
missing regarding your comment.
That said, I think my experiance with Model-Glue is valid and
relevant. I was the first person ever to work with Model-Glue. Joe
gave me a copy at, I think, version 0.4. I've been working with it
since then. I ported an early version of the framework (0.8)
to .NET. I've submitted many many bug reports and fixes. I've helped
tons of people with lots of the concepts. Etc, Etc, Etc.
Furthermore, I suppose the 43% thing is a bit of hyperbole. I
apologize if that ticked you off. That said, if there are 7 members
of team Model-Glue and I personally employ three of them, then my
quote is fact. Though it might, honestly, have little relevance to
the training sessions as I personally (at least for now) will be
teaching.
One other point. I have talked with Joe and received his verbal
support for this program.
Thanks for your feedback, Sean. I highly value your criticisms and
feedback.
Doug Hughes
On Oct 31, 3:30 am, "Sean Corfield" <seancorfi...@gmail.com> wrote:
> On 10/30/07, Doug Hughes <douge...@gmail.com> wrote:
>
> > For what it's worth, Alagad employs 43% of Team Model-Glue.
>
> Hmm, but you don't employ the author and originator of Model-Glue and
> you seem to be pushing your MG expertise pretty heavily lately...
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View --http://corfield.org/
Wally Kolcz
large, new MG web site tomorrow morning for the law school in which I am the
sole architect. Would be nice to have a listing of proposed dates and times
for myself to get better training and also for my eventual replacement when
I quit here.
Rich
(I've been building CF apps for 10 years now, even got certified, and find
my self in a really awkward spot at the moment regarding these
frameworks....) that since we came from other backgrounds we've had to learn
how to build software in an ad-hoc, on the go manner. It even contributed to
giving CF a bad name - pseudo server technology since anyone can do it,
stuff like that. And it's not been easy for me to get my head around some of
the OO concepts for CF with informal frameworks like Mach-II and Model-Glue.
"Informal"? Yes. Don't get me wrong, and my frustrations have led folks like
Peter F and Matt W to think I'm the biggest and dumbest bum in all the land,
but I can't brag enough about the efforts you guys put into building these
frameworks. Really, a huge initiative for no pay - I can not commend you
folks enough. But they've been fluid, dynamic and changing, which
represents the most difficult of environments for learning them. I
personally wanted to learn OO to actually put on some online seminars to
help people like me learn Mach-II and between the framework changing during
the time I was attempting to learn it and my own abilities (or inabilities I
guess!) I've struggled to say the least. Training would be awesome, and
honestly is required if we're going to keep evolving the CF community.
IMHO, the first one to put up some good, structured formal training wins.
I'll even help evaluate some of the learning tools and resources since I've
already built some Mach-II stuff, that's how motivated I am.
Please get past the small stuff, the percentages, who started what.... We
don't care. Let's get busy building some cool-ass CF apps. Thanks for
putting it all together!
Rich
Joe Rinehart
I believe I know what you meant, but I think the first person was
me ;).
I've got no issues with anyone offering training based on Model-Glue.
It's good for the framework, especially if it comes from a third-
party. I don't enjoy doing formal classroom training on a regular
basis, so I'd never offer this service.
<shameless advertisement>
I do offer consulting-style training with MG, where we spend half a
day or so in the classroom and then work hands-on with me as a member
of a development team or architect for an MG project. I've found this
to be of greater value than what I've done in 100% classroom
settings. Please contact me off-list if interested.
</shameless advertisement>
Two things I'd consider:
Anyone offering training based on Model-Glue is putting themselves at
the mercy of the framework. If the framework changed with popular new
features or methods, they'd be subject to their curriculum becoming
partially obsolete without notice.
If I were a third-party offering training, I'd list accomplishment-
based credentials first. While Alagad does employ 43% of Model-Glue
"team members" its team members have contributed very little source
code (I'd rough guess maybe 2%, mostly in ReactorAdapter.cfc, until
Jared gets the Application.cfc bit done) and one blog entry to Model-
Glue.com (not that my track record on keeping the blog fresh is
anything to write home about).
-Joe
Sean Corfield
> If I were a third-party offering training, I'd list accomplishment-
> based credentials first. While Alagad does employ 43% of Model-Glue
> "team members" its team members have contributed very little source
> code (I'd rough guess maybe 2%, mostly in ReactorAdapter.cfc, until
> Jared gets the Application.cfc bit done) and one blog entry to Model-
> Glue.com (not that my track record on keeping the blog fresh is
> anything to write home about).
I think I've contributed more code than that to MG, eh? :) I've
certainly blogged plenty about the framework (although never as a
guest on Joe's blog).
Anyway, I think the point has been made and Doug and I have talked
about this thread off-list so we can all move on...
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
Sean Corfield
> "Informal"? Yes. Don't get me wrong, and my frustrations have led folks like
> Peter F and Matt W to think I'm the biggest and dumbest bum in all the land,
Nah, it's all a big learning experience and everyone starts out a n00b...
> folks enough. But they've been fluid, dynamic and changing, which
> represents the most difficult of environments for learning them. I
And yet when the frameworks become stable, lots of people complain
that they're "dead" and think they should move on to another
framework. One of the key issues here is backward compatibility.
Mach-II 1.5 still runs pretty much every Mach-II application ever
built. Model-Glue 2.0 required a *small* change from 1.0 (really, it
was only a small change - even tho' MG2 looks to be radically
different to MG1). Fusebox 5.5 still runs every Fusebox application
since 4.0 came out years ago. Reactor has been nice and stable for
ages and people are complaining it's "dead". We can't win for losing,
it seems.
Part of the real issue here is that we're all still growing as a
community so what seems to be best practice one day is overturned and
replaced by different best practices every few months. And this is
true of *all* programming communities. You should have seen the churn
in the C++ community through the 80's and 90's as the language evolved
dramatically! There wasn't even a huge amount of backward
compatibility involved (although we - the ANSI committee - had to
preserve a couple of tricky behaviors and practices that were
enshrined in popular books).
There's a sea change happening right now in CF as many people are
beginning to push away from the strongly-typed, Java-centric, heavily
OO / pattern-laden approach that has become popular toward a more
fluid, more dynamic, pragmatic style that you can see reflected in the
huge growth of scripting languages like Ruby, Python and Groovy. CF is
not Java, it's a scripting language. I've been at least partly
responsible for the initial push toward Java, now I'm trying to help
people move toward the other side of the pool and swim with the
pragmatic scripting languages.
You can't just learn one set of techniques and expect to stick with
that - learning is always an ongoing process. I like that, personally,
I try to learn something new every day - some days are more successful
than others :)
Rich
-----Original Message-----
From: model...@googlegroups.com [mailto:model...@googlegroups.com] On
Paul Marcotte
Can you elaborate on the "sea change happening" and how you see OO frameworks fitting into this change? Are we facing a dichotomy of approaches? Or is the change you suggest more evolutionary than revolutionary?
I consider myself to be on a tightrope between procedural and the "OO / pattern-laden approach". Crossing the chasm is scary, but once you commit, it's just as dangerous to turn around. So, what does the "pragmatic" style represent? Every religion has a zealot and it is up to the individual to subscribe to the particular dogma that feels right for them. The explosion of popularity for Rails is a an example of developers embracing something different. DHH delivered a sermon from the mount and many followed.
If procedural development is archaic and pattern-heavy OO development too rigid, is CF ready for a "new religion"?
Paul
Sean Corfield
On 10/31/07, Paul Marcotte <pmar...@gmail.com> wrote:
> Can you elaborate on the "sea change happening"
There is push back against the Java way of thinking (and not just in
the CF community). Not all Java idioms work well in CF because CF has
more in common with Ruby, Python and Groovy really.
> how you see OO frameworks fitting into this change?
I don't see any real change needed in the frameworks - although I
think we'll see a move toward convention. ColdBox uses convention a
lot (and XML a little). Fusebox 5.5 introduces a set of conventions to
allow you to avoid XML altogether. Joe previewed some ideas for MG3
codenamed "Gesture" which uses convention instead of XML. That's more
in keeping with what's happening in other (scripting) languages.
> Are we facing a dichotomy of approaches?
There is no One True Way - there are already many (valid) approaches.
> Or is the change you suggest more evolutionary than revolutionary?
Evolutionary. CF is evolving. Our understanding of idiom and pattern
applicability is evolving. Everything is always evolving. Unless
you're a Creationist, I suppose :)
> I consider myself to be on a tightrope between procedural and the "OO /
> pattern-laden approach". Crossing the chasm is scary, but once you commit,
> it's just as dangerous to turn around.
It isn't really an "either / or" deal. After all, objects contain
procedural code because *something* has to get work done. OO is really
about organization of code, packaging up lots of little "procedures"
along with the data they operate on.
> So, what does the "pragmatic" style represent?
Mostly it's just recognizing that there is no One True Way and that
"pure" OO is a lot of work that isn't always necessary. Take the
controller + service + dao + gateway + bean approach that you see in a
lot of supposedly OO CF code. This happens because of some ideal of
purity: we must separate everything. But all it does is create a huge
amount of code to get something very simple done.
You don't need all of that. It's OK to have a gateway for several
related objects and have it contain the CRUD methods for those objects
as well as everything else. It's OK to have a service component that
handles several related groups of objects. It's OK to have a
controller that talks to several services. That "5:1 syndrome" code
just doesn't scale to large applications. Gateway components often
have to deal with multiple tables so why try to have a separate
gateway for every bean?
> Every religion has a zealot and it is up to the individual to
> subscribe to the particular dogma that feels right for them.
I don't subscribe to any dogma. Dogma makes to less able to make good choices.
> The explosion
> of popularity for Rails is a an example of developers embracing something
> different. DHH delivered a sermon from the mount and many followed.
Rails is pragmatic. Opiniated, sure, but very pragmatic. It doesn't
follow any pure vision. It gets things done.
> If procedural development is archaic and pattern-heavy OO development too
> rigid, is CF ready for a "new religion"?
More to the point, are CFers ready to *stop* trying to embrace
religions and just get things done?
Peter Bell
Best Wishes,
Peter
Rich
I started working with CF in OO.
Except you made sense ;-)
Thanks for your clarification, this has been an outstanding thread.
Rich
-----Original Message-----
From: model...@googlegroups.com [mailto:model...@googlegroups.com] On
Behalf Of Peter Bell
Sent: Thursday, November 01, 2007 2:34 AM
To: model...@googlegroups.com
Sal
codenamed "Gesture" which uses convention instead of XML. That's more
in keeping with what's happening in other (scripting) languages.
Really? Awesome! Looking foward to this Joe!
More to the point, are CFers ready to *stop* trying to embrace
religions and just get things done?
exactly! :-)
good thread folks!
On Nov 1, 8:16 am, "Rich" <r...@cfsnap.com> wrote:
> Wow, you actually spoke entirely to what I've been thinking to myself since
> I started working with CF in OO.
>
> Except you made sense ;-)
>
> Thanks for your clarification, this has been an outstanding thread.
>
> Rich
>
> -----Original Message-----
> From: model...@googlegroups.com [mailto:model...@googlegroups.com] On
>
> Behalf Of Peter Bell
> Sent: Thursday, November 01, 2007 2:34 AM
> To: model...@googlegroups.com
> Subject: Re: Model-Glue Training available
>
> Really nice thread.
>
> Best Wishes,
> Peter
>
> On 11/1/07 4:06 AM, "Sean Corfield" <seancorfi...@gmail.com> wrote:
>
> > Lots of questions!
>
Paul Marcotte
Lots of questions!
Uh, yeah, a bit overboard, thanks for bearing with (and responding too) my ramble, Sean.
Responses below.
On 10/31/07, Paul Marcotte <pmar...@gmail.com> wrote:
> Can you elaborate on the "sea change happening"
There is push back against the Java way of thinking (and not just in
the CF community). Not all Java idioms work well in CF because CF has
more in common with Ruby, Python and Groovy really.
Makes sense. Why force structure where it isn't necessary?
> how you see OO frameworks fitting into this change?
I don't see any real change needed in the frameworks - although I
think we'll see a move toward convention. ColdBox uses convention a
lot (and XML a little). Fusebox 5.5 introduces a set of conventions to
allow you to avoid XML altogether. Joe previewed some ideas for MG3
codenamed "Gesture" which uses convention instead of XML. That's more
in keeping with what's happening in other (scripting) languages.
My only reservation regarding convention is that you sacrifice flexibility. Also, if the convention isn't how you would naturally work something out, then there's an adjustment period. On the other hand, good conventions, universally adopted, have the potential to become standards. Like a lot of new things, it might take a while to get used to, eventually, you wonder how you ever got along without it.
> Are we facing a dichotomy of approaches?
There is no One True Way - there are already many (valid) approaches.
Agreed. Case closed.
> Or is the change you suggest more evolutionary than revolutionary?
Evolutionary. CF is evolving. Our understanding of idiom and pattern
applicability is evolving. Everything is always evolving. Unless
you're a Creationist, I suppose :)
Agreed. Evolution good.
> I consider myself to be on a tightrope between procedural and the "OO /
> pattern-laden approach". Crossing the chasm is scary, but once you commit,
> it's just as dangerous to turn around.
It isn't really an "either / or" deal. After all, objects contain
procedural code because *something* has to get work done. OO is really
about organization of code, packaging up lots of little "procedures"
along with the data they operate on.
Okay, I'm getting it. The largest quantifiable benefit I can identify that comes from my adoption of some OO practices, is encapsulation and code reuse. I get a really big kick out of refactoring code.
> So, what does the "pragmatic" style represent?
Mostly it's just recognizing that there is no One True Way and that
"pure" OO is a lot of work that isn't always necessary. Take the
controller + service + dao + gateway + bean approach that you see in a
lot of supposedly OO CF code. This happens because of some ideal of
purity: we must separate everything. But all it does is create a huge
amount of code to get something very simple done.
You don't need all of that. It's OK to have a gateway for several
related objects and have it contain the CRUD methods for those objects
as well as everything else. It's OK to have a service component that
handles several related groups of objects. It's OK to have a
controller that talks to several services. That "5:1 syndrome" code
just doesn't scale to large applications. Gateway components often
have to deal with multiple tables so why try to have a separate
gateway for every bean?
Strangely enough, this is the tripping point for a lot of folks that are reluctant to adopt OO in CF. I regularly debate this with my colleague . For a custom query used only in one template, the justification is difficult. "Why so much much code for a simple query?", he'll ask. But if I need that query in a couple of templates, or a dozen, it's not only justifiable, it's smart.
Since you bring up the "5:1 syndrome", I would really like to see a good article explaining how this practice is a not set in stone. As a newcomer, I have read as much as possible to get up to speed and the prevailing tutorials/examples out there espouse "5:1".
Is it time for a new article (or series) with a focus on the domain model rather the application model? I'd write one, but I've still got some learning to get there... :(
> Every religion has a zealot and it is up to the individual to
> subscribe to the particular dogma that feels right for them.
I don't subscribe to any dogma. Dogma makes to less able to make good choices.
Wrong word choice on my part. I meant dogma in terms of ideology/philosophy as it pertains to software development. Subscribing to a particular development methodology, like Iterative rather than Waterfall. Or preferring convention over configuration can be viewed as dogmatic.
> The explosion
> of popularity for Rails is a an example of developers embracing something
> different. DHH delivered a sermon from the mount and many followed.
Rails is pragmatic. Opiniated, sure, but very pragmatic. It doesn't
follow any pure vision. It gets things done.
> If procedural development is archaic and pattern-heavy OO development too
> rigid, is CF ready for a "new religion"?
More to the point, are CFers ready to *stop* trying to embrace
religions and just get things done?
Good point. Over-analyzing (something I'm guilty of) and/or adopting a particular application design because it is suggested or demonstrated isn't necessary. After my last barrage of questions, I jotted down a few points to live by as a developer (surely influenced from other things I've read, very likely paraphrased). To use the religious metaphor again, I call them my developer commandments (to myself).
1. Meet the deadline.
2. Meet the specification.
3. Write it clean, (we all hate inheriting messy code, don't leave a mess).
4. Comment concisely.
5. Avoid hacks, but if you must, document it well.
6. Be consistent. Whatever naming / coding standard you have, stick with it.
7. Use the right tool for the job. Don't use MVC, DI, or ORM because it's cool. Use it when you need it. (Which begs the question, when do you need, but I digress...)
8. Refactor wherever possible.
9. If you can't solve a tricky problem, ask for help.
10. Trust your instinct.
You can take that all with a handful of salt, folks!
Paul
--
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
--
Paul Marcotte
Fancy Bread - in the heart or in the head?
http://www.fancybread.com
Roy Martin
Done so far are the following:
1. Installing Model-glue
2. Refactoring an inline application into controllers -> models -> views
3. Introduction to Model-Glue (high level introduction to the Event model)
4. Refactoring inline into Model-Glue
Outstanding that I have a presentation for but no video:
1. MG:unity features: passing data, broadcasts, results, overview
2. Reactor + MG: introduction
3. MG:unity features: generic events, scaffolding
4. Reactor introduction
5. refactoring into reactor
Let me know what topics you like to see covered and of course I'll need everyones feedback as to how useful they are and what I've done wrong :)
Cheers,
Roy
Eric Roberts
I would be interested in this…I am having to learn MG for work and while I am close to understanding it, I don’t think I am quite there yet. The docs on the model glue site are somewhat helpful, but not very good for reference…especially with the damned quiz thing (bad idea). I have been struggling with it ever since. My main problem is that I don’t have a lot of time to play around with this as I am the only developer for one of our applications, so I am usually pretty busy.
Eric
From: model...@googlegroups.com
[mailto:model...@googlegroups.com] On Behalf Of Roy Martin
Sent: Thursday, November 01, 2007 8:39 PM
To: model...@googlegroups.com
Subject: Re: Model-Glue Training available
Without getting into this
debate and hopefully addressing at least the subject of the e-mail :) I've been
training several people on Coldfusion and Model-Glue recently. During which
I've put together several training videos. I'll be posting those this weekend
so I'll follow-up and send the link to everyone to get your feedback. The idea
is to keep each presentation as concise and simple as possible.
Sean Corfield
> My only reservation regarding convention is that you sacrifice flexibility.
Correct. It's a trade off. Pretty much every choice is a trade off.
That is central to the philosophy of patterns too.
> I get a really big kick out of refactoring code.
Good!
> Since you bring up the "5:1 syndrome", I would really like to see a good
> article explaining how this practice is a not set in stone. As a newcomer,
> I have read as much as possible to get up to speed and the prevailing
> tutorials/examples out there espouse "5:1".
Yeah, that's unfortunate... and some of it dates back to my original
Mach-II Development Guide (on LiveDocs) that was written in 2003 and
contained some guidelines to help OO n00bs organize their code.
Unfortunately, lots of ppl took it as a set of commandments instead of
just guidelines and so they ran with the 5:1 syndrome without actually
understanding the guideline :(
> Is it time for a new article (or series) with a focus on the domain model
> rather the application model? I'd write one, but I've still got some
> learning to get there... :(
The trouble is, whenever you publish something, a lot of ppl take it
as gospel and follow it blindly. That's never good.
> Wrong word choice on my part. I meant dogma in terms of ideology/philosophy
> as it pertains to software development. Subscribing to a particular
> development methodology, like Iterative rather than Waterfall. Or
> preferring convention over configuration can be viewed as dogmatic.
Operative word: "prefer" - not "belief". Dogma is belief. Pragmatism
is preference. Preferences are not always followed.
People just take recommendations too seriously. Sometimes I feel like
publishing some really outrageous, stupid guidelines that would cause
ppl to create maintenance nightmares, just to teach them not to
blindly follow stuff :)
> 1. Meet the deadline.
> 2. Meet the specification.
Both important to the client, yes.
> 3. Write it clean, (we all hate inheriting messy code, don't leave a mess).
Write it clean enough.
> 4. Comment concisely.
Picking good names is better. If the code is clean and simple and
reads like English, comments are pretty much not needed.
> 5. Avoid hacks, but if you must, document it well.
Agreed.
> 6. Be consistent.
Agreed. Consistency good.
> 7. Use the right tool for the job. Don't use MVC, DI, or ORM because it's
> cool. Use it when you need it. (Which begs the question, when do you need,
> but I digress...)
You need it when you need it. There are no hard and fast rules. It
depends. You can only figure this out with experience.
> 8. Refactor wherever possible.
Refactor where appropriate. When is it appropriate? See my comment on #7...
> 9. If you can't solve a tricky problem, ask for help.
And ask *early*... don't get stuck for hours on something. At the very
least, walk away, do something else. If it still evades you later, ask
for help immediately. I'm not afraid to ask for help and I've been
building large software systems in a wide variety of technologies for
two decades. I still need help sometimes.
> 10. Trust your instinct.
But see #9. Sometimes you're instinct convinces you you're on the
right track even when you're headed down a dead end.
Above all, don't expect black and white rules. There's no silver
bullet. This stuff is hard. Sometimes, very hard.
Paul Marcotte
Yeah, that's unfortunate... and some of it dates back to my original
Mach-II Development Guide (on LiveDocs) that was written in 2003 and
contained some guidelines to help OO n00bs organize their code.
Unfortunately, lots of ppl took it as a set of commandments instead of
just guidelines and so they ran with the 5:1 syndrome without actually
understanding the guideline :(
I might be talking out my backside here, but in terms of separation of concerns, the 5:1 anti-pattern (can we call it that?) works. The issue (for me) is that it's fine-grained. With experience, a developer can make an informed decision about using 5:1 or not.
> Is it time for a new article (or series) with a focus on the domain model
> rather the application model? I'd write one, but I've still got some
> learning to get there... :(
The trouble is, whenever you publish something, a lot of ppl take it
as gospel and follow it blindly. That's never good.
> Wrong word choice on my part. I meant dogma in terms of ideology/philosophy
> as it pertains to software development. Subscribing to a particular
> development methodology, like Iterative rather than Waterfall. Or
> preferring convention over configuration can be viewed as dogmatic.
Operative word: "prefer" - not "belief". Dogma is belief. Pragmatism
is preference. Preferences are not always followed.
Okay, I stand corrected.
People just take recommendations too seriously. Sometimes I feel like
publishing some really outrageous, stupid guidelines that would cause
ppl to create maintenance nightmares, just to teach them not to
blindly follow stuff :)
Please don't! The reality is that you're an experienced leader in the community and your opinion is respected. If I published a recommendation on application architecture, readers are more likely to scrutinize, scoff at, or debate my ideas (and justifiably so, because I'm inexperienced). I think it would be great to see an article on Fusion Authrity, or in an future FAQU, on the subject.
> 1. Meet the deadline.
> 2. Meet the specification.
Both important to the client, yes.
I'll argue that clients are the income source, so if you want to get paid, keep these two a priority.
> 3. Write it clean, (we all hate inheriting messy code, don't leave a mess).
Write it clean enough.
> 4. Comment concisely.
Picking good names is better. If the code is clean and simple and
reads like English, comments are pretty much not needed.
Yes, that makes sense. Cool.
> 5. Avoid hacks, but if you must, document it well.
Agreed.
> 6. Be consistent.
Agreed. Consistency good.
> 7. Use the right tool for the job. Don't use MVC, DI, or ORM because it's
> cool. Use it when you need it. (Which begs the question, when do you need,
> but I digress...)
You need it when you need it. There are no hard and fast rules. It
depends. You can only figure this out with experience.
> 8. Refactor wherever possible.
Refactor where appropriate. When is it appropriate? See my comment on #7...
> 9. If you can't solve a tricky problem, ask for help.
And ask *early*... don't get stuck for hours on something. At the very
least, walk away, do something else. If it still evades you later, ask
for help immediately. I'm not afraid to ask for help and I've been
building large software systems in a wide variety of technologies for
two decades. I still need help sometimes.
Good point.
> 10. Trust your instinct.
But see #9. Sometimes you're instinct convinces you you're on the
right track even when you're headed down a dead end.
Above all, don't expect black and white rules. There's no silver
bullet. This stuff is hard. Sometimes, very hard.
Hard, yes, but so rewarding when you have a eureka moment, or reach the next plateau in learning. :)
Peter Bell
> People just take recommendations too seriously. Sometimes I feel like
> publishing some really outrageous, stupid guidelines that would cause
> ppl to create maintenance nightmares, just to teach them not to
> blindly follow stuff :)
You mean like creating 5 cfc’s for each business object :->
Sorry Sean – couldn’t resist.
Best Wishes,
Peter