Propozycje tematów Opcje

[nospor]

W tym topicu proszę umieszczać propozycje nowych tematów, na które chcielibyście porozmawiać.

[athabus]

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ą.

[Turgon]

Ja z chęcią bym podyskutował na temat modelowania warstwy kontroli dostępu w połączeniu z bazą danych itp.

[nasty]

Witam

Ostatnio na jednym z blogów 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.

Ten post edytował nasty 28.07.2007, 21:00:47

[LBO]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ).

Temat: [MVC] Widok, i różna prezentacja tych samych danych.

Hmmm, zastanawiam się jak we frameworkach (najlepiej opartych o railsy) jest rozwiązywana sprawa widoków o tych samych danych, ale różnej prezentacji (HTML, XML, JSON)?
Wymyśliłem 2 rzeczy.
1. Akcja zajmuje się przypisaniem danych z modelu do widoku. W zależności od żądania, TRANSPARENTNIE podmieniany jest widok - załóżmy, że pliki z widokami (szablonami) mają jakieś ustandaryzowane nazewnictwo to ułatwiające, albo są przypisane w configu.
2. Tworzy się aliasy akcji i w zależności od typu żądania wywoływany jest odpowiedni alias w którym przebiega cały proces wysyłania/[przypisywania do widoku] danych.

Szczerze mówiąc podoba mi się sposób pierwszy. Tylko, czy to będzie odpowiednie z filozofią MVC jeżeli to w widoku zajmę się enkodowaniem danych do JSON'a - dla mnie to już ten rodzaj logiki, który powinien być przeprowadzany w kontrolerze/akcji. Może patrzę się na widok zbyt płasko? W RoR i pochodnych jako widok użyty jest wzorzec Template View (a nawet Two Step View). Wydaje mi się, że w przypadku pewnych danych można z powodzeniem zastąpić go Transform View. Tylko znów - nie wiem czy można tych wzorców używać przemiennie.

Generalnie, chciałbym, żeby działało to niewidocznie dla kontrolera (czyli jeszcze raz skłaniam się tu do opcji 1).

Może Wy macie jakieś pomysły jeszcze? Zapraszam do dyskusji.

[Strzałek]

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.

[Sedziwoj]

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]

[LBO]

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.

Założenie ogólnego tematu o MVC, nie przemawia moim zdaniem za tą ideą. Jest to bardzo obszerny temat, z założenia porusza 3 aspekty i dyskutowanie o nich w jednym wątku na pewno będzie bałaganiarskie. Udowadnia to przecież [MVC] Pytań kilka....
Wydaje mi się, że temat, który zaproponowałem jest dostatecznie, jak to mniej więcej opisał kolega powyżej, specjalistyczny, by nadawał się do PRO.

[cicik]

Ja bym chciał podyskutować o Zend API.
Konkretnie o umieszczaniu części lub całości logiki naszych aplikacji w formie rozszerzenia do PHP.

[boom3]

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.

[LEW21]

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 (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

[menic]

A może szablony jak xslt...

[acztery]

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

[tomeksobczak]

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

[batman]

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]

Mnie natomiast bardzo ciekawi zaniedbywany i mało znany temat SPL.

Co dokładnie?

• Iteratory;
• obsługa plików i folderów (po części to również iteratory);
• obsługa XML (w sumie SimpleXMLIterator);
• zabawa z tablicami (po części to również iteratory);
• wyjątki (SPL zawiera tylko definicje klas wyjątków);

czy

• obserwator

(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)

[batman]

@mike
Najlepiej wszystko (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
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] pobierz, plaintext 
<?php
class Klasa implements Iterator
{
	// duzo kodu, obliczen, itp.
	public function current() {
		//...
	}
	// itd
}
?>
[PHP] pobierz, plaintext 

Czy w takim przypadku iterowanie pętlą foreach nie będzie spowodowało większego obciążenia?

[Sedziwoj]

@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)

[batman]

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ć.

Ten post edytował batman 20.09.2007, 07:16:19

[mike]

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ć.

