Przemyślenia dotyczące projektu

[konik32]

Niech każdy napiszę swoje przemyślenia dotyczące projektu (na wzór tego jak zrobił to Bartek): podział na moduły, algorytm wyszukiwania, technologie jakie moglibyśmy użyć(frameworki, biblioteki) oraz cokolwiek innego co wam przyjdzie do głowy. Piszcie w komentarzach

[rampler]

A więc ja bym to widział tak: Projekt składałby się z czterech modułów, a mianowicie:

• Robot przeszukujący oferty i zapisujące je do bazy.
• Serwer, który kategoryzuje te dane i "uczy się", które byłby najtrafniejsze dla użytkownika.
• Klient instalowany, który wysyła zapytania do serwera o oferty i otrzymuje od niego odpowiedź.
• Klient webowy, który ma tą samą funkcjonalność.

Pierwsze powinniśmy zacząć od bazy danych - encje itp oraz komunikacji serwer-klient, a mianowicie jak wygląda interfejs. Potem myślę, że spokojnie można się podzielić pracą i każdy moduł dla testów używałby Mocków. Jak to by działało już porządnie to myślę, że z połączeniem nie byłoby dużego problemu.

To oczywiście tylko moje spojrzenie jak można się do tego zabrać i czekam, aż ktoś inny się jeszcze wypowie.

[ghost]

Na wzór tego co zrobił bartek :+1: I jeszcze okejka :+1: za nazwę bo bardzo mi się podoba. ;D

To w końcu mamy ten temat 9 czy jeszcze będą jakieś zmiany? Trochę z nudów napiszę Wam moje przemyślenia odnośnie tego tematu jakby czasem okazało się, że nie ma licytacji i na 100% mamy ten i już nic się nie zmieni. ;p

W mojej ocenie temat 9 jest całkiem ciekawy. Głównym problemem będzie napisanie algorytmu Web Content Mining, którego zasada działania jest nawet podobna do rozpoznawania obrazów. Metody klasyfikacji są różne (np. genetyczny algorytm, svm, jakieś inne specjalistyczne metody etc). Jednak zasada jest taka sama - trzeba pobrać zawartość, wybrać pewne charakterystyczne cechy z tekstu, wyciągnięte cechy poddać klasyfikacji, sprawdzić wynik klasyfikacji. Żeby nauczyć klasyfikator rozpoznawania to ofc potrzebny jest zbiór danych do nauki.

Żeby ponownie nie popełnić błędu, że nie mamy kompletnie nic do pokazania to trzeba zwiększyć nacisk na frontend. Im więcej jakiś animacji, wykresów, kolorków tym będzie bardziej widać, że coś robimy. A ludzie odpowiedzialni za algorytm, pierwszą rzeczą jaką powini zrobić to wyciągnięcie danych na sztywno z konkretnej witryny (załóżmy ,że będzie to np. gumtree, może jest tam jakiś div z klasą "oferta" i go wybrać na pałe) - tak, żeby było coś do pokazania, a później dopiero przeszlifować algorytm, który sam się nauczy rozpoznawania tego typu rzeczy.

Można by podzielić się tak:

jedna osoba pisze klienta (np. Mateusz zrobi jakieś ekstra nowoczesne GUI) - będzie łączył się z serwerem na określonym porcie, będzie mógł się zalogować na konto, pobrać swoje oferty, będzie rysował wykresy. Jakieś wodotryski jeszcze whatever. jedna osoba napisze serwer (mogę to zrobić ja) - serwer będzie łączył się z bazą danych, sprawdzał użytkowników, ogarniał połączenia z klientami, pobierał oferty z bazy i wysyłał klientom, dodatkowo dla podanego linku będzie pobierał zawartość strony i przez interfejs odpalał algorytm, na podstawie algorytmu będzie podejmował czy dana strona zawiera ofertę i ewentualnie będzie przypisywał ją użytkownikowi jedna czy dwie osoby (np. Tomek jako grafik i ktoś kto ogarnia php czy coś innego) mogą ogarnąć wypasiony interfejs webowy dla serwera, byłby to klient ale webowy - jako ficzer. Wiem, że jest napisane, że użycie tylko przeglądarki jako klienta jest niepełnym rozwiązaniem zadania - ale jako dodatek do klienta normalnego byłby to fajny ficzer do pokazania, że np. na telefonie można łatwo odpalić czy coś. jedna osoba musiałaby ogarnąć bazę danych oraz wszystkie potrzebne do niej zapytania, później ten ktoś musiałaby ogarnąć zbiór danych do nauki (czyli przejrzeć i zgromadzić portale i wyciągnąć z nich oferty, obczaić strukturę) reszta zakadziłaby algorytm i każda z powyższych osób po skończeniu swojej części dochodziła by do tej części. Najpierw jakiś algorytm pobierający na pałe informacje z konkretnego serwisu. Później przeszukanie w internetach metod WCM i implementacja jednej z nich.

