Jaro

Lubię eksperymentować z jedzeniem. Jem dużo różnych rzeczy i wypróbowuję też różne diety. Po ostatniej, która miała super wpływać na samopoczucie, poziom mojego cholesterolu poszybował do wartości, których nie uważałem w ogóle za osiągalne. Lekarz ogólny po zobaczeniu wyników i opowieści o moich dietach, na pytanie co powinienem jeść, żeby wyniki wróciły do normy, odparł, że nie potrzebuję żadnych zmian w diecie, potrzebuję leczenia farmakologicznego :). Ale ponieważ dietą się wprowadziłem w ten stan - uznałem, że dietą się z niego sprowadzę na ziemię. Umówiłem się więc do dietetyka. Po konsultacji dietetycznej dostałem zalecenie na temat tego co jeść a czego unikać, ale oprócz tego, dostałem też zalecenie notowania rzeczy, które jem z podziałem na 2-3 godzinne przedziały. Jako człowiek lubiący komputery bardziej niż papier i długopis, poszukałem sobie apki, która by mi w tym pomogła. O ile apki do śledzenia posiłków są dostępne, są jak dla mnie zbyt skomplikowane. Nie chcę musieć wybi

Czy można architekturę aplikacji mobilnej przekształcić na budowę bardziej modułową? W backendzie to zawsze się zwraca ale czy zwraca się w aplikacji mobilnej? Czy warto funkcjonalności pociąć na niezależne moduły skoro używamy ich i tak w jednej aplikacji? Czy ma to sens, żeby chować je za kolejną warstwą abstrakcji? Czy, w końcu, da się to zrobić w sposób wygodny, który nam pomaga zamiast stawać na drodze? Tradycyjne podejście zakłada użycie CocoaPods. Każdy framework ma swoje repozytorium z którego dociągamy źródła i tworzymy projekt z podsami. Wszystko fajnie poza jednym szczegółem, chciałbym móc edytować źródła moich modułów w miejscu, gdzie ich używam i komitować bez dodatkowych czynności, tzn. chciałbym, żeby z punktu widzenia używania kodu fakt, że komponenty są w innym repozytorium, był niewidzialny. Chciałem użyć Swift Package Managera i jego pakietów. SPM w kwestii używania komponentów w sposób przezroczysty również przypomina cocoapodsy, bo mimo, że możesz mieć swój local c

