Как стать автором
Обновить
110
0
Александр Мышов @Myshov

Because it's there

Отправить сообщение

Какие английские слова IT-лексикона мы неправильно произносим чаще всего

Время на прочтение 5 мин
Количество просмотров 170K
Пока пара новых статей на технические темы еще в процессе написания, я решил опубликовать небольшой лингвистический материал. Достаточно часто замечаю, что коллеги, у которых английский язык — не родной, неправильно произносят некоторые характерные для IT сферы слова. И дело здесь не в том, насколько аутентично произносятся отдельные звуки, а именно в транскрипции. Регулярно встречал ситуации при общении с носителями, когда неправильно произносимое слово приводило к недопониманиям.

Дальше я приведу несколько наборов слов, сгруппированных по типовым ошибкам. К каждому слову будет приложена транскрипция, приблизительная транскрипция на русском и ссылка на более детальную информацию в словаре. Так как большинство IT компаний все-таки работает с Северной Америкой, то транскрипции будут из US English.
Читать дальше →
Всего голосов 309: ↑308 и ↓1 +307
Комментарии 486

Лошадь сдохла – слезь: переход с tslint на eslint

Время на прочтение 7 мин
Количество просмотров 40K
До недавнего времени во всех проектах фронта разработчики Dodo Pizza Engineering использовали tslint – полезный инструмент, который подсказывает, когда ты накосячил в коде допустил неточность, помогает поддерживать код в одном стиле и сам исправляет многие замечания. Но тут tslint взял и умер. Под катом я расскажу, почему так вышло, как перестать лить слёзы по умершему и перейти на инструмент eslint, а также покажу кое-что очень интимное.


Читать дальше →
Всего голосов 39: ↑37 и ↓2 +35
Комментарии 12

Что нужно знать про арифметику с плавающей запятой

Время на прочтение 14 мин
Количество просмотров 931K


В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

Арифметика с плавающей запятой почему-то считается экзотической областью компьютерных наук, учитывая, что соответствующие типы данных присутствуют в каждом языке программирования. Я сам, если честно, никогда не придавал особого значения компьютерной арифметике, пока решая одну и ту же задачу на CPU и GPU получил разный результат. Оказалось, что в потайных углах этой области скрываются очень любопытные и странные явления: некоммутативность и неассоциативность арифметических операций, ноль со знаком, разность неравных чисел дает ноль, и прочее. Корни этого айсберга уходят глубоко в математику, а я под катом постараюсь обрисовать лишь то, что лежит на поверхности.
Читать дальше →
Всего голосов 245: ↑242 и ↓3 +239
Комментарии 75

4 совета для оптимизации webpack-приложения

Время на прочтение 4 мин
Количество просмотров 20K
Всем привет!

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

Кот-фронтендер смотрит на webpack и говорит 'Белиссимо'

Читать дальше →
Всего голосов 19: ↑19 и ↓0 +19
Комментарии 17

Как не наступать на грабли в Go

Время на прочтение 10 мин
Количество просмотров 88K

Этот пост является версией моей же англоязычной статьи "How to avoid gotchas in Go", но слово gotcha не переводится на русский, поэтому я буду использовать это слово как без перевода, так и немного непрямой вариант — "наступать на грабли".


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

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


Но один вопрос меня мучал долгое время — почему я сам никогда не делал этих ошибок? Серьезно, самые популярные из них, вроде путаницы с nil-интерфейсом или непонятного результата при append()-е слайса — в моей практике никогда не были проблемой. Каким-то образом мне повезло обойти эти подводные камни с первых дней своей работы с Go. Что же мне помогло?


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

Читать дальше →
Всего голосов 46: ↑38 и ↓8 +30
Комментарии 9

Как проходят алгоритмические секции на собеседованиях в Яндекс

Время на прочтение 9 мин
Количество просмотров 402K

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


