Details
-
Skillsandroid, java, kotlin, js, ts
-
Github
Joined devRant on 12/12/2020
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Not sure if this has been posted before but GitHub has an official dark mode now!
And it's pretty beautiful too
(Especially check out how your own comments look on an issue!)5 -
Shoutout to YouTube for auto-translating "You suck at cooking ep 23" to "Sie saugen beim kochen episode 23".
Dankeschön16 -
Found an astronomy book from 1837 with instructions on how to build telescopes and drawings of the moon surface.7
-
What a fuckin dweeb.
Bro is not a synonym for douchebag, and you're not some moral god for not hiring one.31 -
My young brother just destroyed everyone at a speedcubing competition!
4x4, 3x3 one handed, 3x3 regular (the main event), skewb, pyraminix — all 1st places!8 -
Me: "Hmm. I should center this image."
img {
align-self: center;
}
CSS: "LOL, no. Intuitively, as a first logical guess at forgotten CSS syntax, that seems like what you ought to type. But this world makes no sense and my creator was a sadist. Here's what you actually need to do."
img {
clear: both;
display: block;
margin-left: auto;
margin-right: auto;
float: none;
}12 -
When a website enforces "overflow: hidden" on all content elements, so you hit them with the good ol'
for(let e of document.querySelectorAll("*")) {
e.style.overflow = "scroll";
}14 -
What the fuck is wrong with the designers? We have had meetings with the client, a proposal drawn up, a project spec written, budget agreed, witeframes drawn up exactly to spec. Designer involved in all stages for input and ideas. Now the designers have the wireframes, they are supposed to create based on these. No they make up what goes on the pages that bare no resemblance to the wireframes in terms of requirements. I am fucking fuming. I have sent the designs back with a note. Please provide designs based on the wireframes.17
-
Github 101 (many of these things pertain to other places, but Github is what I'll focus on)
- Even the best still get their shit closed - PRs, issues, whatever. It's a part of the process; learn from it and move on.
- Not every maintainer is nice. Not every maintainer wants X feature. Not every maintainer will give you the time of day. You will never change this, so don't take it personally.
- Asking questions is okay. The trackers aren't just for bug reports/feature requests/PRs. Some maintainers will point you toward StackOverflow but that's usually code for "I don't have time to help you", not "you did something wrong".
- If you open an issue (or ask a question) and it receives a response and then it's closed, don't be upset - that's just how that works. An open issue means something actionable can still happen. If your question has been answered or issue has been resolved, the issue being closed helps maintainers keep things un-cluttered. It's not a middle finger to the face.
- Further, on especially noisy or popular repositories, locking the issue might happen when it's closed. Again, while it might feel like it, it's not a middle finger. It just prevents certain types of wrongdoing from the less... courteous or common-sense-having users.
- Never assume anything about who you're talking to, ever. Even recently, I made this mistake when correcting someone about calling what I thought was "powerpc" just "power". I told them "hey, it's called powerpc by the way" and they (kindly) let me know it's "power" and why, and also that they're on the Power team. Needless to say, they had the authority in that situation. Some people aren't as nice, but the best way to avoid heated discussion is....
- ... don't assume malice. Often I've come across what I perceived to be a rude or pushy comment. Sometimes, it feels as though the person is demanding something. As a native English speaker, I naturally tried to read between the lines as English speakers love to tuck away hidden meanings and emotions into finely crafted sentences. However, in many cases, it turns out that the other person didn't speak English well enough at all and that the easiest and most accurate way for them to convey something was bluntly and directly in English (since, of course, that's the easiest way). Cultures differ, priorities differ, patience tolerances differ. We're all people after all - so don't assume someone is being mean or is trying to start a fight. Insinuating such might actually make things worse.
- Please, PLEASE, search issues first before you open a new one. Explaining why one of my packages will not be re-written as an ESM module is almost muscle memory at this point.
- If you put in the effort, so will I (as a maintainer). Oftentimes, when you're opening an issue on a repository, the owner hasn't looked at the code in a while. If you give them a lot of hints as to how to solve a problem or answer your question, you're going to make them super, duper happy. Provide stack traces, reproduction cases, links to the source code - even open a PR if you can. I can respond to issues and approve PRs from anywhere, but can't always investigate an issue on a computer as readily. This is especially true when filing bugs - if you don't help me solve it, it simply won't be solved.
- [warning: controversial] Emojis dillute your content. It's not often I see it, but sometimes I see someone use emojis every few words to "accent" the word before it. It's annoying, counterproductive, and makes you look like an idiot. It also makes me want to help you way less.
- Github's code search is awful. If you're really looking for something, clone (--depth=1) the repository into /tmp or something and [rip]grep it yourself. Believe me, it will save you time looking for things that clearly exist but don't show up in the search results (or is buried behind an ocean of test files).
- Thanking a maintainer goes a very long way in making connections, especially when you're interacting somewhat heavily with a repository. It almost never happens and having talked with several very famous OSSers about this in the past it really makes our week when it happens. If you ever feel as though you're being noisy or anxious about interacting with a repository, remember that ending your comment with a quick "btw thanks for a cool repo, it's really helpful" always sets things off on a Good Note.
- If you open an issue or a PR, don't close it if it doesn't receive attention. It's really annoying, causes ambiguity in licensing, and doesn't solve anything. It also makes you look overdramatic. OSS is by and large supported by peoples' free time. Life gets in the way a LOT, especially right now, so it's not unusual for an issue (or even a PR) to go untouched for a few weeks, months, or (in some cases) a year or so. If it's urgent, fork :)
I'll leave it at that. I hear about a lot of people too anxious to contribute or interact on Github, but it really isn't so bad!4 -
I JUST GOT AN OFFER. God has blessed me. I also found out I have cancer a couple weeks ago. What a confusing time this is lol.13