Доброго времени суток.

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

Мне было немного странно видеть, что в таком замечательном ресурсе мало обсуждения и самой темы о торговых марках, то есть наименовании IT продуктов и компаний (“торговой марки”, “торгового наименования”, “ТМ”, “trademark”). Очевидно, что любой программист и участник IT рынка (а особенно те, кто пишут свои продукты), рано или поздно столкнется с этим вопросом. Поэтому, чем раньше IT-шники об этом будут задумываться, тем меньше будет проблем в их бизнесе в будущем.

Итак, постараемся восполнить пробел и открыть тему торговых марок. Очевидно, что с точки зрения программирования легко повторить и tetris, и facebook, и любые «фермы». Но попробуйте раскрутить свой продукт (клон он или нет) с похожими на эти продукты названиями — тут же владельцы (вернее их юристы) вас закроют со всех ресурсов. С другой стороны, если ваш продукт становится популярным, то тут же назревает необходимость защитить его от клонов и сделать так, чтобы другие не использовали и не забивали вашу марку в свои ключевые слова. Если коротко — это и есть причина, по которой торговая марка выступает одним из основных параметров оценки и стоимости любого IT проекта при его финансировании, продаже и заключении солидных контрактов.

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

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

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

Основные понятия
Изображение — отображение объекта на воспринимающие органы. То есть, описание объекта, как множество признаков. Часто объект представляется в виде вектора. Если множество признаков постоянное, то объект отождествляется с его изображением.
Образ (класс) — подмножество множества объектов или изображений.
Решающая функция — функция, на вход которой подается изображение, определяющая принадлежность объекта некоторому классу.

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

Обычно у разработчика есть свой любимый инструмент, которым ему пользоваться удобнее, чем другими. Однако бывает так, что платформа заставляет разработчиков брать в руки инструмент, который не так удобен, как ему хотелось бы, или просто чем-то не устраивает. Так получилось, что традиционно приложения под Android пишут при помощи Eclipse, поскольку Google приняли решение о том, что будут разрабатывать официальный плагин, ADT, именно для этого редактора. В результате тем разработчикам, которые им не пользовались, волей-неволей пришлось его освоить.

К счастью, Google также предоставляют систему сборки, которая работает независимо от имеющейся в наличии IDE. А это означает, что можно настроить любой редактор для работы с приложениями Android. Лично я предпочитаю писать код на Java в NetBeans IDE и хочу поведать о том, как его можно настроить для этого. Есть такие плагины, как nbandroid, но разрабатывается он нерегулярно, энтузиастами, так что есть смысл воспользоваться гибкостью NetBeans и задействовать официальную систему сборки напрямую из редактора.

Мы ходим в японские рестораны,
но не едим рыбу. Кто мы?

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

Идея

Ровно год назад в декабре 2012 года мы сидели с женой в одном из ресторанов. Был новогодний ажиотаж, поэтому меню, как водится, не хватило на всех, а обслуживали достаточно долго. Даже чек пришлось ждать минут 20. Неделей ранее я впервые увидел в другом ресторане механическую кнопку вызова официанта. Тогда у меня в первый раз промелькнула идея о том, что неплохо бы каждому ресторану иметь электронное меню и такой же электронный вызов официанта. Сначала появилась мысль о маленьком Atom PC, который будет стоять в ресторане и по wifi принимать запросы от ресторанных планшетов. Подумал, обсудил с женой и забыл на пару недель. Спустя две недели ситуация с меню повторилась и тогда я понял, что все можно обернуть в красивый SaaS сервис. Сейчас, даже странно смотрится то, что эта идея не пришла ко мне сразу. Так появилась идея сервиса, который мы назвали «47 ресторанов».

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

Эта простая с первого взгляда задача встретилась мне на вступительном экзамене в DM Labs.
На первом занятии мы обсудили решение, а преподаватель (Александр Шлемов; он руководил и дальнейшей реализацией) показал, почему для решения лучше использовать машинное обучение.

В процессе дискуссии мы обнаружили, что наше решение производится в два этапа. Первый этап — фильтрация помех, второй этап — вычисление метрики, по которой будет проходить классификация. Здесь возникает проблема определения границ: необходимо знать, какие значения может принимать метрика для каждой фигуры. Можно проложить эти границы вручную “на глазок”, но лучше поручить это дело математически обоснованному алгоритму.
Эта учебная задачка стала для меня введением в Machine Learning, и я хотел бы поделиться с вами этим опытом.

