Jak zorganizować zespół i poprowadzić projekt.

Jak zorganizować zespół i poprowadzić projekt.
Kamil Raju
  • Rejestracja:ponad 6 lat
  • Ostatnio:prawie 5 lat
  • Postów:77
3

Zostałem niedawno koordynatorem małego, zdalnego, zespołu programistów (4 sztuki). Pierwszy projekt już prawie skończony, ogarnąłem specyfikacje i architekturę projektu, taski lecą przez Trello, pracujemy w tygodniowych sprintach, robimy wzajemnie code review itd.. Wiem jednak że dużo mi brakuje do bycia dobrym kierownikiem.

Największy problem sprawia mi odpowiedni podział projektu na taski, żeby wszyscy mogli pracować jednocześnie, bez konieczności tworzenia mocków, lub czekania aż ktoś inny skończy API innego modułu. Poza tym, często muszę uciekać się do mikrozarządzania, żeby całość ze sobą zagrała. No i finalnie, nie wiem jak podchodzić do całości od strony ludzkiej, starać się z nimi zakolegować, czy raczej trzymać chłodny dystans. Moglibyście mi polecić książki/blogi/filmy/szkolenia na temat skutecznego zarządzania zespołami, projektami i ludźmi? Podzielić się, jak wygląda workflow u was, od otrzymania specyfikacji do zdania projektu?

jarekr000000
  • Rejestracja:ponad 8 lat
  • Ostatnio:29 minut
  • Lokalizacja:U krasnoludów - pod górą
  • Postów:4707
3

Raczej nie mam dobrych rad, za mało konkretów podajesz.

  1. Mikrozarządzanie - chyba większość managierów stosujących mikrozarządzanie nie ma pojęcia, że je stosuje. Nie wiem co u Ciebie znaczy mikrozarządzanie.
  2. Robienie mocków, czekanie na API jest normalne, w każdym projekcie. To nie kopanie rowów, wielu zależności nie widać i wychodzą w praniu.
  3. Jak wiem co jest celem projektu to zwykle w trakcie czekania jestem sobie znaleźć sensowne zadanie w projekcie.
  4. starać się z nimi zakolegować, czy raczej trzymać chłodny dystans. - chcesz się zakolegować z programistami, zrób swoje demko 4k w asmie. To najłatwiejszy sposób.
  5. Do specyfikacji często używamy wiki lub google docsów - w mniejszych projektach. Ważne żeby każdy mógł edytować, szukać i żeby była historia zmian.
  6. Co Ci dają sprinty ?

Tak przy okazji to ostatnio w projekcie typu: specyfikacja, realizacja, zdanie to byłem z 6 lat temu, ale to dla linii lotniczej - wprost powiedzieli, że są bardzo nie agile.


jeden i pół terabajta powinno wystarczyć każdemu
edytowany 2x, ostatnio: jarekr000000
Kamil Raju
Managierem nie jestem, ledwie programistą po awansie. Czasami więc siedzę i palcem pokazuję młodszym co, jak i dlaczego zrobić. I z reguły to nie ich wina, tylko kwestia tego że taski są często nieprecyzyjne i nie łączą się w spójną całość. To nazywam mikrozarządzaniem.
Miang
dlaczego nie doprecyzujesz tych tasków?
Szalony Programista
Szalony Programista
  • Rejestracja:około 7 lat
  • Ostatnio:prawie 4 lata
  • Postów:227
0

Ludzie są społeczni i odwzajemniają emocje, możesz rzucać słowami z nie adekwatnymi emocjami, a ludzie to jakoś przyjmą, ale w sumie to w czasie rozmowy wyczujesz jak rozmowa będzie niekomfortowa.

Kamil Raju
  • Rejestracja:ponad 6 lat
  • Ostatnio:prawie 5 lat
  • Postów:77
0

Sprinty to może za dużo powiedziane, daleko mi do frameworków zarządzania. Chodzi o wymóg żeby co piątek program się kompilował i przechodził wszystkie testy. Po pierwsze, jest czas żeby przez weekend pogadać z klientem i wprowadzić ewentualne poprawki. Nie wszystko można wyłapać w fazie projektowania. Po drugie narzuca to pewien rygor doprowadzania rzeczy do końca, zamiast rozgrzebywać całość na hurra. Wymusza też podział programu na niezależne moduły. Podobnie działa TDD przy pisaniu logiki, nie stricte dla testów, ale dla jakości kodu.

@jarekr000000 Jeżeli mogę zapytać, jaki był podział zadań? Projekt był rozbity na małe kęsy po kilka roboczogodzin, które były rozdzielane na ludzi, czy raczej każdy dostawał do zrobienia cały moduł, na kilkanaście dni pracy i sam sobie dalej organizował jak to przerobi?

Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
5

Chodzi o wymóg żeby co piątek program się kompilował i przechodził wszystkie testy

o_O branch master zawsze powinien sie kompilować i przechodzić wszystkie testy. Jak jakiś feature jest scalany do mastera to znaczy że przeszedł wszystkie testy na środowisku testowym.
Niewiele ma to wspólnego ze Sprintami czy z kończeniem tasków. To jest ortogonalna kwestia. Niemniej moim zdaniem takie sztuczne narzucanie że "feature ma być zrobiony do końca sprintu w piątek" kończy się zawsze źle:

  1. Albo programiści będą estymować zachowawczo mniej - powiedzą że są w stanie zrobić dużo mniej, żeby nie ryzykować ze się nie wyrobią.
  2. Albo będą robić fuszerkę z serii "nie ma testów" i "kiedyś sie to zrefaktoruje", co w najlepszym wypadku skonczy się długiem techniczny, a w najgorszym wysadzi wam kiedyś produkcje
  3. Albo będą olewać wszystko inne (np. jakiś pożar na produkcji) żeby nie "tracić czasu", bo się nie wyrobią. Widziałem takie akcje -> coś sie sypie na produkcji a gość odpowiedzialny za dany serwis mówi ci, że mogą ten problem omówić na planningu za tydzień i może wrzucą w kolejny sprint więc przy dobrych wiatrach za 2-3 tygodnie będzie naprawione :D

Poza jakimiś mocno formalnymi środowiskami, gdzie przyjecie przez klienta nowej wersji jest ustandaryzowane w jakiś sposób, w ogóle bym sie w takie coś nie pakował. Jeśli mozecie sobie pozwolić na ciągłą integrację, to z tego korzystajcie. Jak feature jest gotowy to leci na proda a developer bierze następny task. Nie ma sensu czekać do jakiegoś mitycznego "końca sprintu".


