Дисклеймер:

Я не программирую с трёх лет, не знаю наизусть Кнута, не являюсь призёром олимпиад по информатике и чемпионатов по спортивному программированию, не училась в MIT. У меня за плечами образование по информатике и 6 лет опыта в коммерческой разработке. И до недавнего времени я не могла пройти дальше первого технического скрининга в IT-гиганты из FAANG (Facebook, Amazon, Apple, Netflix, Google и подобные), хотя предпринимала несколько попыток. 

Но теперь всё изменилось, я получила несколько офферов и хочу поделиться опытом, как можно к этому прийти. Речь пойдёт о позиции Software Engineer в европейских офисах перечисленных компаний.

Мой друган в очередной раз объяснял кому-то в уличной курилке, как устроен C#. Я глотнул кофе, закурил и облокотился на ограду, чтобы послушать. Он рассказывал, какие интересные тонкости нашел в сборщике мусора. Говорит, в дотнете он устроен довольно просто снаружи, но очень хитро в деталях реализации.

Я не встревал — просто слушал и мотал на ус. Было 11 утра, я только что закрыл тикет, который от меня ждали завтра, и мог весь оставшийся день слоняться по офису. Витян всегда был очень прокачанным парнем. Он контрибьютил в рослин, изучал сорцы всех инструментов, которыми пользовался, и действительно глубоко шарил в дотнете. Я знал — мне до него как до луны. Но у нас все равно почему-то были одинаковые позиции и зарплаты.

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

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

3 причины, почему специалисты покидают IT

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

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

Некоторое время назад на Quora я отвечал на вопрос: как успевать записывать за лектором конспект по математике на LaTeX. Там я объяснил свой рабочий процесс по конспектированию в LaTeX с помощью Vim и Inkscape (для рисунков). Но с тех пор многое изменилось, так что я хочу опубликовать несколько постов в блоге с описанием нового процесса. Это первая из статей.

Я начал использовать LaTeX для конспектирования во втором семестре курса математики, и с тех пор написал более 1700 страниц. Вот несколько примеров, как выглядит конспект:

Паттерны инверсии контроля (dependency inversion, DI) известны уже давно, но пока не нашли широкого распространения в мире фронтенда. Этот доклад отвечает на вопрос о том, как за счет возможностей JS построить надежную архитектуру на основе DI-контейнера. Автор доклада — Евгений ftdebugger Шпилевский, руководитель группы разработки интерфейсов в Яндекс.Коллекциях.


— Насколько мне известно, инверсия зависимостей, DI-контейнеры и прочие паттерны, придуманные еще в 70-е годы, не очень плотно вошли в мир разработки фронтенда. На это наверняка есть причина. Отчасти дело в том, что многим людям непонятно, зачем они вообще нужны.

Не так давно у нас в компании проводили обучение для потенциальных будущих менеджеров и в том числе пригласили одного из топ-менеджеров «на поговорить».

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

Но потом разговор пришел к теме, над которой я тех пор размышляю: burnout/выгорание. По моим воспоминаниям, еще лет десять назад об этом или не говорили вообще, считая какой-то вымышленной проблемой (как, к сожалению, многие по-прежнему относятся к ментальным заболеваниям, путая депрессию и плохое настроение) или говорили об этом как говорят о чем-то постыдном типа алкоголизма с подтекстом «со мной такое не может случиться».

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

Эта статья содержит необходимый минимум тех вещей, которые просто необходимо знать о типизации, чтобы не называть динамическую типизацию злом, Lisp — бестиповым языком, а C — языком со строгой типизацией.

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

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

Предлагаю вашему вниманию перевод статьи «Tasks, microtasks, queues and schedules» Джейка Арчибальда (Jake Achibald), занимающего должность Developer Advocate for Google Chrome.

