Naucz się języków programowania takich jak Python, Rust, C# oraz innych z tym nowym bundlem książek w formatach PDF, ePUB i MOBI!

#technologia #programowanie #ksiazki #humblebundle

#heheszki #memy #humorobrazkowy #ambasadorjeja #programowanie

Wyniki dorocznej ankiety języka Rust

Polacy są w pierwszej dziesiątce użytkowników tego języka!

#technologia #programowanie #rustlang #rust

Zapraszam o 21:00 na strima.

Cos pozmulamy przy kodzie, pogadamy o bocie, obczaimy oferty i czy na rynku juniorow nadal beznadziejna sytuacja. Sprzedam pare sinjor tipów.

#programujzpasterzem #programista15k #naukaprogramowania #javascript #programowanie

https://www.youtube.com/watch?v=DQSG5Xeddh8

Ostatnio wrzuciłem wpis z linkiem do platformera z dwoma poziomami.

Kilka osób zagrało, nawet przeszło więc stwierdziłem że zrobię kolejną, trochę bardziej dopracowaną grę którą będę robić trochę dłużej niż 2-3 dni.

Idea jest taka:

Wcielasz się w postać latającej d⁎⁎y, Twoim celem jest się wysra... yyy, zasiąść na tronie. Strzelasz bąkami z d⁎⁎y: kwiatki więdną, ludki rzygają, itp. Jak dobrze wyjdzie to będzie kilkanaście poziomów i walka z bossami.

Myślę że niedługo będę mieć gotowe demko. Gierka będzie dostępna za free na itch.io.

Dajcie pioruna dla zasięgu.

Poprzedni link: https://vuaaas.itch.io/worst-platformer-ever

#diy #tworczoscwlasna #gamedev #gry #programowanie

Będąc użytkownikiem Rusta, widzę niekiedy wiadomości, jak to nowy projekt zaczyna używać tego języka czy nowy driver w kernelu jest na niego przepisywany.

Pod każdym znajduje się spora ilość komentarzy pozytywnych/neutralnych jak i pewna część negatywnych głównie pochodzących od użytkowników innych niskopoziomowych języków tj. C czy C++.

Oto niektóre powody szkalowania(często słusznego) języka:

• Toksyczna społeczność - głównie chodzi o RIR(Rewrite in Rust) - pisane często pod postami o programach nie napisanych w tym języku - głównie przez osoby nie programujące w Rust, tylko myślące że jest to złoty środek na wszystkie bolączki i błędy występujące w programach.
  

• Niebezpieczny system pakietów - chodzi głównie o to że można próbować ataku polegającego na podszyciu się pod crates.io i zmienić paczki na ich złośliwe wersje. Według mnie taki atak prawie niemożliwy do wykonania, bo np. Cargo.lock posiada w środku hashe paczek, co uniemożliwia użycie podrobionej wersji paczki.
  

• Używanie do wszystkiego obcych zależności - parser cli czy implementacja tls, według niektórych użytkowników powinno to być napisane ręcznie albo przez zrobione przez kopiuj/wklej bezpośrednio do repozytorium. Według mnie to właśnie jest niebezpieczne, bo kopiowanie coś takiego komplikuje proces budowania, wydłuża proces tworzenia aplikacji jak i zwiększa ryzyko błędów/wymusza ciągłą synchronizację(można to łatwo zrobić przy pomocy git submodule, którego jednak niezbyt lubię). Obce pakiety, używane przez setki innych projektów mają zwykle o wiele lepszą jakość, więcej funkcji i mniej błędów niż te ręcznie napisane.
  

• Problemy statycznego linkowania - jeśli jakaś zależność np. openssl, będzie miała błąd który będzie naprawiony w nowej wersji, to gdy jest ona dynamicznie linkowana trzeba tylko ją przekompilować a w przypadku rusta całą aplikację - głównie jest to podnoszone przez ludzi zarządzających dystrybucjami, bo wiąże się to ze zwiększonym wysiłkiem.
  

