W tym topicu proszę umieszczać propozycje nowych tematów, na które chcielibyście porozmawiać.
Choć w temacie nie miałbym za dużo do powiedzenia z racji małej wiedzy to chętnie poczytałbym dyskusję na temat profilowania aplikacji. Może na forum znajdzie się kilka osób, które miały już z tym do czynienia i będzie chciało się podzielić swoją wiedzą.
Ja z chęcią bym podyskutował na temat modelowania warstwy kontroli dostępu w połączeniu z bazą danych itp.
Witam
Ostatnio na http://bobondevelopment.com/2007/03/19/what-is-a-real-developer/ czytałem ze klasyczny model budowania stron w ASP.NET jest zły, ponieważ Framework ASP.NET robi za duża abstrakcje dla protokołu HTTP i związanymi z nim elementami.
Post ten (oraz komentarze) dal mi dużo do myślenia i po części się z nim zgadzam. I bardzo bym chciał żebyśmy mogli tu przedyskutować temat/problem z abstrakcja. Do jakiego stopnia jest pożyteczna i kiedy zaczyna być szkodliwa ?
Temat ten jest także trochę związany z PHP bo teraz większość frameworkow tez robi abstrakcje dla wspomnianych elementów.
Pozdrawiam.
A ja chciałbym poruszyć z goła rzadko poruszany temat, bo raczej wyspecjalizowany tylko na jednym aspekcie MVC, widoków. Dokładniej sposobów obróbki danych - przekazanych do widoku - do różnych typów wynikowych.
Najlepiej będzie jak zacytuję tutaj post, który napisałem wcześniej (zanim zorientowałem się, że nie mogę tworzyć tematów na PRO ).
Ok, ale jeżeli już to temat ogólnie o MVC, ideą było to żeby nie rozdrabniać się za bardzo w tym dziale i nie robić bałaganu.
Tylko czasem to 'rozdrobnienie' stanowi temat sam w sobie.
(można umieścić temat informatyka i wszystko w nim, lub tworzenie stron internetowych obok pisania systemów operacyjnych)
[mam nadzieję, że nie robię zbytniego OT]
Ja bym chciał podyskutować o Zend API.
Konkretnie o umieszczaniu części lub całości logiki naszych aplikacji w formie rozszerzenia do PHP.
Każdy zauważył, że w php powstaje wiele różnych frameworków. Chętnie poczytałbym o doświadczeniach jakie z nimi macie. Może takie krótkie sprawozdania jak się sprawdził w danych zastosowaniach.
Nie chodzi mi o jałowe dyskusje, który lepszy itd., chodzi o konkretne doświadczenia w pracy, przy pisaniu konkretnych aplikacji.
Przydał by się temat pt. "Singleton vs. Registry vs. zmienne globalne" w którym ktoś może by wreszcie napisał dlaczego w/g niego zmienne globalne są bee w przeciwieństwie do tych dwóch (anty)wzorców projektowych
A może szablony jak xslt...
Ja proponuje zaawansowane metody dot. budowy aplikacji gdzie wykorzystuję się różne grupy użytkowników. np Redaktorzy, obsługa for itp, admin, super admin, gdzie można dowolnie dodawać grupy i ustalać co może a czego nie może
Ja podyskutowałbym chętnie na temat naprawdę dużych projektów i ich rozwiązań:
- duże replikacje mysql (master-slave, master-master, itp)
- farmy serwerów,
- utrzymywanie sesji przy load balancingu
- itd.
Z pewnością mamy tutaj wielu użytkowników biorących udział w takich projektach
Mnie natomiast bardzo ciekawi zaniedbywany i mało znany temat SPL. Dokumentacja praktycznie nie istnieje, więc doświadczenia innych programistów byłby mile widziane.
@mike
Najlepiej wszystko
Jeśli chodzi o samo działanie SPL nie mam z tym większego problemu, chociaż taki RecursiveDirectoryIterator spowodował, że się zawiesiłem przez chwilę. Najbardziej zależy mi na życiowych przykładach, porównaniu wydajności w stosunku do standardowych rozwiązań, itp.
Inną kwestią, która wychodzi poza ramy tego wątku jest to, czy klasa Iterator może być użyta do "dużej" klasy, która oprócz iterowania po jakiejś kolekcji wykonuje inne operacje. Wiem, że działa, ale czy jest to poprawne?
<?php class Klasa implements Iterator { // duzo kodu, obliczen, itp. public function http://www.php.net/current() { //... } // itd } ?>
@batman to może IteratorAggregate?
Ale sam niewiele używałem iteratorów, bo jakoś nie było po co.
Ale temat mógł by być ciekawy, bo można SPL używać do wielu rzeczy, a nie zawsze zdajemy sobie z tego sprawę.
Np. do przeszukania całego poddrzewa folderów i wybranie tylko plików z rozszerzeniem php to są trzy obiekty i już jadąc prostym foreach jedziemy po tych plikach... ( chyba RecursiveDirectoryIterator w konstruktorze RecursiveIteratorIterator a to w konstruktorze RecursiveRegexIterator czy jakoś tak)
A przecież jest na pewno więcej ciekawych zastosowań (zrób to samo bez iteratorów, to jest trochę kodu)
Przypomniałem sobie o jeszcze jednym zagadnieniu, które nie było poruszane na tym forum. Chodzi o XMLReader i XMLWriter. O ile o XMLWriter nie wiem zbyt wiele, to XMLReader jest bardzo dobrym sposobem iterowania po bardzo plikach XML. Te tematy również warto poruszyć.
Akurat siedzę nad XMLReader i podobnie jak w przypadku SPL brakuje dobrej dokumentacji. Z chęcią zobaczę Twoje wpisy na blogu dot. tego zagadnienia
ja proponuję temat o ciekawych błędach w skryptach na przykład ostatnio trafił mi się taki
Fatal error: Exception thrown without a stack frame in Unknown on line 0
muszę przyznać że dostarczył mi wiele radości i śmiechu
o "ciekawych" bledach takich jak Twoj to se z kolegą przy koli możesz pogadać a nie na php Pro
Nie spamuj.
Można założyć temat o Routerach i sposobach routingu. W jaki sposób tworzyć routery na potrzeby naszych aplikacji, jakie są wydajne a jakie nie. Jakich używać a jakich nie używać.
W pełni popieram pomysł dotyczący ruterów.
Sam niedawno wziąłem się za przepisywanie swojego i wyszły mi z tego 3 klasy i całkiem sporo kodu - przynajmniej jak na router.
Prosze bardzo, temat utworzony.
A ja proponuję temat dotyczący odciązania dużych aplikacji po przez rozproszony system serwerów i ich ładną obsługę.
@SHiP: +1 wykop
Gotowe
Witam,
od dłuższego czasu chodzi mi po głowie pomysł utworzenia klasy, która byłaby swego rodzaju reprezentacją ekranu przeglądarki internetowej. Obiekt tej klasy przechowuje dane opisujące środowisko po stronie klienta (przeglądarki internetowej) takie jak jej typ (tekstowa, graficzna, inne), rozdzielczość.
Każdy inny obiekt w systemie po uprzednim wywołaniu odpowiedniej metody "dzierżawi" od tego obiektu pewną część ekranu (lub kilka), która staje się jego interfejsem.
Każdy obiekt systemu otrzymuje od obiektu obsługi ekranu informację o środowisku klienta, dzięki czemu wie jakiego interfejsu użytkownika ma użyć.
Obiekt obsługi ekranu korzysta z menadżera szablonów, który posiada informację o tym ile każdy z szablonów posiada "boxów", które mogą zostać wydzierżawione dla innych obiektów.
To tylko zarys tego o czym myślę. Mam jeszcze wiele pomysłów z tym związanych. Od razu uprzedzę, że mam odpowiednie przygotowanie aby to zrobić, jestem inżynierem informatykiem. To co napisałem powyżej po części zostało sprawdzone i działa.
Chciałbym o tym podyskutować. Czy warto dalej w to brnąć.
Chętnie przyglądnąłbym się dyskusji na temat zaproponowany przez karmera, a nawet włączył, jeśli uznam, że coś do niej wniosę .
Chciałbym zaproponować dyskusję na temat sposobów wykonania widoku.
Szczególnie zależy mi na poznaniu waszych opinii dotyczących generowania widoku przy użyciu smarty i / lub poprzez parsery XML.
Wielce nurtuje mnie i ciekawi przewaga jednej techniki nad drugą.
To czy ten temat nadaje się na Pro może być kwestią dyskusyjną. Jednak wydaje mi się że im lepszy programista tym lepszej techniki używa.
Dlatego chciałbym poznać wasze opinie.
Pozdrawiam i liczę że jest to wystarczające uzasadnienie.
Ciekawe byłoby również przedstawienie różnic wpięcia V w architekturze MVC w przodujących frameworkach (i nie tylko), a także implementacji helperów.
To o czym pisze @orglee fachowo zwie sie Rendererami.
Znalazłem na jednym z kanałów RSS informację o tym, że w październiku pojawi się beta wersja PHP 5.3. Spośród wszystkich opisanych "ficzerów", zainteresowała mnie jedna rzecz - phar. PHP-owy odpowiednik plików jar znanych z Javy. W manualu sporo o tym napisali. Może warto o tym podyskutować? Możliwości i ograniczenia takiego rozwiązania.
Phar w PHP 5.3 nie będzie nowością. Biblioteka ta obecnie funkcjonuje jako jedno z rozszerzeń PECLa. Dodatkiem jaki wniesie PHP 5.3 będzie włączenie biblioteki Phar do core'a PHP.
Nie mniej jednak zakładam wątek bo temat ciekawy: http://forum.php.pl/PHP_Archive_czyli_phar_t103107.html
Przyszedł mi do głowy kolejny ciekawy temat - drzewa w bazie danych. Co jakiś czas przewija się taki temat przez forum i zazwyczaj podawane są dwa rozwiązania - id i parentId oraz nested sets. W ten drugi właśnie zaczynam się wgryzać i wydaje się być dobrą alternatywą dla id i parentId. Z chęcią poznam doświadczenia innych ludzi, którzy znają się bardziej na rzeczy. Czekam na wasze opinie.
W archiwum jest taki temat: http://forum.php.pl/drzewka_sqlowe_t35091.html
Nie wiem czemu nie został przeniesiony tutaj. Może warto by to zrobić teraz? Temat drzewek jest nieśmiertelny.
A ja bym się chciał zapytać o doświadczenia Tych programistów w których firmach stosuje się diagramy UML.
I jak się one mają do rzeczywistego projektu. Praktycznie każdy framework oferuje swoją drogę tworzenia oprogramowania i zastanawia mnie jak na przykład takie diagramy klas przekładają się na kod.
Witam, chciałbym rozpocząć dyskusję na temat zaawansowanej obsługi błędów w złożonych aplikacjach obiektowych.
Chodzi o koncepcję (właścwie o wzorzec projektowy) efektywnego i wygodnego debugera dla systemu składającego się z wielu hermetycznych modułów - jak większość "domowych" frameworków, z których żaden dumny autor nie chce rezygnować
Jest wiele patentów na to, ale zwykle obciążają skrypty tonami kodu.
Ogólnie, topic odpowiadałby na pytanie: "Jak najefektywniej budować wielopoziomową obsługę błędów, tak, żeby się w niej nie pogubić.".
Konkretnie interesuje mnie system, w którym każda klasa ma własny handler i potrafi w ograniczony sposób wpływać na zachowanie całego skryptu. Inne klasy, które z niej korzystają interpretują jej błędy i decydują o tym, jaki mają wpływ na ich własne zachowanie.
Jednocześnie, jak już wspomniałem, rozwiązanie tego typu, że każdą klasę dziedziczymy z jakiegoś przykładowego "errorHandlera" (*kod ponizej) nie przemawia do mnie, bo przy rozbudowanych hierarchiach zawsze trzeba zrzucać ręcznie te błędy na kolejne poziomy - przez kolejne warstwy systemu, np. od jądra, przez kontrolery, widoki, aż do szablonów. Napewno każdy, kto próbował kiedyś pisać spójną rozbudowaną bibliotekę, spotkał się z tym problemem.
<?php // Standardowy errorHandler, którego dzidziczą wszystkie klasy w systemie. // Oczywiście, to tylko najprostszy przykład. class errorHandler { private $errors = http://www.php.net/array(); function isError() { return !http://www.php.net/empty($this->errors); } function lastError() { return http://www.php.net/array_pop($this->errors); } function setError($message) { $this->errors[] = $message; } funciton clearErors() { $this->errors = http://www.php.net/array(); } } ?>
Witam,
Ostatnio coraz to częściej zdarza mi się mieć wyrzuty sumienia zwiazane z tym czy aby napewno nie zagalopowałem się z projektem systemu, czy nie przesadziłem z modularnością, elastycznością, konfiguralnością, odzielaniem coraz to różniejszych warstw (dla przykładu kiedyś myśląc o projekcie zaczynałem z 3 warstwami, teraz żadko mi się zdarza - częściej "na dzień dobry" zaczynam od 5 warstw ).
Bardzo mi się spodobały artykuły http://blog.webarchitect.pl/2008/04/16/przerost-formy-nad-trescia/ oraz http://simonguest.com/blogs/smguest/archive/2009/01/15/_1C20_Micro-Architectures_1D20_.aspx w tym temacie.
Więc proponuję, utworzyć nową dyskusję na temat tego kiedy zanika ta cieniutka linia pomiędzy dobrym, modularny i elastycznym projektem a "over engineering".
Pozdrawiam.
Przyłączam się do obu powyższych próśb o utworzenie tematów. W archiwum jest co prawda temat o debugowaniu skryptów, ale ma on 3 lata. Jak dla metodologi odpluskwiania to całe wieki. Chciałbym się dowiedzieć jak powinno się postępować przy wystąpieniu błędu, którego nie da się od razu zlokalizować. Jaka w takich przypadkach powinna być procedura postępowania. Z góry dziękuję.
Witam,
prosiłbym o utworzenie tematu o "Tworzeniu API do wykorzystania przez zewnetrzne serwisy".
Najbardziej chodzi o dyskusje o tym jak powinna wygladac komunikacja (jaki protokół wykorzystać). W jaki sposob obudowywac serwis dodatkowym api. Czy tworzyc calkowicie odrebne pliki z funkcjami, czy tez moze jak wplesc razem.
Także przyłączam się do tematu na temat debugowania skryptów php.
Jak już się przyłączamy to ja oddaje głos na API.
Będę robił właśnie coś podobnego i fajnie byłoby nie popełniać kardynalnych błędów.
Debugowanie też popieram ;-)
Jak piszemy aplikację php? Czy używamy jakiegoś frameworka? Jakiego? Co się dla nas liczy przy pisaniu aplikacji? Szybkość ich tworzenia, czy szybkość działania samej aplikacji?
Również jestem za API. Jak PRO to PRO, a nie jakieś pierdy, które co drugi programista jest w stanie wykonać.
Ja jestem za tematem Routing - Routery, wg mnie dość ciekawy.
Jak Pro, to Pro:
http://phpazure.codeplex.com/
i/lub
http://phpdataservices.codeplex.com/
A ja z chęcią poczytałbym opinie na temat php + GUI + dostęp do bazy danych, a zwłaszcza: jak, czy koniecznie gtk2 i soap, czy nie lepiej jakiś inny niż php język programowania (php nie jest najlepszym rozwiązaniem dla aplikacji z własnym gui) oraz dodatkowo: czy temat php-gtk2 umrze/już umarł śmiercią naturalną?
Może trochę mniej "pro" niż tematy wyżej wymienione, ale dyskusja na temat budowy newsletter (z prawdziwego zdarzenia, gdzie wiadomości wysyłane są do XX tysięcy osób) ?
Drugi raz intensywnie pracuję z Allegro API i stąd moja propozycja: może warto utworzyć osobny temat pod tym kątem?
skoro mówimy już o API to możemy podyskutować o czymś od googla. wykresy, mapy, adsense do wyboru do koloru.
Tematy związane z API Google i Allegro są ciekawe, lecz wszystko zależy od tego o czym chcecie dyskutować. Jeśli o tym, jak zrobić jakąś konkretną rzecz, to to nie PRO, tylko jakiś samouczek. Też mile widziany, ale nie w tym dziale. Jeśli ktoś pokusi się o dyskusję o czymś bardziej ogólnym w tym zakresie, to ok - niech przedstawi propozycję tematu
Pozdrawiam
Chciałbym zaproponować temat, który byłby niejako rozwinięciem posta Zyx'a o "prawdziwym MVC". Konkretnie chodzi mi o ten post: http://forum.php.pl/index.php?s=&showtopic=141793&view=findpost&p=709863
Z chęcią dowiedziałbym się coś więcej na ten temat. Interesuje mnie również dlaczego największe frameworki odstąpiły od tego wzorca.
Popieram @Blame'a, gdyż właśnie Zyx otworzył mi dzisiaj oczka na prawdziwość implementacji MVC w apliakcjach internetowych i też chciałbym temat "pociągnąć" (bez skojarzeń proszę )
Przydałby się temat deployment i skalowanie aplikacji w php.
Czyli jaki narzędzia i dlaczego stosować do deploymentu działających aplikacji. Siłą rzeczy chodzi mi raczej o "większe" serwisy np. społecznościowe.
Nie widziałem takiego tematu i w sumie bardziej by on pasował do baz danych, ale ciekawym mnie się wydaje "InnoDB vs MyISAM"
Nie chodzi mi o to, że jedne obsługują transakcje czy nie itp... bardziej o wykorzystaniu konkretnych typów tabel do konkretnych działań.
Moją propozycją jest temat omawiający własne praktyki analizy ruchu w witrynie internetowej, głównie ze względu na możliwość weryfikacji skuteczności realizacji różnych celów biznesowych w sposób jaki sobie przyjęliśmy na stronie. Wiadomo, że mamy dostępne narzędzia typu google analytics, czy nawet analizatory pakietów, ale jednak istnieje pewna grupa zagadnień, które rozwikłać możemy w najprostszy sposób jedynie po stronie aplikacji jako takiej.
Druga propozycja to budowa, nazwijmy to, własnego zaplecza SEO i automatyzacja procesów aktualizacji treści linkujących na różnych stronach ( w stylu jeden panel w którym dodajemy linki do stopek w różnych naszych serwisach ), etc.
przydalby sie temat/tematy/art dotyczacy generalnie procedur postepowania i list kontrolnych:)
np. uniwersalna podejscie do deployu aplikacji - co sprawdzic, co zrobic zeby niczego nie zapomniec, kiedy mozna uznac ze zostalo zrobione wszystko co trzeba i sumienie jest czyste
podobnie z testowaniem, reagowaniem na bledy, wypadkami losowymi, wyciekami danych
mozna tu tez wliczyc np. procedury zbierania wymagan do specyfikacji: metodologie generalnie skupiaja sie raczej na metodzie opisu czy sposobie zbierania wymagan, ale przydalby sie zwykly prosty spis o czym zawsze pamietac albo jakie pytania warto zadac
nawet lista kontrolna tego co powinno znalezc sie z umowie z klientem tez nie bylaby zlym pomyslem
generalnie brakuje mi systematycznego podejscia do problemow, ale w partyzancki sposob - nie chodzi o tworzenie kulawej metodologii, tylko o stworzeniu listy "todo-check" w ktorej kolejne rzeczy punkt-po-punkcie mozna odhaczyc:) mysle ze cos podobnego pozwolilo by wszystkim spac spokojniej i np. "omfg zapomnialem ustawic strefy czasowej na serwerze prod", albo "w umowie podpisanej z klientem nie ma ani slowa o supporcie" pojawialoby sie rzadziej
Odświeżam temat PHP w chmurze. Tematyka nie jest już tak egzotyczna jak jeszcze rok temu, narzędzia coraz lepsze, a możliwości coraz większe. Zamiast jednak skupiać się na czysto technicznych zagadnieniach, proponuję dyskusje na temat czy PHP w chmurze ma sens, jakie przed chmurą są zagrożenia oraz jakie oferuje możliwości. co wy na to?
Chciałbym porozmawiać na temat testowania aplikacji php. Czy testujecie swoje aplikacje? Jeśli tak, to jakich narzędzi używacie? Czy w firmach w których pracujecie wdrożone jest continuous integration? Jak w praktyce wygląda praca nad testowaniem aplikacji? Czy używacie testów jednostkowych? Uważam że temat testowania aplikacji to coś ciekawego, o czym stosunkowo mało w polskim internecie - mysle ze moze to byc ciekawy temat do dyskusji.
Bardzo ciekawa propozycja ze strony ActivePlayera, szczególnie jeżeli wątek mógłby wyjść poza temat testów jednostkowych i stada małp klikających co popadnie.
A może coś interesuje kogoś w pozycji: "Testowanie bezpieczeństwa aplikacji internetowych. Receptury" ?
Kupiłem sobie jakiś czas temu i zawsze chętnie mogę się informacjami z niej podzielić. Trochę moim zdaniem po łebkach leci z tematyką, ale dla początkujących powinna nieco tematykę ukierunkować. O ile się przełamią, bo pisana językiem dla nich dość technicznym. Ogólnie zerknijcie w spis treści w księgarniach internetowych i może coś Was zainteresuje.
Ja bym mógł zaproponować temat, który już trochę się rozwinął w 'Autoloaderze'. Mam na myśli cache i sposoby cache'owania. Na pewno wiele osób będzie zainteresowanych.
a może temat o identyfikacji użytkowników?
Rozwiń może myśl odnośnie tej identyfikacji.
Identyfikacja użytkowników w aplikacjach sieciowych.
Jest tyle architektur identyfikacji, autoryzacji i autentykacji użytkowników i zasobów w internecie, że jest to ogromny temat. Począwszy od repozytoria lokalne użytkownik/credentials, Active Directory, po SingleSignOn, OAuth, sfederowana tożsamość, WS-Trust, SAML, Delegacja udentyfikacji, itd... zajmuję się na codzien tymi zagadnieniami w pracy, więc mógłbym uczestniczyć w takiej dyskusji.
Ok
http://forum.php.pl/index.php?showtopic=185809
Do dzieła więc
COP - Components Oriented Programin, ES - Entity System ciekawi mnie to zagadnienie, czy ktoś implementował już taką aplikację, to jest całkiem inne podejście do projektowania aplikacji niż zwykłe OOP. Wydaje mnie się dobrym materiałem na topik.
Cześć, pojawił się ten temat o keszowaniu? Wydawało mi się że go gdzieś widziałem, ale za nic nie mogę znaleźć.
Też mam pytanie dot. tematu o keszowaniu... nie umiem znaleźć, więc chyba nie ma.
Zróbcie ten temat.
Pzdr.
Jest i cache. Zapraszam do dyskusji
http://forum.php.pl/Cache_jak_czym_kiedy_t203918.html
Może temat o 'formularzach', czyli czy dajemy kompletnie wolną rękę innym czy robimy jakieś api typu
$form = new Form( 'jakis/tam/dokument', 'POST' ); $form->addTextInput( 'nazwa', 'domyslnawartosc', 'dodatkowy kod html' ); ... $form->draw();
A może tak temat o sposobie przechowywania i wyszukiwania danych w bazie?
Ja obecnie posiadam bazę danych kilka GB, ponad 300 000 rekordów, zawsze prowadziłem spis wyrazów oraz indeksy w osobnej tabeli do wyszukiwania, ale jest to bardzo odciążające dla bazy, duży rozmiar i spory czas oczekiwania na wyniki, Rozważałem wykorzystanie system fulltext mysql ale niestety całą bazę mam opartą o innodb. Do tego chciałbym usprawnić wyszukiwanie z kilku tabel, aby móc wyświetlać wyniki jako mieszane po trafności frazy, tzn aby artykuły, produkty, wiadomości, posty z forum był traktowane jak jedna pula.
Wiem że temat trochę pod bazy, ale w zasadzie chodzi tutaj o rozwiązanie w php, sama baza danych to za mało, dlatego piszę tutaj.
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)