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



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

Введение в проблему

Здравствуйте, дорогие читатели!

Мысли о создании серии простых уроков «концептуальные идеи для новичков игродева» появились у меня спонтанно, где-то в 2:00 по Московскому времени во время создания своего нынешнего проекта. Ну нет, это так мне кажется, что спонтанно, но, наверное, это мое подсознание так среагировало. Среагировало потому, что все больше юных (коим я и сам являюсь) и очень юных программистов решают заняться созданием игр. Как мне кажется, общая тенденция молодежи-программистов (и людей, интересующихся сферой программирования) плавно перешла от создания сайтов и модных блогов к созданию развлекательных продуктов. Я начинаю замечать это и среди своих знакомых, которые одно время говорили, что, мол игры — это не серьезное программирование, но теперь уже проявляют настоящий интерес к этой среде.

Я объясняю это для себя следующим, очевидным образом. Любые информационные направления приобретает массовые тенденции к изучению при выполнении двух условий: наличие простого и адекватного инструмента осуществления конкретных задач в выбранной информационной сфере и легкость получения прибыли при продаже ваших выполненных задач. В пример же опять можно привести сферу веб-технологий (когда-то сайты было создавать ультра-хардкорно, а сейчас, наверное, даже моя мама сможет поставить блог на WordPress или его аналогах. Опять же почему? Потому что WordPress открыл возможность создавать свои блоги всем мамам вокруг света, и потому что веб-сайты открыли доступ к быстрой популярности, славе, деньгам и рому).

Но пришла эра развлечений – я не буду упоминать с каким трудом делались первые игры, но прошли десятилетия, стали появляться платные игровые движки, через какое-то время они стали практически бесплатные (Unity, Unreal Engine4), причем не движки от Васи с соседнего подъезда в которых можно только сделать “грабеж корованов ”, а движки мастодонты который представляют из себя комплексные среды разработки, способные реализовать ваши проекты мечты. Однако есть и обратная сторона этих популярных технологий. А именно большое количество некачественных продуктов. Обленились придумывать что-то свое… “Лучше сделаю флеппи берд!” – подумал Вася.

Я больше 15 лет при программировании использую логику Хоара и нахожу этот подход очень полезным и хочу поделится опытом. Естественно не надо «стрелять из пушки по воробьям», но при написании достаточно сложных алгоритмов или нетривиальных кусков кода применение логики Хоара сэкономит Ваше время и позволит внести элементы некоторого «промышленного» стандарта при программировании.

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

По поисковому запросу шум перлина сразу попадается этот перевод на Хабре. Как справедливо заметили в комментариях к публикации, речь идёт вовсе не о шуме Перлина. Возможно, автор перевода и сам был не в курсе.

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

Обычный шум (из той самой статьи):


Шум Перлина:


И увеличением количества октав первую картинку ко второй никак не приблизишь. Я не буду описывать достоинства шума Перлина и область его применения (потому что статья о программировании, а не о применении), а постараюсь объяснить как он реализован. Думаю, это будет полезно многим программистам, ведь хакерские исходники Кена Перлина мало объясняют даже при наличии комментариев.

Сегодня завершился финал Яндекс.Алгоритма — ежегодного чемпионата по спортивному программированию, который организует Яндекс. В 2015 году состязание проходило полностью в онлайне — на платформе Яндекс.Контест. Заявки на участие подали программисты из 73 стран. Больше всего участников — из России, Украины, Беларуси, Казахстана, Индии, США, Японии и Китая, но вообще география чемпионата крайне обширна — Бразилия, Индонезия, Перу, Доминиканская Республика, Мозамбик, Сенегал, Каймановы острова. 8,9% зарегистрировавшихся — девушки. Примерно половина всех участников — студенты. Всего мы получили заявки от 3722 человек, из которых до финала дошли 28.

А победителем Яндекс.Алгоритма-2015 стал Геннадий Короткевич. Он по привычке показал лучший результат, решив в финальном раунде пять из шести задач и получив при этом 80 минут штрафного времени. Геннадий занимал первое место в чемпионате Яндекса и в 2013, и в 2014 годах.



