canonical

Мы ожидали увидеть приложение с использованием готовых библиотек для работы с HTTP, базой данных, работы с консолью. А также легко расширяемое и поддерживаемое.

Теперь понятно, что они хотят — но в ТЗ не было указано:

• Под HTTP понимают либы, работающие с PSR 7 или близкие по «духу», например Symfony HTTP Foundation
  
• Под БД понимают Doctrine 2 или Eloquent
  
• По консольным — на рынкке используют как правило Symfony Console
  

Именно это и хотели, предлагаю вам либо объяснить и написать уже на компонентах, либо послать к черту, НО отметить этот момент и на будущее таки делать уточнение, каковы ожидания от задания...
Нескольких людей встречал до фанатизма не принимающих сторонние пакеты, и наоборот... Это нужно учитывать... видел задания на PHP 5.3, видел задания строго на Codeigniter...

Тут на Тостере был пример, когда человек применил композер даже не для сторонней либы, а для внутренних, так на него тимлид сокрушился...
Разве Composer бесполезен в 2017?

Люди разные :)


Материал по компонентной разработке

Елена,
не нужно Symfony ассоциировать с фреймворком — это в первую очередь компоненты — потрясающие компоненты:

• Symfony Console
  
• Symfony HTTP Foundation
  
• Syfony Routing (к слову очень быстрый, недавно ускорили его в 70 раз ребята и сделали самым шустрым компонентом)
  
• Twig
  
• Debug
  

[*!*] В некоторых вакансиях даже указывают, что нужно уметь работать с некоторыми выше перечисленными компонентами :) Пруф: https://novosibirsk.hh.ru/vacancy/25367906

Doctrine — совсем не из Symfony и этот компонент можно использовать где угодно

Zend к слову пошел по тому же пути, например

• для HTTP Request/Response PSR 7 у него есть отличный компонент Zend Diactoros,
  
• для работы с PSR 15 Middleware есть компонент Zend Expressive,
  
• для работы с ролями и правами крутое решение Zend ACL
  

Laravel уже да — фреймворк, и опять же на компонентах, и можно использовать его куски, например у него замечательная ORM (Active Record) — в отличие от AR в Yii2 ее можно (и нужно) использовать в любом кастомном проекте вне фреймворка Laravel или вообще фреймворка там , где Доктрина лишняя


Почитать и посмотреть:

Современный PHP без фреймворков (статья Mail.ru на Хабре)
Консольное приложение (мастер-класс) — собрано из компонента Symfony Console и ORM Eloquent (от Ларавел)
PSR-7 фреймворк от Д.Елисеева

> С какими общими понятиями нужно ознакомится?

То что вы описываете конечно хорошо и полезно, но недостаточно для того чтобы начать писать софт качественно. Причем речь не про "выучить еще немного функий", а про фундаментальные вещи. Понятия которые нужно знать в обязательном порядке (очень выборочно):

