Archive for Luty, 2013

Luty 22, 2013

Semantyczny rejestr usług sieciowych

- autor: tsissput

Cel projektu

Pomysł na semantyczny opis i wyszukiwanie usług sieciowych nie jest nowy, ale jak dotąd nie powstało rozwiązanie, które spotkałoby się z powszechną akceptacją.  Powodów takiego stanu rzeczy należy upatrywać przede wszystkim w skomplikowanym i trudnym w opisie modelu Big Web Services opartym na protokole SOAP. Sprowadza się on w zasadzie do zdalnego wywoływania metod za pośrednictwem rozbuchanego, nadmiarowego i pod wieloma względami dublującego funkcjonalność protokołów transportowych (np. HTTP) formatu XML, co wiąże się z nieograniczoną dowolnością wykonywanych operacji.  Każda próba wzbogacenia takich usług o informację semantyczną wymaga zarówno dodatkowego powiększenia i tak już „ciężkiej” koperty SOAPowej, jak też bardzo indywidualnego podejścia do semantycznego opisu każdej usługi z osobna.

W związku z powyższym, zdecydowaliśmy się ograniczyć zakres projektu do usług zgodnych z paradygmatem REST. Pozwala to na wprowadzenie swojego rodzaju „wspólnego mianownika” dla opisywanych usług, który wynika ze ściśle określonego związku architektury usług z wykorzystanym protokołem transportowym (praktycznie zawsze HTTP lub HTTPS). Ogromnym ułatwieniem jest tu porzucenie potencjalnie nieskończonej (w przypadku usług typu Big Web Services) przestrzeni możliwych operacji, na rzecz tej, którą tworzą metody protokołu HTTP. Ponadto, w przypadku usług RESTowych, mamy pewność, że zakres operacji jest jasno określony przez adres URL zasobu. Nie jest konieczne wnikanie w ciało żądania by określić na jakich danych wykonujemy jakąś czynność.

Należy wspomnieć, że sam paradygmat REST jest pojęciem o bardzo wysokim poziomie abstrakcji i sam w sobie nie definiuje żadnych szczegółów implementacji usług. W projekcie zakładamy zgodność usług z jego konkretną interpretacją opartą na protokole HTTP, a mianowicie z architekturą zorientowaną na zasoby (ang. Resource Oriented Architecture – ROA). Termin ten został zaproponowany przez Leonarda Richardsona i Sama Ruby’ego w książce Semantic Web Services (wyd. O’Reilly).

verbs

Kolejną rzeczą, na którą należy zwrócić uwagę jest fakt, że koncepcja globalnych rejestrów usług nie zyskała powszechnej aprobaty. Samo skłonienie setek niezależnych podmiotów do utrzymywania takich rejestrów jest zadaniem trudnym. Opracowując nasze rozwiązanie nie kierowaliśmy się ambicjami stworzenia takiego rejestru. Nasza aplikacja jest przeznaczona do użytku w zastosowaniach lokalnych, na skalę pojedynczych przedsiębiorstw czy systemów informatycznych

Semantyka

Ograniczenie się do opisu usług RESTowych pozwoliło na opracowanie stosunkowo nieskomplikowanej ontologii opisującej architekturę zorientowaną na zasoby. Do opisu każdej usługi potrzeba w ogólności trzech elementów:

  • Ontologii REST-HTTP opisującej pojęcia związane z ROA, takie jak: zasób, adres URL, nagłówek HTTP, ciało odpowiedzi, operacja tworzenia zasobu, metoda GET, etc.
  • Ontologii dziedzinowej opisującej biznesową interpretację zasobów. Pojęcia w niej zawarte to na przykład: pacjent, kolejka na badanie, wpis w karcie, grupa krwi, etc. Należy tu wspomnieć, że w ogólności każda usługa może być opisana przy pomocy dowolnej liczby ontologii dziedzinowych, które mogą być łączone w celu poszerzenia opisu semantycznego.
  • Ontologii opisującej konkretną usługę zawierającej przede wszystkim instancje klas zdefiniowanych w pozostałych ontologiach.

Pozwala to na elastyczne mapowanie udostępnianych przez usługi zasobów w kontekście ROA na abstrakcyjne zasoby opisane w ontologiach.

