И эту инициативу надо подписать? Там же одна вода. Ну почему нельзя писать кратко и по делу? Первые пять абзацев — непонятно что. Потом единственный найденный минус: 2 слова размытые на 50. Потом спорное «неоспоримое» утверждение на абзац. Потом отсебятина на абзац. И всё.
Думаю, большая часть из тех, кто подписал, даже не читала. Остальная часть прочла, но не вникла. А ведь комиссия будет обсуждать именно это, а не комментарии на хабре. Они рассмотрят всего один аргумент из инициативы «снижение конкуренции», легко покроют его пророссийским «поднятие российского производства» и разойдутся. Дело на 5 минут.
Если автор будет читать этот комментарий, то:
— меньше воды
— больше фактов
— слова вроде «неоспоримым» «многократно завышенных», «непомерных» не заменяют факты. Наоборот, они вызывают ощущение хлипкого фундамента, когда у автора нет фактов и таким образом он пытается это прикрыть.
— выделяйте минусы отдельно, как список.
— найдите побольше минусов, а не один. Даже здесь в комментариях есть минусы, которых нет в инициативе. Например, потребители очень редкого товара просто будут больше платить, потому что наши такой товар продавать не будут. Это национальный товар, товар с очень маленьким спросом, который на одну страну производить не выгодно, и прочий эксклюзив.
— используйте информационный стиль. Хотя бы ставьте подлежащее и сказуемое рядом, а не через 10 слов, как в 6 абзаце (кстати, самом важном).
Я тоже не селен ;) Возможно тогда сама крышка будет легко ломаться, а также будет лишняя морока с подпорками, которые надо обрезать.
Если нужны крепкие подпорки, может легче делать углубления и печатать подпорки отдельно, а потом вклеивать?
И другой вопрос: А нужны ли крепкие подпорки в прототипе из 3d принтера? Может легче просто сделать ребро жесткости, и хоть в принтере это будет не так крепко, но в промышленном литье из пластика всё будет отлично.
В доке уже есть random, который можно примешать к клиентскому генератору. Вместо убедительного «it's highly recommended ...» или даже «client SHOULD» там мягкое предложение: «If the client has an inadequate random number generator, it makes sense ...».
И тут оказывается, что второе случайное число выполняет ту же функцию, но теперь чтоб уж точно. Вопросов куча: зачем первый random если второй nounce и так обязателен? Почему вводится обязательный nounce, когда первый предлагается очень мягко? Почему непонятное имя nounce? Почему в доке не раскрыт смысл nounce, как random? И почему Алисе он выдается в самом конце, а не когда она только начала инициализировать соединение, как random? Всё выглядит ну очень нелогично, пока в теории не появляется Большой Брат и всё быстро становится на свои места. Что ещё нужно для параноика, не так ли?
Но вероятность, что так и было, есть. Сам был на другой стороне, когда простая ошибка со стороны выглядела как заговор. Видел, как работа нескольких людей в сумме давала непоследовательный и нелогичный результат (прям как здесь). Верится очень слабо, но исключить добрые намерения не могу. :) (хотя бы у тех, кто проверял)
эммм… если nonce служит для исправления рандома на клиентах, зачем тогда поле «random» в DhConfig, который можно получить указав random_length > 0, как это описано в core.telegram.org/api/end-to-end?
Там отдельный параграф про «random», который в самом начале приходит с p и g, и примешивается к рандому клиента. И отдельный параграф про nounce, который приходит после того, как сервер может вычислить секретный ключ для Алисы и знает секретный ключ у Боба. Почему бы не передавать nounce с самого начала? Зачем он вообще нужен если random уже примешали?
Начиная с 30-ой минуты в видео вы рассказываете, как плохо отлаживать ПО в эрланге, что отладчика там нет… И слава богу :)
В ноде я как-то пытался отлаживать через node-inspector, поставил брекпоинт, нода остановилась, и, пока я смотрел на переменные в вотчлисте, истекла пара таймаутов. После того, как я нажал run, процесс выдал ошибки и пошел совсем по другому пути. С тех пор я просто вставляю принты и перезапускаю ноду.
В ноде вообще-то таймаутов почти нет, и всё равно они у меня сработали. В эрланге же их рекомендуют ставить на каждый receive. Поэтому проблем с паузой там будет на порядок больше. Особенно, если ставить на паузу всю эрланг-машину. И, конечно, такой метод не годится для отладки продакшн системы на лету.
Это, как я понимаю, общая проблема для актор-систем, если они написаны аккуратно, т.е. с таймаутами.
Поэтому, принты, принты и только принты. И вот с этим в эрланге всё очень хорошо: можно подключиться к ноде на лету (даже продакшн), на лету включить трейс на вызов любых функций, на лету получить и время, и переданные аргументы, и результат, и также на лету пропатчить. Такого мне очень сильно не хватает в других языках, включая ноду с её node-inspector.
Я понял, что вы твёрдо против всей этой системы, хорошо в ней разбираетесь и готовы говорить много и красочно. И, конечно, тот абзац, где вы вернулись к теме:
Представьте, что все на диком западе начали охотиться за неуловимым джо. А за это время вымер скот, спился с горя единственный бармен, а когда все пришли предъявлять счет шерифу — он застрелился. И остались в поселке только охотники за головами. Ни баб, ни жратвы, ни связи с большой землей, зато куча дробовиков у каждого в шкафу.
показывает, насколько неожиданно глубоко вы разбираетесь в рыночных механизмах. Безусловно, вы правы, нельзя давать деньги за информацию о преступниках, иначе того и гляди все начнут гоняться за бандитами и подохнут с голоду. Я бы и такси, кстати, не рекомендовал бы оплачивать, а то все начнут друг-друга возить и тоже подохнут с голоду.
Стоп! А если я буду платить за еду, то все начнут мне готовить и подохнут с голоду, а потом и я. Похоже, голод неминуем. Тогда может разрешить охоту за головами, раз финал один и тот же?
Если я сейчас оставлю программирование и вольюсь в общество кардеров, а потом их всех сдам. Банки, думаю, заплатят. Это тоже «порочная и больная система»?
А давайте вспомним Дикий Запад и эти объявления «Wanted» на убийц и насильников, и целый класс охотников за головами, которые только этим и жили. Тоже «порочная и больная система»?
А когда по телеку предлагают деньги за информацию о каком-нибудь преступнике (жаль, только в кино предлагают, в жизни бесплатно), это тоже больная система?
Есть спрос на информацию о вредных личностях, почему бы и не дать предложение. Всем же лучше.
Минуточку. Что вообще может быть плохого в том, что прижали пиратов, которые незаконно распространяют чужой контент ради денег?
Чем они отличаются от всеми нелюбимых издателей? И те и другие строят свой бизнес на чужом контенте. По-моему, они даже хуже: издатели хоть чуть-чуть делятся с авторами, а такие пираты вообще всё в карман.
> В общем, если есть возможность написать все приложение целиком на одном языке — это большое счастье для проекта!
Это не поможет. Знание языка — это очень маленькая часть, от знаний, которые нужны специалисту в той или иной части проекта.
Даже если и там и там JS, фронтендщики не полезут в бекенд, а бекендщики не должны лезть в фронтенд. Они по разному пишут, по разному работают с колбеками (deffered vs async), разные ньюансы (DOM и браузеры vs node и concurrency), разные инструменты отладки, да вообще почти всё разное. Даже разные точки зрения на задачу: фичи и динамика vs стабильность и нагрузка. Бекендщику в фронтенде от знания js примерно столько же пользы, сколько гастроэнтерологу в стоматологии от знаний русского языка и латыни.
Так что время на изучение другого языка (после 10 языков на 11-ый уйдёт час-два + stackoverflow) незначительно на фоне времени, которое нужно, чтобы вникнуть в матчасть, и покрывается с лихвой, если другой язык — это язык заточенный под конкретную задачу, а то и DSL.
> это уже не клиент, ему доверять можно, поэтому достаточно продублировать валидацию на сервер-UI, чтобы не нагружать этим бизнес-логику вообще
На практике, если бекендщик не будет отбрасывать ошибочные запросы с объяснением что не так, то фронтендщики завалят багтрекер тикетами на «глючащий» бекенд, хотя ошибки на их стороне. Поэтому валидация на бекенде нужна, и не из-за паранои, а просто чтобы упростить всем жизнь, как автоматический судья, который решает, у кого бага.
> Авторизация — это щепотка бизнес-задачи (узнать, кто обратился)
Это аутентификация. Я имел в виду авторизацию, т.е. проверку имеет ли этот юзер права на чтение/изменение этих данных. Эта проверка нужна и фронтенду, чтобы попрятать кнопочки и ссылочки, и само-собой бекенду. Вот и дублирование кода.
Про модель, это отсылка к Meteor, где и клиент и сервер расшаривают одно и тоже описание модели. Нет больше этого плюса, если бекенд не на ноде.
Автор очень странный. Первый раз вижу сторонника ноды, который сам говорит, что нода не должна быть бекендом, а всего лишь прослойкой между бекендом и браузером.
Более того, нодовцы должны даже сильнее критиковать эту идею, чем бекендщики. Возьмём валидацию, где её надо делать? Ни один бекендщик не оставит валидацию клиентам, а с его точки зрения ui-backend на ноде — это уже клиент. Значит будет дублирование кода валидации на js и на языке бекенда. Тоже самое с моделью и с авторизацией. Опять дублируем кучу кода. Ассинхронность ноды тоже теперь не достоинство, она никак не поможет бекенду.
И вот единственный плюс от такой прослойки — это то, что бекендщики теперь не думают про REST и веб. Это важно, если у бекенда несколько клиентов, но в остальных случаях эту прослойку скорее всего просто вырежут бритвой Оккама.
Они ставили перед собой цель обеспечить «язык для склеивания» составляющих частей веб-ресурса: изображений, плагинов, Java-апплетов, который был бы удобен для веб-дизайнеров и программистов, не обладающих высокой квалификацией
> а уж переносить ее на backend — это чистой воды мазохизм
Вся горькая суть этого тезиса становится понятна, когда бекенд разработчик обнаруживает, что его либы, которые ещё фронтендщики используют, должны работать в FF, Chrome, IE7-9, а то и в IE6. В этот момент у него обычно появляется когнитивный диссонанс и вопросы к Всевышнему «Как это произошло? Почему я всю жизнь не лез в эти браузеры, и всё равно в конце-концов должен проверять код в осле???»
Из моего субъективного опыта (уже два кода проект на ноде), никто из чистых бекендщиков не рад ноде и js на сервере. Ему рады фронтендщики, которые теперь могут писать серверный код не изучая других языков.
Да ладно вам, код подбирают режиссёры? Серьёзно?
Думаю, большая часть из тех, кто подписал, даже не читала. Остальная часть прочла, но не вникла. А ведь комиссия будет обсуждать именно это, а не комментарии на хабре. Они рассмотрят всего один аргумент из инициативы «снижение конкуренции», легко покроют его пророссийским «поднятие российского производства» и разойдутся. Дело на 5 минут.
Если автор будет читать этот комментарий, то:
— меньше воды
— больше фактов
— слова вроде «неоспоримым» «многократно завышенных», «непомерных» не заменяют факты. Наоборот, они вызывают ощущение хлипкого фундамента, когда у автора нет фактов и таким образом он пытается это прикрыть.
— выделяйте минусы отдельно, как список.
— найдите побольше минусов, а не один. Даже здесь в комментариях есть минусы, которых нет в инициативе. Например, потребители очень редкого товара просто будут больше платить, потому что наши такой товар продавать не будут. Это национальный товар, товар с очень маленьким спросом, который на одну страну производить не выгодно, и прочий эксклюзив.
— используйте информационный стиль. Хотя бы ставьте подлежащее и сказуемое рядом, а не через 10 слов, как в 6 абзаце (кстати, самом важном).
Если нужны крепкие подпорки, может легче делать углубления и печатать подпорки отдельно, а потом вклеивать?
И другой вопрос: А нужны ли крепкие подпорки в прототипе из 3d принтера? Может легче просто сделать ребро жесткости, и хоть в принтере это будет не так крепко, но в промышленном литье из пластика всё будет отлично.
И тут оказывается, что второе случайное число выполняет ту же функцию, но теперь чтоб уж точно. Вопросов куча: зачем первый random если второй nounce и так обязателен? Почему вводится обязательный nounce, когда первый предлагается очень мягко? Почему непонятное имя nounce? Почему в доке не раскрыт смысл nounce, как random? И почему Алисе он выдается в самом конце, а не когда она только начала инициализировать соединение, как random? Всё выглядит ну очень нелогично, пока в теории не появляется Большой Брат и всё быстро становится на свои места. Что ещё нужно для параноика, не так ли?
Но вероятность, что так и было, есть. Сам был на другой стороне, когда простая ошибка со стороны выглядела как заговор. Видел, как работа нескольких людей в сумме давала непоследовательный и нелогичный результат (прям как здесь). Верится очень слабо, но исключить добрые намерения не могу. :) (хотя бы у тех, кто проверял)
Там отдельный параграф про «random», который в самом начале приходит с p и g, и примешивается к рандому клиента. И отдельный параграф про nounce, который приходит после того, как сервер может вычислить секретный ключ для Алисы и знает секретный ключ у Боба. Почему бы не передавать nounce с самого начала? Зачем он вообще нужен если random уже примешали?
В ноде я как-то пытался отлаживать через node-inspector, поставил брекпоинт, нода остановилась, и, пока я смотрел на переменные в вотчлисте, истекла пара таймаутов. После того, как я нажал run, процесс выдал ошибки и пошел совсем по другому пути. С тех пор я просто вставляю принты и перезапускаю ноду.
В ноде вообще-то таймаутов почти нет, и всё равно они у меня сработали. В эрланге же их рекомендуют ставить на каждый receive. Поэтому проблем с паузой там будет на порядок больше. Особенно, если ставить на паузу всю эрланг-машину. И, конечно, такой метод не годится для отладки продакшн системы на лету.
Это, как я понимаю, общая проблема для актор-систем, если они написаны аккуратно, т.е. с таймаутами.
Поэтому, принты, принты и только принты. И вот с этим в эрланге всё очень хорошо: можно подключиться к ноде на лету (даже продакшн), на лету включить трейс на вызов любых функций, на лету получить и время, и переданные аргументы, и результат, и также на лету пропатчить. Такого мне очень сильно не хватает в других языках, включая ноду с её node-inspector.
показывает, насколько неожиданно глубоко вы разбираетесь в рыночных механизмах. Безусловно, вы правы, нельзя давать деньги за информацию о преступниках, иначе того и гляди все начнут гоняться за бандитами и подохнут с голоду. Я бы и такси, кстати, не рекомендовал бы оплачивать, а то все начнут друг-друга возить и тоже подохнут с голоду.
Стоп! А если я буду платить за еду, то все начнут мне готовить и подохнут с голоду, а потом и я. Похоже, голод неминуем. Тогда может разрешить охоту за головами, раз финал один и тот же?
Если я сейчас оставлю программирование и вольюсь в общество кардеров, а потом их всех сдам. Банки, думаю, заплатят. Это тоже «порочная и больная система»?
А давайте вспомним Дикий Запад и эти объявления «Wanted» на убийц и насильников, и целый класс охотников за головами, которые только этим и жили. Тоже «порочная и больная система»?
А когда по телеку предлагают деньги за информацию о каком-нибудь преступнике (жаль, только в кино предлагают, в жизни бесплатно), это тоже больная система?
Есть спрос на информацию о вредных личностях, почему бы и не дать предложение. Всем же лучше.
Чем они отличаются от всеми нелюбимых издателей? И те и другие строят свой бизнес на чужом контенте. По-моему, они даже хуже: издатели хоть чуть-чуть делятся с авторами, а такие пираты вообще всё в карман.
Это не поможет. Знание языка — это очень маленькая часть, от знаний, которые нужны специалисту в той или иной части проекта.
Даже если и там и там JS, фронтендщики не полезут в бекенд, а бекендщики не должны лезть в фронтенд. Они по разному пишут, по разному работают с колбеками (deffered vs async), разные ньюансы (DOM и браузеры vs node и concurrency), разные инструменты отладки, да вообще почти всё разное. Даже разные точки зрения на задачу: фичи и динамика vs стабильность и нагрузка. Бекендщику в фронтенде от знания js примерно столько же пользы, сколько гастроэнтерологу в стоматологии от знаний русского языка и латыни.
Так что время на изучение другого языка (после 10 языков на 11-ый уйдёт час-два + stackoverflow) незначительно на фоне времени, которое нужно, чтобы вникнуть в матчасть, и покрывается с лихвой, если другой язык — это язык заточенный под конкретную задачу, а то и DSL.
На практике, если бекендщик не будет отбрасывать ошибочные запросы с объяснением что не так, то фронтендщики завалят багтрекер тикетами на «глючащий» бекенд, хотя ошибки на их стороне. Поэтому валидация на бекенде нужна, и не из-за паранои, а просто чтобы упростить всем жизнь, как автоматический судья, который решает, у кого бага.
> Авторизация — это щепотка бизнес-задачи (узнать, кто обратился)
Это аутентификация. Я имел в виду авторизацию, т.е. проверку имеет ли этот юзер права на чтение/изменение этих данных. Эта проверка нужна и фронтенду, чтобы попрятать кнопочки и ссылочки, и само-собой бекенду. Вот и дублирование кода.
Про модель, это отсылка к Meteor, где и клиент и сервер расшаривают одно и тоже описание модели. Нет больше этого плюса, если бекенд не на ноде.
Более того, нодовцы должны даже сильнее критиковать эту идею, чем бекендщики. Возьмём валидацию, где её надо делать? Ни один бекендщик не оставит валидацию клиентам, а с его точки зрения ui-backend на ноде — это уже клиент. Значит будет дублирование кода валидации на js и на языке бекенда. Тоже самое с моделью и с авторизацией. Опять дублируем кучу кода. Ассинхронность ноды тоже теперь не достоинство, она никак не поможет бекенду.
И вот единственный плюс от такой прослойки — это то, что бекендщики теперь не думают про REST и веб. Это важно, если у бекенда несколько клиентов, но в остальных случаях эту прослойку скорее всего просто вырежут бритвой Оккама.
Ну надо же! Вот, оказывается, почему Интернет стал таким популярным.
Вся горькая суть этого тезиса становится понятна, когда бекенд разработчик обнаруживает, что его либы, которые ещё фронтендщики используют, должны работать в FF, Chrome, IE7-9, а то и в IE6. В этот момент у него обычно появляется когнитивный диссонанс и вопросы к Всевышнему «Как это произошло? Почему я всю жизнь не лез в эти браузеры, и всё равно в конце-концов должен проверять код в осле???»
Из моего субъективного опыта (уже два кода проект на ноде), никто из чистых бекендщиков не рад ноде и js на сервере. Ему рады фронтендщики, которые теперь могут писать серверный код не изучая других языков.
Это получается, у нас тут серебрянная пуля, технология без недостатков? А как же у каждой медали есть две стороны?