Wybieramy technologię

[Stanley]

Cześć wszystkim! Dostaliśmy zadanie stworzyć serwis internetowy, który będzie służyć wolontariuszom i sekcji wolontariatu w przygotowaniach do ŚDM w Krakowie. Oczywiście chcielibyśmy żeby w jej tworzenie zaangażowało się jak najwięcej wolontariuszy, dlatego próbujemy dotrzeć do jak największej liczy osób zainteresowanych pomocą z pytaniem: W jakiej technologi powinna być pisana strona, żeby Twój wkład w nią był największy?. Proszę uzasadnij swoją odpowiedź, napisz jakie masz doświadczenie w tej technologi i dlaczego uważasz, że wszyscy inni wolontariusze-programiści powinni się nauczyć akurat tego języka lub frameworku. Waga Twojego głosu będzie zależała między innymi od wymiaru czasowego który zadeklarujesz się przeznaczyć na tworzenie tej strony. Ostateczną decyzję musimy podjąć najpóźniej do końca lutego.

Oto wstępna lista rzeczy które będziemy implementować (może ulec zmianie):

• Publiczne profile wszystkich zarejestrowanych w systemie wolontariuszy.
• Konta dla administratorów, który mogą logować się i zmieniać dane wolontariuszy.
• Logowanie i edycja swojego profilu dostępna dla wszystkich wolontariuszy w systemie.
• Możliwość rejestracji nowych wolontariuszy przez formularz na stronie.
• Integracja z bankiem pracy.
• Publiczne API na potrzeby aplikacji mobilnej.
• Grupy wolontariuszy tworzone przez administratorów, którymi zarządzają opiekunowie grupy.
• Możliwość wysyłania wiadomości przez administratorów i opiekunów grupy do wolontariuszy.

Weź pod uwagę wymagania jakie musi spełnić strona, żeby była przydatna dla ŚDM:

• Musi być niezawodna nawet przy dużym obciążeniu.
• Musi być testowalna, to znaczy że każdy programista będzie potrafił napisać test do swoich zmian.
• Musi być łatwa w utrzymaniu, gdyż wiele osób będzie chciało pomóc.
• Musi być bezpieczna, gdyż dostęp do niektórych danych musi być ograniczony.
• Musi być szybka, gdyż ma pomagać ludziom w pracy, a nie przeszkadzać im w niej.

Z wymagań bardziej praktycznych, strona musi komunikować się z bazą danych [ElasticSearch](), bo taka baza już istnieje.

Czekam na wasze propozycje i ewentualne pytania.

[jjaracz]

Moim zdaniem najlepszą opcją będzie napisać serwer aplikacji w JAVIE. Wtedy jedna grupa może się zająć frontednem a druga backendem, było by na 2 serwerach, na jednym apache czy cokolwiek a na drugim tomcat do javy, a później to tylko podpiąć. Oczywiście jest wiele więcej korzyści wynikających z tego faktu np, bezpieczeństwo, prędkość, skalowalność.

[milkowski]

Osobiście najbardziej preferuję Lua/LuaJIT i platformę http://turbolua.org/ za szybkość i prostotę, ale jak znam życie będzie to zbyt egzotyczne (póki co... ;)) dla większości webmasterów. Natomiast na pewno egzotyczny nie jest JavaScript i osławiony już node.js, ze swoją gigantyczną bazą wtyczek, skryptów i frameworków na https://www.npmjs.com/, więc mój głos na node.js + ustalenie konkretnie co i do czego z npm będziemy wykorzystywać.

[dorotafilipczuk]

Myślę, że frontend w JavaScripcie + backend w Javie (lub w Pythonie) byłyby dobrym pomysłem ze względu na to, że są dość popularne, jak wyżej wspomniano - nie byłoby to zbyt egzotyczne.

[Stanley]

Dzięki za dotychczasowe opinie. Myślę, że pora na mnie :)

