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

Простыми словами — мудреным приложением было трудно пользоваться. Поэтому в лаборатории Массачусетского Технологического Института взялись за улучшения и отсекли все «проблемные элементы» (ведь то, что для одного проблема, для другого легко может быть преимуществом). Улучшенную и упрощенную версию назвали Gitless. Её разрабатывали с учетом 2400 вопросов, связанных с Git и взятых с сайта разработчиков StackOverflow.

Команда авторов вычленила самые проблемные места в Git, включая две концепции staging и stashing. Затем они предложили изменения, призванные решить известные проблемы.

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

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

В лаборатории CSAIL (лаборатории информатики и искусственного интеллекта) Массачусетского технологического института исследователи нейросетей сделали так, что теперь «виртуальный мозг» в дополнение к решению выдает и его обоснование. Они обучали два модуля одной нейросети одновременно. Данными для обучения были текстовые отрывки. Результаты порадовали: компьютер думал, как и человек, в 95% случаев. И все же, прежде, чем запустить новый метод нейросетей в активное пользование, потребуется дополнительная настройка и доработка.

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

В прошлый раз мы рассказывали о том, как выбрать серверы и как установить их в офисе своими руками.

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

Профессия программиста становится все более массовой и востребованной. Сейчас порог вхождения в ИТ-сферу в принципе снизился, но продолжает расти интерес к ИТ-технологиям в целом, и к программированию в частности.

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

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

В общем, как я уже читал тут в комментах: «целые статьи пишут на то, как добавить 5 символов и пробел в конфиг». Все бы хорошо, если бы не google chrome. Они решили прекратить поддержку SPDY и NPN(кому интересно, вот комментарий chromium по этому поводу).

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

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


Под катом — расшифровка и большинство слайдов.

Продолжаю цикл статей «Оптимизация на примере». В данной статье сравниваются два эвристических алгоритма на избитой симметричной задаче коммивояжера. Сегодня чуть углубимся в данную тему и разберем определенную модификацию муравьиного алгоритма.

Тестирование распределенных систем существенно отличается от тестирования централизованных. Немногие тестировщики могут похвастаться серьезными знаниями и опытом в этой области.

Я пообщался со спикером конференции Heisenbug 2016 Moscow Андреем Сатариным (twitter.com/asatarin). Андрей участвовал в проектах по тестированию в Mail.ru, в Лаборатории Касперского, в Deutsche Bank, а сейчас тестирует распределенные системы в Яндексе. Статья будет полезна не только людям, которые занимаются тестированием, но и разработчикам. Если вы ни разу не касались вопроса тестирования распределенных систем, добро пожаловать под капот.

Андрей Сатарин:

… они убивают ноды прямо в рабочее время и разработчики наблюдают за...

Подозреваете, что Linux-сервер взломан? Уверены, что всё в порядке, но на всякий случай хотите повысить уровень безопасности? Если так – вот несколько простых советов, которые помогут проверить систему на предмет взлома и лучше её защитить.

На днях мы решили пообщаться с нашим главным преподавателем на программе Deep Learning, Григорием Сапуновым, и обсудить с ним актуальные вопросы, связанные со сферой искусственного интеллекта (ИИ). Григорий несколько лет назад был руководителем разработки Яндекс.Новостей. В настоящий момент является CTO и сооснователем компании Intento. Уже 15 лет как занимается анализом данных, искусственным интеллектом и машинным обучением, с 2011 года занимается Deep Learning, участвовал в проектах RoadAR (нейросетевое распознавание объектов на дороге), Icon8 (нейросетевые фильтры) и др.

Специалисты из нескольких ВУЗов Европы – Давиде Фуччи, Джузеппе Сканиелло, Симоне Романе, Мартин Шеппэрд, Бойсе Сигвени, Фернандо Уйагуари, Бурак Туран, Наталья Юристо и Марку Ойиво – провели очередное исследование на тему эффективности тестирования ПО. Они рассмотрели методологии Test Driven Development (TDD) и Test Last Development (TLD).



Исследователи сравнивали их по двум показателям – суммарная скорость разработки продукта и качество исходного кода. Первая методология (разработка через тестирование – TDD) вновь не оправдала возложенных надежд: популярная ранее схема тестирования после разработки (TLD) оказалась не менее эффективной. Так что по указанным выше показателям существенных отличий они не обнаружили.

В таком случае чем же объясняется вспышка интереса к TDD, когда она только появилась? Эта методология возникла в 2000-х, так что теперь элемент новизны можно смело сбросить со счетов. Тем не менее, предметом споров она остается до сих пор.

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

Тогда я написал пост «Заблуждения программистов относительно „времени“», в котором указал 34 ошибочных представления и заблуждения, относящихся как к календарному, так и к системному времени. С большинством из них я столкнулся сам, занимаясь дебаггингом программ (как рабочих, так и тестовых).

Когда речь заходит про машинное обучение, обычно подразумевают большие объемы данных — миллионы или даже миллиарды транзакций, из которых надо сделать сложный вывод о поведении, интересах или текущем cостоянии пользователя, покупателя или какого-нибудь аппарата (робота, автомобиля, дрона или станка).
Однако в жизни обычного аналитика самой обычной компании много данных встречается нечасто. Скорее даже наоборот — у вас будет мало или очень мало данных — буквально десятки или сотни записей. Но анализ все же нужно провести. Причем не какой попало анализ, а качественный и достоверный.

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

Для этого вы можете воспользоваться методами байесовой статистики, например, Automatic Relevance Determination.

Игорь Сысоев ( isysoev )

Меня зовут Игорь Сысоев, я автор nginx и сооснователь одноименной компании.

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

Я буду говорить о масштабируемой конфигурации nginx, но это не о том, как обслужить с помощью nginx сотни тысяч одновременных соединений, потому что nginx для этого настраивать не надо. Нужно выставить адекватное число рабочих процессов или поставить его в режим «авто», поставить worker_connections в 100 000 соединений, после этого заниматься настройкой ядра — это гораздо более глобальная задача, чем просто настройка nginx. Поэтому я буду рассказывать о другой масштабируемости — о масштабируемости конфигурации nginx, т.е. о том, как обеспечить рост конфигурации от сотни строчек до нескольких тысяч и при этом тратить минимальное (желательно константное) время на сопровождение этой конфигурации.

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

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

DeepMind разработала новый тип ИИ, способный учиться использовать собственную память. Проект получил название "Дифференциальный нейронный компьютер" (Differential Neural Computer, или DNC).

Какие последствия может иметь проект, цель которого — «научить» компьютер использовать собственную память? Главное — слабая форма ИИ становится более эффективной, чем когда-либо. Например, такая система может помочь человеку передвигаться в полностью незнакомом городе без малейших неудобств.

Недавно ZlodeiBaal писал о достижениях в сверточных нейронных сетях (CNN) (и, кстати, тут же успешно настроил и обучил сеть для поиска области автомобильного номера).
А я хочу рассказать про принципиально иную и, наверное, более сложную модель, которую сейчас развивает Алексей Редозубов (@AlexeyR), и про то, как мы, конечно проигнорировав некоторые важные элементы, и ее применили для распознавания автомобильных регистрационных знаков!

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

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

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

Если вы относитесь к числу таких разработчиков, вам стоит обратить внимание на разработку гибридных приложений, так как вы сможете работать с языком, который вы уже знаете, будь то: HTML5 или JavaScript. Более того, вы можете использовать популярные фреймворки, например: Twitter Bootstrap или jQuery Mobile для разработки своих приложений.

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

Почему Telerik AppBuilder?