"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
edytowany 1x, ostatnio: Shalom
Kamil Raju
Co piątek program ma być w stanie, w którym można go pokazać klientowi. Jak ktoś się nie wyrobi, to żaden problem, z reguły pomaga mu ktoś inny z zespołu, kto już skończył. Jest to kwestia nie tyle programistyczna, co specyfika zamówień; krótkie, z dużym dozorem klienta. Chociaż możliwe że trochę całość przekombinowałem i ciągła integracja trzymająca poziom też da radę.
PI
  • Rejestracja:ponad 9 lat
  • Ostatnio:3 miesiące
  • Postów:2787
0
Shalom napisał(a):
  1. Albo będą olewać wszystko inne (np. jakiś pożar na produkcji) żeby nie "tracić czasu", bo się nie wyrobią. Widziałem takie akcje -> coś sie sypie na produkcji a gość odpowiedzialny za dany serwis mówi ci, że mogą ten problem omówić na planningu za tydzień i może wrzucą w kolejny sprint więc przy dobrych wiatrach za 2-3 tygodnie będzie naprawione :D

@Shalom wiadomo że przy pożarach to trzeba interweniować natychmiast, ale być może chodziło o to że klient nie dogadał się z PO/analitykami/programistami i jest powiedzmy minor, czyli że główne funkcjonalności działają i ogólnie przez te 2-3 tygodnie produkcja może żyć?

Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
2

@Pinek nie, po prostu kwestia kto za co jest odpowiedzialny. Twój zespół jest odpowiedzialny za serwisy X, Y i Z, a inny zespół za A, B i C. Wyobraź sobie że twój serwis X zależy od serwisu A i nagle coś przestało działać na tym styku, ale wszystkie "biznesowe" funkcjonalnosci A, B i C działają, więc tamten zespół ma generalnie wywalone na twój problem. A reszta to klasyczna "spychologia" - jak nie chcesz czekać tych 2-3 tygodni aż oni to poprawią, to siadaj i napraw sam a potem wystaw pull request. Wszystko w imie "scruma", żeby tylko się wyrobić na mityczny koniec sprintu ;]


"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
LukeJL
  • Rejestracja:około 11 lat
  • Ostatnio:minuta
  • Postów:8400
0

@Kamil Raju

, żeby wszyscy mogli pracować jednocześnie, bez konieczności tworzenia mocków,

Ale przecież tego typu mocki w czasie developerki to akurat pożyteczny wynalazek, genialny w swojej prostocie, bo właśnie pozwala pracować jednocześnie. Mock pozwala pracować nad rzeczami, które jeszcze nie są zrobione, więc jest w projekcie odpowiednikiem tego, co w programowaniu nazywa się "promise" albo "future".

Problem zaczyna się wtedy, kiedy mock całkowicie inaczej wygląda/działa niż moduł, który ktoś inny faktycznie robi, ale to wtedy jest to albo porażka komunikacji albo porażka zarządzania (może po prostu nad pewnymi rzeczami nie powinno się pracować za wcześnie).

czekania aż ktoś inny skończy API innego modułu.

Z drugiej strony z mocków można by w ogóle zrezygnować, jeśli ludzie by robili ciągłą integrację i cały czas integrowali nowe API. Więc wtedy zawsze byłoby dostępne prawdziwe API. więc ktoś po prostu tego API by użył, a nie robił mocka.

Tylko żeby to było możliwe, programiści musieliby dostarczać działające kawałki kodu do integracji codziennie, ew. kilka razy na tydzień. A nie raz tydzień, czy dwa tygodnie.

Podobnie działa TDD przy pisaniu logiki, nie stricte dla testów, ale dla jakości kodu.

TDD nie zapewnia dobrej jakości kodu, wręcz przeciwnie. TDD pozwala na bezpieczne pisanie kodu spaghetti (bo zawsze można zrefaktorować). Jedną z korowych zasad TDD jest to, żeby pisać tylko tyle kodu, byleby tylko testy przeszły. Innymi słowy możesz pisać byle jak. Z TDD możesz pisać nawet po pijaku albo od niechcenia i jeśli tylko testy przejdą, to jesteś w domu i masz pewność, że nic nie zepsułeś i że to co robisz, działa (ale TDD nie gwarantuje, że to, co robisz ma w ogóle sens, czy jest wysokiej jakości)..


edytowany 1x, ostatnio: LukeJL
Zobacz pozostałe 3 komentarze
TD
@LukeJL zależy co rozumiesz przez "refaktoring". Wydaje mi się, że według TDD chodzi o to, żeby rzeczywiście napisać najprościej jak się da, tak żeby tylko testy przeszły, a następnie to rozwiązanie ulepszyć. Więc nie chodzi ani o to, żeby napisać byle jak i zostawić, ani o to żeby nagle zacząć refaktorować cały system. Ja tak rozumiem te zasady, a czy one mają sens to już kwestia indywidualna pewnie.
vpiotr
Netflix właśnie chyba pracuje w podejściu mock-less. Oni wrzucają na produkcję coś kilka- kilka-naście razy dziennie. Jak się wywali to automatycznie jest odwracane (opis na poziomie astronauty). Do tego sami wywalają sobie produkcję: https://medium.com/production-ready/using-chaos-monkey-whenever-you-feel-like-it-e5fe31257a07
Kamil Raju
TDD zmusza do podziału kodu na logiczne, krótkie jednostki, bo inaczej nie da się tego przetestować. Od samego red, green, refactor, istotniejsze jest, usiądź, pomyśl, zanim cokolwiek napiszesz. Szczególnie w wypadku juniora. No ale jak się uprzesz, to nic Cię nie powstrzyma przed robieniem fuszerki.
john_klamka
@LukeJL: ty sobie lepiej doczytaj czym jest tdd (najlepiej u źródła) bo powtarzasz hasełka z hinduskich blogów
LukeJL
@john_klamka gdzie, w którym miejscu?
KR
Moderator
  • Rejestracja:prawie 21 lat
  • Ostatnio:około 21 godzin
  • Postów:2964
1

Jak budujesz projekt bottom-up, to nie są potrzebne mocki. Jakby budowlańcy zaczynali budowę od dachu, to w wtedy faktycznie potrzebowali by mocków ścian i fundamentów :P

