Nadchodzi nowe... Coyote 2.0

Od jakiegoś miesiąca, po cichu pracuje nad nową wersją Coyote (https://github.com/adam-boduch/coyote). Póki co nic skomplikowanego - pracuje nad front-endem, layoutem. Celem jest lepsze wyświetlanie strony na urządzeniach mobilnych. Graficznie większych zmian nie ma, nie chcemy przecież aby użytkownicy doznali szoku ;)

Niemniej jednak front-end to początek nowej wersji Coyote i dlatego piszę tego posta. Żeby poinformować o nadchodzących zmianach.

tl;dr Będzie nowa wersja Coyote (open source). Obecnie trwają prace i jeżeli będziesz chciał pomóc to świetnie! Wkrótce więcej informacji.

Po co nowa wersja?

Obecny kod powstał 5 lat temu. Przez ten czas wiele się zmieniło, rozwinęła się masa nowych, fajnych technologii czy rozwiązań. Obecny kod pisany jest na autorskim frameworku i jak się domyślacie - dokumentacja do niego jest dosyć marna. Chciałbym, aby nowa wersja oparta była na popularnych open sourcowych rozwiązaniach. Coyote również będzie udostępniony jako open source i będziemy zachęcać Was abyście pomogli w jego rozwijaniu. Chciałbym aby społeczność miała większych wpływ na "kształt" projektu dlatego wkrótce będę zamęczał Was nowymi wątkami w dziale Coyote :)

Mam nadzieje, że dzięki temu 4programmers.net dostanie "kopa", rozwój znacznie przyspieszy, powstaną od dawna planowane funkcjonalności. Myślałem również nad opcją praktyk studenckich. Idealnie dla introwertyków - możesz zaliczyć praktyki nie wychodząc z domu ;)

**Jakie technologie? **

Język: PHP (proszę nie pytajcie mnie dlatego nie python, java, ruby itp ;))
Framework: Laravel 5
Fron-end: SCSS, Bootstrap, jQuery
Baza: MySQL/MariaDB (moze Postgres?) oraz MongoDB
Inne: Redis, ElasticSearch

Chcesz pomóc?

Jeżeli tak, to świetnie :) Każdy commit będzie mile widziany. Wcześniej jednak musimy opracować pewne zasady pracy oraz procedury.

Kiedy nowa wersja?

Póki co pracuje nad front-endem. Jeżeli chodzi o poszczególne widoki to większość mam już zrobione. Pierwotny plan zakładał uruchomienie pierwszej wersji pod koniec tego roku (ewentualnie na początku przyszłego) lecz teraz widzę że będzie z tym ciężko.

Proponowałbym poważnie zastanowić się nad wyborem języka, bo jak widać od tego zależy ilość osób chcących się zaangażować w rozwój tego projektu.

@tdudzik wiesz jak to bedzie wygladac? Adam zmieni jezyk dla ludzi ktorzy chca sie dolaczyc a pozniej oni od razu lub po tygodniu zrezygnuja z tego projektu.
(zapewne bedzie teraz post, JA NIE, JA BYM PISAL... yhy)

czekam na nowa wersje :)

Akurat PHP jest dobrym wyborem, tylko nie wiem dlaczego Laravel (ten chyba nie jest tak popularny w Polsce jak Symfony)? Więc może to mieć wpływ na potencjalną ilość chętnych. Dlaczego nie Kohana? Dość prosty do opanowania i dość przyjemny, może też CodeIgnither, równie łatwy do opanowania, za to z lepszą dokumentacją, jest wiele modułów pod CI open source. A może Phalcon?

Jeśli framework jest trudny do opanowania (krzywa uczenia) to jak to będzie rzutowało później na ilość potencjalnych chętnych do współpracy? Co do pythonowego DJANGO czy tam Railsów, na ile to jest popularne w Polsce i jak to się przełoży na perspektywy późniejszego rozwoju?

Patrzę na ten wątek i widzę:

• wybieram Abc i Def
• co?! Dlaczego nie Hij?!
• jakbyś wybrał Klm to bym pomógł, a tak..
• nie rozumiem, przecież Nop ma lepszą krzywą, więc dlaczego Abc?

Zero argumentów tylko rzucanie nazw, które się zna :)
To ja może wpasuję się w trend i zapytam dlaczego nie Zend1?

Kohana: martwy projekt.
Phalcon: niszowy
Zend: odszedł trochę do lamusa
CodeIgniter: stary, niezbyt popularny

