1. Не слушайте советов, которые люди дают на основании собственного опыта...
И как же после этого относится к вашим советам, которые следуют дальше? Это ведь тоже «собственный опыт».
Конечно, любой совет нужно критически оценивать, но бывают и достаточно «объективные» советы — например, совет не скрывать своего незнания — это полезный совет для большинства ситуаций где его можно применить, как, впрочем, и про «жизнь вне кода» (то, что работа без отдыха вызывает стресс — это практически научный факт).
А вот совет «не слушать советы» — очень субъективный, ему стоит следовать далеко не в большинстве случаев.
Batch processing в HTTP нет, есть только pipelining, а это совсем не то же самое (хотя в ограниченных случаях и применимо). В HTTP вообще почти ничего нет — это просто транспорт, не более того. Да, получивший широкое распостранение и вне web, передающий уже давно не только HTML, обросший прокси, кэшами и LB, но всего лишь транспорт.
Честно говоря, я не вижу каким образом использование HTTP только как транспорта (как я описал) заставляет отказываться от инфраструктуры, и одновременно сильно упрощает как клиента, так и сервер, потому что весь цикл обработки примерно такой:
// Сервер
while (GetRequest()) {
ProcessRequest()
SendResponse()
}
// Клиент
while (HaveJobs()) {
SendRequest()
ProcessResponse()
}
и всё — код никак не зависит от транспорта, кроме Get/Send.
GET может кэшироваться как и обычно (если нужно и разрешено), остальное спокойно проходит через всё что угодно без потерь (при наличии «умного» прокси-кэша-LB тоже может ограниченно кэшироваться — даже PUT, PATCH, POST и DELETE), при этом клиент гарантированно знает что любой код отличный от 200 обозначает только одно — запрос не попал в приложение (что и требуется — в этом суть транспорта). Мониторинг тоже не страдает — просто может потребоваться добавить разбор тела (причём это стандартная возможность любого приличного мониторинга), но и это не всегда нужно — потому что (снова) — 200 означает «всё ок». Балансировщики — тоже в порядке, ибо если приложение отвечает 200 — значит оно доступно, для недоступности есть 5xx (или таймаут, или connection refused). Что ещё?
Я лично использую этот «велосипед» уже более 15 лет, за стеной прокси, LB и мониторинга, им очень активно пользуются несколько тысяч клиентов — никаких проблем, всё работает как часы (хотя в начале это был не JSON а XML, не SOAP, свой).
Да и пример с Cloudflare я не случайно привел — они на HTTP и всей инфраструктуре целую армию собак съели, но их собственное API использует HTTP только как транспорт, и это реально удобно, но если они захотят, то почти без усилий могут его сделать доступным хоть по почте (SMTP).
Вы когда-нибудь пытались сделать клиента к апи, которое на всё подряд кидает 200 ОК?
Легко. HTTP — это всего лишь транспорт, и 200 обозначает что ответ получен от приложения, а не кого-то ещё, следовательно, можно разбирать тело, а уже в нём всё написано.
Если это не 200, значит, проблема с сервером, прокси или что там ещё по пути к приложению, и разбирать тело смысла не имеет (так как оно не от приложения). Можно возвращать 4xx для того что можно валидировать до приложения (формат, авторизацию и т.п.), но не более того — сам запрос (правильный json) должен обрабатываться только приложением, и только оно может на него ответить.
Изоляция приложения от транспорта полезна ещё и тем что можно легко переключится на любой другой транспорт без риска потерять обработку ошибок, причём не меняя ничего в самом приложении со клиентской стороны.
К примеру, Cloudflare API использует именно этот метод — и это весьма удобно, там вообще нет ответов кроме 200 и 301 (все 4xx это проблемы с запросами ещё до того как они попадают в приложение).
Натягивание кодов ошибок HTTP на возможные ситуации с приложением (которых может быть на порядок больше чем в HTTP, не говоря уже о том что ошибок может быть больше одной и разного типа, и все их нужно обработать) — плохая практика.
При обработке сложных запросов также возникает необходимость возвращать более чем одну ошибку (особенно если запрос обрабатывает более одного объекта), причём разного рода — и все их нужно обработать. Простой пример — пользователь отправил форму, в ней с десяток полей, некоторые с ошибками — будет весьма логично вернуть список всех ошибочных полей за раз, а не останавливаться на первом и возвращать их по мере того как он их исправляет, при этом ошибки могут быть разными («неверный формат», «недопустимое значение» etc), это всё не влезает в линейку 4xx.
Ещё более жесткий случай если мы создаем несколько объектов в одном запросе (batch processing), при этом допускается что не все они будут созданы (частичный успех) — тут 201 никак не поможет, а попытка создание объекта который уже есть (и может быть только в одном экземпляре) вообще никак не отображаема в HTTP — можно было бы использовать 409, но тогда это неотличимо от других конфликтов. В общем, много таких вещей, которые в HTTP не влезут при всём желании, без изобретения своих кодов.
Пример плохого дизайна — в PowerDNS API — на всё что сервер не понял он возвращает «422 Unprocessable Entity», а в теле — текстовое описание проблемы, которое совсем почти непарсабельно (да и может измениться в любой момент, ибо даже не документировано).
Но разумеется, если у вас приложение само является endpoint, перед ним нет даже хиленького LB, а все возможные ошибки «влезают» в 4xx/5xx — тогда да, в самый раз. Увы, в реальности такое бывает редко.
Не обязана, хотя её отсутствие несколько снижает шансы. Отсутствие других данных, которые можно использовать для дискриминации, периодически приводит к этой самой дискриминации, но доказать это вряд-ли возможно, посему почти всегда сходит с рук работодателю.
Впрочем, в компаниях где это «обязательно», обычно не очень приятно работать, так что это даже к лучшему.
Боюсь уже не найду, это было больше 10 лет назад. Помню только что автор был какой-то студент из MIT, написал его под ghostscript. Я был впечатлён и поэтому запомнил.
Не всегда. Иногда язык выбирается исходя из того как быстрее сделать какой-то проект (или хотя бы прототип). Но в этом случае Go не дает никаких преимуществ, если человек уже знает что-то из C/C++/C#/Java. Если производительность не играет существенной роли, то сюда можно добавить знание любого другого языка.
Правда, есть ещё категория энтузиастов, которые чисто из вредности решают задачи на не очень подходящим для них языке (те самые которые пишут веб-сервера на bash или редакторы текста на postscript) — они вряд-ли интересуются деньгами или спросом на рынке труда.
Смешанные чувства у некоторых вызывают даже люди другой расы или просто те кто выглядят сильно иначе — много тату, пирсинга etc, не говоря уже про вымирающие племена со своими заморочками (типа огромных колец в ушах или губах), что уж тут о киборгах говорить…
Вряд-ли. Обезъян, к примеру, многие только на картинках или на экране видели, но после часа в зоопарке их вид уже не проблема, а одну-две недели в странах где они по улицам как кошки шастают вообще на них внимания не обращаешь — то же будет и с киборгами.
которую почему-то нельзя выполнить на «стандартном» языке
А какой язык является «стандартным»? Это понятие, как мне кажется, сильно зависит от компании, индустрии и ещё кучи переменных. Где-то это Java, где-то C/C++, где-то даже Visual Basic, в NASA, к примеру, в своё время был довольно популярен явно «нестандартный» Forth.
Есть достаточно проектов в которых важен факт выполнения функции, а не стек или язык, которые создаются один раз и работают годы или даже десятки лет, или наоборот, с коротким сроком жизни, практически не требуют поддержки кода (потому что всё самое критичное вылизывается до их введения в прод) — соответственно, совершенно несущественно, какой язык выберет исполнитель.
Я говорю о тексте который содержит суть, ключевые моменты доклада — факты, выводы etc. Если у человека есть тема которую он хочет осветить, и он готовится к докладу — наверняка это у него уже есть.
Проблема в том, что далеко не все доклады представимы в виде расшифровок, а те, что представимы, зачастую требуют слишком много ресурсов.
Я могу ошибаться, но мне всегда казалось что все доклады сначала готовятся в виде текстов, слайдов, картинок etc — и только потом уже из них делают выступления и видео. Ок, бывают исключения — когда всё вживую, без подготовки — с вопросами и прочим, но обычно это всё же с подготовкой, а раз так, то сделать читабельный вариант (без видео) должно быть намного проще.
Проблема с живыми выступлениями — приходится слушать всё, даже если все материалы одного дня можно ужать в максимум 10 страниц текста и картинок, и честно скажу, после нескольких сотен часов присутствия на десятках разных докладов только один раз видел докладчика который обошелся без воды и ужал всё до минимума — но именно им большинство осталось недовольно. Если добавить к этому время на то чтобы доехать на место, вернуться, всё по мелочам — слишком высокая цена получается.
Проблема с видео — даже если смотреть на 2x скорости (выше тяжко) и пропускать очевидно бесполезные места (занимающие 25-50% времени), это всё равно займёт в разы больше чем чтение ровно того в чём суть.
Таким образом, невольно создаётся впечатление что докладчики и орги которые не предоставляют материалы в компактном (только суть) текстово-графическом виде, явно не ценят время людей для которых они всё это делают.
Да, примерно так, но обычно это выглядит как дискаунт в счете. Бывают сервисы с SLA > 100% (стоят они немного), т.е. SLA 1000% к примеру — вернут в десятикратном размере за время простоя.
Но без особых договоренностей никто, нигде и никогда не вернет ничего кроме оплаты за время простоя — т.е. никаких компенсаций за прямые или косвенные убытки, потерю репутации и т.п.
Красивые, да. Главное чтобы не получилось как в том анекдоте про роботизированного парикмахера:
— Но ведь форма головы у всех разная!
— Только до первой стрижки.
Речь шла только о технической возможности, точнее, невозможности что-то доказать.
Хотя, контролируемый неадекватным владельцем (или гос-вом) мессенжер вполне могут использовать для таких целей, подбрасывают ведь наркотики или оружие неугодным, чем цифровой мир хуже?
Строго говоря, без чего-то типа blockchain и прочей криптографией (а иногда даже и с ними) вообще ничего невозможно утверждать на 100%, потому что как одно-несколько, так и вся история сообщений могут быть подделаны и на сервере, и на клиенте.
Если телеграм (или любой другой мессенжер без end-to-end) решит подставить кого-то, то легко сможет это сделать (не считая secret chat, конечно), создав фиктивную и выдуманную историю переписки.
Так что, даже видимая в клиенте история переписки не является доказательством её реальности.
Нотариус обычно заверяет тот факт что то что он видел (своими глазами) соответствует тому что он подписывает (на бумаге).
Таким образом, нотариально заверенный скриншот подтверждает тот факт что нотариус присутствовал в момент его создания и видел на экране ровно то что попало в скриншот.
И как же после этого относится к вашим советам, которые следуют дальше? Это ведь тоже «собственный опыт».
Конечно, любой совет нужно критически оценивать, но бывают и достаточно «объективные» советы — например, совет не скрывать своего незнания — это полезный совет для большинства ситуаций где его можно применить, как, впрочем, и про «жизнь вне кода» (то, что работа без отдыха вызывает стресс — это практически научный факт).
А вот совет «не слушать советы» — очень субъективный, ему стоит следовать далеко не в большинстве случаев.
Честно говоря, я не вижу каким образом использование HTTP только как транспорта (как я описал) заставляет отказываться от инфраструктуры, и одновременно сильно упрощает как клиента, так и сервер, потому что весь цикл обработки примерно такой:
и всё — код никак не зависит от транспорта, кроме Get/Send.
GET может кэшироваться как и обычно (если нужно и разрешено), остальное спокойно проходит через всё что угодно без потерь (при наличии «умного» прокси-кэша-LB тоже может ограниченно кэшироваться — даже PUT, PATCH, POST и DELETE), при этом клиент гарантированно знает что любой код отличный от 200 обозначает только одно — запрос не попал в приложение (что и требуется — в этом суть транспорта). Мониторинг тоже не страдает — просто может потребоваться добавить разбор тела (причём это стандартная возможность любого приличного мониторинга), но и это не всегда нужно — потому что (снова) — 200 означает «всё ок». Балансировщики — тоже в порядке, ибо если приложение отвечает 200 — значит оно доступно, для недоступности есть 5xx (или таймаут, или connection refused). Что ещё?
Я лично использую этот «велосипед» уже более 15 лет, за стеной прокси, LB и мониторинга, им очень активно пользуются несколько тысяч клиентов — никаких проблем, всё работает как часы (хотя в начале это был не JSON а XML, не SOAP, свой).
Да и пример с Cloudflare я не случайно привел — они на HTTP и всей инфраструктуре целую армию собак съели, но их собственное API использует HTTP только как транспорт, и это реально удобно, но если они захотят, то почти без усилий могут его сделать доступным хоть по почте (SMTP).
Легко. HTTP — это всего лишь транспорт, и 200 обозначает что ответ получен от приложения, а не кого-то ещё, следовательно, можно разбирать тело, а уже в нём всё написано.
Если это не 200, значит, проблема с сервером, прокси или что там ещё по пути к приложению, и разбирать тело смысла не имеет (так как оно не от приложения). Можно возвращать 4xx для того что можно валидировать до приложения (формат, авторизацию и т.п.), но не более того — сам запрос (правильный json) должен обрабатываться только приложением, и только оно может на него ответить.
Изоляция приложения от транспорта полезна ещё и тем что можно легко переключится на любой другой транспорт без риска потерять обработку ошибок, причём не меняя ничего в самом приложении со клиентской стороны.
К примеру, Cloudflare API использует именно этот метод — и это весьма удобно, там вообще нет ответов кроме 200 и 301 (все 4xx это проблемы с запросами ещё до того как они попадают в приложение).
Натягивание кодов ошибок HTTP на возможные ситуации с приложением (которых может быть на порядок больше чем в HTTP, не говоря уже о том что ошибок может быть больше одной и разного типа, и все их нужно обработать) — плохая практика.
При обработке сложных запросов также возникает необходимость возвращать более чем одну ошибку (особенно если запрос обрабатывает более одного объекта), причём разного рода — и все их нужно обработать. Простой пример — пользователь отправил форму, в ней с десяток полей, некоторые с ошибками — будет весьма логично вернуть список всех ошибочных полей за раз, а не останавливаться на первом и возвращать их по мере того как он их исправляет, при этом ошибки могут быть разными («неверный формат», «недопустимое значение» etc), это всё не влезает в линейку 4xx.
Ещё более жесткий случай если мы создаем несколько объектов в одном запросе (batch processing), при этом допускается что не все они будут созданы (частичный успех) — тут 201 никак не поможет, а попытка создание объекта который уже есть (и может быть только в одном экземпляре) вообще никак не отображаема в HTTP — можно было бы использовать 409, но тогда это неотличимо от других конфликтов. В общем, много таких вещей, которые в HTTP не влезут при всём желании, без изобретения своих кодов.
Пример плохого дизайна — в PowerDNS API — на всё что сервер не понял он возвращает «422 Unprocessable Entity», а в теле — текстовое описание проблемы, которое совсем почти непарсабельно (да и может измениться в любой момент, ибо даже не документировано).
Но разумеется, если у вас приложение само является endpoint, перед ним нет даже хиленького LB, а все возможные ошибки «влезают» в 4xx/5xx — тогда да, в самый раз. Увы, в реальности такое бывает редко.
Впрочем, в компаниях где это «обязательно», обычно не очень приятно работать, так что это даже к лучшему.
А если смартфон в противоударном чехле, особенно таком который не очень легко снимается (мой развинчивать надо, к примеру)?
Правда, есть ещё категория энтузиастов, которые чисто из вредности решают задачи на не очень подходящим для них языке (те самые которые пишут веб-сервера на bash или редакторы текста на postscript) — они вряд-ли интересуются деньгами или спросом на рынке труда.
Вряд-ли. Обезъян, к примеру, многие только на картинках или на экране видели, но после часа в зоопарке их вид уже не проблема, а одну-две недели в странах где они по улицам как кошки шастают вообще на них внимания не обращаешь — то же будет и с киборгами.
А какой язык является «стандартным»? Это понятие, как мне кажется, сильно зависит от компании, индустрии и ещё кучи переменных. Где-то это Java, где-то C/C++, где-то даже Visual Basic, в NASA, к примеру, в своё время был довольно популярен явно «нестандартный» Forth.
Есть достаточно проектов в которых важен факт выполнения функции, а не стек или язык, которые создаются один раз и работают годы или даже десятки лет, или наоборот, с коротким сроком жизни, практически не требуют поддержки кода (потому что всё самое критичное вылизывается до их введения в прод) — соответственно, совершенно несущественно, какой язык выберет исполнитель.
Я могу ошибаться, но мне всегда казалось что все доклады сначала готовятся в виде текстов, слайдов, картинок etc — и только потом уже из них делают выступления и видео. Ок, бывают исключения — когда всё вживую, без подготовки — с вопросами и прочим, но обычно это всё же с подготовкой, а раз так, то сделать читабельный вариант (без видео) должно быть намного проще.
Проблема с живыми выступлениями — приходится слушать всё, даже если все материалы одного дня можно ужать в максимум 10 страниц текста и картинок, и честно скажу, после нескольких сотен часов присутствия на десятках разных докладов только один раз видел докладчика который обошелся без воды и ужал всё до минимума — но именно им большинство осталось недовольно. Если добавить к этому время на то чтобы доехать на место, вернуться, всё по мелочам — слишком высокая цена получается.
Проблема с видео — даже если смотреть на 2x скорости (выше тяжко) и пропускать очевидно бесполезные места (занимающие 25-50% времени), это всё равно займёт в разы больше чем чтение ровно того в чём суть.
Таким образом, невольно создаётся впечатление что докладчики и орги которые не предоставляют материалы в компактном (только суть) текстово-графическом виде, явно не ценят время людей для которых они всё это делают.
Но без особых договоренностей никто, нигде и никогда не вернет ничего кроме оплаты за время простоя — т.е. никаких компенсаций за прямые или косвенные убытки, потерю репутации и т.п.
— Но ведь форма головы у всех разная!
— Только до первой стрижки.
Разве что в сфере IT. Не могу себе представить удаленно работающего хирурга или курьера…
Хотя, контролируемый неадекватным владельцем (или гос-вом) мессенжер вполне могут использовать для таких целей, подбрасывают ведь наркотики или оружие неугодным, чем цифровой мир хуже?
Если телеграм (или любой другой мессенжер без end-to-end) решит подставить кого-то, то легко сможет это сделать (не считая secret chat, конечно), создав фиктивную и выдуманную историю переписки.
Так что, даже видимая в клиенте история переписки не является доказательством её реальности.
Таким образом, нотариально заверенный скриншот подтверждает тот факт что нотариус присутствовал в момент его создания и видел на экране ровно то что попало в скриншот.