edytowany 1x, ostatnio: Krolik
Shalom
Tylko że zabawa w układanie przez 100 osób po jednej cegle też może nie mieć za bardzo sensu ;) lepiej sie umówić co będzie potrzebne i część ekipy niech robi kolejne elementy które się zintegruje kiedy będą potrzebne.
MarekR22
Nawet w budowlance jak się buduje most, to się ustala jakieś zasady i jedni budują fundamenty przęsła itp, a w fabryce powstaje pomost, który potem przypływa rzeką na gotowe fundamenty i jest ustawiany na swoim miejscu. Jak widzisz, że twój przykład z budowlańcami nie koniecznie dowodzi, słuszności twojej koncepcji "bottom-up". Tak samo najpierw buduje się tymczasowe drogi (mocki) potem budynek i na koniec końcowe drogi dojazdowe.
KR
Przykład z mostem pokazuje właśnie, że wszystko się buduje bottom-up. Z małych elementów robi się większe, nie odwrotnie. Bottom-up nie zakłada braku specyfikacji, ani że elementy nie mogą powstawać w innym miejscu.
LukeJL
(tu wcześniej był komentarz, ale rozpisałem się i napisałem całego posta) Jak zorganizować zespół i poprowadzić projekt.
NO
  • Rejestracja:ponad 7 lat
  • Ostatnio:ponad 5 lat
  • Postów:165
1

Może po prostu masz za dużo ludzi w projekcie?

somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:3 dni
  • Lokalizacja:Wrocław
1
Kamil Raju napisał(a):

Chodzi o wymóg żeby co piątek program się kompilował i przechodził wszystkie testy.

Nawet w Bangalore nie ma takich niskich standardów.

LukeJL napisał(a):

Ale przecież tego typu mocki w czasie developerki to akurat pożyteczny wynalazek, genialny w swojej prostocie, bo właśnie pozwala pracować jednocześnie. Mock pozwala pracować nad rzeczami, które jeszcze nie są zrobione, więc jest w projekcie odpowiednikiem tego, co w programowaniu nazywa się "promise" albo "future".

Problem zaczyna się wtedy, kiedy mock całkowicie inaczej wygląda/działa niż moduł, który ktoś inny faktycznie robi, ale to wtedy jest to albo porażka komunikacji albo porażka zarządzania (może po prostu nad pewnymi rzeczami nie powinno się pracować za wcześnie).

No i dlatego lepiej pracować na prawdziwych serwisach, nie na mockach. Bo potem nagle może się okazać, że dopasowanie systemu do faktycznej instancji zajmuje wiele miesięcy. A tworzenie i utrzymywanie mocków to też jest koszt, który jest de facto wyrzuceniem pieniędzy w błoto.

Z drugiej strony z mocków można by w ogóle zrezygnować, jeśli ludzie by robili ciągłą integrację i cały czas integrowali nowe API. Więc wtedy zawsze byłoby dostępne prawdziwe API. więc ktoś po prostu tego API by użył, a nie robił mocka.

No i co za problem? Pracuję w firmie, która w ten sposób działa już od wielu lat. Nie ma dodatkowego kosztu utrzymania mocków, nie ma niespodzianek przy podłączaniu do realnego serwisu.
Jedyna wada to to, że czasem realny serwis się może wywalić i zastrzymać pracę zespołu. Ale to jednocześnie zaleta, bo w takiej sytuacji można sprawdzić, czy nasze serwisy prawidłowo sobie radzą w sytuacji failowania swoich zależności. Przy zabawie w mocki nie ma na to szans - zawsze wszystko działa, dopiero po deployu okazuje się, jakie badziewie zostało wdrożone.

jarekr000000
  • Rejestracja:ponad 8 lat
  • Ostatnio:29 minut
  • Lokalizacja:U krasnoludów - pod górą
  • Postów:4707
0

Do obecnego zespołu i firmy dołączyłem (między innemi), dlatego że w zasadach mieli, robienie mocków do wszystkich zewnętrznych zależności. Dzięki temu można spokojnie pracować nad systemem będąc totalnie offline. Niektóre mocki mają całkiem skomplikowaną logike i symulują całkiem niezłe rzeczywiste systemy.

W poprzedniej firmy ilość strat generowana przez to, ze jakiś z systemów nie działał i nie mozna było nawet GUI dopalić - była kosmiczna. Całe roboczo tygodnie w p...du.


jeden i pół terabajta powinno wystarczyć każdemu
edytowany 2x, ostatnio: jarekr000000
Zobacz pozostałe 15 komentarzy
jarekr000000
@somekind: coś podkapcasz? WYstarczy, że byłem ileś razy w takich głupich konstelacjach to wiem jak to wygląda. Żadnych sabotazystów tu nie trzeba i żadnego kasowania w bazie (nic o bazie nie pisałem). Trzech ludzi odpala co lepsze testy e2e równocześnie i się wywala, jeśli idzie na wspólnej bazie danych (zweykle wielu wspólnych bazach), bo własnie mamy np. tych samych userów. I się konta nie zgadzają... Na zakłamanych zależnościach można przetestować wszystko - nawet cały bank - nawet zasymulować dwa lata pracy.
somekind
Nie znam słowa podkapcać. Nawet jeśli nie chodziło Ci o bazę, to napisałeś o kasowaniu. Odpalenie testów e2e powoduje znikanie danych? Nie rozumiem jak.
jarekr000000
Bo np. testuje dość konkretnie, rejestrowanie użytkownika w systemie, obsługe jego konta, zawieszanie jego konta i co dość ważne: koniec współpracy (ten ostatni punkt nawet szczególnie trudny/zabawny). Do tego jeszcze nie tylko w bazach aplikacji, ale jeszcze w całym security. A ponieważ system działał właśnie jak normalny, normalny stage DEV/INT - to nie za bardzo działać mogło wymyślanie użytkowników. Np. przez dość ograniczona pulę dostępnych userów z ldap, na potrzeby testów - dramat.
somekind
A to serio nie można mieć więcej userów do testów i programiści muszą się nimi dzielić? Jak dla mnie to wygląda na problem organizacyjny.
jarekr000000
Tak, to jest problem organizacyjny pod tytułem jedna współdzielona infrastruktura do testów. Za to prawdziwa.
LukeJL
  • Rejestracja:około 11 lat
  • Ostatnio:minuta
  • Postów:8400
0

@Krolik

Jak budujesz projekt bottom-up, to nie są potrzebne mocki. Jakby budowlańcy zaczynali
budowę od dachu, to w wtedy faktycznie potrzebowali by mocków ścian i fundamentów :P

