PyTorch — современная библиотека глубокого обучения, развивающаяся под крылом Facebook. Она не похожа на другие популярные библиотеки, такие как Caffe, Theano и TensorFlow. Она позволяет исследователям воплощать в жизнь свои самые смелые фантазии, а инженерам с лёгкостью эти фантазии имплементировать.

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

От А0 до B2 за год

Чуть больше года назад я был полностью монолингвом, говорящем только на английском, с нулевыми познаниями во французском языке. А спустя двенадцать месяцев, я с лёгкостью сдал международный экзамен DELF B2. Если вы не знаете, что значит «В2», посмотрите шкалу CEFR.

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

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

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

• Беседа на французском в течение нескольких часов;
• Понимание различных видов французских СМИ (например, новости и видео на YouTube);
• Чтение статей, написанных для носителей французского языка;
• Построение мыслей на французском;

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

Продуманная стратегия внутреннего общения — основа высокой продуктивности коллектива

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

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

Джеймс Хартер и Эми Адкинс из Института Гэллапа в статье для Harvard Business Review пишут: «Часто общение составляет основу здоровых отношений, включая таковые между работником и руководителем. [Постоянное общение] — лично, по телефону или в электронном виде — связано с более высоким уровнем вовлеченности». А чем выше вовлеченность, тем лучше прибыли. В Институте недавно выяснили, что компании с высокой вовлеченностью сотрудников по дивидендам на акцию опережают конкурентов на 147%.

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

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

Ярополк Раш из Wargaming рассказал, кого на самом деле ищут работодатели, чем продакт-менеджер отличается от продюсера и по какому фреймворку он работает.

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


Ярополк Раш на конференции ProductSense

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

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

Такое изложение событий было приведено в пересказе издания CNews или, по крайней мере, таким образом было интерпретировано читателями.

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

Целью данного поста является устранение этого пробела.

Алексей Акулович объясняет жизненный путь высоконагруженного проекта на PHP. Это — расшифровка Highload ++ 2016.

Меня зовут Лёша, я пишу на PHP.

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

Начнём.

Дорогие товарищи инженеры, сообщество Метархия представляет вашему вниманию современный курс по Node.js, который включает глубокий разбор всех возможностей и аспектов платформы. Основной упор делается на то, как создавать надежные высоконагруженные сервера приложений и API без привязки к конкретному фреймворку и даже протоколу, т.е. абстрагировать бизнес-логику в отдельный слой. К лекциям прикреплено множество примеров кода, демонстрирующих гибкую структуру приложений и архитектурные приемы, в том числе работу с СУБД через слой доступа к данным, создание интерактивных приложений на вебсокетах, обеспечение безопасности, Graceful shutdown, межпроцессовое взаимодействие, предотвращение утечек памяти, масштабирование и кластеризацию при помощи процессов и потоков. На текущий момент в курсе 38 лекций (около 35 и ½ часов видео), 37 репозиториев с примерами кода, 4 PDF со слайдами. Перед основной частью курса по Node.js нужно сначала освоить хоть частично курс по асинхронному программированию.

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

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

Вряд ли это название что-то говорит большинству людей. Издательство и издательство, очередное привидение из советских времен, которое уже лет тридцать ничего не выпускало, но почему-то продолжало существовать. В конце нулевых оно было на грани банкротства, но каким-то образом возвращало долги, кому бы и что оно там ни было должно. Вся его современная история — это пара строк в Википедии о чехарде между всякими государственными МГУП ШМУП ФМУП, которые пылятся в папочках Ростеха (если верить Википедии, опять же).

Но за бюрократическими строчками нет ни слова о том, какое огромное наследие «Мир» оставил в Индии и как повлиял на жизнь нескольких поколений.

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

Заодно посмотрим изменение цен и предложений на этом «рынке», а также реакцию «Тинькофф Банка» на вот это вот все.

Поехали...

Всем привет.

Сегодня я хотел бы поделиться с Вами своим видением систем очистки воды.

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

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

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

Давайте разберёмся.

Привет, %username%

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

Но я не хочу перечислять то же самое. Я не хочу меряться дозами LD₅₀ и претендовать на оригинальность.

Я хочу написать про те яды, с которыми ты, %username%, имеешь большой риск столкнуться каждый день. И которые не так просты, как их ближайшие собратья.

Врага надо знать в лицо. И надеюсь — будет интересно. А если окажется интересно — то возможно, что и осилишь вторую часть.

Итак — моя смертельная десятка!

Где-то в альтернативной вселенной, согласно MWI, я стал гениальным физиком. Но в этой вселенной просто подробно слежу за профессиональными публикациями в области физики, зарабатывая себе на хлеб развозкой пиццы базами данных. Как следствие чуть более глубоких знаний, я не могу смотреть никаких научно-популярных передач. Это как железом по стеклу — тут oversimplification, тут просто неверно, тут есть тонкости…

Я решил сформировать список наиболее часто встречающихся неправд и полуправд. Итак, самое частое это…

Большой взрыв

Его изображают примерно так:

Я уже перестал вздрагивать и удивляться, когда звонит телефон и в трубке раздается жесткий уверенный голос: «Вас беспокоит капитан такой-то (майор такой-то), вы можете ответить на пару вопросов?» Почему бы не поговорить с родной полицией…

Вопросы всегда одни и те же. «У нас есть видео с подозреваемым, пожалуйста, помогите восстановить лицо»… «Помогите увеличить номер с видеорегистратора»… «Здесь не видно рук человека, пожалуйста, помогите увеличить»… И так далее в том же духе.