1. Автоматизированное тестирование.
1. Автоматное программирование.
1. DDD.
1. Функциональное программирование (функции высшего порядка, библиотеки типа https://github.com/tightenco/collect)

Мастхев книги: https://ru.hexlet.io/pages/recommended-books
Немного умных слов: https://docs.google.com/spreadsheets/d/e/2PACX-1vS...

Исключение - это отклонение от нормы. Оно всегда будет. Всего не предусмотреть. Вы можете сделать исключения для Unprocessable, Forbidden, NotFound.
Написать обработчик, который ловит все необработанные исключения и конвертирует Unprocessable в HTTP 422, Forbidden в HTTP 403, Not Found в HTTP 404, а все остальное в HTTP 500.

О проблемах с сетью клиента уведомлять не надо. Таких технических проблем могут быть сотни и тысячи. Когда они возникнут, ваше приложение итак по очевидным причинам не сможет обработать запрос и упадет с исключением/ошибкой. Вам лишь надо, чтобы исключение/ошибка провалилась в обработчик и превратилась в 500 Internal Server Error. О большем клиенту знать не зачем.

Качай навык обмана и изворотливости! Когда ты один, то дается бонус +5 к начальному навыку вранья, +3 к изворотливости, а так же призрачный посох просраного дедлайна одинокого разработчика. Посох кастует заклинание: "Немного осталось, скорее всего уже завтра!", а так же дает временный иммунитет от увольнения, пока ты один, без союзников.

Больше 10 лет работаю под Битриксом. Мне очень нравится то, что в этой работе нужен целый стек знаний. Начиная от настройки апача и нжинкса (у меня свой сервер на Хетцнере) и до вёрстки. Прям прёт от кайфа.

Этот год начал вникать в новое ядро (а там уже ORM), начал восполнять недостаток знаний. Ниточка за ниточкой... — просмотрев видео-курс по Ларавел понял, что моё мировоззрение дало трещину. Насколько там всё строго и по полочкам, в противовес анархии внутри Битрикса. Но у битрикса шикарное лицо. CMS прокачана так, что удобно как заказчику, так и обслуживающей команде. Вряд ли какая CMS сможет угнаться. Но внутренности... Мама дорогая. Хочется скрестить Ларавел и Битрикс (CMS).

Есть надежда, что новое ядро привнесёт какую-то строгость, но, увы, Битриксы не культивируют "эко-культуру". То есть тренда быть стильным, правильным, структурным — нет. Порог входа опущен настолько, что можешь писать лапшой, можешь прикручивать свои шаблонизаторы. Вообще твори что хочешь. Битрикс ограничивается необязательными рекомендациями.

Ища выход стремлению "хочу большего" завёл профиль на апворке и логично задумался: а что я могу предложить? То есть сначала была шальная мысль выходить на full-stack заказы c Битриксом, но, блин, после Ларавелл я уже не уверен. Если переходить (менять тех заказчиков, которые уже есть), то на солидный уровень (по задачам, в первую очередь). А для этого нужно понимание: к чему душа лежит (выбор технологии) и что востребовано (однозначно могу сказать, что буду копать Ларавел — уже и мини-проекты придумал; из фронт-энда буду пробовать пилить Вью, но пока что нет жёсткой мотивации: чистый css/js никто не отменял). А значит метод проб и ошибок. Пока не определился — держать ушки на макушке и анализировать входящий поток, не особо отвлекаясь от текущих дел, потому что так можно и загнуться (а на плечах семья, дети).

Пытаясь понять, «как оно», — запустил и небольшой оффлайн бизнес с продажей через Интернет. Есть опыт запуска своих проектов и этот путь мне кажется наиболее перспективным для удовлетворения жизнью: сразу делаешь то, что легко согласовывать (с самим собой =), за ошибки платишь сам, можно делать неспеша (некоторые решения должны вызреть внутри), а можно упасть и прям не вставать пока не закончил — делаешь-то для себя, а это совсем другой настрой.

Но чем хорошо (полезно) по-фрилансивать: остаёшься в курсе новинок, не оседаешь в своей тине и не разучиваешься шевелиться. По сабджу — держать нос по ветру, пробовать разные задачки, пока не придёт чёткое понимание.

Почитайте-ка историю Алексея Ситникова

И лично от себя... Просто примите как данность - в жизни ВОЗМОЖНО ВСЁ!
Что бы вы не планировали, какие бы цели не ставили, в какой бы ситуации не находились, как бы не комплексовали и какие-бы страхи вас не одолевали, ВСЕГДА найдется не один человек, который в схожих, либо худших, стартовых условиях добился того, о чем грезите и вы.

Потому что в ноде до сих пор нет хоть каких-то общепринятых стандартов как PSR в PHP (или даже PEAR). И этого не будет при текущем бурном развитии самого языка. В PHP хоть и меняется синтаксис между версиями, но не так значительно, чтобы прибегать к таким монстрам как babel.

Большой фреймворк подразумевает каноничность и концентрацию лучших практик в себе, которые затрагивают не только обработку роутинга и ответы (как во микрофреймворке а-ля express), а работу с базой, логирование, шаблонизацию, сообщения и все-все-все остальное в едином стиле, продуманной архитектурой на пару лет вперед и желательно от одной сплоченной группы авторов.

Когда появятся стандарты то им будут следовать все фундаментальные инструменты, например как composer+PSR4 (autoload).

Как можно выработать общие железобетонные принципы и написать что-то большое, когда буквально раз в год все становится с ног на голову и выходит очередной ES-стандарт, а популярные библиотеки могут легко сломать обратную совместимость? =) Уж не говоря про чехарду технологий.

Думаю обязательно появятся, как только там наверху авторы "угомонятся" и разработчики смогут спокойно кодить, а не подгонять полдня версии пакетов.

Бросайте паттерны. На вашем этапе обучения они пока не нужны. Изучайте принципы (SOLID, GRASP). Учитесь писать тесты, пробуйте TDD/ATDD. И тогда паттерны будут образовываться сами собой.

Паттерны придумали не для того что бы ими проектировать, они нужны что бы называть ваши решения. Это просто словарь терминов что бы меньше времени приходилось тратить объясняя то или иное техническое решение. Но сначала код а потом паттерны, а не наоборот.

Чтобы получать много заказов нужно много работать и работать очень хорошо, сроки, качество, общение с клиентом должно быть на высоком уровне.
Так на любой нормальный фрилансе бирже

Не будет смены специальности без потерь. К потерям надо готовиться. Семье надо объяснить причину смены специальности. Потери будут либо в деньгах, либо в свободном времени.

