Każdy z nas posiada zestaw “snippetów” – nie wiem jak to przetłumaczyć na język polski – skrawki? wstawki? fragmenty kodu? Chodzi o kod, który używamy dosyć często w różnych projektach. Czasami jest to jakaś działająca funkcja sprawdzająca poprawność zmiennych, czasami jest to sposób użycia jakieś klasy a czasami jest to… coś innego. Wiadomo o co chodzi – Snippet to taki kod, funkcja, klasa którą możemy wielokrotnie używać przy różnych okazjach.
Wspominałem już o kilku edytorach on-line (a może powinienem napisać w “chmurze”) – niestety przy żadnym nie zatrzymałem się na dłużej. Bardzo dobrze zapowiadał się Cloud9 dzięki swojej integracji z GITem no i generalnie poprawnym i sprawnym działaniu. Co mi się nie spodobało? Za dużo klikania, za duże guziczki… no nie wiem. Nie przypadł mi do gustu. Niby wszystko działa poprawnie, ale czegoś mu zabrakło.
Jednak znalazł się edytor przy którym zostałem na dłużej – prawdę mowiąc w kilku przypadkach uruchamiam go częściej niż moje ulubione Komodo Edit . Jego nazwa to ShiftEdit . Grafika prosta, wręcz prymitywna – ale to edytor, narzędzie 🙂 Młotek nie musi mieć ornamentów – ma działać. Tak jest właśnie z ShiftEdit.
Jakiś czas temu Google wyliczyło, że jeżeli strona ładuje się “szybciej” to generuje 20% więcej przychodów. Wszystko idzie więc w kierunku przyspieszania i optymalizacji tego co się da. Są dwa rodzaje operacji jakie możemy wykonać w celu przyspieszenia ładowania strony. Część z nich to zadania server-side, które polegają na optymalizacji generowania strony, przepływu informacji do klienta (kompresja stron, css, JavaScript, cache’owanie zapytań SQL itp, itd). Druga strona to wizualne tricki, które powodują, że strona renderuje się “szybciej” w przeglądarce klienta.
Komodo Edit to darmowa wersja bardzo dobrego edytora komodo IDE. Przez lata używałem EditPlus’a, niestety jego możliwości okazały się zbyt małe. Komodo Edit jest bardzo wygodnym narzędziem dla programisty. Świetnie radzi sobie z obsługą zagnieżdżonego kodu w plikach HTML, posiada autozupełnianie, można pracować zdalnie przez FTP albo SCP.
Niepodważalną zaletą jest też wieloplatformowość Komodo Edit. Jest wersja dla Windows, Linux no i oczywiście Mac OS. Zasadniczo wersje działają w miarę podobnie na każdej platformie, większych różnic nie ma. Przez chwilę używałem nawet wersji pełnej, ale jej koszty są całkiem wysokie. Czego mi brakowało w wersji darmowej? Nie wiele… znalazłem odpowiednie rozszerzenia.
Zasadniczo nie mam nic przeciwko phpMyAdmin . Towarzyszy mi praktycznie od początku przygody z PHP. Wprawdzie przez parę lat przytyło mu się znacznie, ale za to jego ostatnie wersje mają odrobinę Ajaxa dzięki temu nabrał trochę prędkości. Jednak nie o nim będę dzisiaj pisał, tylko o ciekawej alternatywie w postaci CIMyAdmin . Projekt o tyle ciekawy, że oparty o nasz ulubiony CodeIgniter.
Jako fanboy CodeIgniter ‘a ciężko mi było spróbować i przekonać się do czegoś innego. CodeIgniter jako framework dla PHP zapewnił to co było mi potrzebne – modularność, porządek – sporą liczbe gotowych modułów. Polubiłem go głównie za bardzo klarowną dokumentację i prostotę całego rozwiązania. Jednak po dłuższej pracy z tym rozwiązaniem odkryłem też jego braki.
Jego prostota po pewnym czasie zaczyna też być jego wadą. Brak wbudowanego CRUD’a i praktycznie nie istniejące wsparcie dla idei modelu (o czym napisał jeden z moich czytelników) to główne wady CI. W przypadku prostych projektów nie stanowi to problemu, modele tworzymy sami, ale trzeba pisać wszystkie zapytania “ręcznie” – dbać o relację pomiędzy złożonymi tabelami i obiektami.
Tym razem kilka słów o robieniu wersji językowych dla naszych aplikacji. Praktycznie każdy framework oferuje jakieś wbudowane rozwiązanie. Wbudowane rozwiązania wiadomo – raz działają szybciej, raz wolniej.
Tak naprawdę mamy do wyboru kilka opcji – trzymanie wszystkiego w osobnych szablonach dla każdej wersji językowej (widoki), wykorzystanie stałych (define('zapisz', 'save') – i odpowiedni plik dla każdego języka), trzymanie danych w tablicach globalnych (array('zapisz' => 'save') – reszta jw).
Potem w grę wchodzą rozwiązania dedykowane – pliki .ini i parsery (m.in. Smarty) no i co tam sobie wymyślimy – można tłumaczenia trzymać w bazie, potem generować jakieś pseudo konfiguracje i podmieniać. Wszystko opiera się na jednej zasadzie – musimy mieć gdzieś oryginał i tłumaczenia.
Ostatnimi czasy przyszło mi powalczyć z implementacją kodowania AES 128 w PHP. Oczywiście Google – pierwszy przyjaciel programisty – naprowadził mnie na rozwiązania typu phpAES czy 28 trafionych klas na www.phpclasses.org .
Oczywiście nie wierzę specjalnie w pisanie funkcji kodujących w czystym PHP (wolę binarki) – z pomocą przyszedł opisywany wcześniej MCrypt 🙂
Zasadniczo Mac OS X przychodzi z preinstalowanym Apachem i o ile mnie pamięć nie myli z PHP. Niestety w standardzie nie ma bibliotek MCrypt , z których korzysta wiele popularnych rozwiązań takich jak phpMyAdmin czy Magento.
Oczywiście można sprawdziź w Google jak skompilować sobie MCrypt ze źródeł, ale trwa to chwilę i trzeba dociągnąć kilka (albo kilkadziesiąt MB z sieci). Tak naprawdę potrzebne są tylko dwa pliki.
Bardzo czysty i prosty przykład wysyłania danych POSTem przy pomocy CURL. W sumie jest to bardzo prosta i podstawowa informacja, ale nigdy nie pamiętam składni.
