Wątek przeniesiony 2017-03-16 22:04 z Nietuzinkowe tematy przez somekind. Powód: Niepoprawna kategoria forum

Pisanie open source w pracy

Odpowiedz Nowy wątek
2017-03-16 21:23
2

Prowadzący zajęcia parę razy wciskał nam coś, co później okazało się być bzdurą, np. że nazwa "round robin" wzięła się od ptaka - rudzika albo że jedynym poważnym źródłem zarobków Microsoftu jest subskrypcja Office365 i praktycznie nic innego już nie sprzedają.

Ostatnio znowu coś powiedział, a ponieważ pierwszy raz usłyszałem o czymś takim, postanowiłem napisać tutaj pytanie z prośbą o weryfikację.

W wielu firmach, w których programiści pracują nad projektami komercyjnymi, podpisują specjalne umowy zabraniające im w razie opuszczenia firmy pisania podobnego kodu przez następne parę lat. Programiści omijają ten proceder, publikując napisany przez siebie kod na licencji otwartej typu MIT, po czym importując go do projektu komercyjnego jako bibliotekę. W razie zmiany miejsca pracy, będą mogli w ten sposób skorzystać z już gotowego kodu swojego autorstwa i jednocześnie nie złamią postanowień umowy.

Wiem, że to brzmi śmiesznie, ale mimo wszystko chciałbym rozwiania moich wątpliwości przez osoby z doświadczeniem komercyjnym xD


Miał prawie dobre informacje - bardzo dużym źródłem przychodów Microsoftu jest Azure. Więc nie Office 365, nie jedynym i coś innego jednak sprzedają, ale jednak prawie dobrze. Jak z tymi rowerami na Placu Czerwonym. - Ktos 2017-03-17 20:42

Pozostało 580 znaków

2017-03-16 22:02

Hm generalnie to bzdura, bo nie możesz ot tak sobie opublikować kodu pisanego w pracy, bo tenże jest własnością twojego pracodawcy. Pewnie mógłbyś po godzinach sklecić jakąś bibliotekę a potem użyć jej w pracy, ale znów często umowa zabrania ci takich rzeczy, jeśli ta biblioteka jest związana z tym co robisz w pracy. No i też zwykle nie możesz ot tak importować sobie biblioteki noname z d**y w projekcie w pracy, bo cie jakiś architekt nabije na pal :D

Niemniej wiele firm pisze rzeczy open source i faktycznie udostępnia je dla innych, ale to wszystko odbywa się za zgodą i wiedzą pracodawcy.

edytowany 1x, ostatnio: Shalom, 2017-03-16 22:03

Pozostało 580 znaków

2017-03-16 22:19
0

Dokładnie tak samo myślałem, ale według tego pana tak robią wszyscy, którym umowa zabrania pisania podobnego kodu w przyszłości. Podobnie twierdzi w kwestii używania zewnętrznych bibliotek: jeśli tylko licencja na to pozwala, można używać wszelkich bibliotek, jakie się znajdzie, bo "po co wynajdować koło na nowo".


Pozostało 580 znaków

2017-03-16 22:20
0

Pewnie mógłbyś po godzinach sklecić jakąś bibliotekę a potem użyć jej w pracy, ale znów często umowa zabrania ci takich rzeczy, jeśli ta biblioteka jest związana z tym co robisz w pracy. No i też zwykle nie możesz ot tak importować sobie biblioteki noname z d**y w projekcie w pracy, bo cie jakiś architekt nabije na pal :D

U nas w projekcie (w międzynarodowym banku) jest sporo takich bibliotek naklepanych przez poprzedni zespół po godzinach. Biblioteki są dostępne na Google Code i/ lub GitHubie.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition<hr>"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2017-03-17 00:09
0