Zakłada się ponadto, że każdy złożony zasób (na przykład Lekarz) interpretowany jako instancja pewnej klasy z ontologii, składa się z pewnej liczby podzasobów atomowych o typach prostych reprezentowanych przy pomocy typowanych literałów.  Zarówno zasoby złożone, jak i atomowe, są wiązane w stosunku 1:1 z pojęciami z ontologii dziedzinowej.

Oto kilka przykładów zapytań w języku naturalnym, które można wyrazić przy pomocy opisanego powyżej zestawu ontologii:

  • Znajdź usługę, która umożliwia pobranie kolekcji pacjentów leczonych na zapalenie płuc bez podawania dodatkowych parametrów
  • Znajdź usługę, która pozwoli na utworzenie nowego zasobu oznaczającego pojęcie pacjent w kontekście kolejki na badanie rentgenowskie, przy założeniu że znam PESEL, imię i nazwisko pacjenta.
  • Dysponuję numerem książeczki ubezpieczeniowej pacjenta. Jakich jeszcze parametrów potrzebuję by wykonać zapytanie tworzące zasób reprezentujący tego pacjenta przy pomocy usługi X?

Implementacja rejestru

Oczywiście sama ontologia to za mało by wykorzystać takie zapytania w praktyce. Dokonaliśmy implementacji usługi RESTowej pozwalającej na wgrywanie ontologii i udostępniającej końcówkę SPARQL  wykorzystywaną do wykonywania zapytań do ontologii.

Wykorzystaliśmy w tym celu bibliotekę Apache Jena udostępniającą interfejsy do manipulacji danych semantycznych i ich przechowywania w bazie danych oraz silnik SPARQL. Interfejst REST usługi oparto na bibliotece Jersey implementującej standard JAX-RS. Widoki stworzono w technologii JSP.

semreg2

Plany na przyszłość

Opracowana aplikacja stwarza szereg interesujących możliwości. Dzięki semantycznemu opisowi publikowanych usług możliwe jest tworzenie klientów aplikacyjnych, które zamiast jawnie wywoływać konkretne usługi posiadać będą jedynie zdefiniowaną w sposób deklaratywny informację o tym jaką operację należy wykonać i na jakim zasobie. Dzięki wykorzystaniu rejestru, potrzebna będzie jedynie informacja o tym, na jakie pojęcie w dziedzinie biznesowej przekłada się dany zasób.

Łatwo sobie wyobrazić sytuację, w której klient pobiera listę dostępnych usług oraz wymaganych przez nie parametrów, a następnie odpytuje rejestr w celu znalezienia usług udostępniających dane, które są potrzebne jako parametry żądania. Jeszcze prostszym zadaniem jest kompozycja formularzy HTML pozwalających na wprowadzenie wymaganych przez usługi danych przez użytkownika. Potencjalnym klientem rejestru jest rozwijany na Politechnice Poznańskiej silnik procesów biznesowych ROsWeL (ang. Resource Oriented Workflow Language).

roswelLogoWidePlainBlack50pxhi

Korzystanie z rejestru zostałoby znacznie ułatwione gdyby opis usług w językach RDF i OWL był generowany w pewnym stopniu automatycznie. Można to zrealizować przy pomocy biblioteki opartej o mechanizm adnotacji w języku Java, w sposób podobny do tego, w jaki na podstawie adnotacji JAX-RS lub JAX-WS generowane są dokumenty WADL i WSDL. W gestii programisty usług pozostałoby wtedy tylko umieszczenie odpowiednich adnotacji semantycznych obok adnotacji JAX-RS definiujących parametry i typy obiektów zwracanych przez usługi.

Powyższe założenia zamierzamy zrealizować w ramach pracy magisterskiej.

Tomasz Niedźwiedź i Paweł Pawłowski

Luty 21, 2013

SignedNetworkGenerator

- autor: tsissput
  • Przemysław Wróblewski 89846
  • Marcin Wojdowski 89843

Program ma za zadanie generowanie sieci z wiązaniami ujemnymi i dodatnimi.