Właściwie wybór sprowadza się do Symfony2 oraz Laravel. Laravel ma wiele komponentów z Symfony, jest prostszy do opanowania oraz o wiele szybszy. Przyjemnie się z nim pracuje, jest dynamicznie rozwijany i coraz popularniejszy.

http://www.sitepoint.com/best-php-framework-2015-sitepoint-survey-results/
http://learninglaravel.net/most-popular-php-frameworks-2015-infographic
http://beebom.com/2015/02/best-free-php-frameworks
http://noeticforce.com/best-php-frameworks-for-modern-web-development

Zróbcie jeszcze tryb nocny w nowej wersji i API :D

Co do głupich argumentów: Dlaczego nie Android?

Dlaczego nie... a w sumie mi obojętne bo i tak nie umiem żadnego języka :(

pisanie nowej wersji zawsze obarczone jest ryzykiem, że początkowo będzie to 50% dawnej funkcjonalności¹ ;-)

ale cokolwiek to będzie, proszę by interfejs nie opierał się o monochromatyczne hieroglify, których znaczenie można poznać tylko po kliknięciu, a potem trudno je odróżnić i zapamiętać.

również kolor przewodni jakiś by się przydał, a nie wszędzie szarości. kolor może być konfigurowalny, ale to już „zadanie z gwiazdką”.

jeśli ma być osobna wersja mobilna, powinna być opcjonalna. wiele stronek zmienia postać tylko na podstawie rozdzielczości, co jest chybionym pomysłem bo smartfony i tablety mają coraz większe rozdzielczości, przekraczające rozdzielczości starszych laptopów (np. 1024x768). na desktopie za to istotny jest aktualny rozmiar okna, a nie rozdzielczość (okno użytkownik mógł zmniejszyć albo przypiąć do połowy czy ćwierci ekranu).

o kwestiach technicznych się nie wypowiadam bo web to nie moja działka i jestem do tyłu w temacie.

¹) choćby takie niepisane rzeczy jak tab i spacja podczas edycji posta wysyłają tego posta albo zapisują zmiany. takie szczegóły łatwo zgubić gdy się pisze kod od nowa...

Azarien napisał(a):

wiele stronek zmienia postać tylko na podstawie rozdzielczości, co jest chybionym pomysłem bo smartfony i tablety mają coraz większe rozdzielczości, przekraczające rozdzielczości starszych laptopów (np. 1024x768).

Ale przecież rozdzielczość sprzętowa ma niewiele wspólnego z określaną w css logiczną rozdzielczością. Znaczy się ma sporo, ale nie działa to tak jak to przedstawiasz:
rozdzielczość logiczna = rozdzielczość sprzętowa / pixel ratio
Pixel ratio urządzenia rośnie wraz ze zwiększaniem rozdzielczości ekranów i jest dostosowane właśnie do proporcji wielkość/rozdzielczość.

Marooned napisał(a):

Zero argumentów tylko rzucanie nazw, które się zna :)
To ja może wpasuję się w trend i zapytam dlaczego nie Zend1?

Zadałem tego typu pytanie bo już od dłuższego czasu nurtuje mnie pytanie dlaczego wybierane są takie frameworki PHP a nie inne. Decyzja podjęta? Spoko. Jednak tego typu forum można bez większych problemów napisać właściwie w dowolnym frameworku PHP. Można mieć chyba jednak wrażenie, że wybór jest w dużej mierze uzasadniony tym, że skoro ten a nie inny FW jest przyjemniejszy, to to powinien być słuszny wybór. I spoko, tego typu podejście jest chyba po części słuszne - łatwiej jest zrealizować ten sam cel w czymś co się lubi a nie w czym z czym trzeba by się męczyć.

Nie wiem jednak skąd taka popularność Symfony 2 w Polsce i czy przypadkiem Laravel nie jest poważną konkurencją (i zagrożeniem) dla Symfony. Czy przypadkiem jednak nie jest to tak, że przy czymś większym tak naprawdę wszystko rozbija się o czas pracy, koszty, support i dostępność komponentów?

@Azarien: heh, masz racje. Takie funkcjonalności łatwo zgubić. Postaram się mieć to na uwadze.

Większość widoków jest już gotowych, graficznie póki co nie ma żadnych rewolucyjnych zmian. Kod pisany jest przy użyciu frameworka Bootstrap który jest dość popularny jeżeli chodzi o pisanie responsywnych stron WWW.

