Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "apple users"
I’m surrounded by idiots.
I’m continually reminded of that fact, but today I found something that really drives that point home.
Gather ‘round, everybody, it’s story time!
While working on a slow query ticket, I perused the code, finding several causes, and decided to run git blame on the files to see what dummy authored the mental diarrhea currently befouling my screen. As it turns out, the entire feature was written by mister legendary Apple golden boy “Finder’s Keeper” dev himself.
To give you the full scope of this mess, let me start at the frontend and work my way backward.
This function allows the user to better see the rows in the API Calls table, for which there is a also search feature — the very thing I’m tasked with fixing.
It’s worth noting that above the search feature are two inputs for a date range, with some helpful links like “last week” and “last month” … and “All”. It’s also worth noting that this table is for displaying search results of all the API requests and their responses for a given merchant… this table is enormous.
This search field for this table queries the backend on every character the user types. There’s no debouncing, no submit event, etc., so it triggers on every keystroke. The actual request runs through a layer of abstraction to parse out and log the user-entered date range, figure out where the request came from, and to map out some column names or add additional ones. It also does some hard to follow (and amazingly not injectable) orm condition building. It’s a mess of functional ugly.
The important columns in the table this query ultimately searches are not indexed, despite it only looking for “create_order” records — the largest of twenty-some types in the table. It also uses partial text matching (again: on. every. single. keystroke.) across two varchar(255)s that only ever hold <16 chars — and of which users only ever care about one at a time. After all of this, it filters the results based on some uncommented regexes, and worst of all: instead of fetching only one page’s worth of results like you’d expect, it fetches all of them at once and then discards what isn’t included by the paginator. So not only is this a guaranteed full table scan with partial text matching for every query (over millions to hundreds of millions of records), it’s that same full table scan for every single keystroke while the user types, and all but 25 records (user-selectable) get discarded — and then requeried when the user looks at the next page of results.
What the bloody fucking hell? I’d swear this idiot is an intern, but his code does (amazingly) actually work.
No wonder this search field nearly crashed one of the servers when someone actually tried using it.
#fuckapple for holding back the open-web. Most folk don't know that Chrome on iOS is just Safari with a skin; neither Google or Apple want you to know that.
If you hate web-apps on iOS, that is Apple's intentional doing. Apple cannot allow a bug-free and modern browser to run on their iOS devices, else they lose their 30% tax + dev fees cut. There are literally so many crippling bugs in iOS Safari that it HAS to be intentional.
There are email exchanges between Phil Shaffer and Steve Jobs from years past, where Phil didn't believe Apple could continue to gouge users 30%. He argued the open-web would make native apps largely redundant, and so to stay competitive, they'd need to drop the store fees to something reasonable. I suppose Steve Jobs saw a different solution -- just impede browser development.
As someone who develops free and open-source apps, I believe I am doing the world a favour by not supporting a native iOS app. When users complain about missing features in the web-app version, I tell them to take it up with Apple or buy an Android. Guess what? They sometimes actually do just that.
Join me if you have the balls. Tell Apple to FUCK OFF the only way they understand -- threaten their bottom line. At the very least, you'll never need to touch XCode again if you do. If time is money, that alone will make you wealthy.10
Dear Apple, You made an amazing UI but Windows sure does beat you in terms of ease of use.
So my company provided us with Macbooks, I've been a windows users for almost 7-8 years now.
The thing I want to rant about is how we cannot switch between same application windows in full screen.
In Windows, you press tab, voila, the other full screen window. For instance, I want to use 2 google chrome "full" size windows, I cannot just press tab and view the other one, Like whaaaat!
There should be a provision to use the other window of the same application.
The same thins is so easily done in windows machine.13
Fuck Apple with two pineapples in the ass. 99€ per fucking year to tell me how the fuck should the access to my app be. I damn require users to sign up. I only need email and country. Not a single other piece of data. My app is not a goddamn catalogue or boutique. No free content, free app but each user needs to Auth themselves. You fucking telling me y pay 99€ so you decide how the access to my app should be?
Cunt Apple should rot in 10 day old humid shit and let devs be owners of their apps and hard work. Clowns.7
I am hearing reports from less computer savvy people that some Apple devices will refuse to charge the battery if updates are not applied. Supposedly as a way to strong arm users to update. I cannot find anything on this when searching.
Has anyone heard of this?9
Android users, I have a question.
How many of you do actually use Apple signup on your Android device?