Nie jestem PM ale zarzucam tylko takie moje przemyslenia związane z tematem, żeby było nad czym podyskutować. Proponowałbym też w najbliższym czasie jakoś spotkać się i przedyskutować temat, naszkicować bazę danych, przemyśleć i określić interfejsy (co będzie chyba najważniejsze, żebyśmy jakoś się później złączyli) oraz wybrać technologie dla każdej osoby.

A kolejnym moim przemyśleniem jest to, że znacznie lepsza będzie grupa na fb, a nie czat, bo jak przyjdzie nam odszukać informacji już opisanych to przygniecie nas ich natłok.

[ghost]

... chociaż w sumie OfferSucker też by było dobre. ;D

@rampler Natchnąłeś mnie do pytania odnośnie klienta webowego. Czym można by to było łatwo ogarnąć, żeby serwer wystawiał tylko jedno API dla wszystkich i można by się było komunikować z nim z aplikacji w JAVA czy w PHP? Jakiś SOAP, JSON, REST? Nie znam się na tym. Tak żeby się nie dublować z kodem.

Można by jakieś takie JSONowe wiadomości wysyłać. Przykład Three-Hand-Shake do logowania: K->S: { "header" : "loginSYN", "content" : { "username" : "XXX", "passwd" : "YYY" } } S->K: { "header" : "loginSYN/ACK", "content" : { "SID" : "3409924AFFBBAAA123" } } K->S: { "header" : "loginACK", "content" : { "SID" : "3409924AFFBBAAA123" } }

I później każdy kto ma deal'a do serwera to wysyłałby wiadomość z SID, np.: K->S: { "header" : "suckOfferByDate", "content" { "SID" : "3409924AFFBBAAA123", "DATE" : "1992-01-01T00:00" } } a jak na serwerze przestanie istnieć SID to klient nie będzie mógł wykonać operacji i będzie musiał zalogować się jeszcze raz.

Macie jakiś lepszy pomysł na taką współpracę serwera z dowolnym źródłem?

[bambalooon]

Nie jestem pewien jak jest w komunikacji PHP używając SOAP, ale wydaje mi się, że z RESTem nie ma problemów - niech wypowie się ktoś, kto zna te technologie.

W każdym razie - w Javie nie byłoby problemu stworzyć takie API, w REST byłoby pewnie szybciej i sprawniej.

Co do logowania to JAVA jest w stanie przenieść to na osobną warstwę i odebrać nam część tej roboty - na pewno w SOAPie, w REST raczej też - bawiłem się tym trochę na projekt do Rogusa, spróbuje to sobie przypomnieć.

Edit: W REST da się zrobić tą autoryzację.

[rampler]

@bartQH Myślę, że najlepiej to byłoby JSONem puścić (najlepsze wsparcie w wielu językach ma) w formacie takim jak napisałeś lub jako pseudo wywołanie funkcji tj.

{"function": "getBlaBla", "parameters" : {jakaś tablica parametrów}}

Wtedy nawet po najprostszych socketach moglibyśmy to wysyłać, bez zaciągania zaawansowanych technologii. REST też nie jest złym pomysłem tylko czy wszyscy to ogarną? Btw. Planujemy to jakoś szyfrować, czy dajemy sobie z tym spokój? I czy w ogóle potrzebujemy logowania?

[bambalooon]

REST może przyjmować i zwracać JSONa. Pominąłbym szyfrowanie, ponieważ jest to w cholere roboty, na różnych serwerach różnie, masa kombinowania - jak nie wymaga to nie pchajmy się w to bagno.

[ghost]

@bambalooon a 2xRSA wysłane w pytaniu SYN przez klienta oraz odpowiedzi SYN/ACK przez serwer nie wystarczy? Klient zaszyfruje sobie swoim, serwer rozszyfruje sobie swoim i odwrotnie. RSA wygasa z końcem sesji, a samo szyfrowanie rozpoczyna się zaraz po ACK. Można traktować wtedy publiczny klucz klienta jako jego ID, a publiczny serwera jako SID. Tylko też pytanie czy jest sens używać tego szyfrowania.

@rampler Ładne!

EDIT: @rampler - a format odpowiedzi? :P A co powiesz na nadbudowanie request/response?:

{ "req" : {"getOffer" : { ...params... }} } { "res" : {"Offer" : { ...offer... }} }

EDIT2: Początkowo myślałem, że linki będą gromadzone i przydzielane użytkownikom (stąd też profile), a serwer będzie wysyłać tylko oferty dla konkretnego użytkownika. To co z tym logowaniem?

[konik32]

Jeśli REST to bez logowania. Każde zapytania posiada Headera to autoryzacji, przynajmniej tak to przeważnie robiłem. Pominąłbym szyfrowanie. Co do zapytań, jeśli zdecydujemy się na RESTA to powinniśmy się trzymać standardów czyli zapytania przesyłać w GET z parametrami.

Co do mojej wizji całości. Algo:

