WSTECZ
Mówi się, że czas leci szybko, gdy dobrze się bawisz. Dla mnie osobiście zabawa jest szczególnie ważna w codziennej pracy nad startupem i rozwojem biznesu. Sprawia, że cieszę się sobą bez względu na to, jak wiele moich wewnętrznych zasobów energii pochłaniają cotygodniowe obowiązki.
(W następnym odcinku będę kontynuował temat humoru w miejscu pracy, aby rozwinąć go nieco bardziej, tylko dlatego, że mogę. "Dlaczego tak poważnie?").
Mówiąc o czasie, minęły 2 tygodnie od mojej ostatniej publikacji, więc najwyższy czas na 4 odcinek naszego #TheCodestReview seria.
Komentarz na temat buforowania widoku dostarczony przez naszego programistę fullstack i podcast kierownika inżynierii skomentowany przez moją skromną osobę.
Jako powszechnie znany mistrz aplikacji Paint oraz wielbiciel GIF-ów i memów, które są jak czekoladki Merci - mówią więcej niż 1000 słów, postanowiłem, że od teraz będę dodawał tutaj ich smaczek. I zgadnijcie co?
Darth Sidious Myślisz, że możesz mnie powstrzymać GIF z Darthsidious GIFs
Ostatnim razem zdecydowaliśmy się poświęcić trochę uwagi StimulusReflex, który przyciąga uwagę społeczności Ruby jako nowy dzieciak na bloku, będący alternatywą dla korzystania z nowoczesnego Javascript frameworków w projektach Rails, aby uniknąć przesady.
Zobacz: StimulusReflex aka ReactiveRails
Aby była to walka na równych warunkach, chciałem pozwolić React odegrać się na Stimulusie. Ponieważ jestem również dobrze znanym człowiekiem honoru, zawsze robię to, co mówię i dotrzymuję obietnic, oto on:
W następnym odcinku mam przyjemność ogłosić, że będziemy mieli gościnny wpis inżyniera React z Vinted.com. Dla tych z Was, którzy nigdy nie słyszeli o Vinted (małe szanse, ale wciąż możliwe), Vinted to rynek mody pochodzący z Wilna na Litwie, który osiągnął wycenę jednorożca w 2019 roku. Platforma zbudowana jest na solidnym fundamencie Ruby on Rails wspieranym przez React w części frontendowej.
Na marginesie: moja żona absolutnie uwielbia Vinted i prawie całkowicie przestała używać OLX jako głównego miejsca docelowego do porządkowania naszej garderoby i sprzedaży używanych ubrań (była prawdziwą zagorzałą fanką) =. ROBICIE TO DOBRZE!
Mam zaszczyt powitać pierwszego gościa w naszej serii:
Meryl Streep Tak GIF z GIF-y Merylstreep
Ugnė Kryževičiūtė - inżynier React z Vinted
Czytając tytuł ostatniego podcastu LadyBug ("Getting Hooked On React"), spodziewałem się, że będzie on dotyczył głównie haków React. A jednak, choć nie zagłębiał się on głęboko w Hooks, podcast stanowił doskonałe wprowadzenie do podstaw biblioteki React dla JavaScript.
Ali i Emma z podcastu LadyBug omawiają tajniki React - od ogólnego układu biblioteki i jej zalet po ożywione dyskusje na temat komponentów, obsługi danych lub cyklu życia React, a wszystko to przedstawione ze szczyptą osobistego doświadczenia. Warto posłuchać każdego programisty front-end, który nie miał jeszcze okazji wypróbować cudów React.
Moje pierwsze spotkanie z React miało miejsce około trzy lata temu, kiedy rozpocząłem swoją podróż jako programista. Chociaż Ali i Emma sugerują, że React może początkowo wydawać się mylący, z własnego doświadczenia uważam, że jest stosunkowo łatwy do rozpoczęcia i prawdopodobnie najłatwiejszy do zaawansowania w porównaniu z innymi frameworkami front-endowymi. Wszędzie dostępnych jest mnóstwo samouczków, artykułów, bibliotek open-source i innego rodzaju materiałów edukacyjnych. Należy jednak pamiętać o aktywnym rozwoju React podczas przeglądania takich zasobów. Ten odcinek podcastu LadyBug nie jest wyjątkiem - niektóre aspekty i metody, o których mowa, są już od jakiegoś czasu przestarzałe. Najlepiej więc zastosować się do rad samej Emmy i zapoznać się z najnowszą dokumentacją.
React bardzo ewoluował i dojrzał, dzięki czemu kod pisanie jest jeszcze łatwiejsze dzięki Hooks, które pozwalają używać metod stanu i cyklu życia bez pisania komponentów klas. Ale dla początkujących - jak trafnie zauważa Ali - różnorodność sposobów pisania React (takich jak komponenty klasowe / funkcjonalne / haki) dodaje dodatkowej złożoności, ponieważ czasami może być trudno zwizualizować, co się dzieje. Ponadto, konieczność destylacji tego, czego potrzebujesz i znalezienie odpowiednich informacji dotyczących implementacji kodu może być wyzwaniem.
Jako jedną z głównych zalet React Ali wskazuje fakt, że jest on oparty na komponentach, co umożliwia modularyzację kodu i ułatwia współpracę z innymi programistami. Poza tym, możliwość korzystania z JSX jest świetną pomocą wizualną podczas pracy z interfejsem użytkownika w kodzie JavaScript - nie musisz mieć oddzielnych plików HTML!
Ali i Emma również ładnie podsumowują elastyczność, jaką daje posiadanie systemu komponentów. Doskonałym przykładem z praktyki jest moja firma Vinted, która doświadczyła szybkiego wzrostu w odniesieniu do produkt jak również zespoły deweloperskie pracując nad nim przez ostatnie kilka lat. React przyniósł ogromne korzyści - umożliwił nam pisanie znacznie czystszego kodu, korzystanie z komponentów interfejsu użytkownika wielokrotnego użytku i ułatwił testowanie naszego kodu.
Ogólnie rzecz biorąc, ten odcinek podcastu LadyBug zapewnia żywą i czarującą dyskusję na temat głównych aspektów React. Polecam go każdemu, kto rozpoczyna swoją podróż z React. Pełen zabawnych przykładów i analogii do prawdziwego życia, odcinek płynnie "przyciąga" uwagę każdego słuchacza, w tym moją.
Widoki w Railsach niestety z czasem stają się coraz wolniejsze. Dzieje się tak, ponieważ ilość obiektów przechowywanych w bazie danych rośnie. Powoduje to dłuższe czasy zapytań i oczywiście dłuższe przetwarzanie, jeśli robisz coś z każdym z obiektów. Kiedy tak się dzieje, nie jesteś bez szans, ponieważ istnieje buforowanie widoków Rails.
Dzięki temu można zaoszczędzić sporo czasu, ładując ciężkie dane z bazy danych z pamięci podręcznej (ładowanie pojedynczego zapisanego pliku html zamiast odpytywania bazy danych i przetwarzania obiektów). Można to również uczynić mniej kosztownym w przypadku różnych części i obiektów - oczywiście jeśli obiekty nie zmieniają się zbyt często. Można również spróbować przechowywać buforowane obiekty w oddzielnych partialach - i zaoszczędzić np. 19 z 20 renderowanych postów (być może z dużą ilością pól).
Domyślnie buforowanie Railsów używa file_store i przechowuje buforowane dane w folderach. Nie usuwa jednak starych wpisów w pamięci podręcznej (które mogły wygasnąć dawno temu). Może to prowadzić do przepełnienia ilości plików lub nawet wyczerpania wolnego miejsca na serwerze. Inną metodą jest memory_store, która również ma pewne wady (ponieważ pamięć podręczna jest przechowywana na jednym serwerze). Może również przekroczyć ilość pamięci RAM przechowywanej na serwerze (lub brak pamięci podręcznej, jeśli będzie ona cały czas usuwana). Dlatego najlepszym mechanizmem buforowania na dużą skalę jest metoda Memcached/Redis. Daje to możliwość korzystania z oddzielnej maszyny przechowującej pamięć podręczną, która może być używana przez wszystkie serwery. Dzięki temu nie będzie problemu z brakiem cache lub kończącym się miejscem na dysku na serwerze.
Pamięć podręczna w Railsach jest przechowywana na podstawie identyfikatora - który może być podany od razu jako ciąg znaków lub wygenerowany automatycznie po przekazaniu obiektu do funkcji pamięci podręcznej. W przypadku obiektów jest to najczęściej atrybut updated_at. Można również podać klucz statyczny z parametrów obiektu.
Inną metodą buforowania jest użycie Javascript do aktualizacji pola, które jest zmieniane raz dziennie. W ten sposób można mieć aktualną datę wyświetlaną przez cały czas, bez odświeżania strony internetowej - co może być dość duże lub powolne.
Aby nie zepsuć zbyt wiele, dyskusja panelowa obejmująca temat roli kierownika inżynierii w procesie rekrutacji jest bardzo cenna dla wszystkich, którzy zastanawiają się, kiedy jest odpowiedni czas, aby lider technologiczny wkroczył w cykl rozmów kwalifikacyjnych. Na CodestW pewnym sensie praktykujemy to, co głoszą paneliści i nasze CTO jest pierwszym punktem kontaktu z aplikującymi do nas inżynierami, natomiast na kolejnym etapie rozmowy kwalifikacyjne przeprowadzane są przez zespół menedżerów, z którymi potencjalni nowi pracownicy będą ściśle współpracować. Kilka praktycznych rad, które możesz zastosować od razu, aby ulepszyć swoją grę rekrutacyjną jako kierownik ds. inżynierii:
Przeanalizuj swój proces i upewnij się, że dołączyłeś do niego tak wcześnie, jak to możliwe, najlepiej będąc pierwszym punktem kontaktowym dla kandydatów, ponieważ pierwsze wrażenie odgrywa kluczową rolę w tym, jak Twoja firma jest postrzegana przez największe talenty.
Skontaktuj się z wysoce skutecznymi menedżerami ds. rekrutacji w swojej organizacji (być może z tymi, którzy zatrudnili Cię w przeszłości) i zapytaj, czy mógłbyś obserwować niektóre z ich planowanych rozmów kwalifikacyjnych, sprawdzić ich techniki, zapytać o wskazówki. Obserwuj i ucz się. Przystępuj do każdej rozmowy z prawdziwą ciekawością wobec kandydatów.
Szukaj potencjału i zatrudniaj pracowników z potencjałem i zdolnością do szybkiego rozwoju.
Omów ogłoszenia o pracę ze wszystkimi inżynierami i zapytaj, czy chcieliby ubiegać się o tę pracę. Jeśli nie, zapytaj, co jest do bani i zastosuj ich opinie w ogłoszeniu o pracę w wersji 2.0, które zamierzasz opublikować na portalach z ofertami pracy.
Postrzegaj pierwszą rozmowę kwalifikacyjną jako okazję do nawiązania świetnych relacji z potencjalnymi przyszłymi współpracownikami.
Zachęcam do obejrzenia całego panelu wideo, ale jeśli jesteś fanem podcastów i lubisz ich słuchać podczas jazdy samochodem, ćwiczeń lub zmywania naczyń, tutaj masz również Spotify link.
Wielkie dzięki za przeczytanie i jeśli dotarłeś tak daleko, doceniam twój czas, a wszelkie opinie (czy to fajne, czy mnie niszczące) są więcej niż mile widziane. LinkedIn lub do mojego e-mail.
Kolejny odcinek już wkrótce!
Yippie IWill See You Soon Tańczący GIF z Yippieiwillseeyousoon GIFs
Czytaj więcej:
TheCodestReview #3 - cotygodniowy sok z inżynierii oprogramowania
TheCodestReview #2 - cotygodniowy sok z inżynierii oprogramowania
TheCodestReview #1 - cotygodniowy sok z inżynierii oprogramowania
Polish 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch 
Estonian 
Greek