Blog przeniesiony!
Po kilku latach bycia wiernym bloggerowi, nastał czas na małą, wielką zmianę. Blog przenosi się na WordPress i pod nowy bardziej osobisty adres.
Oprócz bloga, pojawiła się także mała sekcja o mnie, jak i moje dotychczasowe (2!) wystąpienia publiczne.
Pomyślcie sobie gdy idziecie do lekarza i strasznie was coś boli. Macie wizytę, doktor bada i opukuje i finał finałów: chcielibyście dostać informacje że lekarz nie wie i zaleca wizytę u specjalisty, czy lepiej żebyście dostali witaminę C, podczas gdy np. wasze oko wygląda jak u osób zarażonych wirusem H1Z1? Ja wybieram opcje 1. Oszczędzam swój czas, swoją nadzieję że to co dostałem mnie wyleczy i oszczędzam reputację lekarza u którego byłem, bo na pewno wrażeniami z leczenia podzielę się z innymi.
Ostatnio powiedziałem: “nie wiem, nie mogę tego zrobić, to jest poza moim poziomem wiedzy” – i wiecie co, świat się nie skończył. Zadanie dotyczyło wyznaczania jakichś standardów technicznych w miejscu gdzie pracuje. Oczywiście mogłem dorzucić swoje trzy grosze, ale pomyślałem że lepiej nie wtykać nosa tam gdzie nie mam nic mądrego do powiedzenia. Gdybym się wymądrzał, mówił rzeczy które mogą nie mieć sensu, kręcił, etc. wtedy robota którą miałem dostarczyć byłaby nie fajna. Standardy, które wyznaczyłem byłyby nie fajne. wrażenia innych po przeczytaniu standardów byłyby nie fajne.
Jasne, każdy z nas chciałbym zrobić coś ciekawego i ważnego – ja też. Czasami jednak przychodzi moment, że coś mnie (nas wszystkich) przerasta. Możemy wtedy zrobić dwie rzeczy: wziąć na siebie odpowiedzialność i spierdolić sprawę śpiewająco; budżet, czas, reputacja, nerwy, zdrowie, co tam jeszcze można. Lub! Lub zagrać w otwarte karty: nie dam rady, potrzebuje kogoś innego do pomocy, albo w ogóle się na tym nie znam, musicie znaleźć kogoś innego.
Sami zgadnijcie która postawa jest bardzie pro.
Następnym razem postaram się bardziej technicznie napisać.
Jeśli klient chce statycznego HTML za kilka minut, nie dostarczaj mu dynamicznego kodu, z pętlami, partialami czy różnymi warstwami za godzinę – za późno.
Jeśli klient chce Abyś wygenerował te notatki w kontrolerze za kilka minut – nie produkuj repozytorium, nie zaprzęgaj dependency injection za godzinę – za późno.
Jeśli klient chce edycji tylko swoich wpisów i możliwości edytowania tylko tytułu czy tekstu, to dostarcz tylko tyle, nie podmieniaj całego modelu – za późno, źle i za dużo.
Pamiętaj, lepiej mieć coś co spełnia wymagania klienta powoli, niż coś co nie spełnia ich szybko.
Posłuchaj swojego klienta, zapytaj jeśli czegoś nie rozumiesz, zaproponuj jeśli uważasz że coś może być zrobione lepiej. Ale pamiętaj, że to jego biznes i to on wie jak robić na tym pieniądze.
Nigdy nie ciągnęło mnie do logowania. Zawsze miałem problem z określeniem poziomu na jaki zasługiwała dana informacja, a może ostrzeżenie. Czy to błąd, czy to już krytyczny błąd. Jak mam to dobrze zalogować. Czemu te okrutne logi tak strasznie mieszają mi się w aplikacje, wtedy jeszcze nie znałem podejścia AO.
Pisanie własnego logera też nigdy nie sprawiało mi przyjemności, zawsze czułem że robię coś nie tak. Jak już poznałem nloga czy log4net i próbowałem go zaprząc do aplikacji, to konfiguracja jednego i drugiego też zawsze szła po gruzie. Summa summarum życie szło powoli, a z logów nie korzystałem i nadal nie najczęściej nie korzystam (czasem żałuje). W projektach dziedziczonych logowanie już jest i wszystko jest już ustawione i postanowione i tak ma być – a że wszyscy referują do logera, to też jest “spoko”. Ale nie o tym miałem pisać. Często się zdarza, że mi tego brakuje i wtedy albo na chwilę dodaje logowanie, a potem usuwam, a potem jak znowu potrzebuje to usuwam, albo zostawiam bo może kiedyś mi się przyda i strasznie mnie to wkurza. Dlatego gdy odkryłem tracing musiałem się tym podzielić. Otóż taram taram – ( dla części z was oczywista oczywistość), w asp.net mvc jest wbudowane proste tracowanie, które spełnia moje podstawowe wymagania i włącza się to niebotycznie prosto.
Wystarczy tyle, żeby móc przejść na stronę myWebApp/trace.axd i móc oglądać szczegóły request’ów, które otrzymuje aplikacja. Jest tam więcej przełączników, które można poznać na internecie, np. na msdn.
Oto co dostajemy za darmoszke:
Faking hel – i to praktycznie za darmo?! Oczywiście możemy dorzucać trochę swojego logowania jeśli trzeba robi się to przez taką linikę kodu:
HttpContext.Trace.Write(“Category”, “Text to log”);
Dodatkowe wpisy znajdą się w sekcji TraceInformation. Dla mnie bóstwo. Włączyć, dodać kilka linijek w kodzie na szybko, sprawdzić i wywalić.
Podobną funkcjonalność można uzyskać przy pomocy Glimpse – też wypas. Jeszcze inna opcja to F12 developers tools w każdej przeglądarce, ale tam nie dostaniemy informacji o stanie serwera. No i tyle, krótko i na temat.
Tworzy się wszystko po angielsku, a przez to nie ma problemów ze znakami “zażółć gęślą jaźń”. Ja popełniłem ostatnio małą aplikację, gdzie postanowiłem że cały UI będzie po polsku, ponieważ do takich odbiorców kieruje swój projekt. Skoro jedno języczne to będzie to proste. HTML i opisy po polsku, atrybuty i informacje po polsku.
Nic nie zapowiadało małej katastrofy, ale ta nadeszła całkiem szybko:
Plik zapisany w UTF-8, przynajmniej VS2015 tak twierdzi (słaba ta wersja). Html meta też mówi, że to UTF-8. Ciekawie zaczyna się dopiero gdy w spojrzy się do source tree (aktualnie tego używam):
Nie zastanawiając się za długo, pomyślałem sobie walić to, kiedyś jak (nie jeśli, tylko kiedy!) będzie więcej użytkowników trzeba będzie to wyświetlić w innym języku. Zasoby! Pomyślałem i stop, bo nie pamiętam jak to się dokładnie robiło i właśnie dlatego wpis.
Prawy na projekcie, dodaj nowy resource. Z automatu dodaj się domyślny język, u mnie domyślny jest taki który nie będzie posiadać tłumaczenia, po to, żeby znaleźć braki w tłumaczeniu. Chciałem przez chwile, mieć “———-” zamiast tekstu, ale potem pomyślałem że będzie trudniej znaleźć klucz dla wartości “———“, jeśli taka będzie wszędzie. Przyjąłem na razie konwencja, że wartość odpowiada kluczowi, czyli dla klucza ViewModel_LoginViewModel_Password domyślnym tłumaczeniem jest także ViewModel_LoginViewModel_Password. Bo: nie wygląda to strasznie źle w przypadku fakapa, łatwo daje się znaleźć w wielkim pliku z zasobami, a jednocześnie szybko daje się odnaleźć w kodzie. ViewModele, klasa LoginViewModel, właściwość Password. Nie które z właściwości posiadają także błędy, wtedy dodaje do klucza informacje o błędzie np. required. Poniżej inna klasa, bo LoginViewModel okazał się nie przetłumaczony do końca – ot uroki pracy samemu i braku reviewu.
Przykład z właściwością która posiada więcej niż jeden atrybut z tłumaczeniem i klucz użyty:
ViewModel_VerifyPhoneNumberViewModel_Code_Required
ViewModel_VerifyPhoneNumberViewModel_Code
Itd, itp, etc i wiecie – rozumiecie.
Tak tylko dla wyjaśnienia: Translations to klasa, która zawiera tłumaczenia.
Co jeszcze jest ważne? Dodatkowe wersje językowe (inne niż domyśla) powinny zawierać język, które mają wspierać – u mnie .pl. I ostatnia ważna ważność: plik *.Designer.cs dla wersji językowej innej niż domyślna będzie pusty – tak ma być. Tylko domyślny designer posiada wygenerowany kod.
Korzystanie z zasobów jest proste, w przypadku atrybutów kod powyżej pokazal jak korzystać – uwaga na ErrorMessageResourceType i ResourceType. Natomiast w przypadku razora, z którego ja aktualnie korzystam wygląda to tak:
W przypadku l> pamiętamy o wcześniejszym using. I tyle, pozostaje tylko dodać tłumaczenie wszędzie i będzie po krzyku.