Если ваш веб проект так или иначе будет связан с поиском и предоставлением пользователям некоторых данных, то перед вами наверняка встанет задача реализации строки поиска. При этом, если в проекте по какой-либо причине не удастся использовать технологии умных сервисов как Google или Яндекс, то поиск частично или полностью придется реализовать самостоятельно. Одной из подзадач наверняка будет реализация нечеткого поиска, ведь пользователи часто ошибаются и иногда не знают точных терминов, названий или имен.

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

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

Самый простой способ – задавать порядок вручную. В физических магазинах на полках делается именно так, и это называется «выкладка». У нас её делают продавцы по планограммам под каждую точку (это входит в обучение), а в тех же больших продуктовых – специальные чуваки-мерчендайзеры, которые следят, чтобы всё было ок. В Интернете, конечно, хочется сделать так же, но метод хорош до 50 позиций.

На другой стороне шкалы методы больших данных, когда все данные о вас начиная от сборки браузера, типа девайса (точнее, его цены) и разрешения экрана, плюс все данные профиля и оценка ваших действий на сайте ведут к оптимальному результату. Самый простой способ использования таких данных – за первые 20-30 секунд нахождения на сайте строить ваш профиль и сравнивать с профилями таких же людей. И предлагать вам в итоге не самые дешёвые квартиры и отели, например, а начинать с тех цен, которые для вас будут приемлемыми. Вы наверняка знаете эту сортировку, которую почему-то подают в прессе под соусом «самой удобной для клиента».

По моим ощущениям, самая удобная для нашего покупателя – это такая, которая понятна и поддаётся контролю.

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

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

Более трех лет назад я написал пост о выборе платежной системы для приема платежей на своем прошлом проекте. С тех пор прошло довольно много времени и многое в способах приема платежей изменилось. Теперь я расскажу как делал прием платежей на сайте poiskvps.ru.

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

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

В новой статье из серии «Основы геймдизайна» представлен подробный обзор самых популярных настольных игр, включая традиционные вроде шахмат и го, ролевые вроде «Зова Ктулху», европейские вроде «Колонизаторов» и многие другие, у которых есть чему поучиться.

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

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

Теперь посмотрим на сам процесс продажи. Он делится на пять шагов — приветствие, засада, разработка, презентация, продажа. Самая частая ошибка приветствия в том, что продавец, скорее всего, не доктор. Поэтому «Вам чем-нибудь помочь?» — это где угодно, но только не в стенах нашего магазина. Правильно улыбнуться и поздороваться с человеком, когда он заходит на точку. Задать настроение и обозначить, что вы его увидели. И всё. Не лезть к нему и не подходить даже. Человек зашёл — не надо набрасываться.

Хотя нет, прежде чем переходить к пунктам, обсудим подготовку.

Главный наш принцип в отношении покупателя — относиться к нему как к другу. Это не красивые слова, а одна предельно конкретная вещь — не делай ничего такого, что не сделал бы с другом.

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

Представляю вашему вниманию перевод своей статьи Amazon software engineer interview, изначально опубликованной на английском на sobit.me.

Не так давно со мной связался технический рекрутер из Amazon. Компания организовывала трехдневное онсайт собеседование по найму программистов в их берлинский офис.

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

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

С развитием HTML5 и мобильных платформ 2D-игры возвращаются в моду. Заниматься такими проектами, будь то браузерные игры, игры на телефон или для ПК, стало легче благодаря таким инструментам, как Unity, и онлайн-ресурсам с игровыми ассетами. Ниже представлен список из 10 лучших сайтов с 2D-ресурсами для игр – как платными, так и бесплатными.

Реальная информация о ситуации на отечественном рынке настольных игр из первых рук, описание процесса создания игры, перепись грабель и схема монетизации.

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

Кратко:
— Ситуация на рынке и оценка его ёмкости
— Почему важно сразу работать с крупным игроком
— Грабли разработчиков
— Расчёт монетизации и установка цены на продукт
— Аутсорсинг в Китай и другие замечательные страны
— Издание игры за рубежом
— Что нужно сделать, чтобы крупная розничная сеть полюбила ваш продукт

Привет, Хабр! Сегодня я хочу представить вам огромную коллекцию из 51 набора бесплатных векторных иконок. Да, есть потрясающие ресурсы Flaticon или Iconfinder, но бывают случаи, когда необходима именно группа иконок в едином стилистическом оформлении. Определиться с выбором, вам поможет эта подборка. Я старался собрать не как можно больше, а действительно самое лучшее.

Среди веб-разработчиков существует много споров о том, что лучше: иконочный шрифт или SVG спрайты? Четкого ответа на этот вопрос нет. Каждый выбирает свое. Данные наборы иконок вас неограничиывают в выборе, поскольку представлены в различных форматах: @font-face, SVG, EPS, AI, PSD, Sketch.

