Приветствую! Хочу вам показать один из способов, как реализовать свободное перемещение частиц в указанном диапазоне. Для выполнения этой задачи я буду использовать ReactJS. Но сам алгоритм все равно будет общим, и вы можете его использовать где угодно.

Привет, Хабр! Эту статью меня подвигла написать замечательная история, как одна новозеландская компания 8 недель работала с тремя выходными. И как мы ими как бы гордимся.

Контекст

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

Мы придумываем, как этим управлять и первые пробы и эксперименты, разумеется, ставим на себе. Очевидно: занимается мы HR в ИТ.

Итак

Эксперимент: четырехдневная рабочая неделя.

Место действия: Москва и Киев. Распределенный коллектив.
Интеллектуальный труд. Самоокупаемая коммерческая компания.
Продолжительность эксперимента: более 100 сотруднико-лет.
Подробности под катом.

Доброго времени суток, Хабр! Представляю вашему вниманию перевод статьи «Understanding Promises in JavaScript» автора Sukhjinder Arora.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Understanding Asynchronous JavaScript» автора Sukhjinder Arora.

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

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

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

Большинство вопросов анкеты строилось на материалах мастер-класса Наталии Дзеружинской, доктора медицинских наук, профессора, врача-психиатра высшей квалификационной категории, проведённого ею в рамках «Школы менеджеров «Стратоплан»» (видеозаписи 5 мастер-классов школы).

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

Как мы узнали, более 50% ИТ-специалистов имеют опыт профессионального выгорания, причём половина из них прошли через этот опыт 2 и более раза. Для работодателя подобное выгорание сотрудников имеет довольно серьёзные последствия: до 20% сотрудников находятся регулярно в подобном состоянии, только 25% выгорающих остаётся на прежнем месте работы. А значит, довольно большая часть сотрудников работает крайне неэффективно и мешает другим, плюс постоянно нужно вкладывать средства в рекрутинг и адаптацию новых сотрудников взамен выгоревших. Если работодатель научится управлять процессом выгорания, то сможет экономить много материальных и моральных сил для своей компании.

Смотрел я тут на днях выступление Kate Gregory на конференции Pacific++ 2018.


Кейт — хороший программист и отличный спикер. Сам доклад поднимает много интересного о программировании на С++ и программировании вообще (стоит посмотреть). Но больше всего меня зацепила одна высказанная ею (буквально вскользь) мысль. Кейт удалось очень кратко и по делу обозначить мотивацию программистов. Звучала она так: «Программист во время работы стремится максимизировать своё счастье». Это звучит банально, но ведь так оно и есть.

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

Сразу хочу вынести за скобки вопросы оплаты труда, условий работы, начальства, коллектива и прочего. Если вы работаете там, где работаете — то всё это вас примерно устраивает. Давайте сфокусируемся на том, что делает нас счастливыми и несчастными при непосредственной работе над кодом.

Автор материала, перевод которого мы публикуем сегодня, сотрудник Welldone Software, говорит, что если в двух словах рассказать об инструментах для тестирования JavaScript-проектов, то для модульного и интеграционного тестирования рекомендуется использовать Jest, а для тестов пользовательского интерфейса — TestCafe. Однако каждый конкретный проект может нуждаться в чём-то особенном. Лучший способ найти именно то, что нужно — взять несколько инструментов, которые, как кажется, подойдут, и испытать их в действии. Эксперименты подскажут — на чём именно стоит остановиться.



Представляем вашему вниманию обзор наиболее широко используемых инструментов тестирования для JS-проектов, на которые стоит обратить внимание в 2018-м году.

С выходом нового React 16.6.0 в документации появился HOOKS (PROPOSAL). Они сейчас доступны в react 17.0.0-alpha и обсуждаются в открытом RFC: React Hooks. Давайте разберемся что это такое и зачем это нужно под катом.

Некоторые люди как-то неправильно поняли WebAssembly. Есть те, кто считает, что раз браузеры уже поддерживают выполнение WebAssembly (ещё с 2017 года), значит всё уже готово. Даже и близко ещё нет, готов лишь MVP (минимально жизнеспособный продукт). Я могу предположить откуда произрастает корень этого заблуждения: после релиза MVP его разработчики пообещали поддерживать обратную совместимость на уровне «любой написанный сейчас код будет работать и в будущем». Но это ведь не значит, что разработка WebAssembly закончена, совсем нет! Множество фич разрабатывается прямо сейчас и планируется к разработке в ближайшем будущем. И когда они будут реализованы — всё очень сильно изменится.

Все эти фичи можно попробовать представить себе в виде дерева навыков в какой-нибудь игре. У нас есть пару «базовых» (уже реализованные фичи) и целое дерево со множеством веток и листьев, которые будут со временем открываться, давая нам всё больше и больше могущества.

Давайте посмотрим на то, что у нас уже есть сейчас и что нам ещё предстоит открыть.
(Под катом много картинок, трафик)

(Начальное название статьи «Алгоритм работы протокола SSH» было изменено по рекомендациям Vindicar, Karroplan и других участников хабросообщества)

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

Попытаюсь внести немного ясности в работу протокола SSH, а заодно рассмотреть роль алгоритма RSA и ключей авторизации пользователя…

HOC — слишком громкое слово для простого функционального паттерна!

Месяц назад в РайффайзенБанке прошел первый фронтенд-митап, и поскольку я всего за пару дней подготовил презентацию на тему «High order components with functional patterns using Recompose», а информацию о Recompose мельком выцепил в интернете за неделю до доклада, то не успел подготовить никакого справочного материала, и даже не написал своих контактных данных в конце презентации, что было не очень хорошо. И на вопрос: «Где мы можем увидеть ваши слайды?», я замялся и ничего не ответил, за что очень сильно извиняюсь.

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

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

Возможно, это поможет и вам.

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

Знаю, у других это тоже бывает.

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

Очень важно проявлять упорство перед лицом таких трудностей — хотя это и непросто.

За прошедшие годы я научился нескольким ментальных «хитростям», которые помогали мне в сложные минуты, часы и дни.

Я расскажу о тех точках зрения, которые оказались особенно полезны.

Переведено в Alconost

Данная статья является конспектом книги "Чистый Код" Роберта Мартина и моим пониманием того, каким Чистый Код должен быть. Тут нет разделов о тестировании, TDD, о том какая должна быть архитектура и т.д. Здесь все только о том, каким должен быть Чистый Код.

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

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

Автор материала, перевод которого мы сегодня публикуем, Нэш Вэйл, говорит, что недавно он занимался исследованием лендинг-страниц. В ходе работы он наткнулся на один сайт. Это был отличный, полезный ресурс. Однако, в ходе работы с ним, Нэш заметил, нечто неприятное.

Неестественная анимация

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

Если по счастливому совпадению вы нашли что-то общее с персонажами, напишите в комментариях.

Авторские иллюстрации подготовлены Антоном , за что ему огромное спасибо!