Что должен знать бекенд-разработчик?

АЛГОРИТМЫ

* Познакомиться с алгоритмами:
. Сортировки
. Поиска в строке
. Обхода и поиска в структурах данных
. На графах

* Статьи:
. Пузырьковая сортировка и все-все-все (habrahabr) https://habrahabr.ru/post/204600/
. Алгоритмы поиска в строке (habrahabr) https://habrahabr.ru/post/111449/
. Алгоритмы и структуры данных поиска. Лекции и курсы от Яндекса (habrahabr) https://goo.gl/JjvC5n
. Алгоритм Дейкстры. Поиск оптимальных маршрутов на графе (habrahabr) https://habrahabr.ru/post/111361/

* Книга:
. Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих (Адитья Бхаргава) https://goo.gl/jgeuz3
. Алгоритмы. Вводный курс (Томас Х. Кормен) https://goo.gl/ZMzsZs


СЕРВЕРНЫЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ
Цель - освоить несколько серверных языков программирования.

Нельзя останавливаться на одном языке, так как у вас может появиться 'JAVA головного мозга' - неспособность думать за пределами своего языка программирования.

Лозунг: нужно программировать не на языке программирования, а используя его.

* Примеры серверных языков:
. PHP
. Python
. Ruby
* Статьи:
. Типы данных
. Функциональное программирование
. Объектно-ориентированное программирование
. Тестирование


ПАТТЕРНЫ ПРОГРАММИРОВАНИЯ
* Познакомиться cо слелующими типами паттернов:
. Порождающие шаблоны проектирования
. Структурные шаблоны проектирования
. Поведенческие шаблоны проектирования

* Статьи:
. DesignPatternsPHP https://goo.gl/xTW5dw
. Шаблон проектирования (wikipedia) https://goo.gl/7WreCS
. Шпаргалка по шаблонам проектирования (habrahabr) https://goo.gl/mjgNSU
. Справочник «Паттерны проектирования» http://design-pattern.ru/
. Design Patterns for Humans (Github) https://goo.gl/18ENLQ
. Каталог паттернов проектирования https://goo.gl/q9KyZE

* Видео:
. Webinar: Patterns (Hexlet) https://goo.gl/ioB2Ey

* Книга:
. Приемы объектно-ориентированного проектирования. Паттерны проектирования (Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссилес.) https://goo.gl/DRpXeT


ПРИНЦИПЫ ПРОГРАММИРОВАНИЯ
* Познакомиться с принципами:
. DRY
. KISS
. YAGNI
. SOLID

* Статья:
. Принципы программирования (wikipedia) https://goo.gl/hbi7qZ

РЕГУЛЯРНЫЕ ВЫРАЖЕНИЯ
* Усвоить понятия:
. Квантификация
. Жадность
. Группировка

* Статьи:
. Регулярные выражения (wikipedia) https://goo.gl/xKZTz7
. Жадные и ленивые квантификаторы (learn.javascript) https://goo.gl/WCbVWg


SQL

* Усвоить понятия:
. DDL, DML, DQL
. Создание и удаление базы данных, таблицы
. Добавление, обновление и удаление записи
. Схема (SCHEMA)
. Представления (VIEWS)
. WHERE
. LIMIT, OFFSET
. ORDER BY
. GROUP BY
. JOIN
. Подзапросы

* Статьи:
. Что такое SQL (wikipedia) https://goo.gl/2kufz2
. Схема базы данных (wikipedia) https://goo.gl/WhQrY1
. Представления в MySQL (habrahabr) https://goo.gl/JA95Tb
. Квалифицированный выбор при использовании предложений https://goo.gl/383gXA
. Полнотекстовый поиск и его возможности (habrahabr) https://goo.gl/nKwwFr

* Курсы:
. Базы данных: SQL (DDL/DML) (Hexlet) https://goo.gl/TMTJNa
. Базы данных: SQL (DQL) (Hexlet) https://goo.gl/ngtzSe

ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ
* Усвоить понятия:
. Нормализация
. Денормализация
. Связи

* Статьи:
. Проектирование баз данных (wikipedia) https://goo.gl/NtJbmf
. Нормальная форма (wikipedia) https://goo.gl/68A4D9
. Нормализация отношений. Шесть нормальных форм (habrahabr) https://goo.gl/NqMT9z
. Денормализация БД. Зачем? Когда? Как? (habrahabr) https://goo.gl/E4A4zU

