#текучка
Регата на корпоративе заказчика. Супер. :)

Субботний пост про книжки собрал 907 просмотров 23 лайка и 90 шар. Самый мой успешный пост в блоге. :) Образование и научпоп не мой профиль конечно. Но если будет что-то интересное, что сказать, то буду писать.

#экология #бутылочное_горлышко
В комментариях про бутылочные горлышки напомнили про экологию (в научном смысле этого слова). А там все основано на лимитирующих факторах.

"Закон ограничивающего (лимитирующего) фактора, или Закон минимума Либиха — один из фундаментальных законов в экологии, гласящий, что наиболее значим для организма тот фактор, который более всего отклоняется от оптимального его значения." Вики.
"Закон толерантности Шелфорда — закон, согласно которому существование вида определяется лимитирующими факторами, находящимися не только в минимуме, но и в максимуме. Дополняет закон минимума Либиха, где речь лишь о минимуме." Вики.

Вот еще ссылку приложил. Спасибо )
https://deep-econom.livejournal.com/89601.html

От себя добавлю, что экология на мой взгляд очень дает очень много интересных примеров для бизнеса. Буду писать про интересные примеры.
Навскидку вспоминается, что Co2 это лимитирующий фактор роста растений и с увеличением его растет и биопродуктивность и объем биосферы. Это и про накормить голодных и про дикую природу.

А с лимитирующим фактором в максимуме вспоминается классическая константа уровня спирта в 12%, при котором бактерии перестают размножаться :)

Выступил в Московской торговой промышленной палате на круглом столе гильдии логистики. В целом было интересно. Интересные люди и новые контакты получил, ура.

#экология #бутылочное_горлышко
Один из интересных лимитирующих факторов в природе это растворенное в океане железо. Железо в воде плохо растворяется и его там очень мало. Грубо говоря в половине океана железо является лимитирующим фактором.
В планктоне океана есть разные микроэлементы которые находятся в пропорции Редфилда C:N:P:F 106:16:1:0.1-0.001
микробам нужно чуть чуть азота и фосфора и совсем немного железа.

Но при этом железа в воде обычно очень мало! То есть для океана железо это очень мощное удобрение. В 10-1000 раз более сильное чем фосфорное.

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

Один человек Джорж Расс несколько лет назад устроил незаконный эксперимент по терраформингу земли.

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

#новость
Нашли алмаз размера 2500 карат, второй по размеру в мире, и самый крупный в данный момент.

https://www.rbc.ru/rbcfreenews/66c704189a79471048b06fa4?from=from_main_12

Из России мы таких новостей кстати не услышим. Потому что например на алмазном ГОК в Мире стоит такая щель, чтобы разламывать руду в довольно мелкий калибр. В результате в руде становятся видны (открываются) мелкие бриллианты, но бриллианты больше 1000 карат разламываются. Подсчитали, оказывается так выгодней.

Небольшая текучка.
#текучка #итоги

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

Набрал 3 сотрудников. Думал, двух но решил сотрудников много не бывает и взял еще одного. Наверняка же кто-то отвалится. Когда текущих переварим и выстроим процесс, то возможно еще одного возьму.

Запустил в работу 3 новых проекта и третий на подходе. К счастью небольшие.
Один связан с генерацией текстов на ЛЛМ, один классическая оптимизация работы сотрудников и их маршрутизация, третий сделать план продаж, повторный заказ.

При этом это все на фоне что у нас есть большой проект, который мы продолжаем пилить, и куда бросаем основные силы.

#команда #мысль

В процессе найма определяюсь, что должен знать сеньор и должен способен осознать рано или поздно джун или миддл разработчик. Нашел несколько вещей.
1. Машина состояний. Должен понимать, что это и применять на практике. Например для точного описания флагов запуска сложной программы и состояния в котором программа находится.
2. Закон протечки абстракций. Чтобы не городили ООП не понимая.

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

Метод пристального вглядывания.
#программирование #отладка #мысль

Только что исправил баг, заметив что у одного прямоугольника, который толще чем нужно, ширина ровно 3 метра. Проверили и правда стояло ограничение, которое вообще имеет смысл, но в данном случае было неуместно.
Ура.

Это метод ненадежный, но иногда сильно сокращает время. По плану этот баг мы бы убили за полдня, и никак не могли собраться это сделать.

