Języki, frameworki, wzorce, strategie i technologie które na co dzień używacie w pracy jako programiści .net
mvc, api, ddd, cqrs, rabbitmq, docker, clean architecture, react, angular, R, Unity itd.
Języki, frameworki, wzorce, strategie i technologie które na co dzień używacie w pracy jako programiści .net
mvc, api, ddd, cqrs, rabbitmq, docker, clean architecture, react, angular, R, Unity itd.
docker core vue wczesniej angular, ale krotko.
WCF, XML, itd.
.NET Core 2.2, Angular 8, Docker, RabbiMQ
ja bym tu jeszcze dodał zarobki bo mnie ciekawi ich zależność do zbioru technologii :)
a co do tematu ja tam w C# nie mam projektu, choć z przymusu czasem w nim cos koduje to mamy .NET, Angular 4, Entity Framework - raczej prosty stack bo i aplikacja jest raczej niewymagająca (póki co)
WeiXiao napisał(a):
docker core vue wczesniej angular, ale krotko.
Miałbym prośbę; czy zechciałbyś napisać coś więcej na temat dlaczego VUE zastąpiło Angulara?
Dotnet Core, Angular, Dapper, RabbitMQ, Docker, SignalR, Redis
Aż czasami w domu odpalam projekt w ASP.NET MVC 5 żeby nie odpłynąć za daleko od szarej rzeczywistości.
Python, Julia, AWS (Lambda, s3, ec2, sagemaker), Tensorflow, Pytorch, Pandas, SQL
.NET Core, EF Core, Docker, Kubernetes, Helm, Azure, ElasticPool(MS SQL). Angular
Jeden projekt: UWP, ASP.NET Core 2.2, WebAPI, MVC, EF Core, Docker, Xamarin.Forms... oraz C i C++ (embedded). Oraz Azure Dev Ops.
Drugi projekt: Xamarin, Azure, Python, Pandas.
Trzeci projekt: Unity.
.NET, WPF, WF, PL/SQL, VBA
NET, .NET Core, WCF, RabbitMq, SQL Server
Wydaje mi się, że podawanie samego stacka dla samego stacka jest trochę z szarej dziury. Jak ktoś pracuje w takim a takim stacku niech chociaż powie z czego to wynika.
U mnie np jest tak:
**[backend] **
[front]
[bazy]
A w planach:
JESTEM SAM: Ogólnie pierwszy motyw jest mniej programistyczny, a bardziej zawodowy. Chodzi o to, że etat i zlecenia odchodzą u mnie do lamusa. Mam dość przypadkowych okoliczności (tzn przypadkowy zespół, przypadkowy kod i przypadkowy zarząd). Moje ambicje chcą ugrać coś większego niż miesięczna wypłata za dupogodziny. Z drugiej strony jednak nie stać mnie na własny (nawet mały) zespół programistyczny więc ostatecznie jestem sam i w zasadzie wszystko jedno w czym zrobię całe oprogramowanie. Rzucenie etatu to był bodziec, który pozwolił mi skupić się na tym co rzeczywiście uważam za warte uwagi, inaczej nadal klepałbym w python/javascript a clojure ciągle byłby tylko w strefie pet projektów.
JEDEN JĘZYK: Chociaż znam kilka języków to nie chcę pisać projektu w kilku językach, bo w przypadku kilku produktów ciężko będzie mi z tym połapać. W clojure (chociaż nie jest to zawsze takie łatwe) mogę zrobić front, backend, apki mobilne. Mogę pisać zwyczajnie, reaktywnie, asynchronicznie i wszystko da się ze sobą przeplatać tak jak tego potrzebuję. W moim przypadku używanie clojure dawno by się skończyło, gdybym nie mógł korzystać z javascriptowych i javowych bibliotek.
Potencjalnie mogłem startować z tym co znam: python i javascripty (tak też robiłem), ale z czasem poznałem clojure i widzę dramatyczną różnicę w czasie i jakości. To nie tylko prosty język, ale przede wszystkim potężny, ponieważ łatwo mogę zintegrować biblioteki javy i javascriptu w jedną całość.
W pracy to mogę sobie dłubać w c++/java za dupogodziny i też wolę mieć 2-4 razy więcej kodu ubezpieczonego typami, defensywnym podejściem, testami, by się mniej denerować, bo nigdy nie wiadomo kto co zrypie.
Natomiast w moich projektach potrzebuję uzyskiwać odwrotny stosunek, czyli 2-4 razy mniej kodu i jak najmniej abstrakcji, bo w lisp to język wiele jej dostarcza. Zamiast abstrakcyjnych typów, wolę mieć kolekcje i funkcje, które mogę ze sobą łączyć na sto różnych sposobów. Dużo przywiązuje uwagi do konwencji i intencji jakie mam w kodzie niż do wzorców. Wiadomo tak potencjalnie może powstać więcej błędów, ale tutaj decydującym czynnikiem jest to jak prosty i spójny jest kod więc do pewnego limitu takie podejście jeszcze się zwraca :-)
Poza tym w społeczności clojure fajne jest to, że panuje tutaj tendencja do tworza małych i konkretnych biblioteki. Niby projekt wydaje się porzucony (brak nowych commitów), a tak naprawdę projekt jest już skończony (jak obraz, który i tak można by w nieskończonośc ulepszać). Podoba mi się to, że mogę wziąć herbatę i wieczorem przeczytać całą bibliotekę. To jest spoko sprawa, gdy wiesz, że ludzie tworzą kod jak dla ludzi. Dlatego nie obawiam się sytuacji, w których autor biblioteki ot tak zniknie.
back-end:
php 7 (slim framework + eloquent (niestety)), python (flask, tensorflow, dlib), cos tam mamy w golang, rabbitmq, postgresql, mercure, docker, ansible, java jesli chodzi o czesc mobile (tylko android), nodejs + puppetter
front-end:
angular 7.x + material design, server-sent-events + tysiace innych libow/komponentow :D
Netcore, WEBAPI, MVC, EF Core, PostgreSQL, Kafka, Redis, Angular, ELK, Docker, Jenkins, Octopus, Kubernetes. Części z tego nie dotykałem (Octopus, Kubernetes), o części pewnie zapomniałem.
c# 5.0, wpf, geometria obliczeniowa
Backend:
Front:
mar-ek1 napisał(a):
Dotnet Core, Angular, Dapper, RabbitMQ, Docker, SignalR, Redis
Do Ciebie też miałbym pytanie (a może i całą serię) - dlaczego Dappera nie EF.Core?
W sumie, to może być dłuższa opowieść...
Reszta mi się podoba :)
Aż czasami w domu odpalam projekt w ASP.NET MVC 5 żeby nie odpłynąć za daleko od szarej rzeczywistości.
Ale że to lepiej z .NET Core czy gorzej?
Bo się pogubiłem ;-)
wloochacz napisał(a):
Do Ciebie też miałbym pytanie (a może i całą serię) - dlaczego Dappera nie EF.Core?
Pozwolę sobie wtrącić swoją odpowiedź bo również używamy Dappera. Jest to micro-ORM a więc jest lekki i mało kontroluje za nas, więc świetnie się sprawdza w przypadku gdy nie ma się w SQL pełnego modelu domenowego (w sensie encji) a jakieś luźno powiązane tabele. My np. mamy CQRS na poziomie infrastruktury więc modele widoku są budowane asynchronicznie i zapisywane w bazie SQL. Używanie EF czy innego pełnego ORMa było by więc przerostem formy nad treścią. Używamy więc Dappera to zapisywania i wyciągania rekordów a jednocześnie nie musimy się bawić w "ręczne" rzutowanie rekordu z bazy danych na obiekt w pamięci.
.NET, ASP.NET MVC 5, NHibernate, JS, SQL Server, WCF, ELK stack, Octopus, TC, Redis.
Xamarin, SQL Server, ASP.NET Core, .NET, WinForms, trochę WPF i troszeczkę Unity
kzkzg napisał(a):
Netcore, WEBAPI, MVC, EF Core, PostgreSQL, Kafka, Redis, Angular, ELK, Docker, Jenkins, Octopus, Kubernetes. Części z tego nie dotykałem (Octopus, Kubernetes), o części pewnie zapomniałem.
No właśnie, jakie macie podejście do nowych technologi? poznajecie nowe technologie w pracy w razie potrzeby CZY cały czas poznajecie i przypominacie sobie poznane technologie w domu?
Ja zostawiłem nowe technologie pijącym migdałowe latte hipsterom w rurkach. Fajnie patrzeć jak się potykają o własne nogi.
Najczęściej wystarczy zapytać o 2 rzeczy:
Zazwyczaj kończy to rozmowę.
Uprzedzając, nie jestem przeciwnikiem innowacji ;)