Вчера стартовал Revision Online 2020!

• сайт мероприятия: https://pm.revision-party.net/start
• расписание CEST (UTC+2): https://pm.revision-party.net/timetable
• youtube: https://www.youtube.com/channel/UCqqLfq_BLPFe1QIPerYi86w/
• discord: discordapp.com/invite/ZfRaw63
• twitch: www.twitch.tv/revisionparty (прямая трансляция!)
• irc: #revision @ open.ircnet.net (6667)
• виртуальный тур по Revision: https://www.sofaworld.net/

Что еще можно успеть посмотреть в прямом эфире? Практически всё — мероприятие только стартовало. Концерты, семинары, эвенты, но самое главное, соль, выделено ниже жирным:

Суббота (11 апреля, CEST UTC+2)

13:00 Tracked Music
14:00 Семинар: «Amiga users and hardware upgraders»
15:00 Shader Showdown 2020 Semifinals
17:00 Shader Showdown 2020 Final
18:00 ASCII/ANSI/PETSCII > Oldskool Music > Photo > Animation/Video > PC 64K Intro
21:00 Концерт: Ronny
22:00 Amiga Intro > PC 4K Intro > 256 Byte Intro > Oldskool Demo

Сегодня темой выпуска ИЦБМ будет… АНИМЭ. То самое, которое обычно обсуждают на irc-каналах про FreeBSD, в перерывах между патчами ядра. И вернемся мы назад во времени ажн к февралю 1999 года, то есть на двадцать один (!) год назад.


Перед нами видео-диск Locomotion для ZX Spectrum 128К + дисковый интерфейс. Авторы конверсии два простых самарских парня alkoro и unbeliever, а дело было так… После работы Blame для демопати Funtop'98 мы научились легко оперировать с видео-фрагментами из оперативной памяти Спектрума. Ролик с Биллом Гейтсом не являлся великим достижением, но он и сегодня смотрится вполне прилично, особенно если отойти от экрана и держать в голове, что все данные в момент видео находятся в ОЗУ 128К.

На прошлой неделе =RMDA= выпустила свой первый релиз для легендарного советского компьютера «Электроника БК-0011М» и я хочу рассказать вам некоторые подробности. Вот сама работа: Gift 2020



Это gift — такой тип поздравительных intro, обычно приуроченных к Дням Рождения. Так получилось, что к моменту завершения работы у двух видных деятелей российской демосцены синхронно случился день рождения, и мы решили немного переформатировать этот релиз в гифт, чтобы все остались довольны. В остальном, перед нами обычное intro/demo, никак не связанное с ограничениями по размерам.

Доброго времени суток, друзья!

В этой статье объясняются некоторые концепции из теории музыки, на основе которых работает Web Audio API (WAA). Зная эти концепции, вы сможете принимать взвешенные решения при проектировании аудио в приложении. Статья не сделает вас опытным инженером по звуку, но поможет понять, почему WAA работает так, как работает.

Дамы, господа, как бодрость духа?

От лица =RMDA= приглашаю вас на Revision Online 2020. Как вы отлично знаете, коронавирус лютует, отменены не только крупные мировые конференции, но даже крошечные мероприятия вокруг демосцены по всей Европе (Forever, Speccy.pl и многие другие). Ребята из команды Revision две недели боролись с муниципалитетом микроскопического городка в Германии, но не смогли отстоять право на проведение демопати. Они решили сделать мероприятие онлайн.

С 10 по 14 апреля, 72 часа непрерывного онлайн-потока по всем платформам и аспектам демосцены ждут вас! Все тут: 2020.revision-party.net

Мы активно участвуем в организации Revision Online 2020 и уже выпустили первую работу по теме: Revitro, 256 bytes intro, PC, x86

Честь по чести и часть за частью. Примерно так мы будем погружаться с вами в увлекательный мир демосцены. Сегодня поговорим о конкретной работе в области sizecoding. Дело в том, что некоторые релизы не только имели культовый статус в узких кругах — они прямо и явно воздействовали на умы людей, заставляя учить IDA Pro, смотреть код, проникать во все мельчайшие детали. Было просто непонятно и очень интересно, как же такая магия работает.

