• UML умер, а никто и не заметил?
    0

    Нормальный пример. Более того, я даже не могу припомнить пример из своей практики, когда принцип "код сам себе документация" работал на все сто. Ну кроме совсем примитивных случаев, когда и так всё понятно.

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

  • UML умер, а никто и не заметил?
    –3

    Сложность эту, к сожалению, на хлеб не намажешь. Мы наворачиваем всё новые и новые уровни абстракции, городим фреймворки поверх фреймворков, оборачиваем многослойные виртуализации дополнительными слоями виртуализации, и всё ради упрощения. Только проще не становится, а становится только сложнее. Сюрприз?

  • UML умер, а никто и не заметил?
    0

    >>Типичный современный продукт на порядки сложнее и технологичнее, чем 20 лет назад

    Это потому что у нас сильно облегчилось накопление сложности. То, что современный продукт ради того, чтобы показать анимацию, поле ввода и кнопочку тянет в себя гигабайт разнообразных фреймворков, не делает его сложным. Он так и остаётся простым как валенок, а вся его сумасшедшая сложность на 99.9% является либо издержками техпроцесса, либо просто балластом. Следует ли нам гордиться этой сложностью? Ну, не уверен. Особенно с учётом того, что вместе со сложностью частенько возрастает хрупкость.

    >>У нас основная спецификация — это код

    Нет. Вот просто нет, и всё. Я не знаю, кто ввинтил этот тупейший мем в массовое сознание. Почитайте, например, документацию на Реакт, а потом поройтесь в его исходниках. Уверен, вы почувствуете разницу.

  • UML умер, а никто и не заметил?
    0

    Я говорил не про крепление глушителя, а про деградацию качества инженерных решений при внедрении agile там, где не нужно.

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

    Заметьте, мы это всё обсуждаем под статьёй про упразднение за ненужностью стандартизованных нотаций, использовавшихся при проектировании софта. Ушло проектирование - ушли и нотации. Это как если бы в материальном производстве ушли чертежи. Петровичу не нужны ни кульман, ни САПР. У него опыт и сварочный аппарат.

  • UML умер, а никто и не заметил?
    +1

    Что делает Фольксваген, когда нужно внести изменение, например, в крепление глушителя? Пригоняет толпу конструкторов, материаловедов, сопроматчиков, технологов, они плодят кучу расчётов, чертежей, смет, и прочей фигни. Потом изготавливаются опытные образцы, которые испытываются на стенде, потом натурно. Опять же, несколько машинок разбить в краш-тестах чисто на всякий случай.

    Что делает дядя Ашот, если нужно внести изменение в крепление глушителя? "Падажди здесь дарагой, щас Петрович докурит и в пять минут тебе всё как надо приварит".

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

    По мере продолжения победного шествия agile по планете, я ожидаю всё больше и больше самых неожиданных вещей, сделанных быстро, дёшево и очень сердито.

  • Хватит везде делать микросервисы
    +1

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

  • Генераторы для самых маленьких
    +2

    Нормальный путь питониста вглубь этой темы:

    1. Не знать про yield. Спокойно в своём уютненьком юпитер-нотбуке совать пандас в матплотлиб и горя не знать.

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

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

    4. Оказывается, yield умеет не только отдавать, но ещё и принимать данные. Ой.

    5. Туго, со скрипом, через боль и фрустрацию въезжаем в тему async/await и внезапно обнаруживаем, что теперь у нас каждая мать её функция является этим самым генератором, который где-то там внутри под капотом елдячит на каждом "await".

    6. ... не знаю, я дальше не ходил.

  • Не начинайте учиться кодингу с Python, начните с языка C
    +1

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

    Хотя, конечно, если главным в обучении считать череду страданий и унижений, через которые должен пройти ученик, тогда да, лучше начинать с С, или ещё лучше с плюсов. Или с Хаскеля.

  • Не начинайте учиться кодингу с Python, начните с языка C
    0

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

  • Микрофронтенды и виджеты в 2021-м. Доклад Яндекса
    +4

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

  • Языки любимые и языки страшные. Зелёные пастбища и коричневые поля
    0

    Хаскель самый страшный из любимых

  • Мотоциклетный жилет с подушкой безопасности компании Klim не сработает, если не оплатить подписку
    0

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

  • Как без усталости кодить по восемь с лишним часов
    0

    — Как без усталости кодить по восемь часов?
    — Перестать с усталостью кодить по двенадцать.

  • Белогривые лошадки. Как облачные технологии меняют мир
    +1

    С этими прекрасными облачными приложениями всё хорошо за исключением того, что пользователь фактически (физически) не владеет своими данными. А те товарищи, которые владеют, никакой ответственности не несут. Высокопрофессиональные юристы корпораций добра грамотно прописали все мыслимые отказы от ответственности. Сегодня всё хорошо и ничего не предвещает беды, а завтра… "война окончена, всем спасибо, все свободны".

  • Разговор с майнером Chia, имеющим 1ПБ ёмкости
    +1

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

  • NFT — это пирамида, и люди уже теряют на ней деньги
    +1

    Давайте попытаемся разобраться с мотивацией приобрести NFT-токен.


    Во-первых, понты. Но какие-то странные понты. За солидные деньги приобретаешь понт, которым, по сути невозможно попонтоваться. Только самоудовлетворяться самопонтованием. ИМХО, редкостная дурь.
    Во-вторых, это может быть инвестицией. Это у нас, нищебродов, нет серьёзной задачи деть куда-нибудь внезапно свалившуюся хренову гору бабок, но вообще вот прямо сейчас уйма народа спать не может, решает эту проблему. Скажем прямо, перспектива выгодной перепродажи такого актива весьма призрачная.
    В-третьих, отмывание денег. Рисуешь в пэйнте фигню, сам себе её продаёшь, и вот ты теперь не наркодилер, а удачливый творец цифрового искусства.
    В-четвёртых, популяризация торговой площадки, самой идеи NFT, Эфира, себя любимого в конце концов. Вчера ты был убогим нонэймом, а всего за какие-нибудь $10К прогремел по новостным каналам и стал типа инфлюенсером. Правда ненадолго, да и качество этого инфленсерства так себе, жиденькое.
    В-пятых, поддержать любимого творца. Однако, лично мне кажется, что есть масса более простых и менее затратных способов это сделать.


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

  • NFT — это пирамида, и люди уже теряют на ней деньги
    +3

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

  • NFT — это пирамида, и люди уже теряют на ней деньги
    +1

    Извиняюсь за наивный детский вопрос. Допустим, некий покупатель купил у некоего продавца некую последовательность нулей и единиц. Имеет ли это событие какие-нибудь последствия лично для меня? Должен ли я проверить свой комп и флешки и почту и всё остальное чтобы убедиться, что нигде чужое не завалялось? А если этим пренебрегу, оно завалялось и его найдут, что мне грозит? Штраф? Тюрьма? Расстрел? Чем вообще регулируется конкретно этот подвид права собственности? И каким образом организовано правоприменение?

  • Теперь персональные данные должны удалять отовсюду по первому требованию, но есть побочка
    +1

    Это как минимум неудобно, но вообще весьма опасно, когда законодательство противоречит природе вещей.
    Об "забыть Герострата" ещё древние греки спотыкались.

  • Сколько стоят ваши социальные данные?
    +2

    Проблема не в том, что некий чел продал какому-то другому челу за огромные деньги моё ФИО, а я с этой сделки не имею процент. Бегать-кричать ради того, чтобы отсудить пару долларов — ну такое, на любителя.


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


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


    Тема "персональные данные", ребята, она не про бабосики, она про свободу. Свободу быть самим собой и самому выбирать своё будущее. Очень, очень серьёзная тема.

  • Serverless-архитектура сегодня: как бессерверные решения меняют разработку
    0

    Обещать не могу, но идея интересная.


    Итак, как понять, что для реализации задумки годится серверлесс.


    Во-первых, что логично, оно должно укладываться в архитектурные ограничения. Читаем доки по используемому облаку и, например, выясняем, что для того, чтобы завершиться, у функции есть не больше пяти минут. Если была идея сделать функцией какой-нибудь нудный и долгий ETL, то не судьба. Допустим, в ограничения укладываемся, потому что если нет, то здесь разговор закончен.


    Во-вторых, сразу прикидываем, пугает ли нас привязка к конкретному облачному провайдеру. И если пугает, то насколько. А если не пугает, сразу пытаемся прикинуть, какова вероятность того, что мнение по этому вопросу не изменится. Допустим, всё ОК, не пугает и пугать не собирается, потому что иначе… ну, понятно.


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


    (а) Нам надо выкинуть в облако нечто действительно простое. Например по запросу от фронтенда выдернуть немножко данных из базы, сунуть их в пандас, немножко там покрутить, скормить матплотлибу и отдать получившийся PNG клиенту. Уже есть готовый Юпитер-ноутбук, который это умеет делать, надо только опубликовать в виде сервиса. Погружаться в хтонь девопса со всеми этими терраформами, хельм-чартами и прочими тяжеловесными CI/CD нет ни сил, ни желания, ни квалификации. Предоставляемая функциями фича "NoOps" это как раз то, что нужно.


    (б) Прямо противоположная ситуация. У нас всё сложно и мощно, и фича, которая нас интересует — автоскейлинг до небес на пиковых нагрузках. И вот здесь включаем голову и смотрим, что конкретно у нас является узким местом. Если всё тормозит, то это вовсе не значит, что оно тормозит процессором. В 99% случаев оно отдыхает на операциях ввода-вывода. В этом случае асинхронка поможет лучше автоскейлинга функций хотя бы потому, что можно накрутить дополнительных плюшек типа кеширования. Плюс к тому так будет легче контролировать транзитивную нагрузку и избежать того, что функция-то справилась, но сервер базы лёг. Короче, в этом сценарии функции применяются только для вычислений. И то только если уже перевели вычисления на быстрый язык, а не на эти ваши пандасы. Да, ещё на всякий случай убедимся, что сложность, с которой воюем это O(n). В случае с O(n^p) горизонтальный скейлинг всё равно счастья не принесёт. В сухом остатке: чисто вычислительные задачи сложности O(n), уже переведённые на гошечку или С++.


    (в) Лепим халтуру, главное запуститься, подписать акт и успеть добежать с деньгами до канадской границы. Серверлесс поможет проскочить нагрузочные испытания, а дальше хоть трава не расти.


    Мне ближе сценарий (б), но я отдаю себе отчёт, что это весьма редкая (хотя, конечно, меткая) ситуация. Ожидаю, что подавляющее большинство поделий будут по сценариям (а) и (в).


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

  • Serverless-архитектура сегодня: как бессерверные решения меняют разработку
    0

    Спасибо большое за статью и ответы. Наконец-то заставил себя поразбираться с этой штукой.


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

  • Serverless-архитектура сегодня: как бессерверные решения меняют разработку
    0

    Спасибо что откликнулись. На сообщество пока подписываться не буду т.к. сидим на Ажуре и переезжать не планируем. Хотя кто знает. В Ажуре тоже есть функции, которые, догадываюсь, идейно есть то же самое. И вот смотрю на эти функции (вот они, рядом, нажимай кнопочку "add new" и получай неземное наслаждение) и не понимаю зачем мне это. Есть смутное ощущение, что может очень даже пригодиться, но как и зачем — no idea.
    Можно я порассуждаю вслух? Если забреду куда-нибудь не туда, пожалуйста поправьте.
    Итак, функция. Как мы уже выяснили, оно без вариантов должно быть стейтлесс. То есть данные в себе не хранит. Если нужно хранить, то пользуемся живущими вовне базами данных, файлохранилищами, кафками и прочими товарищами, которые уже не функции, потому что они стейтфул.
    Ещё функция не должна выполняться слишком долго. 30 секунд максимум. Или сутки тоже нормально, если задача достойная?
    И ещё она не должна пожирать слишком много оперативы. На какое ограничение ориентироваться?
    Быстрый холодный старт. Т.е. если нужен длительный предрасчёт чего-то или кеширование куска БД, то функцию делать лучше не надо.
    С кешированием, насколько я понимаю, у функций вообще всё странно — его невозможно применить эффективно т.к. экземпляры функций как попало рождаются и умирают. Да и вообще, любое кеширование это уже маленький такой безобидный стейтфул.
    Что у нас с параллелизмом внутри функции? Однотредовую асинхронщину, если язык позволяет, однозначно можно, но что с многопоточностью? Можно? Нельзя? Можно, но не рекомендуется?
    Насколько я понимаю, GPU — запретная тема для функций, сразу и навсегда. То есть нейросети и прочие ML-дела в любом виде, что обучение, что инференс, точно не про функции.
    Что с аутентификацией/авторизацией? Всё плохо или наоборот, организация авторизованного доступа это как раз тот случай, когда имеет смысл в первую очередь подумать о функциях?
    Пока что я вижу следующие сценарии использования функций:


    • У нас настолько тупые клиенты, что не способны выполнить простейшую операцию типа сортировки массива или ресайзинга картинки, поэтому пусть платят за свою тупость необходимостью гонять данные через сеть.
    • Обёртка вокруг существующего сервиса. То есть нам нужно превратить слишком сложное или слишком полное чьё-то API в нечто простое и урезанное "для народа". Функция, по сути, будет заниматься перекладкой JSONов: сначала в одну сторону, от клиента к серверу, а потом обратно.
    • Мы переигрались в NoSQL, расщепили наши данные на зоопарк хранилищ и технологий, и теперь будем латать дыры методом написания 100500 функций, которые будут джойнить данные для нас. Но поскольку это всё без кеширования, производительность будет так себе, и мы согласны это терпеть.
    • Наша команда разработчиков состоит в основном из джунов без профильного образования, работающих за еду. Единственное, что они могут из параллельного это запулить одновременно пачку POST-реквестов и собрать результаты (нам стоило больших усилий обучить их этому трюку, но, кажется, удалось). Просить их собрать что-то достойное на очередях и семафорах себе дороже. Пусть могучий и мудрый облачный провайдер разберётся с нашим параллелизмом.
    • У наших джунов всё плохо с оптимизацией алгоритмов. Говоришь им про О-большое — смотрят пустыми глазами. Будем тушить пожар неограниченной мощью современных датацентров. И, ну да, деньгами.
    • … что-нибудь ещё?
  • Serverless-архитектура сегодня: как бессерверные решения меняют разработку
    +1

    Присматриваюсь к серверлесс-архитектуре, и пока что-то не пойму как применить это в свей реальной жизни так, чтобы потом не пришлось всё срочно переделывать.
    Адепты этого подхода из каждого утюга кричат, что "подходит для всего" и "можно реализовать что угодно", но это очевидно… мягко говоря… хм… неправда.
    Начать с того, что серверлесс он ещё и неизбежно стэйтлесс. Если разрабатываемая штучка обязана быть стейтфул, то серверлесс сразу мимо.
    У меня есть архиполезный для бизнеса сервис, который стартут пять минут, зажирает 2ГБ оперативы, но после этого выдаёт ответы с ураганной скоростью. Очевидно, что из-за этих самых 2ГБ и пяти минут этот сервис не может быть серверлесс.
    И ещё я понимаю, что слегка попервой накосячить и вызвать сход лавины вызовов (примерно как у ребят по приведённой Вами ссылке) — ну это просто святое. Когда такое происходит (а оно неизбежно происходит), в "обычной" архитектуре тестовый кластер просто покрасится красненьким, да и ничего страшного. Серверлесс же всё стерпит и пришлёт конский счёт за услуги.
    Кстати, а кто-нибудь знает, как развернуть модельку серверлесс-среды у себя на локалке? Или предлагается сразу запускаться в очень платном облаке?
    Если продолжить занудствовать, то уверен, наберётся ещё список на сорок листов архитектурных ограничений и тонкостей. Кто-нибудь об этом говорит? Кто-нибудь проводит инструктаж по технике безопасности? Как раз строго наоборот, "подходит для всего" и "можно реализовать что угодно".
    Задача правильной декомпозиции разрабатываемых систем и так чудовищно сложная. А с учётом дополнительных архитектурных ограничений она становится кошмаром. А с учётом того, что эти ограничения ещё и старательно замалчиваются, всё превращается в какую-то совсем мерзкую липкую хтонь.
    Так что пока у меня есть только ощущение, что вся эта история про то, чтобы доверчивого и падкого на диковинки клиента (т.е. меня) меньше кормить и больше доить. Охотно готов оказаться не прав.

  • No comments
    +4
    1. Комментарии устаревают
    Вообще вся документация устаревает. Откажемся от документирования?
    2. Программисты пишут плохие комментарии
    … да и код тоже частенько так себе. Особенно полохими комментарии получаются когда разработчиков насильно заставляют их писать, как в приведённом примере про собачку.
  • Предустановка отечественного ПО или кто теперь следит за нами?
    0

    Следующим (ну ОК, м.б. не следующим, а позаследующим) законодательным ограничением будет запрет нахождения вне адреса прописки без включённого смартфона.

  • Ваша любовь к разработке в первую очередь выгодна работодателю
    +1

    Полезно различать и не путать следущие безусловно связанные между собой вещи:


    1. Работа как деятельность. Ремесло. Это хорошо и правильно, когда кодеру нравится кодить, доктору лечить, певцу петь. Правильно ли когда менту нравится бить людей а солдату убивать — отдельный вопрос, но в нормальной ситуации это нормально, когда от самого вида деятельности не воротит, а лучше если конкретно прёт.
    2. Работа как добывание корма и прочих нужных вещей. Да, нам нужно кушать, без этого мы болеем, умираем и не можем получать удовольствие от любимого вида деятельности.
    3. Работа как часть мира. Бывает полезно иметь ответ на вопрос, каким образом моя деятельность делает мир лучше. Или по крайней мере не хуже. Или хуже, но не сильно.
    4. Работа как социализация. Если коллектив гадюшник и начальник урод, то лучше бы всё же было наоборот.

    Жёсткая просадка по любому из этих четырёх пунктов — хороший повод крепко задуматься и нахрен всё поменять. А если без жёсткой просадки, то это уже вопрос личных предпочтений в расстановке приоритетов. Лично мне в кайф когда работа, за которую мне платят достаточную зарплату также является и моим хобби, и коллектив приятный, и делаемое дело не входит в противоречие с представлениями о добре и зле.

  • Свидетели DevOps: мифы и байки про девопсов и тех, кто их нанимает
    +4

    Девопс это человек, программирующий на ямле

  • Новогоднее обращение GPT-2
    0

    Тег "Будущее здесь" как нельзя кстати

  • Фетиш WYSIWYG или Как правильно скрещивать ужа с ежом
    +1

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

  • Эти безумные KPI
    +1

    Расскажите мне как у вас считается KPI и я скажу, от чего сдохнет ваша контора.
    Не, ну серьёзно. Одним скаляром невозможно выразить даже банальный вектор на плоскости. Каким же нужно быть самонадеянным или… хм… крайне недалёким, чтобы на полном серьёзе пытаться выразить одним скаляром результат деятельности живого человека!

  • Канал «Мультики студии Союзмультфильм» удалил более тысячи советских мультфильмов с YouTube
    0

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

  • Улучшение Python-кода: 12 советов для начинающих
    +3

    Меня немножко печалит когда простенькая логика в десяток строк на Питоне обвешивается как ёлка ямлами-томлами-инифайлами. Докеры-шмокеры, полный девопс по последней моде, и всё это ради того, чтобы один джейсон жутко неоптимальным образом переложить в другой джейсон и передать дальше. Ну когда, скажите, думать об алгоритмах и структурах данных, когда нужно пытаться удерживать в голове десятки "облегчающих жизнь" тулзов с десятками настроечных параметров каждый?
    Автоформаттеры, кстати, лично для себя считаю ацким злом. Вырубаю первым делом безжалостно. Автор кода я и мои товарищи, и механическим роботам править его не разрешается.

  • Как переписать SQL-запросы на Python с помощью Pandas
    +1

    А что с джойнами? Особенно интересует full outer

  • Математические расчёты, стоящие за феноменом роллинг-шаттера
    0

    Вот интересно, как это всё вяжется с таким понятием, как экспозиция

  • Ликбез про электронные трудовые книжки
    +3

    Если Росреестр умудряется массово терять записи о сделках с недвижимостью, могу себе представить какой ад будет с электронными трудовыми. Особенно с учётом того, что владелец этой затеи финансово заинтересован в том, чтобы потерялось как можно больше.

  • Не стоит создавать собственные решения для аутентификации пользователей
    0

    Почитал комменты, и не могу нарадоваться на то, что аутсорсинг аутентификации неопределённому кругу третьих лиц не мне одному кажется долбаным безумием.
    Да, безусловно, пароли и управление ими очень сложная тема. Если в кратком изложении, займёт в книжке страницы три, а если с объяснениями, то аж целых десять. Не всякий осилит, это правда. Но разве это повод приказным тоном загонять всех в гиперцентрализованные сервисы аутентификации?
    Когда я предоставляю услуги (особенно платные), а мой клиент их потребляет, это дело (а) моё, (б) клиента, и (в) больше ничьё. Я обязался предоставлять сервис, и это область моей ответственности. Клиент обязался следовать условиям предоставления сервиса, и это его область ответственности. И тут внезапно появляется третье лицо неизвестного происхождения с грамотно прописанным отказом от ответственности, которое для меня неотличимо от всех моих пользователей. И если кто-то имеет возможность прийти к этому третьему лицу и сделать предложение, от которого невозможно отказаться, этот "кто-то" тоже получает возможность быть для меня неотличимым от любого из моих пользователей.
    Учитывая, что ИТ-гиганты почти всегда включают режим открытых дверей для всех спецслужб всех государств, а те в свою очередь бывает не брезгуют перепродавать данные кому попало, оно всё начинает как-то совсем нехорошо попахивать.

  • Как думают программисты-сеньоры?
    +6

    Очень похоже на рассуждения о сеньорстве начинающего мидла вчерашнего джуна. Извините. По ходу дела, оно совсем не про то, чтобы досконально изучить Реакт. Доскональное изучение Реакта — вообще джуновая тема.

  • [Перевод] Смыть
    0

    Если у меня есть дата, к примеру, 17.03.2020, то в конструктор new Date(year, month, day) я должен передавать числа 2020, 3 и 17. Других чисел у меня нет. По крайней мере, я в упор не вижу.
    Всё остальное ненормально. Всё остальное или шизофрения, или психопатическое желание поиздеваться над джунами.

  • [Перевод] Смыть
    +1

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