Program realizuje następujący scenariusz:

  1. Załadowanie danych konfiguracyjnych
  2. Pobranie z fabryki NetworkFactory2 głównego algorytmu przetwarzania, impl w pakiecie org.tsiss.sng.network.creators
  3. W zależności od głównego algorytmu przetwarzania klass wspierajacych przetwarzanie. Przykładowe wartości z pliku ApplicationContext:
    1.  ac.getProbability(); – zwraca model prawdopodobienstwa dla procesu tworzenia krawedzi wewnątrz grupy i na zewnątrz(osobne).
    2. ac.getGroupChooser(); – zwraca model wyboru grupy do przydziałów nowych elementów.
    3. ac.getExtNegativeEdge(); – zwraca model wyboru docelowego wierzchołka dla negatywnej zewnętrznej krawedzi
    4. ac.getExtPositiveEdge();- zwraca model wyboru docelowej grupy dla negatywnej zewnętrznej krawedzi
    5. ac.getNodeChooser();- zwraca model wyboru docelowego wierzchołka dla wybranej grupy
    6. ac.getAgeFunction();- zwraca funkcje postarzająca krawędzie.

Głównym plikiem konfiguracyjnym projektu jest plik sng.properties.

W środku znajdziemy następujące przykładowe parametry:

  • nodes=40 ­– ilośc węzłów
  • iterations=40000 – ilośc iteracji algorytmu
  • edges=220 – max ilość krawędzi
  • negative-edge=1 – możliwość tworzenia negatywnych krawedzi
  • bidirected=true – czy sieć jest skierowana
  • minimum-edge-weight=-5.0
  • maximum-edge-weight=5.0
  • output-file=d:\\sng\\sng.gdf – plik wyjsciowy
  • output-type=GDFFile – format wyjsciowy
  • groups=5 – ilość dostępnych grup
  • AgeFunction=LinearFunction – nazwa klasy użytej jako funkcja postarzania(pakiet: org.tsiss.sng.edge.age)
  • probability  = ParametrizedProbability – nazwa klasy użytej jako funkcji określającej możliwość powstania krawędzi (pakiet: org.tsiss.sng.probability.create.edge)
  1. — parametry specyficzne dla danej klasy
  2. ParametrizedProbability.createInternalEdgeProb=0.8
  3. ParametrizedProbability.createExternalEdgeProb=0.6
  4. ParametrizedProbability.isNegativeEdgeProb=0.5
  •  groupChooser=PopularPreference – nazwa klasy użytej jako funkcji wybierającej docelową grupę dla nowego obiektu (pakiet: org.tsiss.sng.probability.choose.group)
  •  nodeChooser  = NodeDegreePreference – nazwa klasy użytej jako funkcji wybierającej wierzchołek z podanego zbioru, np. Wybranej grupy (pakiet: org.tsiss.sng.probability.choose.node)
  1.  — parametry specyficzne dla danej klasy
  2. NodeDegreePreference.handicap = 2
  3. NodeDegreePreference.degreeWeight =1.5
  • externalNegativeEdge = GroupNegativePreferenceWithPositiveInfluence – nazwa klasy użytej jako funkcji wybierającej docelową grupę dla nowej negatywnej krawedzi (pakiet: org.tsiss.sng.probability.choose.group)
  1. — parametry specyficzne dla danej klasy
  2. GroupNegativePreference.handicap = 1
  • externalPositiveEdge = GroupPositivePreference – nazwa klasy użytej jako funkcji wybierającej docelową grupę dla nowej pozytywnej krawedzi (pakiet: org.tsiss.sng.probability.choose.group)
  1. — parametry specyficzne dla danej klasy
  2. GroupPositivePreference.handicap = 2

Jak widzimy po skompilowaniu projektu możemy zmieniać mechanizm działania aplikacji bez potrzeby ponownej przebudowy projektu.
Możliwości aplikacji możemy rozszerzać dodając nowe implementacje klas.
Należy jednak pamiętać,że wszystkie klasy utworzone w pakiecie org.tsiss.sng.probability.* i org.tsiss.sng.edge.age należy zarejestrować w odpowiedniej enumeracji w pakiecie org.tsiss.sng.enum.