Речь идет о cross by Queue Members Group — 128 байт интро для PC из далекого 1996 года:



Вот видеозапись работы:

Дамы, господа, сегодня отличный день!

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


Одной из форм соревнования на демосцене является sizecoding — программирование визуальных эффектов в крайне ограниченном объеме машинного кода. Прежде чем мы перейдем к достижениям сегодняшнего дня (а они есть и более чем масштабные), давайте очень быстро пробежимся по наследию дедов. Все приведенные ниже работы сделаны в разные годы, объединяет их требование к платформе — PC, x86, DOS (никакого GPU, обычная видеокарта). В идеале вам стоит поставить DosBox и запускать каждую работу самостоятельно, благо авторы не особенно озадачиваются созданием видео и загрузкой его на YouTube. Мы постарались выбрать по одной показательной работе в каждой номинации.

Итак, друзья, 1-е апреля прошло, пора раскрывать карты, что же такое "2B or not 2B" на самом деле. Это совместный текст от автора работы jin_x и уже знакомого вам деда unbeliever



Обязательно скачайте архив с работой на Pouet и прочитайте вводную (первоапрельскую) статью, а так же комментарии к ней. Посмотрите первое видео с практической демонстрацией того, как работает код из «двух байт» на x86. И вот уже потом попробуйте осилить весь текст ниже.


Да, 2B or not 2B — это действительно среда для запуска различных sizecoding-работ, очень простая и, пожалуй, самая маленькая из существующих. При этом она имеет свои требования и ограничения.

Если кто-то ещё не уловил, тул 2b.com запускается из-под DOS (DOSBox, FreeDOS, MS-DOS) и осуществляет прыжок в область командной строки (по смещению $82* сегмента PSP), запуская на исполнение код, который передан в командной строке в двоичном виде. Собственно говоря, код этот вполне может иметь вид строки, которую можно набрать на клавиатуре (т.е. состоять из ASCII-символов с кодами от 33 до 126), но об этом немного позже.

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

Прочтите внимательно эту статью, если вы применяете упрощенную систему налогообложения с объектом налогообложения «доход» по ставке 6 процентов и продаете игры или приложения в Google Play, Apple App Store, а также прочий цифровой контент — например, 3D-модели — в Steam, Unity Asset Store или на других площадках, в условиях договоров с которыми фигурируют комиссии, агентские вознаграждения и прочие формы разделения выручки между сторонами.

Из материала вы узнаете:

• Почему разработчику желательно обладать хотя бы базовой юридической грамотностью
• Чем с точки зрения Гражданского кодекса являются игры и приложения и какие права на них есть у разработчиков помимо авторского права
• Что такое агентский договор и почему все это важно при работе по договору с Apple или Google
• Кто такой налоговый суслик и почему он может превратиться в пушного зверя
• Какой «подвох» существует для применяющих «упрощенку» в части определения налоговой базы
• Почему налог на добавленную стоимость (НДС) продолжает преследовать нас, даже когда мы не являемся его плательщиками
• Как, с точки зрения Федеральной налоговой службы, облагаются НДС внутриигровые покупки (InApp Purchases)

8 лет назад маленькая команда разработчиков, почти что бывшие студенты, решили сделать свою первую большую, как им тогда казалось, игру. Они выполняли все функции вперемешку. И гейм-дизайн, и программирование, и арт. Кто что умел. Получившаяся игра называлась «Возмездие». Это была браузерка. Она показала неплохие результаты: доходы с игры выросли от нескольких десятков до сотен тысяч рублей за первые месяцы. Для группы в несколько человек это уже какие-то деньги. В таком режиме игра просуществовала порядка года. А потом аудитория стала уменьшаться, доход начал падать. Разработчики подумали: «Наверное, мало контента». Игра была контентнозависимой, т.е. постоянно жила на обновлениях. Они поднажали, стали производить больше локаций, предметов, уровней, ремесленнических рецептов — всё, что делали раньше. Но пользователи все равно продолжали уходить. И было непонятно, почему это происходит. В итоге проект, просуществовав три года, закрылся — рано или поздно такой конец ждет все онлайн-игры.


