По следам треда: Python Shared Objects
Поскольку в прошлом треде все рискнувшие пройти по ссылке заснули на половине статьи, то я решил написать статью в 3 раза короче про совсем общие принципы, лишь отдаленно относящиеся к PSO:
https://habr.com/en/post/587750/ — Многозадачность и многопоточность — распространенные заблуждения и недопонимания
Начал плотно мониторить рынок труда
Макака ищет работу, C, Python, JS, либо челендж в опенсорсе на C++
и у меня обострилось довольно странная догадка, которая была и раньше, но сейчас прям очень режет глаз. А именно: откуда сейчас происходит такое странное искажение спроса на спецов в IT? Каждая третья-четвертая вакансия — блокчейны. Или просто очередные старпаты на реакте с микросервисами на ноде или Go. Ну вы же не хотите мне сказать, что получаемый продукт кому-то даст хотя бы доллар прибыли? Потому что я не поверю.
Второй интересный факт, который мозолит глаз — это требования в специализации на штатовском рынке намного выше. Работая в очень-очень узкой нише в штатах можно по прежнему иметь большой рыночек, чуть ли не плана «специалист по async/await в JavaScript» — и все уже к этому привыкли. То есть, фактически в вакансиях это проявляется в виде экзотики в разделе «hard skills», названия которой я первый раз в жизни вижу. Эта закономерность имеется и в СНГ, но в штатах она достигла каких-то фантастических масштабов. Грубо говоря, от соискателя будет требоваться три года опыта разработки на каком-нибудь фреймворке, который два года назад релизнулся. А вот надо было сразу с бета-версий осваивать его, тогда был бы востребованным спецом.
Пока что цепочка видится такая: ФРС и банки генерят деньги, деньги самыми разными путями попадают к «инвесторам» (что-то близкое к понятию «инвестор в МММ»), инвесторов окучивают аккуратно одетые мальчики и девочки с поставленной речью, выдающими базворды через слово, что-то про «проверенные решения», «перспективные платежные средства», «занять место на растущем рынке», «мотивированная команда, жаждущая постоянного роста своей квалификации», и так далее. Раньше для того, чтобы доказать, что «эти слова не пусты», садились имитаторы программиста в опенспейс офис. Даже если они не профессиональные имитаторы — все равно будут исполняющими обязанности, потому что в опенспейсе эффективный кодинг невозможен в принципе. Как сейчас организаторы пузырей убеждают инвесторов отдать деньги — понятия не имею, предлагайте ваши варианты.
Какие вы можете назвать революционные технологии ПО, созданные в последние 20 лет? (комментарий)
Я в данный момент наблюдаю стартапы только для отмывания денег или для игр инвесторов в финансовые пирамиды.
Но самая интересная моя догадка касается того, что вектор целей этих пузырей и даже не совсем пузырей косвенно управляются забавными механизмами. Как то банальный кредитный рейтинг, который диктует очень простую вещь: если твои партнеры являются российской фирмой, то рейтинг ты получишь низкий, и кредиты под свой пузырь ты получишь с большим процентом. Сей инсайт позволил мне понять странный наблюденный мной феномен, а именно — в компании все программисты сидят в россии/СНГ, но почему-то офис находится в штатах/бриташке/гонконге. При том, что он там никому не нужен и никакие заказчики туда не приходят, тем более в короновирусную эпоху. Почему об этом так мало рассказывают? В интернетах мало людей, которых хотя бы просто интересуют вопросы бизнеса с прямой работой на забугорных заказчиков?
PS: поднял архивы с другого компа и нашел сочные материалы с http://labor-union.wikia.com/ (оригинальный сайт удален):
Работающая бедность в РФ
Lifehacks
Лайфхаки для выживания в РФ
Вот такой контент я бы читал в интернетах днями и начами. Жалко, что к создателю сайта (keinkeinkein) в Воронеж пришли правильные люди, и вежливо попросили удалить под ноль все материалы.
inb4: при чем тут это к линю и опенсорсу? Это очень глупый вопрос, потому что в 2021 весь ваш опенсорс находится в рабстве забугорных корпораций, ваш GPL софт используют в коммерческих целях, а модифицированные сорцы никто отдавать обратно не собирается. Потому что SaaS, тотальная централизация и прекращение разработки оффлайнового софта. Когда я еще в 2008 году вкатывался в опенсорс, я бы ни за что не догадался, что опенсорс станет таким.
10 лет в разработке, из опыта — GUI и веб-фронтэнд, UX, но не графический дизайн, СУБД, опыт разработки больших распределенных и многопоточных систем (си, паскаль), животное хорошо знакомо со внутренностями CPython, но бэк и машинное обучение на нем не писало. Когда-то разрабатывало контроллеры и аналоговую электронику, но нынче это никому не нужно, особенно на удаленке. Любит наукоемкие сферы, в частности математику, физику, химию.
Уверенный письменный английский, менее уверенный, но всё же разговорный английский.
Мой код вы можете заценить тут: https://github.com/byko3y/python-shared-objects
Зряплатные ожидания $4000-6000 за фултайм, но на очень сочные проекты возможны скидки. С радостью рассмотрю предложения part-time.
Бесплатно (или почти бесплатно) напишу фичу или исправлю годами висящий баг в более-менее известном опенсорс проекте на C++, если это теоретически выполнимо за несколько недель. Просьба не предлагать монстров, компилирующихся полдня, вроде Google Chrome. В крайнем случае Firefox, это верхняя граница.
Поскольку релиз пре-альфо-альфы моего проекта вызвал шквальный интерес, то почему бы мне не запостить результаты своих успехов на LOR.
https://github.com/byko3y/python-shared-objects - репушка
https://habr.com/en/post/585320/ - статья-обзор-бенчи (ахтунг, english).
https://www.reddit.com/r/Python/comments/qfdj8m/pso_easy_concurrency_with_pyt... — душный тред на reddit (тоже инглиш, внезапно)
Меня больше всего удивила не негативная реакция, нет, а тот факт, что мне даже никто не ответил в списках рассылки бидона. При том, что чел, который недавно просто выкинул GIL из питона (просто выкинул, почему бы и нет) и выложил свое творение, словил кучу ответов. Ну то есть ответы плана «откуда вас таких рожают? С 1999 года уже который раз выкидывают GIL, но ни к чему это не приводит». ХЗ, может центральные разработчики просто заняты очень важным обсуждением нового синтаксиса для ленивых параметров по умолчанию в PEP 671, и в поте лица пытаются выбрать между символом «=:» и «=>», но никак не получается. Люди работают, а я их тут отвлекаю.
Я давно выдвигал теорию, что разработка софта скатилась в говно. Современный кодер не разрабатывает новый софт — современный кодер только клеет существующий.
Интервал 20 лет выбран не случайно — последние прорывные P2P технологии массово создавались 20 лет назад (Chord, Kademlia, eDonkey, BitTorent).
Начну со своего варианта ответа: Bitcoin. Подавляющее большинство блокчейнов слизаны с битка почти один в один, кое-кто даже развил идею, но качественного скачка не смог сделать никто. К сожалению, больше ничего не вспоминается.
Сразу замечу, что «продавать настроенную инфраструктуру», оно же «облака» — это, мягко говоря, не новое решение. NoSQL СУБД — это шаг назад, с NoSQL БД начинались. Последние новые технологии искуственного интелекта появились в 90-х.
system-root заинтриговал, но ответов не дал. Лично в моих глазах это переводчик с офисно-рыночного языка на программистский, который не занимается техническими деталями, но расставляет приоритеты для конечных фич и сроков их реализации, а также разводит заказчика на даллары. Но мне кажется, что я действительно что-то упускаю.
Хороший манагер — что это за зверь, и чем он отличается от плохого манагера?
Прошлая серия:
Откуда растут ноги ненависти к php?
Я не знаю, есть ли где-то на планете второй такой поехавший, которому реально интересно понять, как инструменты разработки развивались и приобретали успех у простых смертных мартышек. Ну вот нравится мне собирать информацию, на которой невозможно заработать денег. Я пока что не встречал ни одного блогера, который подобный анализ произвел для веб-разработки в целом — а мне интересно.
Итак, что нового я откопал: WordPress, который изначально был CMS для создания бложиков в два клика, внезапно развился в целую платформу, и вот уже на нем клепают интернет-магазины — хотя затея эта, на мой взгляд, и провальная, ведь нагрузку WP абсолютно не держит, а ломают сайты на WP из-за уязвимостей плагинов на раз-два, только и успевай накатывать патчи в надежде, что сегодня взломают не тебя.
Давайте подумаем: а что же у нас до WordPress было инструментом для создания бложиков? Ну? Ну?
Идем далее:
https://www.djangoproject.com/weblog/2005/nov/16/firstrelease/ - Django 0.90
https://github.com/django/django/tree/ce079538c66d826be5f0c4260ab4405b7abcbed7 — примерное состояние сорцов перед релизом 0.90
Что представляла собой джанга на момент 2005 года? Платформа для создания CMS некоего регионального новостного сайта (история разработки) и блевотных бложиков, по сути стоящая на трех китах:
— шаблонизатор;
— ORM, поставляющий содержимое из баз данных в шаблонизатор и засовывающих их обратно в базу из форм;
— алгоритмы авторизации и админка для изменения содержимого бложика.
Вы уже снова узнали, что аналогичный инструмент до боли стар и хорошо нам всем знаком. Забавно, что в дичайшую нечитаемую лапшу джангу превратило уже сообщество — оригинальные сорцы имели зачатки лапши только в иерархии полей модели, где создатели почему-то решили логику отображения-контроллера полей в шаблоне (генерации HTML и валидации введенных полей, core/formfields.py) унаследовать от классов с алгоритмами доступа к БД (core/meta.py), в остальном это было простецкое наследование от template.Node (управляющие структуры шаблона) и meta.Model (абстрактной бессмысленной сущности для агрегации полей аля «таблица»), и даже было немало классов без базового класса. Итого 12 тысяч строк с комментами тогда, а сейчас в Django 300+ тысяч строк питона.
Вы уже поняли логику успеха? Делаем инструмент для создания говнобложиков в два клика — миллионы индусов кидаются писать на нем свои говноблоги — на рынке оказывается огромное число кодеров толка «я не умею в PHP, но могу сделать вам сайт на WordPress» или «питон? не, не умею; когда-то слышал про него, но толком не пытался изучить, я пока только на Django научился сайты писать».
С другой стороны — почему бы не позволить людям писать в два клика вебсайты на Go? Или на лиспе. Где там наш Пол Грэм со своим конструктором сайтов на лиспе? В конце-концов, я и другие программисты пишем программы именно для того, чтобы простой человек мог без напряга воспользоваться нашим софтом.
Интересно было бы услышать вашу аналитику о делах недавнего прошлого: Ruby on Rails? Symphony? Я вот пока не понял, почему Laravel нынче стал лидером среди других PHP фреймворков.
Давайте немножко побеседуем про новомодные low consistency poor availability системы, снискавшие популярность в последнее время.
Попытка заблокировать сервисы Google обернулась сбоем в работе систем Центробанка РФ (комментарий)
«интернет вояками планировался как отказоустойчивая сеть, но вебмакаки умудрились сделать из нее сильно связанный фарш, поздравляю, вы сломали чугунный шар»
Как мы все знаем, интернет разрабатывался, как отказоустойчивая система, которая функционирует до последнего узла. Как мы знаем, коммерсанту частенько есть что скрывать и не хочется зависеть от благого расположения Васи Пупкина, даже если Васю Пупкина зовут SAP, Oracle, IBM, или Microsoft. Так почему же люди покупают Office 365 и Dynamics 365 при том, что есть полностью оффлайн альтернативы? Если вы размещаетесь в России или Китае, покупаете продукт 365, а потом Роскомнадзоры или сам MS блокирует вам облако — вы остаетесь полностью в дерьме. Кто это покупает и что ими движет? Кто завязывает свой бизнес на Dynamics 365? Или на облачный Битрикс? Я не понимаю, предлагайте ваши вариант.
«Облака», в плане «привязан цепью к интернет-серверу», не новы, Самая отстойная копирастическая контора, Ubisoft, в свое время отличилась тем, что их uPlay при кратковременной потере интернет-соединения вываливал вас из ОФФЛАЙН игры. По сути, многие софтоделы ориентируются на облако просто для того, чтобы иметь больше возможностей струсить денег с потребителя. И даже несмотря на то, что теоретически возможность миграции предоставляет много кто — фактически эта миграция выйдет вам в копеечку и вы семь раз подумаете, прежде чем мигрировать.
Ладно, допустим, просто допустим, что таким образом некий Ерохин экономит время и деньги на установке и настройке оффлайнового софта, на организации своего сервера, к которому можно было бы получить доступ даже с мабилы (не спрашивайте меня, зачем с мобилы — я не понимаю). Давайте даже на минуту пофантазируем, что мы — технически грамотный разработчик, который желает приобщиться к потоку денег. Естественно, при этом мы желаем клиенту только добра. Железо дешевое, хостинг дешевый — давайте же сделаем бэк нашего продукта на большом-прибольшом числе серверов, да еще и в разных геолокациях, чтобы у нашего любимого клиента было меньше проблем со связью.
Но раскидать серваки по планете — это одно, а заставить их работать после этого вместе — это совершенно другого уровня задача. Как она обычно решается? Через базы данных, в число которых входят брокеры сообщений, вроде RabbitMQ. И здесь мы вступаем на тропу лютого треша, потому что проектировать и реализовывать распределенные системы и БД в частности на планете умеет человек двадцать, и скорее всего они работают не у вас, но спрос на них сильно больше, потому что другие «умники» уже давно витают в облаках и своих спецов не отдадут.
«Готовые решения всё порешают» — скажете вы? А знаете ли вы, что ZooKeeper — единственная распределенная СУБД, гарантирующая строгую согласованность данных при отказах? А знаете ли вы, что, даже несмотря на выдающиеся достижения, в ZooKeeper операция синхронизированного чтения нелинеаризуема, а потому часть вашего кластера может сидеть с тухлыми данными, не зная об этом? А знаете ли вы, что полностью исправный кластер Riak при интенсивных конфликтах обновлений теряет более половины этих обновлений на полностью исправном кластере? Даже при самых строгих настройках согласованности данных. Причем, таким ужасным Riak делать было не обязательно — на самом деле это спонсоры Riak и попросили сделать умолчательную конфигурацию такой ужасной.
Но как же так, мы же все давно знаем про Paxos, который еще триста лет назад позволял достигнуть консенсуса в распределенной системе с отказами узлов — почему же до сих пор в школе не преподают основы построения распределенных систем? Если мы возьмем тот же ZooKeeper, то мы увидим, что в случае отказа лидера кластеру требуется НЕСКОЛЬКО СЕКУНД на возобновление работы — это настоящая стоимость честного распределенного консенсуса, который у ZooKeeper при выборах лидера похож на Paxos. Для решения проблем дичайше медленного консенсуса и возникла идея выбора «эталонного сервера», лидера, мнение которого безоговорочно принимает весь кластер без затрат на спор между узлами.
Правда, этот подход все равно не сработает при достаточно частых сбоях с частыми потерями лидера. Более того, система на консенсусе полностью выйдет из строя при потере более половины узлов. Вы можете заметить, что согласно теореме говна-или-мочи достижима либо согласованность данных, либо доступность системы, либо в системе недопустимы отказы. Давайте пожертвует согласованностью ради доступности! Но беда мамкиных бигдатовцев заключается в том, что средняя система по больнице не обладает высокой доступностью и не обладает хорошими гарантиями согласованности. То есть, высокодоступная система готова работать 24/7 до первого отказа сервера или потери соединения с интернетом. Почему пришлось так делать? Потому что иначе будет высокая задержка ответа и/или большая нагрузка на каналы.
Возьмем среднюю бигдату в вакууме — GitLab:
https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-database-incident/
Пока бигдатовцы боролись со спамером, они умудрились ушатать данные пользователей за целый день, и потом еще день восстанавливали ее из бэкапа. Тест на доступность успешно провален. Это еще ладно — а я слышал истории о том, что у сервиса бэкапы-то есть, но восстанавливать их придется несколько недель. Так что отказ на день — это еще вполне себе High Availability по нынешним меркам.
Да, какой-нибудь яндекс регулярно устраивает тесты отказоустойчивости, вырубая датацентр. Однако, мне страшно подумать, что случится, если у яндекса внезапно вырубится более половины датацентров и отвалятся службы, опирающиеся на консенсус. Ихний кластер ClickHouse опирается в своей работе на (сюрприз) ZooKeeper. Отказ обезьянника (а он полностью отрубается при отказе половины узлов) приводит к переходу кластера в read-only. Сколько там еще служб отправится в read-only — мне было бы интересно узнать (давайте попросим роскомнадзор для проверки поблокировать датацентры яндекса).
Заметьте, что на серверах обычно SSD/HDD стоят в зеркале — чтобы, боже упаси, 24/7 сервис не умер из-за отказа одного из жестких дисков. И этому процессу впаривания говна нет конца, даже если завтра сделают устройства для передачи информации со сверхсветовой скоростью на спутанных квантовых состояниях и карманные петабайтные носители со средним периодом отказа в 2000 лет, то желающих хранить данные на локалхосте станет еще меньше и облачные сервисы будут выходить из строя по таймаутам при недопустимо больших задержках канала связи в 1 мс.
Потому, как ни странно, самое надежное «облако» — это то, которое стоит у вас в локальной сетке. Мало того, что облака могут в любой момент отвалиться — они еще и более несводобны, чем проприетарная софтина на локалхосте, как и предупреждал нас Штолман:
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
Я вот что не пойму: я один это вижу? Ваши данные, которые не ваши, ваши приложения, которая не ваши, ваши высоконадежные высокодоступные SaaS, которые остаются таковыми до первого отказа (и тоже, в общем-то, не ваши). Или вы тут все зарабатываете на SaaS (как Шома), потому особо не вскрываете эту тему? А со мной не поделились — у-у-у, подлецы.
PS: сам участвовал в разработке SaaS, но поставляли также и коробку для внутреннего сервера.
Выделил в отдельный тред обсуждение консольного клиента GitHub:
www.linux.org.ru/forum/talks/16499288?cid=16499698
Пацаны, кто по понятиям живет, а расскажите все-таки, почему и когда GitHub всех сожрал? Мне не устраивают сказки про «DVCS намного лучше централизированной репы», потому что большинство пользователей Git/GitHub используют его как централизированный репозиторий и сам GitHub развивался именно как централизированный хостинг.
Более того, никому на самом деле не нужен Git — в глазах почтенной публики это скорее консольный клиент для GitHub и его клона GitLab. Причем, именно в таком ключе продолжает развивать эту инициативу Microsoft, ныне владеющий GitHub: дополнительные инструменты в виде виртуальной файловой системы для online-only работы с центральным сервером, при этом сохранение совместимости с консольными клиентом GitHub-а.
По мотивам:
Вкатиться в наукоемкое программирование/моделирование (комментарий)
https://www.joelonsoftware.com/2002/05/06/five-worlds/
Джоэл вкинул важный тезис: если подход не работает в этих ваших опенсорсах, то это не значит, что он не работает вообще. Якобы есть какие-то проекты и команды, где программирование парами со взаиморевью кода и со 100% покрытием кода позволяет ускорять и упрощать разработку каких-то там проектов. Я сталкивался с таким подходом только в лице какого-то блоггера-коуча в рунете, который беспощадно тёр любые комментарии с отличным от его мнением. Судя по всему, движуха до сих пор жива — значит, она кому-то нужна? Соответственно, у меня вопрос:
Кто-то хотя бы слышал про такие проекты, где принципы экстримального программирования дали что-то, помимо экспоненциального роста со временем затрат на разработку и поддержку внутреннего корпоративного софта?
Возможно ли это сделать челу с в.о. по фуфлыжной специальности автоматизатора заводов? Заводов серьезных в округе толком нет, регалий особенных у меня нету тоже. С математикой-физикой-химией дружу, но никогда не видел в них толка, потому что в коммерции нынче востребовано только «купи-продай, разницу себе».
Я прагматичный человек, потому меня не привлекают мозгодробильная математика аля крипта или квантовые вычисления, которые еще никогда не одной реакции не предсказали. В грантораспильных организациях мне ловить нечего, потому что регалий у меня нет и я плохо подхожу для оправдания того, почему никаких результатов нет, а все деньги уже потрачены. Расчеты механических прочностей/ динамики/гидро/газодинамики — это прикольно, но без сверки с испытательными образцами ничего не стоит. Устраиваться в какой-то НИИ или завод за еду работать 8 часов от звонка до звонка уже очень не хочется.
Есть ли какие-то шансы у простого смертного продвинуться в этом направлении, или в СНГ всё глухо? Да, есть вариант сделать собственную лабораторию, но это не так-то просто по финансам, да и перспективы с ней неясные.
Недавно мне в копилку подкинули замечательный сайт:
Отличительной особенностью сайта является то, что он предоставляет хорошие ссылки для дальнейшего углубления.
Я уже давно почитываю обсуждения на hackernews и WikiWikiWeb (например, http://wiki.c2.com/?XmlIsTooComplex ). К сожалению в них существует та же проблема, что и в интернете в целом: очень много мусора, то есть, шаблонных бездумно копируемых «собственных» точек зрения, подтвержденных богатым опытом из пяти угробленных «не мной» за последний год проектов.
Как человеку, который поддерживал годами проекты, над которыми сам работал, и который понимает, чего стоят многие книжные знания, мне, тем не менее, совсем не достаточно своего опыта и интересен аналогичный опыт других людей. Например, когда Дан Абрамов писал-писал годами компоненты в реакте на миксинах, чтобы потом в итоге заявить Mixins Considered Harmful и Mixins Are Dead. Long Live Composition. Ну и из классики — мой любимый Дейкстра, конечно.
У меня есть очень большая подборка, но она отвратительно систематизирована и только я сам в ней смогу разобраться — короче говоря, это мои личные заметки. Возможно, есть такие поехавшие, кто тоже коллекционирует специфичные неортодоксальные взгляды на технологии и методики программирования, но при этом еще и организовал их в формате какой-нибудь вики.
Как некоторые из вас слышали, я уже некоторое время пытаюсь укусить локти и думаю, с какой стороны бы подступиться к нише CRM+ERP.
Существуют ли по-настоящему удобные системы совместного планирования и работы?
Энтерпрайз ERP/CRM фо отомейшн оф ё сириоз бизнес
Последний тред
Поиски вдохновения и единомышленников
я создал в том числе потому что почувствовал, что исчерпал запас новой информации, но хронически не знаю, откуда его пополнить. Удивительно, но почему-то интернет скромно замалчивает эту сферу. К сожалению, имеющиеся у меня сведения позволяют сделать вывод: готовые CRM/ERP системы не нужны. Если клиенту нужно руками вводить информацию о клиенте, обновлять его статус и писать комментарии — это не автоматизированная связь с клиентами. Это тупо ручная система организации, поскольку незначительно отличается от создания бумажных карточек клиента от руки или на печатной машинке. «Оповещения» — это те карточки, которые коллега передал мне в отдельную стопочку.
Потому можно говорить о том, что какой-нибудь мегаплан или битрикс 24 — это, по большей части, системы организации ручного труда. Почему-то лицемерные продажники не любят слово «ручной» вместо этого применяют слово «автоматизированный».
«По большей части ручного» — потому что все таки есть некоторые элементы автоматизации. Например, слежение за времяпрепровождением сотрудников — пусть ввод и весь ручной, но сбор статистики о времени активности все-таки полуавтоматический. Или генерация PDF файлика по введенным оператором значениям — это тоже полуавтоматика. Конечно, когда я вижу, как оператор три минуты пялится в экран, чтобы распечатать мне чек по уже выполеннному заказу — это не автоматизированный процесс, а полуавтоматизированный. Так и хочется сказать «недоавтоматизированный». Но давайте здесь я еще больше не соглашусь сам с собой, потому что никому на самом деле не нужен PDF файл. Особенно сейчас, когда бизнес постепенно мигрирует в электронную нишу, и максимум что нужно печатать — это чек, хотя бы потому, что так требует законодательство. А вот если на печатаемом документе еще и нужно ставить подпись/печать — это уже лишняя и бессмысленная ручная работа оператора.
Самое труднодостижимое и самое полезное в автоматизации — когда оператор перестает замечать систему. Когда руководитель вводит в компьютер «сделать трактор», а система находит нужных свободных сотрудников, ставит им задачи со сроками, резервирует детали, заготовки, инструмент на складах и заказывает недостающее. Это то, для чего изначально вообще задумывалось ERP. К сожалению, в реальном мире возникают несостыковки, брак, работник заболел/его сбил автобус, технология изменилась, склад замело снегом. Если довести эти факторы до абсурда, то получится система планирования в рамках страны, в которой форс мажоров настолько много, что планирование со сколь бы то ни было приемлимой точностью просто невозможно.
Проблемы автоматизации, как правило, находится на стыке некоторых механизмов, например: поступил звонок от клиента — передать клиента его привычному менеджеру или первому свободному, если привычный занят. Здесь есть две точки сопряжения: распознание номера телефона и определение факта доступности менеджера. Если их не проработать, то от автоматизации не остается и следа. И если у нас в системе есть N программ/механизмов, то задача их сопряжения имеет сложность O(N^2), то есть, сопрягать N механизмов с N(-1) механизмами. Отсюда вывод: плодить программы значительно проще, чем потом лепить из них единую автоматизированную систему.
Таким образом, настоящую ценность представляет не какая-нибудь табличка битрикса с клиентами, а возможность вообще без участия человека эту табличку создать на основании фактических звонков. Склад бесполезен, если мы не можем выгрузить из битрикса доступность позиций и их цены во внешнюю площадку — а мы не можем этого сделать, потому что битрикс безумной кривой и плохо поддается автоматизации.
А что же тогда продают упомянутые мегаплан, битрикс, ну и в конце-концов SAP с Oracle? Как правило, они продают число модулей, табличек, вкладочек, рюшечек на страничках. Это свойство, которое точно противоположно автоматизированности системы — незаметности модулей, которые должен видеть только админ и которые просто тихо незаметно работают. Таким образом, когда вы внедряете эти готовые программы на предприятии, вы прежде всего ВНЕДРЯЕТЕ ПРОБЛЕМУ, а потом уже ищете ей решение. Так и вижу лозунги «Битрикс 24 — лучшая проблема для вашего бизнеса», «BMW е$@^!я с SAP», «SAP — ready when you are» (вольный перевод: «SAP — будет готова как только вы подготовитесь к ней»). Последнее, между прочим, настоящий рекламный слоган, который иронично отражает сложность внедрения SAP на предприятии — а у SAP накопился богатый опыт провалов внедрений.
Как сказал один мой знакомый, который когда-то занимался вместе со мной внедрением самопального ERP на местном заводе: «нужно не спрашивать у заказчика о том, какую проблему ему нужно решить, а приходя к заказчику нужно уже иметь решения проблем, про которые он до тебя не знал». Я много лет не мог понять этой фразы. Наконец, я её понял.
Но я, все-таки, подходил к вопросу со стороны «чему можно научиться у этих систем? Как можно сделать их лучше, можно ли улучшить интерфейс и реализацию, чтобы по итогу получить конкурентное преимущество и оттяпать у них рыночек». А парадокс решения в том, что чем тоньше ваша система, тем проще она поддается автоматизации. Чем проще ваша БД, тем удобнее её адаптировать под нужды бизнеса. По этой причине SAP является самой-присамой неудобной базой для автоматизации на рынке.
Специалист по UX, Голден Кришна, написал целую книгу на схожую тему «Хороший интерфейс — невидимый интерфейс». Один из ключевых тезисов книги — нынче модно лепить планшеты куда ни попадя, хотя они делают устройство не проще, а сложнее. Именно это делают мегаплан-битрикс-SAP-Oracle — удовлетворяют потребность налепить китайский планшет на ваш бизнес (на удивление, довольно популярную потребность), превратив хорошо налаженное и много лет работающее предприятие в сиамского близнеца с четырьмя ногами. Мол «ваш бизнес приобрел больше ног, и теперь может ходить в два раза эффективнее». В тему планшетов/смартфонов они вам скажут «зато у нас есть готовые мобильные версии, удобно вне офиса ткнуть в смартфон и посмотреть список дел и сообщений». Я с удивлением обнаружил более одного человека, который занимается планированием не на компьютере и не на смартфоне, а тупо в бумажной тетрадке. Потому что бумажную тетрадку можно носить с собой и пользовательский интерфейс у нее заметно удобнее смартфона. К тому же, тетрадка не разобьется при падении на асфальт.
Но тема катастрофической неюзабельности современных смартфонов — это отдельный разговор, я бы предпочел остановиться на том, что смартфоны нужны для того и только для того, чтобы эффективно прожигать время, когда не можешь этого сделать на десктопе или игровой приставке.
Так что да здравствует простой софт, да здравствует юникс-вей (что бы это не значило). Вот такие промежуточные итоги изучения вопроса. Странно, что эти достаточно банальные вещи мало кто пишет на просторах интернетов. Иногда кажется, что вот этот комментатор сейчас скажет то же самое — но перед ключевыми словами умолкает, будто речь идет про вопросы его мастурбации или про конечность жизни человека, о которых в приличном обществе не принято говорить вслух.
Да-я-занимаюсь-онанизмом-thread
Под мои крайне специфические предпочтения весьма тяжело находить людей. живущих в подобном ритме и в аналогичной парадигме. Да, LOR остается довольно неплохим сайтом, дожившим с минимальными изменениями аж с нулевых годов.
Когда-то такой платформой был ЖЖ и я относительно активно в нем участвовал. Да, вы можете сказать «заведи свой блог и собирай единомышленников в нем». Но проблема в том, что специфика моего поведения плохо подходит под формат блога, потому что людям нужен регулярный и ожидаемый контент, то есть, если человеку понравилась тема UI/UX в моем блоге, то он зайдет еще раз почитать про UI/UX. Но у меня кончились интересные идеи в этой нише и я вообще забыл про нее на полгода. А если ему внезапно в ленту начнут сыпаться посты про авиацию из моего блога, то он вообще отпишется от меня.
То есть, мне больше подходит роль «на подхвате у сообщества». Я внезапно заваливаюсь к анимешникам, вдохновленный единичной годнотой со смыслом, но очень быстро выясняется, что подавляющее большинство аниме — это низкопробное говно, а его поклонники — не самые мудрые люди. И в итоге короткое время поучаствовав в жизни сообщества я с чистой душой забываю про него навсегда. Примерно как я лет на 8-10 пропадал с LOR-а, настолько, что даже забыл пароль к старому аккаунту (по сути я уже пятизвездочник).
К сожалению, ЖЖ бесповоротно скатился в говно. Альтернативных сервисов не вижу. Ну то есть вижу. но они всё больше напоминают помойки, заваленные рекламными статьями и не подразумевающими обсуждения. Вроде сайта Y Combinator, который, помимо фактического состояния помойки из случайной и рекламной информации, имеет отвратительную функциональность комментирования, где ты пишешь комментарии непонятно кому даже не надеясь на ответ. Некоторое время мне посчастливилось сидеть на одном сайте с Пелевиным, который мне очень близок широтой и спецификой своих интересов, но с закрытием сайта связь пропала, а публичности он, как и я, не любит.
С простыми смертными мне разговаривать не о чем, поскольку миром они не интересуются, книжки не читают, хобби не имеют, им «лишь бы работа была», пиво в холодильнике, и хер стоял. Попа мира, где я нынче размещаюсь, обладает довольно скромным количеством интересных людей, поскольку онные поразъезжались строить карьеры в столицы. Иронично, что на местном городском портале самым интересным человечком оказался парниша, который живет в штатах. Я даже знаю вполне конкретные адреса оффлайн тусовок, но они чертовски далеко от меня.
Мне кажется, что я своим слепым пятном упускаю какую-то нишу, где тусуется весь бомонд, и делает он это без меня, я не получал ни приглашения, ни открытки, ни электронного письма. Кроме лора, конечно же, тут стабильно неплохая публика. Или суровые самураи тусуются только в списках рассылки, разрабатывая опенсорс?
По мотивам:
Подарите старый NetBeans 8 с поддержкой C++ (комментарий)
Мне интересно, кто как больше всего применяет и редакторы кода, и просто текстовые редакторы, вроде Notepad++. На самом деле то же самое я пытаюсь узнать уже много тредов, но почему-то всегда получаю абстрактные ответы «NeoVim — говно хипстерское» или «зато в виме макросы есть» — правда, ни один пример полезного применения макросов мне пока что не смогли привести.
Итак, дублирую здесь свои требования к IDE/редактору:
Для меня ключевые фичи — это подсветка синтаксиса, пар скобок, текущей строки, достаточно простые операции автоматической обработки текста, вроде «верхний/нижний регистр», замена табов на пробелы и обратно, и вообще автоприменение отступов, и самое-самое-самое главное — это фичи обзора кода, то есть: поиск слов по файлам, открытие файлов по нечеткому имени, поиск тегов по нечеткому совпадению, в идеале поиск объявлений/реализации, иерархии вызовов, и самая обожаемая фича в VS, которую не может повторить никто — это возможность выстроить ручными или полуручными переходами иерархию связанного кода в одном окне прямо в коде. Обычно максимум что могут редакторы по последнему пункту — это позволят открыть несколько окошек и просматривать другие файлы параллельно там, пока не забудешь, что к чему привязано и зачем ты это вообще открывал. Вкладки для этой задачи подходят еще меньше, поскольку смысл их открытия забывается еще быстрее.
В текстовых файлах я в том числе создаю «базу знаний», но, к сожалению, во многих текстовых редакторах не хватает нечеткого полнотекстового поиска по простому тексту, а не коду программы, потому далеко не всегда поиском по файлам получается найти то, что записал, из-за банальной опечатки, или, наоборот, слишком большой выдачи по общему запросу, который не получается конкретизировать дополнительными условиями плана «из результатов поиска найти те, рядом с которыми находится такое-то слово». Буду благодарен, если кто-то также подскажет готовое решение для данной задачи — размеры моей благодарности не будет знать границ.
Как вы все прекрасно знаете, в мире есть волшебная традиция: множество людей, которые создают вещи, и множество людей, которые зарабатывают на них деньги, в основном не пересекается. За очень-очень редким исключением. Торвальдс делает ядро, IBM (а скоро и Microsoft) на нем зарабатывает. Это примерно как народная мудрость «есть люди умные, и есть люди сильные». Меня в данном случае не волнуют банальные рациональные объяснения, вроде «господь желает сохранить спонтанную радость в людях и не дает превратить мир в цифровой концлагерь» — даже если я не смогу научится в продажность, я хочу понять, как и почему.
У меня навык продажи, в том числе своего ануса, хронически хромает. Поскольку я в ближайшее время свой анус выставляю на аукцион, то хотелось бы немножно апгрейднуться в этом направлении. Я понимаю, что не совсем на том сайте это спрашиваю, но все же. Я потихоньку коллекционирую наблюдения за успешными, вроде «отдавай предпочтения популярным/популистским решениям, а не правильным» (ты себе хочешь сделать хорошо или заказчику?), «врубай режим нарцисса и рассказывай, что краше тебя на белом свете нету», и просто «пиши про себя на каждом заборе — авось кто-то поведется».
И да, я хронически плохо строю и пользуюсь связями. У меня есть небольшое оправдание — огромная толпа народа с прекрасной социализацией и кучей связей ничего не может из этих связей добыть.
Также бонусный вопрос: где нынче в айти вообще шевелятся денежки? Ну то есть я плохо понимаю, как за последние годы перекроилась индустрия. Для меня не составляет проблемы вкатиться в новую нишу, но очень не хочется вкатываться в совсем уж помойку, которую я обязательно безошибочно выбору из сотен вариантов. Как я выбрал тот же поцкаль, который никому не нужен — и это правильно. Правильно, что индустрия на нем ничего не пишет, и правильно, что я выбрал бесполезную технологию — всё, что нас не убивает, делает сильней.
Воскресный батхерт-разогрев перед началом рабочей недели. Очередной рассказ про «слабую логическую связанность, составленность из груды костылей, неподдатливость расширению», то есть " питоничность".
Как вы декорируете блоки кода в Python? Ну то есть все мы знаем, что можно декорировать функцию:
@decorator
def funcname(arg):
passи даже декорировать класс:
@decorator
class classname:
def __init__(self):
pass
Но вот беда — как передать кусок кода в другую функцию? Вечная проблема лямбды в питоне, которая не решена до сих пор и никогда не будет решена:
>>> decorator(lambda: a = 2)
File "<stdin>", line 1
SyntaxError: lambda cannot contain assignmentМне стыдно, но я до сих пор не подозревал, что в лямбдах нельзя использовать присваивание. Я подозреваю, что я не один такой, на самом деле, потому что лямбды почти никто не использует — в том числе по этой причине.
«Хорошо, наш язык говно, но давайте не отчаиваться, с этим что-то можно сделать» — сказал когда-то Гвидо, и предложил:
https://www.python.org/dev/peps/pep-0343/ — PEP 343 — The «with» Statement
Этот чудесный костыль позволяет вам обрамить любой блок кода процедурами инициализации и финализации. Проблема — что мне делать, если я хочу обрамить блок кода сложнее, например, чтобы он оказался в цикле? То есть
for filename in filenames:
with try_infinitely():
print(open(filename, 'r').readlines())В данном случае код должен пытаться бесконечно открывать и читать файл, пока не сможет это сделать. На питоне это можно написать как:
for filename in filenames:
while True:
try:
print(open(filename, 'r').readlines())
except Exception as e:
print(e)
else:
break;Но писать такую стенку каждый раз весьма утомительно. Как и заставлять юзверя объявлять вложенную функцию и передавать ее функции-декоратору, поскольку это будет нарушать обычную читаемость кода из-за того, что код вложенной функции будет выполняться позже своего объявления, в отличие от тех же лямбд JS, которые выполняются там, где определены. Чтобы была чуть более очевидна блевотность такого кода, я специально добавил цикл for filename in filenames снаружи:
for filename in filenames:
@try_infinitely
def nestedfunc():
print(open(filename, 'r').readlines())
nestedfunc()или
@try_infinitely
def nestedfunc():
print(open(filename, 'r').readlines())
for filename in filenames:
nestedfunc()Последнее, к моему удивлению, работает, потому что области видимости в питоне поделены на уровне функций, а не блоков, и потому filename будет видима в любом месте функции.
А хотелось бы чего-то простого и понятного, плана:
for filename in filenames:
@try_infinitely:
print(open(filename, 'r').readlines())Чувствуете, как код сразу стал намного проще? Единственный выход, который я пока что вижу — это городить свой DSL через
source = inspect.get_source(func)
ast.parse(source, func.__code__.co_filename, 'exec')
К сожалению, питон из коробки не позволяет кормить AST декоратору, а сам AST он нигде не хранит, потому остается только парсить сырцы.
По мотивам:
Си с классами
бери с++20 с концепциями, корутинами и ренжами. игнорируй всё из с++17, сфинае, не пиши упоротые шаблоны, вообще шаблоны старайся не писать, и всё будет ок.
концепции уже вроде работают, ренжи тоже есть, корутины ещё не подъехали, но в будущем пригодятся, генераторы там всякие, всё такое. ещё будет проще потом перелезть на экзекюторы и т.д. потом ещё модули затащишь.
Как эффективно учиться? (комментарий)
Я недавно всерьез собрался найти где-то гайды по крестам, которых был бы описан какой-то цельный подход к писанию на новых крестах с полным игнорированием неудачного наследования старых крестов, но с удивлением обнаружил, что таких нет или почти нет — можно найти отдельные подсказки, которые придется долго собирать воедино, а самому мне это делать тяжеловато, потому что кресты я только начинаю осваивать
Конкретно мне интересен функционально-процедурный подход к написанию кода на крестах, что-то похожее на Rust, только без абсурдной помешанности на безопасности памяти, так сказать «си с плюшками», но совсем НЕ «си с классами», как было в упомянутом треде. Для примера: Qt и UE — это примеры плохой архитектуры в данном контексте. Например, fstream — это плохая реализация файловых операций, поскольку скатывается в классы и исключения, в ней даже нельзя без исключений получить конкретную ошибку файловых операций.
Итак: какие есть конкретные хорошо проработанные приемы и библиотеки для писания на крестах в функционально-процедурном стиле?
Невеяло видео:
Что бесит программиста | Анастасия Лукьяненко
Ravens - Intelligent Rascals of the Skies | Free Documentary Nature
Если ворон сумел освоить тачскрин, то скоро его наймут писать софт для андроида. Ну или хотя бы веб-приложухи на JS.
Если серьезно, то мне не дает покоя недавнее обсуждение сложности отдельных конструкций в ЯП:
programming languages performance benchmarks (комментарий)
Там были упомянуты вопросы сложность рекурсивных функций и циклов. Как вы можете знать, на базе рекуррентных функций строятся такие замечательные вещи, как сеть Фейстля и подстановочно-перестановочная сеть, составляющие основу большинства симметричных алгоритмов шифрования. То есть, даже хорошо обученный и оснащенный человек не может ускорить вычисление конечно рекуррентной функции, не может угадать, что получится через несколько шагов или какие отклонения от нормы привели нас к состоянию текущего цикла вычисления функции.
Важное наблюдение — цикл можно представить в виде простого рекурсивного вызова (функция может вызывать себя только один раз), и простой рекурсивный вызов можно представить в виде цикла. Еще более важное наблюдение: машину Тьюринга можно представить как рекуррентную функцию, которая принимает аргументом предыдущее состояние машины и выдает на выход следующее состояние машины. Следствием этого являются известные вам алгоритмически неразрешимые задачки, как то проблема остановки, определение свойств произвольного алгоритма-функции (теорема Райса).
Асимметричные криптографические алгоритмы, которые зачастую основаны на модульной арифметике, как то RSA и эллиптическая криптография, являются типичными рекуррентными алгоритмами с глубокой степенью вложенности, пусть это и выражено в ввиде хитромудрых модульных операций умножения и возведения в степень, при этом входные и выходные значения алгоритмов имеют одинаковый размер, то есть, как конечное состояние машины Тьюринга на предыдущем и текущем цикле.
На основании этих исследований я хотел бы сформулировать теоремы Byko3y: для произвольного нетривиального алгоритма, представляющего собой неограниченно рекуррентную функцию, то есть программу машины Тьюринга, справедливы утверждения:
Есть ли выход из Тьюринг-западни? То есть, существуют ли/можно ли создать инструменты, на которых сможет достаточно эффективно писать даже умственно осталая мартышка? Очевидно, есть Тьюринг-неполные языки, которые просты и достаточно мощны для некоего узкого набора задач. Регулярные выражения, SQL, в конце-концов подмножества обычных ЯП, или какая-нибудь Clojure, построенная на персистентных структурах данных с очень хорошей предсказуемостью поведения и ограничением применения макросов. Даже Rust в каком-то смысле тоже попытался пойти именно по этому направлению, то есть, через ограничение применения изменяемого состояния, характерного для Тьюринг-машины.
Очень долго индустрия приходила к замыканиям, но замыкания хороши именно тем, что избавляют нас от сложной работы с общим изменяемым состоянием, и становятся плохи, когда замыкания начинают принимать/передавать аргументами другие замыкания и вызывать таким образом сами себя, создавая сложное рекуррентное поведение.
Или когда пользователь хочет отсортировать некий массив или даже банально посчитать сумму, ему совсем не обязательно писать цикл, ему не нужно проходить по массиву последовательно от первого элемента до последнего — исходный порядок здесь не имеет значения. Но Тьюринг-машины научили нас, что действия должны выполняться строго последовательно, и нынче никто уже никто не ставит под сомнение такой подход. Функциональные языки, даже весьма «чистые», имеют функции reduce, но я не видел еще ни одного языка, который имел бы реализацию reduce, безразличную к порядку прохода по элементам, вроде иерархического агрегирования аки агрегатные функции в SQL.
Одна из относительной свежих попыток решить эту проблему для разработки фронтэнда — React.js. Не Angular, который значительно сложнее и мартышку за него не посадишь, а именно React, который если и тьюринг-полон, то эту тьюринг полноту непросто достичь. С позиции программиста-пользователя React, имеет тупейше прямолинейное преобразование данных в отображение, и такую же простую функциональность для измения состояния по событиям пользователського ввода, причем, механизм «ввод->изменение модели» развязан с механизмом «модель->данные», и оба они развязаны между отдельными компонентами, потому косяки реализации мартыхой одного компонента не рушат другой.
Продолжайте список, какие инструменты/приемы вы знаете или о каких вы думали/мечтали.
PS: давно хочу вкатиться в ограниченное подмножество C++ без наследования, без зубодробильных шаблонов, с минимумом исключений. Потому что на Си неудобно писать без обобщений и замыканий. Буду благодарен за литературу и/или готовые опенсорсные проекты, реализованные в подобном стиле. Знаю, что Unity сделан в этом духе, но беда в том, что Unity проприетарен.
Взамен досрочно почившему:
| ← предыдущие | следующие → |