to, to! Też chciałem to napisać, ale pomyślałem, że nie ma sensu, bo OP i tak pewnie nie wcieli tej zasady, ponieważ zasada budowania top-down jest wręcz dogmatem w wielu firmach (sam fakt, że OP jest "koordynatorem" - czyli w nazwie stanowiska ma wpisaną zasadę top-down). Namawianie do podejścia bottom-up to tak jakby powiedzieć koordynatorowi, żeby przestał być koordynatorem. -

Wydaje mi się, że coś jest szalenie zepsute w metodykach budowania komercyjnego softu. Dlatego właśnie w wielu firmach "agile" panuje dalej waterfall, bo te firmy dalej opierają się na zasadzie top-down (czyli: waterfall), zamiast zrobić coś takiego jak jest w open source projektach - że jeden programista tworzy moduł/bibliotek, a inni programiści używają tej biblioteki. Łączą wiele niskopoziomowych bibliotek/modułów w większe biblioteki, czy w całe aplikacje

Trochę tak jakby to były 2 inne światy, gdzie w open source budowałoby się metodą syntezy (tworzenia czegoś większego z małych elementów - budowanie jak klocków), a komercyjny soft byłby robiony metodą analizy (gdzie bierze się jeden wielki projekt i dzieli się ten projekt na wiele małych stories czy tasków). To wynika w dużej mierze ze struktury władzy (może dziwnie brzmi to słowo w tym kontekście, ale chodzi mi o to, kto podejmuje decyzje, czy idzie z góry, z duchem waterfalla, czy może samowystarczalne zespoły, i poszczególni programiści, mają autonomie piszą soft współpracując ze sobą).

Swoją drogą zamiast dzielenia tasków, ja bym zapronował coś w stylu opracowania spójnych standardów / reguł współpracy / zasad.

bez konieczności tworzenia mocków, lub czekania aż ktoś inny skończy API innego modułu.

Gdyby istniały spójne standardy, to nie trzeba byłoby czekać aż skończy API modułu, ponieważ moduły miałyby standardowy kształt API (wg jakiegoś tam dobrze znanego standardu).

O ile w ogóle nie byłyby skończone (czemu też można by zapobiec przez continous integration).

Czemu tak często w komercyjnym sofcie odkrywa się koło na nowo (NIH) i pisze się soft na zasadzie "wielkich zmian co jakiś czas" zamiast "małych zmian codziennie"?


edytowany 5x, ostatnio: LukeJL
Kamil Raju
  • Rejestracja:ponad 6 lat
  • Ostatnio:prawie 5 lat
  • Postów:77
0

@LukeJL: Nie mam nad sobą nikogo technicznego, tylko Prezes, dla którego liczy się co zrobię, a nie jak. Mogę eksperymentować do woli. Jednocześnie zupełnie nie rozumiem jak mógłbym wprowadzić bottom-up. Projekt zaczyna się zebraniem listy wymagań od klienta. Potem, tak jak mówisz, analiza na moduły, featury, taski. Open Sourcowa synteza rozwija program, ale robi to w przypadkowych kierunkach, podczas gdy ja muszę trafić najkrótszą drogą do postawionej specyfikacji. W jaki sposób zastąpiłbyś taski ogólnym standardem pracy? W sensie, jak taki standard miałby być zdefiniowany?

Ogólnie miło jeżeli ktoś rozwinął by jak wprowadzić to Bottom-Up. Szczerze powiedziawszy sam nie potrafię powiedzieć z którego podejścia korzystam, raz jest tak, raz inaczej.

Btw. Może warto dodać do kontekstu: pracuję nad małymi, krótkimi projektami (1-3 tygodnie) programów lokalnych, nie web. Mocki nie są używane do separacji programu od innych serwisów, tylko udają funkcjonalności, które aktualnie tworzą inni członkowie zespołu.

jarekr000000
  • Rejestracja:ponad 8 lat
  • Ostatnio:29 minut
  • Lokalizacja:U krasnoludów - pod górą
  • Postów:4707
2

Niezłe. Masz projekty na 1-3 tygodnie i narzekasz. Do tego masz tygoniowe sprinty(?) - co wskazuje na to, że część projektów udaje Ci się zrobić w jednym sprincie. Powiniście dostać wręcz jakąś specjalna nagrodę, bo udaje i sie zrobić projekty w mitycznym modelu waterfall, którego mało kto próbował przed wami. A Ty narzekasz.

Ludzie doskonale opanowali zasady współpracy, robią mocki żeby móc pracowac nad swoimi częściami, nie czekając na innych, a Ty nadal narzekasz.

Trudno Ci tu będzie chyba dostać rozsądne porady, bo nie rozumiem nawet twoich problemów i strzelam, że wielu innych forumowiczów nie ogarnie. Nawet jak pracowałem w Januszsofcie i robiłem strony dla warzywniaków, to wyciągniecie od klienta co ma być na tej pierwszej stronie, poza jego gębą..., wymagało więcej czasu niż te kilka tygodni, w które wy robicie całe projekty.


jeden i pół terabajta powinno wystarczyć każdemu
edytowany 3x, ostatnio: jarekr000000
Kamil Raju
Nie narzekam, mam nadzieję że to tak nie zabrzmiało. Praca idzie bardzo dobrze, firma dostaje coraz więcej zleceń, całość się rozrasta. Ale sam mówisz że robię typowego Waterfalla. Narzucone przeze mnie sprinty to też chybiony pomysł. Poza tym, pierwszy raz spotkałem się z określeniem organizacji Bottom-Up. Właśnie o takie rzeczy pytam, nie zawsze będę miał wokół siebie tylko doświadczonych ludzi, chcę być dobry w tym co robię. Projekty 1-3 tygodnie, ale pracowania w opór po 70 godzin tygodniowo, ot, specyfika branży.
jarekr000000
70 godzin tygodniowo? Specyfika branży? To branża cyrkowa?
Kamil Raju
Kioski multimedialne. Klient zgłasza że potrzebuje xyz na targi, oczywiście na ostatnią chwile, my klepiemy. 2-3 tygodnie gułagu, potem tydzień-dwa luzu, wolne albo po 3-4 godziny przy utrzymaniu programów które są w stałej ofercie. Cokolwiek każde zlecenie to niezły wyścig z czasem, więc cały proces deweloperski musi być dobrze spasowany.
jarekr000000
Czyli cyrk. Nawet byłem w okolicach tego cyrku (reklama). I tak bardzo mnie nie zmęczyły te głupie terminy jak niestety klienci - w tej branży chyba trzeba mieć wyobraźnie porównywalną z workiem cementu, żeby zostać tzw. kreatywnym.
LukeJL
  • Rejestracja:około 11 lat
  • Ostatnio:minuta
  • Postów:8400