ФРЕЙМВОРКИ
Для разных языков программирования существуют разные фреймворки, не нужно изучать всё сразу, необходимо взять несколько фреймворков за основу.

* PHP фреймворки:
. Slim microframework http://www.slimframework.com/
. Laravel https://laravel.com/
. Symfony https://symfony.com/
. Yii http://www.yiiframework.com/

* Python фреймворки:
. Django https://www.djangoproject.com/
. Flask http://flask.pocoo.org/

* Ruby фреймворки:
. Ruby on Rails http://rubyonrails.org/

* Статьи:
. Фреймворк (wikipedia) https://goo.gl/z3sKAa
. Не учите фреймворки, учите архитектуру (habrahabr) https://habrahabr.ru/post/253297/

ПАКЕТНЫЙ МЕНЕДЖЕР

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

Фейсбук, вконтакте и другие соцсеточки

Проявление каждого разработчика в соцсеточках происходит по-разному. Кто-то старательно себя выпиливает отовсюду. Кто-то иногда постит интересную ссылочку. Кто-то старательно придерживается одной тематики. Кто-то постит жалобы - то ли на какой-то неудобный интерфейс, то ли на соцслужбы, то ли на больницы и тд и тп.

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

Как тут быть? Научитесь контролировать аудитории, для которых вы что-то пишете, - например, личные заметки лучше убирать подзамок. В фб очень развитая система прав, которая позволит чётко сементировать кому и что вы пишете.

Про работу и войну, ложь, задачи и приказы

Лгут все (с), но мало кто знает, почему именно все лгут. Ответ очень простой: лгут или говорят полуправду (которая также является ложью) для спуска пара как через свисток накалённой ситуации. Если этого не делать, пар легко взорвёт ту самую ситуацию.

Чтобы на войне не происходила мясорубка (мочилово) используют обман, как средство удешевления потерь. Война - это путь обмана, а обман - это путь войны. Милый обман - милая война. Святой обман - святая война. Обман коллеги - это обман того, кто не является для Тебя коллегой, а лишь тем, кого Ты используешь, как инструмент.

Работа похожа на танец, - вы с коллегами действуете слаженно и слаженно же добиваетесь результата. Это прямо противоположное явление войне. В работе ставятся задачи, обозначая и результат, который будет достигнут выполнением задачи и конечная цель, которая будет достигнута в результате выполнения ряда задач. Выполнение такой задачи начинается с предварительно обсуждения: обоснование, способоы реализации и вот это вот всё.

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

Очень важно понять, если Тебя коллега/руководитель обманывает в мелочах, то Ты для него не коллега/подчинённый. Ты для него воин аллаха, которого куда он пошлёт, туда Ты и побежишь.

Если приказывает, а не выдаёт задачи, - Ты на войне, а не на работе.
Если обманывает хотя бы в мелочах, - Ты на войне, а не на работе.

Можно быть либо на войне, либо на работе.

Относится обучаемость сотрудника к soft-скиллам?
anonymous poll

Да – 44
👍👍👍👍👍👍👍 77%

Нет – 8
👍 14%

Другое – 5
👍 9%

👥 57 people voted so far.

Что важнее в кандидате?
anonymous poll

Чтобы был результат! – 30
👍👍👍👍👍👍👍 65%

Soft-скиллы теперь не менее важны. – 16
👍👍👍👍 35%

👥 46 people voted so far.

А у кого есть успешный опыт заморозки используемого фреймворка для того. чтобы годами его использовать на продукте?

*** На правах рекламы ***

В Mad Devs освободились 3 Go разработчика Senior уровня с бекграундом в C и Java.
Цена: $35.
Подробности у @Gen1us2k

Конференция по управлению знаниями

Олег Бунин, Ник Волынкин и Светлана Нивикова организовали конференцию по управлению знаниями в IT: https://knowledgeconf.ru/2019 - 26 апреля 2019 г.

О чём эта конференция? Фактически о том, как правильно рулить информация на проектах, начиная от обучения кандидатов и заканчивая холиворами между разными представлениями информации.

