Przechowywanie 5000 elementów po stronie klienta w aplikacji internetowej [zamknięte]

Właśnie miałem wywiad telefoniczny dla programisty ASP.Net, po wstępnych wstępnych pytaniach ankieter zadał mi pierwsze pytanie techniczne:

„Jak miałbyś przechowywać 5000 elementów po stronie klienta dla każdego użytkownika w aplikacji internetowej”.

Moja odpowiedź rozpoczęła się od:

Jaki jest średni rozmiar każdego elementu? Czy naprawdę musimy przechowywać tyle danych po stronie klienta? Czy nie możemy zachować tego w bazie danych i jakoś powiązać z identyfikatorem sesji / klienta .

Jego odpowiedź brzmiała: „Nie, mówisz mi, jak chcesz go przechowywać po stronie klienta, biorąc pod uwagę, że każdy element jest rekordem z około 8 polami, w tym int / string, normalnym wierszem tabeli”.

Powiedziałem: „Mogą być przechowywane w sesji, ale ponieważ sesje są utrzymywane po stronie serwera dla każdego użytkownika, może to stać się kosztowne lub inną opcją jest przechowywanie tak dużej ilości danych w pliku cookie”, powiedziałem również, że nie jestem upewnij się, że tyle danych może być przechowywanych w pliku cookie. Wspomniałem, że istnieją opcje przechowywania HTML5, ale z tym nie pracowałem. Ponieważ jest oparty na SQLite, może teoretycznie przechowywać tyle danych .

W tym miejscu ankieter powiedział nieco sarkastycznie , więc masz 3-letnie doświadczenie w tworzeniu stron internetowych i zakończyłeś wywiad.

Zastanawiam się, co zrobiłem źle? czy jest coś naprawdę podstawowego, czego mi brakuje w odniesieniu do przechowywania danych po stronie klienta.

Zgadzam się z komentarzami, że prawdopodobnie szukał lokalnej pamięci HTML5 i mógł oczekiwać, że będziesz miał z nią doświadczenie.

Szczerze mówiąc, chyba że było to integralnym wymogiem pracy i nie stwierdziliście, że macie z tym doświadczenie, jego oczekiwania i reakcja były, moim zdaniem, nieuzasadnione dla każdego, kto ma jakiekolwiek doświadczenie.

Dlaczego?

Ponieważ trzy lata temu HTML5 jako specyfikacja był jeszcze w powijakach. Innymi słowy, dla ciebie, twoja kariera trwa tak długo, jak historia samej specyfikacji. Często zdarza się, że oferty pracy szukają osób z większym doświadczeniem z produktem niż ten produkt. Rzadko widuje się tak samo w przypadku całej specyfikacji. W tym celu dziękuję za znalezienie takiego klejnotu.

A tak na poważnie, wygląda na to, że problem polega bardziej na tym, że Twój ankieter zadaje ci zbyt niejasne pytanie i ocenia cię zbyt surowo. Często zdarza się, że ankieterzy zadają niejasne pytania, szczególnie na arenie programistycznej. Zwykle robi się to, aby ocenić, jak myślisz i dokąd prowadzi twój pierwszy instynkt. Zrobiłeś to dobrze, kwestionując potrzebę lokalnego przechowywania tego rodzaju danych. Te pytania same w sobie nie są złe, ale to, co robi z nimi osoba prowadząca wywiad, może doprowadzić do złego wyniku (prawdopodobnie takie zakończenie wywiadu oznacza, że ​​prawdopodobnie nie chcesz pracować dla tej firmy).

Możliwe jest, że potrzeby biznesowe firmy wymagały korzystania z lokalnego magazynu z tego czy innego powodu. W takim przypadku powinno to zostać określone w opisie stanowiska pracy i powinieneś zostać wykluczony jako potencjalnie rentowny kandydat, gdy twoje CV nie odzwierciedla takiego doświadczenia, jeśli uważają, że nie mogą lub nie powinni trenować lub w inny sposób zapewniać nowy pracownik, który ma czas / środki, aby przyspieszyć technologię.

Jeśli chodzi o lokalne przechowywanie, samo w sobie - jak wspomniałem wcześniej, HTML5 jako specyfikacja istnieje już od około trzech lat, a to jest hojne i liczy się szkic „ostatniego połączenia”. Następnie masz problem z obsługą przeglądarki, która może, ale nie musi, mieć długą historię (na przykład, podczas gdy pary nazwa-wartość były szeroko obsługiwane nawet przed zestaleniem HTML5, IndexedDB i Web SQL DB są nadal szkicowe ).