В свободное (очевидно, внерабочее) время читать, смотреть, думать и делать pet projects - в этом я не оригинален. Иллюзий по поводу программирования питать не надо. У многих разработчиков 12-14 часой рабочий день, особенно у фрилансеров: 4-6 часов покодить + время на поиск новых заказов + время на общение с старыми/новыми клиентами + время на организационную деятельность + время на маркетинг самого себя. Офисные программисты работают несколько свободнее по времени, но уверен, что многие после работы ещё вштыривают проектик для себя или шабашат по мелким заказам.

Хочу озвучить ещё четыре варианта.

1. Мне известны уже несколько случаев, когда человек уходил на сдельную работу или на 1/4 ставки или на почасовку на основном месте работы и увеличивал количество часов на изучение второй специальности. Или устраивался на новое место на почасовку или на четверть ставки для стажировки, а то и на должность джуна. Сам так делал. Очень эффективно.

2. Выходные, праздники и отпуск не для ремонта или отдыха, а для ускоренной реализации своих проектов. Я кучу людей знаю, которые работают без отпуска, включая махинации с увольнением/восстановлением, чтобы просто получить компенсацию и работать дальше. Не вижу ничего сложного в том, чтобы отпуск потратить на стажировку или самообразование. Если новая работа приносит удовольствие, то можно развернуть свои собственные мысли так, чтобы новая работа считалась отдыхом (самомотивация, аутотренинг, самогипноз - называйте как хотите). Не замечали, что 8 часов нелюбимой работы тянутся долго-долго, а 8 часов любимого занятия (хобби, увлечение) пролетают незаметно?

3. Административный отпуск. Он, конечно, не оплачивается, но если подвернулось интересное дело, то можно попробовать, потрогать, пощупать, оценить свои ощущения и если не уверен - вернуться в своё уютное тёплое гнёздышко на старом месте работы. Административный отпуск хорош тем, что его можно устроить в любое время без согласования отпускных графиков и отказать в нём не могут. Так что сразу, как подвернётся интересное дело - можно с головой нырнуть, устроить себе интенсивное погружение.

4. Попробовать совмещать должности на старом месте работы. Попросить руководителя дать несложную работу из соседнего отдела программистов. Я сам встречал маркетологов-программистов, аналитиков-программистов, менеджеров-программистов. Им просто это интересно. При этом зарплата будет прежняя, а может быть повысится - как договоритесь. Ещё можно уговорить послать на курсы переквалификации, организация оплатит и время и курсы - ничего не потеряешь.

Ещё варианты плавного перехода придумать?

Кто хочет - найдёт 1000 способов, кто не хочет - найдёт 1000 причин (Конфуций)

php.net/manual/en/language.namespaces.basics.php

Статьи на хабре:
Как использовать пространства имен в PHP, Часть 1:...
Как использовать пространства имён в PHP, Часть 2:...
Как использовать пространства имён в PHP, Часть 3:...

Лень фото искать...
Вообще всё лень...
Так вот там, на фото, на рабочем столе свободно только пространство коврика, для мышки (ей нужно активно бегать - геймер ещё тот я).
И перед клавой, там бумажки всякие для набросков, эскизов и так, для заметок.
А по периметру... Одни бутылки пустые из-под тёмного! Какие-то пакеты от чипсов и т.п. ерунды.
Вокруг стола, под столом и на колонках тоже бутылки. (благо монитор не загораживают)
Кодер с начала 2000-х.
Возраст 37 лет.
Рост 175.
Вес 58-63.
Жены нет 7 лет.
Головные боли.
Апатия.
Сплю много и как попало.
Вечно голодный.
Чувство собственной нереализованности в обществе.
Очень похож на... Радиона Расскольникова!
(Уже готов грабить и убивать)
(зря в конце 90-х решил завязать с криминальными перспективами.)
Сейчас бы был с ходкой, с наколками - люди бы уважали!
Имел бы бизнес - "Деньга на дом" или что-то в этом роде.
Короче компьютерные технологии это тупиковая ветвь развития человека.
О чем и мультик Wall•е.

Совет: не пытайтесь найти в книгах актуальной информации. Андроид - постоянно и очень быстро развивающаяся платформа, приемы и концепции сменяются в ней очень быстро. Вы можете взять книгу издания 2015, однако окажется, что в печать она ушла в 2014, а писал ее автор вообще в 2012-2013. А тут даже за год может многое поменяться. Android Studio 1.0 вышла в декабре 2014, как вы думаете, может автор за пол-года изучить все, описать, сдать в издательство и обеспечить актуальность информации?
Плюшки и максимальная оптимизация, это то, чего одной (или даже несколькими) книгами достичь не удастся. Нужно постоянно читать блоги разработчиков и подобные англоязычные ресурсы, чтобы по крупицам собирать информацию. Ни в одном месте нет всего и сразу. Книга может дать только самое общее представление, но для него можно взять практически любую.