Новая парадигма уже на пороге — или нет?

Согласно исследованию компании Flurry, житель США в среднем проводит за смартфоном около пяти часов в день. Эта цифра удивительна сама по себе, но, кроме того, около 65% этого времени идет на разного рода общение — социальные сети, текстовые сообщения, электронную почту и телефонные звонки. То есть, 3 часа 15 минут — каждый день.

А это значит, что все очень и очень изменилось. Хотели сделать мобильное приложение для своего крутого проекта? Ему придется конкурировать с миллионами других приложений за оставшиеся 35% времени, ежедневно уделяемого пользователями смартфону. И не забывайте сопутствующие затраты на поиски стоящей идеи.

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

• Написание бота бесполезно с точки зрения бизнеса.
  
• Написание ботов — невероятно сложная техническая задача.
  

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

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

Хотите внедрить или доработать функцию поиска? Вам сюда.

Спросите разработчика: «Как бы вы реализовали функцию поиска в своем продукте?» или «Как создать поисковую систему?». Вероятно, в ответ вы услышите что-нибудь такое: «Ну, мы просто запустим кластер Elasticsearch: с поиском сегодня всё просто».

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

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

Цель статьи

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

Основываясь на опыте работы с универсальными решениями и узкоспециализированными проектами самого разного масштаба (в компаниях Google, Airbnb и нескольких стартапах), я расскажу о некоторых популярных подходах, алгоритмах, методах и инструментах.

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

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

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



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

Intro

Основам git мне пришлось научиться на своем первом месте работы (около трех лет назад).
С тех пор я считал, что для полноценной работы нужно запомнить всего-лишь несколько команд:

• git add <path>
• git commit
• git checkout <path/branch>
• git checkout -b <new branch>

И дополнительно:

• git push/pull
• git merge <branch>
• git rebase master (а что, можно еще и на другие ветки ребейзить? О_о)

В принципе, я и сейчас во многом так считаю, но со временем волей-неволей начинаешь узнавать интересные трюки.

Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage).

Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего.

Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь?

Ответ на этот вопрос даёт мутационное тестирование.

Добрый вечер! Хотите произвести впечатление на друзей? Или просто шокировать прохожих теплым летним вечером? Сделайте светодиодную футболку! Представляю Arduino проект выходного дня – эксклюзивная светодиодная футболка. Как она будет смотреться, увидите в ролике. А пока фото.



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

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

Меня зовут Олег Андреев, мне 32 года, занимаюсь ремонтом и разработкой электроники, а также программированием (уже более 10 лет). Всегда увлекался искусственным интеллектом и робототехникой.

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

Сетки из шестиугольников (гексагональные сетки) используются в некоторых играх, но они не так просты и распространены, как сетки прямоугольников. Я коллекционирую ресурсы о сетках шестиугольников уже почти 20 лет, и написал это руководство по самым элегантным подходам, реализуемым в простейшем коде. В статье часто используются руководства Чарльза Фу (Charles Fu) и Кларка Вербрюгге (Clark Verbrugge). Я опишу различные способы создания сеток шестиугольников, их взаимосвязь, а также самые общие алгоритмы. Многие части этой статьи интерактивны: выбор типа сетки изменяет соответствующие схемы, код и тексты. (Прим. пер.: это относится только к оригиналу, советую его изучить. В переводе вся информация оригинала сохранена, но без интерактивности.).

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

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

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

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

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

Предлагаю читателям "Хабрахабра" перевод статьи "Why, oh WHY, do those #?@! nutheads use vi?" за авторством John Beltran de Heredia.

Да, даже если вы не можете в это поверить, у редактора vi, увидевшего свет более тридцати лет назад (и его более молодого, всего-то пятнадцатилетнего лучшего клона & большого улучшения — vim) очень много фанатов.

Нет, они не динозавры, которые не хотят идти в ногу со временем — сообщество пользователей vi продолжает увеличиваться: я, который начал только два года назад (после десяти лет работы программистом). Мои друзья переходят на vi сейчас. Черт, большинство пользователей vi даже еще не были рождены, когда он был написан!

Да, есть конкретные причины, почему модель редактирования vi/vim превосходит любую другую. Вам не надо быть экспертом в Unix, чтобы использовать vi — он доступен бесплатно практически для любой существующей платформы; для большинства IDE существуют плагины, позволяющие использовать его возможности. Давайте же развеем некоторые заблуждения и рассмотрим пару примеров, демонстрирующих его превосходство.

