Ostatnio zacząłem pracę nad API Facebooka i moim zadaniem było rozpracowanie tego api, takie tam. Ale doszło w reszcie do acziwmentów na facebugu. Jeden wpis w google how to, i wio ogień, jedziemy. Poszło łatwo, dokumentacja fajna, przejrzysta, wszystko ładnie opisane: link no ale gdyby wszystko poszło bez problemu nie byłoby tego wpisu…

Facebug

Nie bez kozery w żargonie programistów ta nazwa nabiera coraz silniejszego znaczenia. Kto pracuje z API tego serwisu społecznościowego ten to rozumie. Facebook jest teraz w fazie wprowadzania nowego API o nazwie kodowej Graph (wow how f***g awesome it’s?!). Wracając do meritum sprawy, po wywołaniu rejestracyjnego linka z acziwmentem ni stąd ni zowąd dostawałem błąd: „(#3502) Object at achievement URL is not of type game.achievement”, o którym już pisałem wcześniej na forum php: link, niestety nikt chyba wcześniej nie miał problemu z tym (albo miał i się nie podzielił, who care?). Sytuacja doprowadzała mnie do frustracji, gdyż po użyciu debuggera: link nie zwracał mi żadnego błędu związanego z opengraph, a błąd mówił o czymś innym. Bądź tu mądry i pisz wiersze…

Rozwiązanie problemu

Otóż przypadkiem(?) parę razy udało mnie się zarejestrować te acziwmenty, zachodziłem w głowę jak ja to zrobiłem. Maluśka retrospekcja i olśniło mnie co takiego zrobiłem. Otóż proces jaki należy wykonać przed przystąpieniem do zarejestrowania acziwmentu jest taki:

Wchodzi na stronę debbugera: link Wklepujemy link do naszego acziwmentu, klikamy debug (wow!), teraz na samym dole po poprawnej analizie naszego pliku powinna się znajdować sekcja: „Adresy URL” (tia mam po polskiemu) i jest sobie jakiś pierwszy link: Graph API: http://graph.facebook.com/blablabla klikamy na ten link, otworzy nam się stronka z wyplutym jsonem, i dawaj, po tym zabiegu możemy już wykonać poprawnie proces rejestracji acziwmentu bez żadnego problemu!

Słów kilka na zakończenie

3 dni się z tym ścierwem męczyłem…

ciągle o tym samym

W dzisiejszym wpisie kontynuuje wątek z poprzedniego wpisu, a więc nadal będzie o metodach:)Dzisiaj zbiór wszelkich różnych rzeczy dotyczących metod, czyli trochę informacji, a trochę dobrych praktyk, które warto przestrzegać, aby z kodem przyjemniej się pracowało:)Czytaj więcej »

W ramach szukania oszczędności czasu podczas tworzenia nowych aplikacji opartych o Zend Framework, zauważyłem iż najczęściej kopiowanym przeze mnie kodem jest część administracyjna, szumnie nazywana CRUD. Bardzo często jedyną zmianą jaką musiałem wprowadzić do kodu, była modyfikacja klasy modelu idąca w parze z dopisaniem nowej klasy formularza oraz ewentualne kosmetyczne zmiany w widokach. Mimo iż powyższe czynności nie są skomplikowane, marnują czas i dodatkowo generują sporo niepotrzebnego kodu w postaci kontrolerów i modeli. Z poczynionych obserwacji wyciągnąłem wnioski i napisałem prostą i funkcjonalną zarazem aplikację opartą o Zend Framework, która nie wymaga tworzenia zbędnych klas.

UniversalZF – konwencje

Aplikacja jest mieszanką konwencji oraz konfiguracji. Z jednej strony należy trzymać się założeń poczynionych przez autora (czyli mnie), z drugiej istnieje możliwość wprowadzenia ograniczonych zmian do mechanizmu dzięki konfiguracji przechowywanej w application.ini (lub odpowiedniku).

Najwięcej założeń poczyniłem w stosunku do bazy danych:

• nazwy tabel są jednowyrazowe, pisane bez podkreślników oraz bez użycia camelCase, np user, page, book, products, itd
• nazwy tabel odpowiadają dynamicznie obsługiwanemu kontrolerowi
• kolumna będąca kluczem głównym nazywa się id
• wszystkie tabele znajdują się domyślnym schemacie (w PostreSQL jest nim public)

Kolejnym wymogiem jest nazwa klasy formularza służącego do dodania/edycji rekordu. Musi ona odpowiadać nazwie tabeli w bazie danych, czyli dla user będzie nazywała się Application_Form_User. Ponadto nazwy pól w formularzu muszą odpowiadać nazwom pól w bazie danych.

I to wszystko. Jeśli powyższe warunki zostaną spełnione, będzie można korzystać z UniversalZF.