Wywołania asynchroniczne są jednym z elementów bardzo mocno wpływających na budowę całej aplikacji. Często jednak są traktowane jako zło konieczne lub nawet unikane, o ile to możliwe. Jednocześnie sam system iOS oraz składnia języka swift dostarczają narzędzi ułatwiających pracę w środowisku asynchronicznym. Swift, podobnie jak JavaScript asynchroniczne wywołania opiera na callbackach. Oznacza to, że wołając funkcję asynchroniczną, jednym z argumentów jest inna funkcja (lub blok kodu), która ma zostać wywołana, kiedy praca asynchroniczna się zakończy. Mimo, że działanie jest odmienne od wywołania synchronicznego, zapis w kodzie wygląda mimo wszystko podobnie. Na przykład: func synchroniczna() -> String { //jakaś praca w funkcji return "Wynik" } //wywołanie synchronicznej let dane = synchroniczna() print(dane) func asynchroniczna(callback: @escaping (String) -> Void) { DispatchQueue.global().async { //jakas praca callback(&q

Tego nikt chyba nie lubi. Portfel wypchany plastikowymi kartami, ciężko odnaleźć w nim cokolwiek istotnego, ledwo mieści się w kieszeniach a to tylko po to, żeby raz na ruski rok robiąc zakupy móc nabić sobie punkty na rabat kiedyś w dalekiej przyszłości. Jedyną istotną częścią większości takich kart jest kod kreskowy, cała otoczka z plastiku jest dla dziwnie rozumianej wygody klienta.  W przypadku takich kart można zrobić zdjęcie kodu kreskowego i używać go zamiast samej karty. To pomoże odchudzić portfel, za to zrobi bałagan w galerii zdjęć w telefonie. Tu z pomocą wkraczają programy w stylu "karty lojalnościowe".   Chciałem zainstalować sobie jeden z takich programów, ale nie znalazłem niczego dla siebie. Szukając w appstore znajdowałem albo aplikacje, które miały też gazetki sklepowe (których nie potrzebuję), albo takie, które ważyły ze 100MB (czemu tak prosta funkcjonalność zajmuje tak ogromną przestrzeń?), albo nawet ... pozwalały przechować kilka kart i kazały do

“We must all either wear out or Rust out , every one of us. My choice is to wear out .” — Theodore Roosevelt.  Od dawna chciałem to zrobić. Przeglądałem kursy online, czytałem książki, ale jakoś nie umiałem zabrać się za nic konkretnego. Nie miałem pomysłu, a pisanie kolejnego hello worlda nie daje już takiej przyjemności jak kiedyś. Na szczęście pojawił się problem do rozwiązania. Mam dużą kolekcję zdjęć. Podchodzi pod 1TB i ciągle zawiera sporo duplikatów. Usuwam je "na bieżąco" co w praktyce oznacza, że jak mi się przypomni to szukam i usuwam aż się nie znudzę, czyli dość szybko. Mam nawet zautomatyzowany skrypt w pythonie, który je kataloguje i też (przynajmniej w teorii) usuwa duplikaty. Ale wymarzyłem sobie coś innego. Chciałbym program, który przemieli wszystkie pliki, policzy ich skróty kryptograficzne, zapisze w bazie danych i za każdym razem,  kiedy nowy plik będzie tam dodawany - od razu sprawdzi, czy nie było go już wcześniej. Mój dysk sieciowy na któ

Od czasu pewnego incydentu zakupiłem kamery do obserwacji terenu wokół mojego domu. Jedna z nich (pierwsza, jaką nabyłem) jest produkcji firmy Foscam, model FI9900P V1. Niestety moja kamera padła w ostatnim dniu gwarancji. Na szybko ją spakowałem i wysłałem, żeby załapać się na naprawę gwarancyjną. Naprawa trwała ponad miesiąc ale i tak kamera po powrocie nie działała, zupełnie tak samo jak przed wysłaniem.  Postanowiłem zmierzyć się sam z naprawą. Przy braku doświadczenia naprawiania podobnych rzeczy naprawdę trudno jest znaleźć punkt w którym zacząć. W moim przypadku, podłączałem kamerę i obserwowałem wiresharkiem ruch sieciowy, żeby sprawdzić czy kamera próbuje pobrać adres z dhcp (żadnego pakietu nie było), czy skonfiguruje się na adresach APIPA przy braku dhcp, czy w końcu można się z nią połączyć na domyślnym ip. Nic. Kolejnym krokiem był update firmwaru. Skontaktowałem się z firmą foscam, opisałem mój problem i poprosiłem o pomoc. Wysłano mi plik z firmwarem i instrukcje j

Lubię porządne języki programowania a C# z pewnością jest jednym z nich. To moje główne narzędzie pracy. Nie jest to jednak jedyny dobry język programowania na świecie. Kiedy w pracy pojawiła się okazja napisać jeden z naszych serwisów w F#, byłem bardziej niż szczęśliwy. Niektóre projekty były już napisane w C# i przepisywałem je na F#, inne trzeba było pisać od zera. Myślałem, że F# jest tylko kolejnym językiem z dziwną składnią, który robi te same rzeczy w taki sam sposób. Byłem w całkowitym błędzie. Miałem problem z napisaniem metody w interfejsie, potem z zaimpelemtowaniem jej. A potem z użyciem jej w innym miejscu. To wszystko jest tak bardzo inne od C#, że ciężko to wyrazić w słowach. Poza inną składnią obiekty buduje się też i używa w inny sposób (jak choćby to, że w domyśle są niezmienne). Deklaracja metody w C# wszystko mówi o typach już w pierwszej linijce: string method( string param1, int param2) Podczas gdy w F# może wyglądać bardziej jak to: let method param1 p