Sytuacja jest podobna z formatami wyjściowymi utworzonej sieci (pakiet: org.tsiss.sng.outputs).
Niestety format UCINet wymaga poprawek.

Specyficzne parametry dla danych klas:

Jeżeli zaszłaby potrzeba pobrania z pliku konf. Specyficznego nowego parametru, zapisujemy go wg. schematu:

„NazwaKlasy.nazwaParametru=Wartość”

Po dodaniu parametru należy go zarejestrować w enumeracji org.tsiss.sng.enum.ApplicationOption.java, np:

AGE_FUNCTION(„ageFun”, „AgeFunction”,true,”Name algorithm used to determine age function”,”NoFunction”),

PARAM_NAME(„shortName”, „LongName”,true,”Description”,”DefaultValue”),

Jeżeli mamy już zarejstrowany parameter w klasie ApplicationContext dodajemy:

  1. pole przechowujace wartość naszego paramteru
  2. w metodzie setApplicationValue, dodajemy warunek case i metode konwersji naszego paramteru z klasy String
  3. utworzenie gettera dla pola z pkt 1.

To wszystko.

Jeżeli z jakiś względów użytkownik, nie może zarejestrować, dodać wpisu, może wykorzystać metode ApplicationContext.getProperty(String key, String defaultValue), by pobrać wartośc parametru prosto z pliku sng.properties. Jednak należy pamiętać, że powyższe rozwiązanie nie jest zalecane.

Źródła projektu dostępne pod adresem: http://sirius.cs.put.poznan.pl/~inf89843/tpd2/tsiss/sng.zip

Przykładowo wygenerowane sieci: http://sirius.cs.put.poznan.pl/~inf89843/tpd2/tsiss/sng_net.rar

Uruchamanie:

“java –jar SignedNetworkGenerator.jar plik_konf.properties”

Jako jedyny parametr funkcja przyjmuje relatywną ścieżkę do pliku konfiguracyjnego. Jeżeli użytkownik pominie parametr, aplikacja spróbuje załadować plik sng.properties z katalogu aplikacji.

Miłego korzystania:)

Luty 20, 2013

System Rekomendacji Gier Planszowych

- autor: tsissput

Cel projektu:

Celem projektu było stworzenie systemu będącego w stanie polecać gry planszowe na podstawie wybranej gry planszowej lub preferencji mechanik sterujących grami planszowymi.

Realizacja projektu:

W celu ustalenia jakie gry można polecić, w zależności od wybranego przez użytkownika tytułu, należało stworzyć graf podobieństw pomiędzy grami planszowymi. Do ustalenia podobieństwa pomiędzy nimi zostały wykorzystane ich mechaniki. Wyróżnia się ponad 40 różnych mechanik sterujących grami planszowymi, każda gra wykorzystuje dowolną liczbę tych mechanik w swoim działaniu. Fakt ten został wykorzystany do ustalania podobieństwa między poszczególnymi tytułami- dla każdej pary gier planszowych sprawdzana jest liczba mechanik, z których oba tytuły korzystają oraz liczba różnych mechanik, które te gry wykorzystują. Iloraz tych dwóch wartości daje nam miarę podobieństwa jednej gry planszowej do drugiej. Wartości tej miary stanowią krawędzie w grafie podobieństw pomiędzy grami planszowymi. Ponieważ miara ta jest wartością symetryczną, krawędzie w grafie są nieskierowane. Aby zniwelować dużą ilość krawędzi, szczególnie wychodzących od wierzchołków reprezentujących gry z dużą ilością wykorzystanych mechanik, zastosowano próg odcięcia na poziomie 0,3. Gdy użytkownik szuka gry podobnej do wymienionego tytułu, system zwraca wszystkie wierzchołki, które posiadają krawędź prowadzącą do wierzchołka reprezentującego wybraną grę. Wszystkie tytuły są wyświetlane wg miary podobieństwa w kolejności malejącej wraz z najważniejszymi informacjami o danych tytułach. System udostępnia także alternatywną metodę rekomendacji gier. Pozwala on na wybranie kilku mechanik gier planszowych, po czym dodawany jest tymczasowy wierzchołek grafu i tworzone są krawędzie wychodzące z niego zgodnie z zasadami wymienionymi powyżej. Następnie zwracane są wszystkie tytuły które zostały połączone krawędzią z tymczasowym wierzchołkiem. Po dokonaniu rekomendacji tymczasowy wierzchołek zostaje usunięty z grafu.

