Jaki macie stack technologii w pracy?

Odpowiedz Nowy wątek
2019-09-10 00:42
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.

Pozostało 580 znaków

2019-09-10 12:40
var
0

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

Pozostało 580 znaków

2019-09-10 12:49
2

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

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

4) 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.

+1. Znaczy samo wypisanie kolejnych trzyliterowych skrótów niewiele daje. BTW, autor chciał "technologie które na co dzień używacie w pracy jako programiści .net" ;) - Ktos 2019-09-10 15:53
Właśnie chciałem też napisać że koledze chyba chodziło o .net tylko, stąd też kategoria forum. Ale nic nie stoi na przeszkodzie założyć temat ogólny. - Aventus 2019-09-10 16:05

Pozostało 580 znaków

2019-09-10 16:19
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

Pozostało 580 znaków

2019-09-10 16:29
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.

Pozostało 580 znaków

2019-09-10 17:16
0

c# 5.0, wpf, geometria obliczeniowa


Java to taki C# tyle że z gorszą składnią.

Pozostało 580 znaków

2019-09-10 19:35
0

Backend:

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

Front:

  • React

Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
MSMQ, współczuję - somekind 2019-09-10 19:41
Nie mam pojęcia czemu do nowego projektu wybrali MSMQ. Mogli oprzeć to o RabbitMQ tak jak inny pod-system. No ale już niedługo to nie będzie mój problem bo w następnym miesiącu zmieniam pracę :) - Aventus 2019-09-10 20:10

Pozostało 580 znaków

2019-09-10 20:06
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 ;-)

no lepiej :D - WeiXiao 2019-09-10 20:07

Pozostało 580 znaków

2019-09-10 20:26
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.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.

Pozostało 580 znaków

2019-09-10 20:48
0

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

edytowany 2x, ostatnio: sharper_99, 2019-09-10 20:49

Pozostało 580 znaków

2019-09-11 16:21
0

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


edytowany 3x, ostatnio: Mondonno, 2019-09-11 16:24
Co robicie w xamarinie? Jestem ciekaw czy używa się go do bardziej skomplikowanych aplikacji mobilnych. - Aventus 2019-09-11 16:36
Tak używa się go do tworzenia skomplikowanych aplikacji mobilnych, jeśli chcesz się coś nie coś załapać w Xamarin polecam ci blog/kurs: http://na-macu.pl Mojego autorstwa :) - Mondonno 2019-09-11 16:39
Xamarin daje duże możliwości ponieważ można w nim robić w jednym rozwiązaniu aplikację jednocześnie na iOS, Android oraz Windows. Polecam tą technologię ponieważ jest. bardzo wszechstronna i wygodna oraz programujesz w jezyku C# - Mondonno 2019-09-11 16:40
Sam Xamarin używałem niedawno do projektu na studia. Mam mieszane uczucia. Wydawał mi się dosyć toporny jeśli chodzi o implementacje bardziej złożonych elementów UI. Ale może to błędne przeświadczenie. - Aventus 2019-09-11 16:47
@Mondonno: chłopie, ale przecież tutaj chodzi o stack w pracy. - some_ONE 2019-09-11 18:06

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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