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
-
writing library code is hard.
there are sooo many details that go into writing good libraries:
designing intuitive and powerful apis
deciding good api option defaults, disallowing or warning for illegal operations
knowing when to throw, knowing when to warn/log
handling edge cases
having good code coverage with tests that doesn't suck shit, while ensuring thry don't take a hundred years to run
making the code easy to read, to maintain, robust
and also not vulnerable, which is probably the most overlooked quality.
"too many classes, too little classes"
the functions do too much it's hard to follow them
or the functions are so well abstracted, that every function has 1 line of code, resulting in code that is even harder to understand or debug (have fun drowning in those immense stack traces)
don't forget to be disciplined about the documentation.
most of these things are
deeply affected by the ecosystem, the tools of the language you're writing this in:
like 5 years ago I hated coding in nodejs, because I didn't know about linters, and now we have tools like eslint or babel, so it's more passable now
but now dealing with webpack/babel configs and plugins can literally obliterate your asshole.
some languages don't even have a stable line by line debugger (hard pass for me)
then there's also the several phases of the project:
you first conceive the idea, the api, and try to implement it, write some md's of usage examples.
as you do that, you iterate on the api, you notice that it could better, so you redesign it. once, twice, thrice.
so at that point you're spending days, weeks on this side project, and your boss is like "what the fuck are you doing right now?"
then, you reach fuckinnnnng 0.1.0, with a "frozen" api, put it on github with a shitton of badges like the badge whore you are.
then you drop it on forums, and slack communities and irc, and what do you get?
half of the community wants to ban you for doing self promotion
the other half thinks either
a) your library api is shitty
b) has no real need for it
c) "why reinvent the wheel bruh"
that's one scenario,
the other scenario is the project starts to get traction.
people start to star it and shit.
but now you have one peoblem you didn't have before: humans.
all sorts of shit:
people treating you like shit as if they were premium users.
people posting majestically written issues with titles like "people help, me no work, here" with bodies like "HAAAAAAAAAALP".
and if you have the blessing to work in the current js ecosystem, issues like "this doesn't work with esm, unpkg, cdnjs, babel, webpack, parcel, buble, A BROWSER".
with some occasional lunatic complaining about IE 4 having a very weird, obscure bug.
not the best prospect either.3 -
I was depressed doing a course I hated.
3 years in and I switched to Computer Science.
Best decision ever!3 -
College student here.
What are the most important skills/assets one should bring to the workplace? As a developer and a colleague.
5 -
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 think I can learn English here.
HAHAHA
I can also learn professional knowledge.
**I am a Korean.**
And...
Succeed!
Android studio AVD powered pictures
4 -
I only just started learning Js. And it's going smoothly. In two weeks, I should have gone past the Beginner's level. Then what next?7
-
Just feel like going to a raised platform over my town and scream, "AHHHHHHHhhhhhhhhhhhhhhhhhh....!!!"
-
Just an advice:
Keep in mind that you can now have ES modules in nodejs with the esm package. And it's a zero config install.
For those that don't know, in js ES modules is the import/export syntax and is a huge upgrade from cjs (the require syntax) because you find out "pre runtime" when a specific import is non existent.1 -
Definitely Android 8.0 is neat.
And it's faster.
I think Android has developed a lot.
Isn't that right? -
How long does it take to start writing codes without having to do “too much” looking up of some context?
I’m quite at the intermediate level and I fear I do a lot of cramming(and pouring) than actual coding.
I want to code all on my own, or at least tons of lines before having to check something up.
How do you guys do it? How do I become ‘pro’?6 -
What are you currently working on? You can be as vague as possible and let others try to figure it out.
I’m currently working on something to make pelican based blogs look a bit decent.7 -
NodeJS’s transition from CommonJS is still a bit of a mess. Jest is the most used unit testing tool, but you need to fondle its balls to get it to work with ESM. Jasmine is the only major testing framework to support ESM out of the box. Luckily, jasmine is actually really nice.4
-
(I'm not completely sure of what I'm saying here, so don't take this too seriously)
Settling on a language to write the api for ranterix is hard.
I'm finding a lot of things about elixir to be insanely good for a stable api.
But I'm having a lot of gripes with the most important elixir web framework, phoenix.
Take a look at this piece of code from the phoenix docs:
defmodule Hello.Repo.Migrations.CreateUsers do
use Ecto.Migration
def change do
create table(:users) do
add :name, :string
add :email, :string add :bio, :string
add :number_of_pets, :integer
timestamps()
end
end
end
Jesus christ, I hate this shit.
Wtf are create, add and timestamps. Add is somehow valid inside the create, how the fuck is that considered good code? What happens if you call timestamps twice? It's all obscure "trust me, it works" code.
It appears to be written by a child.
js may have a million problems. But one thing I like about CJS (require) or ESM (import) is that there's nothing unexplained. You know where the fuck most things come from.
You default export an eatShit() function on one file and import it from another, and what do you get?
The goddamn actual eatShit function.
require is a function the same way toString is a function and it returns whatever the fuck you had exported in the target file.
Meanwhile some dynamic langs are like "oh, I'll just export only some lang construct that i expect you to specify and put that shit in fucking global of the importing file".
Js is about the fucking freedom. It won't decide for you what things will files export, you can export whatever the fuck you want, strings, functions, classes, objects or even nothing at all, thanks to module.exports object or export statement.
And in js, you can spy on anything external, for example with (...args) => debugger; fnToSpyOn(...args)
You can spoof console.log this way to see what the fuck is calling it (note: monkey patching for debugging = GOOD, for actual programming = DOGSHIT)
To be fair though, that is possible because of being a dynamic lang and elixir is kind of a hybrid typed lang, fair enough.
But here's where i drop the shit.
Phoenix takes it one step further by following the braindead ruby style of code and pretty DSLs.
I fucking hate DSLs, I fucking hate abstraction addiction.
Get this, we're not writing fucking poetry here. We're writing programs for machines for them to execute.
Machines are not humans with emotions or creativity, nor feel.
We need some level of abstraction to save time understanding source code, sure.
But there has to be a balance. Languages can be ergonomic for humans, but they also need to be ergonomic for algorithms and machines.
Some of the people that write "beautiful" "zen" code are the folks that think that everyone who doesn't push the pretty code agenda is a code elitist that doesn't want "normal" people to get into programming.
Programming is hard, man, there's no fucking way around it.
Sometimes operating system or even hardware details bleed into code.
DSLs are one easy way to make code really really easy to understand, but also make it really fucking hard to debug or to lose "programming meaning".7 -
Peoples saying that JQuery dies after Document.querySelector is gone, but, write the functions like `slideUp` or anything that manipulates styles too, is very non-productive.
Do you know another lib (small) that makes these functions created by JQuery?15 -
How is building Typescript libraries for esm, cjs and dts with Rollup still breaking in 2023? I had a setup last year that worked perfectly fine, I copied it over to a new library and now tslib is being imported by relative path from node_modules? Why would that ever work?5
Top Tags
Weekly Rant
View