Wykorzystane technologie:

– Java
– Play Framework
– Twitter bootstrap

Wizualizacja sieci oraz działania systemu:

Graf podobieństw gier planszowychstronaGłówna wynikigry

Kody źródłowe:

http://sirius.cs.put.poznan.pl/~inf89752/iswd/tsiss.zip

 

Autorzy:

Jakub Jaróżek
Dawid Neumann

Luty 19, 2013

Semantic WoW

- autor: tsissput

Cel projektu

Celem projektu było stworzenie i wizualizacja grafu powiązań pomiędzy graczami World of Warcraft – jednej z najpopularniejszych gier MMORPG w sieci. Niezbędne dane pobrano korzystając z WoW API do bazy danych, przetworzono i uzyskano graf w formacie Netdraw VNA. Wizualizacji dokonano z użyciem programu Gephi.

Zastosowane technologie

Informacje z WoW API pobrano z użyciem aplikacji konsolowej napisanej w języku Java. Dane przechowywano w bazie MongoDB, zaś przetwarzanie odbywało się przy pomocy wspomnianej aplikacji oraz skryptów JavaScript. Dalszych operacji na grafie oraz wizualizacji dokonano w programie Gephi.

Zaimplementowana aplikacja

Jak wspomniano aplikacja jest konsolowa, umożliwia następujące operacje:

  • wczytanie pliku z nazwami gildii,
  • pobieranie nie ściągniętych gildii (na podstawie wczytanej listy nazw),
  • pobieranie nie ściągniętych postaci (na podstawie listy nazw członków gildii),
  • oba powyższe,
  • usunięcie zawartości bazy danych,
  • wygenerowanie pliku z grafem na podstawie pobranych danych przetworzonych za pomocą skryptów JS.

cmd

Architektura aplikacji

Ze względu na sposób udostępniania danych przez WoW Api, aplikacja wymaga nazw gildii, których ma dotyczyć analiza (względnie nazw wszystkich gildii na serwerze). Informację tę uzyzkano z serwisu WoW Progress i wczytywano z plików.
arch

Model ORM

Do mapowania obiektowo relacyjnego wykrorzystano bibliotekę Morphia współpracującą ze biblioteką Java sterowników bazy MongoDB.
orm

Uzyskane dane

Pobrano informację o graczach serwera Arathor-EU należących do gildii uzyskanych z WoW Progress. Dane pobierano na przestrzeni 5 dni w pierwszej połowie stycznia 2013. Po zapisie do bazy danych jej rozmiar wynosił ponad 35GB.

Pobrano informacje o 302 gildiach oraz 38 629 postaciach. Ze względu na rozmiary danych i przyjęty sposób analizy połączeń zdecydowano się przetworzyć jedynie postaci z 5 najlepszych (pod względem liczby punktów osiągnięć):

  • Alliance of Destiny
  • Maligned
  • Velvet Glove
  • Retired
  • Blacksail Pirates

Do tych gildii należy 1760 postaci powiązanych łącznie z 650 kontami graczy.

Graf uzyskany na podstawie top 5 gildii

Postaci są opisane takimi atrybutami jak: średni poziom przedmiotów, klasa, rasa, płeć, poziom postaci, oraz informacją czy jest to główna postać gracza. Wiele postaci gracza udało się identyfikować na podstawie identycznej listy osiągnięć zdobywanych w tym samym momencie. Za główną uznawano tę o najwyższym poziomie w danej gildii (tak więc gracz mógł mieć więcej niż jedną główną postać). Krawędź przechowuje również informację o tym, czy łączy dwie główne postaci, oraz o minimalnej rozbieżności czasowej w zdobyciu osiągnięcia przez obie postaci.