@ShookTea a jeśli w tej bibliotece jest jakaś luka bezpieczeństwa albo poważny bug to co? ;) Jasne że "można", ale często architekt na to nie pozwoli. Widziałem już takie biblioteki co to fajnie działały dla HelloWorld, ale w dużym projekcie powodowały wywalenie się aplikacji z out of memory :D I co potem powiesz klientowi któremu system nagle przestaje działać? ;) Zewnętrzne zależności zawsze niosą pewne ryzyko, ale jednak można mieć nadzieje że bibliotekę standardową języka ktoś przetestował, tak samo jakiś popularny framework. Ale już noname lib z randomowego githuba?
@Wibowit jw, pytanie kto to utrzymuje potem.

edytowany 2x, ostatnio: Shalom, 2017-03-17 00:12

Pozostało 580 znaków

2017-03-17 00:39
0

dobrze, że ktoś zadał to pytanie, bo się nad tym zastanawiałem
Z drugiej strony ciekawi mnie postać prowadzącego, bo jego myślenie jest zaskakujące: napisz liba na licencji MIT, idź do pracy, praca się nie podoba to zmieniasz i idziesz do innej, korzystasz z tego samego liba. Same profity a manna leci z nieba. Trzeba mieć tylko wyjątkowy fart, żeby np. na przestrzeni choćby 2 lat, trafić do innej firmy, która robi konkurencyjny projekt i jest na tym samym etapie co pierwsza firma 2 lata temu. Teoria światów równoległych to przy tym betka.


Panie Żurawiecki, projektowanie to nie jest sprzedawanie pietruszki. Do widzenia Panu.

Pozostało 580 znaków

2017-03-17 00:43
Krwawy Mleczarz
1

Nie ma czegoś takiego jak zakaz pisania podobnego kodu.
Jak niby sprawdzić podobieństwo nie mając dostepu do kodu w nowej firmie byłego pracownika?
Jeżeli zakaz dotyczyłby konkretnych sektorów, to już zupełnie bzdura, bo to by oznaczało, że jak pracujesz w bankowości to później już nie możesz i bardzo szybko ścieżk by się pozamykały.

Jeżeli ktoś coś takiego w umowei ma, to to jest tyle samo warte ile zakaz konkurencji jeżeli pracodawca nie spełni dodatkowych warunków.
Konkretnie każdy tego typu zapis który stawia Cię w gorszej pozycji po zakończeniu współpracy wiąże się z koniecznością jawnego podania kwoty rekompensaty za taki zakaz.

Jeżeli nie będzie w umowie konkretnie napisane, że za to, że nie możesz konkurować dostajesz X zł miesięcznie lub X rocznie to wtedy w sądzie znaczy to tyle samo co jakby pracodawca napisał zamiast tego punktu, że lubi placki ziemniaczane.
Znaczy, że zapis jest zupełnie bez mocy prawnej.

Pozostało 580 znaków

2017-03-17 00:52
0

Nie wiem co nawygadywał prowadzący (dokładnie). Niemniej jednak bibliotek nie wprowadza się do projektu bezrefleksyjnie. Często architekt lub wymagania projektu określają by było szybkie i merytoryczne komercyjne wsparcie dla wprowadzonego elementu kodu. Często może to wykluczyć bibliotekę Open Source (np. ma wsparcie ... żadne....). Inną sprawą jest potencjalny brak kontroli nad procesem rozwoju takiego włączanego produktu. Nie wiadomo czy i kiedy zmieni się jego API lub w jakim kierunku będzie rozwijała się nowsza wersja modułu/biblioteki/narzędzia oraz czy nie zostanie porzucona.
Co do twierdzenia odnośnie pisania na licencji MIT w pracy i "chytrej operacji".. Jeśli to ma być "chwyt" na "krwiopijcę-pracodawcę" to ... jest to działanie nieetyczne. Dobrym programistom raczej dobrze się płaci i mają szacunek tak do pracodawcy jak i do swojej pracy. Ci inni... opowiadają klechdy z krainy mchu i paproci :-) Także IMHO warto skupić się na merytorycznych zagadnieniach przedstawianych przez prowadzącego a te inne pominąć milczeniem :-)