UniversalZF – konfiguracja

W przypadku konfiguracji, istnieje możliwość zdefiniowania:

• kontrolera automatycznie obsługiwanego przez UniversalZF

  universal.page[] = "user"

  W powyższym przykładzie kontrolerem tym będzie user. Oznacza to, iż tabela w bazie danych nazywać się musi user, a klasa formularza Application_Form_User.

• nazw kolumn pomijanych w widoku prezentującym tabelę z danymi

  universal.page.user.skipCols[] = "id"
  universal.page.user.skipCols[] = "password"

• widoku jaki wyrenderuje się dla konkretnej akcji

  universal.page.user.view.index = "user/index.phtml"

Jak to działa?

Za wszystko odpowiedzialny jest plugin przechwytujący żądanie i sprawdzający, czy dany kontroler należy obsłużyć przy pomocy UniversalZF. Jeśli tak, na podstawie nazwy kontrolera tworzony jest obiekt modelu oraz obiekt DbTable, przy czym obiekt DbTable tworzy się dopiero w momencie, gdy jest potrzebny (lazy loading). Resztą zajmuje się kontroler universal posiadający akcje index (listowanie wszystkich danych z tabeli), add i edit (dodanie i edycja danych) oraz delete (usunięcie danych).

Ponieważ universal jest zwykłym kontrolerem, ktoś ciekawski mógłby wpaść na pomysł odwołania się do niego bezpośrednio. Wprawdzie ktoś taki za wiele by nie zdziałał, ale i tak warto takie zapędy ukrócić. W tym celu w pliku konfiguracyjnym znajduje się hash, doklejany w pluginie do parametrów przekazanych do akcji. Jeśli ktoś wejdzie bezpośrednio na kontroler universal, ten rzuci wyjątkiem o niepoprawnym hashu.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

From some time (2+ years) we can observe a huge explosion of different  Javascript frameworks. These frameworks divide mainly into two categories

1. UI widgets / DOM manipulation frameworks
2. class based type system frameworks

In this post I would like to focus on the latter. Every time is see a new framework of this type popping on the news I tend to ask myself the same question – why ? Why one does write all does frameworks, why people so much need classes in Javascript ?

After some thinking I’ve got to a conclusion, that people need them mainly because they are used to the concept of the „class” and to a typical type system like this found in Java, PHP or „name your favorite mainstream programming language here”. This is understandable, as naturally human beings are resistive to change.  Also, some people tend to „not get” what’s going on in the prototypical type system. We cannot also blame them here because it has  some quirks and well, no one teaches it in schools ( ;P ).

One may ask himself – do we have an other choices to write clean, readable and understandable code other than using JS frameworks ? I think the answer for this question would be affirmative.

But before we come up for a solution. We must think for a second and summarize what we are trying to achieve. I think that are needs wrap in:

1. new object instantiation
2. information hiding
3. code reuse
4. modularization

The thing that some one will miss would be inheritance. Should it be on the list ? I don’t think so. The reason for the lack of inheritance is simple – inheritance has two purposes:

1. vertical code reuse – the type lower in the hierarchy inherits behavior from the type higher in it
2. signature checking – in statically typed class based languages, polymorphism is achieved through inheritance

we could achieve code reuse by other means in Javascript and as JS has no type checking we don’t need inheritance at all.

For our „no framework JS framework” we will use mainly such features of JS as first class functions and JSON. So behold, some common patterns for our daily JS programming:

//persons modulepersons = (function(){    //private Person object constructor    var Person = function(firstName, lastName, birthDate){            var foo = "bar";            var name = function(){            return firstName + " " + lastName;        }            var age = function(){            var currentYear = (new Date()).getYear()            var birthDayYear = birthDate.getYear()                        return currentYear - birthDayYear              }            var saySomething = function(){            return foo;        }                //the methods that will be public        return {            "name": name,            "age": age,            "saySomething": saySomething        }    }        //private FitnessAddict object constructor    var FitnessAddict = function(firstName, lastName, birthDate, weight, height){                var person = Person(firstName, lastName, birthDate);                var bmi = function(){            return weight / (height*height);        }                var isWeightNormal = function(){            var currentBmi = bmi()            if(currentBmi > 25){                return false            }            if(currentBmi < 18.5){                return false            }            return true        }                //we make isWeightNormal method public        person.isWeightNormal = isWeightNormal;                return person;       }    //we make the fitnessAddict object constructor public    return {        "fitnessAddict": FitnessAddict    }})()

view raw noFrameworkJsFramework.js This Gist brought to you by GitHub.

Usage of the example:

var fa = persons.fitnessAddict(    "Bar",    "Baz",    new Date(1990,5,5),    80,    1.8)    fa.isWeightNormal() // truefa.saySomething() // "bar"fa.name() // "Bar Baz"    

