Odbierając dzisiaj pocztę, najmniej się spodziewałem informacji o uzyskaniu dostępu do wersji beta AppFog, o którym szczerze mówiąc, powoli zaczynałem zapominać. Na szczęście okazało się, że nie zapomniano o mnie i w mojej skrzynce wylądowało zaproszenie do nowej chmury, pozwalającej korzystać z dobrodziejstw nowych “zabawek” dla developerów.

Ochocza zabrałem się do testowania i muszę przyznać, że coś w tym jest. Ponieważ opisuję wszystko “na gorąco”, część informacji może okazać się niepoprawna lub nieaktualna, ale mam nadzieję, że wybaczycie mi ten brak profesjonalizmu

Po zalogowaniu się do panelu administracyjnego otrzymujemy dostęp do wszelkich możliwych ustawień oraz informacji o naszym koncie. Warto od razu zaznaczyć, że na czas beta testów korzystanie z AppFog jest bezpłatne. Nie ma jednak co się cieszyć, ponieważ ekipa odpowiedzialna za chmurę wyraźnie zaznaczyła, iż nie powinniśmy stawiać produkcyjnych aplikacji – w końcu to tylko beta.

Z poziomu panelu administracyjnego możemy przede wszystkim utworzyć nową aplikację.

Możemy stworzyć własną aplikację lub skorzystać z już gotowej. Niestety wyboru nie mamy zbyt dużego – Nwiki (aplikacja oparta o Node.js, korzystająca z MongoDB), WordPress (raczej nie wymaga wyjaśnień) oraz RSM Browser (przeglądarka zasobów MongoDB napisana w Ruby).

Ponieważ Node.js oraz Ruby znam o wiele gorzej niż PHP, wybrałem WordPressa. Instalacja zajęła nie więcej niż kilkanaście sekund i po chwili mogłem zabrać się za konfigurację bloga. Od strony administracyjnej niczym się on nie różni od WordPressa hostowanego na każdym innym hostingu. Może działa nieco szybciej. Zaktualizowałem WP do najnowszej wersji, zaktualizowałem pluginy oraz skórki i nie pojawiły się żadne problemy.

Korzystając z okazji, że za wersję beta nie trzeba płacić, poszalałem z zasobami serwera oraz ustawieniami aplikacji. Okazało się, że można uruchomić do 10 instancji aplikacji, skierować własną domenę na aplikację oraz przydzielić do 2 GB pamięci. Ponadto otrzymujemy do dyspozycji bazę Mysql w wersji 5.1 oraz MongoDB w wersji 1.8. Poza tym możemy dodać własne zmienne środowiskowe oraz aktualizować aplikację przy pomocy Gita i Githuba.

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

Zwiń
Czytaj na blogu autora...

Co ma wspólnego loose coupling z dependency injection. Po co jest dependnecy injection i po co do tego dokładać jeszcze kontener?

Zend_Mail provides a great and simple in use and configuration mechanizm to send emails. The problem begins when you would like to specify fully templated and layouted messages.

In my current project I have several kinds of mails: customer invoices and messages, users notifications, admin notifications, webmaster email about critical errors in scheduled system tasks. In this case the Zend_Layout fits perfectly to redner rich text content by Zend_View, but it is implemented in Zend_Mail, wchih provies simply setBodyText() and setBodyHTML() methods.

This inconvenience is understandable by the way, mainly in context simpe, clear and flexible extendable code of Zend Framework. We will strive to extend the functionality od Zend_Mail following ZF developers concepts.

Overview

Writing class extending Zend_Mail I kept a several concepts:

• Messages should be both templated and layouted using Zend_View and Zend_Layout.
• The email view scripts (templates) there are in main view scripts directory nested in subdirectory (as deep as you want).
• … The same path story with layouts.
• You can use this object excatly the same way as Zend_Mail. It behaviour the same way as parent until you set special options (like point to view script path or file to render in body).
• … and object should keep Zend_Mail fluent interface (returning $this in setters) to provide method chaining fluent interface.
• Pointed view file is rendered as a mail body.
• You can use this object excatly the same way as Zend_Mail. It behaviour the same way as parent until you set special options (like point to view script path or file to render in body).

Zend_Mail application.ini configuration and extending application

Simply paste several lines to application.ini configuration, theare are self-commented, description is not neccessary at this point. We will use SMTP transport:

resources.mail.transport.type = smtp
resources.mail.transport.host = YOUR_HOSTNAME
resources.mail.transport.auth = login
resources.mail.transport.username = "YOUR_ACCOUNT"
resources.mail.transport.password = "YOUR_PASSWORD"
resources.mail.transport.register = true
 
resources.mail.defaultFrom.email = YOUR_ACCOUNT
resources.mail.defaultFrom.name = "MyService.com"
resources.mail.defaultReplyTo.email = YOUR_ACCOUNT
resources.mail.defaultReplyTo.name = "MyService.com"

