На данный момент, бухгалтер в России, по крайней мере главный — очень творческая профессия. Как минимум на время подготовки отчётности. Как бы грустно это не звучало.
По поводу официантов — в забегаловках, да, можно заменить и роботом. Но в дорогих ресторанах, официанты — это не голодные студенты, они, в том числе, и актёры, которые должны очень хорошо уметь обслужить каждого конкретного клиента, а не сделать всё «по стандарту». Я в таких заведениях бываю крайне редко, но мне, например, приятно наблюдать за их работой!
А вот это меня реально пугает, ибо левые прошивки появятся точно, и писать их будут абсолютно безответственные люди. Впрочем и с официальными прошивками могут быть вопросы:
Кажется Mercedes(но точно не уверен), уже анонсировали систему, которая сканирует поверхность дороги и перенастраивает подвеску каждого из 4х колёс отдельно, для наиболее мягкого прохождения неровностей.
WebKit пока по особенностям рендеринга не особо отличается от Blink, так что на моноэкосиситему почти не будет влиять. А Presto как бы почти помер — Opera же на Blink перешла.
А автообновление не поможет, потому что сначала надо обновить ось, а это как минимум стоит денег пользователю.
Есть ещё вариант, что в Yota просто мегафоновское руководство начало «оптимизировать расходы», и всякие непонятные штуки, вроде доменов, легли в долгий ящик. Но виновной всё равно будет какая-нибудь девочка из Yota.
По крайней мере Ростелеком такое активно практикует в своих приобретениях, не думаю, что мегафон тут сильно отличается. :(
Имхо, в примере с «color=зИлЁнЕнЬКаЯ», это все-же 404
На самом деле это вопрос исключительно бизнес-логики.
Мы либо пытаемся искать футболки с любым запрошенным пользователем цветом, тогда, да, HTTP404.
Либо сначала проверяем каталог существующих возможных значений цветов, и тогда, признав значение в принципе невалидным(то есть футболки такого цвета гарантированно существовать не может в нашей системе, а не закончились на складе, например), мы со спокойной совестью выдаём HTTP400.
Я никак не могу понять, какая разница между REST и не-REST — HTTP об этом ничего не знает, коды универсальны для всех способов использования HTTP.
при валидации данных, в сценарии что юзер редактировал URL, возвращать разные 40x коды?
Ну вот смотрите, предположим у вас есть сайт, где можно посмотреть футболки. У футболки есть параметры, например цвет. Если кто-то укажет color=red, а у вас есть только зёлёные футболки, то это явный HTTP404 — Not Found, а если параметр цвета вообще не указали или указали неправильный цвет(color=зИлЁнЕнЬКаЯ), то это уже вполне себе некорректный запрос и HTTP400 — Bad Request.
И не надо говорить, что если не указали цвет, то вы покажете зелёную футболку — это уже бизнес-логика и к протоколам отношения не имеет.
Ну это же бред — ни кому не нужная работа, и ложные коды ошибок в случае реальных багов в приложении.
Почему ложные? Они как раз очень точно описывают проблему!
Покажите хоть один сайт, который так делает?
Я уже говорил, что если все делают неправильно, то это не аргумент. В своих проектах я стараюсь такого не допускать и коллег учу тому же.
Из того, что многие делают криво и неправильно, не стоит делать вывод, что это хорошо.
Проблема в том, что большинство разработчиков сайтов (и видимо даже фреймворков) никогда не читали стандарты на используемые ими протоколы. И это на самом деле очень печально!
Надо только учитывать, что каждую плавку, как минимум ABS теряет пластичность и становится хрупким.
На производстве пруток можно делать из свежей смеси компонентов, а такие кустарные пруткоделки выдают уже вторичный продукт. Да и обеспечить качество прутка на самом деле очень сложно — или неровности, или пузыри будут.
Потому что механизм подачи гранул сложнее, тяжелее и весьма дороже чем механизм подачи прутка.
Гранулы кустарно можно удобно использовать в литье пластика в форму под давлением — там их засыпают в «стакан», перемешивая плавят до жидкого состояния. После чего с одной стороны к «стакану» подключают компрессор, а с другой прицепляют форму для заливки.
Лично мне нравится сама идея выделения «новостей», но скорее как плашки (аля «туториал», «из песочницы»), дабы сразу было видно, что пост стоит прочитать как можно быстрее, пока не потерялась актуальность.
А вот необходимость системы голосования, которая будет их разделять для меня не очевидна.
TrueCrypt шифрует контейнер с файлами, а не базу паролей/ключей.
По поводу официантов — в забегаловках, да, можно заменить и роботом. Но в дорогих ресторанах, официанты — это не голодные студенты, они, в том числе, и актёры, которые должны очень хорошо уметь обслужить каждого конкретного клиента, а не сделать всё «по стандарту». Я в таких заведениях бываю крайне редко, но мне, например, приятно наблюдать за их работой!
ko.com.ua/kachestvo_vstraivaemogo_po_ili_pogrom_vsyo-taki_sluchilsya_98518
Не знаю насколько авторитетен источник, но если хотя бы треть написанного — правда, то уже страшно!
А автообновление не поможет, потому что сначала надо обновить ось, а это как минимум стоит денег пользователю.
По крайней мере Ростелеком такое активно практикует в своих приобретениях, не думаю, что мегафон тут сильно отличается. :(
А это не вам, как разработчику, решать — это вопрос бизнес-логики. Набор цветов вполне может быть каким-нибудь строго ограниченным.
На самом деле это вопрос исключительно бизнес-логики.
Мы либо пытаемся искать футболки с любым запрошенным пользователем цветом, тогда, да, HTTP404.
Либо сначала проверяем каталог существующих возможных значений цветов, и тогда, признав значение в принципе невалидным(то есть футболки такого цвета гарантированно существовать не может в нашей системе, а не закончились на складе, например), мы со спокойной совестью выдаём HTTP400.
Я никак не могу понять, какая разница между REST и не-REST — HTTP об этом ничего не знает, коды универсальны для всех способов использования HTTP.
Ну вот смотрите, предположим у вас есть сайт, где можно посмотреть футболки. У футболки есть параметры, например цвет. Если кто-то укажет color=red, а у вас есть только зёлёные футболки, то это явный HTTP404 — Not Found, а если параметр цвета вообще не указали или указали неправильный цвет(color=зИлЁнЕнЬКаЯ), то это уже вполне себе некорректный запрос и HTTP400 — Bad Request.
И не надо говорить, что если не указали цвет, то вы покажете зелёную футболку — это уже бизнес-логика и к протоколам отношения не имеет.
Почему ложные? Они как раз очень точно описывают проблему!
Я уже говорил, что если все делают неправильно, то это не аргумент. В своих проектах я стараюсь такого не допускать и коллег учу тому же.
Для этого тоже есть код, HTTP 404 — Not Found
Кто-то рекомендует её таки прочесть, и убедиться, что кодов таки немножечко больше, чем 200/400/500…
Проблема в том, что большинство разработчиков сайтов (и видимо даже фреймворков) никогда не читали стандарты на используемые ими протоколы. И это на самом деле очень печально!
Если пользователь отредактировал URL, так как вам не надо — выдавайте HTTP 400 — Bad Request.
На производстве пруток можно делать из свежей смеси компонентов, а такие кустарные пруткоделки выдают уже вторичный продукт. Да и обеспечить качество прутка на самом деле очень сложно — или неровности, или пузыри будут.
Гранулы кустарно можно удобно использовать в литье пластика в форму под давлением — там их засыпают в «стакан», перемешивая плавят до жидкого состояния. После чего с одной стороны к «стакану» подключают компрессор, а с другой прицепляют форму для заливки.
А вот необходимость системы голосования, которая будет их разделять для меня не очевидна.