Wreszcie wykorzystanie lokalnego magazynu HTML5 jest jeszcze mniej powszechne. Jako programista stron internetowych spotkałem się z aplikacją, o której wiem, że korzystała z niej od razu (być może niektóre wykorzystują ją niewidocznie, ale trudniej ją oszacować), a może nawet pół tuzina projektów, które mogą być w stanie korzystać z niego (ale tak naprawdę ich nie potrzebowałem w tym czasie, lub koszt zastosowania takiego podejścia w porównaniu z innym nie był uzasadniony).

W bardziej ogólnym sensie zdarzają się nieudane wywiady. Rozwój oprogramowania to zdecydowanie zbyt duża dziedzina, aby móc poznać wszystkie drobne szczegóły na temat każdej pojedynczej rzeczy (w tym przypadku limity pamięci lokalnej pamięci HTML5), a szczera wiedza na temat niewiedzy jest moim zdaniem wciąż najlepsza droga (osobiście mam większy szacunek dla kogoś, kto dostrzega swoje braki wiedzy i stara się je wypełnić, niż dla kogoś, kto próbuje ukryć fakt, że czegoś nie wie). Mając to na uwadze, powiedziałbym, że dobrze poradziłeś sobie z tym pytaniem, biorąc pod uwagę informacje, które tutaj podałeś. Gdyby było coś ciebie popełnił błąd, mogło to być w szczegółach tego, jak zareagowałeś, na co nie możemy ci pomóc, ponieważ nie byliśmy na rozmowie, aby ocenić pozajęzykowe aspekty twoich odpowiedzi.

„Prawidłowa” odpowiedź - przynajmniej ta, której szukali - była rzeczywiście HTMLS LocalStorage (doskonały link Stevena Burnapa). A osoba przeprowadzająca wywiad była prawdopodobnie… cóż, uważam, że techniczne wyrażenie to „trochę pokrętło ”.

Zasadniczo osiąga się to poprzez proces eliminacji, ponieważ plik cookie nie może być wystarczająco duży , sesje są po stronie serwera, a nie mechaniki przechowywania po stronie klienta itp. Osoba przeprowadzająca wywiad prawdopodobnie myślała, że ​​to powszechna wiedza, a ty powinieneś o tym wiedzieć, co jest zabawne, ponieważ potrzebujesz tylko możliwości HTML5 LocalStorage zwykle w pracy z dużym interfejsem użytkownika, która jest wyjątkiem, a nie regułą. Osoba może programować przez wiele lat i nie potrzebuje tej funkcji, podczas gdy inni mogą potrzebować jej przy pierwszym projekcie.

Generalnie jednak powiedziałbym, że w takich przypadkach jest to mniej pytanie o twoją odpowiedź, a raczej pytanie, w jaki sposób odpowiedziałeś i jak to zrobiłeś. Z twojego opisu zrobiłeś OK, ale mnie tam nie było, więc ich wrażenie może być zupełnie inne.

Większość rozsądnych ankieterów nie ogłosi jednego małego aspektu technologii testem lakmusowym, w którym każda osoba musi odpowiedzieć na to świetnie ... jednak miałem wiele wywiadów z ludźmi, którzy nie są rozsądnymi ankieterami. Znajomość takich drobiazgów może być dobrodziejstwem, gdy napotkasz takie osoby.

Na koniec chciałbym zauważyć, że ogłaszając rozmowę w raczej niezbyt miły sposób, jest wysoce prawdopodobne, że osoba ta była już zirytowana i już o tobie zdecydowała (odpowiedź na to konkretne pytanie mogła nie mieć znaczenia w najmniejsze). Czekali tylko na chwilę, abyś się potknął, aby mogli wskazać na to i nie ujawnić faktu, że w ciągu pierwszych 30 sekund zdecydowali, czy jesteś dobrym kandydatem, czy nie.

Być może poćwiczyłbym, jak odpowiadać na pytania, na które od razu nie znasz „właściwej” odpowiedzi, ponieważ umiejętność bycia z wdziękiem, wydawania się kompetentnego i inteligentnego jest i tak cholernie przydatną umiejętnością - i wszyscy moglibyśmy skorzystać z dodatkowej praktyki . Odśwież kilka artykułów „co nowego w [najnowszej wersji ważnej technologii]”, a następnie wracaj!