В целом данная подборка содержит более 10 000 иконок, охватывающих множество категорий: интерфейсы, технологии, наука, спорт, маркетинг, среда, транспорт и тд. Полые, заполненные, цветные, во Flat, Material, Elegant, Cartoon, Hand drawing стилях.

Responsive Icons (100 иконок, PSD, AI, EPS, SVG)

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

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

Оригинальное описание алгоритма

1. Сначала я задаю нужное количество комнат – к примеру, 150. Естественно, цифра произвольная, и чем она больше, тем сложнее будет подземелье.

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

Вместо равномерно распределённых случайных чисел (какие выдаёт генератор Math.random в большинстве языков), я использую нормальное распределение Парка-Миллера. В результате вероятность появления маленьких комнат превышает вероятность появления больших. Зачем это надо, объясню позже.

Кроме того я проверяю, что соотношение длины и ширины комнаты не слишком велико. Нам не нужны как идеально квадратные комнаты, так и сильно вытянутые.

3. И вот у нас есть 150 случайных комнат, расположенных на небольшом пространстве. Большинство из них наезжают друг на друга. Теперь мы осуществляем их разделение по технологии separation steering, чтобы разделить прямоугольники так, чтоб они не пересекались. В результате они не пересекаются, но находятся достаточно близко друг от друга.

4. Заполняем промежутки клетками размером 1х1. В результате у нас получается квадратная решётка из комнат различного размера.

5. И тут начинается основное веселье. Определяем, какие из клеток решётки являются комнатами – это будут любые клетки с шириной и высотой, превышающими заданные. Из-за распределения Парка-Миллера мы получим сравнительно небольшое количество комнат, между которыми есть довольно много свободного пространства. Но оставшиеся клетки нам также пригодятся.

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

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

8. Дерево получается аккуратным, но скучным – никаких вам замкнутых ходов. Поэтому мы случайным образом добавляем обратно примерно 15% ранее исключённых рёбер графа. В результате получится граф, где все комнаты гарантированно достижимы, с несколькими замкнутыми ходами.

9. Чтобы превратить его в коридоры, для каждого ребра строится серия прямых линий (в форме Г), идущих по рёбрам графа, соединяющим комнаты. Тут нам пригождаются те клетки, которые остались неиспользованными (те, что не превратились в комнаты). Все клетки, накладывающиеся на Г-образные линии, становятся коридорами. А из-за разнообразия размеров клеток стены коридоров будут неровными, что как раз хорошо для подземелья.

И вот пример результата!

Осторожно — под катом много монстров анимированных гифок!

Начиная серию статей о гейм-дизайне, в первую очередь стоит выяснить, что же это такое и кто такие эти гейм-дизайнеры?

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

Что же нужно, чтобы начать придумывать свою игру? Вы можете предположить, что это навыки использования движков, таких как Unreal Engine или Unity, может быть знания языков программирования и скриптинга или годы опыта?

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

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

Вторая часть

От переводчика. Статью написал Итай Керен, основатель инди-студии Untame, автор игры Mushroom 11. Получился настоящий учебник по управлению камерой в играх с боковой прокруткой. Хоть там нет ни строчки кода ни на каком языке (вру, одна есть), думаю, несложно будет перевести всё это в инструкции для компьютера. Обязательно к прочтению всем программистам и дизайнерам, которые занимаются динамичными 2D-играми. Терминологию я переводил больше по смыслу: например, position-locking — «привязанная камера». Да, и для многих игр до 1983 года показана версия для Dendy — немного неисторично, но простим.

Введение

Работая над игрой Mushroom 11, я натолкнулся на множество дизайнерских и технических вопросов. Я не рассчитывал, что кто-то напишет о вершинной анимации или плавном изменении формы, но я удивился, что по работе с камерой, задаче с 30-летней историей, тоже практически не пишут.

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

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

Картинка для привлечения внимания

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

Так как небольшой опыт создания игры у меня уже был, я вооружился не клавиатурой, как в прошлый раз, а карандашом и бумагой, и принялся «придумывать» игру. На разных листах А4 я записывал свои мысли по разным направлениям: игровые механики, сеттинг, интерфейс, правила, интересные мысли, запомнившиеся игры из детства и т. п.; при этом я параллельно шерстил Google Play Market в поисках вдохновения. В итоге, спустя несколько дней, было принято решение, что игра станет головоломкой, а именно — пазлом. За это время мой мозг и пальцы заскучали по программированию, в результате чего захотелось сделать хоть какой-нибудь прототип игры. Это сподвигло меня на более интенсивную проработку идеи пазла, и в итоге в качестве рабочего был принят вариант со следующими правилами: игровое поле состоит из квадратных кусочков пазла (далее они будут называться тайлами), на которых располагаются разноцветные линии; тайлы можно менять местами; цель игры: собрать пазл единственным образом, в котором линии одного цвета замкнуты в некий узор.

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.