Pisałem niedawno na temat inicjatywy DevMeetings – serii darmowych szkoleń dla developerów. Otóż to, Panowie robią świetną robotę w całej Polsce, ale ostatnio poszli jeszcze dalej. W ich głowach narodził się DevCamp. A co to takiego, po co to komu, i jakie są tego wyniki dowiecie się czytając dalej.
Jakie było me zaskoczenie, kiedy 1 czerwca dostałem zaproszenie na coś, co kryło się pod nazwą DevCamp. Pozwolę sobie zacytować treść tego zaproszenia, które od razu przybliży wam cel tego przedsięwzięcia:
Co to jest? 3-dniowy event o charakterze “R&D-Campa”, na ktory zapraszamy najbardziej doswiadczonych JavaScript Developerow oraz Backend-Developerow i rozgryzamy najbardziej zaawansowane kwestie zwiazane z SSJS.
Po co? Koncentrujemy sie na niebanalnych i trudniejszych zagadnieniach zwiazanych z SSJS, jakie wystepuja w “prawdziwych”, komercyjnych projektach, udostepnionych produkcyjnie. Nasz cel: po DevCampie jestes w stanie implementowac produkcyjna aplikacje w SSJS: od wyboru technologii, po deployment na srodowisko live i monitoring aplikacji.
Kilka przykladowych tematow:
Jak migrowac baze mySQL do CouchDB lub MongoDB
Jak przekonac management do uzywania SSJS w firmie
Badanie wydajnosci: Node vs RingoJS vs V8CGI vs Java vs PHP – zarowno testy obciazajace I/O, jak i CPU
Security aplikacji opartych o SSJS, m. in. zgodnosc z OWASP10; Single SignOn, autentykacja / autoryzacja
Zdecydowałem się, czego nie żałuję i tak na początku lipca wylądowałem we Wiejcach, gdzie przez najbliższe 3 dni odbywała się totalna burza mózgów na temat SSJS.
Jedną ze świetnych i unikalnych cech języka Scala, której PHP nie posiada są tzw implicit conversions zwane też przez oficjalną dokumentację „widokami” (views). Podobny mechanizm zaimplementowany jest w C#, chociaż szczegółów szczerze powiedziawszy nie znam 
.Przejdźmy jednak do rzeczy. Czym jest widok/implicit conversion ? Jest to technika niejawnego rzutowania za pomocą funkcji zdefiniowanej przez użytkownika. Przydaje się ona gdy chcemy np. rozszerzyć wbudowaną w język klasę o swoje metody. Funkcję konwertującą definiujemy poprzez dodanie słowa kluczowego „implicit” przed deklaracją funkcji.
Poniżej przykład implicit conversion na wbudowanej klasie „String”, dzięki któremu dodajemy do niej znaną z PHP metodę „stripslashes”:
Najpierw definiujemy nową klasę stringów nazwaną „MyString”:
Kanał ATOM
class MyString(val value: String){
def stripslashes():String = {
return this.value.replace("\\\\","")
}
}
Następnie definiujemy funkcję konwertującą:
implicit def stringToMyString(string: String) = new MyString(string)
Czas na testy. Najpierw klasycznie, bez użycia widoku:
val test1 = new MyString(" aaa \\\\ ");
println(test1.stripslashes) //wyświetli aaa
Z użyciem widoku:
val test2 = " aaa \\\\ " println(test2.stripslashes) //wyświetli aaa
Jak widać, dzięki technice widoków możemy łatwo wzbogacać wbudowane typy (i nie tylko) o nowe funkcjonalności, czyniąc kod bardziej przyjaznym. Zasięg implicit conversion jest zależny od kontekstu w jakim został zdefiniowany – jeżeli zdefiniujemy go klasie to ma zasięg do klasy, jeżeli w paczce to do paczki.
Technika implicit conversion jest w pewnym stopniu podobna do zgłoszonego kiedyś do PHP ficzeru zwanego autoboxingingiem, z tą różnicą, że mechanizm implicit conversions jest mniej „magiczny” oraz ma wyraźne granice zasięgu działania. Uważam, że jest również lepszy od otwierania klas znanego z języka Ruby, oraz Javascriptowego przyłączania metod do prototypu, z powodów takich samych jak wymienione wcześniej.
A wy co o tym sądzicie ?
Poprzedni quiz przygotowany przez serwis Nettuts+ dotyczył jQuery i większych problemów raczej nie sprawił. Kolejna odsłona quizu dotyczy czystego JavaScript i jeśli ktoś na co dzień nie siedzi w tym języku, to może stanowić nie lada wyzwanie. Większość pytań, jeśli nie wszystkie, jest podchwytliwa i trzeba dobrze się zastanowić nad odpowiedzią. Za pierwszym razem osiągnąłem wynik 82,35%. Jak wam poszło?
Quiz znajdziecie pod adresem http://net.tutsplus.com/quizzes/nettuts-quiz-3-javascript/
Ostatnio w pracy miałem za zadanie zrobić upload plików w module zarządzania plikami w firmowym CMS-ie. Jak pewnie się domyślacie, oprócz uploadu samego pliku, należy wpisać jakieś informacje o nim do bazy danych, cały proces jest generalnie dość oczywisty nawet dla początkującego. Jeżeli chcemy zachować spójność operacji – czyli mieć pewność, że nie wpiszemy niczego do bazy jeżeli plik nie został poprawnie wrzucony lub na odwrót, że w razie błędu połączenia z bazą danych plik zostanie usunięty z dysku możemy wybrać dwie drogi postępowania:
Druga metoda zwykle sprowadza się do bloku „try-catch” oraz transakcji na bazie danych. Ja natomiast dzisiaj chciałbym zaprezentować podejście alternatywne oparte na wzorcu o wdzięcznie przetłumaczonej na polski nazwie „Polecenie” (Command).
Wzorzec „Command” polega na enkapsulacji całej logiki potrzebnej do wykonania jakiejś czynności. Jeżeli cała logika została zaenkapsulowana, to mamy też wszelkie informację by taką operację cofnąć. Poniżej przedstawię implementację.
Implementacja składa się z kilku podstawowych elementów:
Interfejs IExecutable wskazuje na zdolność klasy do bycia wykonanym:
interface IExecutable {
/**
* @return boolean
*/
public function execute();
}
Interfejs IUndoable wskazuje na zdolność klasy do cofnięcia operacji:
interface IUndoable {
/**
* @return void
*/
public function undo();
}
Całość zostaje złożona w abstrakcyjny typ ACommand:
abstract class ACommand implements IUndoable, IExecutable {
}
Kolejno implementacja konkretnych operacji – przyjęcia pliku, oraz aktualizacji bazy danych. Upload:
class UploadHandler extends ACommand {
private $_field;
private $_destination;
private $_targetPath;
public function __construct($field, $destination) {
$this->_field = $field;
$this->_destination = $destination;
}
public function execute() {
$filename = $_FILES[$this->_field]['tmp_name'];
$targetPath = $this->_destination . $_FILES[$this->_field]['name'];
$result = move_uploaded_file($filename, $targetPath);
$this->_targetPath = $targetPath;
return $result;
}
public function undo() {
if (file_exists($this->_targetPath)) {
unlink($this->_targetPath);
}
}
}
Aktualizacja bazy:
class DbUpdater extends ACommand {
private $_db;
private $_table;
private $_data;
private $_where;
private $_savePoint;
public function __construct(Zend_Db_Adapter_Abstract $db, $table, array $data, $where) {
$this->_db = $db;
$this->_table = $table;
$this->_data = $data;
$this->_where = $where;
}
public function execute() {
try {
$query = $this->_db->select();
$query->from($this->_table);
$query->where($this->_where);
$this->_savePoint = $this->_db->fetchRow($query);
$this->_db->update($this->_table, $this->_data, $this->_where);
return true;
} catch (Exception $e) {
return false;
}
}
public function undo() {
if (!empty($this->_savePoint)) {
$this->_db->update($this->_table, $this->_savePoint, $this->_where);
}
}
}
By ułatwić korzystanie z undo, stworzyłem jeszcze jedną klasę, reprezentującą transakcje: