Forum PHP.pl

To ja może odpowiem pytaniem na pytanie Ci... Czy PHP samo z siebie może być stroną inicjującą komunikację i żyjącą na serwerze sposób ciągły? Gdy zdasz sobie sprawę JAK działa serwer, zrozumiesz sedno problemu w swoim pytaniu.

Chyba najprościej jest sprawdzić czy pomiędzy interesującymi Cię godzinami jakieś zadanie ma swój początek lub koniec. Jeśli ma początek, to decydujesz które ma pierwszeństwo i albo wciskasz nowe przed nie, albo ustawiasz nowe po jego końcu. Gdy masz w tym czasie koniec, to po prostu ustawiasz początek nowego po zakończeniu starego.

Inna sprawa jest taka, że IMHO źle do tego podszedłeś. Istotny jest bowiem początek i czas trwania, a nie godzina zakończenia. Tę łatwo wyliczyć dodając do początku czas trwania Poza tym dodając kolejne rekordy nie grzebiesz się z tym, ale jeśli to jest kolejka jakaś, to łapiesz pierwszy z brzegu o najwcześniejszej dacie. Gdy się skończy, znowu łapiesz najwcześniejszy, aż do wyczyszczenia kolejki. Wszystko zależy do czego Ci to potrzebne.

Na początek sprawdź w jakim momencie to jest uszkadzane. Na poziomie dodawania do bazy? Wcześniej albo później? Może gdzieś jest limit długości znaków? Bez wiedzy w którym momencie to się dzieje nie określisz jaka część skryptu za błąd odpowiada.

Nie ma czegoś takiego jak branżowy standard. Są najwyżej dobre praktyki, których olewanie potrafi nas kopnąć po czasie boleśnie. To czego wiele osób nie mówi, to fakt, że bezkrytyczne ich stosowanie potrafi narobić więcej szkody niż pożytku czasem. O ile sama ich idea jest jak najbardziej słuszna nie znaczy to, że trzeba je stosować wszędzie, zawsze i w 100%. Może bowiem dochodzić do sytuacji, gdy jest to już sztuka dla sztuki i nie przyniesie żadnych korzyści. Może nawet wygenerować niepotrzebne koszty. Czy bowiem jest sens pisać test pokrycia dla setterów i getterów najprostszych? Dobre praktyki powinniśmy stosować, ale nie możemy tego robić automatycznie i bezrozumnie. Wszystko musi mieć swój sens. Dotyczy to wszystkiego: wzorców, SOLID, DRY, TDD, BDD, DDD i co tam jeszcze sobie nie wymyślisz za skróty. To musi naturalnie wynikać z tego co robisz i jak. Jeśli wrzucasz to na siłę, to może istnieć podejrzenie, że nie do końca to rozumiesz,a tym samym implementacja tego w projekcie może być błędna. To trochę tak jak z kultem Cargo. Naśladujesz coś, licząc na określony skutek, choć on nie musi nastąpić, ponieważ nie rozumiesz tego co robisz. Zrozumienie przychodzi często dopiero z doświadczeniem i odpowiednio dużą ilością projektów oraz "kłótniami" z innymi developerami.

Pytanie co konkretnie chcesz zrobić i czy wiesz co siedzi w tych kolumnach. Możesz mieć bowiem błąd na poziomie logiki zapytania. Nie ma zwyczajnie wyniku dla tego co chcesz zrobić bo zapytanie ma złą konstrukcję. Przykład? Szukasz rekordu, który w kolumnie pasuje do wzorca i w innej też pasuje do tego samego wzorca. Pytanie tylko czy aby na pewno to miano osiągnąć? Może miał pasować nie do obu naraz, ale do któregokolwiek z nich? Może błąd zakradł się do tego co kolumna zawiera? Dane tam mają w treści znak, który nie może być wprost wrzucony do XML? Może trzeba wpierw zamienić takie na encje, by nie spowodować błędu parsera? Przyczyny mogą być tym samym różnej natury i dobrze by było gdyby określono gdzie konkretnie problem się pojawia. Na jakim poziomie? Czym się objawia?

