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
Search - "v-model"
-
So I was hired about 4 months or so in this companty, we will name it 'Derp & Co.'
The first task they want me to do was to 'clean' an android app that, for what they told me:
- Previous dev fired. said that tasks have been done but totally a lie.
- Took a fully week of 2 fellows coworkers to 'undo' the mess.
- And for the last but not least, zero documentation, like ZERO.
So, I clone the repo, install android studio, blah blah blah, get hands to the pile of code and jesus...
- The whole app was working with a gargantuan json, there was no use of POJOs at all. Objects are for normies.
- A masive copy/paste code, like 'I will need this here, crtl-c... ctrl-v, DONE!'
- Threads are free, isn't it? let's just put a thread whenever I desire to make an HTTP request and not reuse code at all.
So... with this on mind, my first task is to make proper objects:
- Coworker: 'Sorry dev, we don't have documentation for this, you must debug the code to se what the server will send to you'.
- Me: 'Real?'
Shit... ok. So I first try to figure out how the hell is made my gargantuan json. A month was entirely lost to unravel this data and implement Objects, improve their code, reuse code, etc. but at the very end:
- coworker: 'Good job dev, when the POJOs are done, we can focus on the next task, whe have to define a new DATA MODEL because the one we are using now is not good at all'.
*note: the app is on production and working with all the previous 'features' and today it still on use on some enviroments.
- Me: 'Wait... this is a joke, now you want to define new data models? This should have been done in first place!' <WTF face>
- Coworker: 'I don't think so dev, Mr. boss have this list with things to improve on the app an this is the order of do the tasks'.
Mr. boss is on vacations, two days after he came back:
- Mr boss: 'Coworker said that you have been working with POJOs, is that right?'
- Me: 'Yes'
- Mr boss: 'Why? Did not see the need of a new data model?'
- Me: 'I told that to him, but he insist on "the order" of the list.
- Mr. boss <facepalm>
This is one of the few tales i have from 'Derp & Co.'
PS: Sorry if i made a mistake on writing, english is not my first language and maybe I have done some mistakes.7 -
Homework:
Create a fact file and orbital molecule to the substance I've adviced you.
Me:
- 1min ctrl+c ctrl+v of facts/description
- 2h making a 3D model in blender lol
Conclusion:
I like wasting time8 -
Fuck software assurance.
Fuck functional specifications, fuck software requirements, fuck V-model bullshit documentation, fuck integration test plans.
Fuck trying to shoehorn waterfall requirements into what clearly was an interative development.
Fuck me for being a single dev handling all this bullshit by myself.3 -
So recently I had an argument with gamers on memory required in a graphics card. The guy suggested 8GB model of.. idk I forgot the model of GPU already, some Nvidia crap.
I argued on that, well why does memory size matter so much? I know that it takes bandwidth to generate and store a frame, and I know how much size and bandwidth that is. It's a fairly simple calculation - you take your horizontal and vertical resolution (e.g. 2560x1080 which I'll go with for the rest of the rant) times the amount of subpixels (so red, green and blue) times the amount of bit depth (i.e. the amount of values you can set the subpixel/color brightness to, usually 8 bits i.e. 0-255).
The calculation would thus look like this.
2560*1080*3*8 = the resulting size in bits. You can omit the last 8 to get the size in bytes, but only for an 8-bit display.
The resulting number you get is exactly 8100 KiB or roughly 8MB to store a frame. There is no more to storing a frame than that. Your GPU renders the frame (might need some memory for that but not 1000x the amount of the frame itself, that's ridiculous), stores it into a memory area known as a framebuffer, for the display to eventually actually take it to put it on the screen.
Assuming that the refresh rate for the display is 60Hz, and that you didn't overbuild your graphics card to display a bazillion lost frames for that, you need to display 60 frames a second at 8MB each. Now that is significant. You need 8x60MB/s for that, which is 480MB/s. For higher framerate (that's hopefully coupled with a display capable of driving that) you need higher bandwidth, and for higher resolution and/or higher bit depth, you'd need more memory to fit your frame. But it's not a lot, certainly not 8GB of video memory.
Question time for gamers: suppose you run your fancy game from an iGPU in a laptop or whatever, with 8GB of memory in that system you're resorting to running off the filthy iGPU from. Are you actually using all that shared general-purpose RAM for frames and "there's more to it" juicy game data? Where does the rest of the operating system's memory fit in such a case? Ahhh.. yeah it doesn't. The iGPU magically doesn't use all that 8GB memory you've just told me that the dGPU totally needs.
I compared it to displaying regular frames, yes. After all that's what a game mostly is, a lot of potentially rapidly changing frames. I took the entire bandwidth and size of any unique frame into account, whereas the display of regular system tasks *could* potentially get away with less, since most of the frame is unchanging most of the time. I did not make that assumption. And rapidly changing frames is also why the bitrate on e.g. screen recordings matters so much. Lower bitrate means that you will be compromising quality in rapidly changing scenes. I've been bit by that before. For those cases it's better to have a huge source file recorded at a bitrate that allows for all these rapidly changing frames, then reduce the final size in post-processing.
I've even proven that driving a 2560x1080 display doesn't take oodles of memory because I actually set the timings for such a display in order for a Raspberry Pi to be able to drive it at that resolution. Conveniently the memory split for the overall system and the GPU respectively is also tunable, and the total shared memory is a relatively meager 1GB. I used to set it at 256MB because just like the aforementioned gamers, I thought that a display would require that much memory. After running into issues that were driver-related (seems like the VideoCore driver in Raspbian buster is kinda fuckulated atm, while it works fine in stretch) I ended up tweaking that a bit, to see what ended up working. 64MB memory to drive a 2560x1080 display? You got it! Because a single frame is only 8MB in size, and 64MB of video memory can easily fit that and a few spares just in case.
I must've sucked all that data out of my ass though, I've only seen people build GPU's out of discrete components and went down to the realms of manually setting display timings.
Interesting build log / documentary style video on building a GPU on your own: https://youtube.com/watch/...
Have fun!20 -
Today, a video appeared online of a game called StoneHearth, which is currently in open Alpha.
The video is about adding multiplayer functionality to this (originally) singleplayer game.
'Tony' is a hero! Because he initially designed the singleplayer game according to a strict client-server model, adding multiplayer is now a piece of cake. Good thinking there.
The structure of the game even made it harder for developers to hack around it, than just to follow the model. That is awesome. Kudos to Tony!
https://youtube.com/watch/...1 -
Ok, I'm actually raging at vuejs right now, and this is coming from my second year using it.
the fucking shit is weird.
functional components cannot use v-model.
functional components also cannot reference other components via components property, that child component needs either to be global or be injected (an ugly hack).
v-model behaves differently on checkboxes. checkboxes are fucking shit on vue. things update or do not update.
functional components with checkboxes? hahahahahaha.
vue 3 is taking an ungodly shitload of fucking amount of time.
fuck react, but im actually considering giving vue the middle finger as well.
started this product migration 2 months ago and regretting it, looking at svelte with curious eyes.12 -
Sync
My project: Build model... 1hour plus
Still stuck!!!!!!!
Scenario: After adding just one existing module. 🚶
Android studio v 4.1.3
WTF2 -
Learning vue and it's lovely, except FUCKING V-MODEL I'm literally 10 hours of tutorials in and I still have no clear idea what the thing does, I'm pretty sure it's like 2/10 complexity thing but someone just HAD TO name it V-MODEL so that it doesn't give you a slightest hint of the actual functionality, like you might as well have named it v-cable or v-oompaloompa, it would have the exact same information value (none).3