So the HP guy comes up to me (at the Melbourne conference) and he says, 'If you say nasty things like that to vendors you're not going to get anything'. I said, 'No, in eight years of saying nothing, we've got nothing, and I'm going to start saying nasty things, in the hope that some of these vendors will start giving me money so I'll shut up'.
--Theo de Raadt
Nowości na moim blogu:
Rzadko widzę sens w zmianie raz napisanych rzeczy. Ale teraz jak raz naszło mnie i postanowiłem odświeżyć swój artykuł "Tips for blogging developers".
Między innymi poprawiłem niespójności; trochę przegrupowałem wskazówki; jedną wskazówkę dodałem, jedną usunąłem. Wynik wygląda tak: https://devsilv.github.io/2020/04/08/tips-for-blogging-developers-v-2.html Nie są to zmiany duże, więc jeśli ktoś czytał wersję nr 1, to tutaj raczej nic nowego nie znajdzie – poza 1 wskazówką odnośnie podsumowywania. Natomiast… jeśli ktoś czekał głównie na poprawę niespójności (o ile tacy są ;) ), prawdopodobnie będzie chcieć przejrzeć.
Bardzo chętnie przyjmę wszelkie oceny, recenzje i w ogóle komentarze. Jestem dumny z tego artykułu o tyle, że jest tak obszerny, a mimo wydaje mi się spójny (a co za tym idzie, uważam go za warty publikacji). To dla mnie duża zaleta jako blogera. Ale być może niektóre wskazówki nie mają zastosowania, lub mają błędne założenia? Chętnie przyjmę krytykę.
Miłego czytania. :)
Przy okazji:
Tak, zdaję sobie sprawę, że obecnie ogólnie może artykuły na moim blogu być ciężko być czytać z uwagi na przynajmniej dwa punkty:
Zmiany na blogu nie są teraz moim priorytetem; niemniej chciałbym to zmienić, gdy tylko znajdę chęci / czas / zapał… Nadto blog używa Bootstrapa, a mnie jakoś nie pasuje zmienianie jego stylów, by pasowały do mojej wizji. Więc zmiana chyba będzie poważniejsza – żeby znów mieć własne style CSS (teraz już może w SASS)…
PS. Oczywiście zapomniałem: pierwsza wersja artykułu tutaj, proszę -> https://devsilv.github.io/2018/07/10/tips-for-blogging-developers.html I jeszcze dla formalności: minęło od jej publikacji ok. rok i 8 miesięcy.
#blog #news #artykuł #github #feedback #język-angielski
PS. Tzn. pisząc o tekście, który "dziś czytają", mam na myśli wersję nr 1 – gdyby ją zaczęli czytać dziś. Inaczej mówiąc: jeśli byłaby tylko jedna wersja, zmieniona, to mogliby mieć wrażenie, że coś usunąłem, a oni stracili możliwość zobaczenia, co. Mogliby być więc zdezorientowani – co usunąłem i dlaczego. A tak – widzą, że nie usunąłem nic, tylko dodałem / zmieniłem. Mogą sami porównać.
Dziś podczas przeglądania zakamarków internetu trafiłem na niedawny krótki artykuł o końcu metodologii wytwarzania oprogramowania: http://testerzy.pl/baza-wiedzy/koniec-metodologii-wytwarzania-oprogramowania (autor: Radek Smilgin, Grupa 21CN).
Dokładnie, chodzi o "koniec" metod SDLC (Software Developement Life Cycle). Ostrożnie zgadzam się z taką tezą, że kurczowe trzymanie się metodyki (jakiejkolwiek) może hamować poprawny rozwój oprogramowania. Niemniej, z filozoficznego – lub może: logicznego – punktu widzenia, trudno mi się zgodzić z wnioskami artykułu, które mówią o dążeniu (czego/czyim dążeniu?) do nieposiadania metodyki (jakiejkolwiek). Nie adaptując żadnych metod jawnie, musimy przecież zaadoptować jakieś niejawnie. Nie można efektywnie pracować, nie posiadając, nazwijmy to, zasad.
O ile kogoś to zaciekawi, to zastanawiam się, co o tym myślicie.
#Oprogramowanie #Metodyka #Software-development #Przemyślenia #Pierwsze-wrażenia #Feedback
Oto, jak człowiek może sobie sam utrudnić życie – https://github.com/devsilv/DevSilv-jsgame-1/issues/7 :D
Zadałem nagle sobie pytanie: jak to ujednolicić?
Co ciekawe, dla wszystkich trzech miejsc są powody, dla których wybrałem właśnie taki zapis. Zawsze denerwował mnie zapis wielką literą bez kropki (szczególnie w języku, który znam mniej niż rodzimy – "hm, to już koniec zdania, czy jeszcze może nie?"), więc:
Żeby nie było, że tylko opowiadam o problemach, a ich nie rozwiązuję, tu kilka przykładowych lektur, gdyby ktoś był zainteresowany tematem:
I ciekawy jestem, jak wy zapisujecie te rzeczy. Czy trzymacie się jednego stylu, czy zasady "wszystko jedno, byle zrozumiale"?
#GitHub #VCS #Konwencje #Styl-pisania #Software-development #Sam-sobie-narobiłem #Feedback
Niedawno zacząłem pracę z GitHubem, mam u siebie trzy "projekty-samouczki" – i już zaczynam odczuwać, jak to jest być contributor do projektów, w których brakuje zarządzania (mówię o własnych). Liczba issues rośnie (dodaję nowe), a liczba pull requests nie (nie naprawiam starych)...
W czym problem – wiadomo, co poprawić, ale nie ma czasu na poprawę. Brakuje zarządzania, czyli kogoś, kto powie: to robimy, tamto nie. Czas nie rozmnoży się przez podział jak komórka; trzeba z pewnych rzeczy zrezygnować. :( Ale… przecież do własnych projektów dodam wszystko, co sensownego przyjdzie mi do głowy.
Dlatego też nie dziwię się, że projekt Coyote (nasze forum) ma na GitHubie 81 otwartych issues, a tylko 1 pull request. Nie chodzi mi tu nawet o to, że zarządzanie nim jest dobre czy złe. Raczej o to, że jakkolwiek to projekt społecznościowy (czyli inna bajka, niż opisałem wyżej), to po prostu też projekt jak każdy projekt, w którym są issues i pull requests. Tak, myślę, po prostu bywa z pisaniem kodu.
Oczywiście należy tu uwzględnić czynnik, że inaczej wygląda zarządzanie projektem w sumie dopracowanym, jakim jest to forum (domniemywam, że mniejsza dynamika zmian – issues przybywa szybko, pull requests raczej nie), a inaczej takim, który dopiero się rozwija (domniemywam, że liczba pull requests powinna gonić liczbę issues). Zakładam tu 1 pull request na 1 issue. Może zresztą 81 to wcale nie tak dużo, szczególnie jak na jedenaścioro contributors?
#GitHub #Coyote #Społeczność #Przemyślenia #Projekty #Software-development #Contributing
Zmora debuggerów?
Przed chwilą NetBeans/C++ wyświetlił mi błąd (błędy?), którego opis po wklejeniu do Worda (czcionka 11) zajmuje 184 strony, jako źródło wskazywana jest biblioteka <algorithm> (ach, ci bałaganiarscy programiści biblioteki standardowej C++, znów o czymś zapomnieli, wypuszczając nową wersję!), a opis błędu zaczyna się tak: "In file included from..." i zawiera same (nie wiem, czy tylko je, nie przeglądałem wszystkich 184 stron) odwołania do bibliotek.
#Oprogramowanie #Debugowanie #Software-development #NetBeans #C++
@MasterOf: nie rozumiem. ;) — @Rado95: czystej filozofii raczej nigdy nie będzie, ale być może w końcu poczuję, że jestem na tyle oczytany, że mogę więcej jej tkać do tekstów technicznych. — @no_solution_found: w tym wypadku uznałem, że zmiana tamtego tekstu byłaby zbyt duża. Poprawić literówki mogę, ale nie usuwać, zmieniać i dodawać zdania czy akapity. Nie mówiąc już o przegrupowaniu punktów. Czytelnicy powinni być pewni, że tekst, który dziś czytają, jest tym samym, co kiedyś czytali. Chodzi mi tutaj nie o semantyczne dopasowanie, na przykład po tytule, a o ich wrażenie.