Блог

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

Google представили новый язык программирования Carbon, который должен стать последователем С++. Сколько языков уже вышло из под пера Google?

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

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

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

Почему очень часто можно услышать о том, что кто-то восстановил данные в БД без резервной копии, почему не использовать резервные копии? 

Я не знаю, на сколько часто можно такое услышать, статистику не веду, но могу точно сказать, что на моей практики ещё не разу резервную копию полностью не поднимали. 

Люблю VS Code, но на Linux (я его использую в Fedora) он достаточно часто падает

Я как-то уже записывал видео про ревью кода, как я познакомился с pull запросами и мое отношение к ним. 

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

Я помню когда я начинал работать с SQL, то тогда я использовал старый способ объединения таблиц, где в FROM просто перечисляются имена таблиц, а в WHERE идет наведение связей. Такой же подход долго работал в Oracle и для меня он был более читаемый. Использовать INNER JOIN, LEFT JOIN для меня было болью по двум причинам - я не считал его более наглядным и я вечно опечатывался и писал JOING. Я кажется даже где-то в книге или статьях опечатывался на автомате. 

Сейчас дочка в колледже проходит базы данных и SQL и она позвала меня помочь ей с запросами и я заметил, что у нее та же проблемам, она постоянно пишет JOING. Это семейное или у вас тоже такое было? 

Не раз слышал заявление, что меньшие задачи приводят к тому, что мы можем быстрее выйти на рынок. Допустим, что мы строим автомобиль и разбивкам задачу на более маленькие – собрать двигатель, собрать кузов, покрасить, установить двигатель на кузов. Отличное, мы разбили большую задачу по сборке автомобиля на маленькие, но сможем ли мы после сборки двигателя сразу выйти на рынок и доставить результат клиенту? 

Теоретически мы можем доставить двигатель клиентам и сказать – вот видите какую крутую фигню мы строим.