Zastanawiałem się nad Javą po stronie serwera, ze względu na jej popularność, ale z drugiej strony @milkowski ma rację w tym, że JavaScript też nie jest niepopularny, zwłaszcza wśród osób które zajmują się tworzeniem stron internetowych. Sam znam JavaScript dużo lepiej niż jakikolwiek inny język (ponad 3 lata doświadczenia zawodowego), więc to wpłynie na to, że będę czuł się z nim bardziej komfortowo jako osoba odpowiedzialna za całość kodu. Po stronie klienta nie mamy wyboru i musimy pisać w JavaScript, więc użycie tej technologii ułatwi wejście w projekt osobom, które dopiero uczą się programowania, bo nie będą ograniczeni tylko do klienta lub tylko do serwera (a będą takie osoby). Kolejnym argumentem za JavaScriptem jest możliwość dzielenia kodu klienta i serwera. To jest zakładając, że podejmiemy odpowiedni wybór bibliotek. A biblioteką która daje taką możliwość jest np.: React.js, która pomaga w tworzeniu interface-u. Ponieważ nie wymaga środowiska przeglądarki do działania, pozwala na renderowanie html-a również na serwerze w środowisku io.js (dawniej Node.js). Jest to sprawdzone rozwiązanie działające w produkcji od dłuższego czasu w takich stronach jak Facebook, Instagram, Netflix i Airbnb. Cechą wspólną zespołów tworzących wymienione strony jest to, że są duże, a React.js jest świetny do pracy w takich warunkach, bo wymusza pisanie kodu jako niezależne komponenty, które łącząc się ze sobą tworzą całość. Aby móc skorzystać z komponentu nie musimy znać szczegółów jego implementacji. Każdy moduł może być testowany niezależnie od całości aplikacji, gdyż jego stan (dane na których operuje) jest dany na wejściu.

Podsumowując Jestem za tym, żeby całość aplikacji - poczynając od komunikacji z bazą danych po renderowanie strony i interaktywne funkcje strony były pisane w języku JavaScript. Narzędziem które mogło by pomóc nam w osiągnięciu tego celu jest React.js działający na serwerze w środowisku io.js i w bezpośrednio przeglądarce oraz inne biblioteki pod npm typu express.js jako web framework. Deklaruję zaangażowanie w ten projekt na średnio 10 godzin w tygodniu.

[jjaracz]

Można to napisać w pythonie, bardzo prosty język do nauki a przy tym bardzo elastyczny. Do tego można, jak już byśmy w tym pisali, napisać coś na raspberry pi i zrobić coś ciekawego bo tam też głównie pisze się w pythonie. Deklaruje zaangażowanie +/- 6 godzin tygodniowo i chęć pisania aplikacji na andka :) Chociaż js nie jest złym rozwiązaniem, to jakoś nie mam zaufania do tego języku po stronie serwera.

[Stanley]

Chociaż js nie jest złym rozwiązaniem, to jakoś nie mam zaufania do tego języku po stronie serwera.

Skąd się bierze ten brak zaufania? Myślę, że wiele ludzi ma zły obraz tego języka, ale jeżeli weźmiemy pod uwagę tylko V8 (implementacja JavaScripta, z której korzysta io.js/node.js) to okaże się, że jest to zdecydowanie najszybszy język skryptowy jaki mamy do dyspozycji. Pisanie w tym środowisku jest znacznie łatwiejsze niż na przeglądarkę, bo nie trzeba wspierać żadnych innych wersji języka. Poza tym, V8 (Chrome) to od lat flagowy projekt Google, firmy która jak mało kto inwestuje w bezpieczeństwo.

Mając solidne testy, będziemy mogli spać spokojnie, nawet mając aplikację w JavaScript. Gwarantuję :wink:

[devcateu]

To i ja dodam swoje 3 grosze :) Jestem jednak za Java + JavaScript. Argument jest w sumie prosty. Dla mnie JAVA jest znacznie czytelniejsa od JavaScriptu. Bieże się to zapewne stąd, że lubię języki silnie typowane. Inny 'ZA' może być fakt, że dzięki takiemu posunięciu w ten projekt mogą wejść zarówno osoby znające tylko JAVA jak i te tylko ze znajomością JavaScipt. Deklaracja czasu +/- 6h/week

[jjaracz]

Po prostu zawsze pisałem w js po stronie klienta i myślę że trudno byłoby mi się przestawić. Wiem, że jest szybki i wgl ale jednak dla tych co piszą w językach typu c++ i java było by ciężko. Ja jednak jestem zdania żeby js został po stronie klienta. Oczywiście popieram @slawekK91