In addition we will create tho additional directories and files:

• /application/views/scripts/email/-  just add a subdirectory /email to existing view scripts directory.
• /application/layouts/scripts/email/ – the same story as above

TIP: I have moved default configured layouts direcotry to /application/views/layouts/ to unify structure of application. Just change in application.ini this line:

resources.layout.layoutPath = APPLICATION_PATH "/modules/default/views/layouts/scripts/"

To test our class let’s create additional two files:

/application/layouts/scripts/email/html.phtml

< ?php echo $this->layout()->content ?>
<p>--<br />Best Regards,<br />MyService.com</p>

and scond one, the information about successfull account register with your own content:

/application/views/scripts/email/AccountRegister.phtml

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

Zwiń
Czytaj na blogu autora...

I have just started introducing Zend Framework when I had to face the problem with output multiple error messages in form while email address validation. Checking domain (whith is enabled by default) causes additional error messages indicates anomalies in hostname segment of provided by user email address. In result, we receive several errors assigned to one email field.

The problem is easy to slove by overriding default behaviour of Zend_Validate_EmailAddress clearing all messages generating while validation and setup a new single error message.

Simply add namespace MyOwn_ for own needs and provide class in file /libraries/MyOwn/Validate/EmailAddess.php

class MyOwn_Validate_EmailAddress extends Zend_Validate_EmailAddress
{
  const INVALID = 'emailAddressInvalid';
 
  protected $_messageTemplates = array(
    self::INVALID => "Invalid Email Address."
  );
 
  public function isValid($value)
  {
    parent::setOptions(array(
      'allow' => Zend_Validate_Hostname::ALLOW_DNS,
      'domain' => true,
      'mx' => true,
      'deep' => true)
    );
 
    if(!parent::isValid($value)) {
      $this->_messages = array(); // clear all previous messages
      $this->_error(self::INVALID);
      return false;
    }
 
    return true;
  }
}

And provide above custom validator to form element in /application/forms/AccountRegister.php:

class Form_AccountRegister extends Zend_Form
{
  public function init()
  {
    $this->setMethod('post')
         ->setName('Account_Register');
 
    $email = new Zend_Form_Element_Text('email');
    $email
      ->setLabel('Email address')
      ->addValidator(new ZendUtil_Validate_EmailAddress)
      ->setRequired(true);
 
    $this->addElement($email);
 
  }
}

NOTE:

• In addition, you can simply translate the emailAddressInvalid message.
• For sticklers, setting options in isValid method is hardcoded with look like a messy code, but it is quick-fix

Hope it will help.

As you probably have noticed, PHP 5.4 is around the corner. As far, there’s Release Candidate 6 available and final release is a matter of weeks. Let’s have a look at new features, that will make PHPers live easier. Traits The major change is traits implementation. Traits aims to reuse code in horizontal way. It’s [...]

Pracując z zewnętrznymi danymi zdarza nam się stanąć przed kwestią sprawdzenia poprawności danych, które do nas spływają w postaci xml. Czasami też możemy chcieć sprawdzić poprawność wygenerowanego przez nas xml’a, w szczególności czy zawiera wszelkie wymagane elementy. Z pomocą wówczas przychodzi nam klasa DOMDocument oraz schemat opisu struktury xml w postaci DTD (Document Type Definition). [...]

Do tego wpisu zostałem zmotywowany czytając o google’owskiej potędze i ich sposobie na utrzymanie setki tysięcy serwerów. Pewnie się zastanawiacie jak to jest możliwe, że firma oferująca całą masę produktów takich jak wyszukiwarka, youtube czy też gmail jeszcze na tym zarabia? Od razu zaznaczę że, płatne odpowiedniki i opcje premium niektórych produktów nie zarabiają tak wiele by utrzymać tyle maszyn, wysłać własne sondy w kosmos i jeszcze do tego utrzymać youtube – serwis generujący spore straty, kto wie ile transferu i przestrzeni dyskowej jest zużywane/zapełniane w jeden dzień niech napisze, a reszta niech się zastanowi jak to utrzymać.

Reklamy

Tak, google zarabia na reklamach i nie są to przychody małe, zastanowicie się dlaczego inne serwisy nie mają takiej fortuny z tego rodzaju świadczeń? Odpowiedz jest bardzo prosta google monitoruje naszą obecność w sieci. Na podstawie wszystkich zapytań, stron na których przebywaliśmy i ilości czasu spędzonego na nich, generuje  profil każdego z nas, a następnie dokleja nam do strony którą odwiedzamy dedykowane reklamy. Może i nie jest to zbyt wielkie odkrycie, ale analizując i przekładając na nasze potrzeby (tworzenia stron www) możemy go wykorzystać by zainteresować użytkownika wpisami które go na prawdę interesują i które będą od razu wpadać mu w oko bez konieczności wertowania dużej ilości podstron wpisów.