Każdy problem w informatyce można rozwiązać, dodając kolejny poziom pośredniości,z wyjątkiem problemu zbyt dużej liczby warstw pośredniości — David J. Wheeler

Pozostało 580 znaków

2017-03-17 01:06
def
0

W wielu firmach, w których programiści pracują nad projektami komercyjnymi, podpisują specjalne umowy zabraniające im w razie opuszczenia firmy pisania podobnego kodu przez następne parę lat.

Nie ma czegoś takiego. Jeśli już jest zakaz konkurencji i tyczy się on tylko krytycznych stanowisk w każdej firmie, a nie każdego podrzednego programisty. Jakby to miało wyglądać? Pracujesz w firmie A jako developer Django i po tym nie możesz przez 5 lat pracować z Django? Dwa zakaz konkurencji jest odpowiednio regulowany przez prawo, a także rekompensowany przez pracodawce. To poważne i i obudowane wieloma paragrafami umowy. Nie ma opcji by obejść to bez wyroku sądu. Nie ma czegoś takiego jak zakaz pisania "podobnego kodu". Nie możesz korzystać z własności intelektualnej swojego poprzedniego pracodawcy bez jego zgody, jest to przestępstwo, ale nie możesz być ograniczony do wytwarzania czegoś własnego. Co za bzdury.

edytowany 1x, ostatnio: def, 2017-03-17 01:07

Pozostało 580 znaków

2017-03-17 01:06
0

Typowy kod w pracy jest osadzony w jakimś stosie technologicznym, w architekturze projektu, i rozwiązuje projektowe problemy. Jak to niby zbibliotekować, a potem przenieść do innego projektu?