Есть проактивный метод поиска таких багов. У меня в программе часто бывают числовые константы типа 100000. Теперь я стал делать все такие константы разными 100017 100023 и т.п. В результате если в решении всплывает такое странно число, я сразу знаю откуда ноги растут. Надо стараться делать все константы чуть чуть разными чтобы узнавать их в лицо.

Бережливое производство.
#мысль #бутылочное_горлышко

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

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

Для такой равномерной работы я применяю принцип который я условно называю заглушечное програмирование.
Идея в том, чтобы в каждый момент времени была работающая программа. Понятно, что по началу это будет просто одна заглушка. Даже Hello world.
Потом мы эту заглушку усложняем, то есть делаем хорошо очерченную небольшую задачу (от-SMART-ованную). Дыра , которую закрывала заглушка, при этом превращается в несколько более мелких дыр.

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

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

Минусы подхода - приходится больше думать, планировать и переключаться.

Ораторское искусство, ключевые задачи и KPI.
#бутылочное_горлышко #kpi #история

Стал читать несколько лет назад Тита Ливия про историю Древнего Рима, чтобы понять, что там в оригинале, а что уже переосмыслено в общей культуре. Ну и вообще "все мальчики хотя бы раз в день думают о Римской империи". Реально оказалось полезно.

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

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

2. Враг нас боится, главное его побыстрее сломить, венок тому коннику (патрицию), кто первый добудет флаг врага.

3. Мы долго воевали, и мы знаем, что пехота (плебеи) сильно устала и не успела заниматься хозяйством (обеднела). Удвоенная доля добычи пехоте.

4. Этот город нас предавал, лишний день на разграбление.


Оказывается, ораторское искусство это не про то, чтобы красиво говорить, а про то, чтобы говорить точно и правильно ставить задачу.
Логично, но неожиданно.

По сути, это соответствует «формуле изобретения» в заявке, или «описании стартапа в одной строке» или просто постановке задачи.

#ии #кейс
Я форсирую, чтобы народ максимально использовал chat боты в работе.
А они пользуются редко, да и я сам не часто. Выявили два критерия, которые мешают:

1. Проверяемость задачи.
Задачи для чатбота должны быть хоть и простенькими, но еще легче проверяться.
Например человек просил написать набор линейных ограничений чтобы если есть 3 дискретные переменные x1 x2 x3 то надо сделать так, чтобы переменная y была равна 1 если хотя бы одна из x1, x2,x3 равна одному.
Чат-бот радостно делает очень похожие но не верные варианты.
Тут я посоветовал сразу же просить сделать таблицу истинности для задачи и для решения, которое предлагает сам чат бот. По такой табличке проверить будет уже гораздо легче.



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

Степень использования чатбота это просто уровень умения ставить задачи, то есть уровень программиста.


P.S. Кстати такая несимметричность - проверить проще чем сделать штука интересная и проявляется в других сферах жизни. В математике соответствует NP-полноте, а в жизни искусству.

#выступление
Попросили выступить для NoML community @noml_community. 9 октября буду выступать рассказывать про алгоритм огранки бриллиантов. Чего-то теряются записи выступлений, там по идее останется. Выложу позже сюда.

#текучка
Перешел на работу по тикетам, даже в мелких проектах. Формально, чтобы навести порядок, что очень полезно. А на самом деле ради кайфа, когда ты тикет закрываешь.😍

Автоматизированные тесты пока в только крупных проектах. Но тоже надо бы :)

Про протечку абстракций и високосную секунду.
#история
Недавно писал про протечку абстракций. Напишу одну прохладную историю о протечке, которая случилась в моем прошлом стартапе.

Мы делали систему расписаний для пилотов авиакомпаний, с парком порядка 10-20-50 самолетов.
Система вполне хорошо работала для 10-20 самолетов (это где то 300-500 пилотов и до тысячи бортпроводников).

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

В итоге мы созрели и стали переходить на pypy то есть на компилированный питон. Для этого надо было, чтобы все модули компилировались на pypy. Мы заменили все неподходящие модули кроме одного – datetime. Оказалось, что он на pypy не компилируется. Хотя казалось бы, что сложного во времени. Стали разбираться и ужаснулись.

