Redirect to anchor w asp mvc

Od jakiegoś czasu pracuje za prawdziwe złoto jako sieciowy programista, dawno nikt nie wymagał aby po przekierowaniu wrócić do jakiegoś specyficznego kawałka strony. Zawsze kończyło się przekierowaniem do pełnej. Zapomniałem już o takiej funkcjonalność, no prawie zapomniałem. Otóż klepiąc sobie coś tam w domu, chciałem po zrobieniu POSTa wrócić gdzieś na dół strony, akcja nie korzysta ze zdobyczy technologi jaką jest AJAX, więc strona się przeładowywuje. Pozostało mi tylko skorzystanie z elementu html, który posiada znacznik id oraz nawigacja do strony z podaniem tego znacznika w url. Znacznik podaje się po znaczku ‘#’. Kompilator nie chciał tego przyjąć do wiadomości, gdy próbowałem zrobić this.RedirectToAction(“Index”,”Home”,new{#=”comments”}); nie działało.
Na szczęście internety dają radę także i tym razem super hero w postaci stack overflow ułatwił życie.
Uwaga podaję odpowiedź:
this.Redirect(Url.RouteUrl(new { controller = “Home”, action = “Index”}) + “#comments”);
To tyle w tym krótkim odcinku. Jutro znowu do pracy.

A jak Pan klei stringi?

Człowiek idzie na rozmowę o pracę i pytają go o różne rzeczy, najczęściej pytają o to czego i tak nie będzie korzystać w tej pracy. Np, ile piłek golfowych mieści się w autobusie, czy ile jest okien w wąchocku, chociaż w takimi rzeczami lubi się parać HR. Nasi pytają o wzorce, gdzie najczęściej pada odpowiedź singleton i/lub fabryka. Wcześniej może zapytają o różnicę pomiędzy value type i reference type i kolejny klasyk to konkatenacja stringów. Każdy kto był chociaż na jednej rozmowie odpowie StringBuilder.
Jak często zdarza się wam łączyć taką ilość stringów, że tworzycie StringBuildera, żeby rzeczywiście było szybciej?. Ja chyba nigdy nie byłem (albo już nie pamiętam) w takiej sytuacji, ale zawsze mnie o to pytają. Po jednej z takich rozmów zacząłem rozmyślać co robię w takich sytuacjach, gdy mam kilka stringów do sklejenia, czy korzystam z łączenia stringów i o matko alokuje tworze ich kilka w pamięci raz na kilka sekund czy może tworze owego magicznego wszech potężnego Buildera, aby uratował mnie przy klejeniu “Ala ma 1 kota, koloru szarego“. Uświadomiłem sobie, że praktycznie zawsze korzystam ze string.Format. I co teraz? A jeśli on jest źle zaimplementowany i chłopaki z mikrosoftu kleją stringi jak przedszkolaki? Nie mogłem spać po nocy i musiałem sprawdzić. Dot peek na ratunek, sprawdziłem i jest pięknie, jestem uratowany, jest bohater, w środku siedzi StringBuilder i robi swoje. Także jeśli jesteście ciekawi co jest szybsze czy string.Format czy nowy StringBuilder to sprawdźcie sami. Ja w każdym bądź razie od teraz będę na rozmowach mówić, że korzystam ze string.Format().
Tyle, ot taki krótki wpis.

Czemu bugi są jak wino, im starsze tym droższe.

Każdy z nas/was słyszał o tym, że naprawienie buga z czasem staje coraz droższe, a jak kod pójdzie na produkcje to już w ogóle wszystko drożej miliard razy. Każdy słyszał, ale czy ktoś zdaje sobie sprawę czemu tak się dzieje?
Mi wydaje mi się że wiem i chce się tą wiedzą podzielić, także posłuchajcie pewnej bajki o remoncie mieszkania, a może znajdziecie analogie do IT, a przy okazji może podpowiecie jak dobrze zainstalować progi w mieszkaniu.
Pewnego razu, pewien programista zapragnął mieszkania, takiego pięknego mieszkania, a w nim pomalowanych ścian i sufitów, kafelek i paneli. I chciał (on – programista) aby to ładnie było w nim (tym – mieszkaniu). Słuchy chodziły, że inni koledzy z fachu tego samego już maja takie cuda i że ładnie u nich. Poradził się więc do kogo pójść, aby piękna takie i w jego domu zagościły.
Gdy wszystko już się ustaliło i zrobiło, złoto przeszło z ręki do ręki, wprowadził się on ze swoją białogłową i ich kwiatem miłości do nowego pałacu.
Ich zdziwieniom i radości z posiadania własnego miejsca nie było granic. A w zasadzie były i dosyć szybko się skończyła piękna radość. Pomijając większe i mniejsze odstępstwa od umowy/jakości. Skupię się w tej bajce na rzeczy, która może się wydać wręcz śmieszna, a taka nie jest.
Otóż oto przedmiot wywodu mojego:
Próg

Śmiechy i chichy teraz cichną i lecimy dalej. Otóż piękne plany, które snuliśmy to ograniczenie progów do minimum. Tutaj nastąpił kontakt z rzeczywistością:
Jak to bez panel bez progów, muszą być!
Nieświadomi wiedzy pokiwaliśmy głowami, jak muszą to muszą – fachowiec wie. 0:1 dla niego, bo tak naprawdę to nie muszą.
Gdy w mieszkaniu byliśmy i mieszkaliśmy, naszła nas taka fanaberia, żeby drzwi posiadać, bo czasem warto się zamknąć w jednym z nich i spokój mieć. Progi jednak spokoju nam dać nie chciały. Trzeba było je poprawić. Pewnego weekendu, postawiłem się zebrać i poprawić to co nas boli. Zerwałem progi, tu i tam razem z panelu kawałkiem, ale to nie problem, da się to zakryć nowymi, bardziej płaskimi ale też trochę szerszymi. Aż tak to nie boli. Przy pierwszej próbie założeniu nowego progu okazało się, że nie pasuje i trzeba trochę poprawić

Gdy już przy pomocy próbnika i pilnika dopasowałem szczelinę, tak aby nowy, właściwy próg pasował, wiedziałem że poprawką dwóch następnych na pewno nie zajmie im chwileczki.
Drap drap, szlif szlif udało się zrobić tak, że próg 2.0 pasował do szczeliny 1.0, co mniej więcej wyglądało tak:

Na internetach znana jest taka oto przyśpiewka:

99 little bugs in the code

99 little bugs in the code
Take one down, patch it around
117 little bugs in the code

A wiadomo, tradycja rzecz święta, także tego:

Gdy i tutaj udało mi się dopasować szczelinę do próbnika, okazało się że próg 2.0 nie jest aż tak kompatybilny ze szczeliną i należy wprowadzić drobny tunning sprzętowy:

Wreszcie, gdy wszystkie szczeliny 1.0 zostały spasowane z progiem 2.0, mógł nastać czas relesu. Ale! Przecież jeszcze drzwi. Ktoś opowiadał, że progi po drzwiach, hmmm. Tutaj uratowało nas szczęście, postanowiliśmy zaczekać na monterów ościeżnic i drzwi, co okazało się dobrym posunięciem, bo “progi po drzwiach” – tak rzekł pan montujący.

Ja spędziłem cały dzień, zrywając starą wersję progu, dopasowując szczelinkę i dopasowując nowe progi, Nie mogłem zdjąć podłogi i normalnymi narzędziami ściąć wystających elementów. Nie posiadając także narzędzi czy jakieś specjalistycznej wiedzy (w zasadzie nic szczególnego wiedzieć nie trzeba, ale zawsze) musiałem wprowadzić zmiany już w istniejącym systemie. Ok dałem rade, będzie działać, nauczyłem się pewnie paru rzeczy, ale zajęło mi to dzień – a muszę jeszcze dopasować progi do ościeżnic.
Gdyby od razu zrobić dobrze, tak że nie trzeba by w ogóle poprawiać, mając możliwości do manewrowania panelami, mając narzędzia to zamiast całego dnia, moją robotę można zrobić w pięć minut. W dodatku nie doszło by do uszkodzenia materiału, czy kupowania czegoś co nie pasuje i trzeba to wyrzucić.

Wszystkim czym mogę i jak mogę podpisuje się pod tym obrazkiem.
PS.
Jestem po releasie na produkcje, ale syf. Jestem strasznie nie pocieszony tym, jak mi poszło. Nie wiem czy nie będzie trzeba robić, kolejnego fixa i znowu robić releasa na produkcje, z programi 3.0.
Czas pokaże. Mam nadzieję, że teraz już będziecie wiedzieć, czemu im później tym drożej.

ToBeImplemented reboot

Projekty które robi się dla siebie mają pewna cechę, która jednocześnie jest czymś dobrym i złym. Taki pet-project można rozpoczynać milion razy i nikt nie robi z tego powodu afery – to plus, po milionowym rozpoczęciu szanse na zakończenie są małe – to minus.
Ja właśnie zwiększyłem cyferkę do 3, na szczęście nadal chce mi się to pisać. Rozpocząłem od nowa, bo strasznie pokomplikowałem sobie aplikację, to raz, i przy próbach prostowania doszedłem do wniosku, że chyba szybciej będzie napisać to jeszcze raz, bez takiej ilości magicznego pyłku, który użyłem wcześniej. A dwa, że nauczyłem się paru nowych rzeczy, które chciałem tutaj wykorzystać.
Tym sposobem zmierzam do warstw. O ile wcześniej dzieliłem projekt na proste części:


Jak widać, szaleństwa nie ma. Aplikacja (ASP MVC) korzysta z serwisów, serwisy z bazy oraz czasem z samych siebie (oczywiście przez interfejsy).
Ok, w zasadzie nie ma się czego czepiać, tak/nie? Mogło być lepiej, mogło być gorzej. Zamiast sześciu żółtych prostokątów, mógł być jeden. Zawsze powtarzam, że nie wolno porównywać się gorszym, pozostaje więc tylko czepiać się i szukać miejsca na poprawki.
Co skusiło mnie to tego, żeby to zmienić? W serwisach było w zasadzie wszystko co nie jest związane z bazą danych i z samym mvc, czyli: logika, mapowanie z model na view model, maile, hash, konta użytkowników, blablablabla, wszystko.
Czy to dobre? It depends. Jeśli robi się mały prosty projekt (taki książkowy), to może będzie to dobre rozwiązanie, jeśli robi się nowego fejsbuka to raczej nie, a przypominam, że już nie długo moja aplikacja zajmie jego miejsce – widzę i słyszę wasz śmiech, zobaczymy kto będzie się śmiać ostatni!

Co takiego pozmieniałem w swoim rozwiązaniu? Warstwy, więcej warstw, znacie to przysłowie, że każdy problem da się rozwiązań dodając kolejną warstwę abstrakcji?
Razem z tym zmieniłem także troszkę podejście do rozwiązywania zależności, które tworzę, wygląda mniej więcej tak:

Największe zmiany to wiele aplikacji które są wspierane, robię to żeby sprawdzić jak długo można utrzymywać wspólny kod, na razie bez cross-platform.
Idealnie jest aby aplikacje były maksymalnie lekkie, cała logika jest przeniesiona do części Bussines, która wykonuje właściwą pracę. W przypadku aplikacji WPF są jej dwa warianty, jeden oparty o Application.REST, drugi który referuje bezpośrednio do Bussines i działa “natywnie”.
Dodatkowo ważny jest brak zależności w poziomie, tzn. serwisy nie mogą zależeć od serwisów, infrastruktura od infrastruktury, czy biznes od biznesu. Poszczególne klasy w danej warstwach muszą być samodzielne, jeśli ma się pojawiać jakaś zależność, oznacza to że klasa chce wziąć na klatę zbyt dużą odpowiedzialność i że jest źle.
Prawdę mówiąc, jestem dopiero na początku tej drogi i wiem, że pojawią się bloczki (już są), które będą specyficzne dla poszczególnych aplikacji, ale jestem na to gotowy i na aktualnym stopniu mojej znajomości naszej programistycznej domeny jestem w stanie to zaakceptować.

TL;DR:
W projektach gdzie zależności są poziome, np. serwisA zależy od serwisuB są, złe. Dwa powody: może to prowadzić to zależności cyklicznych, oraz oznaczać to może, że jeden z nich ma za dużą odpowiedzialność, ponieważ część pracy przekazuje do sąsiada o którym nie powinien wiedzieć.
Słowo motywujące na dziś: nie bój się eksperymentować!

Ciekawy moich postępów czy rozwiązań, aktualny projekt możesz znaleźć tutaj:
https://jstadnicki.visualstudio.com/DefaultCollection/_git/ToBeImplemented
https://github.com/jstadnicki/tbi

Do dzieła!

Ach święta, czas jedzenie i nie policzalnych kalorii. A gdy ktoś ma szczęście, to także czas błogiego programowania bez żadnych zobowiązań. To także czas kiedy można przysiąść i poczytać. Udało mi znaleźć chwilę i posiedziałem, czytałem i czytałem i nie mogłem przestać, bo ciągle nie miałem rozwiązania swojego problemu. Chciałem zaimplementować “Owin Identity” w asp mvc, a w internetach chciałem znaleźć rozwiązanie podane na talerzu. Spędziłem cały dzień wpisując coraz to różne i kombinacje słów “owin, identity, mvc, asp” i wiecie co, nie znalazłem niczego więcej niż w ciągu pierwszych trzech minut. Ciągle chciałem znaleźć te talerz i rozwiązanie na nim. Koniec końców, przeczytałem to co było, włączyłem VS z przykładowym kodem gdzie jest wykorzystany OWIN oraz logowanie i zacząłem właściwą pracę poznawczą – programowanie. Miałem jeden projekt wzorcowy, oraz osobny gdzie chciałem to ponownie zaimplementować. Wykorzystując starodawną metodę kopiowania i zrzynania działającego kodu, przenosiłem powoli funkcjonalność z przykładu do celu, aż wreszcie miałem podstawową funkcjonalność. Moja radość nie trwała wiecznie, kod trzymałem na ramdrive, żeby się to wszystko szybciej kręciło. Chwilę po tym jak skończyłem naukę musiałem zrobić reboot, jakie było moje zaskoczenia gdy się zorientowałem kilka godzin mojej pracy poszło się. Może nie wyglądało to aż tak tragicznie:

A wiecie czemu, bo zostało mi w głowie z więcej niż z samego czytania blogów czy tutoriali. I wiecie co zacznę robić za chwilę? Napiszę to jeszcze raz i jeszcze raz, a każdym razem będzie to zrobione lepiej i lepiej.
Przestań liczyć na to, że znajdziesz idealne rozwiązanie swojego problemu na sieci, napisz je sam. Jeśli nie uda się za pierwszym razem, to na pewno za drugim, albo za trzecim, a już na pewno na czwartym. A jak nie to na pewno będziesz wiedzieć co zrobiłeś nie tak i następnym razem zrobisz to lepiej.
TL;DR;
Przestań czytać, zacznij pisać kod.