Чтобы было понятно о чем речь — вот реальный пример присланного сильно сжатого видео, где просят восстановить размытое лицо (размер которого эквивалентен примерно 8 пикселям):


И ладно бы только русские дяди Степы беспокоили, пишут и западные Пинкертоны.

В прошлой статье мы рассмотрели кластеризацию RabbitMQ для обеспечения отказоустойчивости и высокой доступности. Теперь глубоко покопаемся в Apache Kafka.

Здесь единицей репликации является раздел (partition). У каждого топика один или несколько разделов. В каждом разделе есть лидер с фолловерами или без них. При создании топика указывается количество разделов и коэффициент репликации. Обычное значение 3, это означает три реплики: один лидер и два фолловера.

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

Мы выбрали пути развития руководителей разработки темой следующего Team Leader Meetup, который пройдёт вечером 28 ноября в московском офисе Яндекса. Обсудить эту тему можно будет с экспертами из крупных IT-компаний. Регистрация ещё открыта.

В этот раз нашими экспертами стали:

• Николай Крапивный, руководитель бекенд-разработки, Badoo
• Роман romas1982 Ивлиев, CTO, mos.ru
• Александр Поломодов, руководитель отдела исследований и разработки, Tinkoff.ru
• Борис Тоботрас, директор центра программных решений, Инфосистемы Джет
• Виктор Ламбурт, руководитель направления рекомендательных продуктов, Яндекс
• Игорь Кураленок, генеральный директор, Лига Экспертов

Сегодня на Хабре мы задаём им ряд вопросов, чтобы задать тон будущей дискуссии:

1. Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?
2. Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?
3. Сколько времени стоит уделять работе над техническими задачами, а сколько – над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?

Что бы вы почувствовали, если в один прекрасный летний день дата-центр с вашим оборудованием стал бы выглядеть вот так?



Всем привет! Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в «Одноклассниках». На фотографии один из четырёх дата-центров, где установлено оборудование, обслуживающее наш проект. За этими стенами находится около 4 тыс. единиц техники: серверы, система хранения данных, сетевое оборудование и т.д. — почти ⅓ всего нашего оборудования.
Большинство серверов — это Linux. Есть и несколько десятков серверов на Windows (MS SQL) — наше наследие, от которого мы на протяжении многих лет планомерно отказываемся.
Итак, 5 июня 2019 г. в 14:35 инженеры одного из наших дата-центров сообщили о пожарной тревоге.

Nginx, однозначно, один из крутейших веб-серверов. Однако, будучи в меру простым, довольно расширяемым и производительным, он требует уважительного отношения к себе. Впрочем, это относится к почти любому ПО, от которого зависит безопасность и работоспособность сервиса. Признаюсь, нам нравится Nginx. В Яндексе он представлен огромным количеством инсталляций с разнообразной конфигурацией: от простых reverse proxy до полноценных приложений. Благодаря такому разнообразию у нас накопился некий опыт его [не]безопасного конфигурирования, которым мы хотим поделиться.



Но обо всем по порядку. Нас давно терзал вопрос безопасного конфигурирования Nginx, ведь он — полноправный кубик веб-приложения, а значит, и его конфигурация требует не меньшего контроля с нашей стороны, чем код самого приложения. В прошлом году нам стало очевидно, что этот процесс требует серьезной автоматизации. Так начался in-house проект Gixy, требования к которому мы обозначили следующим образом:

— быть простым;
— но расширяемым;
— с возможностью удобного встраивания в процессы тестирования;
— неплохо бы уметь резолвить инклюды;
— и работать с переменными;
— и про регулярные выражения не забыть.

Началось все с того, что я оптимизировал отдачу ошибки HTTP 408 Request Timeout в сервере приложений Impress, работающем на Node.js. Как известно, у нодовского http.Server есть событие timeout, которое должно вызываться для каждого открытого сокета, если тот не закрылся за указанное время. Хочу уточнить, что не для каждого запроса т.е. не для каждого события request, функция которого имеет два аргумента (req, res), а именно для каждого сокета. Через один сокет может последовательно поступить много запросов в режиме keep-alive. Если мы задаем это событие, через server.setTimeout(2 * 60 * 1000, function(socket) {...}) то должны сами уничтожать сокет socket.destroy(). Но если не установить свой обработчик, то http.Server имеет встроенный, который уничтожит сокет через 2 минуты автоматически. На этом самом таймауте можно отдать ошибку 408 и считать инцидент исчерпанным. Если бы не одно но… С удивлением я обнаружил, что событие timeout вызывается и для тех сокетов, которые подвисли и для уже получивших ответ и для закрытых клиентской стороной, вообще для всех, находящихся в режиме keep-alive. Это странное поведение оказалось достаточно сложным, и я расскажу об этом ниже. Можно было бы вставить одну проверку в событие timeout, но со своим идеализмом я не удержался и полез исправлять баг на уровень глубже. Оказалось, что в http.Server режим keep-alive реализован не то что не по RFC, а откровенно не дописан. Вместо отдельного timeout для соединения и отдельного keep-alive timeout, там все на одном таймауте, который реализован на быстрых псевдо-таймерах (enroll/unenroll), но задан по умолчанию в 2 минуты. Это было бы не так страшно, если бы браузеры хорошо работали с keep-alive и переиспользовали его эффективно или закрывали бы неиспользуемые соединения.

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Итак, представим. В комнате заперты 5 котов, и чтобы пойти разбудить хозяина им необходимо всем вместе договориться между собой об этом, ведь дверь они могут открыть только впятером навалившись на неё. Если один из котов – кот Шрёдингера, а остальные коты не знают о его решении, возникает вопрос: «Как они могут это сделать?»

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