Why I stopped worrying and LOVED PHP | Codesushi

May 12, 20170 likes87 views

Krzysztof (Chris) Ozog

INFOMeet Cracow - Codesushi CTO Chris Ozog

Why I stopped
worrying and
LOVED PHP
Chris Ozog - Codesushi CTO

Agenda:
1. 2 słowa o sobie
2. Dlaczego php ma złą sławę, czyli szczypta historii
3. PHP 5.3 i narodziny Symfony
4. Nowoczesny PHP na przykładzie Symfony
5. Dlaczego warto zainwestować swój czas w PHP

2 słowa o mnieW kontekście historii PHP
● Pierwsza aplikacja w PHP - 2004
● Nie chciałem zostać “PeHaPowcem”
● Ale tak wyszło …
● W międzyczasie PHP bardzo się zmienił
● Oprócz powyższego: Codesushi CTO

Dlaczego php ma złą sławę, czyli szczypta historii:
Dziki zachód (1995 ~ 2006)
● Pierwsze wydanie PHP - 1995
● Era spaghetti code
○ Brak stosowania wzorców projektowych
○ Brak oddzielenia HTML od kodu PHP
○ Większe nastawienie na to aby coś działało niż
na jakość kodu
● Spaghetti przestaje smakować - pojawia się Ruby on Rails (2004)
○ Wszyscy chcą być jak RoR - pojawia się CakePHP i Django (python)
● Pojawia sie Symfony 1. Październik 2005

Dlaczego php ma złą sławę, czyli szczypta historii:
Odważny nowy świat (2006 ~ 2011)
● Pierwsze wydanie Symfony 1. 22.10.2005
● Wojna frameworków
○ CakePHP, CodeIgniter, Symfony, ZendFramework
● Problem! Brak możliwości współdzielenia kodu pomiędzy
frameworkami
● PHP 5 - zaczyna wyczerpywać swoje możliwości
○ Długie nazwy klas, aby symulować przestrzenie nazw
● 2009 - pojawia się PHP 5.3 i standardy PSR
● Wydanie Symfony 2, Lipiec 2011

PHP 5.3 - przełomowe wydanie PHP
● 2009 - 1 wydanie PHP 5.3
● Wprowadzało przestrzenie nazw
● Poprawiło wydajność
● Funkcje anonimowe
● Domknięcia
● Poprawiało obiektowość
● Umożliwiło powstanie nowych frameworków
takich jak Symfony 2

Narodziny Symfony
● Lipiec 2011 - pierwsze wydanie
● Wdrożenie standardów PSR-0,1,2
● Odejście od koncepcji RAD - przewrót w podejściu
● System szablonów Twig
● Koncepcja Bunldes
● Koncepcja Components
● Postawienie na wzorzec Dependency Injection i
Oddzielenie zależności
● Od wersji 2.1 - przejście na composer w celu
zarządzania zależnościami
● Dystrybucje symfony - (RAD, CMF, REST)

Nowoczesny PHP na przykładzie Symfony
● Oddzielenie zależności - Decoupling
● Dependency Injection
● Clean code
● SOLID Code

Dlaczego warto zainwestować
swój czas w PHP
● PHP 7
● Nadal jest królem webu
● Wpływ symfony w całym ekosystemie
● To przyzwoity język

Dziękuję za uwagę :)
e-mail: hello@codesushi.co
www: codesushi.coKrzysztof Ożóg
Codesushi CTO

Symfony 4 wprowadza nowy domyślny sposób budowania aplikacji - Symfony Flex. System będzie mocno zintegrowany z composerem, a także zaoszczędzi czas pracy dzięki zautomatyzowaniu powtarzalnych zadań, takich jak wprowadzanie konfiguracji. Dodatkowo ułatwi wybór nowych bibliotek do konkretnych potrzeb dzięki udostępnieniu dwóch repozytoriów zawierających najlepsze z perspektywy twórców bundle dla danego celu. Począwszy od wersji 3.3 Symfony zezwala na użytkowanie Symfony Flex w wersji beta. Zbadamy jego działanie “pod maską” by w pełni wykorzystać potencjał tego narzędzia. Prezentacja była częścią prelekcji na PHPers Summit 2017.

Ruby, Ruby on Rails 2010Natalia Stanko

Clean code w RubyRafal Piekarski

Łebski Development czyli kiedy i dlaczego tworzyć oprogramowanie pod klucz i ...Wojciech Sznapka

- 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.

Webinar symfonyMichał Makaruk

Nie tylko C# - Ekosystem Microsoft dla programistówintive

Jak migrować kod legacy do Symfony? Tips & tricksXSolve