Jako że WoW API nie udostępnia bezpośrednio informacji o tym jak gracze dobierają się w drużyny, dwie postaci połączono krawędzie jeżeli zdobyli osiągnięcie w podobnym czasie (założono, że zdobywali go wspólnie), lub są w tej samej drużynie pvp. Wagą krawędzi ustanowiono liczbę osiągnięć, które zostały zdobyte w podobnym (w odstępie pięciu minut) czasie.

W rezultacie otrzymano:

  • 48792 Krawędzi
  • 36859 krawędzi między głównymi postaciami
  • 153 krawędzie pvp

W pierwszym pliku  krawędzie poprowadzono jedynie pomiędzy głównymi postaciami, oraz pomiędzy wszystkimi postaciami danego gracza. W drugim  umieszczono wszystkie krawędzie.

Wizualizacja

Poniższe rysunki przedstawiają grafy, w którym krawędzie poprowadzono jedynie między głównymi postaciami. Pierwsze dwie ilustrują wspólne zdobywanie osiągnięć, podczas gdy w trzecim zawarto informacje o grze arenowej. Na dwóch początkowych obrazkach pozostawiono jedynie krawędzie między postaciami, które przynajmniej jedno osiągnięcie zdobyły w tym samym momencie, i to tylko te, których waga przekraczała 40. Wielkość wierzchołka odpowiada jego wartości pagerank, zaś kolor wskazuje przynależność do gildii (na pierwszym), poziom posiadanego ekwipunku (na drugim).

guilds_circle_2guilds_circlepvp

Luty 18, 2013

Co słychać w mediach społecznościowych?

- autor: tsissput

Założenia projektu

Celem projektu było stworzenie prototypu aplikacji umożliwiającej analizę wiadomości gazetowych pod kątem popularności, którą uzyskały w serwisach społecznościowych.

Wynik realizacji projektu

Utworzone zostały dwa moduły. Pierwszy z nich odpowiedzialny jest za ciągłą akwizycję wpisów z kanałów RSS wylistowanych w pliku tekstowym. Informacje o kanałach RSS i ich wpisach zapisywane są w bazie danych.

Drugi moduł zajmuje się pobieraniem informacji o zainteresowaniu, jakie wzbudziły wiadomości w serwisach społecznościowych. Prototypowa aplikacja zbiera informacje o liczbie tweetów na serwisie Twitter zawierających link do badanego artykułu oraz liczbę udostępnień artykułu na portalu Facebook. Pobrane dane zapisywane są w bazie danych. Moduł ten generuje również pliki csv z zestawieniem najpopularniejszych artykułów ogółem oraz najpopularniejszych w każdym z kanałów RSS. 

Rozwój projektu

Kolejnymi krokami rozwoju aplikacji mogą być:

– rozszerzenie modułu zbierającego informacje o zainteresowaniu o kolejne serwisy społecznościowe

– opracowanie funkcji oceny zainteresowania na podstawie informacji ze wszystkich serwisów

– stworzenie modułu analizującego artykuły pod kątem cech wspólnych, próba klastrowania wiadomości, w celu odnalezienia zależności między treścią i tematyką artykułu a wzbudzonym zainteresowaniem

– dodanie interfejsu graficznego

Wykorzystane technologie

– Java

– PostgresSQL

– biblioteka do obsługi kanałów RSS: ROME http://rometools.org/

– lekka i bardzo wygodna biblioteka odpowiedzialna za integrację z bazą danych, ORM: jOOQ http://www.jooq.org/

– Twiiter API

– Facebook API

Kod źródłowy + przykładowe wyniki działania aplikacji

https://github.com/k-cz/tsiss

 

 

Autor

Kacper Skory

 

Tagi:
Luty 13, 2013

Event Finder czyli wszystkie interesujące wydarzenia w jednym miejscu

- autor: tsissput

