• Двойная бюстгалтерия* глазами программиста
    +1
    хочу сказать, что ваш начальный тезис — ошибочен.

    Везде говорят, что для минимизации ошибок нужно избегать дублирования информации,


    1. непонятно что такое «везде»
    2. вот я привел несколько примеров, когда наоборот — избыточная информация позволяет не только выявлять ошибки (CRC) но и корректировать их (ECC и прочие), или даже просто примитивное дублирование (RAID 1) повышает надежность хранения информации — то есть, в случае возникновения ошибок на этом уровне, это не приводит к ошибкам далее — используют ту копию, которая осталась целой.

    На статью с парадоксальным выводом хотелось бы ссылку.

    Что же касательно двойной записи в бухгалтерии, то судя по вашим комментариям к этой статье, вы не разобрались, и даже желания разобраться не видно.
  • Двойная бюстгалтерия* глазами программиста
    +1
    Избыточное кодирование — это все-таки не просто дублирование.


    RAID 1 — просо дублирование.
  • Двойная бюстгалтерия* глазами программиста
    +1
    Везде говорят, что для минимизации ошибок нужно избегать дублирования информации,


    В этом месте всем передает привет CRC, ECC, и прочие способы избыточно кодировать информацию, что бы было легко обнаруживать ошибки, корректировать и так далее.
  • Фантом: большая сборка мусора
    0
    В системе Фантом вы не видите никаких серьёзных проблем со ссылками, поэтому я предполагаю, что у вас в голове есть какая-то модель её функционирования.


    повторюсь: ОС Фантом на одном физическом хосте — это (грубо) одна копия jvm/.net или любой другой VM. А разные программы в ОС Фантом — это суть разные нити внутри этой самой jvm. Есть сейчас какие-то вопросы по управлению ресурсами внутри одной копии jvm? Примерно такой-же набор вопросов в ОС Фантом.

    Ключевое отличие от текущей ситуации с jvm:
    — если вы однажды сказали new SomeClass — вам не нужно предпринимать какие-то дополнитлеьные усилия по его сохранению/восстановлению между перезапусками самой системы — это делает ОС сама.
    — память-диск-сеть — для вашего процесса представляется единым API, который суть просто передать ссылку на объект.

    Само по себе persistance никакой не прорыв — есть в каком-то виде наверное вообще для всего.
    Сетевая прозрачность тоже давно известная штука, у jvm есть RMI, например. У того же erlang сетевая прозрачность вообще в базовой концепции. Наверняка можно найти еще примеров успешных промышленных реализаций в этом направлении для других популярных инструментов.

    Разница только в том, что в Фантом дадут всё это сразу, в удобном виде, как базовое API.

    Навскидку, если сейчас на jvm взять комплект akka + akka-cluster + akka-persistance, то можно с помощью напильника и какой-то матери получить примерно такую же среду выполнения как планируется в Фантоме. Список современных инструментов, у которых разное проникновение в промышленность, и для которых в виде библиотек реалихзована персистентность и сетевая прозрачность можно продолжать.

    ответы

    1. конечно, у каждого ресурса есть владелец
    2. при завершении процесса, сборщик мусора освободит все ресурсы, которыми владел процесс
    3. Очевидно, что если владелец передал ссылку на ресурс куда-то наружу, но не передал (разделил?) право владения, то возникает вопрос выбора — что с этим ресурсом делать.

    Сборку мусора по счетчику ссылок, в терминах владения можно сформулировать так: если объект получил у «системы» ресурс, и передал ссылку на него в другой объект — то в этот момент он разделил право владения ресурса с тем другим объектом. У ресурса число ссылок — суть число владельцев.

    Посмотрите на Rust, из того, что сейчас на слуху, это самое интересное место, где люди пытаются вот эти вопросы владения/передачи как-то красиво формализовать, что бы обеспечить автоматическое управление ресурсами.
  • Фантом: большая сборка мусора
    0
    как это копирование или некопирование данных влияет?

    Вы предлагаете каждому ресурсу добавить метку — PID владельца.

    это не я предлагаю. Вот, у меня windows вокруг, там есть такая утилита ProcessExplorer, которая залезает во внуренности системы, и показывает очень много чего. Мне, на самом деле, не важно технически, как именно это сделано, потому, что совершенно очевидно, всё это начинается со списка процессов, и далее там как-то к этим процессам подвязано.

    Вот есть документ в памяти, сейчас его владелец — ОС. Документ передали на редактирование какому-то приложению, что произойдёт?


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

    Процесс приложения при редактировании выделил у менеджера памяти пару новых блоков и добавил их в объект документа. Кто владелец новых блоков? Что с ними произойдёт при убиении процесса?


    Вот та функция внутри программы внутри jvm/.Net/итд (которой дали ссылку на объект) запросил еще памяти, ему выдали, что происходит? Кто владелец новых блоков?

    Могу сходу ответить на «что происходит после завершения функции» — если эти ссылки из этой функции никому больше не попали (функция не отдала эту ссылку в результатах своей работы), у них будет ref count = 0, и эти блоки освободит сборщик мусора.
  • Фантом: большая сборка мусора
    0
    я сходу не знаю какой-то одной ссылки, если dz знает — может сам выдаст.

    Запущенная программа имеет процесс, который владеет ресурсами ОС.


    «Процесс» — это такая запись в таблице процессов? А этот самый PID — это номер этой записи? Есть еще что-то важное? Область памяти в которую загружен код, какие-то стандартные дескрипторы stdin, stdout — это всё не важно. Это по сути тоже какие-то данные в той же таблице, которые можно узнать, зная PID.

    Что значит «владеет ресурсами»? Вот, в программе вызывают malloc(), что дальше происходит? Понятно, что основной результат — адрес блока памяти. Но что значит «владеет ресурсами ОС»?

    Если ОС память выдает, то в той самой «таблице процессов» находит PID откуда пришел malloc(), и записывает «выдано памяти, по такому-то адресу, такого-то размера». То есть, «процесс владеет ресурсами ОС» — это тоже тупо запись в каких-то структурах данных внутри ОС, связанных с этим PID?

    Что значит «освободила ресурсы»? Отправила программа в ОС «сообщение»" free()? Никто не заставляет программу освобождать память, перед тем как сказать system.exit()? Что в этом случае происходит? ОС смотрит в те самые таблицы-итд, находит там PID, находит все ресурсы с ним связанные, выполняет какие-то манипуляции с этими дескрипторами, размерами и так далее. Так?

    Что вообще такое «освобождение памяти»? Это отметка, что начиная с такого-то адреса, такой размер блока — свободен. Отметка, опять таки, в какой-то структуре внутри ОС. Как это сейчас принято делать, списки? Деревья?

    То есть, всё вот это — это просто изменение данных в системных структурах. Больше никаких физических действий не происходит.

    Что изменятся если у нас диск от ОЗУ неотличим? Правильно — ни-че-го.
    И это «неотличимо» работает давно, называется «виртуальная память». Если верить википедии, понятие «Вритуальная память» существует с 1956 года. На практике используется с 1969.

    То есть, какова бы ни была среда выполнения, ОС (эта самая среда),

    — запускает процессы
    — выделяет им ресурсы — malloc
    — умет освобождать конкретные ресурсы по просьбе процесса — free
    — умеет освобождать все ресурсы, по завершению процесса — я думаю, что сама запускает free по всему списку

    И мы только что разобрались, что всё это, просто суть данные в каких-то таблицах/списках/деревьяъ/структурах, как там оно реализовано.

    Что такое «протекаюзщая программа»? Программа, которая не вызвает free. Но с точки зрения ОС, это означает, что где-то там в её структурах, есть данные про эти куски памяти. И как только программа говорит system.exit() — ОС знает, все эти ресурсы свободны, и сама вызывает free.

    Кто или что помешает в ОС Фантом реализовать system.exit()?
  • Фантом: большая сборка мусора
    0
    На эту тему автор пишет уже больше десяти (двадцати?) лет, в разных местах.

    процессов в традиционном понимании в этой ОС нет


    Вот у вас сейчас, в классической ОС, программа — это такой файл на диске. Она «остановлена»? Что случается, если вы её «запускаете»? Просто подумайте. А теперь представьте, что диска как такового нет — всё некая память, которая не пропадает сама по себе. Как изменится ваш ответ на тему «запуск программы»?

    Разница между «запущенной программой» и «незапущенной», только в простом факте: «запущенная» программа получает некие события «извне», и может сама какие-то события генерировать, и куда-то там отправлять. Например запросить кусок памяти, обратиться по сети к какой-то другой программе.

    Что означает для программы «завершила работу»? Перестала обрабатывать события извне. По своей внутренней воле. И перестала сама генерировать события. Последнее событие, которое она сгененрировала — сообщила системе — system.exit(0)
  • Фантом: большая сборка мусора
    0
    Только программы периодически перезапускают.


    при невозможности рестарта процесса


    Любой объект можно создать когда нужно, а когда не нужно — убить.
    С чего вдруг какие-то процессы в Фантоме станут неубиваемые или неперезапускаемые? Кто запретит? Таки лично dz будет приходить и говорить, что грешно процессы перезапускать?

    Особенно странно звучит эта гипотеза в рамках концепции платформы, которая принципиально 100% managed.
  • Фантом: большая сборка мусора
    0
    этот мой «гипотетический пример» — он везде вокруг. По крайней мере, пока Фантом не начал массовый захват мира ;)

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

    Если вы сейчас в программе запускаете нить, что бы она сделала для вас полезную работу, нить в ходе этого нажрала гигабайты памяти, что происходит?
    Либо, ссылка на эти гигабайты осталась в стеке, после освобождения стека протухла, и гигабайты подберет сборщик мусора, или нить отдала «полезное нажратое» вам в качестве результата — «на, слушай, сам выкинь, да!» (анекдот про бумеранг)
  • Фантом: большая сборка мусора
    0
    Разница в том, что при закрытии приложение освобождает утекшие ресурсы


    прошу еще раз посмотреть на аналогию. В случае фантома «закрытие приложения» — это суть «завершилась нить» в тех приложениях которые сейчас.

    Куда переносятся какие ресурсы из нити? Вот будет всё то же самое.

    Сейчас, например у jre память можно жестко ограничить при запуске, и процесс внутри, будет получать отлупы.
    Всё ровно то же будет происходить в Фантоме, никакой качественной разницы не будет.
    То, что условно памяти станет несколько ТБ, я заметной разницей не считаю ;)

    Попробую совсем тезисов: архитектура фантома не дает каких-то там заметных преимуществ в автоматическом управлении ресурсами. Наличие мозга у программиста всё еще требуется, аккуратность работы — всё еще важна важна. В то же время, каких-то заметных недостатков тоже нет — если программист с мозгом и аккуратен, на него не свалятся какие-то внезапные проблемы.
  • Фантом: большая сборка мусора
    0
    Сейчас утечка памяти живёт до закрытия приложения. Если файловой системы нет, утечки не на виду.

    Если утечка не на виду, может это и не утечка вовсе?

    Вопрос был в том, не является ли архитектура Фантом особенно к ним уязвимой.

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

    Хотя, за счет более стройной архитектуры в целом, может оказаться, что инструментарий для мониторинга/анализа и может быть даже автоматических каких-то реакций в таких ситуациях, будет проще реализовать.
  • Фантом: большая сборка мусора
    0
    Возьмем, например, String. Это data class? Он может протекать?
    Возьмем, например, какой-нибудь BinaryTree. Это будет data class? Оно сможет протекать? Там будут виртуальные методы? Или, с другой стороны — нужно ли требовать где-то у таких классов отсутствие виртуальных методов?

    «Нет сериализации».
    Те же самые String и BinaryTree — их совсем нельзя будет сериализовать? Кто-то запретит мне из них сделать json или xml? Так и представляю, приходит dz и ufm, и грозят пальцем «ай-ай-ай, не сериализуй! Грешно! Будешь всю жизнь в SOAP долбиться!»

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

    Как и «добавь вывод типов» — тоже. Как и «добавь зависимые типы» — тоже не сделает.
    Инструменты со строгой типизацией помогают человеку меньше ошибаться.
    Вывод типов компилятором — помогают меньше писать руками.
    Зависимые типы — позволяют исключить еще целый класс ошибок, и еще меньше писать руками. Чем больше вы добавляете мозгов/математики инструменту на уровне концепции, чем больше инструмент может проверить, по сути сужая область в которой программист может нафигачить — тем меньше ошибок.

    Но персистентность — это ведь ортогональная штука ко всему этому. Отсутствие сериализации — это просто выкидывание целого класса тупой работы. Это уменьшает количество ошибок, но не концептуально, а рутинно — меньше работы — меньше ошибок.
    Да и потом, давно уже всю сериализацию генерируют, не?
    javaxb, protobuf, и вот это всё.
    Но если у меня есть «документ», как суть, как понятие, он же как-то будет в системе представлен? Будет это data class, или будет это вполне себе smart class — у которого будет внутри какого-то метода while true, но не такой явный, который моймает компилятор, а заумный?

    Если человек хочет прострелить себе ногу — он её прострелит.
    Могу только повторить тот пример, с которого начал — представьте сейчас любую программу на managed платформе, у которой внутри запускаются отдельные потоки. Вот это примерно то же самое. Просто у современных программ есть какие-то отдельные концепции типа «файл», «база данных», «сеть», а Фантому эти концепции ненужны. И просто не нужно будет мне из какого-то BinaryTree, делать BinaryTreeJson, но не потому, что dz меня предаст анафеме, а просто с точки зрения здравого смысла — зачем заниматьая какой-то фигнёй, если можно прям сам объект отдать, и там всё правильно поймут?
  • Фантом: большая сборка мусора
    0
    «файл» — в данном случае, суть «документ», и конечно, есть же сейчас понятие data class?

    Не понимаю, как экземпляр data class может чо-то там сам решать, ну разве что только если у него будут в комплекте какие-то ACL, которые что-то там ограничат. В любом случае — он эе откуда-то взялся, его кто-то создал, и ссылку на него куда-то передал. Или вместе с понятием «владение» или просто, расрашил (полайкал, ретвитнул :)

    И вот этот data class — он сам по себе протекать не может. В него кто-то может че-то напихивать — да. Но ровно так-же, кто-то другой, должен уметь проверить, че там напихали, и лишние удалить.

    А код, который со всем этим работает, по-любому нужно уметь останавливать, хотя бы для того, что бы обновить на новую-свежую версию, которая «уже не протекает»
  • Зачем мне твои неизменяемые коллекции? Они же медленные
    +1
    Я еще в школу ходил, игрушки были еще 2D, но люди уже понимали, что «отрисовывать» то, что не видно — нет никакого смысла. Можно сказать не «реже», а «вообще не нужно».

    Пытаясь вернуться в контекст статьи — если в коллекции «поле» 30000 объектов, то перед отрисовкой нужно сделать viewField.filter(isVisible()), вдруг в итоге останется вообще один объект, потому что игрок носом уперся в стену.
  • Зачем мне твои неизменяемые коллекции? Они же медленные
    +3
    вы правы, вот только «рано остановились», нужно довести эту логику до денег.

    Денег, которые принесут эти 100 пользователей, и денег, которые нужно будет отдать программистам и за аренду сервера. К сожалению, на шаге «перевод в деньги», очень многие обламываются, а он самый важный показатель. Потому, что серверные мощности со временем дешевеют, а программисты — дорожают.

    А практика (увы, подкрепить цифрами не могу) написания кода показывает, что функциональный оптимизировать легче. Он гораздо более наглядно передает суть «что тут вообще происходит», чем императивная лапша.
  • Как использовать implicit'ы в Scala и сохранить рассудок
    0
    Довольно часто из лаконичности и краткости следует понятность.

    Это я не пытаюсь возразить вам, даже наоборот, поддерживаю — нужно очень четко решать и договариваться где когда и зачем. Потому, что вот эти самые «лаконичность краткость понятность» — очень субъективные штуки.
  • Фантом: большая сборка мусора
    0
    Остановка приложения — это Uninstall.

    Это как-то очень странно звучит.

    Приведу простой пример, который (надеюсь) будет понятен всем:
    Приложение, написанное на Java/C#/несуть. Допустим, какая-то обработка данных, которые откуда-то поступают, их как-то обрабатывают, результат обработки — куда-то складывают. Для обработки очередной порции данных, запускают 1-2, да хоть 100500 нитей, из которых в каждый момент времени может получаться довольно замысловатый граф обработки. Но по мере завершения работы, нити останавливают.

    До этого места всё понятно?

    Теперь, представьте, вот это гипотетическое приложение — операционка. А одна гипотетическая нить в нем — приложение пользователя. Пользователю прислали документ, он его открыл, что-то в нём исправил сохранил и окно закрыл.

    Значит ли, что пользователь сделал Uninstall того куска кода, который отрисовывает окно, документ в нём, обрабатывает события итд? Очевидно — нет. Как был в бинарнике приложения кусок кода — так он там и остался. Должен ли быть «запущен» тот кусок кода или нужно «останавливать нить»?
    Не знаю, но не вижу никаких проблем поступать хоть так, хоть эдак.
  • Фантом: большая сборка мусора
    +1
    Согласно персистентной модели, приложение запускается один раз и на всю жизнь.


    Тут нужно обратить внимание, что никто не запрещает приложению завершать работу.
    «Вся жизнь» — то время, которое необходимо приложению, что бы выполнить полезную для пользователя работу.
  • Обзор систем мониторинга серверов. Заменяем munin на…
    0
    то есть это SQL Server performance monitoring
  • Обзор систем мониторинга серверов. Заменяем munin на…
    0
    потратил минуту на сайте Quest Software не нашел даже раздел где брать на посмотреть.
    Только маркетинговое бла-бла-бла, как круто они умеют всё мониторить.
  • Russian Minesweeper — мультиплеерная версия игры «Сапёр»
    +1
    Боты, увы, это самый очевидный «ответный шаг», как только будет рейтинг, и этот ответ обесценит сам рейтинг.

    А сейчас еще модно нейронки тренировать, не удивлюсь если кто-то решит сделать бота на модных технологиях :)
  • Russian Minesweeper — мультиплеерная версия игры «Сапёр»
    +1
    конечно, всякие очки начнут иметь смысл как только будет глобальный рейтинг.

    Думаю, по ходу дела, еще может всякое напридумываться, по каким критериям ранжировать.
    Поэтому общая идея такая — все метрики по ходу игры куда-то складывать.

    еще навскидку
    — количество таймаутов
    — сколько раз сдавался
    — сколько ходов сделал до выигрыша
    — сколько ходов «продержался», максимум, минимум, среднее

    в общем, казалось бы, такая простая игра, но перевод её в многопользовательскую открывает бездны :)

    Одна беда со всем этим — достаточно просто пишутся боты, да и математика для бота не сильно сложная. По ходу игру совсем примитивная-локальная, в «сложных» — посчитать вероятности…

    В любом случае — спасибо, вспомнил юность, залип на час

    — а если сделать командную… :))))
  • Russian Minesweeper — мультиплеерная версия игры «Сапёр»
    +1
    и да, конечно общее затраченное на раздумья время тоже как-то можно учитывать в рейтингах
  • Russian Minesweeper — мультиплеерная версия игры «Сапёр»
    0
    не-не-не, когда играют двое, из расстановки флагов можно получать более точную оценку кто лучше играет.

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

    Например, противник подорвался на мине, которую я правильно пометил флагом — мне плюс дополнительный балл.
    Или, я открываю одним нажатием несколько клеток (это при правильной расстановке флагов) — тоже можно как-то болше баллов давать.
  • Язык программирования SPL — пример решения задачи
    +1
    Очень сложно в одной статье описать целый язык. Даже если вкратце пробежаться по синтаксису, возможностям и особенностям, то получится очень большой текст, фактически — перепечатка документации по языку.


    Познакомьтесь со статьями на википедии про Lisp, Smalltalk, Scheme, Python, Ruby… Список можно продолжать, пока языки не закончатся… APL, K. J…

    Ни одна из этих статей не являются документацией по языку, но дают хорошее представление (и не только)
  • ArcaOS 5.0 — новая версия OS/2 стала доступна широкой публике
    0
    но зачем?!
  • Как правильно писать логи (?)
    +2
    Давайте посчитаем, мне так сложно сравнить. Возьмем более круглые значения для ровности

    10 типов документов, 60 событий в минуту (1 в секунду). 3600*10 строк в час? 24 часа?
    864000 строк в сутки?

    Взял навскидку из багрепорта посылку, там логи порядка 100М за сутки — 440803 строки, например. Похоже на вашу ситуацию? Всего в два раза меньше.

    У нас «правильное логгиирование» обязует разработчика использовать loglevel'ы, вполне опредленным образом

    * DEBUG — то, что будет читать только разработчик
    * INFO — то, что может почитать инженер поддержки, но не факт
    * WARNING — то, что читает инженер поддержки
    * ERROR — то, что обязательно читает инженер поддержки, и на что реагируют алерты.

    итак, из этик 440К строк:

    * DEBUG — ~356K
    * INFO — ~81K
    * WARNING — 3K
    * ERROR — 86 строк

    Еще раз — я не против ELK. Даже очень за. Но вот сейчас мне хватило просто grep и wc -l, что бы выдать вам эти цифры. Ровно так-же, зная имена модулей, и дальше по архитектуре приложения, я могу получать простым grep'ом нужные срезы. Вот, например, есть у нас некий «ServiceManager» — он в этот лог написал ~253K строк. И в то же время, было всего 123 строки, когда этот самый «ServiceManager» писал «Can't connect to host».

    Это просто одна команда:

    grep ServiceManager" some.log | grep «Can't connect to host» | less

    Вы говорите, что практически невозможно написать такую команду?

  • Как правильно писать логи (?)
    0
    Писать логи — легко. Ниже написал комментарий «в общем виде». Складывание в ELK и прочие инструменты — конечно, но эти инструменты должны облегчать жизнь вполне конкретным людям. То есть задачу «писать правильно лог» — нужно рассматривать как одно из требований к продукту.

    > В результате все равно гиганские стены текста.

    Простите, не понимаю. Лог, а по-русски, «протокол» — это такой поток записей. Причем, в общем случае, на эти записи накладываются совсем небольшие требования, типа «иметь отметку времени» и «иметь loglevel». Если вам этих требований для структурирования мало — никто не мешает в log message добавить то, что облегчит вам фильтрацию. Хоть grep'ом, хоть ELK, хоть еще чем-то.

    Не вижу вообще никаких проблем. Если это ваш продукт — вы сами пишите логи для себя.
    Когда люди готовят для себя еду, они же не насыпают туда килограммы соли или перца, что есть невозможно? Бывает, в первый раз сыпанул, но есть же второй раз, третий раз…
  • Как правильно писать логи (?)
    0
    Что бы правильно писать лог, нужно как можно более четко понимать зачем. Если говорить более формально — какой у вас общий процесс (вашей работы) работы, в котором потребуется читать этот лог?

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

    Инструмент разработки — не важен, даже если никаких удобных библиотек нет, и у вас просто вывод строк в stdout, туда можно и нужно писать так, что бы достигать цель. Навскидку, целей две:

    * оперативное оповещение о проблемах
    * разбор инцидентов

    После того, как с целями разобрались, нужно выяснить, кто пользователи. Опять-же, навскидку

    * дежурный службы поддержки
    * сервисный инженер
    * разработчик

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

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

    Аналогично можно предположить, что для сервисного инженера, который будет разбираться с инцидентом, километровые traceback'и мало что скажут, а вот возможность четко понять какой модуль (с прикладной точки зрения) и в какой момент поломался, или что именно сделал «не так» — важно.

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

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

    Какие сообщения на какой loglevel выводить, нужны ли логах traceback'и или нет, и вот это всё.

    После «пилота», непременно нужно провести фазу тестирования: смоделировать проблемы, взять пользователя, выдать ему лог с зафиксированной проблемой и получить обратную связь.

  • Как правильно писать логи (?)
    0
    если вы копаетесь в логах несколько часов — значит вы их неправильно пишите.

    даже если на продакшине всегда включен DEBUG — кому-то использовать grep религия не позволяет?
  • Connecting to xxx.xxx.xx.xxx:443… failed: Unknown error или предупрежден — значит вооружен
    +1
    написать всегда есть смысл — затрат мало.
  • Клинический анализ крови: от светового микроскопа к гематологическим анализаторам
    0
    Подавляющее большинство лабораторного оборудования имеет интерфейсы для подключения в ЛИС/МИС.
    RS-232 наиболее распространён, но уже давно появляются приборы у которых свой отдельный эзернет, и подключение по tcp. Внутри этого rc-232/tcp бегает или ASTM, или HL7, или что-то своё. В любом случае, производитель прибора выдает спецификацию, и почти всегда работает так, как в спецификации.

    На счет морфологии, бекмановская гематология одна из наиболее продвинутых. Но насколько я смог заметить, полностью от микроскопии никто не отказывается. Если прибор выдает патологию, то очень вероятно, что лейкоцитарную формулу будет считать еще и врач глядя в микроскоп.
  • Почему много JOIN в запросе это плохо или не мешайте оптимизатору
    +3
    про оракловый оптимизатор вообще никаких интриг:

    Дж. Льюис, ORACLE: Основы стоимостной оптимизации.

    На русском издавали, например «Питер», аккурат десять лет назад.
  • Почему много JOIN в запросе это плохо или не мешайте оптимизатору
    +2
    Планировщик запроса — это просто алгоритм. Он может быть плохим, конечно. Книжка которую я читал про оракловый, охватывала версии оракла 8, 9, 10, и автор прям наглядно показывал, как планировщику от версии к версии добавляют мозгов, и ситуации, когда эти «более умные» мозги принимают решения хуже, чем было.

    Меня удивляет отношение человека, с опытом 10 лет.

    В моём понимании, «планировщик запроса» — это такая данность, как восход Солнца. И довольно глупо ругать Солнце, что оно утром светит в окно и мешает спать. Самое простое — добавить к «окно на восток», хорошие светонепроницаемые шторы.

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




    Кстати, отдельный вопрос — когда вообще нужно собирать результаты из 20-ти таблиц? Можно хотя0бы намекнуть на прикладную область, и что за данные такого рода запросом вытаскивали?

  • Почему много JOIN в запросе это плохо или не мешайте оптимизатору
    +1
    Про оракловый оптимизатор даже книга отдельная есть, где не просто рассказывают «как оно работает», а на каждый аспект набор тестов, которые можно взять и по-запускать на своей базе.

    После чтения такой книги, очень странно слышать слова «негативные отзывы от специалиста с 10 лет работы».
  • Делаем более-менее универсальный калькулятор услуг для сайта
    0
    конечно
  • Делаем более-менее универсальный калькулятор услуг для сайта
    0
    Решил авторизоваться через fb



    Это прекрасно.
  • Куда деваются программисты после 40
    +2
    им не нужно повышать вот так свой уровень.

    Сейчас «развлекаюсь» тем, что у новым задачам линкую писанные мною несколько лет назад, на эту же тему.
  • О чём молчат авторы «Hello, World!»-ов
    0
    У нас в рамках компании один стиль. Сколько бы проектов не было.

    не обращая внимания на несущественные особенности

    Вы считаете, что мои слова «стиль затрагивает не только форматирвание» — это несущественные особенности, и не обращаете на них внимание?

    Есть еще интересный факт — умение читать разные стили, совсем не избавляет от требования писать в рамках одного проекта в одном стиле (который принят в этом проекте). Даже не касаясь производительности и бизнес-показателей — это элементарное уважение к коллегам.

    Точки с запятой в конце строк — смешно, а вот, скажем, алиасы таблиц в sql-запросах, единый подход к выбору имен идентификаторов — тоже смешно? Идем дальше — единый порядок аргументов функций для API?

    Вот, из недавного, что меня удивляло: модуль, который дает удобные методы работы с целым пластом данных. Среди них всякие выборки/срезы. Среди них — есть срезы по времени. Для меня очевидно, что если функция принимает аргументы date_start, date_end, то у всех функций с аналогичной семантикой в этом модуле (а лучше, во всём проекте), если есть два таких аргумента, они как минимум должны называться одинаково.
    А еще, например, в Oracle PL/SQL, нет удобного способа вернуть курсор с данными поэтому у процедур из которых нужно возвращать данные, последний аргумент что-то типа P_RC IN OUT REF_CURSOR.
    Хорошее требование, всегда этому аргументу давать одинаковое имя? Или RC, RC1, P_RC, P_RC1, P_CURS, CUR — нормально, все ведь прочтут, все натренировали толерантность и не испытывают боль?

    Пример с RC/итд из реального исходника -
     grep "OPEN .* FOR" some_source.pkg
    
    — 91 штука всего, 6 разных вариантов, преобладает P_RC.
  • О чём молчат авторы «Hello, World!»-ов
    0
    Конечно художник в единицу времени приносит больше ценности бизнесу. Но если он за дополнительные 25 минут сможет заменить 250 часов работы маляров — зачем тогда маляры?

    О какой толерантности может идти речь, если яркие личности со своим стилем становятся счастливее и работают эффективнее? (на минутку стал на другую сторону)

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

    И хочу акцентировать — в общем случае стиль затрагивает не только в форматировании исходников.