Не буду останавливаться на часовых поясах и на других очевидных сложностях, а просто поговорим о сутках и годе.
В юниксе время считается количеством секунд от 1970 года до текущего момента. Например, 12 сентября 2024 года 10:00 это 1726124400 секунда. И чтобы перегонять время туда-сюда, надо знать и все високосные дни с 1970 года.
Все знают про високосные дни и про отличия Юлианского и Григорианского календарей. В Юлианском календаре високосный год был каждые 4 года.
В Григорианском високосный год каждые 4 года, но пропускается каждые сто лет, но делается каждые 400 лет. То есть в 1900 был обычный год, а в 1996 и 2000 високосные.
За пару тысяч лет разница набежала в 2 недели. Юлианский всё-таки неточный.
Для современных нужд уже григорианский недостаточно точен. Поэтому помимо високосных дней ввели, так же високосные секунды. Они добавляются с 1972 30 июня или 31 декабря.
Так что теперь не только в сутках бывает не 24 часа, но и в минуте может быть не 60 секунд. Это значительно усложняет код и замедляет его работу.

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

Понятно, что это все создает сложности при создании модуля и синхронизации различных часов между собой. ГЛОНАСС когда-то от этого падал, GPS работает по своему времени, отличающемуся на 19 секунд и т.п.
А питон получил медленный и некомпилирующийся модуль datetime.
Мы пришли к выводу, что при необходимости мы сделаем свою версию этого модуля, где время будет загрублено до 5 минут (этого достаточно для наших нужд). После чего он и сам по себе станет быстрее работать и сможет компилироваться через pypy.
Крупных клиентов с живыми данными на горизонте не было, потому руки до этого не дошли, но мы были близки.

Вот такая протечка абстракций. Расчет расписания пилотов упирается в плохой прогноз землетрясений.

Добавлю, что тут видно, что моделей одного и того же явления может быть очень много, более или менее грубые причем в разных местах по-разному. Под каждую задачу есть своя модель, оптимальная с точки зрения точности там, где надо и грубости где не надо. Можно сделать время с точностью до микросекунд, но без часовых поясов. Можно с часовыми поясами, зимним временем, но с точностью до 5 минут. И все будет полезно на своем месте

Пара клиентов.
#бизнес #размышления

Одному сделали два проекта. Денег еще не видели, я начал делать проекты раньше заключения договора (потому что срочно). В договоре были пункты, по которым я денег вообще могу не увидеть. Если в первом еще могут быть претензии, то по второму я четко и быстро сделал все что нужно. Теперь жду денег.

Второй клиент предложил оплатить этап до его формального окончания. Очень в кассу.

Я бизнес учусь только делать, ошибки делаю, но за то них лучше всего учишься.
Вот выводы которые зашли в результате не только в голову но и в душу.

1. Торопиться и работать без договора я больше не буду.
2. Надо внимательно следить за репутацией клиента. Репутация первого клиента была мне известна.
3. Как проводить ABC сегментацию клиентов тоже понятно.

У нас неделя искусственного интеллекта.
#текучка #ии

Во-первых, стартовал микропроект с использованием ИИ. До этого мы только ТЗ формировали и проекты ждут в очереди. Но скоро таких проектов будет больше.

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

Язык R очень удобная штука. Задачи которые на нем надо решать понятны как и методы. А сам язык незнаком. В результате удобней писать запросы в чат бот, час писать код самому. И я так освоил чат бот и вот сотрудник пошел. А сейчас я и на питоне активно уже использую ИИ.

#мысль #ии
Заказчики попросили посмотреть один проект, работает или нет. Результатов еще не увидел но и так понятно, что не сработает. Просто потому что задача в проекте решается неверным способом.
Там просто спрашивают чатбот: отсортируй некоторый список по критерию важно/не важно. При этом обучающая выборка не передана, то есть критерии что именно важно или не важно чат бот просто не знает.
Да и если передавать, там чат бот будет лишним звеном излучающим шум. Лучше бы просто статистическую модель запилили. Две ключевые ошибки.

Под каждую задачу надо сначала понять, каким методом её делать.

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

#текучка #бизнес #размышления
Успешно развиваем проект по недвижимости. Во первых алгоритм работает и считает, а во вторых подтверждается ценность проекта для потенциальных клиентов. Ура!

Анализировал свою ценность в проекте. И она получается вообще не связана с объемом работ, которые я делаю. И даже наоборот есть обратная корреляция. То есть, самое ценное, что я делаю - понимаю каким путем идти и время от времени придумываю хорошие идеи (или подхватываю предложенные хорошие идеи других).
Штука рандомная, но важная.
Надо будет думать, как в других проектах с учетом этого выставлять и объяснять стоимость работ.
Видимо, надо просто брать какую-то величину на моё кураторство в проекте просто ни почему. Размер этой доли должен зависеть от объема исследовательской составляющей в проекте.