[jjaracz]

Chwila chwila, może niech każdy określi się w czym pisze i czy woli języki słabo czy silno typowalne. Ja piszę w: Java + android, js, css, html, php, zaczynam pythona i wole języki silno typowalne.

[Stanley]

Lista języków typowanych statycznie które kompilują się do JavaScript :wink:

[devcateu]

@Stanley chciałbyś którąś z części prowadzić w jednym z języków wymienionych w linku ? Widzę parę problemów w tej kwestii : 1) kompilacja do JavaScriptu będzie powodowała nadmiarowość - coś co zostanie skompilowane do 10 linijek JS, w JS mogłoby być napisane w 7, czasami wręcz są dodawane nadmiarowe instrukcje, 2) wybraną część (serwer albo klient) należałoby prowadzić wyłącznie w wybranym języku, w innym wypadku mielibyśmy bałagan w kodzie - takie mixełko/spaghetti :) i też nikt nie mógłby zmieniać coś w wygenerowanych plikach, bo jego zmiany by poprostu przepadły, Czy te języki mogą wywoływać metody napisane w JS ? 3) czy technologię, o których wcześniej wspomniałeś są dostępne z poziomu tych języków ? czy do ich wykorzystania byłoby wymagane użycie JS ? 4) Czy jest jakaś dodatkowa pracochłonność związana z komwertowaniem ? Są jakieś ogarnięte środowiska do pisania w nich ?

Z innej beczki: znana jest ilość wolontariuszy (oczekiwana/przewidywana) ?

[Stanley]

Nie, ja bym nie chciał żeby aplikacja (ani nawet jej część) była pisana w języku kompilowanym do JavaScript, ale tylko chciałem stwierdzić fakt, że to jest taka opcja. Być może takie rozwiązanie byłoby sensowne gdybyśmy uznali, że żeby nikogo nie faworyzować, wybieramy język którego nikt z nas nie zna i uczymy się razem :) (btw. dla mnie to nie jest problem nauczyć się nowego języka). Zleży mi tylko na tym, żeby język był optymalny do zadania które mamy wykonać, a pamiętajcie, że naszym zadaniem jest stworzyć stronę internetową. HTML i operacje na DOMie są natywne dla JavaScriptu, dlatego współgrają ze sobą lepiej od web frameworków w których HTML jest zwykłym ciągiem znaków.

Liczbę wolontariuszy przewiduje się na 20000 osób z Polski i 5000 z zagranicy.

[devcateu]

@Stanley No właśnie nie wiedziałem za bardzo o co Ci chodzi z tym linkiem - podesłałeś i tyle. Co do tego co należy zrobić to ja jeszcze pamiętam, że ma to być strona internetowa ;) JAVA też ma opeację na DOM-ie ;) Myślę o JAVA tylko w kontekście servera. Klient jak najbardziej w JS. Wiem, że niszczyło to zacny plan dzielenia kodu między klientem a serverem. Jednak nie wydaje mi się, żeby takich rzeczy było dużo. Na pewno modele ale czy coś jeszcze ?

Abstrahując od tego. Część funkcji klienta odpowadającą za renderowanie przerzuciłbym na przeglądarkę. W sensie wysyłać tam model i renderować. Co do samego takiego działania wiem, ze jest możliwe w Angularze( w React.js też się tak da?). Jednak poza podstawami Angulara nie znam. Co o czymś takim myślicie ?

[Stanley]

Zróbmy porównanie konkretnych technologii, bo do tej pory nie padły nazwy żadnych konkretnych bibliotek i trudno ustosunkować mi się do niektórych argumentów. Na wiki powstała strona Porównanie technologii. Każdy kto ma propozycję niech ją tam wpisze w nowej kolumnie.

JAVA też ma opeację na DOM-ie

W teorii tak, ale w praktyce jest nieużyteczny bo nie wspiera bibliotek z których będziemy korzystać po stronie klienta (z tego względu, że on oczywiście nie są w Javie tylko w JavaScript), typu np. jQuery.

