Jaki macie stack technologii w pracy?

0

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.

0

docker core vue wczesniej angular, ale krotko.

0

WCF, XML, itd.

0

.NET Core 2.2, Angular 8, Docker, RabbiMQ

0

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)

3
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?

0

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.

0

Python, Julia, AWS (Lambda, s3, ec2, sagemaker), Tensorflow, Pytorch, Pandas, SQL

0

.NET Core, EF Core, Docker, Kubernetes, Helm, Azure, ElasticPool(MS SQL). Angular

0

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.

0

.NET, WPF, WF, PL/SQL, VBA

0

NET, .NET Core, WCF, RabbitMq, SQL Server

3

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] **

  • clojure (prosty dynamiczny kompilowalny funkcyjny lisp z niezłym wsparciem do programowania współbieżnego, programowania zorientowanego wokół REPL i dostępem do bibliotek javy)
  • ring (abstrakcja dla obsługi http, gdzie wszystko to funkcja, ich kompozycja podczas, gdy request i response to hash mapy)

[front]

  • clojurescript (clojure po stronie przeglądarki, zgrywa się z JS - ostatnio integrowałem DraftJS i poszło nieźle. Poza tym nie muszę używać reduxa, immutablejs a ostatecznie uzyskuje ten sam efekt, tyle że szybciej i lepiej)
  • async.core (wprowadza goroutines jak w języku Go, umożliwa prosty zapis współbieżnych działań po stronie JS)
  • rum (nakładka na reactjs, wg mnie 100 razy prostsza i lepsza niż surowe api od facebooka)
  • devcards (pozwala mi wydzielić komponenty, generuje mi strony do podglądu by sprawdzić jak komponent działa w izolacji)
  • figwheel (odpowiada za hotreloading i REPL po stronie przeglądarki)
  • kompilator google closure - jest pod spodem (używany w produktach google), wycina nie używany kod i redukuje końcowy rozmiar plików js

[bazy]

  • postgresql
  • redis

A w planach:

  • jesień: rum + react native
  • mniej więcej do roku: datomic (na razie do eksperymentów, a potem może na serio); koszt za licencję jest duży, ale to i tak sporo mniej niż roczna pensja programisty

DLACZEGO?

  1. 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.

  2. 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ść.

  1. DOPASOWANY DO MNIE: Uwielbiam dynamiczne języki. Uwielbiam je, bo są 100 razy prostsze w użyciu niż c++ i java, dają szybki feedback i pozwalają pisać oprogramowanie w lżejszy sposób.

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 :-)

  1. SPOŁECZNOŚĆ: Możliwe, że społeczność powinniem wymienić jako numer 1, bo gdyby nie ona to nie dostrzegłbym tylu zalet clojure.

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.

0

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

0

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.

0

c# 5.0, wpf, geometria obliczeniowa

0

Backend:

  • .Net Framework (niestety jeszcze nie Core)
  • Topshelf
  • NancyFX
  • MSMQ i Rabbit MQ
  • NServiceBus
  • SQL Server i Event Store

Front:

  • React
0
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 ;-)

0
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.

0

.NET, ASP.NET MVC 5, NHibernate, JS, SQL Server, WCF, ELK stack, Octopus, TC, Redis.

0

Xamarin, SQL Server, ASP.NET Core, .NET, WinForms, trochę WPF i troszeczkę Unity

0
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?

1

Ja zostawiłem nowe technologie pijącym migdałowe latte hipsterom w rurkach. Fajnie patrzeć jak się potykają o własne nogi.

1

Najczęściej wystarczy zapytać o 2 rzeczy:

  1. jakie problemy nowa technologia rozwiąże (lub pomoże rozwiązać)
  2. jakie problemy dołoży

Zazwyczaj kończy to rozmowę.

Uprzedzając, nie jestem przeciwnikiem innowacji ;)

0 użytkowników online, w tym zalogowanych: 0, gości: 0