• Problemy z pamięcią to tzw. skill issue i dobrzy programiści nie robią ich prawie wcale/mnie się one nie zdarzają choć już kilka lat programuję w C/C++ - setki tysięcy programistów używają C/C++ i naturą ludzką jest popełnianie błędów a te języki pozwalają odstrzelić sobie stopę w najbardziej wymyślny sposób w zupełnie losowym momencie(problemy z pamięcią często objawiają się z opóźnieniem). Wymagają od użytkowników trzymania dużej ilości informacji o kodzie w swojej głowie, co oczywiście nie jest idealne i problemy ze zrozumieniem kodu/jego poprawną zmianą pojawiają się przy zmiany osoby używającej program czy po dłuższej przerwie od danego kawałka kodu. W przeciwieństwie do C i podobnych niskopoziomowych języków, kompilator Rust traktuje użytkowników z dystansem(można powiedzieć że jako debili - ale w pozytywnym tego słowa znaczeniu(jeśli oczywiście takie jest)) i wymusza określony styl i praktyki, no chyba że zmienimy to przez unsafe. Pozwala to zwykłym użytkownikom tworzyć szybko działające programy, bez bania się o wszędzie czychające problemy z pamięcią, jak i przychylniejszym okiem patrzyć na pull requesty, bo szansa na zepsucie kodu jest o wiele mniejsza. Z tego co zauważyłem to programiści C, często uważają się za pewną elitę, bo przecież nie każdy potrafi robić to co oni. Wystarczy zobaczyć https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory, by zauważyć że zbyt wiele programów rozwijanych przez bardzo wykwalifikowanych programistów ma problemy z pamięcią i że to raczej nie problem ich zbyt małych umiejętności. No a jeśli to problem zbyt małych umiejętności, to większość programistów powinna unikać jak ognia C skoro jest on przystosowany jedynie dla najbardziej zaawansowanych.
  

• Długa kompilacja i biorąca dużo zasobów systemowych - Rust z racji ilości koniecznej weryfikacji wszystkich parametrów, typów, lifetimów etc. bierze o wiele więcej zasobów systemowych i czasu niż c czy np. go, więc do kompilacji lepiej zaopatrzyć się w mocniejszy komputer
  

• Brak dostępności na wszystkich platformach gdzie C jest dostępny - C jest chyba najbardziej przenośnym językiem na świecie(w ilości kompilatorów na różne platformy sprzętowe), wiec trudno by z nim konkurować. Rust wspiera najbardziej popularne systemy bazujące na ARM, x86-64 i wielu innych architekturach wspieranych przez llvm, ale obecnie nie ma oficjalnego wsparcia dla alpha, hppa, ia64, m68k czy s390. Problemem dużym to nie jest bo dotyczy zapewne grubo mniej niż 1% wszystkich użytkowników i to tych, którzy pracują na antycznym/mniej popularnym sprzęcie.
  

• Jest o wiele trudniejszy niż C/C++ - składniowo na pewno na pierwszy rzut oka nie wygląda zachęcająco, jednak z doświadczenia muszę powiedzieć że programuje się w nim o wiele szybciej niż w powyższych językach, bo nie muszę polegać w wielu przypadkach na sobie, tylko na kompilatorze. C jest dość prosty pod względem składni, ale bardzo trudnym gdy chce się go poprawnie używać, głównie przez to że bezpośrednio operuje się na pamięci. C++ z wersji na wersji próbuje stać się językiem bezpiecznym, jednak ciągnie się za nim szereg funkcji ze starszych wersji i problemów, które po prostu nie mogą zostać naprawione bez gruntownej modyfikacji języka.
  

• Rust rozwiązuje tylko problemy z pamięcią a ich nie robię - cóż, jeśli nawet to prawda(w co szczerze wątpie, jeśli używasz C/C++) to przynosi on szereg przydatnych funkcji, tj. ograniczenie wyścigów o dane, ujednolicenie formatowanie kodu(rustfmt), oficjalny system budowania(cargo), wymuszanie obsługi wszystkich sytuacji w match (switch w C/C++), przyjazne komunikaty błędów - bardzo często z kodem który można zrobić kopiuj/wklej i naprawić problem.
  

