Do napisania czegoś o mysql skłoniły mnie dwie rzeczy. Były to dwie migracje. Jedna z mysql 5.0 do mysql 5.1 i migracja z PostgreSQL 8.1 do 8.3 jakie wykonałem kilka dni temu. Zacznę może od tego co zaskoczyło mnie bardzo pozytywnie. Czyli migracja do Postgresa 8.3 .
Continue reading »
Ostatnio zainteresowałem się pozycjonowaniem stron internetowych i naczytałem wielu artykułów o SEO (Search Engine Optimization), później popróbowałem trochę własnych sił, co doprowadziło mnie do kilku ciekawych wniosków, którymi chciałbym się podzielić.
Continue reading »
Podczas rozwoju dużego portalu webowego każdy prędzej czy później stanie przed problemem wydajności. Przeważnie najbardziej wąskim gardłem jest baza danych. Łatwo jest rozproszy obrazki na więcej serwerów, nawet content html czy pliki php. Najgorzej jest ze skalowalnością bazy. Nie dość że jest to problem od strony technicznej to również jest to najbardziej kosztowne. Po pewnej ilości użytkowników okazuje się że cachowanie, czy generowanie statyczne wszystkiego co było możliwe nie jest już wystarczające a na dodatek wielu użytkowników wykorzystuje opcję przeglądu czy search które pochłaniają najwięcej zasobów bazy danych. W takich przypadkach z pomocą może przyjść nam sphinx. Oczywiście jak w każdym przypadku jego zastosowanie niesie ze sobą wiele plusów i minusów a zadaniem tego artykułu będzie pokazanie jak sobie z tym wszystkim poradzić i jak optymalnie wykorzystać możliwości sphinx’a.
Sphinx to darmowy silnik SQL full-text search na licencji GPL 2. Jest to program pozwalający na zaindeksowanie wybranej przez nas części bazy danych i przeszukiwanie go w bardzo wydajny sposób . W chwili obecnej pozwala na podłączenie sie do MySQL’a i PostgreSQL’a. Posiada natywny support do PHP, Pythona, Javy, Perl’a i Ruby.
w tym wpisie chciałbym rzucić światło na problem zarobków freelancera i sposobów w jaki powinno wycenić się swoją pracę. Dobra wycena projektów jest zadaniem najbardziej kluczowym ponieważ zrobienie tego profesjonalnie i dobrze gwarantuje zadowolenie i zyski dla obu stron, klienta i freelancera. W przeciwnym przypadku projekt będzie jednym wielkim nieporozumieniem i skończy się źle dla jednej ze stron lub najczęściej dla obu. Podstawową zasadę prowadzenia interesów można zawrzeć w słowach: “Obie strony wygrywają albo nie ma biznesu”. Podczas podejmowania się zleceń należy również zastanowić się na czym nam zależy. Chcemy za wszelką cenę zdobyć to zlecenie (nawet spuszczając spodnie poniżej kostek) , czy chcemy zarobić pieniądze, uzyskać kolejnego zadowolonego klienta i nauczyć się czegoś nowego?
Natchnieniem do napisania tego artykułu były dla mnie doświadczenie ostatnich kilku lat mojej pracy i to że mówienie NIE przynosiło mi często więcej pożytku od mówienia tak. Ostatnio znalazłem też w sieci artykuł 10 Absolute “Nos!” for Freelancers który pokazuje że nie tylko ja miałem podobne problemy, a kluczem do ich rozwiązania jest asertywność.
Czy możesz przedstawić nam projekt/atrape a my się zastanowimy
NIE!
Każda szanująca się firma przed podpisaniem umowy z klientem ustala ile kosztować będzie każda część pracy. Przygotowanie projektu, atrapy czy analiza też są płatne. Jeżeli masz poświęcać swój czas to nigdy za darmo. Przeważnie podczas tworzenia aplikacji faza analizy i projektu to koszt na poziomie 15-20% płatny od razu po wykonaniu. Klient zawsze może zabrać owoce pracy analitycznej i pójść do innego developera. W takich przypadkach zaproponuj że projekt/analiza może być wykonany za odpowiednią opłatą razem z przeniesieniem praw autorskich do projektu na klienta. Zaproponuj też podpisanie odpowiedniej umowy bo w przeciwnym razie napracujesz się za darmo a w najlepszym przypadku postawisz się na z góry przegranej pozycji podczas negocjacji ceny całego projektu ponieważ ty już włożysz swoja pracę za która będziesz chciał odzyskać pieniądze a zleceniodawca wykorzysta twoją naiwność i słabe położenie w negocjacjach.
Artykuł ten będzie małym przeglądem tego co można zrobić by oszczędzać moc obliczeniową twojego serwera i transfer twojego łącza. Jeżeli należysz do ludzi którzy uważają że najlepszym rozwiązaniem jest zawsze dokupienie szybszego łącza i większego kabla nie trać czasu na czytanie 🙂
Subselect to fajne zapytanie, ale co w sytuacji, kiedy musimy przeszukać miliony rekordów i to setki razy w ciągu minuty. Subselect okaże się mało wydajny, a przy dużej ilości zapytań liczy się każda oszczędność. W portalach społecznościowych często użytkownicy poszukują innych profili na postawie wieku lub wzrostu i tutaj nie ma żadnych problemów, gdyż łatwo przechować je w jednej tabeli. Gorzej jest natomiast z danymi typu znajomość języków obcych czy zainteresowania, gdzie pola te mogą mieć wiele wartości. Niektórzy stosują harcerskie rozwiązania w stylu umieszczania wielu danych do jednego varchar’a i użycie LIKE w zapytaniu. Mnie chyba nie przyszłoby coś takiego do głowy 😉 Innym pomysłem byłoby zastosowanie pól typu array, lecz odradzane jest to nawet na stronie PostgreSQL:
Najświeższe komentarze