@AvatarOfKaine Yes, OBS Studio.

@hjk101 Ah no worries!

Naming it in the same sentence wasn't even intentional.

@hjk101 Sure, but that is what everyone is just going to say here.

Many hacking /modding efforts for hackable devices can get you into it. As does a simple arduino, but it might be too easy and not motivate you or require to dig deep.

With arduino, you could start with Arduino IDE and later recode a project with only Atmel Libs (e.g. with Atmel Studio or plain makefiles). Maybe even progress to writing parts in assembly.

Also C on your pc can also expose you to many low level memory management things.

Or follow tutorials for sw/games for emulators like "Writing a game for a N64" or similar.

There may be some NGOs that can do the communication on your behalf. They avoid rookie mistakes and also keep you anonymous.

In germany for example, you can ask the ccc to do it.

Btw, gotta ask your PM: Does he want a excel compatible calendar or a correct one?

(Don't even they will surely never notice)

Using a well developed time/chrono/georgian calendar js lib is crucial. There are so many weird things with dates, timezones and such that keeping track of that is almost impossible. Especially on a whim.

If you don't believe me, look up talks about timezones and date libs on yt.

One example: https://youtube.com/watch/...

@iiii For staging selective hunks I do indeed prefer a ui. Since I work mostly with VSCode, I usually select what to commit there and either do the commit with the UI or the console. It's both the same speed at that point.

Sublime merge looks nice tbh. Will give that a look.

I agree that "just using a terminal" doesn't make a new user faster. Most people saying that have an optimized workflow, experience or a lot of scripts to back up that claim.

But new users will not have those, so the first very inefficient use will not back that claim up and may make it seem like a lie.

@iiii It heavily depends on how you use it.

I for example, use a drop down terminal and can get most got commands really fast with zsh's history based arrow feature and shorthand aliases.

If you however first need to find your terminal "UI" window, focus it, and then type out a full git command by hand (most terminal newbies don't use tab) a button 1 or 2 meues deep sure is faster.

A UI is nice for learning a new tech and discovering nifty features. Or just exploring something fast.

A terminal is great once you know the basics and want to be faster, more productive and maybe even automate stuff.

Problem is, that certain features are harder to find/use first time in a terminal and UI containing all the possibilities of the terminal are super rare if not impossible or unusable.

@melezorus34 At least GitLab does afaik. And you can also integrate PlantUML.

So once I'm gonna update my 2 year old frontend... how many days will it take exactly?

Looking forward to relearning it. Or not, depending on whether it gets any priority. Current state works, I'm not aware of any xss and all the dependencies are vendored (poor git).

Fixing bugs or maintenance is often a good source to get started doing pull requests.

Libs: Do niche features still work? Did you need to figure out the hard way how a function works and think it should be documented better? Could dependencies be updated? Add guides and/or examples.

Selfhostable sw: Does the dockersetup still work. Are instructions incorrect or assume wrong/outdated packages/distros?

As with all of this, most projects are small ones and people have a lot of things to do. So keep in mind they might take many days to reply, have to get into the software logic again or straight don't notice the pr if not very active on gh anymore.

So please:
- Check the activity on the repo and their profile to see whether they may take longer to respond.
- Include a detailed explanation of your changes and why.
- Do the little things like polishing (e.g.. create the pr as a draft first) so they don't need to propose/do a lot of fixes.
- Always be nice, no matter what is wrong.

Some things are really weird tbh or hard to grasp (like that enums are more what unions are in most modern languages).

But aside from that, I regard it as a unicorn language with a ridicules learning but a similar ridicules reward for surviving it.

As far as I understand it, the language took some good things from ancient languages (fortran, haskell, ...) as well as some "university languages". That combined with the borrow checker makes the language pretty hard and unfamiliar initially.

Btw, someone made a talk, where he took bad parts from many languages and made up a new worse one. Funnily enough he didn't take anything from rust and even praised it: https://youtube.com/watch/...

Edit: Little tip. Use rust-analyzer over the offical rust extension (which usually is outdated rls). For example in vscode. Not sure if intellij uses the r-a by default.

Compression algos

The best teacher are usually sideprojects that get me into rabbit holes where I cour the internet, try a lot of stuff out and get to sleep at 6am.

Had this yesterday for example. Now know how to easily figure out whether a host/ip is IPv4 or IPv6, can filter for a specific one and learned more regarding DNS SRV entries.

Also may be checking how to create a otb (opentype bitmap font) for something something private web toy.

Welcome to devRant!

Personally found it a blessing when they added their "Actions". Sure they look weird, but they have huge advantages:

- Have them compile everything for you (hugely helpful when testing someone else's PR)
- Have them do various style / syntax checks. So you don't need to complain in a PR, the CI does it for you.

For university projects I also usually use GitLab CI to just compile each push, so other members are discouraged from pushing partial updates that don't compile anymore.

Sure I'm still sceptical of M$ still. But I don't think GitHub on their own could've basically given you free CI compute power + hosting the results in that amount for free.

@annapurna Managers POV:

Meetings:
- Can hear myself talk
- Can spend more working hours on this
- Devs take longer so I can make even more meetings asking them on their progress for same features
- I seem way more productive than the devs

Mails, Chat, or anything non voice:
- None of the above, so clearly inferiour

Just give him a typewriter. Given infinite time even a monkey can find the 0's and 1's to fix that.

Do they have a choice?

If they don't want to, people could always "fork it".

Oh, I do rest. Just not the relaxing kind. ;)

If you didn't talk about the second thing and the fact that she does your social media, I would have guessed that she didn't know her co-workers watched her profile and just wanted to announce it to her more private/casual bubble.

I'm unsure about the vacation thing. Maybe she skrewed up and somehow "got sold" on taking this vacation due to some discount, ad, recommendation or relationship opportunity. If that isn't the case you may need to make clear that she can't "ask you" as in bullying you say "yes" because it would severely incovienence her. Maybe just warn her, that you won't let this fly next time or outright deny it, if she doesn't have a damn good reason or didn't have vacation in ages.

@donuts I think they just present one JPG as THE original. And you get the proof that you own that file. I think it's meant to be similar to real paintings in museums. Sure there are copies if it, but you will own "the official one".

Still just useless bragging rights, imo. Anyone can also download that image, though.

Just did a quick check with: openssl s_client -showcerts -connect localhost:443

I seem to have the newer intermediate certificate, so I shouldn't get affected. Thanks for the heads up though!

You basically get bragging rights on owning the hash of the file (or the file if you want to see it that way).

6. You'll have to do it on Windows

Also git tools do all changes to your git files. If a pull for example fails, use your IDE's gui to resolve the conflicts.

Tools like gitkraken or git tortoise also help a lot. Git also includes a graphical tool btw: kgit. It's great for a graphical more detailed view of git diff and log.

The merge issue can also be left to your git server and project maintainers if you make changes on new branches and turn those changes into merge/pull requests. But that's up to how your project is structured at work I guess.

It is generally the easiest to pull right before starting to work. I personally tend to forget this a lot though. Doing certain good practices in projects also makes using git easier. For example:
- SRP: Try to prevent huge files and split responsibilities into certain files. That way you can reduce the chance of merge/rebase conflicts.
- Turning one big projects with several programs into several separate git repos. Reduces your chance to be behind in general and you know all commits are for a certain project/program.

Some other pieces of advice I learned:
- Look at "rebase vs merge". Rebasing is cool in that it basicially puts your commits behind what you pulled/rebased against. It also doesn't create an extra merge commit.
- Only push once you're done/satisfied with you changes and tested the software. That way you can use "git rebase -i" to "fixup" fixes into the appropriate commit which reduces bugfix commits. This has no consequences as long as you only change local commits.