Jak widać Rust nie jest złotym środkiem na wszystko ale wprowadza kilka niezłych usprawnień w stosunku do C/C++, jednak jak widać części ludzi nie jest tym przekonana. C/C++ jak widać po np. statystykach na githubie nigdzie się nie wybiera i ciągle miliony linii kodu będą w tych językach pisane, jednak z roku na rok, coraz większe grono języków zaczyna je podgryzać.

#programowanie

#rustlang

#rust

As ⟨ÿ⟩ rarely appears as the first letter in a name, and all-caps text typically omitted all accents, initially there was assumed to be no need for an uppercase ⟨Ÿ⟩ when computer character sets such as CP437 and ISO 8859-1 were designed. However much software assumes that conversion from lower-case to upper-case and then back again is lossless, so ⟨Ÿ⟩ was added to many character sets such as CP1252, ISO 8859-15, and Unicode. This also happened to a more prominent character, the German ß.

W ogóle co do ß to ciekawostka, text-transform zmienia je na SS, bo jakaś reforma była czy coś jest w niemieckim, że capsie ten znak zawsze jest SS a nie "normalnie" pisany.

#programowanie #webdev #frontend #css

Pracuję od jakiegoś czasu w projekcie, w którym kiedyś podjęto decyzję, aby tworzyć interfejsy dla serwisów.

Przykład: mamy interfejs HejtoService i dla niego jest implementacja HejtoServiceImpl - i generalnie wszystkie publiczne metody implementacji muszą pokrywać się z tym co jest w interfejsie.

I tak 99% klas ma i zawsze będzie miało tylko jedną implementację - bo zawsze jak zmieniają się wymagania, to modyfikuje się implementację, a nie dopisuje kolejną.

No i później wchodzę do jakiegoś pakietu i mam tam np. 10 plików (5 implementacji i 5 interfejsów) - ciężej cokolwiek znaleźć, ciężej nawigować po drzewku projektu - bo zwyczajnie jest 2x więcej plików.

Dodatkowo chcąc przejść do implementacji danej metody (z miejsca, z którego została użyta), zawsze muszę przejść przez interfejs.

Przykład:

ServiceAImpl -> ServiceB -> ServiceBImpl -> ServiceC -> ServiceCImpl

vs

ServiceA -> ServiceB -> ServiceC

Debugując jest identycznie.

Żebyście mnie nie zrozumieli źle, ja lubię używać interfejsów, tam gdzie faktycznie widzę ich zastosowanie. Np. kiedyś kodowałem jakieś generowanie raportów, wykresów, czy czytanie z pliku - gdzie mamy różny format plików, albo przedział czasowy - i tam interfejsy pasują mi idealnie i widzę ich zastosowanie.

No i mam pytanie, po co tworzyć takie interfejsy? Pytam całkiem poważnie i proszę o proste wyjaśnienie, bo dla mnie nie wprowadzają niczego pozytywnego.

#java #programowanie #kiciochpyta

()

#datascience #programowanie #heheszki

Z czego korzystacie do testowania rest api(głównie chodzi o fuzzer lub coś w tym stylu i to lokalnie, bo chcę to automatyzować bez dostępu do świata)?

Używam serwisów napisanych w pythonie (pydantic + fastapi) i rust (actix + utoipa)

Obecnie korzystam z:

• https://github.com/matusf/openapi-fuzzer - działa tylko dla rustowego openapi, bo fastapi bazuje na jakimś starym dokumencie gdzie niektóre wartości mają inne typy niż walidatory oczekują i przez to się wysypuje. Problematyczne jest to że więcej logiki do weryfikacji mam właśnie od strony pythona i to właśnie chciałbym bardziej testować
  

