Этот текст — перевод репозитория viraptor. Вы можете предложить свои вопросы на английском, в оригинальном репозитории, или на русском — в моём форке, а я постараюсь перевести их и передать автору

Обратное собеседование

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

Если вы задавали вопросы, которых нет в этом списке, отправьте пожалуйста пулл-реквест!

За последний год я очень много говорил о Symfony 3.0 на разных конференциях. Я думал о наилучшей стратегии для этой версии уже давно, и теперь настало время поделиться моими мыслями со всеми.

Мажорные версии

Некоторые разработчики и большинство менеджеров проектов боятся обновлений мажорных версий используемых ими проектов с открытым исходным кодом. Наверное, это из-за того, что мажорные версии ассоциируются с потерей обратной совместимости. Возникает много вопросов: принесут ли изменения пользу моему проекту? Достаточно ли ясны планы разработчиков, чтобы был смысл обновляться? Будет ли обновление легким? Что, если я не могу или не хочу обновляться? И так далее.

Страх перед мажорными версиями растет своими корнями из нашего прошлого: вспомните Perl 6 или PHP 6. В мире Symfony вторая версия тоже была революционной по сравнению с symfony 1. Я понимаю, почему люди нервничают, когда слышат о третьей версии, и именно в этом посте я расскажу, почему вам не нужно паниковать.

Спасибо! И позвольте, я объяснюсь.

В первую очередь, спасибо всем, кто прочитал предыдущие части. Много интересных комментариев написали, и я понял, что должен объяснить, зачем я, собственно, всё это пишу? Зачем мне вообще нужно отделять контроллеры от фреймворка? Скорее всего, об этом не придется думать, потому что

Шансы, что контроллеры придется переносить на другой фреймворк, близки к нулю. (Рафаэль Домс)

В предыдущей части этой серии мы понизили связанность симфонийского контроллера и фреймворка, удалив зависимость от базового класса контроллера из FrameworkBundle. А в этой части мы избавимся от некоторых неявных зависимостей, которые появляются из-за аннотаций.

Обычно считается, что контроллеры — наиболее связанные классы в приложении. Как правило, на основании данных запроса они получают или сохраняют данные в базу данных, затем превращают данные или результат сохранения в HTML, который выступает в качестве ответа клиенту, который произвел запрос.

Получается, что контроллеры — повсюду, они соединяют те части приложения, которые обычно достаточно независимы друг от друга. Это сильно повышает связанность контроллеров: среди их зависимостей есть менеджер сущностей Doctrine, шаблонизатор Twig, базовый контроллер из FrameworkBundle, и прочее.

В этой записи я покажу, что этот уровень связанности совершенно не нужен. Я покажу вам, как значительно понизить связанность, предприняв всего несколько простых шагов. В результате мы получим контроллер, который можно будет повторно использовать в разных типах приложений, например, на базе Silex или даже Drupal.

Не Wave'ом единым живет нынче Гугл. В ЖЖ-сообществе ru_infodesign проскочила ссылка на новый сервис от Google Labs — Fusion Tables. Это весьма красивое средство визуализации практически любых табличных данных.
Суть сервиса проста: берется какая-нибудь статистическая таблица (чем больше данных — тем интереснее), и данные из нее визуализируются одним из предлагаемых способов.
Возможны самые разнообразные способы отображения; в случае, если данные содержат географическую информацию, можно отобразить их на карте с цветовым кодированием, если есть временная информация — можно отображать ее графически.
Еще можно собирать воедино данные из нескольких таблиц сразу и отображать их на одном графике. И, разумеется, как и в любых других офисных сервисах от Гугла, можно работать над таблицами коллективно.
К сожалению, текущая версия весьма сырая. Сейчас это еще даже не альфа-версия. Видно, что интерфейс местами недоработан, и вообще сориентироваться во всем этом нагромождении достаточно трудно. Но, будем надеяться, достаточно скоро продукт дойдет до беты.

Я думаю, большинство хабралюдей должно быть знакомо с такой вещью, как майндмэпы, они же карты разума, они же диаграммы связей. Для тех, кто не в курсе, поясню: майндмэп — это иерархическая диаграмма, отображающая множество взаимосвязанных мыслей.

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

Попробуем сделать при помощи Flex простое приложение. Впрочем, это не будет обычный Hello World, это будет нечто более полезное.
Но перед тем, как попробовать сделать что-нибудь с помощью Flex, разберемся, какие возможности появились в новой версии.

В этот раз разберемся с отправкой данных на сервер при помощи Dojo. Конечно, достаточно легко получать с сервера статические данные, но в реальной жизни это вряд ли пригодится, так что теперь мы будем не просто запрашивать данные, но и отправлять кое-какую информацию на сервер для обработки. Теперь нам понадобится работающий сервер с PHP, ASP, ColdFusion или Java.

Это мой первый хабрапост, посему прошу критиковать конструктивно.
Цель этого урока — дать отправную точку для тех, кто раньше не сталкивался с Dojo. Мы разберемся с настройкой и подключением Dojo, а также напишем небольшой пример AJAX-взаимодействия средствами Dojo.