?

Log in

Electric Café

> Recent Entries
> Archive
> Friends
> Profile
> previous 10 entries
> next 10 entries

May 11th, 2016


04:34 pm - Об универсальных языках программирования/моделирования 2
По мотивам предыдущего поста меня спросили в личке, типа чем так плох XML и ручные конфиги на нём. Раскрываю тему.

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

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

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

Именно поэтому универсальный язык должен поддерживать в качестве таргетов произвольные форматы и представления, а не только "код".

(15 comments | Leave a comment)

02:34 am - Об универсальных языках программирования/моделирования 1
В начале века я ещё считал, что прогресс технологий работы с информацией сильно сдерживается существующими языками программирования, но достаточно заменить C++ чем-то более развитым по части функциональщины и метапрограммирования (но сохраняющим возможность генерации оптимального нативного кода), чтобы стало легко и удобно разрабатывать продукты любой сложности, уделяя внимание только проблемам предметной области, но не ограничениям предыдущего поколения инструментов. Был юный и тупой.

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

Можно сделать язык с полноценной реализацией pattern matching (а не как принято сейчас). С паттернами и комбинаторами в качестве первоклассных сущностей языка. И это уже польза. Однако.

Для определённых типов данных эффективнее создание индексов вместо полного перебора веток. Появляется выбор, либо через удобный pattern matching, либо через ручное решение с индексами. Ложный выбор. Средства метапрограммирования языка должны позволять создание подобных индексов в pattern matching, сочетая удобство написания и эффективность работы. И это ещё полезнее. Однако.

В реальном мире код работает не только с разными видами процессоров, памяти и периферии. Код работает с другим кодом. И существует множество информационных систем, где, например, выражения из паттернов/комбинаторов для регистрации на какие-то события указываются через XML-конфиг, а потом придумываются дублируемые идентификаторы, связывающие их с неким исполняемым кодом (часто тоже не нативным). И да, люди, создающие системы с ручным редактированием XML, достойны перерождения в виде жаб в Бангалоре. Но это не отменяет необходимости интеграции с такими системами. И здесь даже нет выбора. Только через конфиг. Хотя... Ведь и его можно сгенерировать. Ещё одна возможность трансляции pattern matching: что слева - в конфиг, что справа - в код.

То есть, язык, решающий проблемы разработки, должен решать проблемы интеграции. Поддерживать в процессе компиляции как пользовательские compile-time алгоритмы, так и описания таргетов из пользовательских библиотек. Здесь конфиг, там HTML, а кому-то вообще кусочек COBOL на мейнфрейм сгенерировать надо.

Но зачем тогда вообще писать что-то на COBOL (Java, C++, SQL, XML, bash, make, whatever...), если это можно сгенерировать из единой исполняемой спецификации, гарантируя отсутствие расхождений на стыках языков? Да, всё так, они оказываются лишь артефактами старых систем. Настоящий язык программирования должен быть универсальным, и заменить сразу все неуниверсальные. Что не значит, что он будет единственным (таким). Будут и другие универсальные, возможно (точнее: когда-то) лучше.

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

(60 comments | Leave a comment)

May 8th, 2016


12:19 am - О методиках ведения проектов
В лентах опять сравнивают мифический Waterfall, когда-то модные стыд-и-скрам и прочее. А мне на эту тему метафора вспомнилась.

Ну вот едете вы на машине по трассе. Просто вперёд, подстраивая режим под ситуацию.

А в городе - светофор, поворот, светофор, и на навигаторе пробочки посмотреть.

А в селе Гадюкино - аккуратно, желательно на внедорожнике. Или на тракторе.

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

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

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

(12 comments | Leave a comment)

April 1st, 2016


12:06 am - О закупках рекламы
Gabe Leydon интересно разбирает тему закупок рекламы в разных медиа: Watch Machine Zone’s CEO freak out a room of media people — full interview Code/Media 2016

Что осталось за кадром: Гейб декларирует, что реклама на телевидении это наименее выгодный вариант из всех традиционных способов. Однако, Machine Zone запускала рекламную кампанию в трансляциях Суперкубка - огромная аудитория, но миллионы долларов за каждый показ. Взаимоисключающие параграфы? Нет. Это способ быстро прокачать действующую "узнаваемость бренда". Не как у старых компаний, где эта "узнаваемость" обеспечена ещё десятилетия назад, а сейчас все деньги на неё уходят в чёрную дыру, а в более практическом смысле. Повысить конверсию. Чтобы когда массовый пользователь видит настоящий call to action (будь то хоть баннер на фейсбуке), он уже представлял себе что-то солидное, попадающее в его ценности, а не "игрушки там какие-то, наверное китайские". И использование Суперкубка в этом смысле даёт максимальный охват целевой аудитории, с эффектом одновременного воздействия. Как-то так.

(1 comment | Leave a comment)

March 30th, 2016


06:32 am - Нам с тобой
Когда-то я впервые услышал группу "Кино". Школьник, во втором классе. У Вовки был двухкассетник, он сделал копию. И для меня это было открытием. Что в текстах песен может быть смысл. А потом умер Виктор Цой, и вышел последний альбом. "Чёрный альбом". И мы его слушали. И даже что-то понимали.

Прошли годы. Я влюбился в одну девушку. Сильнее чем до этого, сильнее чем после. И я слушал... разную музыку. Что-то было связано со сменой работы, личными стремлениями. Но часто звучала эта песня, "Нам с тобой". И девушка пришла. А потом ушла. Тогда я понял, что творчество "Кино" и Цоя это такая странная штука, которую можно слушать и когда тебе хорошо, и когда тебе очень-очень-совсем плохо. (А слушать тех же Депешей в подобной ситуации это песец-песец).

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