Так что мы подготовили для вас следующие материалы:


  • Специальный контест, содержащий задачи, похожие на те, что мы даём на интервью.
  • Этот пост. В нём рассказывается, почему нужно проводить такие секции, а также разбираются все задачи контеста.
  • Два видео, в которых разбираются задачи из контеста: в первом — задача попроще, во втором — две задачи посложнее. Из этих видео вы узнаете о типичных ошибках, допускаемых и при прохождении алгоритмических секций, и при написании продакшен-кода.
Читать дальше →
Всего голосов 86: ↑52 и ↓34 +18
Комментарии 105

Яндекс.Блиц. 12 алгоритмических задач отборочного раунда и их разборы

Время на прочтение 18 мин
Количество просмотров 106K

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


В Блице можно использовать Java, C++, C# или Python. Кроме того, участие в контесте дает возможность проверить свои знания. Если в итоге вы понимаете, что их стоит подтянуть, — это тоже результат. Кстати, тогда вам может пригодиться специализация на курсере «Алгоритмы и структуры данных», в создании которой Яндекс участвовал.


image


Давайте теперь разберем задачи, которые предлагались в отборочном раунде. У нас было несколько одинаковых по сложности вариантов, каждый из которых содержал по шесть задач. Мы разберем один набор задач полностью, а также наиболее интересные задачи из других наборов. К слову, из 1762 участников квалификационного раунда в финал прошли лишь 263. Так что задачи оказались не самыми простыми.

Читать дальше →
Всего голосов 38: ↑38 и ↓0 +38
Комментарии 18

Юнит-тестирование для чайников

Время на прочтение 15 мин
Количество просмотров 1M
Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

We need to go deeper
Всего голосов 70: ↑63 и ↓7 +56
Комментарии 65

The Art of Unit Testing

Время на прочтение 4 мин
Количество просмотров 56K


Есть некоторые категории знаний, которые профессиональный разработчик познает в процессе своей работы, не прилагая к этому особенных дополнительных усилий. Вот, например, мало кто из нас читал замечательную книгу по регулярным выражениям Джеффри Фирддла, чтобы познакомиться с одноименной темой. Безусловно, есть масса людей, для которых «регвыры» стали смыслом жизни и без подобных фундаментальных знаний никак не обойтись. Но в большинстве случаев пары мелких статей и справки в соответствующем разделе документации будет достаточно для более или менее комфортной работы с регулярными выражениями (если такое понятие, как «комфортная работа» с регулярными выражениями вообще существуетJ).

Аналогичным образом мы обычно относимся и к изучению юнит тестирования. Ведь юнит-тесты – это же не rocket science; для их изучения не требуется многолетняя подготовка и множество бессонных ночей проведенных за изучением толстенных «талмудов» от гуру юнит-тестирования. Концепцию автоматизированного тестирования кода можно объяснить за 10 минут, а познакомившись с одним из тестовых фреймворков семейства xUnit (еще 15 минут), вы сможете работать с любым другим фреймворком практически сразу же. Затем нужно будет потратить еще 20 минут на изучение какого-нибудь изоляционного фреймворка, типа Rhino Mocks, и, вуаля, у нас есть еще один профессионал в области юнит-тестов.

Читать дальше →
Всего голосов 42: ↑34 и ↓8 +26
Комментарии 19

Реактивный фронтенд. История о том, как мы снова всё переписали

Время на прочтение 13 мин
Количество просмотров 32K
Привет, это снова Катя из Яндекс.Денег. Продолжаю свою историю о том, как я перестала верстать и начала жить. В первой части я рассказала, как меня сюда занесло и чем занимаются наши фронтендеры. Сегодня — про фронтовый стек, откуда там React и куда делся БЭМ.

Спойлер: БЭМ пока никуда не делся ¯\_(ツ)_/¯. Погнали!



Внимание: высокая концентрация фронтенда. Много текста, картинок и кода, как обещала.
Читать дальше →
Всего голосов 30: ↑24 и ↓6 +18
Комментарии 47