Poczytaj o scrollHeight i scrollTop

Raczej miał na myśli COBOL ;)

Ale ogólnie posłuchaj rady strife. Z czasem bowiem sam dojdziesz do przekonania, że technologia to sprawa drugorzędna. Nieważne w czym piszesz. Czy jest to PHP, czy Python, czy JavaScript, to naprawdę nieistotne. To tylko składnia, którą można opanować w rozsądnym czasie. Istotne jest to na ile jesteś dobrym programistą. Na ile potrafisz myśleć, jak radzisz sobie z rozwiązywanie problemów, w jaki sposób tworzysz rozwiązania. Często nie jest sztuką je znaleźć, ale zaimplementować w sposób, który nie zemści się po tygodniu czy miesiącu, bo klient zmienił swoje wymagania.

Nowe rzeczy możesz poznawać, bo to zawsze się przyda. Choćby dlatego, że to poszerza Twoje horyzonty i pozwala poznać sposób w jaki rozwiązuje się być może te same problemy w innym języku czy technologii. Możesz też wtedy podpatrzyć w większej ilości kodu ciekawe podejścia i zastosować we własnym kodzie. To naprawdę daje korzyści. Jeśli się rozwijasz, to często po kilku miesiącach własny kod widzisz i łapiesz się za głowę jak głupi byłeś gdy to pisałeś... W końcu dochodzisz do miejsca w życiu, gdy język jest tylko lukrem, a Ty rozwiązujesz problem, który potem może implementować nawet ktoś inny na podstawie Twojego pomysłu czy propozycji implementacji.

I będzie sypało nadal. Zobacz jak przypisujesz datepicker. Wszyscy mówią o unikalnych id i coś tam Ci świta bo zacząłeś kleić je z użyciem inkrementowanej zmiennej, ale gdy już jakiś utworzysz, to chyba trzeba jeszcze sprawić, by do niego datepicker się podbindował. I na to teraz warto popatrzeć.

Bo logger też jest servicem o ile dobrze kojarzę i też musi być wstrzykiwany. Czasem zresztą trzeba się przyjrzeć, bo niekoniecznie wszystko wstrzykuje się przez konstruktor, ale jako dodatkowe wywołanie odpowiedniego settera, już po wywołaniu konstruktora.

Pamiętaj, że Services możesz ładnie odseparować funkcjonalnie, zgodnie z regułami SOLID, a by całość działała w miarę sprawnie i bez zbędnego żonglowania nimi w kontrolerze, Dependency Injection Container może wstrzykiwać zależności. To naprawdę nic niezwykłego, że Symfony w DIC wstrzykiwuje jeden serwis do innego.

Zgadzam się z Crozinem. Osobiście Entity same w sobie jest u mnie jedynie odpowiedzialne za operacje CRUD, na które nałożone jest Repository jako dostarczyciel i obrabiarka danych, ale jeśli ma być coś z tym sensownego robione, co wykracza poza daną encję oraz jej repozytorium i staje się bardziej rozbudowane, wydzielam do osobnych usług za to odpowiedzialnych. I tu właśnie świetnie sprawdzają się Services, które konieczne dla startu rzeczy typu entity manager czy walidatory dostają ładnie do konstruktora z użyciem DI. a odwołanie do nich w kontenerze jest banalne. Wszystkie ograniczenia, parametry, warunki i tak dalej może właśnie kontroler przekazać do serwisu,

Sitemapy to jedno, ale dodatkowo można "pingnąć" googlebota

A może byś sprawdził oprócz sparowania nawiasów, dodatkowo, czym się różni używanie pojedynczego i podwójnego apostrofu? Bo to będzie następne pytanie po tym gdy już poprawisz błąd "w linii 29"

Domyślnym zachowaniem przy formularzach jest tworzenie niezależnych Type, które odpowiadają za konkretne działania. Osobiście nie widzę sensu w aż tak rozdrobnionej formie zapisu, ale może to tylko jakiś prosty przykład by pewną ideę zamodelować. Może chodzi Ci być może o mechanizm Validaton Groups, o czym my nie wiemy...

Ja bym już $this sprawdzał

Ogólnie podejście dobre, choć zapomniałaś, że indeksowanie tablicy jest od 0, a nie 1. No i można nieco sprawę zoptymalizować przyjmując pewne wartości domyślne. Funkcję masz jednak wykonaną w miarę poprawnie ( poza sprawdzeniem wystąpienia... sprawdź co i kiedy zwraca ta funkcja)i to o czym wspominam to już nieco "czepialstwo". Ogólnie można też zamiast posługiwać się w wyniku indeksem tablicy asocjacyjnej, by wiadomo było czym są 0 i 1 indeks wyniku. Stąd bardziej optymalne jest moim zdaniem wyrzucenie osobnych zmiennych (choć to pogwałcenie założeń zadania ) i od razu posłużenie się tablicą. W efekcie powstanie nam:

[PHP] pobierz, plaintext 
function stringExistAndCount($search, $newString) {
    $result = ['stringExists' => false, 'stringCount' => 0]; /* wartości domyślne */
    if (strpos($search, "koniecznie") !== false) {
        $result['stringExists'] = true;
    };
    $result['stringCount'] = substr_count($search, $newString);
    return $result;
}
[PHP] pobierz, plaintext 

A teraz pytanie jakie możesz zadać nauczycielowi, by go zaskoczyć Czemu gdy wywołamy funkcję w postaci stringExistAndCount('alalalala', 'ala') wynik będzie ['stringExists' => false, 'stringCount' => 2] a nie przykładowo ['stringExists' => false, 'stringCount' => 4] Jeśli tego sama nie wiesz, to sprawdź jak działa substr_count.

Może nieprofesjonalnie to zabrzmi z ust moderatora, ale taka pensja na warunki warszawskie (koszty relokacji, zakwaterowania itp.) jest trochę niska. W zasadzie przy takiej pensji sensowna jest tylko praca zdalna lub dla osób, które w stolicy mieszkają/urodziły się i wiele im z tego odpada. Przykład Samsunga z ostatnich tygodni jest tu dość znamienny. Zamykali wszystkie oddziały oprócz warszawskiego i też wychodzili z opcją relokacji pracowników do Warszawy, ale bez zmian w wynagrodzeniu. Znakomita większość pozostała w miastach gdzie już pracowali, nawet jeśli nie mieli nic do stracenia. Znam nawet jednego warszawiaka rodowitego, który na wieść o zamykaniu oddziału i usłyszeniu propozycji, wyśmiał ją i został w mieście dotychczasowego oddziału. To nie jest przytyk w stronę firmy i oferty, bo tego nie jestem w stanie ocenić na podstawie ogłoszenia. To uwaga dla osób, które myślą o relokacji. Niech przeliczą czy są w stanie się utrzymać.

Wybór czegoś, co jest od lat nie wspierane oraz brak łat to proszenie się o kłopoty. Pójście tą drogą, bo ktoś coś tam powiedział dobrego to fatalny wybór.

Uściślij 2 założenie: "Osoba nie może dwukrotnie zagrać z osobami z którymi już grała" może oznaczać, że wszystkie 4 nie mogą się spotkać ponownie, albo osoba nie może trafić drugi raz na choć jedną z nich.

toggle?

Wyrażenia regualarne z preg_replace ?

stripos się kłania

[PHP] pobierz, plaintext 
function alike($item, $full){
    return stripos($full, $item) === 0 ? true : false;
}
[PHP] pobierz, plaintext 

EDIT: stripos zwraca false gdy ciągu szukanego brak albo pokazuje miejsce jego rozpoczęcia. Nas interesuje gdy znajdzie ciąg i pokazuje jego początek na indeksie 0... stąd tylko taki wariant zwróci true.

To może sprawdź wpierw co masz w $profil i dostajesz w wyniku działania. Za Ciebie nikt debugu nie zrobi

xpath?

Na Twoim serwerze LOAD DATA LOCAL jest wyłączone. Prawdopodobnie ze względów bezpieczeństwa -> https://dev.mysql.com/doc/refman/5.1/en/load-data-local.html