Это как минимум неудобно, но вообще весьма опасно, когда законодательство противоречит природе вещей.
Об "забыть Герострата" ещё древние греки спотыкались.
Проблема не в том, что некий чел продал какому-то другому челу за огромные деньги моё ФИО, а я с этой сделки не имею процент. Бегать-кричать ради того, чтобы отсудить пару долларов — ну такое, на любителя.
Основная проблема в расползании перс. данных в том, что чем в больших масштабах это происходит, тем более широкий круг неустановленных третьих лиц получает над нами власть. Не всегда, конечно, ту самую власть, которая в наручники и на подвал. Знание, например, пользовательских предпочтений не только помогает прогнозировать спрос, но и более эффективно воздействовать на динамику этих самых предпочтений. То есть ты, чувак, в том виде, какой ты есть, некоего дядю не очень устраиваешь, и этот дядя подключает крутых специалистов и высокие технологии к тому, чтобы тебя, чувак, поменять в лучшую сторону. Лучшую для него сторону, не для тебя.
Мы любим потешаться типа "вот идиоты, забрасывают меня рекламой кроссовок после того, как я уже купил кроссовки". Ну да, такие грубые промахи сразу заметны, и нас они веселят. Но есть плохая новость: маркетинговые попадания точно в цель незаметны совсем. Мы радостно плывём по течению, наслаждаемся процессом, а потом внезапно оказываемся в рядах ревностных почитателей какого-нибудь говна.
Тема "персональные данные", ребята, она не про бабосики, она про свободу. Свободу быть самим собой и самому выбирать своё будущее. Очень, очень серьёзная тема.
Итак, как понять, что для реализации задумки годится серверлесс.
Во-первых, что логично, оно должно укладываться в архитектурные ограничения. Читаем доки по используемому облаку и, например, выясняем, что для того, чтобы завершиться, у функции есть не больше пяти минут. Если была идея сделать функцией какой-нибудь нудный и долгий ETL, то не судьба. Допустим, в ограничения укладываемся, потому что если нет, то здесь разговор закончен.
Во-вторых, сразу прикидываем, пугает ли нас привязка к конкретному облачному провайдеру. И если пугает, то насколько. А если не пугает, сразу пытаемся прикинуть, какова вероятность того, что мнение по этому вопросу не изменится. Допустим, всё ОК, не пугает и пугать не собирается, потому что иначе… ну, понятно.
Если эти два барьерчика пройдены, то дальше вопрос целесообразности, где у нас развилка на три семейства ситуаций.
(а) Нам надо выкинуть в облако нечто действительно простое. Например по запросу от фронтенда выдернуть немножко данных из базы, сунуть их в пандас, немножко там покрутить, скормить матплотлибу и отдать получившийся PNG клиенту. Уже есть готовый Юпитер-ноутбук, который это умеет делать, надо только опубликовать в виде сервиса. Погружаться в хтонь девопса со всеми этими терраформами, хельм-чартами и прочими тяжеловесными CI/CD нет ни сил, ни желания, ни квалификации. Предоставляемая функциями фича "NoOps" это как раз то, что нужно.
(б) Прямо противоположная ситуация. У нас всё сложно и мощно, и фича, которая нас интересует — автоскейлинг до небес на пиковых нагрузках. И вот здесь включаем голову и смотрим, что конкретно у нас является узким местом. Если всё тормозит, то это вовсе не значит, что оно тормозит процессором. В 99% случаев оно отдыхает на операциях ввода-вывода. В этом случае асинхронка поможет лучше автоскейлинга функций хотя бы потому, что можно накрутить дополнительных плюшек типа кеширования. Плюс к тому так будет легче контролировать транзитивную нагрузку и избежать того, что функция-то справилась, но сервер базы лёг. Короче, в этом сценарии функции применяются только для вычислений. И то только если уже перевели вычисления на быстрый язык, а не на эти ваши пандасы. Да, ещё на всякий случай убедимся, что сложность, с которой воюем это O(n). В случае с O(n^p) горизонтальный скейлинг всё равно счастья не принесёт. В сухом остатке: чисто вычислительные задачи сложности O(n), уже переведённые на гошечку или С++.
(в) Лепим халтуру, главное запуститься, подписать акт и успеть добежать с деньгами до канадской границы. Серверлесс поможет проскочить нагрузочные испытания, а дальше хоть трава не расти.
Мне ближе сценарий (б), но я отдаю себе отчёт, что это весьма редкая (хотя, конечно, меткая) ситуация. Ожидаю, что подавляющее большинство поделий будут по сценариям (а) и (в).
Вообще я очень насторожено отношусь к технологиям, которые развращают разработчиков, давая им ложное ощущение снятия ресурсных ограничений. В конце концов мы живём в физической реальности, и по-настоящему неограниченные у нас только глупость и жадность.
Спасибо большое за статью и ответы. Наконец-то заставил себя поразбираться с этой штукой.
Немножко дополнительно погуглив, выработал для себя чёткий набор критериев, по которым можно определить, имеет ли смысл реализовывать задачу на серверлесс. Если хотите, могу поделиться.
Спасибо что откликнулись. На сообщество пока подписываться не буду т.к. сидим на Ажуре и переезжать не планируем. Хотя кто знает. В Ажуре тоже есть функции, которые, догадываюсь, идейно есть то же самое. И вот смотрю на эти функции (вот они, рядом, нажимай кнопочку "add new" и получай неземное наслаждение) и не понимаю зачем мне это. Есть смутное ощущение, что может очень даже пригодиться, но как и зачем — no idea.
Можно я порассуждаю вслух? Если забреду куда-нибудь не туда, пожалуйста поправьте.
Итак, функция. Как мы уже выяснили, оно без вариантов должно быть стейтлесс. То есть данные в себе не хранит. Если нужно хранить, то пользуемся живущими вовне базами данных, файлохранилищами, кафками и прочими товарищами, которые уже не функции, потому что они стейтфул.
Ещё функция не должна выполняться слишком долго. 30 секунд максимум. Или сутки тоже нормально, если задача достойная?
И ещё она не должна пожирать слишком много оперативы. На какое ограничение ориентироваться?
Быстрый холодный старт. Т.е. если нужен длительный предрасчёт чего-то или кеширование куска БД, то функцию делать лучше не надо.
С кешированием, насколько я понимаю, у функций вообще всё странно — его невозможно применить эффективно т.к. экземпляры функций как попало рождаются и умирают. Да и вообще, любое кеширование это уже маленький такой безобидный стейтфул.
Что у нас с параллелизмом внутри функции? Однотредовую асинхронщину, если язык позволяет, однозначно можно, но что с многопоточностью? Можно? Нельзя? Можно, но не рекомендуется?
Насколько я понимаю, GPU — запретная тема для функций, сразу и навсегда. То есть нейросети и прочие ML-дела в любом виде, что обучение, что инференс, точно не про функции.
Что с аутентификацией/авторизацией? Всё плохо или наоборот, организация авторизованного доступа это как раз тот случай, когда имеет смысл в первую очередь подумать о функциях?
Пока что я вижу следующие сценарии использования функций:
У нас настолько тупые клиенты, что не способны выполнить простейшую операцию типа сортировки массива или ресайзинга картинки, поэтому пусть платят за свою тупость необходимостью гонять данные через сеть.
Обёртка вокруг существующего сервиса. То есть нам нужно превратить слишком сложное или слишком полное чьё-то API в нечто простое и урезанное "для народа". Функция, по сути, будет заниматься перекладкой JSONов: сначала в одну сторону, от клиента к серверу, а потом обратно.
Мы переигрались в NoSQL, расщепили наши данные на зоопарк хранилищ и технологий, и теперь будем латать дыры методом написания 100500 функций, которые будут джойнить данные для нас. Но поскольку это всё без кеширования, производительность будет так себе, и мы согласны это терпеть.
Наша команда разработчиков состоит в основном из джунов без профильного образования, работающих за еду. Единственное, что они могут из параллельного это запулить одновременно пачку POST-реквестов и собрать результаты (нам стоило больших усилий обучить их этому трюку, но, кажется, удалось). Просить их собрать что-то достойное на очередях и семафорах себе дороже. Пусть могучий и мудрый облачный провайдер разберётся с нашим параллелизмом.
У наших джунов всё плохо с оптимизацией алгоритмов. Говоришь им про О-большое — смотрят пустыми глазами. Будем тушить пожар неограниченной мощью современных датацентров. И, ну да, деньгами.
Присматриваюсь к серверлесс-архитектуре, и пока что-то не пойму как применить это в свей реальной жизни так, чтобы потом не пришлось всё срочно переделывать.
Адепты этого подхода из каждого утюга кричат, что "подходит для всего" и "можно реализовать что угодно", но это очевидно… мягко говоря… хм… неправда.
Начать с того, что серверлесс он ещё и неизбежно стэйтлесс. Если разрабатываемая штучка обязана быть стейтфул, то серверлесс сразу мимо.
У меня есть архиполезный для бизнеса сервис, который стартут пять минут, зажирает 2ГБ оперативы, но после этого выдаёт ответы с ураганной скоростью. Очевидно, что из-за этих самых 2ГБ и пяти минут этот сервис не может быть серверлесс.
И ещё я понимаю, что слегка попервой накосячить и вызвать сход лавины вызовов (примерно как у ребят по приведённой Вами ссылке) — ну это просто святое. Когда такое происходит (а оно неизбежно происходит), в "обычной" архитектуре тестовый кластер просто покрасится красненьким, да и ничего страшного. Серверлесс же всё стерпит и пришлёт конский счёт за услуги.
Кстати, а кто-нибудь знает, как развернуть модельку серверлесс-среды у себя на локалке? Или предлагается сразу запускаться в очень платном облаке?
Если продолжить занудствовать, то уверен, наберётся ещё список на сорок листов архитектурных ограничений и тонкостей. Кто-нибудь об этом говорит? Кто-нибудь проводит инструктаж по технике безопасности? Как раз строго наоборот, "подходит для всего" и "можно реализовать что угодно".
Задача правильной декомпозиции разрабатываемых систем и так чудовищно сложная. А с учётом дополнительных архитектурных ограничений она становится кошмаром. А с учётом того, что эти ограничения ещё и старательно замалчиваются, всё превращается в какую-то совсем мерзкую липкую хтонь.
Так что пока у меня есть только ощущение, что вся эта история про то, чтобы доверчивого и падкого на диковинки клиента (т.е. меня) меньше кормить и больше доить. Охотно готов оказаться не прав.
Вообще вся документация устаревает. Откажемся от документирования?
2. Программисты пишут плохие комментарии
… да и код тоже частенько так себе. Особенно полохими комментарии получаются когда разработчиков насильно заставляют их писать, как в приведённом примере про собачку.
Следующим (ну ОК, м.б. не следующим, а позаследующим) законодательным ограничением будет запрет нахождения вне адреса прописки без включённого смартфона.
Полезно различать и не путать следущие безусловно связанные между собой вещи:
Работа как деятельность. Ремесло. Это хорошо и правильно, когда кодеру нравится кодить, доктору лечить, певцу петь. Правильно ли когда менту нравится бить людей а солдату убивать — отдельный вопрос, но в нормальной ситуации это нормально, когда от самого вида деятельности не воротит, а лучше если конкретно прёт.
Работа как добывание корма и прочих нужных вещей. Да, нам нужно кушать, без этого мы болеем, умираем и не можем получать удовольствие от любимого вида деятельности.
Работа как часть мира. Бывает полезно иметь ответ на вопрос, каким образом моя деятельность делает мир лучше. Или по крайней мере не хуже. Или хуже, но не сильно.
Работа как социализация. Если коллектив гадюшник и начальник урод, то лучше бы всё же было наоборот.
Жёсткая просадка по любому из этих четырёх пунктов — хороший повод крепко задуматься и нахрен всё поменять. А если без жёсткой просадки, то это уже вопрос личных предпочтений в расстановке приоритетов. Лично мне в кайф когда работа, за которую мне платят достаточную зарплату также является и моим хобби, и коллектив приятный, и делаемое дело не входит в противоречие с представлениями о добре и зле.
С удовольствием пользуюсь маркдауном, хотя когда с ним уже в зрелом возрасте познакомился, он мне показался какой-то хипстерской поделкой без царя в голове задуманой и абы как сделаной. Что, в общем, так и есть, но это не мешает нам им пользоваться с удовольствием. Иногда, правда, без удовольствия, потому что, положа руку на сердце, штука это реально убогая.
Расскажите мне как у вас считается KPI и я скажу, от чего сдохнет ваша контора.
Не, ну серьёзно. Одним скаляром невозможно выразить даже банальный вектор на плоскости. Каким же нужно быть самонадеянным или… хм… крайне недалёким, чтобы на полном серьёзе пытаться выразить одним скаляром результат деятельности живого человека!
Меня немножко печалит когда простенькая логика в десяток строк на Питоне обвешивается как ёлка ямлами-томлами-инифайлами. Докеры-шмокеры, полный девопс по последней моде, и всё это ради того, чтобы один джейсон жутко неоптимальным образом переложить в другой джейсон и передать дальше. Ну когда, скажите, думать об алгоритмах и структурах данных, когда нужно пытаться удерживать в голове десятки "облегчающих жизнь" тулзов с десятками настроечных параметров каждый?
Автоформаттеры, кстати, лично для себя считаю ацким злом. Вырубаю первым делом безжалостно. Автор кода я и мои товарищи, и механическим роботам править его не разрешается.
Если Росреестр умудряется массово терять записи о сделках с недвижимостью, могу себе представить какой ад будет с электронными трудовыми. Особенно с учётом того, что владелец этой затеи финансово заинтересован в том, чтобы потерялось как можно больше.
Почитал комменты, и не могу нарадоваться на то, что аутсорсинг аутентификации неопределённому кругу третьих лиц не мне одному кажется долбаным безумием.
Да, безусловно, пароли и управление ими очень сложная тема. Если в кратком изложении, займёт в книжке страницы три, а если с объяснениями, то аж целых десять. Не всякий осилит, это правда. Но разве это повод приказным тоном загонять всех в гиперцентрализованные сервисы аутентификации?
Когда я предоставляю услуги (особенно платные), а мой клиент их потребляет, это дело (а) моё, (б) клиента, и (в) больше ничьё. Я обязался предоставлять сервис, и это область моей ответственности. Клиент обязался следовать условиям предоставления сервиса, и это его область ответственности. И тут внезапно появляется третье лицо неизвестного происхождения с грамотно прописанным отказом от ответственности, которое для меня неотличимо от всех моих пользователей. И если кто-то имеет возможность прийти к этому третьему лицу и сделать предложение, от которого невозможно отказаться, этот "кто-то" тоже получает возможность быть для меня неотличимым от любого из моих пользователей.
Учитывая, что ИТ-гиганты почти всегда включают режим открытых дверей для всех спецслужб всех государств, а те в свою очередь бывает не брезгуют перепродавать данные кому попало, оно всё начинает как-то совсем нехорошо попахивать.
Очень похоже на рассуждения о сеньорстве начинающего мидла вчерашнего джуна. Извините. По ходу дела, оно совсем не про то, чтобы досконально изучить Реакт. Доскональное изучение Реакта — вообще джуновая тема.
Это как минимум неудобно, но вообще весьма опасно, когда законодательство противоречит природе вещей.
Об "забыть Герострата" ещё древние греки спотыкались.
Проблема не в том, что некий чел продал какому-то другому челу за огромные деньги моё ФИО, а я с этой сделки не имею процент. Бегать-кричать ради того, чтобы отсудить пару долларов — ну такое, на любителя.
Основная проблема в расползании перс. данных в том, что чем в больших масштабах это происходит, тем более широкий круг неустановленных третьих лиц получает над нами власть. Не всегда, конечно, ту самую власть, которая в наручники и на подвал. Знание, например, пользовательских предпочтений не только помогает прогнозировать спрос, но и более эффективно воздействовать на динамику этих самых предпочтений. То есть ты, чувак, в том виде, какой ты есть, некоего дядю не очень устраиваешь, и этот дядя подключает крутых специалистов и высокие технологии к тому, чтобы тебя, чувак, поменять в лучшую сторону. Лучшую для него сторону, не для тебя.
Мы любим потешаться типа "вот идиоты, забрасывают меня рекламой кроссовок после того, как я уже купил кроссовки". Ну да, такие грубые промахи сразу заметны, и нас они веселят. Но есть плохая новость: маркетинговые попадания точно в цель незаметны совсем. Мы радостно плывём по течению, наслаждаемся процессом, а потом внезапно оказываемся в рядах ревностных почитателей какого-нибудь говна.
Тема "персональные данные", ребята, она не про бабосики, она про свободу. Свободу быть самим собой и самому выбирать своё будущее. Очень, очень серьёзная тема.
Обещать не могу, но идея интересная.
Итак, как понять, что для реализации задумки годится серверлесс.
Во-первых, что логично, оно должно укладываться в архитектурные ограничения. Читаем доки по используемому облаку и, например, выясняем, что для того, чтобы завершиться, у функции есть не больше пяти минут. Если была идея сделать функцией какой-нибудь нудный и долгий ETL, то не судьба. Допустим, в ограничения укладываемся, потому что если нет, то здесь разговор закончен.
Во-вторых, сразу прикидываем, пугает ли нас привязка к конкретному облачному провайдеру. И если пугает, то насколько. А если не пугает, сразу пытаемся прикинуть, какова вероятность того, что мнение по этому вопросу не изменится. Допустим, всё ОК, не пугает и пугать не собирается, потому что иначе… ну, понятно.
Если эти два барьерчика пройдены, то дальше вопрос целесообразности, где у нас развилка на три семейства ситуаций.
(а) Нам надо выкинуть в облако нечто действительно простое. Например по запросу от фронтенда выдернуть немножко данных из базы, сунуть их в пандас, немножко там покрутить, скормить матплотлибу и отдать получившийся PNG клиенту. Уже есть готовый Юпитер-ноутбук, который это умеет делать, надо только опубликовать в виде сервиса. Погружаться в хтонь девопса со всеми этими терраформами, хельм-чартами и прочими тяжеловесными CI/CD нет ни сил, ни желания, ни квалификации. Предоставляемая функциями фича "NoOps" это как раз то, что нужно.
(б) Прямо противоположная ситуация. У нас всё сложно и мощно, и фича, которая нас интересует — автоскейлинг до небес на пиковых нагрузках. И вот здесь включаем голову и смотрим, что конкретно у нас является узким местом. Если всё тормозит, то это вовсе не значит, что оно тормозит процессором. В 99% случаев оно отдыхает на операциях ввода-вывода. В этом случае асинхронка поможет лучше автоскейлинга функций хотя бы потому, что можно накрутить дополнительных плюшек типа кеширования. Плюс к тому так будет легче контролировать транзитивную нагрузку и избежать того, что функция-то справилась, но сервер базы лёг. Короче, в этом сценарии функции применяются только для вычислений. И то только если уже перевели вычисления на быстрый язык, а не на эти ваши пандасы. Да, ещё на всякий случай убедимся, что сложность, с которой воюем это O(n). В случае с O(n^p) горизонтальный скейлинг всё равно счастья не принесёт. В сухом остатке: чисто вычислительные задачи сложности O(n), уже переведённые на гошечку или С++.
(в) Лепим халтуру, главное запуститься, подписать акт и успеть добежать с деньгами до канадской границы. Серверлесс поможет проскочить нагрузочные испытания, а дальше хоть трава не расти.
Мне ближе сценарий (б), но я отдаю себе отчёт, что это весьма редкая (хотя, конечно, меткая) ситуация. Ожидаю, что подавляющее большинство поделий будут по сценариям (а) и (в).
Вообще я очень насторожено отношусь к технологиям, которые развращают разработчиков, давая им ложное ощущение снятия ресурсных ограничений. В конце концов мы живём в физической реальности, и по-настоящему неограниченные у нас только глупость и жадность.
Спасибо большое за статью и ответы. Наконец-то заставил себя поразбираться с этой штукой.
Немножко дополнительно погуглив, выработал для себя чёткий набор критериев, по которым можно определить, имеет ли смысл реализовывать задачу на серверлесс. Если хотите, могу поделиться.
Спасибо что откликнулись. На сообщество пока подписываться не буду т.к. сидим на Ажуре и переезжать не планируем. Хотя кто знает. В Ажуре тоже есть функции, которые, догадываюсь, идейно есть то же самое. И вот смотрю на эти функции (вот они, рядом, нажимай кнопочку "add new" и получай неземное наслаждение) и не понимаю зачем мне это. Есть смутное ощущение, что может очень даже пригодиться, но как и зачем — no idea.
Можно я порассуждаю вслух? Если забреду куда-нибудь не туда, пожалуйста поправьте.
Итак, функция. Как мы уже выяснили, оно без вариантов должно быть стейтлесс. То есть данные в себе не хранит. Если нужно хранить, то пользуемся живущими вовне базами данных, файлохранилищами, кафками и прочими товарищами, которые уже не функции, потому что они стейтфул.
Ещё функция не должна выполняться слишком долго. 30 секунд максимум. Или сутки тоже нормально, если задача достойная?
И ещё она не должна пожирать слишком много оперативы. На какое ограничение ориентироваться?
Быстрый холодный старт. Т.е. если нужен длительный предрасчёт чего-то или кеширование куска БД, то функцию делать лучше не надо.
С кешированием, насколько я понимаю, у функций вообще всё странно — его невозможно применить эффективно т.к. экземпляры функций как попало рождаются и умирают. Да и вообще, любое кеширование это уже маленький такой безобидный стейтфул.
Что у нас с параллелизмом внутри функции? Однотредовую асинхронщину, если язык позволяет, однозначно можно, но что с многопоточностью? Можно? Нельзя? Можно, но не рекомендуется?
Насколько я понимаю, GPU — запретная тема для функций, сразу и навсегда. То есть нейросети и прочие ML-дела в любом виде, что обучение, что инференс, точно не про функции.
Что с аутентификацией/авторизацией? Всё плохо или наоборот, организация авторизованного доступа это как раз тот случай, когда имеет смысл в первую очередь подумать о функциях?
Пока что я вижу следующие сценарии использования функций:
Присматриваюсь к серверлесс-архитектуре, и пока что-то не пойму как применить это в свей реальной жизни так, чтобы потом не пришлось всё срочно переделывать.
Адепты этого подхода из каждого утюга кричат, что "подходит для всего" и "можно реализовать что угодно", но это очевидно… мягко говоря… хм… неправда.
Начать с того, что серверлесс он ещё и неизбежно стэйтлесс. Если разрабатываемая штучка обязана быть стейтфул, то серверлесс сразу мимо.
У меня есть архиполезный для бизнеса сервис, который стартут пять минут, зажирает 2ГБ оперативы, но после этого выдаёт ответы с ураганной скоростью. Очевидно, что из-за этих самых 2ГБ и пяти минут этот сервис не может быть серверлесс.
И ещё я понимаю, что слегка попервой накосячить и вызвать сход лавины вызовов (примерно как у ребят по приведённой Вами ссылке) — ну это просто святое. Когда такое происходит (а оно неизбежно происходит), в "обычной" архитектуре тестовый кластер просто покрасится красненьким, да и ничего страшного. Серверлесс же всё стерпит и пришлёт конский счёт за услуги.
Кстати, а кто-нибудь знает, как развернуть модельку серверлесс-среды у себя на локалке? Или предлагается сразу запускаться в очень платном облаке?
Если продолжить занудствовать, то уверен, наберётся ещё список на сорок листов архитектурных ограничений и тонкостей. Кто-нибудь об этом говорит? Кто-нибудь проводит инструктаж по технике безопасности? Как раз строго наоборот, "подходит для всего" и "можно реализовать что угодно".
Задача правильной декомпозиции разрабатываемых систем и так чудовищно сложная. А с учётом дополнительных архитектурных ограничений она становится кошмаром. А с учётом того, что эти ограничения ещё и старательно замалчиваются, всё превращается в какую-то совсем мерзкую липкую хтонь.
Так что пока у меня есть только ощущение, что вся эта история про то, чтобы доверчивого и падкого на диковинки клиента (т.е. меня) меньше кормить и больше доить. Охотно готов оказаться не прав.
… да и код тоже частенько так себе. Особенно полохими комментарии получаются когда разработчиков насильно заставляют их писать, как в приведённом примере про собачку.
Следующим (ну ОК, м.б. не следующим, а позаследующим) законодательным ограничением будет запрет нахождения вне адреса прописки без включённого смартфона.
Полезно различать и не путать следущие безусловно связанные между собой вещи:
Жёсткая просадка по любому из этих четырёх пунктов — хороший повод крепко задуматься и нахрен всё поменять. А если без жёсткой просадки, то это уже вопрос личных предпочтений в расстановке приоритетов. Лично мне в кайф когда работа, за которую мне платят достаточную зарплату также является и моим хобби, и коллектив приятный, и делаемое дело не входит в противоречие с представлениями о добре и зле.
Девопс это человек, программирующий на ямле
Тег "Будущее здесь" как нельзя кстати
С удовольствием пользуюсь маркдауном, хотя когда с ним уже в зрелом возрасте познакомился, он мне показался какой-то хипстерской поделкой без царя в голове задуманой и абы как сделаной. Что, в общем, так и есть, но это не мешает нам им пользоваться с удовольствием. Иногда, правда, без удовольствия, потому что, положа руку на сердце, штука это реально убогая.
Расскажите мне как у вас считается KPI и я скажу, от чего сдохнет ваша контора.
Не, ну серьёзно. Одним скаляром невозможно выразить даже банальный вектор на плоскости. Каким же нужно быть самонадеянным или… хм… крайне недалёким, чтобы на полном серьёзе пытаться выразить одним скаляром результат деятельности живого человека!
Лишнее нам напоминание, что добрый дядя, предоставляющий кульный бесплатный сервис, на самом деле никакой не добрый.
Меня немножко печалит когда простенькая логика в десяток строк на Питоне обвешивается как ёлка ямлами-томлами-инифайлами. Докеры-шмокеры, полный девопс по последней моде, и всё это ради того, чтобы один джейсон жутко неоптимальным образом переложить в другой джейсон и передать дальше. Ну когда, скажите, думать об алгоритмах и структурах данных, когда нужно пытаться удерживать в голове десятки "облегчающих жизнь" тулзов с десятками настроечных параметров каждый?
Автоформаттеры, кстати, лично для себя считаю ацким злом. Вырубаю первым делом безжалостно. Автор кода я и мои товарищи, и механическим роботам править его не разрешается.
А что с джойнами? Особенно интересует full outer
Вот интересно, как это всё вяжется с таким понятием, как экспозиция
Если Росреестр умудряется массово терять записи о сделках с недвижимостью, могу себе представить какой ад будет с электронными трудовыми. Особенно с учётом того, что владелец этой затеи финансово заинтересован в том, чтобы потерялось как можно больше.
Почитал комменты, и не могу нарадоваться на то, что аутсорсинг аутентификации неопределённому кругу третьих лиц не мне одному кажется долбаным безумием.
Да, безусловно, пароли и управление ими очень сложная тема. Если в кратком изложении, займёт в книжке страницы три, а если с объяснениями, то аж целых десять. Не всякий осилит, это правда. Но разве это повод приказным тоном загонять всех в гиперцентрализованные сервисы аутентификации?
Когда я предоставляю услуги (особенно платные), а мой клиент их потребляет, это дело (а) моё, (б) клиента, и (в) больше ничьё. Я обязался предоставлять сервис, и это область моей ответственности. Клиент обязался следовать условиям предоставления сервиса, и это его область ответственности. И тут внезапно появляется третье лицо неизвестного происхождения с грамотно прописанным отказом от ответственности, которое для меня неотличимо от всех моих пользователей. И если кто-то имеет возможность прийти к этому третьему лицу и сделать предложение, от которого невозможно отказаться, этот "кто-то" тоже получает возможность быть для меня неотличимым от любого из моих пользователей.
Учитывая, что ИТ-гиганты почти всегда включают режим открытых дверей для всех спецслужб всех государств, а те в свою очередь бывает не брезгуют перепродавать данные кому попало, оно всё начинает как-то совсем нехорошо попахивать.
Очень похоже на рассуждения о сеньорстве начинающего мидла вчерашнего джуна. Извините. По ходу дела, оно совсем не про то, чтобы досконально изучить Реакт. Доскональное изучение Реакта — вообще джуновая тема.