• Misc Help

  • Question regarding personal development methods

Hello there friends and neighbors!

To preface, I would like to say that I'm never going to transition to doing this for a living, this will always be a personal hobby so hopefully that helps with the scope and scale of things.

I've used phpBB as a session base for over a decade now. I don't use anything else from it except on one site, where I use the forum system in it's entirety. A couple of times in the time I've used it, PHP has retired stuff that completely broke the system, causing me a lot of issue with not a lot of help(from phpBB, not you guys) other than "just update the forum software".

So I've contemplated building a framework of sorts in a modular fashion and by that I mean a core sessions system, a plugin for the forum features, another for things that I might need(contact, support stuff, etc). I know that things like this exist but to be clear, I'm not doing it because I think I can do it better, I'm doing this because I want to get better at making something like this.

Currently, my work environment is in Debian, I use SSHFS to connect to my servers and edit in MS Code. If I need to change a file, I open that file and modify it. Any files that it references, I open in the editor and make those changes. Saving the file saves directly to the site I'm working on. Backups exist in case something goes horribly awry.

I've heard and read a lot about working on projects and many things are mentioned that I don't know or work with, various IDEs, things that make deployment easier, etc. I just wonder if there's something I can change in my work environment that would make this easier or if I might as well just keep on keeping on in the way I'm doing it now. Like I said before, I'm never going to be doing this large-scale, I'm just a single guy looking at this code, nobody else will ever need to work on it with me.

Any thoughts or insight is very much appreciated. Thanks for your time!

    Whether you're working by yourself or in a team it's a good idea to have a development environment and to use version control. You have a non-accessible development server and do your coding and testing there. Then, when everything works you can push the functional code to the actual production server. That way, even if something does go horribly awry - well, who cares? Nobody but you can see it.

    That leads in to the version control part of things; if you make a change and something goes horribly awry, just undo the change and try again.

    Personally, I use Docker for a development environment and git with bitbucket for version control; all are free for personal use and have wide user bases so help is readily accessible should something be confusing.

    maxxd thank you very much for taking the time to help. I was just wondering if you could explain the role of each of those. I'm assuming Docker is a disposable OS environment to work in, I've used github in a very limited manner so think it's where I store the files. Bitbucket seems to be a frontend for git but I've never learned about it. In an example hello world environment, how would working on the project look? By that I mean, do I connect to a docker container to work on the files, if I like the edits I've made, use bitbucket to move the files to the git branch and if something goes awry, use the same system to roll back files to before the break?

        Docker is a great way to set up a local environment for your project, including web server, database, etc. It lets you tailor things to exact server OS, database version, PHP version etc. in order to match as closely as possible the environment you will be deploying to. Or, if you choose a hosting option that supports it, you can actually run those same Docker containers on your host for a virtually exact match.

        The downside is that there's a non-trivial learning curve with getting things set up and configured.

          Yeah, docker is not a plug-and-play solution in most cases but I agree completely with NogDog that it's a great way to set up a solid and portable local development environment. Basically, you download docker images from dockerhub that you then run locally so you don't have to install or pollute your system with the actual server stuff like PHP, MySQL, Apache - heck, even composer or node. Think of an image as potentially composable remote server(s) that can be stacked in order to build a fully functional development server, but without having to actually install any of the stuff on your local machine. So you're not stuck with specific versions of anything, or having to resort to things like nvm to use the right version of node for the project you're currently working on. It allows you to selectively run any number of different versions of PHP locally while developing any number of different sites.

          Think of it as local installations of remote servers - for instance, you need to connect to the docker container in order to run commands from the command line, but there's no need to pay a hosting service for your development and testing environments. I hope that makes some sense when taken with NogDog's comments - it's late and it was a long day.

          As for git, it's not actually where you store the files, it's where you store the file history so that anyone you invite to contribute can see every change you've made to the project and you can revert to any previous version of the project during it's entire development lifecycle. This is obviously an incredibly simplistic description - there are branches and workflows and stashes and all sorts of things, but more than anything git is an enormous safety net.

          Bitbucket is a GitHub alternative - it's a remote git server. I use it personally because you can have unlimited private repositories for free so it's more economical than GitHub. My company uses it because ... I'm honestly not privvy to those conversations but I certainly assume there's a reason.

          Basically, using docker and git with bitbucket (or whatever remote git repository you decide on) is a safety net at most stages of development. With git and branching, you can try literally any crazy thing in the code - if it doesn't work, revert it to the branch or commit that did work last. With docker, no one can see any of those crazy things you're trying until you're ready for people to see it. And beyond that you can test out upgrading to latest versions of php or node or whatever without having to worry about a reversion route if something doesn't work out - just delete the image and use the last one you know worked.

          As I said, it's been a long day and it's kinda late so I hope that enormous missive made some sense. If not, DM or reply here in the thread - I'm certainly not the best at docker or git, but i do get all kinds of geeked at the possibilities they both offer; and obviously there are people here on the forums that are more than capable and happy to help out!

            Write a Reply...