Code Camp NYC 2017 - How to deal with everything... | Chris Ozog - Codesushi Krzysztof (Chris) Ozog

The document discusses addressing challenges with legacy codebases, focusing on the developer mindset often characterized by laziness, impatience, and hubris. It provides strategies for overcoming issues presented by various forms of legacy code, including well-written older code, poorly maintained code, and single file applications. The emphasis is on understanding the legacy systems, improving code quality, and fostering a collaborative, humble approach to problem-solving.

21st century problem… the cost of it department!Krzysztof (Chris) Ozog

The document discusses the challenges of IT department costs in the 21st century, highlighting the optimization of these costs through automation and various software solutions. It contrasts white collar and blue collar perspectives on software costs, advocating for a deeper analysis of costs at a feature level. The author suggests that understanding the activities involved in feature creation can provide insights that improve cost management and efficiency.

Codesushi: Code review z korzyściami dla recenzenta i recenzowanego Krzysztof (Chris) Ozog

Why I stopped worrying and loved PHP | Codesushi - Krakow 2017Krzysztof (Chris) Ozog

1. The presenter will discuss the history and modern state of PHP, using Symfony as an example. PHP originated in 1995 but had poor code quality until frameworks like Symfony emerged. 2. PHP 5.3 in 2009 introduced important features like namespaces and anonymous functions that allowed new frameworks like Symfony 2 to implement best practices. Symfony focuses on concepts like dependency injection, decoupling, and clean code. 3. PHP and Symfony have matured significantly. PHP 7 and Symfony's influence have made PHP a viable choice for web development, despite its reputation in earlier eras of "spaghetti code". The presenter argues it is worth

Parallel development of Web Apps | Codesushi - Gliwice 2017Krzysztof (Chris) Ozog

This document discusses parallel development approaches for web apps. A standard approach involves implementing endpoints sequentially after defining user stories. A parallel approach involves frontend and backend determining endpoints together upfront. They then use tools like Apiary, Symfony, or Json-server to create mock APIs so frontend and backend can work simultaneously. This allows attacking on multiple fronts and creates less blocking, enabling developers to build a minimum viable product faster. The document provides examples of when different tools are useful and concludes with a case study where using parallel development delivered a new product in 3 months versus 12 months previously.

How to create a WordPress not understanding WordPress, so more on the headles...Krzysztof (Chris) Ozog

This document discusses the headless approach to WordPress development. It begins with introductions and then outlines the agenda which includes: defining the headless approach, advantages like using any frontend technology, disadvantages like losing some WordPress capabilities, and a step-by-step process including installing WordPress configured for headless and building a PHP frontend app. The document promotes the headless approach as allowing WordPress to act as just a content management system with any technology used on the frontend, communicating via API.

Asynchronous PHP | Codesushi - Warsaw 2017Krzysztof (Chris) Ozog

The automation of the process of caring for the quality of the code in PHP an...Krzysztof (Chris) Ozog

This document discusses tools for automating code quality checks in PHP and JavaScript. It begins with an overview of the history of code quality, from unstructured "spaghetti code" to standardized practices. It then covers generally accepted practices like DRY principles. The document outlines PHP standards like PSR-0/4 and tools like PHP CodeSniffer and PHP Mess Detector. Similar JavaScript standards and tools are covered, including JSLint, JsHint, and ESLint. It emphasizes integrating these tools with editors and continuous integration systems to automatically enforce code quality standards.

How to protect your code against a destructive influence of client | Codesush...Krzysztof (Chris) Ozog

The document discusses how to protect code from a destructive client influence. It recommends (1) correctly communicating with the client and planning for refactoring time, (2) introducing rules like SOLID for code creation, and (3) performing code reviews by outsiders and using PHP tools like Mess Detector and Code Sniffer. The goal is to maintain responsibility for the code quality and prevent a good start from leading to a bad finish due to changes.

Migration from drupal 7 to drupal 8Krzysztof (Chris) Ozog

The document discusses the migration process from Drupal 7 to Drupal 8 using Docker and Docker Compose, detailing the speaker's background and the advantages of using Docker for development and testing environments. It outlines the setup, including Dockerfiles for both Drupal versions and how to orchestrate multi-container environments with Docker Compose. The speaker highlights the ease of managing separate PHP versions and performing complex setups with Docker, emphasizing the successful integration of Drupal with Docker technology.

Headless approach and acquia - case study | CodesushiKrzysztof (Chris) Ozog

Asynchroniczny PHP | CodesushiKrzysztof (Chris) Ozog

Równoległy rozwój Aplikacji Webowych | CodesushiKrzysztof (Chris) Ozog

Jak uchronić Twój piękny kod przed destrukcyjnym wpływem klienta | CodesushiKrzysztof (Chris) Ozog