Pokaż pozostałe 3 komentarze
Ale czym innym jest zaprojektowanie i wykonanie oddzielnej biblioteki, a czym innym wycięcie kawałka kodu z jakiegoś taska w pracy i próba zrobienia z niego czegoś uniwersalnego. - somekind 2017-03-17 03:07
"To zależy" :) Kod kodowi nierówny. Czasem byłoby to piekło, czasem w miarę łatwe zadanie. Zależy co ten kod robi, w jaki sposób byłby zintegrowany z projektem (dobrze napisany moduł łatwiej by można było przenieść, niż moduł, który używa tysiąca zmiennych globalnych i ma w zależności 30 innych modułów w projekcie). Chociaż myślę, że pojawia się też kolejne pytanie - czy jest sens? Niektóre rzeczy po prostu nie miałyby sensu poza określonym projektem i byłaby to sztuka dla sztuki. - LukeJL 2017-03-17 03:39
no i czasem zbibliotekowanie spowodowałoby, że kod musialby być bardziej skomplikowany (widzę to po różnych projektach open source, gdzie rzecz, którą w realnej sytuacji w pracy zrobiłoby się w godzinę w jakieś kilka linijek kodu - to tam ma to np. z 1000 linii i robią to miesiącami). No bo w sumie jak coś ma być do jednego projektu to można zrobić to prosto, a jak coś ma być "wspólne" to się zapewnia możliwość konfiguracji wszystkiego, zaczyna się dodawać jakieś dziwne ficzery, bo jakiś user sobie tak zażyczył itp. jakieś corner casy trzeba obsłużyć itp. - LukeJL 2017-03-17 03:46
Niektóre rzeczy po prostu nie miałyby sensu poza określonym projektem - no mi właśnie o to chodzi, tylko ja uważam, że tak jest z większością, a nie niektórymi rzeczami. Kod w pracy jest zazwyczaj zbyt mocno osadzony w konkretnym projekcie, żeby można go było sobie tak po prostu wydzielić. - somekind 2017-03-17 09:21
swoją drogą ciekawe jak to było dokładnie z Reactem (wiem, że FB tego używa w pracy, ale nie wiem czy było na zasadzie "wydzielamy istniejącą rzecz", czy "tworzymy od zera reużywalną bibliotekę). - LukeJL 2017-03-18 03:40

Pozostało 580 znaków

2017-03-17 10:54
0

Typowy kod w pracy jest osadzony w jakimś stosie technologicznym, w architekturze projektu, i rozwiązuje projektowe problemy. Jak to niby zbibliotekować, a potem przenieść do innego projektu?

Dużo zależy od tego jak rozwinięty jest ekosystem dla języka w którym piszesz. Gdy poprzedni zespół zaczynał tworzenie systemu to ekosystem Scali był dużo mniej rozbudowany niż teraz. Wobec tego popisali sami biblioteki, które dzisiaj już czasem mają popularne odpowiedniki. Przykłady:

  • klient HTTP,
  • biblioteka do obsługi CSV,
  • mikroframework do RESTowych enpointów z próbkami (healthchecki) oraz proste narzędzie monitorujące odpalające te próbki w kółko na bieżąco i pokazujące stan systemu,
  • infrastruktura dla testów integracyjnych dla mikroserwisów: mikroframework do RESTowych endpointów w serwisach by wywołać konkretne akcje czy sprawdzenia + narzędzie pozwalające odpalać testy napisane we własnym DSLu, które korzystają z tych endpointów,
  • testy przeglądarkowe, czyli:
    • nakładka na selenium (fluent interface)
    • mechanizm, który pozwala odpalać pulę JVMek i przeglądarek, by odpalić N instancji aplikacji i mieć szybsze wykonanie testów,

Jako że ekosystem Scali mocno się zmienił w ciągu ostatnich kilku lat to obecnie staramy się raczej szukać sprawdzonych otwartych bibliotek, niż rozwijać biblioteki od kolegów z poprzedniego zespołu, bo przede wszystkim te biblioteki nie mają żadnej dokumentacji albo jakieś szczątkowe. Na pierwszy ogień poszedł klient HTTP, później biblioteki do CSV w razie potrzeby. Dodajemy też nowe sposoby monitorowania (Kamon/ Grafana). Następna w kolejności będzie infrastruktura testowa dla testów przeglądarkowych jeśli zmienimy architekturę systemu i zastąpimy komponentowy framework server-side za pomocą RESTa na backendzie i SPA na frontendzie.

@ShookTea a jeśli w tej bibliotece jest jakaś luka bezpieczeństwa albo poważny bug to co? ;) Jasne że "można", ale często architekt na to nie pozwoli. Widziałem już takie biblioteki co to fajnie działały dla HelloWorld, ale w dużym projekcie powodowały wywalenie się aplikacji z out of memory :D I co potem powiesz klientowi któremu system nagle przestaje działać? ;) Zewnętrzne zależności zawsze niosą pewne ryzyko, ale jednak można mieć nadzieje że bibliotekę standardową języka ktoś przetestował, tak samo jakiś popularny framework. Ale już noname lib z randomowego githuba?

Poważne luki bezpieczeństwa są wszędzie. Banki mają specjalizowane zespoły, które wykrywają luki bezpieczeństwa w aplikacjach jako całości i komunikują się z zespołami tworzącymi te aplikacje.

Naszych klientów nie interesują specjalnie biblioteki jakich używamy. Ich interesuje to czy system działa. Jeśli coś się spieprzy to nie mówimy, że biblioteka X ma błąd i rozkładamy ręce tylko szacujemy ile coś nam zajmie czasu by to poprawić i co można zrobić na szybko by kupić sobie czas (bo np za chwilę przyjdą ważne transakcje i wtedy np trzeba zrestartować jeden mikroserwis). Równocześnie w zasadzie nie zdarza się by te biblioteki, które przytoczyłem sprawiały jakieś problemy na produkcji, bo tylko trzy na produkcji lądują i są to proste i rzadko zmieniane rzeczy: klient HTTP, biblioteka do CSV i REST z próbkami.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition<hr>"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 6x, ostatnio: Wibowit, 2017-03-17 11:04

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