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
-
Recipe for a Great Programmer:
Ingredients:
-Books for a computer science curriculum from a top university
-Computer
-Headphones
-Internet
-Stress ball
-Pillow
-Lighter fluid
-Food
Directions:
1. Cover computer science books with lighter fluid
2. Light books on fire
3. Use flames to cook an energy-rich meal for the thousands of hours ahead
4. Pick an IDE
5. Choose a project beyond current capabilities. Good ways to push boundaries:
- Unfamiliar domain (e.g. large scale data processing, UI programming, high performance computing, games)
- Exotic programming language
- Larger in scope than any project before
6. Shut up about your IDE
7. Attempt to build
8. Stop procrastinating on Hacker News
9. Re-attempt to build
10. Squeeze stress ball and scream into pillow as necessary to keep sanity
When stuck:
- Paste stack traces into Google
- Find appropriate mailing list to get guidance
- Realize that real learning happens when you are stuck, uncomfortable, and/or frustrated
- Seek out books, classes, or other resources AFTER you have a good understanding of your deficiencies
11. Repeat #4 to #10 for at least 10 years
12. Results guaranteed! (to the same extent static types guarantee bug-free programs)
source: nathanmarz.com4 -
Some days I feel like I work in a different universe.
Last night our alerting system sent out a dept. wide email regarding a high number of errors coming from the web site.
Email shows the number of errors and a summary of the error messages.
Ex. 60 errors
59 Object reference not set to an instance of an object
1 The remote server returned an unexpected response: (413) Request Entity Too Large
Web team responds to the email..
"Order processing team's service is returning a 413 error. I'll fill out a corrective action ticket in the morning to address that error in their service. "
Those tickets are taken pretty seriously by upper mgmt, so I thought someone on the order processing team would point out the 1 error vs. 59 (coming from the web team's code).
Two hours go by, nobody responds, so I decide to jump into something that was none of my business.
"Am I missing something? Can everyone see the 59 null reference exceptions? The 413 exception only occurred once. It was the null reference exceptions that triggered the alert. Looking back at the logs, the site has been bleeding null reference exceptions for hours. Not enough for an alert, but there appears to be a bug that needs to be looked into."
After a dept. managers meeting this morning:
MyBoss: "Whoa..you kicked the hornets nest with your response last night."
Me: "Good. What happened?"
<Dan dept VP, Jake web dept mgr>
MyBoss: "Dan asked Jake if they were going to fix the null reference exceptions and Jake got pissed. Said the null reference errors were caused by the 413 error."
Me: "How does he know that? They don't log any stack traces. I don't think those two systems don't even talk to one another."
<boss laughs>
MyBoss:"That's what Dan asked!..oh..then Jake started in on the alert thresholds were too low, and we need to look into fixing your alerting code."
Me: "What!? Good Lord, tell me you chimed in."
MyBoss: "Didn't have to. Dan starting laughing and said there better be a ticket submitted on their service within the next hour. Then Jake walked out of the meeting. Oh boy, he was pissed."
Me: "I don't understand how they operate over there. It's a different universe.
MyBoss: "Since the alert was for their system, nobody looked at the details. I know I didn't. If you didn't respond pointing out the real problem, they would have passed the buck to the other team and wasted hours chasing a non-existent problem. Now they have to take resources away from their main project and answer to the VP for the delay. I'm sure they are prefixing your name right now with 'that asshole'"
Me: "Not the first, won't be the last."2 -
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 -
Oh boy some mutex deadlocks inside the 16 year old, unmaintained, company application framework.
Time to look at the stack traces of 24 different threads and try and guess which one fucks it up
(Send help)
5 -
# PROD
* 10 app instances running
* 1 instance starts burning up 100% cpu
* we ask for a Thread Dump (stack traces)
* we get a TD taken after they manually restarted the instance
* they: "Please investigate. We need this fixed ASAP"
* .....
EVERY FUCKING TIME!!! Not once in recent years have they managed to take a TD correctly. What kind of a retarded monkey do you have to be for this to not sink in for YEARS!
Who tf put those idiot monkeys there in the first place...8 -
My company decided to reinvent the wheel by writing its own queue system instead of using the existing message queue service.
And it uses plain PHP with exec() to run the workers.
Where do we store the job? We use mongoDB which is already used in our existing projects. We can query the collection/table each time the queue service start, execute the jobs, and let it exit if there's no job anymore. Don't worry, systemd will start the queue service again once it exits.
How to monitor the workers? Yep, we use ps and grep to check if the worker's PID still exists in the OS.
What about error stack traces? Nice question, we redirect the stdout and stderr when exec()-ing into a file.
What about timeout? We don't need it, let's just assume no one is going to write while(true).
It works flawlessly! /s8 -
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 -
If you do `log.error("blah: " + e.getMessage())` rather than `log.error("blah: ", e)` then I will personally hunt you down, come to your house, and give you a bloody good talking to as to why stack traces are free, useful debugging tools, and you've just wasted my time by omitting it.4
-
I gleefully await the day that languages are so high level that stack traces can be generated simply for unintended behavior, not just errors2
-
Today I spent half an hour trying to figure out why my IDE stops on an exception that is very obviously caught.
I left a breakpoint there because the stack traces behaved weirdly.7 -
Dev Mantra
I do not write code with my keyboard. He who writes code with his keyboard has forgotten the days of the punch cards. I write code with mind.
I do not write non descriptive variables. He who writes non descriptive variables has forgotten the days of the punch cards. I write self descriptive code.
I do not debug by brute force. He who debugs by brute force has forgotten has forgotten the days of the punch cards. I debug with breakpoints and stack traces.1 -
I think work is finally getting to me, I had crazy dreams last night full of stack traces. Woke in a cold sweat...
-
I wonder when the transition from being scared of stack traces to loving them came. who needs a debugger when you can substitute any suspicious line/breakpoint with a runtime error.
-
What is worse code that works in debug but not in production or code that doesn't work in debug but does work in production. Both without usable stack traces.
Currently batteling both.... -
Ain no missing semicolon like one in postcss w/gulp. HOW HARD IS IT TO SPECIFY WHERE THE UNEXPECTED SPACE IS?2
-
nothing new, just another rant about php...
php, PHP, Php, whatever is written, wherever is piled, I hate this thing, in every stack.
stuff that works only according how php itself is compiled, globals superglobals and turbo-globals everywhere, == is not transitive, comparisons are non-deterministic, ?: is freaking left associative, utility functions that returns sometimes -1, sometimes null, sometimes are void, each with different style of usage and naming, lowercase/under_score/camelCase/PascalCase, numbers are 32bit on 32bit cpus and 64bit on 64bit cpus, a ton of silent failing stuff that doesn't warn you, references are actually aliases, nothing has a determined type except references, abuse of mega-global static vars and funcs, you can cast to int in a language where int doesn't even exists, 25236 ways to import/require/include for every different subcase, @ operator, :: parsed to T_PAAMAYIM_NEKUDOTAYIM for no reason in stack traces, you don't know who can throw stuff, fatal errors are sometimes catchable according to nobody knows, closed-over vars are passed as functions unless you use &, functions calls that don't match args signature don't fail, classes are not object and you can refer them only by string name, builtin underlying types cannot be wrapped, subclasses can't override parents' private methods, no overload for equality or ordering, -1 is a valid index for array and doesn't fail, funcs are not data nor objects when clojures instead are objects, there's no way to distinguish between a random string and a function 'reference', php.ini, documentation with comments and flame wars on the side, becomes case sensitive/insensitive according to the filesystem when line break instead is determined according to php.ini, it's freaking sloooooow...
enough. i'm tired of this crap.
it's almost weekend! 🍻1 -
Sometimes clojure stack traces are so damn unhelpful that I wish they weren't there at all....
It's a beautiful language though.. -
We receive by mail the build report launched by Jenkins so I get It on my smartphone. Bad idea, I make nightmare of "BUILD FAILURE" and endless stack traces..
Top Tags
Weekly Rant
View