Inner Symfony’s DaemonsKrzysztof (Chris) Ozog

This document discusses daemons and how to create them in PHP and Symfony. It begins with some background about the speaker and defines what a daemon is. It then outlines that daemons are useful for processes that run more frequently than every minute, like websockets or socket protocols. Typically daemons are created by forking processes or using OS tools like upstart scripts. The document demonstrates creating a simple looping daemon in PHP and discusses its issues, and then shows how to properly create daemons using forking or upstart scripts. It also introduces a Symfony bundle that provides an interface for creating daemonized console commands. In the end it notes some things to consider for long-running daemon

Speed up your zombies! - Bootstrap dev environment in 5 minutes!Krzysztof (Chris) Ozog

This document summarizes and compares several online development environments: Nitrous, Codio, Koding, and Cloud9. It finds that Nitrous is the best fit overall as it allows users to create and share cloud virtual machines while also using local tools through the Atom text editor plugin, and provides templates for common languages and frameworks. While the others have advantages like configuration sharing for Koding or being designed for teaching for Codio, they lack the ability to use local tools like Nitrous or share built machines like Koding.

Why I stopped worrying and LOVED PHP | Codesushi

1. Why I stopped worrying and LOVED PHP Chris Ozog - Codesushi CTO

2. Agenda: 1. 2 słowa o sobie 2. Dlaczego php ma złą sławę, czyli szczypta historii 3. PHP 5.3 i narodziny Symfony 4. Nowoczesny PHP na przykładzie Symfony 5. Dlaczego warto zainwestować swój czas w PHP

3. 2 słowa o mnieW kontekście historii PHP ● Pierwsza aplikacja w PHP - 2004 ● Nie chciałem zostać “PeHaPowcem” ● Ale tak wyszło … ● W międzyczasie PHP bardzo się zmienił ● Oprócz powyższego: Codesushi CTO

4. Dlaczego php ma złą sławę, czyli szczypta historii: Dziki zachód (1995 ~ 2006) ● Pierwsze wydanie PHP - 1995 ● Era spaghetti code ○ Brak stosowania wzorców projektowych ○ Brak oddzielenia HTML od kodu PHP ○ Większe nastawienie na to aby coś działało niż na jakość kodu ● Spaghetti przestaje smakować - pojawia się Ruby on Rails (2004) ○ Wszyscy chcą być jak RoR - pojawia się CakePHP i Django (python) ● Pojawia sie Symfony 1. Październik 2005

5. Dlaczego php ma złą sławę, czyli szczypta historii: Odważny nowy świat (2006 ~ 2011) ● Pierwsze wydanie Symfony 1. 22.10.2005 ● Wojna frameworków ○ CakePHP, CodeIgniter, Symfony, ZendFramework ● Problem! Brak możliwości współdzielenia kodu pomiędzy frameworkami ● PHP 5 - zaczyna wyczerpywać swoje możliwości ○ Długie nazwy klas, aby symulować przestrzenie nazw ● 2009 - pojawia się PHP 5.3 i standardy PSR ● Wydanie Symfony 2, Lipiec 2011

6. PHP 5.3 - przełomowe wydanie PHP ● 2009 - 1 wydanie PHP 5.3 ● Wprowadzało przestrzenie nazw ● Poprawiło wydajność ● Funkcje anonimowe ● Domknięcia ● Poprawiało obiektowość ● Umożliwiło powstanie nowych frameworków takich jak Symfony 2

7. Narodziny Symfony ● Lipiec 2011 - pierwsze wydanie ● Wdrożenie standardów PSR-0,1,2 ● Odejście od koncepcji RAD - przewrót w podejściu ● System szablonów Twig ● Koncepcja Bunldes ● Koncepcja Components ● Postawienie na wzorzec Dependency Injection i Oddzielenie zależności ● Od wersji 2.1 - przejście na composer w celu zarządzania zależnościami ● Dystrybucje symfony - (RAD, CMF, REST)

8. Nowoczesny PHP na przykładzie Symfony ● Oddzielenie zależności - Decoupling ● Dependency Injection ● Clean code ● SOLID Code

9. Dlaczego warto zainwestować swój czas w PHP ● PHP 7 ● Nadal jest królem webu ● Wpływ symfony w całym ekosystemie ● To przyzwoity język

10. Dziękuję za uwagę :) e-mail: [email protected] www: codesushi.coKrzysztof Ożóg Codesushi CTO

Why I stopped worrying and LOVED PHP | Codesushi

Recommended

More Related Content

More from Krzysztof (Chris) Ozog (16)

Why I stopped worrying and LOVED PHP | Codesushi