95
Replies
When setup properly within an IDE, it is so easy to maintain a backup/version control. Have a look at the following where 'A' = added and 'M' = modified. Depending on how often you want a backup or create a version, you could leave the commit go for a week or a month. Committing the files shown below is very fast and it only requires the push of a button.
BenPleysier wrote
When setup properly within an IDE, it is so easy to maintain a backup/version control. Have a look at the following where 'A' = added and 'M' = modified. Depending on how often you want a backup or create a version, you could leave the commit go for a week or a month. Committing the files shown below is very fast and it only requires the push of a button.
We know that, every editor under the sun, well as far back as a few years has a Git implementation. I know you're excited because Wappler has just got one, last week. We are discusing the relevance of who would benefit from using Git not how GIt works or what a git panel looks like.
Please tell me the Wappler implementation is a bit better than what you show, it must document the time/day the commit was made and to what file the comment refers, rather than just the commit message?
Git supplies you with an incremental backup. Surely that is what you do as a professional web designer. And as I said, it requires the push of a button.
And for your information, I was using Git way before Wappler was thought of.
BenPleysier wrote
Git supplies you with an incremental backup. Surely that is what you do as a professional web designer. And as I said, it requires the push of a button.
And for your information, I as using Git way before Wappler was thought of.
So I assume all those 'comments' refer to the open file?
Yes, I make back-ups, its called time-machine on a Mac. It backs up frequently throught-out the day and I can roll back to a point in time, including many months back, which is not usually necessary. Of course I dont get to write the message but I really have no need as the changes are mostly set in stone. I always just duplicate the file before I make any changes so I can roll back to that if the client doesn't approve as an extra measure. Git only takes you back to a certain commit point so you still might lose some chnage you actually require unless as I say you commit every single change.
osgood_ a écrit
In your mind, only. Version control is no more than a glorified back-up system which is useless unless you make frequent commits. A rather bloated approach for most individual developers, in most circumstances....but you cant tell em that use such solutions. It rather spoils their perception.
quickly... as you still confuse both...
back up , copy each single byte of files and folders
version control, copy just the difference in between... 
https://forums.adobe.com/people/B+i+r+n+o+u wrote
osgood_ a écrit
In your mind, only. Version control is no more than a glorified back-up system which is useless unless you make frequent commits. A rather bloated approach for most individual developers, in most circumstances....but you cant tell em that use such solutions. It rather spoils their perception.
quickly... as you still confuse both...
back up , copy each single byte of files and folders
version control, copy just the difference in between...
Well thanks for the clarification....how does that change the outcome. It doesnt.
All this is coming from a guy that doesnt know if they should be using Bootstrap 3 or Bootstrap 4 for a new project....can you take it seriously
pziecina wrote
Yes it is true that BS4s css would have to be modified to support IE10 or other very old browsers and mobile devices flexbox implementations, but that should be easy to do.
Except for the lack of knowledge and the reluctance to use flexbox by many, (especially by Dw users) flexbox has been usable for over 8 years.
Note: It is true that flexbox was only fully usable 6 years ago, but that was because of firefox.
The reluctance for many to use flexbox was mainly because of their dependency on Bootstrap v3. Bootstrap is always, at some point in its life-cycle 2 years + out of date. Any decent webdeveloper was using Flexbox more than 2 years before those using Bootstrap, quite a lot according to the Bootstrap usage figures, go figure. Lambs to the slaugther comes to mind.
Many decent web developers are now gravitating towards grid for some aspects of their website construction but not those that use Bootstrap 4. No workflow is stable until Bootstrap officially says it is, for them. Bye Bye.
Obviously I'm very 'angry' according to the Frenchman
osgood_ wrote
Obviously I'm very 'angry' according to the Frenchman
Actually you do the term 'whingeing pom' proud. 
BenPleysier wrote
osgood_ wrote
Obviously I'm very 'angry' according to the Frenchman
Actually you do the term 'whingeing pom' proud.
I take that as a compliment, thanks, not enough of us here in the UK whinge about issues, the majority take it lying down, unlike the rest of the world who whinge a great deal, especially the aussie.
pziecina wrote
I don't think bootstrap is the problem.
I obviously disagree. It's a problem, much like any other 'short-cut', not all but most developers won't bother to learn the basics. I jumped straight onto jQuery because I could not be bothered to learn some basic javascript. Well I've been brushing up on my javascript recently and can now see I've been a total dickhead and jQuery has/did somewhat blinker my approach (I had a one-track mind as a result of not really understanding how a basic web-development technology worked).
I'm not saying jQuery is bad, I still use it to some extent, of course, but in my opinion you must investigate the origins of these 'short-cuts' to be able to provide yourself with a more rounded view and approach. That's why I oppose click and drag, basically anything that by-passes the incredibly important stage of learning what you are actually doing and making some attempt to understand the environment you choose to work in.
Any text editor can be used if you have the right skills and knowledge. In my opinion, a developer should not make themselves dependent on any particular bit of editing software, to the point if its removed from them they simply cannot produce their work. After all, its only code, and much of what is needed to produce the average website is quite within the remit of anyone who is a serious developer to learn over time, without the need for any supporting crutches.
Even if such advance technologies are introduced into a web-editor you have the issue of if they have been implemented to the best of what is possible. If you remember the DW server behaviours the implementation was bloated and crap but did the job, but you only knew they were crap as a result of going and learning how to implement the workflow yourself in a more professional capacity. Once again I failed myslef to acknowledge that, until I was forced to go and learn, only as a result of the SBs being scrapped.
Recently I was watching a reasonably respected developer on youtube (75000+ followers). He was teaching lazy load of images. The javascript workflow used was really rather obtuse and unnecessary, using 3 times the amount of code that was required.........so regardless of where you look its hugley difficult to seperate the wheat from the chaff.
The underlying problem with web-development is there are just too many ways and workflow, all which produce the same result and everyone thinks their way is the best
https://forums.adobe.com/people/B+i+r+n+o+u wrote
osgood_ a écrit
I guess the question should be 'How frequently should you commit your changes and document those changes' to get any benefit. Like I said I could spend an hour or more troubleshooting a page. If I only commit after each hour I really wont have a clue all that I've changed in that hour.
in fact everyone is free to adopt the rules that suit them best.
for my part, I like to make a commit as soon as I get a stable point of the evolution towards a functionality defined by the specifications.
let's imagine that in version 1.0 the data is retrieved through a full page reload (PHP) and that in order to optimize the fluidity of the user experience, we wanted to replace this with local and punctual loads (JS AJAX)
there may be a branch to create called Passage to AJAX. Once the structure has been adapted, a first commit, then as soon as the engines will reload the data a second one, etc...
if in the meantime the client wishes to add an autocompletion functionality (become accessible through the AJAX approach), a second branch is created to separate the two modifications in order to preserve the general and global stability...
so in the second branch we only focus on the adaptation of the main for the autocompletion aspect.
this is beautifully orchestrated with GIT and commits made at each intermediate level.
as soon as the core scripts are stable we can merge each brancs together or with the master app.... so easly...
if we have to manage various projects at the same time... what a mess with simple backups
but as I said above... each one is free to organise its way as one care...
So... now it's time for the pool... and a great aperitif.
I should expect an overly complex answer from someone that uses an overly complex workflow
As for simple back-ups I guess that comes down to if you're organised or not and organisation obviously doesnt appear to be one of your strong points so you'd rather hand that off to 'something' else. Each to his/her own I guess.
AdChoices