Не учите фреймворки, учите архитектуру

Время на прочтение 5 мин
Количество просмотров 198K
Некоторое время назад у меня состоялся интересный разговор, коллега активно защищал Angular, говорил, что тот ускоряет веб-разработку. Я более десяти лет разрабатываю сложные web-сервисы, работал в Microsoft, в Spotware Systems на Кипре, сейчас создаю приложение для стартапа из Кремниевой долины, и в общем то слежу за трендами. Однако почувствовал себя динозавром, потому что не видел смысла использовать фронтэнд-фреймворки до того момента, а оказалось, что это уже мейнстрим. Шёл 2014-й год, я погрузился в мир Angular, Knockout и Backbone, что из этого вышло, почему я от них в итоге отказался и рекомендую коллегам сделать то же самое – под катом.
Читать дальше →
Всего голосов 152: ↑133 и ↓19 +114
Комментарии 123

О главнейшей причине существования современных JS-фреймворков

Время на прочтение 7 мин
Количество просмотров 32K


Автор материала, перевод которого мы публикуем сегодня, говорит, что ему очень и очень часто приходилось видеть, как веб-разработчики бездумно пользуются современными фреймворками вроде React, Angular или Vue.js. Эти фреймворки предлагают много интересного, но, как правило, программисты, применяя их, не учитывают главнейшей причины их существования. Обычно на вопрос: «Почему вы используете фреймворк X», можно услышать следующие ответы, среди которых, однако, нет самого главного:

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

На самом же деле самая главная, фундаментальная причина использования фреймворков заключается в том, что они помогают решать задачу синхронизации пользовательского интерфейса и внутреннего состояния приложения. Это — чрезвычайно сложная и важная задача, и именно о ней мы сегодня и поговорим.
Читать дальше →
Всего голосов 42: ↑30 и ↓12 +18
Комментарии 48

Stimulus 1.0: скромный JavaScript фреймворк для HTML, который у вас уже есть

Время на прочтение 6 мин
Количество просмотров 12K

От переводчика: Давид Хейнемейер Ханссон написал небольшой текст о том, почему он и его команда Ruby on Rails разработала свой собственный Javascript фреймворк. Оригинал текста размещен в репозитории нового проекта


обновлено 4 февраля: оригинал статьи был официально опубликован в блоге Basecamp. Обновил ссылку на оригинал и название


Мы пишем много Javascript в Basecamp, но мы не используем его для создания "JavaScript-приложений" в современном смысле. Все наши приложения рендерят HTML на стороне сервера, затем мы добавляем вкрапления Javascript, чтобы оживить их.


Это путь величественного монолита. Basecamp работает на множестве платформ, включая нативные мобильные приложения, с единым набором контроллеров, представлений и моделей, созданных под Ruby on Rails. Иметь общий интерфейс, который обновляется из единого места, — это ключ к тому, чтобы маленькая команда работала хорошо, несмотря на множество поддерживаемых платформ.


Это позволяет нам быть продуктивными, как и в старые добрые времена. Возвращение к тем дням, когда единственный программист мог обеспечить немалый прогресс, не застревая в слоях абстракций распределенных систем. Время до того, как каждый стал думать, что святым граалем является ограничение серверной стороны до только лишь производства JSON для Javascript-приложений на клиенте.

Читать дальше →
Всего голосов 12: ↑12 и ↓0 +12
Комментарии 15

React медленный, React быстрый: оптимизация React-приложения на практике

Время на прочтение 14 мин
Количество просмотров 65K

Всем привет! Хочу поделиться своим переводом статьи React is Slow, React is Fast: Optimizing React Apps in Practice автора François Zaninotto. Надеюсь, это кому-то будет полезным.


Краткое содержание:


  1. Измерение производительности React
  2. Почему ты обновился?
  3. Оптимизация через разбиение на компоненты
  4. shouldComponentUpdate
  5. Recompose
  6. Redux
  7. Reselect
  8. Остерегайтесь объектных литералов в JSX
  9. Заключение