^{Арт персонажа браузерной игры Возмездие}

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

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

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

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

• Asana
• Trello
• SmartSheet
• Мегаплан
• JIRA
• Clarizen

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

В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].

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

Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии :)

Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)

Одна из наиболее популярных идей, появившаяся в индустрии разработки в последние годы, — это концепция Minimum Viable Product, сокращенно MVP. В двух словах, это стратегия разработки минимального по функциональности продукта, позволяющего получить обратную связь от пользователей. Но можно ли переносить эту концепцию в сферу мобильных приложений и если нет, то есть ли альтернатива? Мы в Alconost перевели отличную статью, отвечающую на этот вопрос. Всем, кто имеет дело с мобильной разработкой — читать обязательно.

Всем привет! Меня зовут Сергей Макеев, и я технический директор в проекте Skyforge в команде Allods Team, игровой студии Mail.Ru Group. Мне хотелось бы рассказать про технологии рендеринга, которые мы используем для создания графики в Skyforge. Расскажу немного о задачах, которые стояли перед нами при разработке Skyforge с точки зрения программиста. У нас свой собственный движок. Разрабатывать свою технологию дорого и сложно, но дело в том, что на момент запуска игры (три года назад) не было технологии, которая могла бы удовлетворить всем нашим запросам. И нам пришлось самим создать движок с нуля.

Мы хотим поделиться своим опытом доработки Microsoft Project Server 2010 под специфические требования заказчика.

Данная статья может быть интересна как бизнес-пользователям, которые могут узнать о новых возможностях платформы применительно к собственной компании, так и техническим специалистам, которые могут подчерпнуть из статьи новые знания о методах доработки Microsoft Project Server 2010.

Небольшое введение

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

Информационная система управления проектной деятельностью в идеальном случае должна обеспечивать следующий функционал (далеко не полный, но, в общем, достаточный):

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

TL;DR: Работа с таймзонами — это боль и унижение. Никогда не работайте с таймзонами!

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

Эта статья — краткий пересказ невероятно интересного доклада Скотта Майерса для тех, у кого нет 70 минут на весь доклад, но есть 7 минут на основные тезисы.

Некоторые люди, которые не пишут на С++, а лишь слышали об этом языке, задаются вопросом: «Почему вообще кто-то пишет на C++?». Но есть люди, которые используют С++ каждый день, и вот эти люди задаются вопросом: «А действительно, почему я пишу на этом языке?».

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

Язык, который был бы получен в результате принятия всех предложений, выходил слишком сложным и тогда Бьёрн Страуструп сказал «А помните Ваза?». Никто, кроме людей из Швеции, не понял о чём речь. Ваза был огромным боевым кораблём, построенным в Швеции в 1625 году. Основным принципом постройки корабля было «А почему бы нам не добавить сюда ещё и вот такую фичу?». Многие из идей исходили непосредственно от короля, в частности он лично утверждал размеры корабля. Также на Ваза по указаниям свыше требовалось нацепить огромное количество элементов украшения, резьбы, большое количество пушек и т.д. А королю ведь не откажешь. Итог был закономерным — из-за ошибок в конструировании Ваза затонул в первом же рейсе, едва выйдя из бухты.

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

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

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

Как то я слушал подкаст, в котором вскользь говорилось о написании шейдера для жука (25 минута, 35 секунда), имитирующего радужную поверхность (не знаю как сказать это по-русски, но в английском языке есть термин — iridescence). Я посмотрел этого персонажа и мне захотелось написать свой шейдер, но имитирующий более реальную поверхность хитина, о нем я расскажу в следующей статье.
Однако возникла проблема — у меня не было подходящей модели жука.