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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Помню, как со мной случилась истерика, когда со всего размаху охреначился об то, что в JS первый месяц — это февраль.

  • Новые модели поиска и анализа данных. WSDM 2020 глазами команды Яндекс.Толоки
    –2

    Что-то в этих Толоках есть такое, что вызывает во мне глубокое омерзение

  • Макросы для питониста. Доклад Яндекса
    +2

    Есть зло, есть адское зло, и есть макросы

  • Машинное обучение столкнулось с нерешенной математической проблемой
    –1
    Поскольку действительные числа включают в себя иррациональные, а также рациональные и целые числа
    Миллениалы изобрели доказательство теоремы Кантора
  • DevOps-инженеров не существует. Кто тогда существует, и что с этим делать?
    +1

    "В молодую развивающуюся компанию требуется DevOps-инженер DevOps-манагер"
    Так лучше?

  • Асинхронное программирование в Python: краткий обзор
    0

    Ну да, в этом и есть смысл параллельного исполнения.
    Тем не менее, в статье совсем не раскрыто, в чём, собственно, разница между
    await asyncio.sleep(1)
    и старым добрым
    time.sleep(1)

  • Асинхронное программирование в Python: краткий обзор
    –1
    (про await) Такая конструкция означает, что программа будет выполняться до тех пор, пока не встретит await-выражение, после чего вызовет функцию и приостановит своё выполнение до тех пор, пока работа вызванной функции не завершится

    Извиняюсь, а разве старый добрый вызов функции не делает вот это самое, что здесь описано?

  • Как я проработала 3 месяца в Я.Маркете и уволилась
    +15
    • Где работаешь?
    • В Яндексе
    • Таксист что ли?
    • Нет, еда
  • Что умеют делать наручные часы кроме показа времени и как выбрать свои первые часы
    +8

    Со смартфоном есть небольшая засада. Когда его включаешь, чтобы просто посмотреть время, ты также видишь кучу уведомлений. Даже если сжал волю в кулак и не стал их открывать, ты всё равно потратил душевные силы на это. Более того, следующие несколько минут ты будешь лихорадочно прикидывать, вдруг там что-то срочное и важное. Смартфон — отвлекающий фактор #1 в современном мире. Каждый лишний взгляд на него — вычеркнутый кусок жизни. Небольшой, но всё же. Или большой, когда захотел узнать, не пора ли уже выходить, а очнулся через час, отсмотрев кучу мемов.
    Старые добрые часы не показывают уведомлений. Никогда. Вскинул руку, узнал сколько времени, и продолжаешь как ни в чём не бывало заниматься своими делами.
    А насчёт понтовости… Не знаю, не эксперт. У меня самого купленные 10 лет назад за 200 баксов абсолютно нейтральные по части понтовости часы.

  • И всё же C — низкоуровневый язык
    +3
    Никто не станет спорить с тем, что язык ассемблера находится на самом низком уровне.
    У нас так не бывает, чтобы никто не спорил. Verilog и VHDL двумя уровнями ниже ассемблера.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0
    Молоток не моделирует забивание гвоздя, кастрюля не моделирует варку борща, автомобиль не моделирует перевозку пассажиров и грузов, самолёт не моделирует движение в воздушном потоке. Так почему программа должна моделировать ту область, в которой она применяется? Не является ли требование моделирования ничем в сущности не обоснованной обузой?

    Мне кажется, весьма глубоко укоренившееся заблуждение насчёт моделирования возникло от того, что компьютер действительно является очень удобным инструментом для численного моделирования. Сначала в основном для этого компьютеры и использовались. Но сейчас времена уже давно как поменялись. Сейчас решение задач собственно моделирования занимает от силы 2% мировых вычислительных мощностей. Очень достойные и очень уважаемые 2%, но всё же 2%, если не меньше.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0
    -
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0

    М.б. имеется в виду контроль единственности не объекта, а класса?

  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0
    Складывается ощущение, что ребята традиционно исходят из неверного представления, что в базах данных хранятся объекты. Посмотрим конечно, но на их долгосрочные перспективы я не готов поставить ни цента.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    –1
    Почему лишняя, если в реальности она «физически» существует в виде кортежа реляции?
    Физически мы все состоим из атомов, но функционируем как единое целое. Аналогия понятна?
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0
    Последнее. Объекты мэппятся на отношения. Вы создаёте/правите структуру персистентных классов, и шайтан-фреймворк сам допиливает метаданные БД. Если сказать ему, что классы «Абонент» и «Номер» нужно отмэппить на одно и то же отношение, он решит, что разраб сошёл с ума и откажется так делать.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0

    Аргумент "вы просто не умеете их готовить" не принимается. Извините.

  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    +1
    NoSQL — зонтичный термин для всего, что «не только SQL». Кто-то из них схемный, кто-то бессхемный, кто-то вообще ничего персистентно не хранит, кто-то, говорят, без проблем только insert умеет делать, а update и delete долго и дорого, кто-то ACID, а кто-то нет.

    Что касается схемы, то она есть всегда. Даже если база бессхемная. Только она не в метаданных в СУБД записывается, а где-то ещё. Хоть в коде программы, хоть на прибитой к стенке бумажке, хоть в голове у сотрудника.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0
    Ну это же халтура! Никому не нужен объект «Запись книжки». Когда ищу по имени, мне нужен список объектов «Абоненты», а когда приходит входящий звонок, отображается карточка объекта «Телефонный номер». Объект «Запись книжки» — лишняя сущность. Да ещё и снабжённая суррогатным ключом.

    Прочувствуйте пожалуйста красоту идеи ситуационно-зависимого проецирования набора фактов на объекты, с которыми работает логика и пользователи. С одной стороны зашли — один набор объектов, с другой стороны зашли — другой набор, с третьей — третий. На одних и тех же фактах. Данные в базе хранятся естественным для них образом. Объекты выстраиваются опять же естественным для них, объектов, образом. То, что одно другому один-в-один не соответствует — да и не очень-то хотелось. ORM требует, чтобы соответствовало, и в результате у нас или база кривая, или миллион строк невменяемого кода, или и то, и другое вместе. Ребята, зачем?
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0

    Это какая-то совсем чёрная магия. Для контроля типов и составления контекстной подсказки сгодится, но какое ожидать поведение от таких объектов?

  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    –1

    Вообще, контрагент — это покупатель ИЛИ продавец. А у Вас "И".


    Что касается makemigrations/migrate, то оно по-любому не потянуло бы мою сложную переукладку данных. Всё равно пришлось бы собственно перенос данных рисовать вручную, и делался бы он не групповыми запросами, а пообъектно. То есть в десятки раз дольше. Или сотни.

  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    –1
    А в каком виде держать данные в памяти, если вы запретили объекты?
    Это где же я запрещал объекты? Более того, я специально акцентировал внимание на том, что они — наша неизбежность.

    И как же частичная статическая проверка запросов компилятором и контекстные подсказки от IDE? Избыточно и совсем не нужно?
    Это, конечно, вкусно, но честное слово, жить без этого можно. Впрочем, если следовать подходу «объекты как проекции фактов, а в базе факты», то будут вам и проверки компилятором, и подсказки от IDE.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    –1
    ООП разве не построено на основе теории множеств?
    Нет, не построено. В первом приближении класс — это множество, а экземпляр — это элемент. Но если копнуть глубже, начинаются чудеса. Например, оказывается, что у нас с операциями пересечения и объединения множеств? Вот есть, например, два класса — Customer и Vendor. Как их будем объединять и пересекать? Какие-то странные множества. Теория множеств, в которых определена только операция разбиения на подмножества (наследование). Немножко странно всё это.

    Об ETL или об автоматическом апдейте структуры базы?
    Второе
    Вот я, например, пару недель назад учинил рефакторинг структуры базы (очень хотелось разогнать в пару десятков раз). Написание весьма хитрой миграции у меня заняло пару часов. Почему-то уверен, что через ковыряние во всяких миграционных тонких настройках в духе джанговского каталога «migrations» отняло бы гораздо больше времени, сил и нервов, и всё равно в результате не дало бы той стопроцентной уверенности, которую я получил вручную.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0
    Эта таблица имеет составной первичный ключ, в который входят обе колонки. Только не говорите пожалуйста, что так не бывает.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0
    Как построить объекты для приведённого издевательского примера про имена и номера телефонов? Объект «запись в книжке» в целом бесполезен. Полезные объекты — Абонент (у которого может быть несколько номеров) и Номер (который может использоваться несколькими абонентами). Ни одна ORM не потянет мэппинг двух классов на одну таблицу.
    Вы скажете, что это извращение. Возможно, но в дизайне баз данных ещё и не такие извращения иногда доводится крутить, при этом, что характерно, оставаясь в рамках высочайших стандартов нормализации данных.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0
    Спасибо за интересную ссылочку. Хотя при прочтении этой статьи может возникнуть ложное ощущение, что проблема в том, что технология РБД лет на 40 отстала от прогресса.

    Что касается соломенных чучелок, то не очень понимаю, почему Вы увидели только эти Вами перечисленные. Главное чучелко — это то, что невозможно по-настоящему крепко подружить математику и не-математику. ООП, кстати, это совсем даже не плохо. Я этого не говорил. Сам им с удовольствием пользуюсь. Просто не надо его абсолютизировать и возводить в догму. Не годится оно для этого.

    безопасность запросов
    Инъекции? Ну, не знаю. Как-то совсем давно не вписывал значения в прикладном коде прямо в SQL-строку, отправляемую на сервер. Что с ORM, что без. Как-то сразу приучил себя предохраняться.

    оптимизация обращений к СУБД (каскадное конструирование запроса, отложенное выполнение)
    Чисто по практике: рефакторинг с отказом от ORM зачастую в разы улучшает производительность именно за счёт более оптимизированной работы с СУБД.

    миграции!
    А что миграции? Вы о чём? Об ETL или об автоматическом апдейте структуры базы?
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0
    С нормализацией в данном случае, что удивительно, всё в порядке. Старая добрая веками прекрасно зарекомендовавшая себя технология бумажного блокнотика.
    Несколько записей по одному и тому же имени абонента — нормальная ситуация. Нужно только исключить ситуацию, когда пользователь под именем «Маша» записывает десять разных Маш. Решается на уровне пользовательского интерфейса.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    +4
    Спасибо за ссылку. Хорошая статья, и заминусовали её, скорее всего, за слишком провокационный заголовок.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0
    Совершенно верно. Когда я, например, разбираюсь с тем, что там как разложено в NoSQL-базе, всё равно рисую старую добрую ER-диаграмму. Народ сначала смотрит дико, а потом втыкает, что это действительно удобно и наглядно.
  • ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно
    0
    В принципе, все технологии программирования, включая ОППшные, замкнуты друг на друга через Тьюринг-полноту. Впрочем, не суть, и Вы, наверно, не об этом.
  • Непростой принцип единственной ответственности
    –1
    Но системность от этого всё равно не появится. Будут только куча отдельных обёрнутых в функции строчек.
  • Непростой принцип единственной ответственности
    –1
    Сложность убивает, раздели ее на части и ты победишь
    но потреяешь системность. То есть поделия будут не системами, а кучками разрозненного мусора. Собрать в единое целое в результате, конечно же, удастся, но только только ценой удесятирения объёма кода.
  • Менеджер по продукту: чем он занимается и как им стать?
    –1

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