Pull to refresh
15
0
bormotov @bormotov

User

Send message
не-не-не, когда играют двое, из расстановки флагов можно получать более точную оценку кто лучше играет.

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

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


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

Ни одна из этих статей не являются документацией по языку, но дают хорошее представление (и не только)
Опять-же, я не знаю что лучше. Приняли решение показать — значит они считают, что нужно показать, даже вот так.

Про парня geohot я читал краем глаза всё время. И что-то мне подсказывает, что ребята из Яндекса не только читали, но скорее всего общались с ним, смотрели в его код (оно же вроде всё опубликовано?) а может он на них работает.

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

Есть проблема, как заметили выше «нейтрального положения»? — Ну ок, есть. Оформлена тикетом? Эту проблему когда нужно иметь решенной? Сроки поставлены? К этому релизу? К следующему? Через год?

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


Даже в названии ролика написано «первая демонстрация». И пишут, что занимаются этим направлением год.
Вы так смело утверждаете, о чем имеют понятие разработчики, а о чем нет, что я даже не знаю, что бы я мог ответить на ваш вопрос по сути.

Первое, что приходит в голову (простите), фраза, как-то типа
«Да, в Lukas Art, знают. что импульс лазера не издает звук и вообще звуки в космосе не слышны».

Второе, что приходит в голову, эпизод из фильма «Доктор Голивуд», когда главный герой заходит в автомастекскую и обнаруживает свою машину разобранную, слова, которые ему сказал мастер.
а еще классические споры МКПП против АКПП ;)

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

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

уже второй комментарий про руль. Наверняка примерно так же говорили «опытные водители» про ABS, гы.
ключевые слова «по моим наблюдениям». А теперь, просто представьте — сколько народу ездит с Я.Навигатором? «Нарушает правила» — это же не должно быть сильно большой проблемой для фильтрации. Скоростной режим, разрешенные повороты — это всё известно. И если в каком-то месте конкретный трек нарушает правила, он легко отбрасывается, или наоборот — учитывается как отрицательный пример — «так делать нельзя». А дальше работает статистика.
Ваш сарказм, немного не дотянул…

Провод меняется отдельно. Что характерно, у топовоых моделей наушников это довольно часто — UE, Westone и так далее — провода съемные.
Давайте посчитаем, мне так сложно сравнить. Возьмем более круглые значения для ровности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

если вы копаетесь в логах несколько часов — значит вы их неправильно пишите.

даже если на продакшине всегда включен DEBUG — кому-то использовать grep религия не позволяет?
написать всегда есть смысл — затрат мало.
Подавляющее большинство лабораторного оборудования имеет интерфейсы для подключения в ЛИС/МИС.
RS-232 наиболее распространён, но уже давно появляются приборы у которых свой отдельный эзернет, и подключение по tcp. Внутри этого rc-232/tcp бегает или ASTM, или HL7, или что-то своё. В любом случае, производитель прибора выдает спецификацию, и почти всегда работает так, как в спецификации.

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

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

Лично я пытаюсь пояснить людям, почему это так.

И вопрос не в допусках, не в необходимости что-то рассчитывать, соблюдать, заканчивать курсы.

Вопрос в том, что если автомобиль сделали так, что нужно снять полностью бампер (например, кто-то выше в комментариях рассказал), что бы добраться до этой самой лапочки, то скорее всего не подразумевали, что это будет делать сам водитель в полевых условиях.
Кроме того, что нужно откуда-то узнать знать, с какой стороны начать, нужны инструменты (у нас в машине нет комплекта отверток даже, не нужны), и мне бы было спокойнее такое делать глядя в какую-нибудь инструкцию с картинками, где будут стрелочками указаны места какие винты в какой последовательности откручивать. Да, и еще, видимо, нужно иметь в запасе лампочки. У отца в машине был комплект лампочек. У нас — нет. Не нужно.

Что характерно, задача «заменить колесо» гораздо проще:
— баллонный ключ есть в комплекте
— какие винты откручивать — есть в прилагаемой инструкции (да и так видно)

Я достаточно четко описал разницу?
Ок, движение запрещено — останавливаетесь, вызываете специалистов. Я не предлагаю ждать несколько часов. Я пытаюсь показать один из вариантов того, как рассуждает производитель при выборе технического решения.
У производителя, например, могут быть данные, что эвакуатор приезжает в среднем течении 20 минут, а больше чем час — один случай из 10000.

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

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

На всякий случай, еще раз: не пытаюсь защитить производителя, сам считаю, что «всё должно быть просто, удобно и надежно».
Но у подавляющее большинства людей другой комплект требований. Им пофиг на простоту и надежность, чуть меньше чем полностью. А вот их личный комфорт, и цена этого комфорта — важны. И да, у всех разное понимание «личный комфорт».
Производители автомобилей давно уже рассматривают машину не как «завершенный продукт», а как один из элементов большого бизнес-процесса.
Почему вы решили, что замена лампочки ДОЛЖНА производиться водителем?
И откуда вот эти требования «две минуты», «на темной дороге»?
про «одноразовость авто» давно уже написано замечательное

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity