Фотографии: Антон Арешин

Несколько дней назад на GitHub стал популярен китайский репозиторий 996.ICU. Вместо кода в нем — жалобы на условия труда и незаконные переработки. Само название отсылает к мему китайских разработчиков о своей работе: «С девяти до девяти шесть дней в неделю, а потом в реанимацию» (Work by '996', sick in ICU). Коммитить в репозиторий может кто угодно, если подтверждает свой рассказ скриншотами внутренних документов и переписок.

На случай обратил внимание The Verge и нашел внутри рассказы об условиях труда в крупнейших ИТ компаниях страны — Alibaba, Huawei, Tencent, Xiaomi и других. Почти сразу эти компании начали блокировать у себя доступ к 996.ICU, не отвечая на комментарии иностранных СМИ.

Я не знаю, что может быть обыденнее этой новости — как и нашей реакции на нее: «Китайцы жалуются на Гитхабе? Ок, скоро им его заблокируют и сделают свой». Мы привыкли, что о Китае только такое и пишут — блокировки, цензура, камеры, социальный рейтинг а-ля «Черное зеркало», гонения на уйгуров, адская эксплуатация, абсурдные скандалы с мемами про Винни-Пуха и так по кругу.

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

Это интересные противоречия (сочетания?). В мире, где правда окончательно умерла под ножами точек зрения, понять весь контекст, что такое на самом деле Китай — кажется, уже невозможным. Даже и не надеясь разобраться, я поговорил с несколькими людьми, которые там давно живут и работают — просто чтобы добавить еще пару мнений в копилку.

В React 16.3 был добавлен новый Context API. Новый в том смысле, что старый Context API был за кадром, большинство людей либо не знали о его существовании, либо не использовали, потому что документация советовала избегать его использования.

Однако теперь Context API является полноценной частью React, открытой для использования (не так, как раньше, официально).

Если вы читаете Twitter, вы, вероятнее всего, знаете что Hooks  -  это новая фича React, но вы можете спросить, как мы на практике можем их использовать? В этой статье мы покажем вам несколько примеров использования Hooks.
Одна из ключевых идей для понимания заключается в том, что Hooks позволяют использовать state и другие возможности React без написания классов.

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Я наблюдал за тем, как величайшие умы моего поколения работали по 18 часов в день, и хвалились этим в Instagram с тегом #hustle. Когда перформативный трудоголизм успел стать образом жизни?

Ни разу в начале своей рабочей недели – ни в очереди за утренним кофе; ни в толпе людей, едущих на работу в метро; ни в начале сортировки бездонной папки «входящие» – я не останавливался затем, чтобы посмотреть в небо и прошептать: #СлаваБогуПонедельник (СБП).

Судя по всему, этим я предаю своё поколение. Я узнал об этом во время серии моих недавних визитов в коворкинги сети WeWork в Нью-Йорке, где диванные подушки призывают занятых посетителей: «Делайте то, что вы любите». Неоновые знаки требуют «Суетиться побыстрее», а настенные надписи прославляют доктрину СБП. Даже у огурцов в кулерах WeWork есть своя программа. «Не останавливайтесь, когда устали», — недавно вырезал кто-то на плоти плавающих овощей. «Останавливайтесь, когда закончили». Метафоры, относящиеся к употреблению Kool-Aid, редко бывают настолько буквальными [в американской культуре фразеологизм «пить Kool-Aid» означает верить в опасную идею, обещающую большое вознаграждение, и связан с массовым самоубийством в Джонстауне / прим. перев.].

Всем привет!

Кратко о себе. По образованию я математик, а вот по профессии — программист. В сфере разработки с 2006 года. Хотя, поскольку программирование начали изучать ещё в школе, свои первые программки и игры я начал писать ещё в школе (примерно, с 2003). Так сложилось, что пришлось выучить и поработать на нескольких языках. Если не брать во внимание ВУЗ-овские лекции по С, С++, Бэйсику, Паскалю и Фортрану, то реально я работал с Delphi (более 6 лет), PHP (более 5 лет), Embedded (Atmel + PIC около 2.5 лет) и последним временем Python + чуть-чуть Scala. Конечно же без баз данных тоже никак не обойтись.

Для кого эта статья? Для всех, кто, как и я, хотел (или хочет) найти для себя достойную хорошо оплачиваемую работу с интересным проектом, классным коллективом и всякими плюшками. А также для тех, кто желает поднять свой уровень знаний и мастерства.

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



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

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

→ Часть 1: первая программа, особенности языка, стандарты
→ Часть 2: стиль кода и структура программ
→ Часть 3: переменные, типы данных, выражения, объекты
→ Часть 4: функции
→ Часть 5: массивы и циклы
→ Часть 6: исключения, точка с запятой, шаблонные литералы
→ Часть 7: строгий режим, ключевое слово this, события, модули, математические вычисления
→ Часть 8: обзор возможностей стандарта ES6
→ Часть 9: обзор возможностей стандартов ES7, ES8 и ES9

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

Другие части: 4-6, 7-9, 10-13, 14-15.

Руководство по проектированию баз данных.

1. Вступление.

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

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

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

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



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

Итак, обо всем по порядку.

Привет, Хабр. Под этим пафосным заголовком я бы хотел поговорить о том, что такое «инженерная наука», в чём состоит главная обязанность инженера и что бывает, если он с ней не справляется — мне кажется, в последнее время эта тема становится всё более актуальной, при этом её публичного обсуждения я не вижу.

Сподвигла меня на это разразившаяся (при моём активном участии) в минувшие выходные история с «нейроинтерфейсами» компании Bitronics Lab — детскими учебными наборами для снятия ЭЭГ и мышечной активности, которые при ближайшем рассмотрении оказались попросту небезопасны в использовании из-за несоблюдения их производителем базовых требований к электробезопасности медицинского оборудования.

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

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

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



Казалось бы, что может пойти не так?

Выбор подходящей архитектуры — ключевая часть построения фронтенда сервиса. Разработчик Анна Карпелевич рассказала студентам Школы разработки интерфейсов, что такое архитектура, какие функции она выполняет и какие проблемы решает. Из лекции можно узнать о наиболее популярных архитектурных подходах во фронтенде: Model-View-* и Flux.


— Добрый вечер. Меня зовут Аня Карпелевич. Мы сегодня с вами будем говорить про архитектуру фронтенда верхнего уровня.

Этот материал завершает серию переводов руководства по Node.js. Сегодня мы поговорим о модулях os, events и http, обсудим работу с потоками и базами данных, затронем вопрос использования Node.js при разработке приложений и в продакшне.

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

Вот исходный вопрос:

Как используется ключевое слово yield в Python? Что оно делает?

Например, я пытаюсь понять этот код (**):

def _get_child_candidates(self, distance, min_dist, max_dist):
    if self._leftchild and distance - max_dist < self._median:
        yield self._leftchild
    if self._rightchild and distance + max_dist >= self._median:
        yield self._rightchild

Вызывается он так:

result, candidates = list(), [self]
while candidates:
    node = candidates.pop()
    distance = node._get_dist(obj)
    if distance <= max_dist and distance >= min_dist:
        result.extend(node._values)
        candidates.extend(node._get_child_candidates(distance, min_dist, max_dist))
        return result

Что происходит при вызове метода _get_child_candidates? Возвращается список, какой-то элемент? Вызывается ли он снова? Когда последующие вызовы прекращаются?

** Код принадлежит Jochen Schulz (jrschulz), который написал отличную Python-библиотеку для метрических пространств. Вот ссылка на исходники: http://well-adjusted.de/~jrschulz/mspace/

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

Сегодня поговорим о сериализации словарей, JSON, регулярках, об ошибках и исключениях.

Другие статьи в этой серии:

1. Первая часть — приведение к типу, тернарный оператор, доступ к свойству по имени свойства, словари, списки, строки, конкатенация строк.
2. Эта статья
3. Часть третья: современные Python и JS: строковые шаблоны (f-строки), распаковка списков, лямбда-функции, итерации по спискам, генераторы, множества.
4. Четвертая часть — аргументы функций, создание и работа с классами, наследование, геттеры-сеттеры и свойства класса.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Equivalents in Python and JavaScript. Part 1".

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

Это не справочник, здесь не будет базовой информация о типах переменных, if-ах и циклах.
Но мы рассмотрим более сложные структуры данных и операции с ними используя Python и Javascript.

Также я проиллюстрирую это примерами из практики.

Эта серия будет интересна бэкендерам, использующим Django, Flask или любой другой Python-фреймворк, которые хотят получше узнать о современном Javascript'е. С другой стороны, эти статьи будут полезны фронтендерам, которые желают лучше понять как работает бэкенд, или даже написать свой сайт на Django.

Остальные статьи в этой серии:

1. Часть вторая: JSON, регулярки, ошибки-исключения
2. Часть третья: современные Python и JS: строковые шаблоны (f-строки), распаковка списков, лямбда-функции, итерации по спискам, генераторы, множества.
3. Четвертая часть — аргументы функций, создание и работа с классами, наследование, геттеры-сеттеры и свойства класса.

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

Я никогда так не думал. Я любил офис и эту спокойную сосредоточенность рабочего места. Думал, никогда со мной не случится. Но удалёнка случилась. Уже два года. И я пишу сюда, на любимый Хабр, свой очень субъективный пост — просто, чтобы была вторая сторона этой, как оказалось, тянущей шею медали.


Adme.ru

Привет Всем! Я недавно запустил на GitHub проект JavaScript Algorithms and Data Structures, который содержит примеры классических алгоритмов и структур данных написанных на JavaScript с объяснениями, примерами и ссылками для дальнейшего изучения (в частности на соответствующие YouTube видео).

Основная задача проекта — помочь программистам в изучении и применении алгоритмов и сделать это на JavaScript-е.

С момента появления Node.js диагностика совершенствовалась в несколько этапов, от отладки приложений до глубокого анализа производительности. В этот раз речь пойдет о стратегиях использования таких инструментов, как core dump debuggers, flame graphs, ошибках в production и утечке памяти.


Мы расшифровали для Хабра доклад Николая Матвиенко из Grid Dynamics с нашей конференции HolyJS. Далее повествование идёт от лица спикера.

Экзамен в школе прапорщиков.
— Вот смотрите. Это большой палец, это — указательный, это — средний, это — безымянный, это — мизинец. Мешаем, мешаем, мешаем (двигает пальцами)… Теперь где какой?

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

Перед моими студентами регулярно встаёт задача случайного перемешивания массива. За её решением они, как правило, лезут в гугл. И гугл им подсказывает следующее:

var shuffledArr = arr.sort(function(){
  return Math.random() - 0.5;
});

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