Второе место занял Пётр Митричев, а третье — Евгений Капун. Они решили по четыре задачи, при этом Пётр набрал 31 штрафную минуту, а Евгений — 79 минут. Результаты всех финалистов можно посмотреть на сайте Яндекс.Алгоритма.

Задачи для Яндекс.Алгоритма составляет международная команда, в которую входят как сотрудники Яндекса, так и приглашённые эксперты — в том числе победители и финалисты состязаний ACM ICPC и Topcoder Open. И мы по традиции подготовили для вас разборы всех заданий. Решить все из них никому не удалось. Больше всего участников справились с задачей B, а вот задания A и D решило всего по одному человеку.

В данной статье я хотел бы вкратце рассказать про самые последние best practices от Google. Я постарался выделить самые основные моменты, чтобы читатель сразу мог понять, что именно какая-либо фича дает разработчику. Не удивляйтесь, если где-то повторяюсь. Конспектировал + добавлял от себя по ходу просмотров видео в www.youtube.com/channel/UCVHFbqXqoYvEWM1Ddxl0QDg

Также к каждому пункту приводятся все необходимые ссылки для более подробного ознакомления с конкретной best practice.

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







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

Все проблемы в области Computer Science могут быть решены введением дополнительного уровня косвенности. За исключением одной: слишком большого числа уровней косвенности.
All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection.

Программные интерпретаторы известны своей невысокой скоростью работы. В этой статье я расскажу, как их можно ускорить.
Я давно уже хотел поподробней остановиться на создании интерпретаторов. Прямо таки обещал, в том числе самому себе. Однако серьёзный подход требовал использования более-менее реалистичного кода для примеров, а также проведения измерений производительности, подтверждающих (а иногда и опровергающих) мои аргументы. Но наконец-то я готов представить почтенной публике результаты, причём даже чуть более интересные, чем собирался.
В данной статье будет описано семь способов построения программной ВМ для одной гостевой системы. От самых медленных мы проследуем к более быстрым, поочерёдно избавляясь от различных «неэффективностей» в коде, и в конце сравним их работу на примере одной программы.
Тех, кто не боится ассемблерных листингов, испещрённого макросами кода на Си, обильно удобренного адресной арифметикой, goto и даже longjmp, а также программ, использующих копипаст во имя скорости или даже создающих куски самих себя, прошу пожаловать под кат.

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

Добрый день! Одним прекрасным днем мы обнаружили, что наш MSBuild деплой проект не хочет работать в новой среде: для создания и управления сайтами и пулами он использовал MSBuild.ExtensionPack. Падали ошибки, связанные с недоступностью DCOM. Среду менять было нельзя, поэтому кстати пришлась возможность написания собственных задач для MSBuild: msdn.microsoft.com/en-us/library/t9883dzc.aspx, было принято решения написать свои, которые работали бы через WMI (доступный на среде) Кому интересно, что получилось, прошу под кат.

В то время пока я собирался на ланч, мой ко-воркер Дейв окликнул меня: «Хэй, Алекс, а ты не хочешь заниматься улучшениями навыков своего программирования?». Я задумался. Это было интересное предложение, но я склонялся ответить отказом: «Сейчас я занимаюсь развитем навыков говорения на языках, дружище!». Ладно, шучу. Утро началось с того, что я добрался до почты и заполучил в руки копеечный китайский Кубик, случайно заказанный на али. К обеду я проштудировал мануал сборки и обновил мышечную память, а к вечеру пришло осознание, что я наигрался. Будущее кубика было ясным: он будет пылиться на полке, раз или два в неделю может быть я буду его собирать, чтобы привести мысли в порядок или отвлечься, но не более того. Соревнование в механической скорости сборки? Non merci, уж лучше скворечники делать…

