?

Log in

Electric Café

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

September 13th, 2016


12:35 am - Kibana
После упоминания фишечек Wireshark ( http://justy-tylor.livejournal.com/249105.html ) мне намекнули, что некоторое подобие Apply as Column есть в Kibana. И таки есть. Вообще интересная штука, учитывая универсальность на уровне "показывает любые данные, впихуемые в ElasticSearch".

Хотя вместо самобытности с inline detail сразу захотелось нормальной пары вьюх main+detail. А ещё поддержки SQL (вроде есть в каком-то форке) и кнопочки Edit (увы, просрана by design).

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

(Leave a comment)

September 4th, 2016


10:14 pm - И ещё об искусстве
Продолжая тему http://justy-tylor.livejournal.com/247653.html

В то время, как стихает хайп на тему "AI, рисующих картину по фото", появляется всё больше видео в подобной стилистике. Например:

NYC FLOW from Danil Krivoruchko on Vimeo.

Вангую, что когда допилят VR/AR, то пойдёт волна сверххипстерских приложений "Сделайте свою жизнь живописной!"

(16 comments | Leave a comment)

September 3rd, 2016


09:51 pm - Правильные кусочки мозаики
Недавно пришлось воспользоваться Wireshark. Инструмент такой, для наблюдения за передаваемыми по сети пакетами и их содержимым. И... Он клёвый. Даже не в смысле отладки сети, которая мне обычно не требуется, а по общим фичам.

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

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

Ну, только пока я таких возможностей не встречал. Ни для общих инструментов работы с логами, ни для бизнес-данных. А в Wireshark есть. И это приятно. Потому что во всём остальном тоже когда-нибудь будут. Может даже сам куда-то добавлю. :)

(5 comments | Leave a comment)

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)

> previous 10 entries
> Go to Top
LiveJournal.com