Celem projektu było stworzenie aplikacji, która ułatwi użytkownikom dostęp do informacji na temat zbliżających się wydarzeń. Dzięki wybraniu interesujących nas kategorii oraz miast otrzymujemy dostosowaną grupę wydarzeń. Dzięki temu nie trzeba przekopywać się przez treści zupełnie nas nie interesujące. Wydarzenia oraz kategorie są dodawane przez użytkowników i to oni dbają o dostarczenie jak najciekawszej treści.
MainPage
Na zaprezentowanym obrazku widać dwa wydarzenia, są to koncerty z kategorii muzyki rockowej. Wydarzenia wybierane są na podstawie ustawień użytkownika, tak więc w systemie widnieją innego typu wydarzenia, natomiast użytkownik widzi dobrane dla niego. Ma oczywiście możliwość przejrzenia wszystkich wydarzeń, jednak jest w tym celu zrealizowany inny widok. Wydarzenia na które użytkownik planuje się wybrać są oznaczana na niebiesko.
Oczywiście jak na portal społecznościowy przystało nie może obyć się bez interakcji między użytkownikami. Możliwe jest śledzenie wybranych osób dzięki czemu dostajemy spis wydarzeń na jakie się wybierają. Dodatkowo każde wydarzenie może zostać skomentowane przez użytkowników.
Inwigiluj

Do stworzenia aplikacji wykorzystaliśmy technologię .Net, język C#, logika biznesowa została zrealizowana z wykorzystaniem technologii WCF dzięki czemu istnieje możliwość stworzenia dodatkowych interface’ów użytkownika. Domyślny interface został zrealizowany z wykorzystaniem technologii MVC oraz styli CSS Twitter Bootstrap.

Autorzy
Tomasz Bartoszewski
Marcin Wolicki

Luty 12, 2013

Facebookowe rozszerzenie dla sklepów Magento

- autor: tsissput

Ogólnym założeniem projektu jest wykorzystanie zasięgu i danych zbieranych przez Facebooka w celu zwiększenia sprzedaży w sklepie internetowym.

Zaprezentowane tutaj rozwiązanie jest modułem dla sklepów opartych o platformę Magento. Oznacza to, że każdy sklep oparty o tą modułową platformę może poprać stworzone rozszerzenie i od ręki zacząć korzystać z udostępnionej funkcjonalności.

magento_friendlist
Widok sugestii prezentów dla znajomych

Pierwszą zachętą do korzystania z naszego sklepu jest możliwość założenia konta i późniejszego logowanie się w sklepie z wykorzystaniem Facebooka – nikt nie lubi pamiętać wielu haseł, a tak za jednym kliknięciem mamy już konto i jesteśmy zalogowani.

Drugi krok, który potencjalnie może przełożyć się na wzrost sprzedaży to dodanie guzika „Lubię to!” wraz z Facebookowymi metadanymi.

Magento Panel Administracyjny
Widok panelu administracyjnego – wybór fan page – widoczne propozycje słów kluczowych i szczegóły wybranego fan page

Trzeci największy krok to sugestie prezentów dla Facebookowych znajomych. Sugestie prezentów pochodzą z dwóch prostych źródeł:
Pierwszym są produkty polubione w naszym sklepie przez znajomego. Drugim są tak zwane „Punkty Zainteresowań” które tworzymy samodzielnie w panelu administracyjnym. Na punkt zainteresowań składają się produkty które będą wyświetlane jako sugestie prezentów oraz Facebookowe Fan Page. Jeżeli nasz znajomy polubi przynajmniej jeden z wymienionych Fan Page produkty znajdujące się w tym punkcie zainteresowań zostaną mu zasugerowane. W przypadku uniwersalnego modułu dla nieznanych nam sklepów trudnym jest zaproponowanie mechanizmu który automatycznie powiąże odpowiednie Fan Page z odpowiednimi produktami – to zadanie spada na administratora sklepu. Prostą pomocą dla wyszukiwania odpowiednich Fan Page propozycje słów kluczowych zbierane ze słów kluczowych wybranych produktów.

Zapraszam do przeklikania się przez działające demo i ograniczenia się z wandalizmem przy przeglądaniu opcji panelu administracyjnego (użytkownik: fdemo hasło: tsiss-put1234)

Autor: Kamil Balwierz

Luty 12, 2013

FaceOnFacebook

- autor: tsissput

faceonfacebook
Aplikacja mobilna o nazwie FaceOnFacebook działająca pod kontrolą systemu Android OS za główne zadanie przyjmuje ciekawe wykorzystanie danych udostępnianych przez użytkowników portalu Facebook.
Jako dane, które zostają poddane przetwarzaniu przez aplikację FOF zostały wybrane zdjęcia znajdujące się w albumach naszych znajomych.

