Это блог компании МТС на Хабре. Для Хабра важно только количество просмотров, а компания МТС, очевидно, считает такую статью достойным пополнением своего многогранного маркетингового образа.
Комменты не читают ни первые, ни вторые. Но читают подписчики хаба "Космонавтика", и мы тут все разделяем ваше негодование.
После замены любой платы заново начинается программа испытаний, о длительности которой мы можем только догадываться. Но в 90е годы это скорее всего было долго (учитывая описанный антураж с ручным подключением).
До запуска оставалось две недели, следующее окно через несколько лет.
И всегда удивляюсь, что энтузиасты пассивного охлаждения вообще не задумываются о том, что при наличии 3D-модели можно посчитать теплообмен в каком-нибудь CFD пакете.
Вот накопить денег, заказать фрезерование, покрытие и пр. - это да, это ребята уважают.
Есть еще один аспект, который мне однажды подсказали: "перед началом работы спроси себя, кому я смогу это продать?"
Понимать нужно в самом широком смысле, но в случае ИТ-специалиста это значит "перед вхождением в долгий проект спросите себя, насколько полезна будет в вашем резюме эта запись, увеличит ли она вашу ценность в глазах следующего работодателя"
И вот у костылей есть одно важное отличие - они уникальны для каждой системы. Опыт, полученный на проекте, состоящем из костылей, довольно сложно потом применить "по специальности". Там, конечно, будет прокачана целеустремленность, вера в светлое будущее и стрессоустойчивость, но это типа софт-скиллы. А по основному роду деятельности - костыли, непригодные для других компаний.
Любая организация, проектирующая систему (трактуется здесь шире, чем просто информационная система), неизбежно создаст такую модель, которая будет повторять коммуникационную структуру самой организации.
Код, состоящий из IF, как правило признак костыльности.
При всей моей любви к суровому производству, скажу, что архитектор со стороны к вам после этой статьи не придет. Потому что невозможно построить архитектуру из костылей. Строить можно, а построить нельзя.
timestamp означает "просто время, без даты, часового пояса или чего-то другого"
Надеюсь, что это у вас опечатка насчет "без даты". В PG пишут, что там и дата и время с разрешением в 1 микросекунду. Ну и в статье вы сами при сравнении показываете наличие дат: _ now | now _ ----------------------------+------------------------------- 2023-06-28 21:49:56.417841 | 2023-06-28 21:49:56.417841+03
Хорошая статья, но пример применения "время для напоминания в будущем, для будильника или другого действия по расписанию" лучше выпилить. Время timestamp, которое из базы получит клиент - это не время относительно начала сферических суток в вакууме, это вполне конкретный момент времени на определенную дату.
Как только клиент начнет вычисления с этим значением, он пойдет по тропинке, устланной граблями - он же в другом часовом поясе, а значит может оказаться и в стране, где переходят на зимнее/летнее время.
Короче, хранение времени нужно спокойно и вдумчиво проектировать, без должного внимания с любым форматом можно огрести проблемы.
Про ошибки 400 vs 500 - принцип простой: ошибки 4xx означают, что если клиент изменит что-то в своем запросе, то он может быть получит результат. https://www.rfc-editor.org/rfc/rfc9110.html#name-client-error-4xx Ошибки 5xx означают, что от действий клиента ничего не зависит - где-то внутри сервиса при обработке запроса всё идет плохо. https://www.rfc-editor.org/rfc/rfc9110.html#name-server-error-5xx Однако на практике это означает необходимость ручного анализа возникающих на сервере ошибок и принятия решения по каждой, что выдавать: 400 или 500. Сами понимаете, на это подпишется не всякая команда разработки.
Есть и приколы. Некоторые системы допускают более широкое толкование понятия "действий клиента". Например SaaS позволяющий изменять конфигурацию купленного сервиса. Бывает, что клиент так наизменяет, что сервис выпадает с внутренней ошибкой 500. И для того, чтобы донести до клиента информацию, что он сам может исправить ситуацию, приходится совершенно очевидную ошибку 500 (сервис подняться не может) преобразовывать в 400.
Перечитал статью, посмотрел исходники: когда вы в промежуточном сервисе ProcessExecutor создали список запросов - вы создали у своего сервиса state, он как-бы перестал быть "чисто-рестовым". public static List<RequestDTO> Requests { get; set; } = new List<RequestDTO>(); Теперь при отключении инстанса (а при масштабировании на это надо закладываться) этот state потеряется. Клиенты должны будут самостоятельно решать, какие транзакции отправлять повторно, какие признать выполненными.
Кажется, ваш кейс решается в терминах многозадачности: вы выбрали кооперативную, когда задача не отдает разделяемый ресурс до своего завершения. А можно выбрать вытесняющую, когда разделяемый ресурс выделяется задачам небольшими кусками.
В терминах операционных систем разделяемый ресурс - это процессорное время. В терминах вашей задачи - это количество обрабатываемых транзакций.
Все пачки придется разделить на блоки по 1000 транзакций, блоки обрабатывать последовательно для каждой пачки.
В итоге получается т.н. планировщик, и это тоже термин из области многозадачности.
А мне этот случай запомнился тем, что аргументы Диффи в итоге не привели к признанию патента недействительным, и TQP выиграл дело.
Адвокат TQP избрал линию на создание сомнений в репутации Диффи как ученого: тот не получал ученую степень, и не преподавал в учебных заведениях, а только работал там:
Diffie never completed a master’s degree, nor has he held a full time academic position
Я, помню, неделю был под впечатлением от того, что такое может прокатить в суде.
Это блог компании МТС на Хабре. Для Хабра важно только количество просмотров, а компания МТС, очевидно, считает такую статью достойным пополнением своего многогранного маркетингового образа.
Комменты не читают ни первые, ни вторые. Но читают подписчики хаба "Космонавтика", и мы тут все разделяем ваше негодование.
После замены любой платы заново начинается программа испытаний, о длительности которой мы можем только догадываться. Но в 90е годы это скорее всего было долго (учитывая описанный антураж с ручным подключением).
До запуска оставалось две недели, следующее окно через несколько лет.
Ух ты, какой-то новый космодром построили!
[7] Dobrovolskii M. B., “Liquid rocket engines: design basics”, Batman Moscow State University
Феерично: Ba
tman Moscow State UniversityБуду рад помочь советом.
Плюсую.
И всегда удивляюсь, что энтузиасты пассивного охлаждения вообще не задумываются о том, что при наличии 3D-модели можно посчитать теплообмен в каком-нибудь CFD пакете.
Вот накопить денег, заказать фрезерование, покрытие и пр. - это да, это ребята уважают.
Есть еще один аспект, который мне однажды подсказали:
"перед началом работы спроси себя, кому я смогу это продать?"
Понимать нужно в самом широком смысле, но в случае ИТ-специалиста это значит "перед вхождением в долгий проект спросите себя, насколько полезна будет в вашем резюме эта запись, увеличит ли она вашу ценность в глазах следующего работодателя"
И вот у костылей есть одно важное отличие - они уникальны для каждой системы. Опыт, полученный на проекте, состоящем из костылей, довольно сложно потом применить "по специальности". Там, конечно, будет прокачана целеустремленность, вера в светлое будущее и стрессоустойчивость, но это типа софт-скиллы. А по основному роду деятельности - костыли, непригодные для других компаний.
70 % алгоритма — это IF для разных случаев жизни
Это одна из лучших иллюстраций закона Конвея:
Любая организация, проектирующая систему (трактуется здесь шире, чем просто информационная система), неизбежно создаст такую модель, которая будет повторять коммуникационную структуру самой организации.Код, состоящий из IF, как правило признак костыльности.
При всей моей любви к суровому производству, скажу, что архитектор со стороны к вам после этой статьи не придет. Потому что невозможно построить архитектуру из костылей. Строить можно, а построить нельзя.
Растите архитектора внутри коллектива.
timestamp означает "просто время, без даты, часового пояса или чего-то другого"
Надеюсь, что это у вас опечатка насчет "без даты". В PG пишут, что там и дата и время с разрешением в 1 микросекунду.
Ну и в статье вы сами при сравнении показываете наличие дат:
_ now | now _----------------------------+-------------------------------
2023-06-28 21:49:56.417841 | 2023-06-28 21:49:56.417841+03
Хорошая статья, но пример применения "время для напоминания в будущем, для будильника или другого действия по расписанию" лучше выпилить.
Время timestamp, которое из базы получит клиент - это не время относительно начала сферических суток в вакууме, это вполне конкретный момент времени на определенную дату.
Как только клиент начнет вычисления с этим значением, он пойдет по тропинке, устланной граблями - он же в другом часовом поясе, а значит может оказаться и в стране, где переходят на зимнее/летнее время.
Короче, хранение времени нужно спокойно и вдумчиво проектировать, без должного внимания с любым форматом можно огрести проблемы.
совсем недавно космонавты Юрий Гагарин и Алан Шеппард облетели вокруг Земли.
При всём уважении к Алану Шеппарду, он не облетел вокруг земли. Его полет был суборбитальным - задача была достичь высоты 100 км и приводниться.
По давней традиции американцы называют своих ребят астронавтами, и многие уважают их выбор.
Про ошибки 400 vs 500 - принцип простой:
ошибки 4xx означают, что если клиент изменит что-то в своем запросе, то он может быть получит результат. https://www.rfc-editor.org/rfc/rfc9110.html#name-client-error-4xx
Ошибки 5xx означают, что от действий клиента ничего не зависит - где-то внутри сервиса при обработке запроса всё идет плохо. https://www.rfc-editor.org/rfc/rfc9110.html#name-server-error-5xx
Однако на практике это означает необходимость ручного анализа возникающих на сервере ошибок и принятия решения по каждой, что выдавать: 400 или 500. Сами понимаете, на это подпишется не всякая команда разработки.
Есть и приколы. Некоторые системы допускают более широкое толкование понятия "действий клиента". Например SaaS позволяющий изменять конфигурацию купленного сервиса. Бывает, что клиент так наизменяет, что сервис выпадает с внутренней ошибкой 500. И для того, чтобы донести до клиента информацию, что он сам может исправить ситуацию, приходится совершенно очевидную ошибку 500 (сервис подняться не может) преобразовывать в 400.
Если коротко, то вряд ли вашей проводке что-то угрожает. Длительность скачка тока уж очень мала (десятки микросекунд).
Подробнее - например тут.
Как считаете, такое упрощение - путь к отупению нации, или будет удобно, если документы начнут пояснять простыми словами?
Нация и без вас успешно справляется с отупением, не переживайте.
А идея хорошая, снижает "порог входа" при чтении юридических документов.
Перечитал статью, посмотрел исходники:
когда вы в промежуточном сервисе ProcessExecutor создали список запросов - вы создали у своего сервиса state, он как-бы перестал быть "чисто-рестовым".
public static List<RequestDTO> Requests { get; set; } = new List<RequestDTO>();
Теперь при отключении инстанса (а при масштабировании на это надо закладываться) этот state потеряется. Клиенты должны будут самостоятельно решать, какие транзакции отправлять повторно, какие признать выполненными.Как вы будете бороться с этим тонким местом?
Мелочи не трогаю.
Кажется, ваш кейс решается в терминах многозадачности: вы выбрали кооперативную, когда задача не отдает разделяемый ресурс до своего завершения. А можно выбрать вытесняющую, когда разделяемый ресурс выделяется задачам небольшими кусками.
В терминах операционных систем разделяемый ресурс - это процессорное время. В терминах вашей задачи - это количество обрабатываемых транзакций.
Все пачки придется разделить на блоки по 1000 транзакций, блоки обрабатывать последовательно для каждой пачки.
В итоге получается т.н. планировщик, и это тоже термин из области многозадачности.
Спасибо, я не знал, что у этой истории было продолжение.
По ссылке документ трудноват для чтения, вот более легкий английский текст об отмене решения:
https://jolt.law.harvard.edu/digest/newegg-wins-patent-troll-case-after-court-delays
Не обошлось без нового анекдота - на отмену ушло 20 месяцев из-за ошибки при вводе номера судебного дела в базу данных.
А мне этот случай запомнился тем, что аргументы Диффи в итоге не привели к признанию патента недействительным, и TQP выиграл дело.
Адвокат TQP избрал линию на создание сомнений в репутации Диффи как ученого: тот не получал ученую степень, и не преподавал в учебных заведениях, а только работал там:
Я, помню, неделю был под впечатлением от того, что такое может прокатить в суде.
- Как померить температуру струи диаметром 1мм?
- Возьмите обычный настенный термометр. В комнате он показывает 22 градуса - это самый главный критерий, такой термометр нам точно подойдет!
Спасибо за полезную статью.
Мне вот подумалось, а в нашей вселенной еще остались те, кто помнит, что краткое прилагательное "не успешен" пишется слитно?
И ведь это дороже исправлять, чем плюнуть и оставить как есть на стороне сервиса...