Когда я сказал своему коллеге Мэту Ганту, что подумываю о написании статьи об очерёдности микрозадач и порядке их исполнения внутри событийного цикла браузера, он сказал «Джейк, буду честен, я об этом читать не стану». Что ж, я всё же написал, поэтому откиньтесь на спинку кресла и давайте вместе в этом разберёмся, ладно?

На самом деле, если вам будет проще посмотреть видео, есть замечательное выступление Филиппа Робертса на JSConf, которое рассказывает о событийном цикле – оно не покрывает микрозадачи, но в остальном является отличным вступлением в тему. В любом случае, погнали…

Давайте рассмотрим следующий код на JavaScript:

console.log('script start');

setTimeout(function() {
  console.log('setTimeout');
}, 0);

Promise.resolve().then(function() {
  console.log('promise1');
}).then(function() {
  console.log('promise2');
});

console.log('script end');

Как вы думаете, в каком порядке должны вывестись логи?

Недавно мне довелось побывать на встрече участников проекта FreeCodeCamp в Сан-Франциско. Если кто не знает, Free Code Camp — это сообщество, нацеленное на изучение JavaScript и веб-программирования. Там один человек, который готовился к собеседованиям на позицию фронтенд-разработчика, попросил меня подсказать, какие вопросы по JavaScript стоит проработать. Я немного погуглил, но не смог найти подходящего списка вопросов, на который я бы мог дать ссылку и сказать: «Разбери эти вопросы и работа твоя». Некоторые списки были близки к тому, что мне хотелось найти, некоторые выглядели очень уж простыми, но все они были либо неполными, либо содержали вопросы, которые вряд ли кто станет задавать на реальном собеседовании.

В данной статье речь пойдет о замечательном фронтенд фреймворке Vue.js. Как вы видите, статья называется «Vue.js для сомневающихся», и, если вы до сих пор не могли решиться попробовать Vue.js на практике, то надеюсь, что после прочтения вы все-таки на это решитесь.

Расшифровка доклада Ильи Климова на конференции JavaScript fwdays.

Мы с вами попробуем отследить некоторые тренды в развитии JS, как сообщества, как движения, в 2017-ом году. Я очень постараюсь избежать оценочных суждений. Хотя кого я обманываю, все равно не получится. И где-то через год вы сможете с радостью открыть эту презентацию на YouTube, и понять, насколько я был не прав.

Поэтому давайте перенесёмся в 2015 год. Посмотрим, как развивался JS.

В этом исследовании мы показываем, что даже если новый HTTP/2 протокол значительно улучшает скорость загрузки страницы, время для полного отказа от фронт-энд оптимизаций ещё не наступило. Сегодня мы сосредоточимся на спрайт-сетах.

HTTP/2 стал доступен в 2015, как альтернатива к замене многоуважаемого HTTP/1.1, используемого с 1997. Многие авторы предсказывают устаревание или, даже, контрпродуктивность фронт-энд оптимизаций. В список классических оптимизаций входят спрайты: группировка множества маленьких изображений (спрайтов) в одно большое (спрайт-сет).

Несмотря на быстрое внедрение поддержки и в браузерах и в серверах (вики, w3techs), мы не смогли найти опубликованные сравнительные замеры для подтверждения утверждения (прим. того, что спрайты больше не нужны). Как веб-архитекторы, тогда, мы естественно, интересовались, следует ли нам отказаться от подхода спрайтов или нет. Как гласит известная цитата Уильяма Эдвардса Деминга: “In God we trust, all others bring data”. Поэтому мы сделали свой собственный бенчмарк.

Первая часть этой статьи описывает основные отличия между HTTP/1.x и 2 и почему они могут способствовать устареванию спрайтов. Во второй части мы покажем сравнительные результаты бенчмарка.

Прочитав множество постов о нынешнем «выгорании» программистов, я начал думать, как же я сумел сохранить интерес к этой профессии даже после столь долгой карьеры — с 1981 года (!). Почему интерес к коду у меня ещё не угас?

