Конечно. Проблема в том, что все лого-вьюверы-анализаторы, которые я видел, работают со строками. Строка — якобы одна запись в логе, и запись в логе — якобы одна строка. Сомнительное допущение. Внезапно бывают приложения, которые пишут многострочные сообщения в лог. Например:
// Одна строка:
2020-07-16T17:05:00.123 ERROR Something went wrong!
// Много строк:
2020-07-16T17:05:00.123 ERROR Something went wrong! SmthWrongException:
stacktrace
stacktrace
stacktrace
stacktrace
stacktrace
stacktrace
// Одна строка:
2020-07-16T17:05:00.123 INFO Request received: {"data":{"action":"delete","id":"123qwe"}}
// Много строк:
2020-07-16T17:05:00.123 INFO Request received:
{
"data":
{
"action":"delete",
"id":"123qwe"
}
}
Для примера с переносами строк типичный поиск работает очень плохо, если нужно найти записи, где action было delete для некоторого id. В вырожденном случае, как здесь, можно искать "delete.*\n.*123qwe", но не всегда известно количество строк между delete и 123qwe. Поиск по "delete|123qwe" выдаст кучу мусора. Между тем, для нормального поиска есть вся информация. Ну, конечно, с вводом message pattern'а: "{YYYY-MM-DDThh:mm:ss.fff} {level} {message}" — где {message} может содержать переносы строки.
Хороший функционал. Давно нечто подобное ищу, отчаялся, уже начал сам писать себе вьювер для логов) У вас там функционала для работы (хотя бы поиска) с многострочными сообщениями нет? Кому как, но для меня это была бы киллер-фича. Нигде не смог такого найти.
В случае с адресами, конечно, маловероятно, но в общем виде — где сегодня семь параметров, завтра восемь, послезавтра девять. Сегодня они передаются в один метод, у которого поменяете интерфейс, а завтра в два метода, а послезавтра будете менять уже интерфейсы трёх методов (не считая тестов). А если ещё не все параметры обязательные и внезапно кто-то здраво решит, что нужно не null передавать, а сделать перегрузки с набором только обязательных аргументов, это все стремится превратиться в локальный адок и место множественных опечаток. Кучка конструкторов у класса Address выглядит более удобным решением. Пользователь метода всегда знает, что вызывает метод с валидным параметром, метод не отвечает за полноту данных адреса — за это очень предсказуемо отвечает класс Address, и ошибка контролируется на этапе инстанцирования. Мне кажется, все очень складно получается.
Развести 100 мл перекиси в 6 раз это чуть более полулитра, как раз необходимый объём для погружения кистей в раствор. Сколько раз можно/целесообразно таким раствором пользоваться?
Там не продукты упоминаются, а категории (ECCNы, Export Control Classification Number):
Specifically, this rule adds the following Export Control Classification Numbers (ECCNs) in the categories of materials processing, electronics, telecommunications, information security, sensors and lasers, and propulsion to the supplement: 2A290, 2A291, 2B999, 2D290, 3A991, 3A992, 3A999, 3B991, 3B992, 3C992, 3D991, 5B991, 5A992, 5D992, 6A991, 6A996, and 9B990
Возможно, у меня с вами и автором разное видение того, что такое «задачи бизнеса». В моём понимании, в контексте возмущения «не хочу решать задачи бизнеса, хочу программировать», это все противоположное решению программистских задач красиво, интересно, с проявлением творчества, перепробовав энное количество подходов и выбрав лучший, bleeding edge и state of art. То есть все, чему как раз и мешают «граничные условия»: мы не можем переписать это легаси на последней версии языка, потому что оно просто приносит деньги, и нужно просто латать некоторое количество багов в неделю, а не делать проект лучше, это бизнесу не нужно.
Да, я понимаю основной посыл — если Подрядчик не подумал заранее, это проблема Подрядчика. Но зачем такая хитрая формулировка? Это же сводится к утверждению «договорная цена не может быть изменена» или я неправильно понимаю?
У меня нет опыта работы в аутсорсинге, но есть в промавтоматизации (нефтянке, энергетика) — там картина прямо противоположная, часто договоры дешевые, на грани или даже за гранью рентабельности, но потом добиваются допсоглашениями до приемлемой стоимости. Следствие порочной системы тендеров.
А это как? Подрядчик вправе требовать изменения стоимости, но Подрядчик несёт риск удорожания (то есть всё что свыше изначальной цены из договора — за счёт Подрядчика?) Это будет стоить дороже на n рублей, но мы сами себе заплатим?
Но ведь ваши примеры ошибочны. Врачи, бывает, как раз думают, как бы побольше денег вытянуть, инженеры самолёта укладываются в смету (смета, деньги — ограничения бизнеса) и запросы заказчика (посадить как можно больше пассажиров на квадратный метр — или джакузи поглубже на борту), проектировщик моста построит разные мосты в центре города и на загородной трассе, потому что в городе должно быть красиво и статусно, а на трассе — дёшево и сурово. Нет?
Интегрироваться через квик это изврат) Я рассматриваю вариант не HFT, думаю, для начала (для дева и тестирования, как минимум) подойдёт деплой в AWS/Azure. Тащить туда QUIK это лишние проблемы.
Раньше была идея сделать разработку публичной, но позже я от нее отказался
Если не секрет — почему? Чтобы не плодить конкурентов или другие причины?
Можете немножко рассказать про биржевые/брокерские API? Я по вечерам пытаюсь написать что-то подобное, один из открытых вопросов — интеграция. Есть какие-то стандартные или хотя бы массово популярные протоколы, или у всех всё своё? До брокеров пока с этим вопросом не добрался, да и вряд ли у них есть на попробовать бесплатно, а платить я пока не готов — процесс движется медленно, это будет куча денег на ветер. Как вы решали этот вопрос?
Очень крутой аэропорт в Хельсинки, от интерьера до питьевой воды из крана и милой сувенирки местного производства. Если рассматриваете, не написать ли о нем что-нибудь интересное — пишите, пожалуйста! :)
Отделка «под дерево», ммм, когда же это закончится.
А зачем вообще что-то принципиально в плацкарте менять? Единственное достоинство плацкарта — цена, разве нет? Мне кажется, лучшее, что можно сделать — повысить качество сборки и материалов, чтобы не гремело, добавить звукоизоляции, чтобы не так слышно было храпящего соседа за перегородкой.
А вот робо-пылесосы прокачать нормальной системой навигации было бы круто. А то они, судя по слухам, все ещё тупые и застревают в самых неожиданных местах.
// Одна строка:
2020-07-16T17:05:00.123 ERROR Something went wrong!
// Много строк:
2020-07-16T17:05:00.123 ERROR Something went wrong! SmthWrongException:
stacktrace
stacktrace
stacktrace
stacktrace
stacktrace
stacktrace
// Одна строка:
2020-07-16T17:05:00.123 INFO Request received: {"data":{"action":"delete","id":"123qwe"}}
// Много строк:
2020-07-16T17:05:00.123 INFO Request received:
{
"data":
{
"action":"delete",
"id":"123qwe"
}
}
Для примера с переносами строк типичный поиск работает очень плохо, если нужно найти записи, где action было delete для некоторого id. В вырожденном случае, как здесь, можно искать
"delete.*\n.*123qwe", но не всегда известно количество строк между delete и 123qwe. Поиск по"delete|123qwe"выдаст кучу мусора. Между тем, для нормального поиска есть вся информация. Ну, конечно, с вводом message pattern'а:"{YYYY-MM-DDThh:mm:ss.fff} {level} {message}"— где{message}может содержать переносы строки.Не встречал такого. Можно пример?
В случае с адресами, конечно, маловероятно, но в общем виде — где сегодня семь параметров, завтра восемь, послезавтра девять. Сегодня они передаются в один метод, у которого поменяете интерфейс, а завтра в два метода, а послезавтра будете менять уже интерфейсы трёх методов (не считая тестов). А если ещё не все параметры обязательные и внезапно кто-то здраво решит, что нужно не null передавать, а сделать перегрузки с набором только обязательных аргументов, это все стремится превратиться в локальный адок и место множественных опечаток. Кучка конструкторов у класса Address выглядит более удобным решением. Пользователь метода всегда знает, что вызывает метод с валидным параметром, метод не отвечает за полноту данных адреса — за это очень предсказуемо отвечает класс Address, и ошибка контролируется на этапе инстанцирования. Мне кажется, все очень складно получается.
Развести 100 мл перекиси в 6 раз это чуть более полулитра, как раз необходимый объём для погружения кистей в раствор. Сколько раз можно/целесообразно таким раствором пользоваться?
Все винды и офисы относятся к 5D992.c, все айфоны с эйрпоцами — к 5A992.c.
Возможно, у меня с вами и автором разное видение того, что такое «задачи бизнеса». В моём понимании, в контексте возмущения «не хочу решать задачи бизнеса, хочу программировать», это все противоположное решению программистских задач красиво, интересно, с проявлением творчества, перепробовав энное количество подходов и выбрав лучший, bleeding edge и state of art. То есть все, чему как раз и мешают «граничные условия»: мы не можем переписать это легаси на последней версии языка, потому что оно просто приносит деньги, и нужно просто латать некоторое количество багов в неделю, а не делать проект лучше, это бизнесу не нужно.
Да, я понимаю основной посыл — если Подрядчик не подумал заранее, это проблема Подрядчика. Но зачем такая хитрая формулировка? Это же сводится к утверждению «договорная цена не может быть изменена» или я неправильно понимаю?
У меня нет опыта работы в аутсорсинге, но есть в промавтоматизации (нефтянке, энергетика) — там картина прямо противоположная, часто договоры дешевые, на грани или даже за гранью рентабельности, но потом добиваются допсоглашениями до приемлемой стоимости. Следствие порочной системы тендеров.
А это как? Подрядчик вправе требовать изменения стоимости, но Подрядчик несёт риск удорожания (то есть всё что свыше изначальной цены из договора — за счёт Подрядчика?) Это будет стоить дороже на n рублей, но мы сами себе заплатим?
Но ведь ваши примеры ошибочны. Врачи, бывает, как раз думают, как бы побольше денег вытянуть, инженеры самолёта укладываются в смету (смета, деньги — ограничения бизнеса) и запросы заказчика (посадить как можно больше пассажиров на квадратный метр — или джакузи поглубже на борту), проектировщик моста построит разные мосты в центре города и на загородной трассе, потому что в городе должно быть красиво и статусно, а на трассе — дёшево и сурово. Нет?
Если не секрет — почему? Чтобы не плодить конкурентов или другие причины?
Очень крутой аэропорт в Хельсинки, от интерьера до питьевой воды из крана и милой сувенирки местного производства. Если рассматриваете, не написать ли о нем что-нибудь интересное — пишите, пожалуйста! :)
Типичный паттерн Event Broker, со всеми вытекающими плюсами и минусами.
А зачем вообще что-то принципиально в плацкарте менять? Единственное достоинство плацкарта — цена, разве нет? Мне кажется, лучшее, что можно сделать — повысить качество сборки и материалов, чтобы не гремело, добавить звукоизоляции, чтобы не так слышно было храпящего соседа за перегородкой.
А how-to’шкой кинете, как это сделать, если есть? Для тех, кто про fpga только слышал)
Не знаете, можно там как-то скейлить видео, чтобы обрезать края, но занять черые зоны внизу и вверху?
А вот робо-пылесосы прокачать нормальной системой навигации было бы круто. А то они, судя по слухам, все ещё тупые и застревают в самых неожиданных местах.