A i żeby komentarzem nie dało się rozwalić układu strony.

Nie mogę uwierzyć, że minął już prawie rok od napisania tego wątku. To był bardzo ciężki rok, ale prawie się udało... wersja 2.0 jest już prawie na ukończeniu. Ufff...
Nie będę się długo rozpisywał bo pewnie niektórzy mają już dość tego, że ciągle piszę o nowej wersji ;) Chciałbym jednak dotrzeć do jak największej liczby osób, zachęcić do zgłaszania błędów a być może również w pomocy w rozwoju projektu.

ChangeLog: https://github.com/adam-boduch/coyote/blob/master/CHANGELOG.md
Przy okazji podaje link do wersji testowej: https://dev.4programmers.info/

Błędy, uwagi: https://github.com/adam-boduch/coyote/issues

napisał(a):

Tzw. "sticky header" domyślnie dla wszystkich (bez możliwości wyłączenia)

WTF!

@Adam Boduch, w sygnaturce nie są obsługiwane obrazki - poniższa, przykładowa fraza:

![title](http://www.google.pl/images/foo.png)

traktowana jest jako zwykły link, poprzedzony znakiem !; Poza tym wyrzucane są wszystkie znaki nowej linii (nie rozumiem po co), a znacznik <br> nie jest obsługiwany.

@furious programming: nowe linie to ewidentnie przeoczeniem. Już to poprawiłem. Co do obrazków w stopce: czy uważacie, że to jest na pewno konieczne? Ponieważ wyłączenie ich w stopce było celowym działaniem, aby zminimalizować dostępne znaczniki w stopce do minimum.

Co do obrazków w stopce: czy uważacie, że to jest na pewno konieczne?

Może nie jest konieczne, ale fajnie mieć możliwość wrzucenia obrazka (mnie się ta opcja przydaje);

Ponieważ wyłączenie ich w stopce było celowym działaniem, aby zminimalizować dostępne znaczniki w stopce do minimum.

W jakim celu? Nie widzę powodu, aby te znaczniki aż tak ograniczać;

Bieżąca wersja systemu ma już poobcinane znaczniki (nawet <quote> w mikroblogach), co przeszkadza i trzeba obchodzić znacznikami HTML; W nowej wersji mikroblogi mają pełną funkcjonalność, nawet w komentarzach są wyświetlane emotki, dlatego też nie widzę powodu, aby ograniczać znaczniki w sygnaturkach.

Aby ograniczyć "pstrokatość" sygnaturek, dozwolone są tam tylko podstawowe znaczniki markdown. Podobnie jak w komentarzach do postów, artykułów, mikroblogów czy artykułów. Zostało to ujednolicone. Tzn. mamy możliwość pogrubienia, czy użycia backtick. Dodatkowo z użytkowników aktywnych (tzn. takich, którzy logowali się w ciągu ostatnich kilku miesięcy) mniej niż 5 osób ma ustawione obrazki w sygnaturce. Uznałem więc że ta funkcjonalność nie jest konieczna; jeżeli jednak będzie taka potrzeba to można taką opcję przywrócić.

Tak jak pisałem: dążyłem do ujednolicenia, czyli obsługi takich samych znaczników w postach, mikroblogach, artykułach. Z drugiej strony mamy komentarze do postów, mikroblogów, artykułów. W tej grupie znajduje się też parser sygnaturek.

Aby ograniczyć "pstrokatość" sygnaturek, dozwolone są tam tylko podstawowe znaczniki markdown.

Posty i tak są pstrokate, dlatego że można w nich używać mnóstwo znaczników, więc jeden obrazek czy wstawka kodu w sygnaturce (czyli fragmencie posta) nie robi zupełnie żadnej różnicy; Skoro i tak mniej niż 5 osób ma obrazek w sygnaturce to włączenie tej opcji nie będzie w niczym przeszkadzało; Zbyt duże obrazki można odsiewać, aby nie rozciągać nadmiernie postów;

Mam obrazek w sygnaturce, bo jest taka możliwość; Nie jest jakiś specjalnie pstrokaty, jest mały, więc forum nie paskudzi; Taki obrazek pozwala przyciągnąć wzrok, czego o zwykłym linku nie można powiedzieć, bo ginie w natłoku tekstu posta i ew. komentarzy;

Zrobisz jak zechcesz - przecież nie będziemy się bić o głupi obrazek :D