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

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

В этой статье мы поговорим о том, зачем вообще их нужно знать веб-разработчикам, и затронем тему оценки сложности алгоритмов и Big O нотации.

Зачем мне алгоритмы? Я фронтендер!

Вы наверняка задумались: «А зачем мне нужно тратить своё время на изучение этих сложных алгоритмов, если я работаю с фронтендом? Как знание графов и бинарных деревьев поможет мне лучше отцентровать одну div-ку внутри другой div-ки?»

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

Многие веб-разработчики на таких форумах, как Reddit и Stack Overflow, отмечали, что, освоив даже на базовом уровне эти фундаментальные основы программирования, чувствовали себя увереннее, профессиональнее и писали более чистый и структурированный код.

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

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

Ведь они ищут лучших из лучших, и знание алгоритмов как раз делает вас лучше как разработчика. Тем более, лучше инвестировать свое свободное время в новые знания и навыки, чем в сериалы на Netflix.

И на этой прекрасной ноте давайте перейдем к основной теме статьи.

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

Начнем с плохих новостей. Да, на свете есть страны, в которых обсуждается тема "Зайцы охренели до такой степени, что жрут корм, оставленный для птиц" и все ждут выступление президента по этому поводу, потому что это самая серьезная проблема в стране. Но если мысль понаехать туда у тебя появилась только на прошлой неделе — это значит ты не занимался подготовкой предыдущие два года и, сори, тебе нужно заниматься подготовкой следующие два года. Может показаться что два года — это слишком и "мне то нужно завтра, какие два года". Но тут история такая: к началу текущей спецоперации ты уже не успел. У тебя есть шанс успеть к началу следующей. Воспользуешься ты им или нет - зависит только от тебя.

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

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

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

В отделе продаж можно услышать аббревиатуру ABC: Always Be Closing, что означает заключение сделки с покупателем. Последнее десятилетие породило еще одну аббревиатуру ABCD: Always Be Collecting Data. 

Мы используем Google для почты, карт, фотографий, хранилищ, видео и многого другого. Мы используем Twitter, чтобы читать поток сознания одного президента. Мы используем Facebook для обмена сообщениями и… ну, почти все. Но наши родители пользуются им. Мы используем TikTok… Понятия не имею, зачем. 

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

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

Прим. перев.: автор этой статьи — Ben Nadel, сооснователь и главный инженер InVision App Inc. Миссию своей команды, поддерживающей серверную инфраструктуру компании, он сам характеризует как «advocate for the users», т.к. её главная цель — гарантировать пользователям InVision «получение опыта, который они заслуживают». Его опыт — яркая иллюстрация того, что микросервисы не серебряная пуля.

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

• Организационные
  　Культура разработки performance-first
  　Бюджет скорости
  　Performance mantras
• Те, что можно использовать независимо от языка и его реализации
  　Смена языка или фреймворка
  　Смена алгоритма
  　Оптимизация алгоритма
  　Вынос инвариантов на уровень выше
  　Boolean short circuit
  　Досрочный выход из цикла
  　Предвычисление
• Для языков/фреймворков, в которых нет ленивых вычислений и приёма copy-on-write
  　Shortcut fusion
  　Ленивое вычисление
  　Copy-on-write
  　Оверинжиниринг
• Зависящие от железа
  　Разворачивание мелких циклов
  　Предсказание ветвлений (Branch prediction)
  　Доступ к памяти: направление итерации
  　Доступ к памяти: [i][j] vs [j][i]
• Для языков со сборкой мусора
  　Мутабельность
  　Zero memory allocation или GC-free
• Специфичные для JavaScript
  　Антипаттерн: накопление строк в массиве
  　Антипаттерн: Lodash _.defaults
  　Idle Until Urgent
  　Даунгрейд кода: ES6 → ES5
• Примеры из код-ревью

Облачные сервисы уже давно стали неотъемлемой частью нашей жизни. На данный момент существует большое количество сервисов от разных компаний. Так давайте разберемся в принципах работы простейшего облачного сервиса, подтянем навыки проектирования систем. Данный проект можно постоянно развивать на протяжении длительного времени, и может стать отличным pet project. Созданное облако может пригодится для управления домашними файлами, достаточно его развернуть в локальной сети и с легкостью получать доступ к файлам с разных устройств.

Прыгайте под кат за подробностями.

Обычный, теневой, виртуальный, инкрементальный… Как получилось, что простой программный интерфейс доступа к элементам веб-страниц обзавелся таким количеством «родственников»? Чем современные фреймворки не устраивает стандартная объектная модель документа или просто DOM? Что и как на самом деле отрисовывает браузер в процессе рендера веб-страницы?

Всем привет, это Макс Кравец из Holyweb. Помните сцену из Матрицы, в которой один из юных кандидатов в Избранные наставляет Нео: «Не пытайся согнуть ложку. Первое, что ты должен понять — ложки не существует!»? Давайте переформулирую: «Не пытайся изменить DOM...». А вот о том, что прячется под многоточием, мы сегодня и поговорим.

Довольно часто я попадаю в ситуацию, когда мне нужно в моменте оценить длительность реализации реализации бизнес-фичи. Обычно это какая-нибудь рядовая встреча, на которой инициатор бизнес-идеи, резво размахивая руками в воздухе, рассказывает о своем предложении. В конце своего выступления, в котором часто много слов (но не цифр) сказано о том, зачем это фича нужна и какой эффект она даст, всегда звучит сакральный вопрос: «Когда сделаете эту великолепную доработку?»

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

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

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

В начале лета в официальном блоге React вышла новость о планах на 18 версию библиотеки. Команда разработчиков рассказала о новых фичах и API, которые планируется зарелизить в обновлении. Меня зовут Ильмир Шайхутдинов, я frontend разработчик Технократии, и в этой статье я хочу пробежаться по изменениям и познакомить вас с ними поближе. 

6 лет назад мы обсуждали с сообществом критерии качества вёрстки, которые мы используем в обучении, чтобы наши выпускники радовали рынок своими умениями и подходом к работе.

С тех пор в разработке интерфейсов произошло море изменений: сначала в продакшн пришли флексы, потом подтянулись гриды, умер IE, все переехали из Фотошопа в Фигму, и много чего ещё. Каждое это изменение влияло на наши критерии, и мы постоянно их дорабатывали.

Сейчас пришло время обсудить с сообществом обновлённые критерии.

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

Всем же интересно про зарплаты? Давайте про зарплаты

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

Под катом я рассказываю о том, как формируется зарплата (особенно программиста) с точки зрения экономики.

Задача 5. Предел и вероятности

Команда Typeable понимает ценность безопасности. Мы любим Haskell, но стоит ли его выбирать, если ваша цель – создание защищенного программного обеспечения? Хотелось бы сказать «да», но как и для большинства эмпирических вопросов о разработке ПО, здесь просто нет объективного доказательства, подтверждающего, что Haskell – или ещё какой-нибудь язык программирования – обеспечивает большую безопасность, чем любой другой. Нельзя сказать, что выбор языка в Typeable не имеет значения для безопасности, но какое именно значение он имеет, еще нужно подумать.

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

Дисклеймер:

Я Дима, фронтэнд разработчик и инжиниринг менеджер, и в январе 2021 года я и жена решили переехать из Беларуси.