Wiem, że niszczyło to zacny plan dzielenia kodu między klientem a serverem. Jednak nie wydaje mi się, żeby takich rzeczy było dużo. Na pewno modele ale czy coś jeszcze ?

Tak, oczywiście :) Plan jest taki, żeby dzielić widoki.

[pkasperczyk]

Witajcie, Dla mnie może być java (serwer) i javascript (klient) ew. z Angularem. Choć może też być wszystko w javascript, ale mam bardzo małe doświadczenie. Deklaruję ok. 5-10h w tygodniu.

[milkowski]

Moje 2 gr. do całej dotychczasowej dyskusji. Po pierwsze ten projekt ma być "rock solid" i "fast and reliable", więc nie ma tu miejsca na eksperymenty ani uczenie się czegokolwiek, jakiekolwiek propozycje "z ciekawości" to niewłaściwy adres. Osobiście jestem fanatycznym wyznawcą reguły KISS i wrogiem wszelkiego overengeeneringu, czyli utrudniania sobie życia i proszenia się o kłopoty. Pytanie zasadnicze jest takie: kto jak dobrze zna proponowaną technologię/język i na ile jest w stanie się zaangażować, bo chyba lepiej mieć pewny i doświadczony zespół ekspertów jednego języka niż rozjechany design kilku "fajnych" technologii nad którymi nikt do końca nie panuje i robi się zmierzający ku klęsce patch-overdriven-development.

@stanley jako osoba odpowiedzialna, a także z tego co zdążył już napisać i zaproponować widać, że zna JS jak własną kieszeń, co i jak się robi i dzięki temu będzie mógł sensownie panować nad całością, nawet jeśli dołączą się osoby niedoświadczone wrzucające "głodne kawałki kodu" wołające o pomstę do nieba. Dobrze zorganizowany framework testowy, który po krótce nakreślił, będzie tutaj nieoceniony.

RasberryPi jest fajne, sam siedzę w embedded, ale to zupełnie nie ten projekt i nie ta liga zastosowań (nawet serwer-farmy na ARM-ach buduje się inaczej), BTW w mikrokontrolerach można od jakiegoś czasu pisać i w Pythonie (http://www.micropython.org) i w JavaScripcie (http://www.espruino.com/), ale Java to już zbyt duży bloat i tu dochodzimy do drugiej kwestii - wydajność.

Tak wiem, Java potrafi być szybka, jak już się ma dostatecznie duże środowisko. Trudno mi na ten moment prognozować obciążenie jakie będzie wymagane i nie wiem gdzie i jak to ostatecznie zostanie "zwodowane", ale jeśli nie znajdzie się naprawdę mocna ekipa, która w razie czego będzie potrafiła zapanować nad całym środowiskiem i profilować zdalnie wąskie gardła albo debugować kod, to jest to proszenie się o kłopoty. "Mi się podoba" to jeszcze za mało. Jest kwestia organizacji środowiska testowego, ujednolicenia metodologii i stosowanych koncepcji, żeby nie skończyło się na nieustannym przepisywaniu hierarchii klas "bo X zrobił tak a ja muszę mieć tak, bo tak jest lepiej".

Typy statyczne kontra dynamiczne to temat rzeka, który nie prowadzi do jednego słusznego wniosku, więc sobie go daruję. Generalnie więcej tu zależy od zastosowania, wygody i doświadczenia programisty niż samego języka.

node.js/io.js mają tą zaletę nad konkurencją, że dysponują gigantyczną, dobrze zarządzaną i scentralizowaną bazą gotowych - i co najważniejsze sprawdzonych w poważnym boju - komponentów do użycia (czyli mniej potencjalnych błędów) i jednocześnie jest to lekkie środowisko, w którym można tworzyć aplikacje jak z klocków, używając tylko niezbędnych elementów i olewając niepotrzebną resztę (tu przytyk do opasłego na dzień dobry JVM Javy).

I na koniec pytanie z gatunku egzystencjalnych: skoro i tak będziemy stosować JS to warto się dodatkowo rozdrabniać? Tu już każdy niech sam sobie odpowie.

Podsumowując moim zdaniem JS bo:

• prostota projektu,
• większość kodu już jest napisana trzeba go tylko zebrać do kupy i dostosować,
• doświadczenie w zespole (organizator),
• jasna metodologia testowa w "zwirtualizowanym" i lekkim środowisku io.js agregującym zarówno kod po stronie klienta jak i serwera (czyli można przetestować całość w jednym odpalonym VM V8, bez przeglądarki)
• wyjątkowo bogata i zróżnicowana baza komponentów do wyboru oraz frameworków do ich łączenia (padła propozycja experss.js)
• większość kodu na MIT/BSD (przepraszam, nie mogłem się powstrzymać, np. z javowym jbossem już tak różowo nie jest ;))