Я (Дмитрий Симонов) вхожу в Программный Комитет конференции, - через меня можно подать заявку на доклад. Кроме меня в ПК ещё Николай Волынкин (Plesk), Цепков Максим, Цупко Игорь, Максим Бабич, Родион Нагорнов, Сергей Заика, Константин Медведев и бессменный коуч конференций Олега - Роман Побочий.

Велком! Подать доклад тут: https://conf.ontico.ru/lectures/propose?conference=kc2019

Роадмеп

Это короткое слово довольно злое. К нему нельзя относится легкомысленно.

Роадмеп отвечает на следующие вопросы:
* Декомпозиция всех работ и зависимость их друго от друга, чтобы добежать до цели роадмепа
* Стоимость во времени, деньгах и сроках - то есть сколько нужно оплатить времени, кому именно и календарно когда начнётся и когда закончится именно эта часть работы
* "Толщина" роадмепа в каждый момент времени не должна превышать доступных ресурсов - людей, оборудования и вот это вот всё

По сути роадмеп - это как прогресс-бар. Объясняет простыми словами, когда мы начали вкладывать бабло, когда закончим, сколько именно потратим и что именно получим в каждый календарный день всего процесса.

Даже если отставить в сторону шутки вида "каждый программист может позубиться не более, чем 32 раза", всё-равно составить полный роадмеп непросто. А уж выполнить...

Как собирать команду  на проект

Техдир без команды, - это как техдир с командой. Но без команды.

Тут нет противоречия, так как холодные незнакомые Тебе люди приходят не на пустое место, а к лидеру в проект с готовым роадмепом, налаженными процессами и свёрстанными бюджетом.

Роадмеп - это последовательно перечень понятных и очевидных шагов, как превратить текущее состояние в выпущенный в продакшн проект.

Проекты делятся на простые и сложные, которые сложены из команды, сделавшей с Тобой простой проект, и нескольких простых проектов.

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

Бюджет - это часть роадмепа, описывающая оплату человеко-ресурсов, аренду/покупку оборудования, лицензии на софт и используемые сервисы, а также консультирования экспертами.

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

После первых результатов их можно превратить в две продуктовые команды, придав им по одному помощнику. И далее почковать.

Сервисная команда - временная команда, где собранные специалисты из продуктовых команд, сфокусированная на решение одной большой задачи, которая затрагивает работу сразу многих продуктовых команд.

Александр Турханов пишет, что  выступление на конференции необходимо для карьерного и профессионального роста.

Многие специалисты достигают успехов в своей тематике после многолетней практики, но затем их развитие замедляется. Для дальнейшего продвижения нужна помощью других людей. Эту помощью можно получить из habr, по соцсетям, митапам, но как в этом поможет конференция?

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

1. Вы четко формулируете, в чем проблема. Члены ПК рецензируют ваш доклад, дают качественный фидбек.
2. Вы рассказываете о своем понимании проблемы и ее решении людям со свежим взглядом. Специальный тренер учит вас как правильно строить конференцию и сделать выступление интересным.
3. После доклада вы обсуждаете проблему и решение с людьми, которым это тоже интересно. Можно найти других интересных людей по наклейкам с интересами и по другим докладам и поговорить с ними. На конференции нормально подходить и знакомиться, это не улица.
4. Вы вернетесь домой, не потратив денег, с идеями, контактами единомышленников и запалом работать дальше.

Правильная конференция - это не пустая трата времени, это инвестиция, которая окупается.

Обман, - это когда врут или не договаривают правду. Полуправда - это тоже обман. Можно ли в работе обойтись без обмана?
anonymous poll

И да и нет, - придётся сидеть на двух стульях. – 22
👍👍👍👍👍👍👍 49%

Да, настоящих высот добиться можно только с высокой моралью. – 17
👍👍👍👍👍 38%

Нет, обман - это реалии жизни. Без него только испортишь со всеми отношения. – 4
👍 9%

Другое. – 2
👍 4%

👥 45 people voted so far.

Объяснение, что такое баги, от симпатичной девушки, далекой от разработки

Предположим Ты собралась погулять с кем-то, но неожиданно оказалось, что нужно сменить туфли. Туфли Ты сменила, но в связи с этим пришлось полностью переодеться вплоть до смены трусов.

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

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

Дай порулить!