Конечно, я частично объяснил это в моём посте «Да, я в мои 56 всё ещё хочу делать это», получившем известность почти три года назад. Но тот пост был о стороне жизни профессионального программиста, связанной с самим процессом программирования; здесь же речь пойдёт не о самом написании кода, а о том, как я всё ещё выдерживаю «программистское бытие». Что же это за работа, которая захватывает так, что утром ждёшь не дождёшься открыть текстовый редактор или IDE или же испытываешь благоговейный ужас от мысли отправить свой зад в офис?

Оглядываясь назад на мои места работы — те, которые мне нравились, те, которые я ненавидел, и те, с которыми просто было можно жить, — я думаю, в чём же различие между ними? Что я делал такого, что позволило мне так долго идти по этому пути?

Не так давно увидел свет релиз Angular 1.5, который привносит множество интересных нововведений. Важной особенностью

данной версии является то, что это первый из череды релизов, который должен сгладить концептуальный разрыв между Angular1.x и Angular2.x. Для людей, у которых есть необходимость вести проекты на Angular сейчас, но в будущем планируется постепенная миграция на Angular2, это очень радостная новость.

В данной статье я постараюсь осветить основные нововведения:

• Компоненты!
• Односторонние биндинги!
• Мульти-слот трансклюды!

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

Я бэкенд Java-разработчик, и до фронтенда руки доходят очень редко. Это большое упущение. Отсутствие представления о фронтенде не даёт мне увидеть полную картину мира. Я не знаю, на что обращают внимание и как пользуются всеми модными средствами вроде Node.js, Gulp, Webpack, то есть тем, что так пугает бекенд разработчиков своим разнообразием и постоянными переменами.

И первой моей жертвой целью стал Dillinger.io. Это открытый текстовый редактор для Markdown, в нём есть подсветка синтаксиса и экспорт написанного текста в PDF, HTML, Dropbox, Github и Google Drive, также можно добавить собственный способ, к примеру, статический генератор сайтов или Wordpress.

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

Ранее в комментариях и в статье я упоминал, что в западном мире принято три обозначения ЭМК – Electronic Health Record (EHR), Electronic Medical Record (EMR) и Personal Health Record (PHR).

Прежде чем гадать на кофейной гуще, в чём похожи или отличны эти три термина, нужно определиться, что же такое эта самая Электронная Медицинская Карта. Начнём с того, что существует два измерения медицинских данных – какая информация хранится (или полнота информации) и кто хранитель (custodian) этой информации.

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

Второе измерение, хранитель информации, для которого характерны следующие варианты:
• Организация, представляющая медицинские услуги.
• Пациент как частное лицо.

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

Здравствуйте, коллеги.

В последнее время мы эпизодически возвращаемся к теме JavaScript. Нас особенно заинтересовала очередная книга из серии «You Don't Know JS», посвященная стандарту ES6 (Кайл Симпсон):



Кстати, может быть кто-то уже присматривался к новой книге Адама Бодуха "JavaScript at Scale" и хотел бы увидеть ее на русском языке?



Об этом в опросе. А под катом — критическая (январская) статья мистера Коди Линдли, помогающая задуматься о том, насколько мир JavaScript готов к переменам.

Некоторое время назад у меня состоялся интересный разговор, коллега активно защищал Angular, говорил, что тот ускоряет веб-разработку. Я более десяти лет разрабатываю сложные web-сервисы, работал в Microsoft, в Spotware Systems на Кипре, сейчас создаю приложение для стартапа из Кремниевой долины, и в общем то слежу за трендами. Однако почувствовал себя динозавром, потому что не видел смысла использовать фронтэнд-фреймворки до того момента, а оказалось, что это уже мейнстрим. Шёл 2014-й год, я погрузился в мир Angular, Knockout и Backbone, что из этого вышло, почему я от них в итоге отказался и рекомендую коллегам сделать то же самое – под катом.