Co dokładnie oferuje FaceOnFacebook:
– tworzenie mozaiki zdjęć profilowych wszystkich naszych znajomych
– tworzenie kolorowej mozaiki wszystkich znalezionych twarzy na zdjęciach naszego jednego znajomego

* zarówno mozaika profilowa oraz mozaika twarzy mogą zostać udostępnione i wrzucone na naszą ścianę FB

Wykorzystując API udostępniane przez firmę Facebook każdy deweloper i jego aplikacja może uzyskać dostęp do praktycznie wszystkich informacji profilu danej osoby oraz informacji o znajomych tej osoby. Wystarczy aby właściciel profilu zgodził się i przyznał prawa naszej aplikacji do konkretnych elementów swojego profilu.

Dzięki temu aplikacja taka jak FOF wykorzystując Facebook Graph API może pobierać zdjęcia znajdujące się w albumach naszych znajomych, jeżeli tylko jej na to pozwolimy.

Jak działa tworzenie mozaiki twarzy?!

  1. Aplikacja pobiera informacje dotyczące wszystkich naszych znajomych.
  2. Na etapie wybierania konkretnego znajomego, którego zdjęcia mają zostać przeszukane w ramach wyszukiwania twarzy i tworzenia z nich jednej mozaiki niezbędne jest pobranie informacji o albumach wszystkich znajomych.
    Dzięki informacjom zawartym w każdym albumie znamy sumaryczną liczbę zdjęć każdego znajomego.
  3. Dla wybranego znajomego, z każdego jego albumu pobierane są informacje o wszystkich jego zdjęciach (URL’e do zdjęć).
  4. Zdjęcia pobierane sekwencyjnie jedno po drugim służą jako informacje wejściowe do algorytmu wykrywania twarzy (zawarty w API Androida).
  5. Po przeskanowaniu wszystkich zdjęć, z tablicy bitmap, w której znajdują się wszystkie znalezione twarze sklejana jest jedna duża bitmapa (mozaika).

Przykład działania algorytmu:

Obraz1

Zdjęcie profilu naszego znajomego wraz z jego zdjęciami twarzy

Obraz2

Mozaika wygenerowana przez FaceOnFacebook

screen

Widoki aplikacji

Autor: Michał Łu….k

Luty 4, 2013

Generator sieci społecznościowych ze znakiem

- autor: tsissput

Celem projektu było opracowanie i zaimplementowanie generatora dynamicznych sieci społecznościowych ze znakiem (ang. signed networks). W sieciach takich obok związków pozytywnych występują także negatywne. Przykładem takiej sieci może tworzenie się połączeń pomiędzy użytkownikami portalu Allegro, poprzez komentarze, które mogą być pozytywne jak i negatywne.

Projekt

Generator posiada wiele opcji, pozwala m.in:

  • Ustalić wielkość i sposób tworzenia grafu wejściowego
  • Określić liczbę i sposób pojawiania się nowych krawędzi
  • Wybrać funkcję predykcji znaku
  • Umożliwia postarzanie i wygaszanie krawędzi i węzłów

Stworzone sieci są zapisywane w bazie danych. Możliwa jest ich wizualizacja.

Implementacja

Projekt został stworzony w oparciu o platformę PaaS od Google’a: Google App Engine. Z oferowanych funkcji wykorzystano przede wszystkim dostęp do bazy danych, a także wykorzystano możliwość łatwego i szybkiego tworzenia i publikowania aplikacji webowych. Sam generator jest jednak niezależny od użytej platformy i może zostać użyty np. z konsoli.

Wykorzystane narzędzia:

screenshot_original

Projekt jest dostępny pod adresem: http://sn-generator.appspot.com/

Referencje:

Predicting Positive and Negative Links in Online Social Networks by J. Leskovec, D. Huttenlocher, J. Kleinberg. ACM WWW International conference on World Wide Web (WWW), 2010.
Signed Networks in Social Media by J. Leskovec, D. Huttenlocher, J. Kleinberg. ACM SIGCHI Conference on Human Factors in Computing Systems (CHI), 2010.

Autor: Jan Łukaszewicz