Hej,
Zabrałem się ostatnio za prowadzenie bloga. Tematyka: programowanie / JEE. Byłoby mi miło gdyby brać z NW zerknęła swoim fachowym okiem i wyraziła swoją opinię / uwagi / zachętę / krytykę / cokolwiek :). Jeśli ktoś nie nie jest zainteresowany tematem, to nie pogardzę też bezinteresownym poklikaniem po blogu, podbicie hit count zawsze mile widziane :)
http://howtotrainyourjee.wordpress.com
pozdro, hf
Modle się, żebyś chociaż ty nie dostał chujowego pocisku na twarz od bandy debili, jak to ostatnio bywa...
bezinteresownie poklikalem, podbijam i zostawiam posta bez hejtu
szkoda ze to java (bleh...), no ale mimo wszystko powodzenia =]
+1 za odniesienia do V for Vendetta
-1 za w sumie wszystko inne :/
Przejrzalem na szybko i nie wiesz o czym chcesz pisac.
Piszesz o tym jakie sa role w metodyce scrumowej, piszesz jakie IDE bedziesz uzywal i piszesz ze napisals strone w PHP w notatniku. Co mnie to interesuje?
Zamiast napisac posty w stylu:
Scrum VS np inne metodyki zwinne. Albo scrum a wsparcie Javy do TDD. A ty mi tlumaczysz kim jest scrum master do tego niestety nieudolnie. Po co?
Zamiast zrobic porownanie IDE ty piszez ze uzywasz Eclipsa od 5 lat... Super. Co mi po tej wiedzy?
Zamiast zrobic porownanie roznic GIT VS SVN ty piszesz ze uzyjesz tego pierwszego bo nowsze XD
I nie doszukalem sie prawie niczego o JAVIE.
Sry mate. Nie bede czytal.
Zrób listę zagadnień, które poruszasz i umieść ją w widocznym miejscu (nawet jako link do postu) - taku spis treści.
Na końcu postu pisz, co będzie w kolejnym wpisie.
Postuj w ustalonych terminach (np. wtorek i czwartek o 19).
Blog nie jest obiektywnym opisem technologii/tutorialem tylko subiektywnym sprawozdaniem z podejścia do projektu/luźną dywagacją dookoła, więc piszę o własnych doświadczeniach / historiach.
To jest kila wstępnych postów przed projektem. Nakreślam metodykę / technologię / narzędzia na ogólnym poziomie, jeśli wymieniam ich w jednym poście 10 to nie będę analizował dokładnie każdego wyboru bo zajęłoby to zbyt dużo miejsca na tym etapie.
Napisałem, że użyję Gita bo jest a) popularniejszy b) siedzę w svn od 5 lat i mi się nudzi. Pewnie w przyszłości napisze coś więcej o wybranych technologiach / narzędziach i wtedy będzie czas na porównania z innymi w danej kategorii.
Anyway, dzięki za feedback, doceniam :)
to jest twoj blog i pisz co Ci sie podoba. 99% userow nic nie stworzylo przez cale swoje asrane zycie, a wylewaja zale. gud lak z projektem
#7 jeśli piszesz to wyłącznie dla siebie jako pamiętniczek to spoko. Jeśli chcesz żeby inni to czytali, to muszą mieć oni z tego jakąś wartość. Jeśli nie chcesz merytorycznie opisywać technologii, różnic i podejść to moim zdaniem zostają Ci 2 wyjścia:
1. Opisujesz case study ze swojego życia i swoich projektów. Piszesz np, że w trakcie projektu oczywiste było zastosowanie technologii X a jednak zastosowaliście Y i opłaciło się bo. Albo zastosowaliście X i wszystko się zjebało bo stało się to i to. Zresztą nie muszę tłumaczyć czym case study jest, ale dobrych opowieści o fuck-upach w projekcie nigdy za wiele :)
2. Dodaj „human touch” do swoich opowieści. Zadbaj nie o treść a o formę. Tutaj za sztandarowy przykład mogę dać link:
http://juniorbrandmanager.blogspot.com
polecam popatrzeć nie tylko na obrazki ale poczytać cykl „pamiętnik napiętego grafika”.
Pisanie bloga pod siebie i o sobie może być dla Ciebie fajnie spędzanym czasem, mieć wartość terapeutyczną(?), możesz w ten sposób systematyzować sobie swoją własną wiedzę dla siebie , ale czytelnikowi nic po takiej formie i nikomu nie będzie chciało się tego czytać.
Moim zdaniem nie piszesz ani dostatecznie „łopatologicznie” żeby noob mógł pójść za Twoim przykładem i stworzyć to co Ty ani dostatecznie „pro” żeby ktoś z doświadczeniem mógł z Twoich tekstów wyciągnąć praktyczne wnioski dla siebie.
EDIT:
Tutaj masz kolejny genialny przykład artykułu z human touch:
http://pando.com/2013/10/26/i-challenged-hackers-to-investig...
Pokazuje jakich technologii używali hackerzy, pokazuje jak to robili, ale opowieść była przede wszystkim o ludziach.
Zmieniony 2014-08-16 11:24:07 przez Vol
#7
I nie musi byc obiektywnym, bo nie ma czegos takiego jak obiektywizm w szczegolnosci jak masz za zadanie wybrac "lepsza" technologie.
Chodzi o to ze twoje wybory nie sa niczym poparte poza "jest nowsze to uzyjmy tego" albo "pracuje w tym 5 lat wiec dalej bede tego uzywal". Nie pokazujesz zadnego procesu myslowego, ktory stoi za twoimi decyzjami.
Tak samo, z tego co zgooglalem na twoj temat, masz certyfikat SM a scruma opisujesz w taki sposob jakbys to pisal na odpierdol sie... z cyklu bede pracowal w scrumie (i jak sam zaznaczasz i dobrze wiesz, jezeli nie spelniasz wszystkiego w agile manifesto to to jest gowno a nie scrum) to opisze role, ktore rownoczesnie bede spelnial. Moje pytanie po co? Nie ma to zwiazku z JAVA, nie tlumaczysz noobka na czym proces scrumowy polega, tym co ogarniaja twoje opisy zdaja sie w najlepszym wypadku lakoniczne.
Wielki plus, ze Ci sie chce. Sam zrobilem jeden wpis i pracuje nad drugim ale moja czestotliwosc pisania na tematy techniczne to 1 artykul na 2 miesiace (jak mam naplyw sily woli zeby sie zmusic) wiec jestem pod wrazeniem ilosci tekstu jakie napisales.
Niestety nie wiem dla kogo jest twoj blog.
Powinienes tez moim zdaniem zmienic platforme na np medium.com, ktore za "darmo" da ci wieksza publicznosc.
Tutaj masz post mortem moje, jednego z projektu, ktory robilem:
https://medium.com/ios-dev/river-news-app-22bee8acee50
Nie jest to bron boze wysokich lotow literatura i tekst, ale zamierzeniem tego artykulu bylo pokazanie jak podejmowac decyzje, jakie byly wersje aplikacji, jak przebiega proces.
Nie zas pisanie o wszystkim po trochu.
co jest na tym blogu czego nie znajde na milionie pozostalych? co cie wyroznia?
Obrazek ze smokiem po każdym poście ^^
Wrzuciłem kolejny post. Tym razem o Product Backlogu i poszukiwaniu odpowiedniego narzędzia do zarządzania nim, starałem się być bardziej merytoryczny i uzasadniać decyzje.
Enjoy
http://howtotrainyourjee.wordpress.com/2014/08/17/the-first-...Blog prosty, a jednak w swojej prostocie wizualnie atrakcyjny i nie odpychający. Duży plus za prowadzenie bloga po angielsku, tym sposobem przyciągniesz więcej wejść.
Co do samej zawartości to się nie wypowiem, bo na temacie się nie znam.
Moim zdaniem idziesz w dobrą stronę, jak będziesz przypominał na NW o nowych postach to zawsze chętnie przeczytam :)
Ale z NW to szczery, czyli moje wątpliwości:
Napisałeś bardziej noob friendly i fajnie, można się z tego czegoś dowiedzieć… Tylko… Jaki jest target bloga? Do kogo piszesz? Gdybym miał odpowiedzieć do kogo był ten wpis skierowany to powiedziałby: żółtodzioba który chce zacząć startup(?).
Dalej nie znam Twoich motywacji do pisania bloga. Jeśli piszesz dla siebie to spoko. Jeśli chcesz być poczytny to moim zdaniem zamiast odpowiadać na pytanie „O czym chcę dzisiaj napisać?” odpowiedz sobie na pytanie „Dla kogo piszę, i o czym ten ktoś mógłby chcieć przeczytać (w tematach na których się znam)?”.
”p.s. I’m using Wikipedia links a lot. It’s not because I’m a noob.”
Przypomniało mi się powiedzenie, które nauczyło mnie by samemu nie pisać takich rzeczy: Z władzą jest jak z pięknem. Jeśli musisz mówić innym że masz władzę to znaczy że jej nie masz.
Zmień favicon jeśli można, masz domyślny wordpressowy :P
Jako wyznawca hakanizmu staram się merytorycznie, bez hejtu, tym bardziej że sam mam mniej expa i jestem w branży na stanowisku juniorskim. Krytykuję raczej dlatego, że sam chętnie poczytałbym coś co mogłoby się juniorowi przydać i poszerzyć wiedzę albo zaciekawić czymś co do tej pory olewałem. Np. cały cykl na temat stawiania środowiska testowego (wiem że nie Twoja bajka, tylko przykład), Jenkinsa, optymalną ilość środowisko testowych, do czego każde z tych środowisk miałoby służyć.
Są to rzeczy które jako junior dostaję od razu przychodząc do miejsca pracy i uczę się ich obsługi, natomiast celowość ich stworzenia („po cholere nam 10 środowisk testowych na których jest ta sama wersja?!”) albo sposób ich postawienie od zera są czymś czym zajmują się seniorzy i coś o czym się nie mówi w pracy ot tak.
---
Kolega z Wrocławia z Quality Assurence ;)
EDIT:
Jako wyznawca hakanizmu staram się merytorycznie, bez hejtu, tym bardziej że sam mam mniej expa i jestem w branży na stanowisku juniorskim. Krytykuję raczej dlatego, że sam chętnie poczytałbym coś co mogłoby się juniorowi przydać i poszerzyć wiedzę albo zaciekawić czymś co do tej pory olewałem.
Np. cały cykl na temat stawiania środowiska testowego (wiem że nie Twoja bajka, to tylko przykład), Jenkinsa, optymalną ilość środowisko testowych, do czego każde z tych środowisk miałoby służyć, itd. Są to rzeczy które jako junior dostaję od razu przychodząc do miejsca pracy, i jedynie uczę się ich obsługi. Celowość stworzenia („po cholere nam 10 środowisk testowych na których jest ta sama wersja?!”) albo sposób postawienie od zera takich rzeczy jest czymś czym zajmują się seniorzy i coś o czym się nie mówi w pracy ot tak. A wiadomo, że taka wiedza nie pójdzie w las ;)
---
Kolega z Wrocławia z Quality Assurence ;)
Właśnie generalnie nie do końca chyba wiem jaki jest mój target. Początkowe założenie było takie, że chcę zrobić full wypas aplikację i dokumentować ten proces na blogu. Nie ma to być taki tutorial od początku do końca i krok po kroku, (screen po screenie co kliknąć w eclipse) bo takich jest od groma na dowolny temat, bardziej ogólny opis procesu developmentu, na co należy zwrócić uwagę, jak sobie radzić z popularnymi problemami + własne refleksje i doświadczenia. Lista wszystkich elementów które trzeba wziąć pod uwagę - czyli co zrobić żeby żeby ruszyć projekt samemu od zera. Taka robota dla seniora.
W miarę jak zaczynam pisać to wychodzi mi chyba więcej dywagacji i ogólnej filozofii poszczególnych elementów tworzenia oprogramowania zgodnie ze sztuką a mniej praktycznego opisu. Ogólnie to chyba szukam odpowiedniego stylu póki co i dlatego może to sprawiać lekko chaotyczne wrażenie.
Nie chcę też z reguły wchodzić zbyt głęboko w jakiś temat (chyba że uznam coś za fajną ciekawostkę), bardziej zaznaczyć że jest coś takiego (np. tool do statycznej analizy kodu) i można sobie poszukać więcej detali jeśli jest się zainteresowanym.
Zmieniłem ikonę bloga, ale to chyba nie przekłada się na favicon, muszę jeszcze pogrzebać.
p.s. gdzie dokładnie pracujesz we Wrocku? ;)
p.s. 2 zachęcam do rozsyłania linka po znajomych developerach, the more the merrier :)
A co stawiania środowiska testowego, to też moja bajka ;) W adżajlu developer powinien być w stanie z grubsza ogarnąć każdy aspekt tworzenia softu, łącznie z testowaniem. Niby mogą być specjaliści od każdej dziedziny (np testy / web design), ale dobrze mieć chociaż ogólny ogląd na wszystko, szczególnie w małych projektach. Bus factor i te sprawy :)
W Merytorykę wpisów się nie zagłębiam bo nie jestem programistą ale...
Czysto technicznie:
1) Za mała czcionka. Twój blog powinien być łatwy do czytania, zadbaj o to żeby na monitorach o większej rozdzielczości się dobrze czytało.
2) Za duże wall of text. Pogrupuj to jakoś, podkoloruj - bez akapitów / zdjęć / przerw / pogrubienia / bulletów (musisz to stosować). (czyta się słabo - monotonnie)
3) Pierwszy akapit powinien być podsumowaniem tego czego osoba czytająca ma się spodziewać w tekście
4) Brak spisu treści
5) Brak możliwości wyszukiwania po kategoriach wpisów (jeżeli piszesz o róznych rzeczach. To powinienem mieć możliwość zawężenia postów do tylko tych o Javie, tylko tych o PHP, Scrum itd.
6) Ze względow SEO. Lepiej jak każdy wpis ma swoją stronę, niż ciągłe scrollowanie. Jeżeli jednak chcesz zachować ten wygląd bloga, postaraj się aby maksymalnie 5 artów było na 1 stronie a potem anchor next.
7) Nie masz podpiętych wtyczek społecznościowych (a to ważne jeżeli zależy Ci na popularyzacji bloga w sieci). Daj ludziom możliwość ćwierkania, udostępniania lubienia czy innego rodzaju interakcji
8) Tytuły - Ważne dla SEO - Jeżeli chcesz, żeby ktoś szukający czegoś w googlach wbił na twoją stronkę musisz zadbać o keywordsy, a więc w przypadku Twojej strony o dobry nagłówek artykułu + powielenie w samej jego tresci paru słów kluczowych
9) Jak bedziesz miał już jakąś grupę ludzi którzy czytają Twoje posty to we wpisach zadawaj pytania, zachęcaj do interakcji
favicon już się ustawił :)
#20 big thx, postaram się zastosować wymienione punkty jak będę miał chwilę na ogarniecie.
#22 np, chętnie pomogę jak coś
Co do zawartosci bloga, to dla mnie (programisty) malo konkretow. Jak juz ktos wspomnial, napisane w stylu: wezme to i to i bedzie fajnie. Nawet dla kogos poczatkujacego raczej nie widze nic, co mogloby go zatrzymac. Jak sam napisales jest troche chaotycznie, ale bede zerkal od czasu do czasu :)
Sam pare wpisow poczynilem, tylko dziedzina raczej niszowa - Mule ESB(chodzi na Javie :) ) Jak ktos ma ochote to zapraszam:
http://blog.poznachowski.plSpoko, póki co się uczę blogowania dopiero, więc będzie lepiej w przyszłości, mam nadzieję :) Ogarnę temat, doszlifuje co trzeba i wymyśle co chcę dokładnie.
Wrzuciłem dziesiąty wpis póki co:
http://howtotrainyourjee.wordpress.com/2014/08/21/into-the-w...
enjoy
"software programmer" to dziwolag niczym z translatora
zmien na:
- software engineer* **
- software developer
- programmer
- computer programmer
* software engineer w np. kanadzie musi posiadac odpowiedni certyfikat i/lub skonczyc studia
** software engineer ma (przynajmniej w teorii i rozumieniu niektorych) inny zakres obowiazkow niz developer/programmer
Faktycznie, dzieki. Juz poprawione.
oo to ja czekam na solid:)
Postaram się max w ciągu 2-3 dni wrzucić :)
Strasznie pobieżnie przeleciałeś te SOLID-y:/ Ktoś, kto już to zna nie ugruntuje i nie potwierdzi sobie wiedzy tym wpisem. Ktoś kto nie zna, raczej poza poznaniem co to w ogóle jest to wiele się nie nauczy. A przecież cały bajer polega na tym, żeby nauczyć się SOLID-a stosować a nie tylko wiedzieć, ze takie coś jest. Bo takich kilku zdaniowych wpisów to całe setki są w necie.
A i OCP nie kłóci się z agilem bo OCP wcale nie wymusza przewidywania możliwości rozwoju danej klasy. Po to masz np. wzorzec dekoratora, zeby ładnie OCP zachowywać. Co nie zmienia faktu, ze głupotą byłoby czasem bawienie się w dekoratory jeżeli chcemy zrobić tylko małą modyfikację w jakiejś metodzie. Bo jak dobrze wspomniałeś, wszystkie zalecenia trzeba traktować z głową.
Hm też się przyczepię do OCP. To nie stoi w sprzeczności z Agile. Raczej odwrotnie. Stosowanie OCP ułatwia częste zmiany w funkcjonalności. "Gwarantuje", że niezbędne zmiany będą miały jak najmniejszy wpływ na istniejący kod.
Napisałem że wydaje się stać w sprzeczności, nie że stoi :)
O każdej zasadzie jeszcze pewnie napiszę więcej w przyszłości. Póki co jest taki bardziej overview i zasygnalizowanie że jest takie coś ogólnie. Nie chciałem robić zbyt długiego wall of text, i tak ten jest najdłuższy ze wszystkich 12 które popełniłem do tej pory.
Ok, tylko juz bylo pisane i napisze jeszcze raz. Musisz siw czyms wyroznic, zeby byc czytanym. Albo pisac o niszowych rzeczach, albo dokladnie w dane zagadnie ie wchodzic, albo pisac o problemach w danym zagadnieniu i jak je rozwiazywac itp. Bo co ma przyciagac do Ciebie czytelnika kiexy podobnych blogow sa tysiace? Chyba, ze piszezz dla siebie. Ale wtedy nie potrzebne sa takie teoretyczne wpisy i lepiej same notatki z placu boju
Noted. Popracuję nad tym.
o nie, ty tez jestes jednym z tych co napierdalaja o scrumie, i glosza jaki to nie jest zajebisty... :/
Bo jest dobry :P Ale są tacy co głoszą że wystarczy mieć scruma i projekt się uda no matter what co jest bzdurą.
Ja uważam że jak ludzie są ogarnięci to i bez scruma będzie dobrze, scrum jest naprawdę dobry jak ma się młody i niedoświadczony team i trzeba ustalić jakiś ordnung bo inaczej sie wszystko rozsypuje.
Jak scrum nie działa to jedynym wytłumaczeniem jest:
https://www.youtube.com/watch?v=XzK2It-TAyQA ja naiwny wciąż wierzę, że gdzieś tam na świecie jest porządnie napisany projekt...
^ ten twoj blog,
uzywasz angielskich slow ale czytanie tego przypomina przypadkowe zjedzenie piasku na plazy. Pocwicz stylistyke i wszystko inne. Chyba, ze jestes osoba opoziona w rozwoju(czego pewnie bys i tak nie wiedzial), wiec pro forma - swietny blog, gratulacje.
TEMAT ZAMKNIĘTY po 2 tygodniach automatycznie.
