Global Azure Bootcamp we Wrocławiu! 2017-logo-200x135

Witamy w pierwszym odcinku codingtv();!

Dzisiaj przedstawimy jaki projekt będziemy tworzyli w ramach codingtv();, narzędzia z jakich będziemy korzystali oraz zaplanujemy sobie zadania na następne odcinki.

Zapraszamy do oglądania i czekamy na Wasze komentarze.

Zgodnie z obietnicą przedstawiamy również linki do narzędzi:

34 komentarze

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

  • Bardzo dobry początek 🙂

    Zapomnieliście tylko wspomnieć że:
    – Użytkownik chciałby zobaczyć komentarze

    Czekam na następne odcinki

  • Cool:)
    Prosiliście o komentarze więc oto co mi do głowy wpadło:
    * sql server express jest „poważną, produkcyjną” bazą, tyle że darmową:)
    * blog powinien mieć RSS (chyba ze to juz zaliczymy do integracji)
    * do testów jednostkowych ja osobiście polecałbym xunit…
    * …a do mocków moq lub nsubstitute (rhino było fajne kilka lat temu, ale czasy się zmieniają)
    * i ostatnie: „włĄczać” a nie „włANczać”:) na litość szatańską

  • Panowie, świetny pomysł, właśnie czegoś takiego brakowało na polskiej ziemi 😉

    Ogólnie fajny temat projektu, do tego TDD, mocki – ekstra.

    Co ile planujecie wypuszczać nowe odcinki?

    • cieszymy się, że pomysł się spodobał 🙂 Na początek chcemy nagrywać jeden odcinek tygodniowo – później zobaczymy jakie będzie zainteresowanie.

  • @Marcin – cieszymy się, że pomysł się spodobał 🙂 Na początek chcemy nagrywać jeden odcinek tygodniowo – później zobaczymy jakie będzie zainteresowanie.

  • Proponuję lepszy mikrofon bo S w wydaniu kolegi z lewej strony jest strasznie bijące po uszach.

    Reszta zapowiada się bardzo fajnie. Zobaczymy jak wyjdzie w praniu. No i popieram procent-a precz z rhino.

  • Dobry pomysł. Czekam na kolejny odcinek.

    Może jeszcze mała krytyka: jako fotografa-amatora, razi mnie takie ustawienie kamerki. Niepotrzebnie dużo przestrzeni nad wami.

    • Krytyka jest najcenniejsza bo pomaga nam eliminować błędy 🙂 postaramy się coś z tym fantem zrobić następnym razem

  • Tak wybiegając w przyszłość. W jakiej technologii będzie tworzony blog? ASP.NET MVC czy WebForms?

  • Świetny pomysł. Mam tylko jedną uwagę. W podsumowaniu odcinka tak jak podaliście linki, można by wypisać najważniejsze pojęcia + linki do wikipedi gdzie można by szerzej poczytać o danym pojęciu.Nie zawsze z języka mówionego można zrozumieć że mówicie o TDD, Scrum itp.

    Pozdrawiam

    • Faktycznie, od strony realizacji nagrania jeszcze sporo pracy przed nami. Mamy nadzieję zacząć zmiany już od przyszłego odcinka.

  • Witam,

    gratuluję pomysłu oraz trzymam kciuki za kolejne produkcje.
    Do narzędzi dodałbym koniecznie StructureMap lub inny odpowiednik dla DI (Dependency Inversion).
    Czekam na kolejne odcinki.

    Pozdrawiam,
    Marek

  • Super! Czekam na kolejne odcinki.

    Mam nadzieję, że bedzie też jakieś sprytne wyczukiwanie i np. tagowanie wpisów dla SEO, a może nawet integracja z Lucene.NET 😉

    • Ciekawa propozycja. Z jej realizacją będziemy musieli jednak poczekać jeszcze kilka odcinków 😉

  • Fajna inicjatywa, kilka uwag:
    – zgadzam się całkowicie z Procentem – xUnit mógłby być, ale zdecydowanie Moq – Rhino Mocks fatalnie się używa,
    – faktycznie jakiś kontener DI by się przydał np. Castle Windsor lub prostszy Autofac,
    – i na miły Bóg – nie uczcie ludzi robienia komentarzy GhostDocem – kod trzeba pisać tak, aby komentarze były zbędne – polecam coś takiego jak Clean Code, a jeżeli są potrzebne, to na pewno nie te automatycznie generowane.

    • Na temat komentarzy słyszałem już wiele teorii. Czas poznać tą ogłoszoną w Clean Code.

      Nie wiedziałem, że GhostDoc ma takie kiepskie opinie. Zgadzam się (co zresztą podkreśliłem w nagraniu), że łatwo można wpaść w zły nawyk akceptowania wszystkiego co podpowiada to narzędzie. Jednak zawsze czytam i uzupełniam to co wyprodukuje GD w zależności od potrzeb. Jednak w obecnej sytuacji najprawdopodobniej zrezygnujemy z tego narzędzia, aby nie promować złych praktyk 🙂

    • Popieram Procenta, GhostDoc bee, nawet nie pokazywac tego programista bo potem dostaje sie dokumentacje „Get User Id By E-mail” do metody GetUserIdByEmail.

  • Bardzo dobry pomysł ;), będę śledził wasze poczynania – dobrze bo do tej pory górowały anglojęzyczne strony tego typu.
    + za ASP.NET MVC

    „Rhino Mocks fatalnie się używa” <– true;

  • Bardzo podoba mi się inicjatywa! Próbowałem do swoich projektów już kilku sposobów na zbieranie wymagań i nadal spisanie tego co chcę robić nie idzie mi najlepiej więc fajnie byłoby gdybyście zaprezentowali w działaniu jakieś poważniejsze narzędzie niż notatnik 😉

    • Bardzo dobry pomysł. Rozważymy kilka możliwości – issue tracker zintegrowany z CodePlex, Mantis, Trac. Decyzja zapadnie niebawem.

  • Sporo zostało już powiedziane, ale dodam coś od siebie:
    – Rhino Mocks, dopóki nie zacząłem używać Moq też wydawało mi się rozsądną propozycją 😉
    – komentarze … jeśli nie tworzycie API które ma być reużywane na dużą skalę, to nie ma co opisywać kolejnych metod/klass, lepiej skupić się w tym czasie na ich readability 😉 Komentarze w kodzie – UNIKAĆ i jeszcze raz unikać, również polecam książkę Clean Code. Piszmy kod tak aby nie trzeba było pisać komentarzy (i ich utrzymywać !!)

    Do modelowania (jeśl planujecie) polecam narzędzie Visual Paradigm for UML Community Edition 😉

    Pytanie czy planujecie używać jakiegoś systemu wersji? Może GIT 😉

    Przy dodaniu historii: Jako użytkownik chcę filtrować listę wpisów, tutaj wydaja mi się że analiza poszła za daleko w tym etapie. Jeśli chcemy mieć prosty blog w pierwszej fazie to dla każdej funkcjonalności określamy wszystko tak prosto, jak tylko się da 🙂

    Na koniec gratuluje pomysłu i początkowej realizacji 🙂

    • Dzięki za sugestie.
      Co do mocków – chyba nie odrobiliśmy zadania domowego i wybraliśmy to co wydawało nam się popularne. Jak wynika z kilku już komentarzy – wydawało nam się 🙂
      Komentarze w kodzie – zawsze staram się komentować bardziej skomplikowane kawałki kodu a także klasy i metody. Faktycznie przydatne jest to głównie kiedy planujemy udostępnić API. Choć muszę przyznać, że nawet własny kod lepiej mi się czyta jeśli są w nim objaśnienia w istotnych miejscach. Clean Code nie czytałem, chyba więc najwyższy na to czas.
      O modelowaniu na razie nie myśleliśmy.
      Repozytorium – najprawdopodobniej będzie to CodePlex, więc skorzystamy również z istniejącego tam issue trackera.

  • Bardzo fajna inicjatywa. Jako początkujący programista .NET na pewno będę widzem Waszego videobloga. Czegoś takiego brakowało w Polskim internecie. Dlaczego tylko zagraniczne blogi muszą obfitować wartościowe screencasty? Jedyne do czego mam zażalenia to kiepska jakość dźwięku. Może dałoby się coś z tym zrobić? 🙂

    Pozdrawiam twórców i innych zaintereoswanych 🙂