Waar was dan dat stukje UI voor waarvan jij zegt dat die weggehaald is maar de code erachter bleef draaien?
Natuurlijk hoorde het bij elkaar. Maar het is
niet zo dat als de UI-code weg is, dat dan automatisch de rest ook weg is. Bij html-formulieren heb je sowieso altijd minimaal 2 stappen: het formulier en de verwerking daarvan. Formulieren kunnen heel goed bij een 'template team' horen en verwerking van de submits bij een 'backend team'.
Ik weet niet hoe ze werken, maar die scheiding komt in de industrie voor. Zeker bij grote bedrijven.
En met zo'n scheiding is het prima mogelijk dat het formulier is aangepast en in de code-flow een heel eind verderop niet is gedacht aan dat daar nog iets met een knop uit dat formulier gebeurde.
Als het een functie is dan kun je die gewoon van bovenaf uitzetten, zelfs als de code ernog staat.
Kan misschien. Maar dat moet je dan specifiek ingebouwd hebben en bewust doen. En dat laatste is dus sowieso niet gedaan.
Ja, maar dat is allemaal bedacht op basis van jouw aanname dat het per ongeluk is gegaan.
Mijn
aanname?!?!
Het is nota bene wat ze zelf zeggen. Ik probeer vooral duidelijk te maken dat het een plausibele verklaring is.
Veel simpeler is het om te denken dat ze nooit werkelijk een poging hebben gedaan om het uit te zetten. Dat past ook in lijn met andere privacygevoelige dingen waarvan facebook zegt dat het niet gebeurt maar achteraf wel blijkt te gebeuren.
Dat is helemaal niet simpeler. Hun verklaring is simpelweg daadwerkelijk plausibel. Of het ook de waarheid is kan ik je niet vertellen.
Code kan niet actief zijn tenzij het aangeroepen wordt.
Dat klopt. Maar er zijn bij dit soort situaties allerlei asynchrone aspecten, waardoor de code die hoort bij het verwerken van de formulier-resultaat niet hoeft te veranderen om iets bij het formulier anders te doen.
Wil je zeggen dat facebook geen goed overzicht heeft op welke code er draait en welke functies dat hun backend biedt?
Ik weet niet of ze dat wel of niet hebben. Maar gezien de enorme hoeveelheid code die ze hebben, zou het me eerlijk gezegd niet verbazen als er niemand is die daadwerkelijk alles weet. En dat losse teams en teamleden niet alles weten, is waarschijnlijk gewoon een feit. Bekijk ook de reactie van @
P_Tingen een eindje verderop hoe zoiets zou kunnen ontstaan.
Dan zeg je dat facebook naar de UI kijkt om te bepalen of een stuk code nog actief is ofzo?
Nee. Ook dat niet. Sowieso niet iedere keer. Het zal van de omstandigheden afhangen.
Maar ze kijken zeer waarschijnlijk los naar de UI en naar code die iets doet met handelingen die in de UI gebeuren. En daar zit natuurlijk wel wat impliciete en expliciete koppelingen tussen. Maar zeker als iets in deze flow pas tientallen stappen verderop gebeurt, is het prima mogelijk dat die koppeling gemist is.
Luister, een bedrijf als facebook heeft enorm veel klanten en is over de hele wereld actief. Elk stuk code zal tot de bodem gemanaged worden, anders is zoiets onbehersbaar.
Dat tot de bodem managen zal juist onbeheersbaar zijn. Al is het alleen maar omdat je dan je programmeurs kwijt bent en/of net zo veel managers als programmeurs nodig hebt.
Het kan niet anders dan dat ze wisten dat er nog steeds telefoonlijsten werden binnengehengeld.
Dat kan wel degelijk.
Facebook was al lang en breed van het toneel verdwenen als ze hun code niet beheersten. Het schaalt namelijk niet als er wilde stukken code blijven draaien zonder dat daar iemand achter komt.
In theorie juist, in de praktijk zwaar overdreven. Dit gebeurde op stap die weinig gebruikers doorlopen, vaak hooguit een of enkele keren in hun "Facebook leven"; want het zat blijkbaar in de emailvalidatie.
Op hun performance-monitoring merken ze daar niks van.
Dit ging (toevallig weer) over een privacyaspect, maar wat denk je dat er gebeurt als ze zich dit soort fouten in andere delen van hun code zouden opdoemen? Dan werkte facebook niet meer.
Dat concept is heel bekend en noemt men in de regel 'bugs'. En daar heeft ook Facebook mee te maken.
Zelfs makers van ruimteapparatuur en controlesystemen maken fouten, en zij hebben veel hogere interne en externe eisen op het gebied van tests en codekwaliteit. Dus waarom denk je dat Facebook geen bugs heeft of fouten maakt?
Maar grappig genoeg zie je dat soort problemen niet bij facebook. Dus ze kunnen het blijkbaar wel, hun systeem beheersen,.. Maar dan weer toevallig een aantal zwaar privacygevoellige deatures die 'per ongeluk' blijven draaien? Maak dat de kat wijs.

De privacygevoelige dingen zijn degenen die het nieuws halen. Behalve de enkele keren dat ze deels of zelfs helemaal down zijn, betwijfel ik het of andere bugs en fouten het nieuws halen.
Hoe dan ook, ik zie zo'n fout niet zo snel per ongeluk gebeuren. En ik zie het helemaal niet snel gebeuren bij een bedrijf als facebook dat vaak iets anders doet dan het zegt te doen.
Ik vind het een plausibele uitleg. Ik ga niet beweren dat het daadwerkelijk de waarheid is, maar om nou altijd maar te suggeren dat Facebook geen fouten kan maken en alles expres doet, gaat me ook erg ver.
Wat ze in mijn beleving wellicht wel teveel expres doen, is dat als er dergelijke fouten worden ontdekt, dat ze die onder de pet houden. Maar zelfs daar kan zijn dat de communicatie niet voldoende in orde is. Als een paar developers denken "shit, dit moest vorig jaar al uit", wie weet of ze dan nog even aan hun manager doorgeven dat het er nog was.
En ja, ik vind het ook plausibel dat Facebook hun zaken lang niet zo goed op orde zou hebben als jij lijkt te denken
[Reactie gewijzigd door ACM op 23 juli 2024 04:42]