Details
-
AboutJust some random dude.
-
Skillslearning HTML/CSS and PHP.
Joined devRant on 10/28/2016
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
-
!rant
This was over a year ago now, but my first PR at my current job was +6,249/-1,545,334 loc. Here is how that happened... When I joined the company and saw the code I was supposed to work on I kind of freaked out. The project was set up in the most ass-backward way with some sort of bootstrap boilerplate sample app thing with its own build process inside a subfolder of the main angular project. The angular app used all the CSS, fonts, icons, etc. from the boilerplate app and referenced the assets directly. If you needed to make changes to the CSS, fonts, icons, etc you would need to cd into the boilerplate app directory, make the changes, run a Gulp build that compiled things there, then cd back to the main directory and run Grunt build (thats right, both grunt and gulp) that then built the angular app and referenced the compiled assets inside the boilerplate directory. One simple CSS change would take 2 minutes to test at minimum.
I told them I needed at least a week to overhaul the app before I felt like I could do any real work. Here were the horrors I found along the way.
- All compiled (unminified) assets (both CSS and JS) were committed to git, including vendor code such as jQuery and Bootstrap.
- All bower components were committed to git (ALL their source code, documentation, etc, not just the one dist/minified JS file we referenced).
- The Grunt build was set up by someone who had no idea what they were doing. Every SINGLE file or dependency that needed to be copied to the build folder was listed one by one in a HUGE config.json file instead of using pattern matching like `assets/images/*`.
- All the example code from the boilerplate and multiple jQuery spaghetti sample apps from the boilerplate were committed to git, as well as ALL the documentation too. There was literally a `git clone` of the boilerplate repo inside a folder in the app.
- There were two separate copies of Bootstrap 3 being compiled from source. One inside the boilerplate folder and one at the angular app level. They were both included on the page, so literally every single CSS rule was overridden by the second copy of bootstrap. Oh, and because bootstrap source was included and commited and built from source, the actual bootstrap source files had been edited by developers to change styles (instead of overriding them) so there was no replacing it with an OOTB minified version.
- It is an angular app but there were multiple jQuery libraries included and relied upon and used for actual in-app functionality behavior. And, beyond that, even though angular includes many native ways to do XHR requests (using $resource or $http), there were numerous places in the app where there were `XMLHttpRequest`s intermixed with angular code.
- There was no live reloading for local development, meaning if I wanted to make one CSS change I had to stop my server, run a build, start again (about 2 minutes total). They seemed to think this was fine.
- All this monstrosity was handled by a single massive Gruntfile that was over 2000loc. When all my hacking and slashing was done, I reduced this to ~140loc.
- There were developer's (I use that term loosely) *PERSONAL AWS ACCESS KEYS* hardcoded into the source code (remember, this is a web end app, so this was in every user's browser) in order to do file uploads. Of course when I checked in AWS, those keys had full admin access to absolutely everything in AWS.
- The entire unminified AWS Javascript SDK was included on the page and not used or referenced (~1.5mb)
- There was no error handling or reporting. An API error would just result in nothing happening on the front end, so the user would usually just click and click again, re-triggering the same error. There was also no error reporting software installed (NewRelic, Rollbar, etc) so we had no idea when our users encountered errors on the front end. The previous developers would literally guide users who were experiencing issues through opening their console in dev tools and have them screenshot the error and send it to them.
- I could go on and on...
This is why you hire a real front-end engineer to build your web app instead of the cheapest contractors you can find from Ukraine.
19 -
rant && dev && education
So I just interviewed this guy for admission into our bootcamp and because he has raised some red flags before, I asked him to just write a factorial function and he chose HTML to do it. I told him he can certainly try thinking that maybe he doesn't know that whatever you write inside script tag is actually JavaScript. He went on to do this. What bothers me is he have a computer science diploma.
Till now I have just heard of these people but always taught those are just marketing or some person who think that just because they here HTML with some other programming language. BUT THIS IS SOME NEXT LEVEL SHIT.
78 -
I imagine two dev colleagues sitting next to each other, on their phone, each feeling very secure in the anonymity of devrant.
11 -
Wan't your own personal devBanner?
Now you can have one!
We're building a powerful banner generator over here: https://devrant.com/collabs/...
The first version is up and running, still basic tho.
You can generate your own by calling this URL:
https://devrant.nuernberger.kim/api...
You'll have to replace "Kimmax" with your devrant name and the value after subtext with the extra text.
A cool domain is already on it's way!
We'll be working on a frontend and a ton of extra features to make this banner even more awesome.
If you got any nice ideas add them to the issue tracker here: https://github.com/cozyplanes/...
Have fun!
95 -
:^)
For real though, to each their own in the end.
I accept MacOS for development, but Apple hardware is just price gouging.
51 -
Ever wanted cheat codes to devRant? Well, that's weird. But here you go, I guess.
Since the avatars do not use any external assets (Such as images), all avatars are generated. To be friendly to people who want to make third-party devRant clients (such as devRantron), avatars are generated server-side, so that the assets don't need to be distributed, and third-party programmers don't need to work out rendering avatars.
But this allows you to cheat a little.
The devRant avatars API works like this: you request a really long URL from the API, specifying the IDs of each cosmetic item the user has active, and it returns a PNG file. But you don't need an auth token to generate an avatar (which makes sense), so the avatar API is essentially a sandbox you can play around with if you have the time and patience.
You can write a really good avatar previewer with this knowledge, and see your avatar with a white tiger, even if you don't have the ++s
13
