Спасибо :)
Теперь у нас бот для Telegram! (https://inmind.tech/)

Поправка, только сейчас увидел, что статья 2015 года, docker тогда еще не так актуален был.

Все нижесказанное чистое ИМХО, не является конечной инстанцией и руководством к действию.
На хабре уже неоднократно появлялись статьи, что нужно знать для Junior, Middle и тому подобное. По-моему личному мнению, это зло. Человек изучит материалы, предоставленные вами, и будет ошибочно считать свой уровень = Middle. Вы уж извините, но ваша подборка материалов больше годится для Junior'ов. Но опять же, зачем спускаться до уровней? Middle должен обладать не набором каких-то конкретных технологий, а отличным пониманием, что, где, как и зачем. Middle уже по первому взгляду должен прикинуть примерное решение:

• «Так, ага, здесь у нас отсылка письма с линком восстановления пароля, сделаем через очередь задач, чтобы фронт не тормозил» => «Можно взять beanstalkd, в прошлом он хорошо себя показал. Однако, я понимаю как можно самому реализовать простейшую очередь задач! К примеру, использовать Redis (=> Redis? Я знаю что redis это in-memory хранилище, с поддержкой перзистентности. Зачем? Например кэширующего слоя перед бд, возможно, выноса части бд в in-memory, для разгрузки медленных запросов. Для кэша есть еще memcached...). Redis single-threaded, поэтому я избегу race-condition при выборке новых задач. Нет Redis'a? Ok, могу сделать очередь поверх обычной таблицы! Использую LOCK FOR UPDATE, или просто обойдусь UPDATE. Я знаю что UPDATE блокирует строку!.. А может просто, потоко-небезопасный код обернуть в мьютекс — PHP Redlock?!»
• «Так, с очередью ясно! Что по поводу отправки_писем? Заинжектю-ка я MailerInterface в логику отправки письма, вместо использования моего класса Mailer, я же знаю про DI, и завтра нам может понадобится другой сервис для отправки писем. Стоп. Мы же хотели в будущем сделать и восстановление паролей по sms? Назову-ка я лучше интерфейс NotificationInterface, сейчас реализую его для e-mail, а в будущем для sms»
• «Нотификацию мы умеем отправлять. Что по поводу самого восстановления? Наверное, нам нужен какой-то секретный токен, который мы отправляем на NotificationInterface::send($notification, $user), а позже верифицируем, и удостоверяемся, что пользователь владеет e-mail/телефоном»
• «С этим ясно, а как хранить токены для восстановления паролей будем? Создадим таблицу confirmation_tokens. Стоп. Готов поклясться, что Я уже делал что-то подобное когда-то на другом проекте, и понял, что секретные токены весьма многообразны в использовании, и подходят так же для: сброса пароля, ссылки — автологина, мерджа аккаунтов! Заведу ка я таблицу secret_tokens, будут методы acquire/verify. Ограничу токены по времени жизни — чтобы исключить перебор. Пока заведу только один тип токенов — TYPE_CONFIRM_EMAIL»
• «С логикой вроде все ясно. Хм! Мы используем платный сервис для отсылки sms, будет нехорошо, если url /send_confirmation может дергатся неограниченное кол-во раз, с разными номерами телефонов. Так один пользователь может отправить и 1000 смс на разные номера! Можно отдавать куки, можно сверять IP. В принципе, я знаю как это сделать! Но постойте, у нас в Laravel есть замечательный throttle middleware! Он как раз призван ограничивать кол-во обращений к url'у, с привязкой к клиенту»
• «Постойте, так у нас тут поле ввода Email проверяется AJAX'ом на существование. Это же уязвимость налицо! Можно построить список email всех пользователей сайта! Добавим ограничение и на урл /check_email!»
• «Так, в форме надо не забыть еще и про CSRF. Да, я знаю что это! Same-origin policy не запрещает отправку кросс-доменных POST запросов, злоумышленник влегкую может использовать нашу сессию для сабмита POST'ов со своего сайта! Проверку CSRF можно реализовать поверх сессий, хранить токен, который сверять потом с прешедшим токеном в скрытом поле POST запроса. Но у нас в Frameworkе же есть готовое решение, {{ csrf_field() }}»

…

Лечге просто преподносить пост, как скопление полезного материала к прочтению.

• Книга по 1ой книге — «Колесниченко», морально устарела. Первую главу — «Выбираем FTP клиент и текстовый редактор». FTP клиент? 2017. Мало того, не рекоммендую книгу данного автора, основываясь на своем и чужом опыте. Как и вообще многие русскоязычные книги. Официальная документация PHP — отличная кладезь знаний.
• Vagrant — Docker
• Выучить на память TOP100-300 функций PHP (1 неделя) — бывали такие вопросы на собеседованиях. Не ответил. Не жалею что не устроился на вакансии. Есть IDE, к чему знать названия? Главное знать что они есть.
• Twitter Bootstrap, Twig — это совсем лишнее. Что там изучать? 5 — 15 минут чтения документации. Можно вообще не писать об этом.
• Совершенный код — бесспорный лидер в подобных топиках. К прочтению обязателен. Однако, дает ли одно прочтение книги способность писать идеальный код? Однозначно нет. Нельзя даже сказать, что навык писать Идеальный код когда-то приходит. Это тот идеал, к которой нужно стремиться, но не делать первопричиной и самоцелью, в ущерб бизнесу. Качество кода несомненно всегда должно расти, лучший способ для этого — практика.

Гораздо более хорошо знать более базовые вещи (как бы банально и знакомо это не звучало), например:
— Английский язык
— Агоритмы/структуры данных
— Устройство Linux-подобных ОС
— Протокол HTTP
— Модель OSI
— И т.д.

Не заэкранировал &quоt, вот правильный код:

$client = Model_Client::find(1);
echo $client->message->text; // '{"text":"hello"}'
echo View::forge('view', $client); // empty view
$client = Model_Client::find(1, array('from_cache' => false));
echo $client->message->text; // '{&quоttext&quot:&quоthello&quоt}'

Откуда такие положительные эмоции от фреймворка? После небольшого знакомства остались только негативные эмоции. Из того что помню:

— Auth::get_user_id(), вполне адекватно названный метод, только возвращает он не user_id как ожидается, а внимание(!), array([0]=>driver_id, [1]=>user_id). Возвращается массив вместо ожидаемого скаляра, ладно, но они что не читали дядюшку Макконнелла, который писал что магические константы — это зло (Хотя бы добавили именованные константы array([Auth::DRIVER_ID]=>driver_id)? Приходится писать Auth::get_user_id()[1]. По всему фреймворку подобных мест уйма.
— Многие «особенности» работы таких компонетов как View, Model, Caching могут создавать дикие лулзы:

$client = Model_Client::find(1);
echo $client->message->text; // '{"text":"hello"}'
echo View::forge('view', $client); // empty view
$client = Model_Client::find(1, array('from_cache' => false));
echo $client->message->text; // '{&quottext&quot:&quothello&quot}'

Что здесь произошло?
1 Мы достали клиента, передали его в пустую вьюху
2 Повторно считываем клиента, принудительно указывая не использовать данные из кэша (для справки, между пунктом 1 и 2, никаких модификаций $client и связанных объектов не происходило)
3 Выводим $client->message->text, и видим что произошла модификация содержимого, при том, что никаких изменений мы не вносили.

Дело в том, что вьюха для всех полей объекта делает safeoutput in-place, то есть меняет на ходу нашу модель(!). Как можно ожидать от вьхи такое поведение? Сохранения после safeoutput'a не происходит, казалось бы при повторном запросе из бд (минуя кэш), мы получаем неизмененный объект, однако, флаг 'from_cache' => false, распространяется только на сам объект, поведения чтения подчиненных объектов изменить нельзя (будут браться из кэша, получим поломанный вьюхой json).

В официальной IRC'e по подву in-pace safeoutput'a идут горячие споры между разработчиками, но воз и ныне там.

Лончер (стандартный либо сторонний) хоть немного тормозит при скроллинге меню/перелистывании домашних экранов? Просто уже пару лет использую CM7 + launcher pro, в работе интерфейса абсолютно никаких подтормаживаний, перед переходом на CM10 хотелось бы узнать как с этим тут обстоят дела.

P.S. Похоже проблема локальна — Бугурусланский район. По отзывам пострадавшей — уже все нормализовалось.

Я с Оренбурга, провайдер — dom.ru, все работает. Спросил у знакомых — с уфанетом и ростелекомом проблем тоже нету. Эти три провайдера, на глаз, покрывают около 80% оренбурга.
Похоже это дело рук какого-нибудь мелкого районного провайдера.

Очень жаль. Являюсь владельцем EeePC 1001PXD, никаких жалоб нету — и винда нормально работает, и линукс.
Планшет, пусть даже дополненный клавиатурой, не сможет полноценно заменить нетбук — ни тебе нормальных IDE, ни больших объемов памяти (~300гб), ни соревнований с одногрупниками в CS 1.6 на тачах…

Никаких. Речь идет про обычные звонилки.

Правда с такими большими возможностями приходила и большая ответственность. К примеру кривой эльф положить в папку Daemons (хотя со временем появилось что-то вроде сэйф мода — при включении надо было нажимать на какую-то кнопку, и загрузка демонов не происходила). Было много шансов запороть телефон (помнится кто-то вместо прошивки в формате bin залил случайно сэйв от игры NFS — хорошо это не закончилось).
Даже новенькие сименсы можно было покалечить просто например установив скин (скины на сименсах — просто зазипованные файлы с определенными именами, так вот, если видео фрагмент переименовать в background.jpg, запаковать и установить — кирпич гарантирован).

Эх ностальгия… К сожалению в разработке лично участие не принимал (не было пк в то время), но постоянно репортил баги/подавал идеи для новых эльфов.
Не знаю как SE и motorolla, но сименсы частенько выключались сами по себе (В народе это явление называлось «пикофф», потому как при внезапном выключении издавался характерный звук), особого дискомфорта не доставляло, но все же. Происходило это в основном из-за критических ошибок, из-за криво написанных эльфов и т.п.
Что говорить, эльфы могли сделать из обычной звонилки почти полноценный смартфон. Особую радость приносили эльфы NatICQ (аська, работала все время пока был включен телефон), XTask (менеджер задач), BalletMini (опера мини), Dendy Emulator, MegaDial (удобный номеронабиратель).

Процитирую свою комментарий к похожей статье:

Эльфы — тоже интересная штука (были на 65, 75 сериях). Диспетчер задач, ballet mini, icq, jabber, dendy/sega/doom/gameboy emulator, mp3 player (для телефонов с wav only), это далеко не полный список вкусностей, доступных для мобильника по цене около 3к (конкретно у меня был siemens c72 (аналог c65). Ну и пара скринов с моего телефона (сейчас они воспринимаются с улыбкой, раньше было круто):

Вот такой получался бюджетник (siemens всегда отличались низкой ценой).
Прошло пол года после покупки девайса — сименсы были уже у всего двора :-)

К слову это не первая фича которую скрывает amazon в своих читалках. (тот же микрофон в kindle keyboard нигде не упоминается на amazon'e)

Что касается киндла:


Geolocation: Yes, you heard that right; Kindle does have geolocation facilities built in. There's no GPS, but it uses its wireless hardware to determine location, a la iPhone. To use the feature, just open the browser by going to Menu > Experimental and clicking on launch browser. Then, Press Alt-1to show your current location on Google Maps. Note that on newer models, Q key represents 1, W represents 2 and so on. The map can be zoomed in and out just like on the PC using Kindle's 5-way navigation button. Pressing Alt+2 together finds the nearest gas stations, and pressing Alt+3 looks for the nearby restaurants. Sounds cool, but why didn't Amazon tell us about it?

Хорошо, но о геолокации придется забыть — ни в одной известной мне читалке нету gps-модуля. Просто листать листать карты можно, если вас устроит скорость работы. Способов много — предложенная вами html страничка, если дело идет о киндле — используя фреймворк Qt, можно написать неплохой вьювер самому. 2GIS написан на Qt, можно попробовать портировать (не нужно будет нарезать тайтлы, а просто скачать готовую мапу. Правда векторная карта будет дольше отрисовываться).

Вопрос снимается — на форуме нашел множество программ для разных форматов.

Что можете сказать насчет чтения fb2, djvu на нуках?
На клавиатурном киндле пару софтин решают проблему недостатки форматов. Многую техническую лит-ру можно читать без проблем.

Кхм, к чему gps на читалке?