Wojciech Sznapka Web Technologies

Moja prezentacja o Symfony2 i dedykowanym oprogramowaniu z InternetBeta 2011

2011-09-15

Poniżej slajdy z mojej prezentacji, którą wygłosiłem na InternetBeta 2011 w Rzeszowie. Zapraszam do zapoznania się z slajdami.

Łebski Development czyli kiedy i dlaczego tworzyć oprogramowanie pod klucz i dlaczego framework Symfony2 pasuje tu jak ulał?

View more presentations from Wojciech Sznapka

Prezentacja o Symfony2 i oprogramowaniu dedykowanym na InternetBeta 2011 w Rzeszowie

2011-09-12

W czwartek 15 września 2011 o 14:30 będę miał przyjemność prowadzić prelekcję na Sesji Technologicznej InternetBeta 2011 w Rzeszowie. Mój temat to Łebski Development czyli kiedy i dlaczego tworzyć oprogramowanie pod klucz i dlaczego framework Symfony2 pasuje tu jak ulał? A poniżej krótka agenda:

– oprogramowanie dedykowane vs. produkty Open Source gotowe do użycia – w którym momencie te drugie przestają być wystarczające,

– jaką wartością jest indywidualne podejście do zagadnienia i gdzie każdy z udziałowców projektu otrzymuje największe korzyści,

– po co komu framework, skoro można wszystko samemu napisać najlepiej?

– Symfony2, jego historia, możliwości i usytuowanie na rynku,

– przykłady z życia codziennego, jak PHP i Symfony2 zwinnie daje radę w przeróżnych dziedzinach software developmentu.

Wszystkich zainteresowanych tematem serdecznie zapraszam 🙂

Symfony2 stable is available, what’s the big deal?

2011-08-07

On July 28th Symfony2 was finally released, with launch parties all over the world. Developers are excited, managers are excited and whole ecosystem is happy. They’re right, there are plenty of reasons to be optimistic. symfony 1.x is a great framework, I made many projects with it, nevertheless Symfony2 is a new way of doing things in PHP. I observe, that applications made with symfony 1 tends to be messy with raising number of functionalities. There too many magic tricks, which you can use, which are hard to manage in big, multi-team projects. Symfony2 does it smarter.

RESTful Symfony2

2011-08-01

Zapraszam do zapoznania się z moją prezentacją pt. RESTful Symfony2, którą można obejrzeć na xlabie http://xlab.pl/2011/08/restful-symfony2/

Fully isolated tests in Symfony2

2011-06-14

The most important thing you should provide with your re-usable bundles is unit tests set. Lately I solved two major cases which Symfony2 hasn’t got out of the box: testing services, defined in Dependency Injection Container and running model tests with fixtures in fully isolated environment.

Symfony sfWidgetFormSelect with disabled options

2010-05-13

The sfWidgetFormSelect doesn’t provide ability to render disabled options. It’s rarely used feature of a HTML select element, but sometimes it could save your life 🙂 In fact, we can achieve this feature by creating our own widget, like one listed below, which inherits from sfWidgetFormSelect. This solution is inspired by problem posted on Symfony Experts.

Symfony Mixins – how to extend symfony core classes without inheritance

2010-02-02

Symfony is very powerful PHP framework, one of the most popular in the PHP world. In big projects you should probably noticed, that there isn’t easy way to extend core classes, which aren’t returned by factories, for example actions classes. Every generated module has actions.class.php, which inherits from sfActions. What, if we want to have same method in few actions, let’s call it getCurrentDay to achieve effect listed bellow?

class defaultActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $year = $request->getParameter('year', date('Y'));
    $this->day   = $this->getCurrentDay($year);
    $this->month = $this->getCurrentMonth($year);
  }
}

Current day is <strong>Monday 2010</strong>
The month is <strong>February</strong>

Which convention is more common „static public function” or „public static function” (based on Symfony and Doctrine)

2010-01-25

Few minutes ago Brent Shaffer asked on the Twitter

Which is more standard, „public static function” or „static public function”?

I was curious about it, so I’ve checked which convention is used in my favourite Symfony Project. Of course, I haven’t got enough time to check it manually, class by class, so I wrote simple bash script:

egrep "^[^\*/]*static.*function" /usr/share/php/symfony/ -rioh --include=*.php | sed 's/^\s*//g' | sort | uniq  -c | sort -r

The answer for the Symfony 1.2 was:

685 public static function
181 static public function
27 static protected function
16 protected static function
16 private static function
11 static function
2 abstract public static function

I’ve done same thing for Doctrine ORM Project

egrep "^[^\*/]*static.*function" /usr/share/php/Doctrine/lib/ -rioh --include=*.php | sed 's/^\s*//g' | sort | uniq  -c | sort -r

and the result was:

78 public static function
6 static public function
6 static protected function

Now I can tell that „public static function” is more common, and by the way I use same convention in my classes 🙂

Cross-application partial w symfony

2009-10-28

Ostatnio zetknąłem się z problemem wspólnych partiali dla wszystkich aplikacji w projekcie Symfony (dokładnie frontend i backend). Dokładniej, to te partiale były templatkami mailowymi, wysyłanymi zarówno przy zdarzeniach wygenerowanych w frontendzie jak i w panelu administracyjnym. Jako, że ponad wszystko cenię zasadę DRY (Don’t Repeat Yourself, czyli Nie Powtarzaj Się), chciałem, aby moje templatki były napisane raz, a używane z każdego miejsca w projekcie. Pewnym rozwiązaniem byłoby zrobienie symlinka: apps/frontend/modules/mails -> apps/backend/modules/mails i to działa, ale nie jest zbyt eleganckie. Z pomocą przyszła analiza kodu Symfony (dzięki Bogu, że jest Open Source:-)).

Import użytkowników z hasłami w md5 do sfDoctrineGuardPlugin

2009-02-27

Import użytkowników z zewnętrznej tabeli do pluginu sfDoctrineGuardPlugin dla Symofny, nie jest taki prosty na jaki wygląda na pierwszy rzut oka. Wydawałoby się, że wystarczy w pętli tworzyć obiekt klassy sfGuardUSer, ustawiać username i password dla niego oraz wywoływać metodę save(). Nic bardziej mylnego. SfDoctrineGuardPlugin do przechowywania haseł używa hasha tworzonego na podstawie soli (salt), dzięki temu zwiększa się bezpieczeństwo. Dodatkowo domyślnie używanym algorytmem jest sha1, a nie popularny md5, stosowany z zapałem przez wielu programistów PHP. Cały problem polega na tym, że plugin przy tworzeniu nowego obiektu, generuje sól (chyba, że podamy własną) i nie przyjmuje do informacji, że ustaliliśmy jej wartość NULL. Małym pocieszeniem jest fakt, że możemy własnoręcznie ustawić dla rekordu algorithm na md5, ale mimo wszystko po ustawieniu hasha do atrybutu password, zostanie on połączony z solą i ponownie zahashowany, co rozwali wszystkie nasze hasła.

Aby temu zapobiec, należy stworzyć klasę ImportsfGuardUser i umieścić ją w lib/ (nie zapomnij wyczyścić cache symfony):