Постановка задачи

Код на языке C# нужно перевести в код на Rust. Точнее, требуется такая процедура перевода (разработка продолжается на C#), чтобы в любой момент можно было получить работающий код на Rust. Эту задачу я решал для языков Java, Python, JavaScript и PHP, написав конвертер из C# в эти языки. Концепция такого конвертирования была изложена в статье UniSharping пару лет назад. Я разрабатывал этот конвертер, чтобы переводить код своего проекта SDK Pullenti (лингвистический анализ текста). И подумалось мне: а не замахнуться ли на Rust? Да, слышал разные отзывы, что язык необычный и пр., но попытка же не пытка… Тем более, что у одного из заказчиков группа программистов увлечённо пишет на нём.

В своей карьере мне приходилось быть и разработчиком, и менеджером, и даже один раз «CTO» в небольшом стартапе. И, разумеется, приходилось проводить большое количество собеседований кадидатов. Поэтому для себя я выработал такие правила проведения технических собеседований:

• всем кандидатам задавать одинаковые вопросы,
• вопросы должны быть такие, чтобы на них ответил и junior, и senior, но по разному,
• после трёх вопросов должен быть понятен уровень кандидата.

И вот такие три вопроса для Java-разработчиков у меня получились.

В интернете есть много статей с описанием алгоритма градиентного спуска. Здесь будет еще одна.

8 июля 1958 года The New York Times писала: «Психолог показывает эмбрион компьютера, разработанного, чтобы читать и становиться мудрее. Разработанный ВМФ… стоивший 2 миллиона долларов компьютер "704", обучился различать левое и правое после пятидесяти попыток… По утверждению ВМФ, они используют этот принцип, чтобы построить первую мыслящую машину класса "Перцептрон", которая сможет читать и писать; разработку планируется завершить через год, с общей стоимостью $100 000… Ученые предсказывают, что позже Перцептроны смогут распознавать людей и называть их по имени, мгновенно переводить устную и письменную речь с одного языка на другой. Мистер Розенблатт сказал, что в принципе возможно построить "мозги", которые смогут воспроизводить самих себя на конвейере и которые будут осознавать свое собственное существование» (цитата и перевод из книги С. Николенко, «Глубокое обучение, погружение в мир нейронный сетей»).

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

Мы в поте лица готовим очередную мажорную версию Tokio, асинхронной среды выполнения для Rust. 13 октября для слияния в ветку оформлен пул-реквест с полностью переписанным планировщиком задач. Результатом станет огромное улучшение производительности и уменьшение задержки. В некоторых тестах зафиксировано десятикратное ускорение! Как обычно, синтетические тесты не отражают фактическую выгоду в реальности. Поэтому мы также проверили, как изменения в планировщике повлияли на настоящие задачи, такие как Hyper и Tonic (спойлер: результат замечательный).

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

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

Многие из вас читали предыдущую статью про то, как неправильная визуализация для объяснения работы JOIN-ов в некоторых случаях может запутать. Круги Венна не могут полноценно проиллюстрировать некоторые моменты, например, если значения в таблице повторяются.

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

Все желающие приглашаются под кат

1.1 Введение

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

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

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

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

С недавних пор я активно заинтересовался темой переезда за границу, и в связи с этим изучил существующие сейчас сервисы, которые оказывают помощь в переезде ИТ-специалистам. К моему удивлению, далеко не так много проектов помогают потенциальным иммигрантам. Пока что я отобрал шесть сайтов, которые показались мне интересными.

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

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

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

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


Автор материала, перевод которого мы публикуем сегодня, собирается обсудить распространённые ошибки, которые совершают программисты при работе с Git, и поговорить о том, как с этими ошибками бороться.

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

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

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

Доступ к объемным файлам и различные внешние динамические данные часто являются очень важной частью децентрализованного приложения. При этом в самом по себе Ethereum механизма обращения наружу не предусмотрено — смарт контракты могут читать и писать только в рамках самого блокчейна. В этой статье рассмотрим Oraclize, который как раз дает возможность взаимодействия с внешним миром путем запросов к практически любым интернет-ресурсам. Смежной темой является IPFS, вкратце упомянем и о ней.

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

Первая часть дала нам теоретическое представление о том, что есть лямбда-исчисление. В этой статье мы последуем неофициальной його-заповеди «Practice-practice-practice» и увидим его в действии.

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

Весь код написан в ES6 стиле, поэтому, что бы повторить его вам нужно использовать Babel в вашем проекте (а еще есть такие кто его не использует?).

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

Если вам интересно, то добро пожаловать под кат.

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


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

Всем привет. Сразу поделим аудиторию на две части — тех, кто любит смотреть видео, и тех, кто, как я, лучше воспринимает тексты. Чтобы не томить первых, запись моего выступления на Дата-Ёлке:

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

Привет, Хабр!

Сегодня мы предлагаем вам сравнительно краткую, но при этом толковую и информативную статью об устройстве и вариантах применения Apache Kafka. Рассчитываем перевести и выпустить книгу Нии Нархид (Neha Narkhede) et. al до конца лета.


Приятного чтения!

Не так давно React позиционировал себя как "V in MVC". После этого коммита маркетинговый текст изменился, но суть осталась той же: React отвечает за отображение, разработчик — за все остальное, то есть, говоря в терминах MVC, за Model и Controller.

Одним из решений для управления Model (состоянием) вашего приложения стал Redux. Его появление мотивировано возросшей сложностью frontend-приложений, с которой не способен справиться MVC.

Главный Технический Императив Разработки ПО — управление сложностью

— Совершенный код

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

• состояние всего приложения хранится в одном месте
• единственный способ изменить состояние — отправка Action'ов
• все изменения происходят с помощью чистых функций

Смог ли Redux побороть возросшую сложность и было ли с чем бороться?

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

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



Для тех, кто не следил за темой. Рассмотрим две вращающихся друг вокруг друга чёрных дыры, допустим, массами 15 и 20 единиц (масс Солнца). Рано или поздно они сольются в одну черную дыру, но её масса будет не 35 единиц, а, скажем, всего 30. Остальные 5 улетят в виде гравитационных волн. Именно эту энергию улавливает гравитационный телескоп LIGO.

Суть идеи Горькавого и Василькова в следующем. Допустим, вы наблюдатель, сидите в своём кресле и чувствуете притяжение 35 единиц массы делить на квадрат расстояния. И тут бац — буквально за секунду их масса уменьшается до 30 единиц. Для вас, в силу принципа относительности, это будет неотличимо от ситуации, когда вас отбросило в обратном направлении с силой в 5 единиц, делить на квадрат расстояния. То есть, неотличимо от антигравитации.