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
-
I started working in 2014. In one of my first jobs they gave me a virtual machine running Windows 2000.
I had a conversation that went more or less this way:
Me: «Why a so old OS?»
Boss: «Because we rely on an old library which has been compiled on Windows 2000»
Me: «What library is it? Who wrote it?»
Boss: «We wrote it. It belongs to our company.»
Me: «Can we try to port it on a more recent OS?»
Boss: «Oh, we've lost the source code a long time ago...»
Me: «...»8 -
So I had my exams recently and I thought I'd post some of the most hacky shit I've done there over here. One thing to keep in mind, I'm a backender so I always have to hack my way around frontend!
- Had a user level authentication library which fucked up for some reason so I literally made an array with all pages and user levels allowed so I pretty much had a hardcoded user level authentication feature/function. Hey, it worked!
- CSS. Gave every page a hight of 110 percent because that made sure that you couldn't see part of the white background under the 'background' picture. Used !important about everywhere but it worked :P.
- Completey forgot (stress, time pressure etc) to make the user ID's auto incremented. 'Fixed' that by randomly generating a user id and really hoping during every registration that that user ID did not exist in the database already. Was dirty as fuck but hey it worked!
- My 'client' insisted on using Windows server.Although I wouldn't even mind using it for once, I'd never worked with it before so that would have been fucked for me. Next to that fact, you could hear swearing from about everyone who had to use Windows server in that room, even the die hard windows users rather had linux servers. So, I just told a lot of stuff about security, stability etc and actually making half of all that shit up and my client was like 'good idea, let's go for linux server then!'. Saved myself there big time.
- CHMOD'd everything 777. It just worked that way and I was in too much time pressure to spend time on that!
- Had to use VMWare instead of VirtulBox which always fucks up for me and this time it did again. Windows 10 enjoyed corrupting the virtual network adapters after every reboot of my host so I had to re-create the whole adapter about 20 times again (and removing it again) in order to get it to work. Even the administrator had no fucking clue why that was happening.
- Used project_1.0.zip etc for version control :P.
Yup, fun times!6 -
For a project day we had to write a game of our choice in Java.
"You should make this game using the JSwing library and make each component a JComponent"
Later I learned you can simply use a Bitmap as a canvas.
NEVER. EVER. BASE. YOUR. GAME. ON. SWING.
It inefficient to the top of my taskmanager. I had to wrap everything with something like a virtual playground where I had to manage everything myself to not roast my cpu.
I had alot more fun debugging hundred lines of C code with print statements than writing that shit2 -
TL;DR: Stop using React for EVERYTHING. It's not the end-all solution to every application need.
My team is staffed about 50/50 with tenured devs, and junior devs who have never written a full application and don't understand the specific benefits of different libraries/framworks. As a result, most of these junior devs have jumped on the React train, and they're under the impression that React is the end-all answer to any possible application need. Doesn't matter what type of app is, what kind of data is going to be flowing through the app, data scale, etc. In their eyes, React is always the answer. Now, while I'm not a big fan of React myself, I will say that it does its job when its tasked with a data-heavy application that needs to be refreshed/re-rendered dynamically and frequently (like Facebook.) However, my main gripe is that some people insist on using it for EVERYTHING. They refuse to acknowledge that there can be better library/framework choices (Angular, Vue, or even straight jQuery,) and they refuse to learn any other frameworks. You can hit them with countless technical reasons as to why React isn't a good choice for a particular application, and they'll just spout off the same tidbits from the "ReactJS Makes My Nips Hard 101" handbook: "React is the future," "Component-based web architecture is the future," (I'm not arguing with that last one) "But...JSX bro.," "Facebook and Netflix use it, so that's how you know it's amazing." They'll use React for a simple app, and make it overly-complex, and take months to write something that should have taken them a week. For example, we have one dev who has never used any other frameworks/libraries apart from React, and he used React (via create-react-app) to write what is effectively a single form and a content widget inside of a bootstrap template. It took him 4 MONTHS to write this, and it still isn't fully functioning. The search functionality doesn't really work (in fact, it's just array filtering,) and wont return any results if you search for the first word in an entry. His repo is a mess, filled with a bunch of useless files that were bootstrap'd in via create-react-app. We've built apps like this in a week in the past using different libraries/frameworks, and he could have done the same if he didn't overly-complicate the project by insisting on using React. If your app is essentially a dynamic form, you don’t need a freaking virtual DOM.
This happens every time a big new framework hits the scene. New young developers get sucked into it, because it's the cool hip new framework (or in React's case, library.) and they use it for everything, even when it's not the best choice. It happened with Angular, Rails, and now it's happening with React.
React has its benefits, but please please please consider which library/framework is the best choice from a technical standpoint before immediately jumping on the React train because "Facebook uses it bro."2 -
Today I spent 9 hours trying to resolve an issue with .net core integration testing a project with soap services created using a third party soap library since .net core doesn't support soap anymore. And WCF is before my time.
The tests run in-process so that we can override services like the database, file storage, basically io settings but not code.
This morning I write the first test by creating a connected service reference to generate a service client. That way I don't need to worry about generating soap messages and keeping them in sync with the code.
I sent my first request and... Can't find endpoint.
3 hours later I learn via fiddler that a real request is being made. It's not using the virtual in-process server and http client, it's sending an actual network request that fiddler picks up, and of course that needs a real server accepting requests... Which I don't have.
So I start on MSDN. Please God help me. Nope. Nothing. Makes sense since soap is dead on .net core.
Now what? Nothing on the internet because above. Nothing in the third party soap library. Nothing. At this point I question of I have hit my wall as a developer.
Another 4 hours later I have reverse engineered the Microsoft code on GitHub and figured out that I am fucked. It's so hard to understand.
2 more hours later I have figured out a solution. It's pure filth..I hide it away in another tooling project and move all the filth to internal classes :D the equivalent of tidying your room as a kid by shoving it all under the bed. But fuck it.
My soap tests now use the correct http client with the virtual server. I am a magician.4 -
Oddly enough, i have simultaneously been less busy and more productive since working 66% remotely.
I find myself with more time that feels "wasted" or not busy, but my metrics show that I have more production, better results, and far nicer documentation. A bunch of us also sat down and did a bunch of coursework on really putting together a domain script library for one click onboarding of new servers or new client setups. We spun up a bunch of new virtual environments that literally solved headaches that had existed for years that never got dealt with because of too many other tickets.
Some of our web clients freaked out at us because the business is moving away from doing maintenance of legacy web work (small to midsize businesses). But it didn't matter. Rather than respond with a "make them happy," the response was "well, we will get rid of them as clients. We need to focus our energy on the essential service sectors we support."
Hell, we even got an automated test that has been broken apparently since 2018 to work again.
Granted, the incoming workload has slowed down. But it's still interesting to me to see that despite the slowdown, there isn't any concern; its still paying the bills and we are getting rid of technical debt everywhere. Tbh, this has really been a good reality check.1 -
I hate when programmers never want to go out their comfort zone. They should be relegated into a hell spinned inside a Virtualbox instance.
I have this *** angular setup. We want to try to keep the dev environment congruent between all the colleagues.
The decent programmer would use a node version manager, or try to keep up with everything. LOLNOPE THEY FUCKIN' SPUN A FRIGGIN' VAGRANT VIRTUAL MACHINE RUNNED WITH ADMIN PERMISSIONS which is slowing everyone down. A single "npm i" now requires half an hour.
I tried to use YARN that is faster and makes a mergeable lock, NOPE WE SHOULD KEEP USING THAT STUPID NPM INSTALL that is slow AF and sometimes messes up the versions.
I tried to make 'em use the peerDependencies correctly but LOLNOPE WE SHOULD RELY ONTO THE AUTOMATIC PEERDEP RESOLVER INSIDE NPM7, SO YOU DON'T KNOW IF YOUR VERY SAME LIBRARY IS INCLUDED OR NOT.
Thank god i'm changing job.
Top Tags
Weekly Rant
View