Show #201 - Hangovers, Frameworks and Whinging

ColdFusion , Frameworks Add comments

In this show Dave and Scott relive and re-love the CFSummit 2013 conference, FW/1 will soon get an update, and they discuss a recent blog post regarding CFSummit news and updates.

 


Show Link: http://traffic.libsyn.com/cfhour/Show_201_-_Hangovers_Frameworks_and_Whinging.mp3

 

Sponsor

 

A little bit about our sponsor. Host Media is, among other things, a ColdFusion hosting provider. Click the link below for an exclusive discount for CFHour listeners using the discount code 'cfhour'

Host Media
http://www.hostmedia.co.uk/

 

Show Topic Links:

cf.Objective() 2014 call for speakers
https://trello.com/b/4M6JSoyL/cf-objective-call-for-speakers-2014

FW\1 The year ahead
http://corfield.org/blog/post.cfm/fw-1-the-year-ahead

CFSummit Rant
http://trendecide.com/entry/cf-summit-2013-rant

 

Buy Stuff

 

http://cfhour.spreadshirt.com/

Credits

CFHour intro and outro audio created and provided by vocal talent James Allen: http://jamesallenvoice.com

24 responses to “Show #201 - Hangovers, Frameworks and Whinging”

  1. Brad Wood Says:
    Good show, guys. I wanted to point out there seems to be some confusion about the shared MVC conventions between FW/1 and ColdBox. (ColdBox and ColdBox Lite have the same MVC conventions) Sean used ColdBox for a while before he wrote FW/1 and the controller layout and "rc" naming etc was borrowed from ColdBox, not the other way around.

    I'd also like to hear your opinions on WireBox. I consider it to be the premier dependency inject and persistence engine in the CF world, but I got the idea it all comes down to ColdSpring and DI/1 for you guys.

    As an example of how easy WireBox can be, the simplest way to use it (with zero configuration) is to drop a CFC in a folder called "models" and then put getModel("foo") in your code. That's it. I'm pretty certain that ranks up there with the simplicity of FW/1 except we were doing that long before. Of course, it also supports autowire, persistence, AOP and has come bundled with ColdBox since the beginning. I'm curious if you don't like it, or just didn't realize what it does.
  2. Sean Corfield Says:
    Whilst FW/1 was indeed a reaction to the bloatware that most CFML frameworks had become, I am pretty sure I had NOT used ColdBox prior to developing FW/1:

    http://corfield.org/blog/post.cfm/introducing-framework-one

    I didn't actually use ColdBox until August 2009, as I recall. I'm at Clojure/conj right now so I can't check the exact date of my first consulting work with World Singles, which was my first run-in with ColdBox...

    As Brad says tho' ColdBox didn't borrow anything from FW/1 (except perhaps the notion of ColdBox Lite - although in what universe that actually qualifies as a "lite" framework I have no idea!).

    As for WireBox, all of its non-trivial uses require annotations in the model - which runs completely counter to the whole point of Inversion of Control. The model should know *nothing* about the Dependency Injection framework.
  3. Brad Wood Says:
    > all of its non-trivial uses require annotations in the model

    Not true at all. Everything you can accomplish with annotations is also possible with the mapping DSL.

    map("foo").to("model.foo").asSingleton();

    I don't quite agree on whether that breaks ioc though. The point isn't that the model understands its dependencies and environment (I mean, it has to use them in its code for goodness sake). It's that the models don't have to do the work to create them and and provide persistence. That's where the ioc comes in. You simply describe what the model needs, and the ioc container makes it happen. Personally I love the annotations as it keeps the information about my domain objects right there inside of them.

    If FW/1 can have a > 2,000 line god object, I'm sure we can live with some annotations in our models :)

    Thanks for the corrections on the dates. I knew you had been working on FW/1 a while before it was released but I didn't remember seeing it in the wild until after your ColdBox usage.
  4. Sean Corfield Says:
    Ah, I'd forgotten about the DSL... The Builder pattern... very Enterprise-y :)

    Yeah, I wrote FW/1 to "scratch an itch" and made it FOSS (of course) and people just seemed to like it so it gained a life of its own with a long list of contributors over time. Using both ColdBox and FW/1 at World Singles (for different parts of the system) really contrasts the approaches and I can see why users tend to gravitate to one or the other and can get rather zealous about it...
  5. Scott Stroz Says:
    Brad - sorry for the confusion (on our part) about which framework came first.

    As for WireBox I cannot offer up a valid opinion as I have never used it. I planned on using a WireBox example in my CF Summit, but I found the documentation a bit confusing and after spending more time than I think it should have to get a working example, I decided against it.

    The *Box suite has a ton of documentation, but, sometimes, I think it is overkill. Every time I have tried to do something with *Box, I always get frustrated with how long it takes to find what it is I need. I know how it sounds to complain there is 'too much' documentation, but to me, the best documentation is not necessarily the one with the most pages, but the one that is easiest to find what I need.
  6. Brad Wood Says:
    Thanks for the feedback. We understand that's an issue which is we we've begun creating the getting started ref cards. Have you seen the reference card for WireBox? It's only 6 pages and tries to only cover the getting started stuff.

    https://github.com/ColdBox/cbox-refcards/raw/master/WireBox/WireBox-Refcard.pdf

    Also, our WireBox doc page covers everything possible with the WireBox utility (which can be used standalone), but a doc like Model Integrations might be more helpful when it comes to actual using models in a ColdBox application.

    http://wiki.coldbox.org/wiki/Models.cfm

    The greatest source of *Box help in the community is the Google Group though. You'll often times get answers within minute at any time of the day or night. It doesn't appear you've ever posted there though. If you ever need clarification, or just a "how do I do this?" question, please PLEASE just post to the list. It's the best help you can get and it's far better than simply giving up.
  7. Scott Stroz Says:
    Brad -

    Thanx for helping me make my point. A 'reference card' that is 6 pages long? This honestly looks a lot like the not-so-clear documenation, only in PDF format.

    Take a look at the DI/1 'Getting Started Guide'. That is how 'getting started' docs should be. Clear and concise.
  8. Brad Wood Says:
    Our ref cards were modeled after the DZone ref cards which are PDF, similar in length, and very popular. DI/1 also has a minute fraction of the functionality of WireBox.

    What formats would you like to see them available in? We created them in InDesign, so if we can export it to your desired format, we will.
  9. Scott Stroz Says:
    It is not the format that concerns me, it is the content. There is nothing in the reference card that makes 'getting started' any more clear than the online docs - matter of fact, I may be more confused now.

    I don't care how much more WireBox may do than DI/1 - a "getting started guide" should be simple, clear and concise. Something this reference card is not.
  10. Brad Wood Says:
    I'm sorry you feel that way Scott. To reduce the content any more would mean we start telling our users how to write their apps. For instance, don't tell them about setter or constructor injection and only show mixin injection. Or completely ignore the mapping DSL, and only show scan locations.

    We're not comfortable making those kinds of decisions for our developers. Instead, we'd rather skim all the approaches with code samples and let users determine how they'd like to use the library. I'm sure it would be simpler to write a guide for a library that gave users only one way to solve the problem.

    Our reference card is also a primer on why you would use an object factory and dependency injection as well. So, you could say we're covering a bit more ground. Our goal was to have something simple and printable for developers to keep at their desk to keep all the basic functionality at their fingertips. Perhaps we can consider something even more dumbed-down when we write our online docs that takes a single approach and covers it.
  11. Scott Stroz Says:
    Brad -

    If you guys were aiming for 'simple' with this reference card, I think you fell quite a bit short of that goal. I would hazard a guess that this could realistically be whittled down by at least half and be more clear and still make all the points you want. It is simply too verbose for a 'getting started guide'.

    The 'menu' of support options on the last page really made me wonder - How much motivation is there to make clear and concise documentation when selling support is part of the business model?
  12. Andy K Says:
    As an active user of both of these frameworks - and a HUGE fan of Coldbox, I have to agree with Scott here: there's a big difference between a reference card/guide/etc. and a getting started guide. You have an awful lot of the former and not nearly enough of the latter.

    The exhaustive Coldbox docs actually have the unintended effect of scaring people away from using it. People coming new to a framework/app want to see a quick 1-page doc, 1-minute screencast, etc. that says "look how quick and simple we can make this". The entire RoR movement was arguably spawned by a simple, short video showing how one could quickly desing an enote app.

    The problem I see with all of the Coldbox docs, presentations, connect sessions, etc. is that they tend to be conducted in a "here is all the shit that we are able to do and all the different ways that we can do it." You start with the complex, deep dive...

    Frankly, you had the right approach in your first post, Brad:

    "As an example of how easy WireBox can be, the simplest way to use it (with zero configuration) is to drop a CFC in a folder called "models" and then put getModel("foo") in your code. That's it."

    Remove all else from page-1 of the docs. This simplicity should be your hook - not the 300 pages of other amazing things you can do (and they are amazing!) The Coldbox approach reminds me of some of the resumes I get: there are some people that send in 10-page resumes with everything and every detail that they've ever done. Guess how many of those get read?

    My unsolicited advice is to avoid the urge to immediately show off every bell and whistle that you have proudly created and instead focus on "look how simple this is" types of material. Once you get the Scott's of the world to take a taste of WB then you can point them to how the DSL and how they can do AOP and how they can use annotations or blah, blah, blah... because right now all they are going to see is the "blah, blah, blah..."
  13. Sean Corfield Says:
    Since Scott raised the issue of documentation... One of the biggest problem we had at World Singles after ColdBox was selected (by the CTO, before I joined), was trying to find answers in the documentation to what should have been simple questions.

    Back then (in the run up to the 3.0 release) there was no real "Getting Started" doc at all and even the supposedly introductory material bombarded you with options and possibilities without telling you the simple step-by-step stuff.

    I recently started looking at TestBox - because I love the BDD style of writing tests - but even there, you're quickly dumped into all the possible options without a real "Getting Started" tutorial. One of the pieces I'm most interested in - at least initially - is the MXUnit compatibility aspect but that is almost completely glossed over, and presented as just yet another option.

    I've heard this complaint from a number of people who've tried to use ColdBox: the documentation is overwhelming (and certainly very impressive) but it really doesn't address the needs of the initial learning curve. Once you're up and running, the documentation becomes easier to use - or simply less relevant and less of a problem - but that doesn't alter the fact that this really is a case of "less is more".

    Saying you can ask on the mailing list is a cop-out: you might as well not bother with documentation if that's your answer to everything. Perhaps that's why you don't hear too many complaints about the documentation? People just get lazy and ask on the list instead of trying to use the documentation. I know from past experience with many projects that really do have excellent "Getting Started" guides, a lot of people don't bother to read them anyway and ask lots of basic questions on the mailing list for the project.

    You could say that's fine and it obviates the need for introductory material but I stand with Scott that if you're trying to produce introductory material (and failing) then it's a failing that should be called out.
  14. Sean Corfield Says:
    And a point I should have included in that:

    When I raised the lack of introductory material with Luis four years ago, he agreed that the documentation was weak in that area - so this isn't just a random drive by criticism of the material. The problem persists today tho' and it's still a case of trying to tell people too much.

    The documentation for FW/1 is far from perfect - I've never claimed to be a good writer of technical material - but it takes a very clear cut approach: Getting Started, Developing Applications, Reference Manual. The intent is that everyone should go through the Getting Started guide, step-by-step and it gives you just one simple way to build your first app. Then you can read the Developing Applications manual piece by piece to get a better idea of what is possible. Finally you can dip into the Reference Manual to understand specifics (of configuration, of the API, etc).
  15. Brad Wood Says:
    I do appreciate the feedback on the docs. I promise we're listening even if we're moving slowly to change it. We've been holding off on rewriting the ColdBox docs for at least a year since we were "on the verge" of re-doing the site and converting the docs to ContentBox. Obviously that transition has taken longer than we expected.

    Believe it or not, the one-page approach to our docs was intentional at one point as we were copying other approaches we saw at the time. An example of a project that still does that is backbonejs.org-- they have a single page of docs on their homepage that would be 72 printed pages. Even the Ruby On Rails "Getting Started" guide is 60 printed pages: http://guides.rubyonrails.org/getting_started.html

    Nonetheless, our goal will be to break the docs up so it's easier to find what you need without mixing the advanced stuff in with the basic stuff. And no, I'm not justifying the complexity of our docs by saying you can ask on the mailing list, but I think it shows a lack of due diligence if you give up on something before even seeking help.
  16. Tim Cunningham Says:
    Gentlemen,

    Let's stop beating around the bush and talk about the real travesty in this podcast. Scott and Dave talked for more than 30 minutes about CFSummit in "Vegas, Baby" and not once even mentioned my penthouse suite.

    What is the point of having a $3,000 a night room if I can't even get one lousy mention on CFHour? Oh sure, Dave and Scott were fine yucking it up in my room at all hours of the night, storing "The Coooler" there, regaling me with stories of Pete "Freaking" Rose, petting the tiger. They even had keys to my room, I don't even want to think how the bidet was filled with so much blood while I was gone or whose severed toe was left in sink.

    But did the penthouse get one little mention? No, sir, not one. I swear, it is as if you gents are trying to get me to move to PHP!!
  17. Luis Majano Says:
    My 2 cents:

    I read all the comments and thanks for a nice read. I agree with all the points, but at the end of the day. It is really easy to say, create the getting started, do this, do that. At the end, it takes time to do things and SOMEONE to do it, and what one person likes, there are 2 that don't. You try one thing, it might work, another might not. You can't be in everybody's head at one time. So catering for different audiences is definitely a challenge. Go try and read the documentation for Spring or Hibernate or Struts and you will see what I mean, and you will think our docs are a cakewalk.

    It has been such an interesting few years to see how to manage POSS software and try to accommodate not only a software, but its ecosystem to many people and be able to bring something of value to the table. It is without saying that maintaining OSS software is not easy (Sean can attest to that), there is so much time, money and effort that we put in to our products that people might never realize it. With that said, I think that being able to bring constructive criticism to the table is very important, but also being able to us as a community to support each other is even better. We all need help and direction to push the envelope.
  18. Tim Cunningham Says:
    Luis,

    You must have missed the point, you didn't even mention the penthouse!
  19. Luis Majano Says:
    I didn't go to CFSummit, so cannot attest, was busy delivering a baby and pooped diapers!
  20. Sean Corfield Says:
    Luis is right about the effort involved in FOSS. I was very pleased to see that Team CF Advance has appointed someone specific to oversee documentation and help everyone get up to speed on producing documentation for the various projects that Team CF Advance works on.

    One of the most frustrating aspects is that sometimes, when there's a gap in your project's documentation, and someone in the community starts to produce their own documentation to fill in that gap, they won't contribute it back to the project or even edit it into the project wiki. I've been lucky with FW/1 - pretty much everyone who has contributed code has also updated the wiki (rarely without prompting tho') and some people even contribute to the wiki without contributing code. Not all projects are that lucky and it can lead to a lot of fragmentation at times...
  21. Tim Cunningham Says:
    Sean,

    Again to of the smartest guys I know are missing the real travesty of this podcast..

    Lack of penthouse!

    The title was Hangover, people. Focus.

    Tim "Stu" Cunningham
  22. Sean Corfield Says:
    FYI: https://github.com/framework-one/aop1 - written by Mark Drew as an extension of DI/1.

    Oh, and as for cfclient making it possible to write code without callbacks - read Ram's blog post where he says this isn't really the case: all the JS to support the UI and most of the UI logic will need to have callbacks... and that stuff isn't meant to be handled by cfclient so developers WILL have to learn about callbacks and will have to write JS. As you can imagine, I'm not impressed by anything I've read / seen / heard about cfclient so far :)

    Re: Tim's penthouse - wasn't there, can't comment!
  23. security news Says:
    Hi to all, it's actually a fastidious for me to pay a quick visit this website,
    it contains helpful Information.
  24. Raymond Camden Says:
    Scott, Ripple info:

    http://www.raymondcamden.com/index.cfm/2013/11/5/Ripple-is-Reborn

    Btw - surprised you haven't seen it before - I've blogged about it a few times. ;)

Leave a Reply

Leave this field empty:

Powered by Mango Blog. Design and Icons by N.Design Studio