Эту версию я не слышал раньше. Не лучше, не хуже. Просто, она есть.


Кино - "Нам с тобой", черновой вариант

(Leave a comment)

March 24th, 2016


02:14 pm - О программистах
Сейчас смотрел видео Jonathan Blow ( https://www.youtube.com/watch?v=k56wra39lwA ), где он заслуженно критикует коллективы разработчиков твиттеров/фейсбуков за то, что они буквально не умеют программировать (в общей массе). Ну, как бы странно. В соцсеточках, где бешеные бабки, не умеют, а в геймдеве, где специалистам бабла меньше, таки умеют. Однако если сравнить то, что показывали игровые движки на железе двадцатилетней давности, с сегодняшним вебом, то очевидно, что таки да, в вебе не умеют. Более того, древняя игрушка внутри браузера (через эмулятор на тормозном JavaScript) может показать лучший фреймрейт, чем страничка традиционного оппа-говносайта.

Оно так исторически сложилось. Но надо понимать причины. А причина одна: минимальные условия работоспособности продукта.

Чтобы игра работала - надо рисовать только то, что видит игрок. Причём, в оптимальной последовательности. Бросил на отрисовку весь уровень - всё сдохло, нет игры.

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

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

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

Есть люди, у которых своя система ценностей, и им западло делать плохо. В любой нише. Но большинство делает "как принято", по минимуму. И в геймдеве эта планка минимума задрана высоко. Чтобы хотя бы работало - надо очень постараться с движком. А в вебе - каждый первый дебил на пыхе пишет свой креатив и... оно плохо работает. Но работает. Тупит, тормозит, сжирает память и батарейку вашего планшета. Но в браузер заложено 100500 костылей, благодаря которым _это_ всё ещё продолжает работать.

Это как разные школы. Если в геймдеве за "2+2=5" оставляют на второй год, то в вебе говорят "это шедевр" ( https://www.youtube.com/watch?v=8Hdetk98L-U ) и дают юродивому конфетку.

А дальше удивляться нечему. Что выросло, то выросло.

(38 comments | Leave a comment)

March 20th, 2016


11:09 pm - Роботы
В чатике кинули ссылку на http://www.cnbc.com/2016/03/16/could-you-fall-in-love-with-this-robot.html - сегодняшнее состояние технологий "человекоподобия" в робототехнике. Там интересное видео вначале статьи.

Ещё раз упоминают, что для восприятия важны мимика и контакт глазами. А мне вспоминается начало двухтысячных, когда эти же факторы значительно сильнее продвинули реалистичность NPC в видеоиграх, чем количество полигонов.

(2 comments | Leave a comment)

March 10th, 2016


05:35 pm - Coroutines в C++
Тут в стандарт C++ пытаются пропихнуть coroutines. Что само по себе правильно, но относительно предлагаемой реализации идут споры.

Различные papers не раскрывают полную картину (а особенно "нафига именно так"), но для этого есть видео вроде https://www.youtube.com/watch?v=_fu0gx-xseY

В общем, предлагаемое решение это существенный прогресс относительно других недавних реализаций (C#, Python, Go, ...). Однако, есть свои недоработки. Вызванные, в первую очередь, именно ориентацией на допиливание популярных решений.

Прежде всего, зачем вообще нужны coroutines? Для удобства написания останавливаемых-и-возобновляемых вычислений как непрерывных.

Для вычислительных задач предлагаемая в C++ реализация (как и другие упомянутые выше решения) такого удобства не предоставляет. Да, ручное прошивание кода лапшой из await выглядит более сахарно, чем прошивание такой же лапшой из .then(some closure), но это снова ситуация, когда программист вынужден выполнять работу вместо компилятора. А в C++ возможностей системы типов достаточно для того, чтобы обойтись без await.

А для задач моделирования каких-либо процессов все эти реализации просто непригодны. Так как не поддерживают необходимую сериализацию coroutines.

В общем, стандартизировать недоделки глупо. С другой стороны, это же C++, не пофиг ли?

(22 comments | Leave a comment)

February 10th, 2016


07:19 am - Lumberyard
Амазон выпустил свой кроссплатформенный игровой движок Lumberyard, созданный на базе CryEngine. Сорцы прилагаются.

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

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

Раздача технологий для продвижения сервиса - вполне в духе сегодняшних тенденций.

(4 comments | Leave a comment)

January 7th, 2016


01:10 am - Зачем продукту экосистема
Многие программные продукты/сервисы при хорошей идее (и достаточно приличной реализации) остаются недостаточно популярны и даже недостаточно понятны в своей нише. Типичный пример - Podio (обсуждалось в http://justy-tylor.livejournal.com/243549.html). Почему это так?

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

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

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

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

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

Когда-то платформа 1С отхватила львиную долю рынка продуктов автоматизации бухгалтерии исключительно за счёт партнёрской сети. Это позволило предоставить услуги настройки и внедрения продукта даже там, где создание собственного филиала было экономически нецелесообразным. Развитие партнёрской сети это один из возможных путей. Но появились и новые. Например, консалтинг в варианте "скайп и командировки". Причём, если все данные расположены в сервисе, а археологических раскопок в предыдущих информационных системах клиента не требуется, то количество командировок может быть сведено к нулю.

В общем, кто-то думает про технологии, кто-то про продукты, кто-то понимает фишку "продукт+реклама", но в ряде случаев и этого недостаточно. Потому что предметка сложная. И нужна связка "продукт+реклама+экосистема".

(14 comments | Leave a comment)

> previous 10 entries
> next 10 entries
> Go to Top
LiveJournal.com