view raw noFrameworkJsFramework2.js This Gist brought to you by GitHub.

The first example proves, that we can achieve all of our goals through simple Javascript, without the need for frameworks. The additional benefit is that, because all is private by default, we improve the „cleanliness” of our API.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Dzisiejszy wpis będzie niecodzienny, ponieważ nie jest to news ze świata IT, konkurs ani stricte techniczny tekst. Dzisiaj poszukiwany, poszukiwana jest specjalista od Magento. Jeśli wiesz co to jest, potrafisz się w tym odnaleźć oraz posiadasz odpowiednio dużo wolnego czasu, wyślij maila na adres ksoklabs [at] gmail [dot] com. W treści maila prześlij przykłady swoich wdrożeń (linki do stron) oraz stawkę godzinową.

Ponieważ to nie ja poszukuję, nie jestem w stanie podać więcej szczegółów. Uzyskacie je pod wskazanym adresem.

po długiej przerwie

Trochę to potrwało zanim znalazłem chwilę czasu, żeby coś napisać, ale mam nadzieję, że warto było czekać:) Postaram się, żeby kolejne wpisy z tej serii pojawiały się częściej, a że w najbliższym czasie nie planuję już żadnych długoterminowych prac, myślę, że jest to założenie, które uda mi się zrealizować.Dobra, bez dłuższego przynudzania, zaczynam. Dzisiaj kilka słów o metodach, czyli:Czytaj więcej »

Pod powyższym tytułem został opublikowany artykuł w najnowszym magazynie Imagine. Magazyn jest wydawany przez Empathy i można się z nim zapoznać całkowicie za darmo online: http://issuu.com/imaginemagazine/docs/imagine_no2

Artykuł powstał dwa miesiące temu, ale z dzisiejszego punktu widzenia mogę powiedzieć że kierunek rozwoju Zend Framework 2 trzyma się planu. Zagłębiając się bardziej w jego temacie napisałem pierwszą aplikację na FB właśnie przy użyciu ZD2 i Doctrine2. Mogę powiedzieć że z punktu widzenia programisty jest dużo nowych rzeczy do nauki. ZF2 zmienia sposób pisania aplikacji internetowych. Ale na ten temat na pewno jeszcze napiszę jeszcze kilka słów

Jako że w magazynie artykuł ukazał się w wersji skróconej, umieszczam go poniżej w pełnej wersji. Życzę smacznego!

Wstęp

Deweloperzy pracujący nad rozwojem framework’a postawili duży nacisk na to by produkt, który tworzą, był bardziej spójny, dobrze udokumentowany, zwiększający produktywność i szybkość uruchamiania aplikacji. Artykuł opisuje dlaczego i w jaki sposób developerzy chcą zrealizować postawione przez siebie cele. Do pełnego zrozumienia będzie potrzebna podstawowa znajomość pierwszej wersji Zend Framework, wzorców projektowych i PHP 5.3.

Prosty i szybki proces nauki

Pierwszy krok jest najtrudniejszy, to stwierdzenie, dokładnie oddaje najczęściej napotykany problem, przez rozpoczynających przygodę z pierwszą wersją framework’a, programistów. Pomimo dobrej dokumentacji i dopracowania rozdziału „Quick Start”, programista napotyka na dodatkowe problemy związane z rozwojem aplikacji:

• Spójność. Dokumentacja opisuje jak korzystać z poszczególnych komponentów takich jak Zend_Cache, Zend_Translate, Zend_Form, itd. ale brakuje kompletnego przykładu, pokazującego jak połączyć istniejące komponenty, w bardziej złożonej i dynamicznie rozszerzanej o nowe funkcjonalności aplikacji.

• Niekonsekwencja API. Pierwsza wersja framework’a zawiera hepler’y, plugin’y i filtry, niektóre z nich posiadają spójny interfejs a pozostałe już nie. Cześć z nich posiada niejawne metody tworzone poprzez __call(), które trudniej jest znaleźć w kodzie. Część z komponentów pozwala na konfigurację poprzez przekazanie array lub obiektu Zend_Config natomiast pozostałe wyłącznie array. Niektóre komponenty pozwalają na konfigurację camelCaseOption natomiast inne na underscore_separated.

Rozwiązanie, które deweloperzy zaproponowali jako remedium na powyższe problemy można przedstawić w kilku zwięzłych punktach:

• Stworzenie podręcznika demonstrującego kompletny cykl tworzenia aplikacji internetowej w ZF2.

  Czytaj dalej tutaj (rozwija treść wpisu)
  Czytaj dalej na blogu autora...

  

  Zwiń
  Czytaj na blogu autora...