Размеры дисплеев неуклонно растут, а габариты девайсов без него стремятся к уменьшению. Даже игровые компьютеры стремятся к формату mini-ITX, а уже офисным решениям нужно быть еще меньше. Давным-давно появились неттопы на Атомах, не самые быстрые, да еще и несимпатичные компы. С появлением процессором с ультранизким энергопотреблением, читай процессоров для ультрабуков, возможности инженеров приблизились к бесконечным. Я уже тестировал на OCCLub.ru решение от Intel — NUC и от Gigabyte — BRIX. Оба неттопа были основаны на Intel Core i3 и имели сверхмалые габариты, но при этом были не лишены некоторых огрехов. Девайс от Foxconn основан на таком же процессоре, больше по размерам, но имеет значительные преимущества в области расширения. Под катом — препарация неттопа Foxconn AT-7300.

 

Салют, Хабр!
Недавно я уволился с довольно завидной должности (главного архитектора) в довольно неплохой компании (Acronis) и с непоколебимым решением в мозгу больше не работать по найму переехал из Москвы обратно в Ереван, откуда семь лет назад понаехал в Златоглаво-Нерезиновую. Учитывая необычность произошедшего и часто задаваемый вопрос «но почему?!», я решил разобраться в собственных мыслях и озвучить их вслух для себя самого и тех, кто может почерпнуть в моих размышлениях что-то для себя полезное. Короче говоря, это рассказ о том, почему я оставил высокооплачиваемую перспективную работу в международной компании ради сомнительной перспективы начать собственное дело, и как я собираюсь дальше жить.

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

Для меня проблема заключалась в том, что я не люблю читать и чтение расцениваю исключительно как неизбежную работу, которую необходимо проделать, чтобы добыть материал из печатного вида. Но так получилось, что для повышения своей квалификации читать приходится. Я установил для себя норму — одна книга в месяц. С одной стороны, это мало, с другой, — много (если действительно придерживаться плана). Ну и раз уж мне приходится читать в принудительном порядке, это должно давать какую-либо выгоду. Каждая книга — это мучение, и я не вижу смысла тратить время на литературу, которая мне ничего не даст после. Поэтому каждый раз, попадая в книжный и держа в руках очередную книгу, я задаю себе вопрос: «А зачем?! Какой толк от этих кусков бумаги?! Что я вообще тут делаю?!». Чтобы вы не тратили время на книги, которые мне кажутся бесполезными, я решил написать небольшой обзор прочитанной за два года литературы и прочих найденных источников знаний. Весь материал ниже так или иначе связан с веб-разработкой и различными её аспектами. Ниже описаны только те книги, которые я прочитал. Те книги, которые «не осилил»/не дочитал (например, про NodeJS и пару фреймворков) не привожу.

История стара как мир. Две таблицы:

• Cities – 100 уникальных городов.
• People – 10 млн. людей. У некоторых людей город может быть не указан.

Распределение людей по городам – равномерное.
Индексы на поля Cites.Id, Cites.Name, People .CityId – в наличии.

Нужно выбрать первых 100 записей People, отсортированных по Cites.

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

Для меня этот проект стал первым, где надо было вплотную использовать SQLite (раньше он был нужен не более, чем для select <что-нибудь> <откуда-то>).

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

В ходе решения сделал несколько интересных для себя выводов.

В этой статье будет рассказано про крестики-нолики на Java под Android за 30 строк кода пять с половиной тысяч строк кода, и зачем потребовалось так много кода на такую простую игру.Ровно год назад, 9 декабря я выложил свою игру на Google Play. Теперь я хочу рассказать про то, что произошло за этот год, как росла популярность игры, что сработало, а что — нет.Вы увидите чистую статистику загрузок и удалений за год существования игры, цифры. Узнаете, сколько пользователей можно собрать с Google Play, как создавалась игра, как тестировалась. Вы узнаете, возможно ли создать инди-игру с нулевым бюджетом, какие трудности могут возникнуть у небольшой игры в большом мире.Кому интересно, добро пожаловать.

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

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

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

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

Здравствуйте!

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

<?php 
	echo dsCrypt('habrahabr.ru');
	//Выведет: 60634K7T0*0!
	echo dsCrypt('60634K7T0*0!',1);
	//Выведет: habrahabr.ru
?>

Если вы все еще пользуетесь XOR шифрованием :), то можете заглянуть под кат и посмотреть как еще можно защищать данные…

Предисловие

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

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

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

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

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

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

Как находить тексты похожие по смыслу? Какие есть алгоритмы для поиска текстов одной тематики? – Вопросы регулярно возникающие на различных программистских форумах. Сегодня я расскажу об одном из подходов, которым активно пользуются поисковые гиганты и который звучит чем-то вроде мантры для SEO aka поисковых оптимизаторов. Этот подход называет латентно-семантический анализ (LSA), он же латентно-семантическое индексирование (LSI)