React может быть медленным. Я хочу сказать, что любое React приложение среднего размера может оказаться медленным. Но прежде, чем искать ему замену, вы должны знать, что и любое среднее приложение на Angular или Ember может также оказаться медленным.


Хорошая новость в том, что если вы действительно заботитесь о производительности, то сделать React приложение очень быстрым довольно легко. Об этом — далее в статье.

Читать дальше →
Всего голосов 36: ↑35 и ↓1 +34
Комментарии 59

CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?

Время на прочтение 2 мин
Количество просмотров 131K

Что случилось?


Исследователи Google опубликовали исследование «Reading privileged memory with a side-channel», в котором они описывают найденную ими аппаратную уязвимость, которая затрагивает практически все современные и устаревшие процессоры вне зависимости от операционной системы. Строго говоря, уязвимостей целых две. Одной подвержены многие процессоры Intel (на них проводилось исследование). AMD с ARM также уязвимы, но атаку реализовать сложнее.

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

Пожалуй, самое вероятное и неприятное применение на данный момент — получение дампа системной памяти во время выполнения JavaScript.

Другой интересный вариант — эскалация прав чтения памяти из виртуальной машины. Как вам VPS, который ворует данные из других машин хостера?

Эксплуатация уязвимости не оставляет следов.

Насколько это серьезно?


Это очень серьезно. Мир разделится на «до» и «после». Даже если у вас вообще нет компьютера, отдельные последствия косвенно могут догнать вас в офлайне.

Как защититься?


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

Прекрасные новости, это всё?


Не все. Судя по тестам, патчи сильно повлияют на производительность существующих систем. Тесты показывают падение на 10-30% в некоторых задачах. Да-да, вы все правильно поняли, ваш мак может навсегда стать медленнее, а AWS заметно дороже.

Дополнительные данные


Читать дальше →
Всего голосов 138: ↑130 и ↓8 +122
Комментарии 524

Поняв Docker

Время на прочтение 14 мин
Количество просмотров 221K

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


К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!


UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.


Что мы имеем сегодня


  • Зоопарк дубовых VPS-хостингов.
  • Дорогие IaaS и PaaS с гарантированным vendor lock in.
  • Уникальные сервера-снежинки.
  • Ворох устаревших зависимостей на неподдерживаемой операционке.
  • Скрытые связи частей приложения.
  • Незаменимый админ полубог на скейтборде.
  • Радуга окружений: development, testing, integration, staging, production.
  • Генерация конфигов для системы управления конфигами.
  • Feature flagging.
docker run docker
Всего голосов 92: ↑83 и ↓9 +74
Комментарии 245

Инверсия управления/Inversion of Control

Время на прочтение 5 мин
Количество просмотров 68K
Инверсия управления является распространенным явлением, с которым вы столкнетесь при использовании фреймворков. И действительно, она часто рассматривается как определяющая характеристика фреймворка.

Давайте рассмотрим простой пример. Представьте себе, что я пишу программу, которая получает некоторую информацию от пользователя с помощью командной строки. Я мог бы сделать это как-то так:

  #ruby
  puts 'What is your name?'
  name = gets
  process_name(name)
  puts 'What is your quest?'
  quest = gets
  process_quest(quest)


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

Однако если бы я использовал оконную систему для чего-то похожего, я написал бы что-то, что работает с окном:
  require 'tk'
  root = TkRoot.new()
  name_label = TkLabel.new() {text "What is Your Name?"}
  name_label.pack
  name = TkEntry.new(root).pack
  name.bind("FocusOut") {process_name(name)}
  quest_label = TkLabel.new() {text "What is Your Quest?"}
  quest_label.pack
  quest = TkEntry.new(root).pack
  quest.bind("FocusOut") {process_quest(quest)}
  Tk.mainloop()

