Hello Ryan & team, and thank you for all your work, I'm absolutely loving all your tutorials ! By far the best courses I found on the internet, as I'm beginning my programmers journey, I can relate on this.
This composer tutorial made me think : Isn't an idea to display somewhere (subtitle, under the video, on the course list, ...) some context informations about your courses ?
_Date of recording _Last edition (Updated for sf4.2 etc) _The versionning of every component used in this course (PHPStorm: 2018.2, Composer: 1.8.2, Symfony: 3.3, PHP: 7.1, etc.. Even push further with symfony components version), and this course is validated for (PHPStorm: actual, Composer: actual, Symfony: until 5.0, PHP: until 7.4, etc..) <-- this was totally non-real exemples, don't search any logic !
I Know some of the informations are recorded (I can't even imagine you don't have a createdAt column in your db :) ), some of them are displayed (you put headband on some courses updated or deprecated), but I think beeing more consistant and rigorous with "versionning" can have huge benefits : _For users who come and measure how usable can be a tutorial, and follow it with the insurance that it's actual, in a single glance,
_For you to track precisely what you have to update/revamp, according to each tool used in a video.
I'm actually EATING the courses of your site, so if you're interested I can keep a track of which version of what is in every courses, that can be a starting point ?
Anyway, thank you for reading me and thinking a bit about it, I really think it's one of the rare defaults here ! Road to perfection !
Welcome - and thank you VERY much for your kind words. It means a lot, and I'll pass them to the whole team ❤️
About your idea, we think alike ;). We currently have a feature that's in its *final* stages of development that will do almost all of this: it will tell you the version of the major piece of technology being taught (e.g. "Symfony 4"), but will also expose the specific version of all of the dependencies - e.g. "symfony/framework-bundle" 4.2.3. In addition, you're 100% correct that even this doesn't tell the whole story. Even if a tutorial is built on Symfony 4.2, we might be keeping it up-to-date and valid for all versions of Symfony. So, when we need to, we also add a descriptive note about that - e.g. "This tutorial was built in Symfony 4.2, but is valid for all versions of Symfony 4". All of this will be deployed... hopefully as early as next week?
How does that work for you? We aren't planning to show a recorded data because we think that could cause a "false positive" "this is too old" feeling. Most technology will change fairly quickly and invalidate tutorials over a few years. But some are solid and can last much longer without needing to be updated. The version of Composer and PhpStorm *shouldn't* affect things in a significant way (except for possibly the phpstorm and composer tutorials [this one!] where we could/should indeed list them - I hadn't thought about those 2 cases :)).
Let me know - I really appreciate the feedback and conversation!
The imgur link doesn't work for some reasons, but I'll just seek and enjoy the new version as soon as it will be live.
Your question about the age of a tutorial deserves a real discussion.
you're 100% right, I can relate on : dates hit me more than "versions". When I see a 3 years old, 4 years old content, I'm not willing to click.. And I'm sure my 2016's me would hate me for that !
Maybe I behave like this because I don't want to see something "out of date" ? I already followed a bootstrap 3 tutorial with practical works, on bootstrap 4 (I didn't know about the difference) : NEVER AGAIN.. Or, I am a hipster and I always want to see something about shiny new technology ? I don't know. For example, knowing that "the gang of 4" classified the actual design patterns 25 bloody years ago doesn't compute in my head. I accept this for science, but not for IT; Hipster thing surely.
You're absolutely right about the date displaying, and that's why the 2nd part ("from sf3.0" "to sf5.1") of my precedent suggestion is soooo important : it's not just about keeping records on your side for some reasons; It's about the contract with the user. The guarantee. The API.
False positive : _"This is too old" but the tutorial is still up to date ! The user lost an opportunity to learn something and go away... --> With this information, he knows he can follow your tutorial: you guarantee it.
False negative : _"This is OK" but the tutorial is deprecated ! The user tries to fit circles into squares with deprecated components, get frustrated and lose faith... --> With this information, he knows he must skip these cool-but-deprecated videos: you warned him.
The bonus hidden case : _I'm a generic dev, my company works only on a sf3.4 app and it's not going to change, so I'm searching for good tutorials. But when I see brand new shining one, maybe this is not for me. Aaaaand you have a false positive on "it's too new".
Because in fact you absolutely can do a tutorial on sf5.1 now that is backward compatible with sf4.1 for example !
So ultimately, you don't really say:
"this tutorial was recorded on symfony 2.2 but it stills OK for symfony 5.1".
But instead:
"this tutorial is compatible for symfony versions between 2.2 and 5.1".
This way, you don't really have to give the information "created date" and "last revision date" as it's not relevant anymore (unless you write "revision date" as "certification date", to reassure people about how active you are). "From" & "to" are OK to 99% of use cases, with a simple color code for validated, partly deprecated or fully deprecated courses.
We are lucky, we currently have a real case scenario : Authentication ! Sf5.1 proposes a new authentication workflow, and will be (let's say it will be) the only one standing on sf6.0. You actually have an awesome tutorial about "Beautiful Authentication, Powerful Authorization". This one is sf4' Spacebar related, but maybe it is ok with sf3.3 (I don't really know). So this "Beautiful Authentication, Powerful Authorization" will have information "compatible from sf3.3 to sf5.4". Then, imagine you make a new tutorial about authentication, using the brand new system. You're late, and you publish it when sf6.1 is out. So this "new authentication tutorial" will have information "compatible from sf5.1 to sf6.1". And at every new version of sf out, like sf6.2, you check if the authentication stills the same (2 seconds for you), validate & update your course, "compatible from sf5.1 to sf6.2".
Of course, you can improve the granularity by storing this information for each symfony component or PHP tools, with your new system. You can even imagine a "filter section" on the left of your courses list, like on e-shopping sites you know : version of forms, version of httpfoundation, brand, color, price... Wait, is there a make:filter command ??
I really think this is the best organization you have to either ensure every user finds what he searches for, and you to track efficiently your numerous courses.
Please take a few minutes to think about it, appropriate the idea, and let's see how it grows !
Thank you very much again all your work, I'm going to make some suggestion to the make:reset-password bundle I played with :p
Thanks for the long reply - I read all of it, and really appreciate it!
> It's about the contract with the user. The guarantee. The API.
💯💯💯
That's the idea that resonates with me as well. I want to have an agreement with our users that a specific tutorial is valid for a specific "range" of Symfony versions (or whatever the main tech is).
> Then, imagine you make a new tutorial about authentication, using the brand new system. You're late, and you publish it when sf6.1 is out. > So this "new authentication tutorial" will have information "compatible from sf5.1 to sf6.1".
So this is very interesting. As I mentioned, we *do* have (in the upcoming feature) a place for exactly this message as well as a simple way just to "tag" a tutorial with a "main" technology version that it uses - e.g. "Symfony 5". Here's the proper Imgur link - https://imgur.com/a/6OvOJv1 - you can see the "Symfony 2" in the background but more information when you enquire.
But what I hadn't really thought about was a specific range... especially one that could span to another Symfony major version - e.g. Sf 5.1 to 6.1 (while waiting for the Symfony 6 security tutorial). That's really interesting. I'll take this feedback to the team. The trick with all of this is maintaining these versions in some "sane" way - we have MANY tutorials, and checking and updating them by hand every 6 months would be a lot of work, not to mention error-prone. That being said, especially with Symfony's versioning and deprecation policy, there are some ways that I think this could be automated.
having problems with the fixtures, when i run php app/console doctrine:fixtures:load i got You have requested a non-existent parameter "database_path" im using sqlite database, i found the solution for composer havig same problem here http://stackoverflow.com/qu... but how to use it in the doctrine:fixtures?
This typically just means that you're missing a database_path parameter in your app/config/parameters.yml file in Symfony. Actually, if you're getting this error when running the fixtures command, you should be getting this error when you do anything - i.e. load a page - because Symfony can't boot until all of the parameters have been defined. In other words, because you have a %database_path% in your app/config/config.yml file, you need to have a database_path parameter defined in app/config/parameters.yml.
8 Comments
Hello Ryan & team, and thank you for all your work, I'm absolutely loving all your tutorials ! By far the best courses I found on the internet, as I'm beginning my programmers journey, I can relate on this.
This composer tutorial made me think : Isn't an idea to display somewhere (subtitle, under the video, on the course list, ...) some context informations about your courses ?
_Date of recording
_Last edition (Updated for sf4.2 etc)
_The versionning of every component used in this course (PHPStorm: 2018.2, Composer: 1.8.2, Symfony: 3.3, PHP: 7.1, etc.. Even push further with symfony components version), and this course is validated for (PHPStorm: actual, Composer: actual, Symfony: until 5.0, PHP: until 7.4, etc..) <-- this was totally non-real exemples, don't search any logic !
I Know some of the informations are recorded (I can't even imagine you don't have a createdAt column in your db :) ), some of them are displayed (you put headband on some courses updated or deprecated), but I think beeing more consistant and rigorous with "versionning" can have huge benefits :
_For users who come and measure how usable can be a tutorial, and follow it with the insurance that it's actual, in a single glance,
_For you to track precisely what you have to update/revamp, according to each tool used in a video.
I'm actually EATING the courses of your site, so if you're interested I can keep a track of which version of what is in every courses, that can be a starting point ?
Anyway, thank you for reading me and thinking a bit about it, I really think it's one of the rare defaults here ! Road to perfection !
Regards,
Hi Julien R.!
Welcome - and thank you VERY much for your kind words. It means a lot, and I'll pass them to the whole team ❤️
About your idea, we think alike ;). We currently have a feature that's in its *final* stages of development that will do almost all of this: it will tell you the version of the major piece of technology being taught (e.g. "Symfony 4"), but will also expose the specific version of all of the dependencies - e.g. "symfony/framework-bundle" 4.2.3. In addition, you're 100% correct that even this doesn't tell the whole story. Even if a tutorial is built on Symfony 4.2, we might be keeping it up-to-date and valid for all versions of Symfony. So, when we need to, we also add a descriptive note about that - e.g. "This tutorial was built in Symfony 4.2, but is valid for all versions of Symfony 4". All of this will be deployed... hopefully as early as next week?
Here's a preview of what it would look like, for a particularly old tutorial: https://imgur.com/undefined
How does that work for you? We aren't planning to show a recorded data because we think that could cause a "false positive" "this is too old" feeling. Most technology will change fairly quickly and invalidate tutorials over a few years. But some are solid and can last much longer without needing to be updated. The version of Composer and PhpStorm *shouldn't* affect things in a significant way (except for possibly the phpstorm and composer tutorials [this one!] where we could/should indeed list them - I hadn't thought about those 2 cases :)).
Let me know - I really appreciate the feedback and conversation!
Cheers!
Hello weaverryan,
Thank you for taking time to answer me !
The imgur link doesn't work for some reasons, but I'll just seek and enjoy the new version as soon as it will be live.
Your question about the age of a tutorial deserves a real discussion.
you're 100% right, I can relate on : dates hit me more than "versions". When I see a 3 years old, 4 years old content, I'm not willing to click.. And I'm sure my 2016's me would hate me for that !
Maybe I behave like this because I don't want to see something "out of date" ? I already followed a bootstrap 3 tutorial with practical works, on bootstrap 4 (I didn't know about the difference) : NEVER AGAIN..
Or, I am a hipster and I always want to see something about shiny new technology ? I don't know. For example, knowing that "the gang of 4" classified the actual design patterns 25 bloody years ago doesn't compute in my head. I accept this for science, but not for IT; Hipster thing surely.
You're absolutely right about the date displaying, and that's why the 2nd part ("from sf3.0" "to sf5.1") of my precedent suggestion is soooo important : it's not just about keeping records on your side for some reasons; It's about the contract with the user. The guarantee. The API.
False positive :
_"This is too old" but the tutorial is still up to date ! The user lost an opportunity to learn something and go away... --> With this information, he knows he can follow your tutorial: you guarantee it.
False negative :
_"This is OK" but the tutorial is deprecated ! The user tries to fit circles into squares with deprecated components, get frustrated and lose faith... --> With this information, he knows he must skip these cool-but-deprecated videos: you warned him.
The bonus hidden case :
_I'm a generic dev, my company works only on a sf3.4 app and it's not going to change, so I'm searching for good tutorials. But when I see brand new shining one, maybe this is not for me. Aaaaand you have a false positive on "it's too new".
Because in fact you absolutely can do a tutorial on sf5.1 now that is backward compatible with sf4.1 for example !
So ultimately, you don't really say:
But instead:
This way, you don't really have to give the information "created date" and "last revision date" as it's not relevant anymore (unless you write "revision date" as "certification date", to reassure people about how active you are). "From" & "to" are OK to 99% of use cases, with a simple color code for validated, partly deprecated or fully deprecated courses.
We are lucky, we currently have a real case scenario : Authentication !
Sf5.1 proposes a new authentication workflow, and will be (let's say it will be) the only one standing on sf6.0.
You actually have an awesome tutorial about "Beautiful Authentication, Powerful Authorization". This one is sf4' Spacebar related, but maybe it is ok with sf3.3 (I don't really know).
So this "Beautiful Authentication, Powerful Authorization" will have information "compatible from sf3.3 to sf5.4".
Then, imagine you make a new tutorial about authentication, using the brand new system. You're late, and you publish it when sf6.1 is out.
So this "new authentication tutorial" will have information "compatible from sf5.1 to sf6.1".
And at every new version of sf out, like sf6.2, you check if the authentication stills the same (2 seconds for you), validate & update your course, "compatible from sf5.1 to sf6.2".
Of course, you can improve the granularity by storing this information for each symfony component or PHP tools, with your new system. You can even imagine a "filter section" on the left of your courses list, like on e-shopping sites you know : version of forms, version of httpfoundation, brand, color, price... Wait, is there a make:filter command ??
I really think this is the best organization you have to either ensure every user finds what he searches for, and you to track efficiently your numerous courses.
Please take a few minutes to think about it, appropriate the idea, and let's see how it grows !
Thank you very much again all your work,
I'm going to make some suggestion to the make:reset-password bundle I played with :p
Hey Julien R.!
Thanks for the long reply - I read all of it, and really appreciate it!
> It's about the contract with the user. The guarantee. The API.
💯💯💯
That's the idea that resonates with me as well. I want to have an agreement with our users that a specific tutorial is valid for a specific "range" of Symfony versions (or whatever the main tech is).
> Then, imagine you make a new tutorial about authentication, using the brand new system. You're late, and you publish it when sf6.1 is out.
> So this "new authentication tutorial" will have information "compatible from sf5.1 to sf6.1".
So this is very interesting. As I mentioned, we *do* have (in the upcoming feature) a place for exactly this message as well as a simple way just to "tag" a tutorial with a "main" technology version that it uses - e.g. "Symfony 5". Here's the proper Imgur link - https://imgur.com/a/6OvOJv1 - you can see the "Symfony 2" in the background but more information when you enquire.
But what I hadn't really thought about was a specific range... especially one that could span to another Symfony major version - e.g. Sf 5.1 to 6.1 (while waiting for the Symfony 6 security tutorial). That's really interesting. I'll take this feedback to the team. The trick with all of this is maintaining these versions in some "sane" way - we have MANY tutorials, and checking and updating them by hand every 6 months would be a lot of work, not to mention error-prone. That being said, especially with Symfony's versioning and deprecation policy, there are some ways that I think this could be automated.
Cheers!
having problems with the fixtures, when i run php app/console doctrine:fixtures:load i got You have requested a non-existent parameter "database_path" im using sqlite database, i found the solution for composer havig same problem here http://stackoverflow.com/qu... but how to use it in the doctrine:fixtures?
Hey Arturas!
This typically just means that you're missing a database_path parameter in your app/config/parameters.yml file in Symfony. Actually, if you're getting this error when running the fixtures command, you should be getting this error when you do anything - i.e. load a page - because Symfony can't boot until all of the parameters have been defined. In other words, because you have a %database_path% in your app/config/config.yml file, you need to have a database_path parameter defined in app/config/parameters.yml.
Let me know if that helps :)
Yes, that helps, thanks a lot!
very nice! I love the narration...it added to the simplicity as it has a good flow! Thanks again
"Houston: no signs of life"
Start the conversation!