Professionally similar; 1024x768 here (might have had an 800x600 laptop or thereabouts).
But when people today complain about how how anything less than 4k x 60fps on some game is unplayable, I remember playing Doom in 320x200 on a 14" monitor, and still having to shrink the screen into an even tinier window, so I could get 10fps.
Could be a “You can’t let John down now, we’re old pals, and a few people expect the site to work by the end of the week. He just needs a site like Facebook, but for gardeners”
Even just an afternoon of CSS would mean 2-4 hours, plus setting everything up, plus talking to the client, revisions, etc. You’ll quickly end up with 10h overall, even if the actual task is rather small. And that’s the optimistic case.
So you’ll end up with maybe 50€/h , probably more like 30. Not terrible, but that’s the optimistic case.
Currently migrating a massive monolithic Java application to microservices… The circle of life continues.
Want to just swap jobs in ~5 years to keep the cycle going? You can migrate this project back to a Java monolith and I’ll migrate your monolith back to micros :D
Honestly this just sounds like periodically refactoring everything to remove cruft can be a good thing. Also, it helps you understand how the existing code works if you change it and not break everything.
Once you understand that everything is similar to a tag, like branch names are basically tags that move forward with each commit, that HEAD is a tag that points to your current commit location in history, and what command moves what kind of tag, it becomes easier to understand.
Suddenly having a detached HEAD isn’t as scary as you might think. You get a better understanding of fast forward merges vs regular 3-way merge.
Also understanding that each commit is unique and will always remain in the history and can be recovered using special commands. Nothing is lost in git, unless you delete the .git sub-directory.
For folks unaware, the technical git term, here, is a ‘ref’. Everything that points to a commit is a ref, whether it’s HEAD, the tip of a branch, or a tag. If the git manpage mentions a ‘ref’ that’s what it’s talking about.
Oh fuck. I didn’t think of that. Than you for reminding me.
Edit: Ah but you can only run this in your local repo. If you happen to push anything, you might not be able to run it on the remote. Many DevOps platforms won’t allow it.
Oh yeah, and anybody else who had fetched in those commits may still have them as well. It’s hard for something to be gone-gone, but it may be annoyingly-hard-to-recover-gone.
I just remembered the dumbest argument I’ve ever suffered about this - someone insisting the “length” of one tab changed, depending on what’s before it. As in, is it eight spaces, or seven? Or six! It only goes up to eight spaces! No. It goes one stop. The same way a newline goes one line, and cannot by measured by how many times you’d slap the spacebar to get text to wrap around to the next line.
They mean if you insert a tab after some other text.
Word processors and desktop publishing apps tend to have tab stops (sometimes visible in a ruler at the top of the page) and pressing tab goes to the next tab stop. They’re about an inch apart (assuming letter or A4 paper) by default, and you can usually also add your own tab stops. For example, you might have text like this:
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.