Теперь между этими двумя программами большая разница в потоке управления — в частности, в управлении временем, когда вызываются методы process_name и process_quest. В примере с коммандной строкой я контролирую, когда эти методы вызываются, но в примере с оконным приложением нет. Вместо этого я передаю контроль оконной системе (команда Tk.mainloop). Далее она решает, когда вызвать мои методы, основываясь на связях, которые я настроил при создании формы. Управление инвертировано — управляют мной, а не я управляю фреймворком. Это явление и называется инверсией управления (также известно как Принцип Голливуда — «Не звони нам, мы сами позвоним тебе» — Hollywood Principle — «Don't call us, we'll call you»).
Читать дальше →
Всего голосов 58: ↑50 и ↓8 +42
Комментарии 25

Как я писал приложение на Elm

Время на прочтение 5 мин
Количество просмотров 15K

Если вы совсем не знакомы с Elm, то, если вкратце, это функциональный язык программирования и платформа для написания web-приложений. Код, написанный на Elm, компилируется в JavaScript и встраивается на страницу. Более подробно про основы можно почитать например здесь на Хабре или же просто на официальном сайте . Я же хотел суммировать свой опыт, который получил, написав своё первое приложение, поэтому в статье будет большое число очевидных вещей, чуть-чуть неочевидных и много ссылок.

Читать дальше →
Всего голосов 31: ↑29 и ↓2 +27
Комментарии 37

Как мотивировать себя, чтобы выполнить отложенные задачи

Время на прочтение 4 мин
Количество просмотров 22K
image

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

Две стороны мотивации


Сайт Barking Up the Wrong Tree (его название переводится как «идти по ложному пути», прим. пер.) объясняет, что существуют всего два способа восприятия любой задачи. Первый способ — «взгляд снаружи», или как задача выглядит со стороны наблюдателя, а второй — «взгляд изнутри», или как она выглядит глазами исполнителя. Мы склонны забывать о последнем способе, даже если делали свою работу раньше. Например, сторонний наблюдатель воспринимает стрижку газона как тяжелую работу, в то время как вам нравится слушать музыку и при этом тренироваться на свежем воздухе. Задача не выглядит такой уж плохой, как только мы беремся за ее выполнение. Если вы изо всех сил стараетесь найти необходимую мотивацию для выполнения работы, посмотрите на нее своими глазами:

Есть большая разница между «взглядом изнутри» и «взглядом снаружи». Когда мы оцениваем задачу (даже если выполняли ее раньше), то переходим на сторону наблюдателя. Мы забываем об эмоциональной составляющей. И то, что мы так любили делать, теперь кажется тяжелой ношей.

Мне часто приходится читать несколько книг во время подготовки к интервью. И иногда моя рефлекторная реакция вызвана взглядом со стороны: «Я должен прочитать 450 страниц, прежде чем поговорить с этим человеком?! Тьфу». Ирония в том, что я люблю читать, когда нахожусь в середине процесса. Для меня это состояние «потока». Если я не напомню себе о тех положительных эмоциях, которые испытываю во время чтения, то буду прокрастинировать. Со стороны это смотрится как «еще одна тяжелая работа, которую я должен выполнить».
Читать дальше →
Всего голосов 25: ↑16 и ↓9 +7
Комментарии 6

Что нельзя говорить со сцены на ИТ-конференциях, но очень хочется

Время на прочтение 9 мин
Количество просмотров 37K


Как известно, во многом мы берем пример с Европы и США. К ИТ-сфере это относится в полной мере: разработчики перенимают инструментарий и лучшие техники программирования, ИТ-менеджеры равняются на самые прогрессивные методы управления проектами и разработкой.

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

Однако отдельные личности с критическим мышлением предостерегают нас от ошибки при выборе примеров для подражания. Далеко не всё, что говорят даже самые лучшие спикеры, положительно воспринимается аудиторией.
Всего голосов 65: ↑57 и ↓8 +49
Комментарии 39

Информация

В рейтинге
Не участвует
Откуда
Новосибирск, Новосибирская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность