Сегодня, в переводе седьмой части руководства по Node.js, мы поговорим об асинхронном программировании, рассмотрим такие вопросы, как использование коллбэков, промисов и конструкции async/await, обсудим работу с событиями.

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

Суть

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

git clone https://github.com/attardi/wikiextractor.git
cd wikiextractor
wget http://dumps.wikimedia.org/ruwiki/latest/ruwiki-latest-pages-articles.xml.bz2
python3 WikiExtractor.py -o ../data/wiki/ --no-templates --processes 8 ../data/ruwiki-latest-pages-articles.xml.bz2

и потом немного отполировать скриптом для пост-процессинга

python3 process_wikipedia.py

Результат — готовый .csv файл с вашим корпусом.

Если вы музыкант или знаете кого-то из музыкантов, то вам знакомы такие понятия как «практика» и «репетиция». Они имеют совершенно разное значение.

Большинство музыкантов имеют «священные» часы практики. Они делают это не для артистов, группы или кого-то еще. Это время для того, чтобы сесть и сосредоточиться на технике, песне, которую они хотят изучить, или на том, что их сердце желает.

Когда я изучал язык Go, мне очень понравилась идея с приведением к интерфейсам по сигнатурам методов (остальная часть системы типов мне не понравилась, слишком примитивная). Это ведь статическая утиная типизация! По научному: структурная типизация.

Если вдуматься, у такого подхода куча недостатков: начиная со сложности реализации и заканчивая нарушением принципа подстановки Лисков. Ведь если у класса есть метод с нужной сигнатурой (включая название), это совсем не значит, что этот метод делает то, что ожидается.
Поэтому в мейнстрим языках, в том числе в C#, структурная типизация не поддерживается. Казалось бы на этом и сказке конец. Но недавно я осознал что в проекте, которым я сейчас занимаюсь, структурная типизация применяется. Подробности под катом.

Интерфейсы, впервые появившись в PHP 5, давно уже заняли прочное место в объектно-ориентированной (или всё-таки правильнее «класс-ориентированной»?) части языка.

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

Однако не всё так просто, как может показаться начинающему программисту на PHP. Привычные аналогии не работают, руководство по языку вводит вас в заблуждение, в коде таятся неожиданные «подводные камни»…

Три предыдущие части:

• Готовимся к собеседованию по PHP: ключевое слово «static»
• Готовимся к собеседованию по PHP: псевдотип «callable»
• Готовимся к собеседованию по PHP: Всё об итерации и немного про псевдотип «iterable»

Ну привет. Я только что с собеса, и у меня бомбит. Сколько не пишут на Хабре, как правильно собеседовать — лучше не становится.

Мне кинули предложение — Senior full-stack .NET Developer, удаленно, крутой проект, куча денег. В списке требований хренова гора не связанных между собой вещей из мира .net и js/ts. Выглядит так, будто просто свалили в кучу все, что нагуглили за 10 минут — причем мало понимая, что именно.

Тревожно, но ничего. Собеседовать, думаю, будет разработчик — человек, с которым я говорю на одном языке. Расскажу про то, что делал, обсудим подходы к решению задач, проблемы в .NET, перспективы C#. Поговорим про структуры данных. Расскажу, почему структурная типизация мне нравится больше, чем мнемоническая. Если пойдет хорошо, поделюсь даже своей идеей фикс — всегда использовать структуры вместо классов в качестве моделей. Посравниваю FLUX с MVVM, расскажу, как нереально красив симбиоз ФП и ООП в TypeScript.

В общем, предвкушаю хороший разговор.

Типичный кандидат по версии излишне рьяных «охотников на самозванцев»

Несколько дней назад Филипп fillpackart Ранжин выпустил статью под заголовком «Хватит подозревать разрабов в самозванстве. Научитесь лучше собеседовать», в которой поднял очень острую для индустрии проблему неадекватных собеседований. Я ее прочитал, ужаснулся, прочитал еще раз и задумался: «а почему вообще такая фигня происходит?». С этим вопросом я отправился к паре знакомых HR-специалистов и директору Crossover Russia Владимиру vme Еронину (что в итоге вылилось в статью в блоге) и, как оказалось, ноги подобных неприятных и непонятных практик растут, как обычно, не из нашей собственной культуры найма.

К сожалению, тренд на слепое копирование всего и вся, «чтоб было не хуже, чем на Западе», жив и в 2018 году. И если в иностранных компаниях подобные вещи хоть как-то можно оправдать, закрыв глаза на градус маразма, то для России и стран СНГ множество из выработанных заокеанскими коллегами механизмов вообще неприменимы. Вот только не все HR-специалисты и руководители это понимают.

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

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

Суть разработки программного обеспечения
— Нужно проделать 500 отверстий в стене, так что я сконструировал автоматическую дрель. В ней используются элегантные точные шестерни для непрерывной регулировки скорости и крутящего момента по мере необходимости.
— Отлично, у неё идеальный вес. Загрузим 500 таких дрелей в пушку, которые мы сделали, и выстрелим в стену.

Я занимаюсь программированием уже 15 лет. Но в последнее время при разработке не принято думать об эффективности, простоте и совершенстве: вплоть до того, что мне становится грустно за свою карьеру и за IT-отрасль в целом.

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

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений.

Недавно я вырос из лютого эникея в очень большой компании, до скромного сисадмина надзирающего за сетью в 10 ПК. И, как очень ленивый сисадмин, столкнулся с задачами по автоматизации своей деятельности. Полгода назад я еще не знал, что в командной строке Windows есть конвейеры. Это стало первым шокирующим открытием. И я пошел дальше, и выяснилось, что там, где я раньше писал утилитки на C#, Delphi или громоздкие скрипты с вложенными циклами, можно было обойтись парой команд forfiles или robocopy.
Не буду рассказывать о банальностях, типа о перечислении файлов и папок клавишей Tab. Под хабракатом расскажу о том, что может быть полезно начинающим админам и эникеям.

Если хочешь в чем-то разобраться — учись сразу у лучших. Сегодня на мои вопросы отвечает бог корутин и concurrency, Рома elizarov Елизаров. Мы поговорили не только о Kotlin, как вы могли бы подумать, но ещё и о куче смежных тем:

• Golang и горутины;
• JavaScript и его применимость для серьезных проектов;
• Java и Project Loom;
• олимпиадное программирование на Kotlin;
• как правильно обучаться программированию;
• и другие волнующие вещи.

Несколько дней назад активисты движения за свободное аппаратное обеспечение выпустили вторую версию крошечного Linux-компьютера VoCore2 размером 25,6×25,6×3,0 мм, то есть с крупную монету (почти вписались по площади в квадратный дюйм). В спичечный коробок поместится примерно восемь таких компьютеров.

Это потомок того самого VoCore, на который собирали деньги через Indiegogo. Всё-таки собрали, и проект живёт. Это абсолютно открытый компьютер, который кто угодно может собрать из указанных комплектующих (или купить плату в сборе за $17,99). Компьютер работает на прошивке OpenWrt/LEDE, то есть идеально подходит на роль портативного маршрутизатора.

В предыдущей статье мы рассмотрели несколько интересных моментов языка python, разумеется, одной статьёй они не исчерпываются, поэтому продолжим.

В одном из комментариев рассматривался следующий код:

SEX = 'Female', 'Male'
sex = SEX[True]  # -> Male
sex = SEX[False] # -> Female

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

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

Последнее время ко мне часто обращаются начинающие тимлиды и руководители продуктов с вопросами: а что почитать на тему управления? что почитать на тему планирования? что почитать про управление рисками?

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

Разбираемся с технологиями роуминга (Handover, Band steering, IEEE 802.11k, r, v) и проводим пару наглядных экспериментов, демонстрирующих их работу на практике.

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

От переводчика: эта статья — перевод материала, написанного программистом Аластером Парагасом (Alastair Paragas) из Apple.Он работал с такими языками программирования, как Javascript, Python, PHP, Java, Scala, Haskell, Swift и Rust. Аластер делится собственными размышлениями на тему выбора и изучения «своего» языка, ведь этот вопрос актуален как для новичков, так и для профессионалов, которые хотят выбрать новый инструментарий.

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

Друзья, с позиции главы программного комитета Frontend Conf поместил под катом краткий обзор шести самых полезных докладов с РИТ++ 2018 по фронтенду.

В подборке нашлось место рассказу про то, как настраивать PWA-приложения и делать их более нативными. Отдельно затронуты вопросы транспиляции, где на примере API Яндекс.Карт показано, как можно писать на ES2015, получая на выходе ES3, и обеспечить поддержку IDE и линтеров. Еще одна история — про популярные форматы хранения изображений, их сжатие и варианты загрузки на мобильные устройства. Не менее хардкорный доклад про то, как перенести нагрузку, связанную с расчетом анимации, с CPU на видеокарту. Плюс два отдельных доклада про секреты и лайфхаки CSS.

Все доклады — сугубо практические, а некоторые — вполне холиварные. Одним словом, именно такие, как мы любим, и отбираем для Frontend Conf Moscow.

Я работаю с контекстной рекламой достаточно давно. И ещё веду курсы для новичков по работе с Я.Директ. Некоторым из них повседневные приёмы кажутся крутыми «фишками». Возникла идея поделиться некоторыми из них в этой короткой статье.

Прим. перев.: Автор оригинальной статьи — Nicolas Leiva — архитектор решений Cisco, который решил поделиться со своими коллегами, сетевыми инженерами, о том, как устроена сеть Kubernetes изнутри. Для этого он исследует простейшую её конфигурацию в кластере, активно применяя здравый смысл, свои познания о сетях и стандартные утилиты Linux/Kubernetes. Получилось объёмно, зато весьма наглядно.



Помимо того факта, что руководство Kubernetes The Hard Way от Kelsey Hightower просто работает (даже на AWS!), мне понравилось, что сеть поддерживается в чистоте и простоте; и это замечательная возможность понять, какова роль, например, Container Network Interface (CNI). Сказав это, добавлю, что сеть Kubernetes в действительности не очень-то интуитивно понятна, особенно для новичков… а также не забывайте, что «такой вещи, как сети для контейнеров, попросту не существует».