0

swoją drogą, jeśli jest dużo krótkich projektów, to przypuszczam, że są one jakoś podobne do siebie? Nie można by np. wydzielić wspólnego rdzenia (jakieś biblioteki "core") i używać w kolejnych projektach (żeby jeszcze szybciej szły / albo żeby krócej pracować, a nie 70 h tygodniowo). No i też dużo małych, podobnych (jak przypuszczam) projektów, to też można ustalić jakieś spójne zasady współpracy (między programistami nawzajem, ale także między firmą a każdym nowym klientem), żeby za każdym razem od początku wszystkiego nie wymyślać i nie kłócić się o pierdoły?

(ew. tak jak @jarekr000000 wspomniał - może już jest dobrze i nie trzeba nic zmieniać, bo nie wszystko się da ulepszyć i czasem pewne rzeczy lepiej zostawić w statusie quo?).

Open Sourcowa synteza rozwija program, ale robi to w przypadkowych kierunkach, podczas gdy ja muszę trafić
najkrótszą drogą do postawionej specyfikacji.

To jest dobre pytanie. Z jednej strony przydaje się mieć kogoś, kto nada kierunek (widać co się dzieje w GNU/Linux, gdzie jest totalnie rozdrobniony ekosystem, a istniejące rozwiązania często też są dziwne w obsłudze - np. Gimp, ja się co prawda przyzwyczaiłem, ale wiele osób narzeka). Podobnie te wszystkie setki słabych bibliotek JSowych, które robią to samo (i społeczność JSowa lepiej by skorzystała, gdyby ludzie dopracowywali istniejące narzędzia).

Ale z drugiej strony praca według "postawionej specyfikacji" to zwykle "idiotokracja", bo o kształcie projektu decydują zwykle idioci (nie zawsze oczywiście, ale zwykle tak bywa*). Ew. idąc w poprawność polityczną - ludzie niekompetentni, którzy nie są w stanie przemyśleć tego, co robią, a kierują się płytkimi emocjami/ambicjami (np. "chcę mieć to i to na stronie, bo strona konkurencji to ma").

Więc czy lepsza jest open source'owa anarchia czy dyktatura idiotów? :|

* a te rzadkie przypadki, kiedy na górze jest mądry człowiek, pozwalają na stworzenie czegoś naprawdę fajnego. No ale to rzadko się zdarza, bo nie każdy jest Stevem Jobsem


Szalony Programista
Szalony Programista
mając teraz 60 lat, prawdopodobnie urodziłeś się gdy tranzystory umożliwiły rozpoczęcie miniaturyzacji, pierwsze systemy unix kiełkowały i języki programowania. Większość pracy steva jobsa to było wzięcie hajsu za te opensource projekty i przeznaczenie tych środków na rozwój, który dalej był płatne. On tylko zgarnął wszystko co ludzie stworzyli i rozwinął z ich sprzedaży.
somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:3 dni
  • Lokalizacja:Wrocław
0

@jarekr000000: jestem ogólnie bardzo zaskoczony i zdziwiony teraz. Myślałem, że podobnie jak ja jesteś przeciwnikiem mockowania, a teraz okazało się, że tak naprawdę jesteś jakimś kryptomockofilem.

Choroba to jest coś negatywnego, co utrudnia funkcjonowanie. Wspólne dla zespołu serwisy i baza ułatwiają pracę, więc nie są chorobą lecz jej przeciwieństwem. Chorobą są mocki, które co prawda na początku pomagają lepiej kłamać, że w kodzie wszystko jest w porządku i wszystko działa, ale kiedyś w końcu nadchodzi czas wielkiego jeb. To jest dobre tylko, jeśli nas nie ma już wtedy w projekcie.

Wspólne serwisy i baza pozwalają na:

  • Oszczędność czasu z instalowaniem i konfigurowaniem dziesiątek serwisów, baz i systemu operacyjnego po to tylko aby uruchomić jakieś odległe zależności swojego projektu.
  • Wygodniejszą pracę, bo mniej softu działającego lokalnie, to też mniejsze zużycie zasobów.
  • Sprawdzenie wytworzonych danych w różnych aplikacjach służących do ich odczytu. Dane wstawione lokalnie widać w systemach postawionych na środowisku zespołowym, dane wstawione tamże są dostępne lokalnie. W przypadku jakichkolwiek błędów wszytko mogę sprawdzić czytając z tych samych baz i serwisów, co testerzy, zamiast żmudnie reprodukować lokalnie.
  • W pewnym zakresie darmowe testy wydajnościowe.
  • Brak big-bang deploymentów i związanego z tym gaszenia pożarów.
  • Cntionous integration na poziomie organizacji, a nie tylko pojedynczej aplikacji.

Wada jest jedna - nie można pracować bez dostępu do sieci. Ale zawsze można wziąć zadanie, który nie wymaga zależności zewnętrznych.

Dla porównania wady mocków:

  • Potrzebne oddzielne testy integracyjne.
  • Potrzeba więcej testów wydajnościowe.
  • Big-bang deployment i gaszenie pożarów po nim.

Co dają mocki?

  • Możliwość pisania kodu współpracującego z nieistniejącymi systemami.
    Czyli kup pan tonę uranu, bo w TV obiecali, że niedługo każdy w domu będzie miał reaktor.
jarekr000000
  • Rejestracja:ponad 8 lat
  • Ostatnio:29 minut
  • Lokalizacja:U krasnoludów - pod górą
  • Postów:4707
0
somekind napisał(a):

@jarekr000000: jestem ogólnie bardzo zaskoczony i zdziwiony teraz. Myślałem, że podobnie jak ja jesteś przeciwnikiem mockowania, a teraz okazało się, że tak naprawdę jesteś jakimś kryptomockofilem.

Jestem zwolennikiem totalnie prostej i bezproblemowej pracy w samolocie, ogródku i w lesie. Do tego bez konfliktów z innymi teamami i czekaniem aż coś naprawią.
Dawno temu juz pisałem, że nie mockuje zazwyczaj klas kolegów. Nie mockuję też własnych baz danych.