Представь себе Сапсан, в котором Тебя впустили в кабину. Ты садишься на пассажирское сидение и с восторгом наблюдаешь за тем, как машинист нажал пару кнопочек и поезд едет сам. Машинист садится в кресло и читает "Миямото Мусаши: книга пяти колец!". Три часа подряд ничего не делает, - изредка поглядывает на приборы и пару раз что-то поправил.

Хм... Я тоже так могу! Давайте выгоним машиниста! Я! Сам! Всё! Могу! Также!!! Дайте порулить!

...

Авария, катастрофа, разбился поезд.

* * *

На практике с собранными настоящими лидерами командами всегда примерно также. Все думают, что если есть собранная команда, подобная Сапсану, всё может и всё умеет, то лидер и не нужен. Ведь всё очевидно же! Мы сами с усами! Дайте порулить!!!

И неизменно каждый раз авария за аварией... В чём загвоздка? Ведь процесс основной дейстительно производится командой. Почему без лидера не получается?

Время

Об этом уже 100500 раз писали - планируй время, пиши стартплан, оценивай задачи и тд и тп. Почему не планируем, не пишем, не оцениваем? Почему шашки наголо и поскакали? Почему "да чё тут делать? тут всё просто! победа воон виднеется! Сейчас доскачем!"?

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

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

В нашем понимании такой котик просто отсутствует, хотя нам постоянно о нём напоминают. Мы даже не мыслим такими категориями, хотя примеров его использования немало. Самй яркий пример - собор Саграда-Фамилия в Барселоне - один из самых известных «долгостроев» мира.

Но строится он по единому плану, который учитывает и время и общую стилистику с 1882го года. Если уж тогда люди умели правильно планировать, то и мы, прогрессивные потомки, как-нибудь с большими проектами справимся. Нет?

Обсудить за планирование и планирование во времени тут: http://t.me/ctorecordschat

Обсудить за безопасность тут: t.me/ctorecordschat

Святой пипец (СП)

Как бывает святой обман, предназначенный для какой-то благородной цели, бывает и святой пипец, с которым технические команды даже не то, чтобы сталкиваются... Это практически религия, членами которой мы все являемся независимо от используемого стека технологий или того, к какому рынку принадлежим: финтех, реклама, геймдев, телеком и другие...

Как это выглядит?

* Дедайн вчера, времени правильно писать нет, давайте закостылим это решение, а потом когда денег заработана, перепишем.

* Продажи обосрались, зато сео купил себе пару новых тачек и самолет. Для красивых отчетов инвесторам и сохранения имиджа сео спрятать это, поэтому «заработаем» на сокращении технической команды.

* Введем комплекс модных правил внутри компании (kpi, ценности, правила коммуникации, ...), как настоящие взрослые компании, - введём задержки выплат (по-быстрому за месяц-два прокрутим денежку) или даже сокращения зп при сохранении производительности: рынку будем хвастаться, какие мы классные, сплочённые и вообще - мы БАНДА!

* Столичный тимлид пообещает региональному разработчику золотые горы, но «после того, как ВСЕ доделает». Нет, изначально-то желания кидать не было...

* Устроим супержесткие правила работы в команде, по-минутное логирование даже походов в туалет, выжмем все до капельки по производительности. Все для фронта, все для победы! Надо потерпеть! Начальству же шлем «гладкие» отчёты и вообще офис работает на пятёрку!

* Премиальный фонд распилим так, чтобы себе забрать 90%, а у всех остальных покажем куевые показатели. Да и вообще, зачем им деньги? Не могут покупать мяса, пусть едят пирожки с картошкой!

* Давайте на этом проекте оттестируем новую модную технологию, а в резюме повесим строчку эксперта в ней

* Финансирование полученное на возрождение бизнеса потратим на операции родному человеку, а в компании скажем, что денег не дали и что надо затянуть пояса

У всех этих СП есть две особенности, которую ни кто не замечает:

* внутри команды всегда (!) говорят, что у нас-то конечно не сладко, но вот снаружи - вообще ппц, - там негров линчуют, а мужики женятся друг на друге и зп не платят по полгода.

* весь СП делается с целью получить лично для себя ништяков из внешнего мира за счёт того СП, который устроен внутри.

Эти два свойства и определяют сам СП.