Póki co mogę zadeklarować 5h tygodniowo.

[jjaracz]

Widzę, że js jak na razie króluje. To ja mogę się zająć aplikacją na andka z grupą entuzjastów JAVY.

@milkowski z raspberrym chodziło mi żeby np. zrobić taką stację w naszej bazie która wyświetlała by projekty do zrealizowania albo cokolwiek zintegrowane ze stroną. Jakbyśmy pisali stronę w pythonie to każdy mógłby napisać coś na raspberrego co mu wpadnie do głowy.

[milkowski]

@jjaracz To jest całkiem rozsądny pomysł. Przydadzą się niezależne aplikacje na Androida i iOS-a (ktoś lubi C# i Windows Phone? Taka Java tylko z MS. :)), komunikujące się z backendem np. przez JSON-a.

PS. Nie wiem czemu Ci się malinka kojarzy tylko z Pythonem, może akurat takie jej zastosowania widziałeś, ale np. Google Coder robi z niej zabawkę dla webmasterów JS (a nawet konsolę do web-gier :)) http://googlecreativelab.github.io/coder/ A tak w ogóle to pazury pokazuje dopiero w gdy się jej dobierze do trzewi. ;) http://www.raspberrypi.org/tag/bare-metal/

[jjaracz]

Kojarzy mi się akurat z pythonem bo ma niezłą komunikację z gpio i pełno bibliotek do elektroniki której używam :) A poza tym można na nim postawić oprócz tego stronę albo restowe api i całkiem przyjemnie komunikować się z hardware i przy tym jest dziecinnie prosty :)

[devcateu]

@milkowski Cóż by rzec jak nie to, ze dobrze gadasz ;) Niestety JS znam słabo. Pewnie gdyby było inaczej podzielałbym Wasz optymizm. Co do samej technologii chciałem proponować : SPRING + jakiś framework JS-owy typu Angular/React. Jednak z tego co czytam w Waszych komentarzach JS w całym projekcie jest też dobrym pomysłem. Także świetną dla mnie okazją do nauczenia się czegoś nowego (i może zmiany zdania o JS).

[Stanley]

@slawekK91 mógłbyś dodać swoje propozycje do https://github.com/Krakow2016/wolontariusze/wiki/Por%C3%B3wnanie-technologii? To nasza oficjalna lista ;)

[Stanley]

Wielkie dzięki wszystkim za udział w dyskusji! Nadszedł czas na podjęcie ostatecznej decyzji. Biorąc pod uwagę wasze głosy oraz wszystkie za i przeciw o których można przeczytać w internecie, doszedłem do wniosku, że językiem, który najbardziej pomoże nam w realizacji naszych celów jest JavaScript. Będziemy korzystać z niego zarówno po stronie serwera - poprzez platformę node.js (lub jej nowszą wersję io.js) oraz oczywiście po stronie przeglądarki.

W najbliższym czasie rozpiszę zadania które mamy do zrobienia w formie Issues, które każdy z was będzie mógł wziąć na siebie. Zachęcam wszystkich którzy jeszcze tego nie zrobili do śledzenia tego repozytorium, gdyż z czasem znajdzie się praca dla każdego ;)

Dobór bibliotek, styl kodowania i dokumentacji, techniki testowania itp. będziemy wypracowywać na bieżąco razem wraz z rozwojem projektu. W razie jakichkolwiek pytań, wątpliwości i uwag zachęcam bardzo gorąco do używania funkcji komentarzy na GitHubie - zarówno to do pojedynczych linijek kodu, całych commitów oraz issues. Mam nadzieję na owocną współpracę :sunflower:.