Ale mockowanie i to całkiem zaawansowane - wszelkich systemów zewnętrznych to podstawa. Bez tego straty na "czekaniu" (bo ktoś coś spierd... ) są zbyt duże. I widzę to wystarczająco często, żeby uwierzyć w alternatywne cuda.

Poza tym, lubię sobie pojeździć po konferencjach i nie tylko. Bez zmockowanych serwisów nie miałbym szansy sensownie pokodować.

Zresztą nie muszą to być stricte mocki, jak zapewnisz mi jednoklikowe postawienie całej infrastruktury na moim kompie to jestem jak najbardziej na tak.

EDIT:

Wspólne serwisy i baza pozwalają na:

  • Oszczędność czasu z instalowaniem i konfigurowaniem dziesiątek serwisów, baz i systemu operacyjnego po to tylko aby uruchomić jakieś odległe zależności swojego projektu.

Jak jest kiepska infrastruktura, że ta instalacja zajmuje czas - to tak jest, ale to gdzie indziej jest choroba.

  • Wygodniejszą pracę, bo mniej softu działającego lokalnie, to też mniejsze zużycie zasobów.

Ale większe użycie sieci i potencjalnych problemów z tym związanych. (np. paskudnie wolne działanie lokalnej aplikacji).

  • Sprawdzenie wytworzonych danych w różnych aplikacjach służących do ich odczytu. Dane wstawione lokalnie widać w systemach postawionych na środowisku zespołowym, dane wstawione tamże są dostępne lokalnie. W przypadku jakichkolwiek błędów wszytko mogę sprawdzić czytając z tych samych baz i serwisów, co testerzy, zamiast żmudnie reprodukować lokalnie.

I potem się okazuje, że tester bawił się z uprawnieniami, zasymulował śmierć babci - i twój pracowicie zrobiony przypadek testowy poszedł się rypać. Akurat na demo. (coś podobnego miałem).

  • W pewnym zakresie darmowe testy wydajnościowe.

To jest najlepsze. Jakie testy wydajnościowe, jak wszyscy korzystają w tym czasie ze wspólnej infrastruktury. To jak robienie odcinka specjalnego WRC w centrum Warszawy w godzinach szczytu. Co te testy mierzą? Jak można porównywać ich wyniki?
Przeważnie kończy się to raczej: panowie dziś miedzy 13:00-15:00 nikt nic nie tyka, bo beda robione testy wydajnościowe (autentyk).

  • Brak big-bang deploymentów i związanego z tym gaszenia pożarów.

Mocki nic przecież nie mają wspólnego z big bang deployment. WTF? Raczej jest stałe gaszenie pożarów, bo wrzucenie drobnej, experymentalnej zmiany na DEV kończy się krzykiem z sąsienich zespołów, że im nie działa.... Nie możesz np. przetestować kawałka infrastruktury z nowymi serwisami itp.

  • Cntionous integration na poziomie organizacji, a nie tylko pojedynczej aplikacji.

Ja to przerabiałem i to był continuues desintegration. Testy e2e były wywalone przez pół roku - zawsze coś było nie tak i nie dawało się ustabilizować (przy 150 developerach i 120 aplikacjach zawsze ktos coś grzebie).


jeden i pół terabajta powinno wystarczyć każdemu
edytowany 8x, ostatnio: jarekr000000
somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:3 dni
  • Lokalizacja:Wrocław
0
jarekr000000 napisał(a):

Ale mockowanie i to całkiem zaawansowane - wszelkich systemów zewnętrznych to podstawa. Bez tego straty na "czekaniu" (bo ktoś coś spierd... ) są zbyt duże.

To jest mnie niż minuta czekania, bo tyle trwa przywracanie poprzedniej wersji z panelu TeamCity.

Zresztą nie muszą to być stricte mocki, jak zapewnisz mi jednoklikowe postawienie całej infrastruktury na moim kompie to jestem jak najbardziej na tak.

Ty chyba w ogóle nie czytasz tego, co ja piszę. Zupełnie nie chodzi mi o to, żeby mieć wszystko łatwo postawione u siebie.

Ale większe użycie sieci i potencjalnych problemów z tym związanych. (np. paskudnie wolne działanie lokalnej aplikacji).

Ok, tak się czasem może stać. Akurat nie u mnie, bo straty na transferze przez sieć nadrabia przetwarzanie na nieco lepszych niż developerska maszynkach w chmurze.

I potem się okazuje, że tester bawił się z uprawnieniami, zasymulował śmierć babci - i twój pracowicie zrobiony przypadek testowy poszedł się rypać. Akurat na demo. (coś podobnego miałem).

No, ale jak pisałem, to jest jakiś problem albo z testerem albo z tym, że macie jedną babcię do testów. Nie wiem, kto zarządza babciami do testów, ale może da się ich załatwić więcej... babcie nie są drogie. Ale ok, rozumiem, że w jakimś tam specyficznym przypadku u Ciebie tak to nie może działać. Ja mam o tyle łatwiej, że po prostu sam sobie klientów tworzę.
Nie rozumiem tylko czemu brak testowych użytkowników wymusza stosowanie mocków. Jak na moje proste rozumowanie, to są to niezależne kwestie.

To jest najlepsze. Jakie testy wydajnościowe, jak wszyscy korzystają w tym czasie ze wspólnej infrastruktury. To jak robienie odcinka specjalnego WRC w centrum Warszawy w godzinach szczytu. Co te testy mierzą? Jak można porównywać ich wyniki?

Dlatego napisałem "w pewnym zakresie". Nie chodzi mi o mierzenie szybkości przetwarzania requestów, ale np. o to, że jeśli na naszym środowisku user na którym chodzą testy integracyjne ma zrealizowanych 100 tys zamówień i da się bez problemu przeglądać ich historię, to znaczy, że z typowym klientem na produkcji też nie będzie problemu.

Przeważnie kończy się to raczej: panowie dziś miedzy 13:00-15:00 nikt nic nie tyka, bo beda robione testy wydajnościowe (autentyk).

Ja też - ale tylko tam, gdzie były mocki. Po zgaszeniu pożarów po big-bang deploymencie można było dopiero zacząć testowanie wydajnościowe.

Mcoki nic to przecież nie mają wspólnego z big bang deployment? WTF?

