?

Log in

Electric Café

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

July 30th, 2016


11:43 pm - lytdybr
Снова делаю перевязку собаке. Лангета, бинты, подвязывание лапы, все дела. Муторно это. А инженерная интуиция говорит, что если бы спецы-ветеринары немного задумались и вспомнили, в каком веке живут, то ситуацию можно было бы свести к настолько же трёхкопеечным, но на порядок более удобным в сопровождении и комфортным для собаки решениям. Вот просто по уровню сегодняшнего дня, не залезая в светлое будущее 3D-печати и прочих пока непривычных технологий. Может где-то так и есть, в вип-клиниках далёких городов при сверхнаценках в десятки раз. Но не там, где мне сейчас нужно.

(7 comments | Leave a comment)

June 20th, 2016


01:22 am - Про "ботаников" и информационные системы
Попалось мне как-то видео https://www.youtube.com/watch?v=Fn6_DhWvvvg - решил посмотреть, у интервьюируемого знакомое имя, но не помнил откуда. В процессе вспомнил когда-то прочитанную "И ботаники делают бизнес" Максима Котина. Там про то, как Фёдор Овчинников старый бизнес делал. А в видео - про новый, сеть пиццерий.

И высказывается очевидная мысль, что процессы это софт. (Моё примечание: Ок, можно процессы не прописывать в софте, но будет дороже. Например, сейчас дешевле поставить в машину навигатор, чем обучить водителя карте местности.) Но внимания теме "процессы это софт" Фёдор явно уделяет больше, чем иные предприниматели и менеджеры. Считает это важной половинкой бизнеса, тратит значительные ресурсы.

Как они делают информационную систему - рассказывается во многих статьях. Например:
http://sila-uma.ru/2015/09/03/soft-menyaet-zhizn/
http://sila-uma.ru/2015/11/11/dodo-is-oktyabr-2015-2/

В общем, и 100500 одноразовых формочек, и "китайская классификация животных по Борхесу" во все поля. Плюс срачи в комментариях "ну как можно так делать, переписывать же всё придётся".

Однако. Да, такие вопросы надо решать меньшим количеством людей и более адекватным ситуации технологическим стеком. Но многое пришлось бы переписывать в любом случае, даже после хардкорных профессионалов или решений на сторонних ERP. Потому что exploratory programming, сами процессы ещё только создаются, UI-решения подбираются. Это не система, это прототип. И только с какого-то уровня maturity процессов можно сформировать требования для стабильной информационной системы и создать её. Придёт время - сделают. С нуля или на базе чего-то. А процессы есть прямо сейчас. И оптимизировать их при переносе в новую систему на порядок проще, чем создать или извлечь из неформальных источников.

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

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

(41 comments | Leave a comment)

June 15th, 2016


04:03 pm - Мысли вслух


Из всех профессий от современного прогресса в области AI больше всего пострадают некоторые дизайнерские. Для "нарисовать любимую собачку в стиле Ван Гога" достаточно нейросетки. В общем, где типовые требования и уникальный контент.

Пример: http://blog.deepart.io/2016/06/04/color-independent-style-transfer/

А вот программистам, даже основной тупой массе, замена на AI не грозит. Потому что большинство задач "интеграции с говном и торфом" суть типовой контент, но уникальные требования. Здесь речь только о замене на специалистов с более продвинутым (как по UI, так и по AI) инструментарием.

(28 comments | Leave a comment)

June 1st, 2016


09:29 pm - Откуда берутся эксперты
Когда-то я затрагивал тему врождённых и приобретённых талантов в http://justy-tylor.livejournal.com/242968.html

А сейчас, пролистывая ленту по возвращению из Японии, наткнулся на пост "Про гениальность и способность к обучению" - http://mr-bison.livejournal.com/424063.html

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

(27 comments | Leave a comment)

May 16th, 2016


03:45 am - дыбр
Хотел развить языковую (и когнитивную) тему в постах, но пока всё в черновиках, замотался с делами. Сегодня вылетаю в Японию, за вдохновением для жизни, творчества и всего такого. Продолжу через пару недель.

(1 comment | Leave a comment)

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)

> previous 10 entries
> Go to Top
LiveJournal.com