Еще лет 10 лет назад роль архитектора решений (Solution Architect) на проектах выполняли сами разработчики. Теперь это отдельная профессия, довольно востребованная и активно обсуждаемая. Вместе с коллегами-архитекторами подробно разбираемся во всех деталях и рассказываем, как стать архитектором в EPAM.

Статья доработана с учетом ценных комментариев, дополнен список источников.
Данный чек-лист — компиляция нескольких источников, я его делал для себя, когда в конце 2019 года покупал 13" б/у макбук 2015 года, последний из имевших нормальную клавиатуру и набор портов, перед тем как Apple перешла на клавиатуру-бабочку и usb-с порты.

Какую модель б/у макбука стоит брать? Вместо введения

На этот вопрос нет однозначного ответа, поскольку все зависит от ваших задач. Для начала 2020 года и задач «офисной» работы и серфинга я бы сформулировал ответ так — можно брать любой мак от 2014 и более позднего года выпуска, на полноценном процессоре (m5 и m7 брать скорее нежелательно). Macbook pro таким образом предпочтительнее macbook air, поскольку у последних процессор и система охлаждения обычно проигрывает в сравнении.

Оптимальный выбор, который проработает еще несколько лет без проблем — это модели с четырехядерным процессором (не путать с четырехпоточным!), такие ставили обычно в 15" модели. Оперативки не менее 8 Гб, SSD лучше 256 Гб и больше, хотя на 128 с определенными неудобствами жить тоже можно. Батарея оптимально с менее чем 500 циклами перезарядки.

Стоимость 13" макбуков 2014-2016 годов колеблется от 40 до 55 тыс. рублей, причем варианты в хорошем состоянии около 40-45 тыс. мне кажутся наиболее выгодными с точки зрения дилеммы «взять б/у или доложить и взять новый».

Надо иметь ввиду, что все модели 2013-2015 года включительно очень ограничены с точки зрения апгрейда, а апгрейд моделей с 2016 и более поздних вовсе невозможен, поэтому берите сразу конфигурацию, которой вам хватит на ближайшие 2-3 года.

Моделей с клавиатурой-бабочкой (2016-2019 гг) не то что бы надо избегать, но надо отдавать себе отчет, что они требуют радикально более бережного к себе отношения, чтобы клавиатура проработала дольше. Сейчас полно предложений продажи mac mini — это тоже хороший вариант, особенно если он базируется на нормальном четырехядерном процессоре.

Тут вот праздники скоро. Спросил недавно друг «как мне это все пережить?». Я сначала объяснял, а потом решил написать статью на Хабр. Рассказанное — услышит один человек, а написанное — прочитают сотни!

Меня, если честно, достаточно сильно раздражают всевозможные застолья. Потому что гораздо приятнее посидеть с паяльником или читая книгу, а не "… хорохорясь, ерепенясь и валяясь, как колода..." провести выходные. Но традиции-с, будь они неладны, формировались столетиями и не умея пить — бывает достаточно сложно вписаться в коллектив, найти нужный подход и т.д. Особенно грешат этим делом всевозможные руководящие кадры из старого поколения. Что же делать тем, для кого алкоголь и необходимость его употреблять — это просто лишняя головная боль? Самый простой ответ — НЕ ПИТЬ, но на практике полностью это очень сложно реализовать. Эффективнее в наших реалиях принять тезис «алкоголь — просто инструмент» и учиться с ним правильно работать и использовать для решения своих задач с минимизацией ущерба для здоровья.

Статью кладем в закладки и рассылаем всем друзьям, подчиненным и т.д. и т.п. Есть время подготовиться и встретить новогодние корпоративы во всеоружии. Практически уверен, что многое из описанного активно используют те, кто «не напиваться» обязан по долгу службы. Простой же обыватель чаще про это не думает, полагаясь на удачу и легкую руку. И чаще всего оказывается в проигрыше. Предупрежден = вооружен, поэтому под катом читаем, как победить в битве с алкоголем.

Продолжаю делать расшифровку своего доклада Docker для фронтендера с конференции FrontendConf 2019.

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

Привет, Хабр!

Несколько месяцев назад я выступал на конференции FrontendConf 2019 с докладом Docker для фронтендера и хотел бы сделать небольшую расшифровку доклада для тех, кто больше любит читать, а не слушать.

Приглашаю под кат всех веб-разработчиков, особенно фронтендеров.

В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

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

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