Skoro mocki stosuje się po to, aby móc pisać kod dla nieistniejącej zależności, to gdy ona w końcu powstanie, to zostanie na raz wdrożona w całej swej okazałości. To jest big-bang deployment.
I z tym przede wszystkim kojarzą mi się mocki, bo coś takiego przeżyłem kilka lat temu. Przez 1,5 roku soft był tworzony w oparciu o mocki, a potem przyszedł faktyczny system i wszystko stanęło w miejscu, bo okazało się, że poza standardowymi rzeczami takimi jak niezgodność formatów danych po serializacji, to autoryzacja trwa 5 minut.
To było 3 lata temu, na produkcję wyszli jakoś na wiosnę tego roku. Tyle w temacie braku chorób bez mocków.

Raczej jest stałe gaszenie pożarów, bo wrzucenie drobnej, experymentalnej zmiany na DEV kończy się krzykiem z sąsienich zespołów, że im nie działa....

Nie ma żadnego DEV. Są środowiska zespołów: Dev1, Dev2 ... Dev150. Na każdym środowisku zespół rozwija swój soft i ma zainstalowane zależności innych zespołów. Nikt z drugiego zespołu swoimi eksperymentami nie zepsuje mi mojego środowiska. Może się to stać dopiero, gdy my sobie zainstalujemy nową wersję oficjalnie stabilnej zależności. Wtedy trzeba przywrócić poprzednią wersję, a autorom zgłosić buga.

Nie możesz np. przetestować kawałka infrastruktury z nowymi serwisami itp.

Mogę - robię Dev151, albo raczej korzystam z jakiegoś porzuconego środowiska.

Ja to przerabiałem i to był continuues desintegration. Testy e2e były wywalone przez pół roku - zawsze coś było nie tak i nie dawało się ustabilizować (przy 150 developerach i 120 aplikacjach zawsze ktos coś grzebie).

A u nas jest 350 developerów, 200 serwisów oraz 800 narzędzi pomocniczych, do tego kilkanaście stron www i jakoś wszystkie testy działają. W ogóle wszystko jest stabilne, na produkcji także.

jarekr000000
  • Rejestracja:ponad 8 lat
  • Ostatnio:29 minut
  • Lokalizacja:U krasnoludów - pod górą
  • Postów:4707
1
somekind napisał(a):

Ok, tak się czasem może stać. Akurat nie u mnie, bo straty na transferze przez sieć nadrabia przetwarzanie na nieco lepszych niż developerska maszynkach w chmurze.

Ty nie wiesz jaką ja mam maszynę :-) Prawda jest taka, że u głownego klienta nie mogę jednak na niej developować.

Skoro mocki stosuje się po to, aby móc pisać kod dla nieistniejącej zależności, to gdy ona w końcu powstanie, to zostanie na raz wdrożona w całej swej okazałości. To jest big-bang deployment.
I z tym przede wszystkim kojarzą mi się mocki, bo coś takiego przeżyłem kilka lat temu. Przez 1,5 roku soft był tworzony w oparciu o mocki, a potem przyszedł faktyczny system i wszystko stanęło w miejscu, bo okazało się, że poza standardowymi rzeczami takimi jak niezgodność formatów danych po serializacji, to autoryzacja trwa 5 minut.
To było 3 lata temu, na produkcję wyszli jakoś na wiosnę tego roku. Tyle w temacie braku chorób bez mocków.

I tu leży pies pogrzebany. Zupełnie nie przyszło mi nawet do głowy developowanie na mockach bez ciągłej weryfikacji z normalnymi serwisami. Skąd ten pomysł? Ja sobię głównie programuje na mockach na mojej maszynie (zresztą przestawiam czasem wajchy na realne, bo np. testuje nową wersję serwisu). Natomiast i tak każdy push leci na takiego deva dla mojego zespołu. Czasem tam zaglądam nawet.
I tam już mamy różne walki z innymi zespołami - najczęsciej związane z security. zwykle przywrócenie czegoś trwa... pół dnia (taką ma infrastukturę klient, najlepsze jak wywali się przy tym jenkins (czyli odpowiednik teamcity :-) ) ). Dla mnie jest wązne, że mogę iść (prawie) zawsze z developerką do przodu, również jak jestem w pociągu w tunelu (ważny problem pierwszego świata).

Z dodatków:
Częśc tych mocków to sa całkiem ciekawe symulatory - potrafią wygenerować mi w parę minut ruch i dane, który prawdziwi testerzy i systemy musieliby robić przez 3 dni. Co więcej na lokalnej maszynie robię sobie clean - czyszcze wsie bazy danych i za pare minut mam system postawiony od nowa. Z danymi testowymi na czysto od konkretnej daty. Niektórych ficzerów (przez dość skomplikowane obliczenia) nie byłbym w stanie przestestować na realnym devowym środowisku. Wyszłyby mi liczby, których nie mógłbym w rozsądnym czasie zweryfikować, za dużo danych, a tak wiem jakie dla mam mieć wyniki i jak mają się prezentować w GUI wykresy na dany dzień. Współczuje białkowym testerom, którzy to musza na faktycznych danych z systemu sprawdzać, mają chyba excele cięższe niż mój kod backendu.

Podsumowując: z pewnością chęć do mocków wynika czasem z takiej sobie infrastruktury u niektórych klientów. Ale mam te mocki/symulatory nawet tam gdzie infrastruktura jest całkiem dobra, albo prosta - np. zależę od raptem jednego serwisu. Mam kilka tuneli na trasie do pracy, mój symulator potrafi przez parę minut wygenerować ruch za cały rok - co świetnie pozwala mi sprawdzać działanie systemu pod obciążeniem, na mojej prywatnej 8kilowej chmurze.

EDIT:
Tak się składa, że po prostu prawcowąłem już w różnych systemach - tylko realne połączenia z serwisami, do bólu i wszystko zamokowane( z zewnętrznych połączeń). Druga wersja na tyle przypadła mi do gustu, że jest w liscie pytań do pracodawcy (i do obecnej firmie trafiłem, bo pokazali mi te mocki). Gdybym nie jeździł po konferencjach i nie spędził wielu smutnych godzin czekając na to aż goście z infrastruktury coś naprawią, bo im się omskło - to może bym nie miał takiego podejścia.


jeden i pół terabajta powinno wystarczyć każdemu
edytowany 7x, ostatnio: jarekr000000
Kliknij, aby dodać treść...

Pomoc 1.18.8

Typografia

Edytor obsługuje składnie Markdown, w której pojedynczy akcent *kursywa* oraz _kursywa_ to pochylenie. Z kolei podwójny akcent **pogrubienie** oraz __pogrubienie__ to pogrubienie. Dodanie znaczników ~~strike~~ to przekreślenie.

Możesz dodać formatowanie komendami , , oraz .