Hehe, wyprzedziłeś tym moje wpisy na blogu, które właśnie na ten temat piszę ;-)

[batman]

Akurat siedzę nad XMLReader i podobnie jak w przypadku SPL brakuje dobrej dokumentacji. Z chęcią zobaczę Twoje wpisy na blogu dot. tego zagadnienia (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[konradk2]

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

[nospor]

o "ciekawych" bledach takich jak Twoj to se z kolegą przy koli możesz pogadać a nie na php Pro

Nie spamuj.

[eai]

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ć.

Ten post edytował eai 21.07.2008, 05:51:25

[starach]

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.

[kwiateusz]

Prosze bardzo, temat utworzony.

[SHiP]

A ja proponuję temat dotyczący odciązania dużych aplikacji po przez rozproszony system serwerów (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) i ich ładną obsługę.

[nrm]

@SHiP: +1 wykop (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

[kwiateusz]

Gotowe (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[karmer]

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ąć.

[Speedy]

Chętnie przyglądnąłbym się dyskusji na temat zaproponowany przez karmera, a nawet włączył, jeśli uznam, że coś do niej wniosę (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) .

[starach]

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.

[LBO]

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.

Ten post edytował LBO 12.09.2008, 14:48:42

[batman]

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.

[mike]

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: PHP Archive czyli phar

[batman]

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.

[Strzałek]

W archiwum jest taki temat: Temat: drzewka_sqlowe

Nie wiem czemu nie został przeniesiony tutaj. Może warto by to zrobić teraz? Temat drzewek jest nieśmiertelny.

[batman]

W archiwum...

Doskonale powiedziane. W archiwum. Poza tym ostatni post jest sprzed ponad dwóch lat, a okres taki w świecie IT to kilka epok. Nie śledzę tematu drzewek, więc nie wiem czy nie pojawiły się jakieś nowe metody/sposoby na przedstawianie drzew lub ich optymalizację.

[LBO]

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.

[Strzałek]

Doskonale powiedziane. W archiwum. Poza tym ostatni post jest sprzed ponad dwóch lat, a okres taki w świecie IT to kilka epok. Nie śledzę tematu drzewek, więc nie wiem czy nie pojawiły się jakieś nowe metody/sposoby na przedstawianie drzew lub ich optymalizację.

No to przenieś go z archiwum do otwartego.

Jeżeli chodzi o moją propozycję: Testy jednostkowe (Unit Tests). Kto używa? Kiedy użwać? Jak używać?

Ten post edytował Strzałek 16.11.2008, 20:16:37

[Nickesh]

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ć (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif)
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] pobierz, plaintext 
<?php
// Standardowy errorHandler, którego dzidziczą wszystkie klasy w systemie.
// Oczywiście, to tylko najprostszy przykład.
 
class errorHandler {
    private $errors = array();
    
    function isError() {
        return !empty($this->errors);
    }
    
    function lastError() {
        return array_pop($this->errors);
    }
    
    function setError($message) {
        $this->errors[] = $message;
    }
    
    funciton clearErors() {
        $this->errors = array();
    }
}
?>
[PHP] pobierz, plaintext 

Oczywiście proponuję ogólną dyskuskę na ten temat - o szczegółach napisałem tutaj tylko, żeby było wiadomo, o co mi właściwie chodzi (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif)

[nasty]

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 (IMG:http://forum.php.pl/style_emoticons/default/sad.gif) ).

Bardzo mi się spodobały artykuły Michała Gołębiowskiego oraz Simon-a Guest-a 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.

Ten post edytował nasty 30.01.2009, 05:08:22

[starach]

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ę.

Ten post edytował orglee 10.02.2009, 18:38:35

[Zigi]

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.

[bim2]

Także przyłączam się do tematu na temat debugowania skryptów php. (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[athabus]

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 ;-)

[S_Olewniczak]

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?

[phpion]

Również jestem za API. Jak PRO to PRO, a nie jakieś pierdy, które co drugi programista jest w stanie wykonać.

[cojack]

Ja jestem za tematem Routing - Routery, wg mnie dość ciekawy.

[bim2]

Ja jestem za tematem Routing - Routery, wg mnie dość ciekawy.

Ehh...
Temat: Routery i sposoby routingu

[batman]

Jak Pro, to Pro:
Windows Azure SDK for PHP Developers
i/lub
Toolkit for PHP with ADO.NET Data Services

[darko]

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ą?

[Nattfarinn]

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ą?

Na to pytanie może udzielić Ci odpowiedzi każda, średnio zorientowana w PHP osoba i nie wymądrzając się mogę powiedzieć, że nie podlega to żadnej dyskusji. Sztuka dla sztuki ma swoje granice, a z klocków lego można budować nawet łodzie podwodne - pytanie tylko po co (IMG:style_emoticons/default/winksmiley.jpg) .

Jak Pro, to Pro

Słuszna uwaga (IMG:style_emoticons/default/smile.gif) . Ja proponowałbym dyskusję na temat implementacji AOP (Aspect Oriented Programming) w PHP oraz jego wadach czy zaletach. Nie tak nowe i nie tak popularne zagadnienie, ale jednak to kolejny etap ewolucji programowania. (IMG:style_emoticons/default/smile.gif)

[Moli]

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) ?

[nospor]

z prawdziwego zdarzenia, gdzie wiadomości wysyłane są do XX tysięcy osób

temat juz byl omawiany w dziale PHP

[phpion]

Drugi raz intensywnie pracuję z Allegro API i stąd moja propozycja: może warto utworzyć osobny temat pod tym kątem?

[piotrooo89]

skoro mówimy już o API to możemy podyskutować o czymś od googla. wykresy, mapy, adsense do wyboru do koloru.

Ten post edytował piotrooo89 10.11.2009, 11:34:11

[Cysiaczek]

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 (IMG:style_emoticons/default/smile.gif)

Pozdrawiam

[Blame]

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=&showt...st&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.

[blooregard]

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ę (IMG:style_emoticons/default/smile.gif) )

[ulisses]

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.

Ten post edytował ulisses 14.08.2010, 13:22:00

[masiakla]

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ń.

Ten post edytował masiakla 6.09.2010, 16:31:03

[AlexDeLarge]

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.

[yevaud]

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 (IMG:style_emoticons/default/winksmiley.jpg)
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 (IMG:style_emoticons/default/smile.gif)

Ten post edytował yevaud 13.10.2010, 01:56:26

[batman]

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?

[ActivePlayer]

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.

[Crozin]

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.

[thek]

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.

[Sagnitor]

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.

[nasty]

a może temat o identyfikacji użytkowników?

[nospor]

Rozwiń może myśl odnośnie tej identyfikacji.

[nasty]

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.

Ten post edytował nasty 14.10.2011, 11:26:25

[nospor]

Ok
http://forum.php.pl/index.php?showtopic=185809
Do dzieła więc (IMG:style_emoticons/default/smile.gif)

[cojack]

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.

[starach]

Cześć, pojawił się ten temat o keszowaniu? Wydawało mi się że go gdzieś widziałem, ale za nic nie mogę znaleźć.

[mrWodoo]

Też mam pytanie dot. tematu o keszowaniu... nie umiem znaleźć, więc chyba nie ma.

Zróbcie ten temat.

Pzdr.

[nospor]

Jest i cache. Zapraszam do dyskusji
Temat: Cache jak czym kiedy

[mrWodoo]

Może temat o 'formularzach', czyli czy dajemy kompletnie wolną rękę innym czy robimy jakieś api typu

[PHP] pobierz, plaintext 
$form = new Form( 'jakis/tam/dokument', 'POST' );
$form->addTextInput( 'nazwa', 'domyslnawartosc', 'dodatkowy kod html' );
...
 
$form->draw();
[PHP] pobierz, plaintext 

Np w aplikacjach, które mogą być rozszerzane przez os. trzecie.
Dlaczego tak? Żeby zachować spójność wyglądu

[stroju]

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.