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 - "xmlhttprequest"
-
!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 -
Me : I found this code issue, I think we need to fix it
PO: does it affect the user?
Me: not really but we can make it better
PO: do you have a defect for it in *insert issue tracker here*
Me: no, I just noticed it
PO: is there an IM ticket for it?
Me: I don't think so
PO: is this issue already in production?
Me: possibly. Yes. That's why I was wondering if we should fix it.
PO: okay then we will fix it in the 3rd release from now if you still remember it by then.5 -
Regular expressions. I know it's not a tool but damn me if I haven't used it like one. Especially regexr.com1
-
❤️debugging
to give you an idea of how much work this really was, the problem was that the request wasn't sending in the frontend6 -
Create a html page on paper, a simple form.
That part was easy.
The hard part was to create the ajax submit function with the validation, jquery is ok.
Failed the test because no way i can remember those shit.
That was 6 years ago -
Sudden changes in requirements. Business now wants a switch for this whole fucking project. They knew this fucking months ago and decided to tell us now. What the frikkity truck I just can't even2
-
There is an "SA" who doesn't know anything about different architectures used around, does not ask if he doesn't know and assumes stuff and puts us in those cringe-worthy moments where everyone in the meeting kind of becomes quiet because he is uttering obvious bullshit. He does this in meetings with senior managers and developers from other teams which clearly puts our team down!
-
Contrary to popular opinion, I still firmly stand by my belief that you should thoroughly study something in-depth before you attempt to do anything serious with it. Failure to do so will have an enormous cost of waste of time attached to it.
Here's an example:
I was using AJAX to post a multi-part request containing a file.
Now here was the problem: no matter what code I forced in the backend, the browser would in all cases refuse to prompt a SaveFileDialog (and I had turned on the option in the browser to ask the user if download). This took me two entire days and at least 100 Google queries and several RFCs to figure out.
From StackOverflow:
The cause was simply that you can't (typically) make a browser prompt a SaveFileDialog via an AJAX request, even if you set the necessary headers. Why? The browser will just dump everything back into the XmlHttpRequest object..
If you make a regular request with Content-Disposition: attachment; and so on, then it works, but yeah, not with an XmlHttpRequest.
Conclusion:
Had I better studied the HTTP spec, networking and AJAX in-depth, I would have instantly known what the cause was.7 -
* hours into the debug session *
"... What are we debugging again?" - me
*Awkward silence*
Actually because no one remembers as well -
Can somebody give working example how to solve
Access to XMLHttpRequest at 'localhost:8000/index.php/api/companies/1/logo' from origin 'http://localhost:8080' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, chrome-untrusted, https.
this error is talked so much but no working solution I can find. Maybe it is somewhere but cannot find so far in the internet trash.
Nginx server.
Not by installing chrome plugin, because other people would also need to install it. Thats not a solution.20