@wysuszony: Sam nie wiem. @duxet naprawił póki co ze dwa, twierdzi że więcej, ale ściemnia bo nie działają te jego poprawki.
TLDR: To nie jest tak, że nikt ich nie naprawia. Po prostu duxet szybciej je tworzy niż naprawia. Zwykle programiści robią więcej błędów w nowych funkcjach, dux ma odwrotnie - talent do niszczenia stabilnych funkcji :D
To chyba takie ćwiczenie i próba udowodnienia sobie, że nie oszalałem. Nie wiem ile razy rozmawialiśmy o tym, że zniszczenie starych dobrych funkcjonalności bo "migracja do..." jest idiotycznym pomysłem. Teraz po raz chyba 3 w tym roku znów stajemy przed tym samym, na skalę niewyobrażalną. Na strimoidzie działa mniej funkcjonalności niż rok temu.
Jak chciałem dla niego testować wersje rozwojowe to on miał inne plany. Potem narzekał, że nikt nie testuje (sorry, wszystkim się znudziło nawet używanie produkcji), a teraz jak wrzucam konkretne bugi to reakcja taka bez szału... chociaż może to wina tego, że nie działają powiadomienia, albo dodawanie komentarzy? :D
Próbowałem to tłumaczyć kilkanaście razy, ale widzę, że to wciąż jest czarna magia dla niektórych. Pokrycie kodu testami automatycznymi to REWELECYJNY krok, ale po prostu niewystarczający. Nie można na produkcję pchać kodu bez jakiegokolwiek testu. Tylko w tym roku złapałem duxa wielokrotnie (pomimo jego zapewnień) na pchaniu na produkcje wersji które nie potrafią robić podstawowych rzeczy, np.: rejestracja, logowanie, dodanie komentarza itd.
@szarak: no to Twoim zdaniem pozostawanie przy Mongo, które się jednak nie sprawdziło byłoby lepszym pomysłem?
@duxet: nie, mysql jest lepsze, widac na oko, że działa szybciej i płynniej cały portal, ale ta migracja wywołała trzesienie bugów
@akemo: no niestety, trzeba prawie cały kod przepisać, mógłbym to robić na osobnym środowisku i testować samemu, ale wtedy dalej by były komentarze, że nic się nie dzieje...
@duxet: Prawdę mówiąc wbrew powszechnej opinii nie uważam, że mongo było błędem. Przecież dzięki niemu przez długi czas (ile, półtora roku?) używaliśmy serwisu pracującego na kalkulatorze zasilanym ogórkami kiszonymi i byliśmy z tym szczęśliwi. Mongo po prostu zrobiło co miało zrobić kiedy miało zrobić.
Ale przyszedł czas, że trzeba było z niego wyjść bo serwis zaczął mulić, a mongo zaczęło więcej ograniczać niż pomagać.
To całkowicie normalna sytuacja w każdym projekcie. Inaczej mogą ściemniać tylko ludzie którzy robią głupkowate gierki "wypuść i zapomnij". Każdy projekt który istnieje dłużej trzeba utrzymywać, modyfikować.
Więc i migracja powinna być robiona jak normalny krok w rozwoju serwisu. Nie można wypieprzyć 60% funkcji bez uprzedzenia i liczyć że nikt nie zauważy. Czasem przejście z jednej technologii do drugiej może być cięższe niż napisanie serwisu od nowa, ale jakoś nie widzę, żeby duże produkty były porzucane na pół roku bo "piszemy nową wersję".
@szarak: a z drugiej strony pracuje przy 4 projektach opensource, każdy ma ponad 500 UU dziennie i żaden nie ma testów, 90% zgłoszeń to feature-request ;)
@akemo: jakich testów? Użytkownika, czy automatycznych? A może w ogóle nie ma testów? :D
Zauważ że w tym konkretnym projekcie opensource (bo rozumiem, że takim strimoid się stał) w ostatnim czasie zainteresowanie kodem portalu jest ograniczone do jednej osoby. Nikt prócz duxeta nie pracuje jawnie na wersjach rozwojowych, wszystko wchodzi błyskawicznie na PROD a po błędach jakie napotykamy widać, że duxet ostatnio nawet nie sprawdza przed chwilą wprowadzonych poprawek.
@akemo: jakich testów? Użytkownika, czy automatycznych? A może w ogóle nie ma testów? :D
żadnych, w ogóle.
@akemo: ale przecież ludzie robią Wam testy. Jak można pieprzyć takie głupoty. Sam dla Ciebie zrobiłem dziś kilka. To, że ludzie pobierają soft i zgłaszają błędy to nie testy? To, że developer po wprowadzeniu poprawki kompiluje kod i patrzy czy to co zrobił w ogóle zadziałało to nie testy?
Chyba nie powiesz mi, że w 4 projektach ludzie napierdzielają kod i nie sprawdzają czy zadziałał :D