Programowanie

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.

Stare ludowe przysłowie mówi “tylko prawdziwi twardziele nie robią backupu”. Ja niestety do prawdziwych twardzieli się nie zaliczam, więc robię regularne backupy. Wiadomo – spadały wahadłowce, nasz serwer też się prędzej czy później spali 😉

Współczesna architektura aplikacji skupia się na trzymaniu danych w… bazach danych. W naszym przypadku jest to zwykle MySQL. Więc na tym się skupimy. Nie wiem jak wy, ale ja lubię mieć kopię każdej bazy w osobnym pliku. Jak to zautomatyzować? Poprzednie używałem Perla, a teraz wiem jak zrobić to bez niego.

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.

Dzisiejszy dzień przyniósł mi do wykonania kolejne zadanie z którym ktoś sobie nie poradził. Wiadomo Linux jest cool, da się wszystko zrobić tylko trzeba się naklepać. Zadanie było nader proste: zautomatyzować proces wysyłania danych na serwer SFTP.

Wydaje się to być proste – mamy crona, mamy login i hasło do serwera SFTP jest tylko jeden problem serwer SFTP zaraz po połączeniu pyta o hasło i nie przejmuje go z linii poleceń.

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 🙂

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.

Zupełnie zapomniałem poinformować was o tym, że Google Storage jest teraz dostępny dla wszystkich i za darmo! Co najlepsze, za można dostać aż 5GB pojemności, 25GB transferu do + 25G z Google storage, 2500 requestów typu PUT, POST i LIST oraz 25000 darmowych requestów typu GET i HEAD i innych.

Dodatkowo pojawiła się lokalizacja serwerów EU, co wydaje się być bardzo korzystne szczególnie dla klientów z Polski.

Nie wiem jak wy, ale ja przy debugowaniu JavaScriptu używam zawsze code inspectora, albo zwykłego alert. Nie zawsze jest to ładne, nie zawsze wygodne no i zatrzymuje wykonywanie skryptu co w przypadku większych i dłuższych skryptów jest trochę upierdliwe. Powstał więc projekt Blackbird .

Wszystko co robi, to umożliwia ładniejsze debugowanie skryptów JavaScript. Wystarczy wywołać jedną z komend, a informacja pojawi się w gustownym boxie.

Zwykle jestem bardzo przywiązany do rozwiązań, które znam lubię i… sprawdziłem. Zaskoczyła mnie wiadomość o wypuszczeniu czegoś szybszego (i być może lepszego) niż mój ukochany CodeIgniter . Mowa tutaj o DooPHP , który pojawił się stosunkowo niedawno i zdeklasował mojego faworyta w walce o prędkość.