Tematem głównym wpisu

… nie będzie google, ani jego niepodważalna fortuna, a właśnie sposób na wykonanie takiego gadżetu na naszą stronę. Na samym początku trzeba wybrać drogę jaką pójdziemy. Możliwości jest dosyć sporo od reguł pisanych dla wszystkich użytkowników, nawet tych nie zalogowanych – tutaj opierając się na ip lub ciasteczkach tak jak robi to google do systemu tylko dla zalogowanych użytkowników. Odpowiedzią w którą stronę powinniśmy pójść jest odpowiedz na pytanie:

Instalując taki moduł mamy zamiar zarabiać na użytkownikach czy ułatwić im życie?

Osobiście chcę zainteresować użytkownika treścią mu potrzebną, więc zainwestuję w mniej skomplikowany system, ale bardziej precyzujący interesujące użytkownika artykuły. Dzięki temu nie tworząc masy profili osób, które nie powrócą do mnie na bloga lub osób których identyfikacja nie jest możliwa. O samym rozpoznawaniu użytkowników można by napisać obszerną notkę więc tutaj powiem tylko o użytkownikach najłatwiej rozpoznawalnych – stałe ip lub konta w naszym serwisie i ich przeciwieństwie – osoby nie akceptujące ciastek, nie posiadające stałego ip. Dla osób zainteresowanych tematem identyfikacji użytkowników nie posiadających konta w naszym serwisie podsunę pomysł – rozpoznawał bym ich na podstawie adresu ip i ciasteczek z wielkim naciskiem na to pierwsze, ciasteczka są znane z swej ulotności, a osoby z stałym ip będą mieć komfort – oczywiście o poprawności tego rozwiązania można by dużo złego powiedzieć, kiedyś coś o tym napiszę!

Kolejnym gorszym problemem jest określenie praw na jakich będziemy przypisywać do konkretnych użytkowników interesujące ich wpisy. Mamy kilka dróg: od bardzo restrykcyjnych i dających sporą dokładność zarazem mocno obciążających nasze serwery jak i sposoby dla leniwych, przedstawię oba i krótko omówię w jaki sposób można by to zorganizować za pomocą mysql’a.

Tagi

Mówimy o gruszce, a tutaj znienacka pietruszka – już śpieszę z wyjaśnieniami, do zrozumienia całości tematu przyda nam się wiedza o tz. tagach – są to krótkie zwięzłe tytuły którymi możemy określić zawartość danego wpisu, jednoznacznie opisujące jego zawartość zazwyczaj służą do pogrupowania treści niczym kategorie tylko w nieco bogatszy sposób. Wpis zazwyczaj posiada jedną kategorię i co najwyżej pod kategorię, używanie kilku kategorii do opisu danej treści jest raczej czymś nie spotykanym, a tagi są właśnie takim elementem który się genialnie do tego nadaje!

Leniwe doradzanie treści

Leniwe ma oznaczać takie które zasobów naszego serwera nie pożre razem z dziesięcioma użytkownikami online, więc zastanawiamy się jak można podejść gościa by wyzyskać od niego informację o jego zainteresowaniach, nie pytając się go w prost. Możliwość jest tylko jedna – musimy go po cichu śledzić i spisywać wszystkie adresy na jakich bywa w obrębie naszej witryny. Tutaj przydadzą nam się informacje o tagach, opis powyżej staje się potrzebny każdy wpis ma kilka tagów więc zakładając użytkownika czytającego wpis o Zend z dwudziestoma tagami, możemy insynuować że jest zainteresowany nim, a opisem zawartości artykułu czy też wpisu są tagi, użytkownik więc dostaje dopisek do swojego konta o zainteresowaniu danymi tagami, a jeśli takie tagi pojawiły się już w jego profilu ich siła zostaje zwiększona.

Teraz czas na analizę informacji posiadanych o preferencjach, oczywistym jest że tagi z największą siłą są najbardziej lubiane przez danego gościa więc trzeba znaleźć wszystkie wpisy zawierające je i porównać ich siłę – w końcu wpis może posiadać kilka tagów więc tutaj przyjdzie z pomocą jakiś bardziej zaawansowany algorytm porównawczy (następnym razem o nim), teraz wypadało by tylko nie podawać artykułów już przeczytanych przez użytkownika, w końcu nie chcemy podsuwać komuś artykułu który właśnie czyta!

Dokładny doradca

Tutaj skupię się tylko na elementach które wzbogacą nasz leniwy system. Pierwszym takim elementem są kategorie, precyzyjność ich jest za razem plusem jak i minusem w takiej aplikacji, z jednej strony jasno mówią co takiego czyta użytkownik, ale i ograniczają nas tylko do jednej kategorii – jest to element pośredni tak na prawdę pomiędzy naszym leniwym a dokładnym pomagierem.

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

Zwiń
Czytaj na blogu autora...