I have been diving into different programming languages & frameworks & I am trying to figure out the best way to balance learning theory with hands on practice. I started with some basic scripting to understand syntax then moved into building small apps to get real experience but I still feel there is a lot more to explore.
I noticed that many developers mention frameworks as a key turning point in their learning When someone switches from just learning Ruby to actually working with Rails it feels such as the concepts start clicking in a different way I came across a Rails course online & it made me think whether following structured learning paths around frameworks really helps in getting a stronger grasp compared to just experimenting on your own.
I wanted to ask the community what worked best for you Did you focus more on raw language skills before moving to frameworks or did you learn both side by side I want to hear your approaches & experiences.
Also i have check this Lucee language compared to Clojure with FW/1 framework still need advice.
Iām a huge proponent of learning by doing; which is why I think that the vast majority of the learning that I do has to be work-related / on-the-job learning (or at least job adjacent) or Iāll never build up the muscle memory to make what I learn actually consumable. I do try do some truly independent learning; but, itās considerably less effective than doing something that I can then turn around and use at work.
I think taking a course is helpful to give you the āvibeā of a language / framework. But, Iāve had trouble finishing courses that - again - I canāt immediately translate into something day-to-day.
Of course everyone is different. I wish I had more motivation to learn random stuff. Or at least dabble enough to get the āvibeā of it without feeling the pressure to take something to completion.
Over the last few weeks, I actually just started putting together a side-project for the purpose of being able to do some stuff that isnāt directly work related (but is language related). Iāll see if I have the motivation to go anywhere with it (repo: GitHub - bennadel/app.bigsexypoems.com: Logged-in site for Big Sexy Poems.).
In summation, itās hard. I try to:
Do stuff that is primarily work related.
Do stuff that is geared towards building something.
Iām biased because Iāve been a cfml dev since before frameworks existed, and I had perhaps subjective reasons for avoiding Ruby on Rails, but I do think objectively speaking that the actual use of a framework isnāt absolutely required for simply grasping the fundamentals of models, views, and controllers.
And the analogies in Lucee 6+ are even easier now with the addition of .cfs files (pure cfscript with no tag syntax).
MVC
Lucee
model
.cfc for database queries, etc (one .cfc āobjectā for each db table)
view
.cfm for page templates
controller
.cfs for the business logic that ties everything together
There probably arenāt many Lucee devs actually doing it that way yet (myself included, being only in the early stages of refactoring all of my business logic from .cfm to .cfs, plus I still have some legacy spaghetti code argh), but I find that with some diligence, this manual separation allows more freedom than any framework.
But hey Iāve never actually used a framework haha so take that with a grain of salt!
Then again on the third hand (lol), scaffolding abstracts from knowing whatās actually going on underneath it all.
Also itās important to ignore all of the tag-based documentation that youāll see in many places, less so from Lucee docs, a lot more so from Adobe ColdFusion docs. That is unless itās purely for a page template (aka view), which was the original reason for tags, to mix in nicely with html!
I think creating a project that you can try in different languages is good path. attempting to build the same application in multiple languages helps to understand how different languages and frameworks attempt to solve problems and organize code. At some point Iām going to need to come to terms that I am getting old. Most of the blogs I learned from are long gone.
I maintain a lot of coldfusion code that still runs under MachII which is an oldie but still a goodie.
I thought Ruby with Rails was more of a scaffolding than a framework but it has been a long time since trying to use it. Some concepts take awhile before really understanding the difference between this and that.
At work I was stuck keeping old legacy code going until the sun burns out so I always kept a couple freelance projects where I was free to build in whatever the new thing was.
Another thing was to focus on one piece at a time, trying to learn multiple frameworks that work together can quickly get confusing as to which does what.
Benās blog is still around (Thanks for keeping it up)
The best advice is keep at it until the light bulb goes on
There is so much old, out-dated ColdFusion stuff out there - itās easy to get caught up in that and wind up learning old, out-dated methods.
Iām also a big framework proponent. Why reinvent the wheel?
And +1 for Benās ālearning by doingā. Iām the same way. Dive in and figure it out But Iād balance that with peer reviews, community input, or some way to get your code in front of other people to ensure you are going in the correct direction.
We do have a comprehensive set of Lucee Recipes on Docs, lots of new stuff in there to learn about new features in 6 and 7
Let us know if there are topics youād like us to cover
Also if you see something which could be improved, itās really easy to update them, just click the github icon and you can edit the markdown and submit a PR.
I do need to get around to adding some category labels and stuff to that now rather long list of recipes as that list is quite long, Iām continually working on cross referencing the docs content
I just recently did some git kung-fu to add the latest recipes to the docs home page
The new java integration with 6.2 makes working with java so much nicer than it was in older style cfml, itās well worth reading thru the java category to see what is now possible, I shudder when looking back at the older style of java support