• https://github.com/Endava/cats - ciekawy projekt, który ignoruje część błędów w schemacie openapi i pozwala na testowanie nawet niepoprawnego schematu. Działa na początku całkiem dobrze, bo znajduje najbardziej podstawowe błędy, jednak z czasem widać że celuje on bardziej w implementację testowania takich programów jak uvicorn/fastapi a nie samego programu użytkownika(np. jest masa fuzzerów które wysyłają śmieci w nagłówkach, dane z niepoprawnym kodowaniem etc.), a mnie interesują tylko dane które w miarę poprawne mogą zwrócić nieoczekiwany wynik
  

Poszukuję czegoś "myślącego" albo dającego takie pozory, by znaleźć błędy które powyższe programy pomijają i muszę ręcznie błedy te wyszukiwać, np. sytuację w której dodaję użytkownika i za pomocą zwróconego uuid kontynuowany jest proces testowania api

jakieś inne programy też testowałem, ale odbijałem się od nich bardzo szybko, bo trudno było je używać albo i nawet zainstalować

#programowanie

#naukaprogramowania

Naszym zadaniem jest tworzenie technologii obliczeniowych, tak aby nikt nie musiał już programować, a językiem programowania był człowiek: każdy na świecie jest teraz programistą – to jest cud.

- Jensen Huang, CEO firmy NVIDIA

Źródło: https://blogs.nvidia.com/blog/world-governments-summit/

#wiadomosciswiat #programowanie #programista15k #artificialintelligence #sztucznainteligencja #nvidia

Niedziela popołudnie a ja w pracy... bo debile ddosują "nasz produkt".

1.2mln requestów na 5 minut, czyli ponad 3k requestów na sekundę... I tak od 8 godzin.

A ja jem se chipsy i batony, bo mamy WAF, więc nam to lotto Ale obserwować trzeba.

Ale nie powiem, na początku dobrze nas zddosowali, poprzez serwery amazona, google, azure, digital ocean i alibaba cloud (alibaba ma serwery w US równiez 0_o )

#programowanie #siecikomputerowe #gownowpis

Potrzebuję stworzyć prosty system logowania do serwera i dostępu do jego zasobów, który oczywiście powinien być bezpieczny, ale w miarę łatwo implementowalny.

Jako że nigdy się w aplikacjach warstwą sieciową nie zajmowałem, to mam problem ze znalezieniem odpowiedniej metody.

Na internecie jest masa poradników jak to zrobić, ale oczywiście dotyczą różnych frameworków jak i różnych metod(tokeny, sesje), więc akurat nie wszystko kojarzę.

Z tego co wnioskuję logika powinna wyglądać w ten sposób:

• W bazie użytkownika zostaje dodane login + posolone hasło
  

• Użytkownik próbuje zalogować się do serwera, więc w zapytaniu przesyła w body login + hasło
  

• Serwer weryfikuje czy w bazie dane się znajdują, jeśli tak, to generuje token przy pomocy sekretnego klucza, w którym wewnątrz jest zapisany login użytkownika i czas wygaśnięcia i zwraca go użytkownikowi
  

• Użytkownik otrzymuje klucz i następnie do każdego zapytania api dodaje go do nagłówka Authentication
  

• Serwer po otrzymaniu zapytania, sprawdza nagłówek i odpakowywuje login i czas wygaśnięcia tokena, jeśli token jest ciągle ważny, to wykonuje daną operację, jeśli nie to zwraca błąd
  

• Serwer dla każdego zapytania wymaga tego tokena(oczywiście oprócz resta do logowania)
  

Czy moje rozumowanie jest poprawne?

#programowanie

#naukaprogramowania

he he he ( ͡° ͜ʖ ͡°)

#informatyka #humorinformatykow #programowanie #linux

https://guthib.com/

#heheszki #programowanie #humorinformatykow

Ostatnio miałem małą przygodę ze Swiftem i chcę to powtórzyć, wspaniały język programowania, polecam każdemu

#programowanie