Понадобилось мне недавно реализовать трёхпозиционный переключатель. Ну это такой, у которого вместо двух состояний «включено/выключено», есть ещё промежуточное состояние. Это часто используется, например, в чекбоксе «выбрать всё», для того чтобы показать, что выбраны не все элементы, а только часть. В общем, захотелось такое реализовать, да чтобы без скриптов.

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

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

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

Глоссарий

Для начала давайте определимся с понятиями и описаниями.

Также хочу добавить что чувство – это более высокий элемент, чем ощущение. Банальный пример: чувство сопереживания и ощущение боли. Ощущать сопереживание нельзя, значит ощущение это то, что дают нам органы чувств.

Добавлю, что я не буду рассматривать сами органы чувств и оставлю этот момент на желание читателя.

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

И заранее: Интеллект != нейронная сеть.

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

Среди рассмотренных будут следующие темы:

1. Наш опыт в выборе подходящей идеи и движение от первых наработок до полноценного продукта.
2. Проведение маркетинговой компании. Что способствовало раскрутке нашей игры и что в итоге помешало нашей стать игре более узнаваемой.
3. Юридические вопросы, связанные с работой с рынком Steam. Открытие ИП или ООО. Выбор валютного расчетного счета.

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

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

В данной статье постараюсь раскрыть основные нюансы реализации системы демонов для PHP и научить консольные команды Yii2 демонизироваться.

Последние 3 года я занимаюсь разработкой и развитием достаточно большого корпоративного портала для одной группы компаний. Я, какие и многие, столкнулся с проблемой, когда решение задачи, которую требует бизнес, не укладывается ни в какие таймауты. Сделайте отчетик в excel на 300 тыс. строк, отправьте рассылку на 1500 писем и так далее. Естественно, такие задачи должны решаться фоновыми заданиями, демонами и crontab-ами. В рамках статьи я не буду приводить сравнение кронов и демонов, мы для решения подобных задач выбрали демонов. При этом важным требованием для нас стала возможность иметь доступ ко всему, что уже написано для бэкенда, соответственно, демоны должны быть продолжением фрейворка Yii2. По этой же причине нам не подошли уже готовые решения типа phpDaemon.

Под катом готовое решение для реализации демонов на Yii2, которое у меня вышло.

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

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

Зачем.

В этой маленькой статье, которую с удовольствием прочитал бы сам неделю назад, я попытался собрать все вещи, которые понадобились бы человеку, задумай он «с нуля» написать приложение на RoR. То есть не углубляясь ни в одну из областей, описать необходимый минимум действий, чтобы установить, настроить и написать своё первое приложение.Здесь собрано, как мне кажется, всё, что нужно и я надеюсь этот текст сэкономит кому-нибудь несколько часов поиска в интернете). Сам изучаю RoR вторую неделю, так что не судите строго).

Установка.

Просто и быстро ror ставится через rvm c rvm.io.

>\curl -L https://get.rvm.io | bash -s stable --rails --autolibs=enabled

Запустить rvm:

>source /Путь_к_домашней_директории*/.rvm/scripts/rvm

*$HOME в дальнейшем.
После этого в $HOME/.bash_profile должна появиться строчка:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*

и при каждом открытии консоли rvm будет подгружаться, но у меня этого не случилось — пришлось ещё в $HOME/bashrc прописывать:

. ~/.bash_profile

Теперь всё точно должно быть хорошо.
Устанавливаем нужную(скорее всего это будет самая последняя) версию руби (сколько их и в чём отличие можно посмотреть здесь -http://www.ruby-lang.org).

>rvm install 1.9.3

Проверка на успешность создания

>ruby -v

должна вернуть более подробную информацию, вроде

ruby 1.9.2p320 (2012-04-20 revision 35421) [x86_64-linux].

В процессе установки я случайно установил несколько версий, что потом доставило некоторые неприятности). Посмотреть список установленных версий руби можно так:
>rvm list
Если версий несколько, то текущая будет помечена "=>", дефолтная — "*", а текущая и дефолтная — "=*". Поменять на нужную используемую версию можно так:

>rvm use ruby-1.9.2-p320 (любая нужная версия)

Чтобы поменять дефолтную версию руби пишем:

>rvm use ruby-1.9.2-p320 --default