Ponieważ dekoracja podkreślenia jest przeznaczona na linki, markdown nie zawiera specjalnej składni dla podkreślenia. Dlatego by dodać podkreślenie, użyj <u>underline</u>.

Komendy formatujące reagują na skróty klawiszowe: Ctrl+B, Ctrl+I, Ctrl+U oraz Ctrl+S.

Linki

By dodać link w edytorze użyj komendy lub użyj składni [title](link). URL umieszczony w linku lub nawet URL umieszczony bezpośrednio w tekście będzie aktywny i klikalny.

Jeżeli chcesz, możesz samodzielnie dodać link: <a href="link">title</a>.

Wewnętrzne odnośniki

Możesz umieścić odnośnik do wewnętrznej podstrony, używając następującej składni: [[Delphi/Kompendium]] lub [[Delphi/Kompendium|kliknij, aby przejść do kompendium]]. Odnośniki mogą prowadzić do Forum 4programmers.net lub np. do Kompendium.

Wspomnienia użytkowników

By wspomnieć użytkownika forum, wpisz w formularzu znak @. Zobaczysz okienko samouzupełniające nazwy użytkowników. Samouzupełnienie dobierze odpowiedni format wspomnienia, zależnie od tego czy w nazwie użytkownika znajduje się spacja.

Znaczniki HTML

Dozwolone jest używanie niektórych znaczników HTML: <a>, <b>, <i>, <kbd>, <del>, <strong>, <dfn>, <pre>, <blockquote>, <hr/>, <sub>, <sup> oraz <img/>.

Skróty klawiszowe

Dodaj kombinację klawiszy komendą notacji klawiszy lub skrótem klawiszowym Alt+K.

Reprezentuj kombinacje klawiszowe używając taga <kbd>. Oddziel od siebie klawisze znakiem plus, np <kbd>Alt+Tab</kbd>.

Indeks górny oraz dolny

Przykład: wpisując H<sub>2</sub>O i m<sup>2</sup> otrzymasz: H2O i m2.

Składnia Tex

By precyzyjnie wyrazić działanie matematyczne, użyj składni Tex.

<tex>arcctg(x) = argtan(\frac{1}{x}) = arcsin(\frac{1}{\sqrt{1+x^2}})</tex>

Kod źródłowy

Krótkie fragmenty kodu

Wszelkie jednolinijkowe instrukcje języka programowania powinny być zawarte pomiędzy obróconymi apostrofami: `kod instrukcji` lub ``console.log(`string`);``.

Kod wielolinijkowy

Dodaj fragment kodu komendą . Fragmenty kodu zajmujące całą lub więcej linijek powinny być umieszczone w wielolinijkowym fragmencie kodu. Znaczniki ``` lub ~~~ umożliwiają kolorowanie różnych języków programowania. Możemy nadać nazwę języka programowania używając auto-uzupełnienia, kod został pokolorowany używając konkretnych ustawień kolorowania składni:

```javascript
document.write('Hello World');
```

Możesz zaznaczyć również już wklejony kod w edytorze, i użyć komendy  by zamienić go w kod. Użyj kombinacji Ctrl+`, by dodać fragment kodu bez oznaczników języka.

Tabelki

Dodaj przykładową tabelkę używając komendy . Przykładowa tabelka składa się z dwóch kolumn, nagłówka i jednego wiersza.

Wygeneruj tabelkę na podstawie szablonu. Oddziel komórki separatorem ; lub |, a następnie zaznacz szablonu.

nazwisko;dziedzina;odkrycie
Pitagoras;mathematics;Pythagorean Theorem
Albert Einstein;physics;General Relativity
Marie Curie, Pierre Curie;chemistry;Radium, Polonium

Użyj komendy by zamienić zaznaczony szablon na tabelkę Markdown.

Lista uporządkowana i nieuporządkowana

Możliwe jest tworzenie listy numerowanych oraz wypunktowanych. Wystarczy, że pierwszym znakiem linii będzie * lub - dla listy nieuporządkowanej oraz 1. dla listy uporządkowanej.

Użyj komendy by dodać listę uporządkowaną.

1. Lista numerowana
2. Lista numerowana

Użyj komendy by dodać listę nieuporządkowaną.

* Lista wypunktowana
* Lista wypunktowana
** Lista wypunktowana (drugi poziom)

Składnia Markdown

Edytor obsługuje składnię Markdown, która składa się ze znaków specjalnych. Dostępne komendy, jak formatowanie , dodanie tabelki lub fragmentu kodu są w pewnym sensie świadome otaczającej jej składni, i postarają się unikać uszkodzenia jej.

Dla przykładu, używając tylko dostępnych komend, nie możemy dodać formatowania pogrubienia do kodu wielolinijkowego, albo dodać listy do tabelki - mogłoby to doprowadzić do uszkodzenia składni.

W pewnych odosobnionych przypadkach brak nowej linii przed elementami markdown również mógłby uszkodzić składnie, dlatego edytor dodaje brakujące nowe linie. Dla przykładu, dodanie formatowania pochylenia zaraz po tabelce, mogłoby zostać błędne zinterpretowane, więc edytor doda oddzielającą nową linię pomiędzy tabelką, a pochyleniem.

Skróty klawiszowe

Skróty formatujące, kiedy w edytorze znajduje się pojedynczy kursor, wstawiają sformatowany tekst przykładowy. Jeśli w edytorze znajduje się zaznaczenie (słowo, linijka, paragraf), wtedy zaznaczenie zostaje sformatowane.

  • Ctrl+B - dodaj pogrubienie lub pogrub zaznaczenie
  • Ctrl+I - dodaj pochylenie lub pochyl zaznaczenie
  • Ctrl+U - dodaj podkreślenie lub podkreśl zaznaczenie
  • Ctrl+S - dodaj przekreślenie lub przekreśl zaznaczenie

Notacja Klawiszy

  • Alt+K - dodaj notację klawiszy

Fragment kodu bez oznacznika

  • Alt+C - dodaj pusty fragment kodu

Skróty operujące na kodzie i linijkach:

  • Alt+L - zaznaczenie całej linii
  • Alt+, Alt+ - przeniesienie linijki w której znajduje się kursor w górę/dół.
  • Tab/⌘+] - dodaj wcięcie (wcięcie w prawo)
  • Shit+Tab/⌘+[ - usunięcie wcięcia (wycięcie w lewo)

Dodawanie postów:

  • Ctrl+Enter - dodaj post
  • ⌘+Enter - dodaj post (MacOS)