• z głównej strony przeszukujemy wszystkie linki
• na podstronach wyszukujemy takich samych elementów po ich klasach. W każdym znalezionym elemencie sprawdzamy czy jego rodzic ma klasę, która również się powtarza jeśli tak przechodzimy w górę do ostatniego. Pobieramy cały element dajemy użytkownikowi do oceny. Po pierwsze użytkownik sprawdza czy jest to w ogole ogłoszenie. Po drugie zaznacza fragment tekstu i wybiera z rozwijanego menu czy jest to cena, powierzchnia, stan produktu itd.. Dopiero po ocenie użytkownika pobieramy ogłoszenia tego typu z 10 pierwszych stron i zapisujemy jego treść w odpowiednich miejscach w tabeli zgodnie z zaznaczeniami użytkownika
• pobrane ogłoszenie(tytuł, tekst) indeksujemy np Hibernate Searchem
• użytkownik podaje słowa kluczowe, które go interesują. Zapisujemy je w bazie. Po pobraniu nowych ogłoszeń puszczamy sobie zadanie, które przeszukuje nowe ogłoszenia po słowach kluczowych poszczególnych użytkowników i zapisujemy ich id w tabeli. Użytkownik odpala program i sprawdza nowe ogłoszenia poprzez zapytanie. Wysyłamy je JSON.

Baza:

• zaprojektować ją trzeba, ale raczej nie klepałbym jej w SQL czy w jakimś designerze. Skorzystałbym z ORM.

Serwer:

• Serwer powinien się łatwo odpalać. Jeślibyśmy się zdecydowali na JAVA, moglibyśmy postawić applikację na Jettym, unikniemy deployowania. Pare osób pisało, że znają Springa, więc moglibyśmy skorzystać ze Spring Boota, ułatwilibyśmy sobie w znacznym stopniu konfigurację.
• Wolałbym nie rozdzielać serwera i algorytmu wyszukiwania na dwie aplikacje. Nie musielibyśmy sprawdzać czy, któreś z nich się wywaliło. Do odpalania algo, użylibyśmy schedulera (ja używałem Quartz Scheduler).
• W przeszukiwaniu neta i zapisywaniu ofert do bazy, jak i w wybieraniu ofert uzytkownikowi mogłby się przydać Spring Batch

Klient:

• nie możemy użyć przeglądarki, ale zawsze można poszukać dobrego silnika do renderowania html i odpalić go w naszej apce. To zależy od tego czy mamy kogos kto się zna na technologiach webowych i chciałby to klepnąć.

Język:

• jeśli chodzi o serwer i algo to użyłbym jednego języka. Model w tych dwóch modulach będzie ten sam. Szkoda pisać dwa razy

Trochę chaotycznie, ale mam nadzieję, że do zrozumienia.

[gkostalkowicz]

Serwer. Zdecydowanie Java.

Klient. Przede wszystkim trzeba zminimalizować ilość pracy, tak żeby klient był możliwie jeden na Windowsa i Linuxa.

• Java prawdopodobnie odpada (ma być Qt/GTK).
• .NET/Mono prawdopodobnie też (C# nie ma wymienionego w językach)
• Wyrenderować HTML w naszym okienku. Trzeba się go skonsultować, czy się tak da.
• Qt lub GTK działają i na Win, i na Linuxa. Pytanie, czy nie wymaga to "pre-instalowania innego oprogramowania poza dostępnym standardowo w systemie windows" co jest zakazane.
• wxWidgets
• W najgorszym przypadku 2 klienty, ale żeby jak największą część wspólną.

Jeśli ktoś chciałby zrobić różne dodatkowe "ficzery" (dodatkowego klienta webowego, szyfrowanie połączenia itd), jestem zdecydowanie przeciw. Wystarczająco dużo pracy mamy w tym semestrze, a nasz temat jest jednym z trudniejszych. Im więcej ficzerów, tym więcej pracy rozkłada się na każdego z członków zespołu - przede wszystkim zróbmy "podstawkę", a potem się zobaczy, czy ktoś ma czas i chce kontynuować, ma to sens? :)

[ghost]

@worldofpiesels w QT czy GKT do katalogu z plikiem wykonywalnym .exe wystarczy dodać odpowiednie biblioteki .dll, więc instalacja nie powinna być problematyczna.

[bambalooon]

@worldofpiesels Zgadzam się całkowicie z minimalizowaniem pracy - zróbmy podstawę, będzie czas to się będzie rozbudowywać, nie będzie to będziemy mieli produkt do pokazania i ładna trója.

Jeśli chodzi o tego klienta - to jako, że mamy te wymagania 'rozjaśnić' z klientem, to może warto spróbować przekonać klienta do rozwiązania javowego/webowego, tak jak w realu - w końcu klient to często wieśniak z ulicy co chce zajebisty system, co zarobi dla niego miliony :P

Co do argumentów za Javą, to: mniej czasu zajmuje zaprogramowanie tego, jest dostępny od razu na wielu platformach, w realu - "mniejszy koszt", programowanie klienta w C++ w tym przypadku jest tak bardzo bez sensu.. Przecież to kurwa nie jest program do grafiki 3D!

Co do argumentów za webowymi: jak wyżej + jest dostępny na każdym urządzeniu z dostępem do neta - a patrząc na charakter naszego projektu - to przecież o to kurwa chodzi! Klient nie zna się w ogóle na biznesie :P