Ситуацию, как всегда, спасли мысли об автоматизации. После недолгого изучения я узнал рекогнисцировку. Для начала, число Бога уже давно найдено и равно 20. Правда задача сборки от этого не упрощается, т.к. использовать граф кратчайших путей для всех возможных конфигураций кубика не очень спортивно и немножко накладно по ресурсам. Алгоритм Бога предполагает под собой некое разумное количество использованной памяти, и в то же время обязан обеспечить минимально возможное число модификаций. Так вот, такого алгоритма еще нет. Есть ряд алгоритмов, позволяющих заметно ускорить сборку по сравнению с традиционными шаблонными методоми, но повторять кем-то уже проложенный (математически) путь мне показалось скучным. Если кому интересно, вот хороший анализ Далее есть традиционные шаблонные методы. Идея здесь в послойной сборке снизу вверх с использованием формул. Формула — последовательность модификаций Кубика, приводящая к таким-то целевым модификациям, и таким-то побочным. Соответственно, побочные модификации почти всегда падают на еще не собранные слои. Различаются шаблонные методы уровнем детализации шаблонов. Всякого рода спидкуберы знают все мыслимые шаблоны для большого количества частных случаев, что позволяет отыграть лишнюю 0.1 секунду с каждой модификации на соревнованиях. Пример, на что еще можно потратить жизнь.

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

Что мы знаем о Кубике? Число его состояний описывается как

(8! × 3^7) × (12! × 2^11)/2 = 43 252 003 274 489 856 000

.

Наверное, не ошибусь, если скажу, что более 90% жителей России знающих, что такое светодиодные ленты, на вопрос «можно ли трансформаторы от „галогенок“ использовать для питания светодиодных лент?» ответят «нет, нельзя!». Самым распространенным объяснением станет банальное «электронный трансформатор – это переменный ток, а светодиодам нужен постоянный». Именно так нам говорят в магазинах, именно такой лейтмотив имеют подавляющее большинство «профессиональных» статей на эту тему, чем, в общем-то, и приучили людей тратить заметно больше денег.

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

Сразу оговорюсь, что для обозначения «светодиод» я и далее буду применять само собой напрашивающееся и вполне естественное сокращение СД и намеренно не буду использовать для этого понятия английскую техническую аббревиатуру LED (Light Emitting Diode). В нашей нынешней стране отсутствие какой либо должной технической подготовки менеджеров и продавцов в магазинах уже привело к замусориванию и появлению таких неестественных для технического языка, юродивых для слуха и ужасных в написании буквосочетаний «леды», «led’ы», «ледовые», или как недавно увидел бегущей строкой — «LEDовые светодиоды». Мало того, что «масло – масляное», я просто вторить и плодить это «словомутие» не хочу…

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

После прочтения статьи про CGA от SLY_G я необычайно возбудился. Вспомнил юность, IBM PC/XT и игру frogger jr, в которой лягушка должна была пересечь дорогу, избежав колес бешено мчавшихся байков. Затем по бревнам допрыгать до тихой заводи. И так до смерти, которых выдавали 4 штуки. Фраю выдали 666, но я не Макс.
Поплакав о безвозвратно потерянных годах, я решил потерять еще пару дней и сделал ремейк игры под iPad.

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

T T F S E...

читать будет не особенно интересно.

Структура публикации

• Получение кватерниона из вектора и величины угла разворота
• Обратный кватернион
• Умножение кватернионов
• Поворот вектора
• Рысканье, тангаж, крен
• Серия поворотов

Получение кватерниона из вектора и величины угла разворота

Ещё раз – что такое кватернион? Для разработчика – это прежде всего инструмент, описывающий действие – поворот вокруг оси на заданный угол:

(w, vx, vy, vz),

где v – ось, выраженная вектором;
w – компонента, описывающая поворот (косинус половины угла).

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

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

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

Доброго дня всем в эту пятницу.

Уже скоро выходные, предлагаю отвлечься от дел насущных и понастольгировать.

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

Для тех, кто не знает, поясняю — это эмулятор разных старых платформ в браузере (думаю скоро Windows XP увидим портированную на кофескрипт).

С момента того поста тут уже появились куча интересного.

Привет, %username%! Итак, продолжим написание нашего бота. Из прошлых статей, мы научились находить адрес перехватываемой функции для DirectX 9 и 11, а так же исполнять произвольный ассемблерный код в главном потоке игры и прятать от различных методов защиты. Теперь все эти знания можно применить в реальных боевых условиях. И начнем мы с исследования программы, для которой мы и пишем бот.