Да все понятно и очень явно :) Тут, конечно, дело вкуса, а о вкусах не спорят. Я не предлагаю называть филды mName или pName - все это точно такой же camelCase. Всё же, мои соображения таковы:
Параметры метода - camelCase. Как и локальные переменные (обычно). У нас не какой-то супер-кастомный code style, +- все так делают (это пусть будет аксиома)
Вот смотришь на ревью, добавлена строчка name = 1 . Будем считать, что присваивать значения input параметрам метода - плохая практика. Это локальная переменная, или человек забыл написать this? А если есть и локальная переменная с таким именем, и филд - как понять? А если написано _name = 1 - всё сразу ясно и понятно.
В принципе и так всегда должно быть понятно, что ты хочешь сделать. Код, который не требует комментариев, все дела. Если необходимо уточнять свои намерения, добавляя this - код уже ну типа не очень ясный. Если это не нужно - то и this не нужен.
Отдельный смак - это проперти. Будем считать, что проперти пишутся в PascalCase (в C# +- все так делают, не знаю, есть ли проперти в Java). Писать this.Name = 1 - чтобы что? Неужели где-то в глобальной области видимости есть Name который можно присвоить?
А вызовы методов? this.Method() - как и в прошлом пункте, шанс того, что тут можно что-то перепутать, крайне невелик.
Таким образом, в зависимости от вкуса, модификатор может быть нужен только для филдов, и то, если не хватило мотивации называть их как-то по-другому. Во всех остальных случаях - не нужен никогда. А для одного частного случая, можно чуть заморочиться, и облегчить всем жизнь. Моё такое мнение.
Насчет человека со стороны. У нас люди не так часто меняются, но все же, когда это происходит - есть .editorconfig, stylecop и набор анализаторов, так что проблем с тем, чтобы вникнуть, не возникает. Даже без этого, если человек на основе одного-двух файлов не может понять, что к чему - может лучше с ним и не работать вообще.
Давно не писал на javascript, на C# решаем проблему соглашениями по именованию. Т е чтобы не писать this.name = name пишем, например, _name = name или Name = name. Вообще, для меня использование this - плохой тон, почти всегда (вообще всегда, кроме пары синтетических примеров) можно обойтись без него. В C# конечно.
Ну, тут упор на то, что он знает. Конечно, он может построить историю, но факт построения истории не является такой уж большой проблемой, т к без VPN он и так знает вашу историю, а с VPN её знает ещё и владелец VPN.
Речь была про тот случай, когда хочешь скрыть от провайдера, куда ты ходишь. А про историю это отдельная большая ортогональная тема, никак не связанная с dns ip leak.
Я про историю просмотров/посещений вообще ни слова не говорил нигде :) Туннели да прокладывают, но не на основе истории отдельно взятого юзера, а на основе агрегированной статистики. С утечками это не имеет ничего общего.
О чем и речь, говорю же, смысла нет. Что у вас бомбануло так, я не понимаю.
Поищите метрику DAU, это +- то же самое только посередине connected. Мне кажется, я вам говорю про тёплое, а вы мне - про мягкое. Не вижу смысла это продолжать.
Ну, я наверное плохо объясняю, раз так тяжело понять. Истории про сервисы, которые ведут себя по-разному в зависимости от того, откуда вы пришли - они не высосаны из пальца. И я не призываю, опять же, никого платить - сам не пользуюсь. Когда надо, на работе прошу админов настроить рабочий впн, чтобы и наружу тоже работал.
А про нарушение закона - ну вот на одной из прошлых работ мы делали впны. Собираешь те же метрики dcu - юзеры в основном из стран типа пакистана, ирана, египта, азербайджана. Смотришь куда они в основном ходят, делаешь туннели чтобы не тормозило. Фичи добавляешь востребованные :) Просто бизнес, ничего личного. Судя по dcu, либо там по полстраны народа преступников, либо тезис ну не совсем состоятельный.
А в курилке таким хвастаться ну это типа вообще не уровень. Вообще хвастаться это как-то по-детски что ли. Кому надо - тот молча дела делает
Понимаете, если меня провайдер или тов. майор спросит пользуюсь ли я ВПН я скажу что пользуюсь. И даже могу историю браузера им показать если очень надо.
Одно другому вообще-то не мешает. Кто-то может перфекционист, и чувствует себя неуютно, когда утечка адреса есть. Где-то может быть сервис, который использует расширенную геолокацию, чтобы блокировать доступ (вспомнить хотя бы волну про-украинских сайтов, запрещающих доступ из РФ/если стоит русская локаль/и т.д.). Совершенно необязательно нарушать закон. Жаль, что у вас такая ассоциация :)
Честно говоря вообще не вижу смысла доказывать, для чего нужно скрывать утечки своего адреса. Хочу - и баста, я думаю, это достаточно сильный аргумент :)
если меня провайдер или тов. майор спросит пользуюсь ли я ВПН я скажу что пользуюсь. И даже могу историю браузера им показать если очень надо
И я могу, но не строю всю свою жизнь исходя из этого. Более того - не могу представить, чтобы такая ситуация произошла.
Пользователи из нидерландов так же могут быть русскими
И при чём же здесь национальность? Не думаю, что кто-то собирает такую метрику, а если и собирает кто-то, то не только лишь все, потому что это непросто. Я про что в данном контексте.
Вот есть у вас продукт - пусть это будет сайт. Вы собираете некоторые метрики - например, сколько всего уникальных пользователей в день зашло, и откуда. И, предположим, видите, что из Нидерландов сегодня был миллион уникальных юзеров. Бизнес может принимать решения на основе этих метрик - например, сделать локализацию сайта. Имея более точное определение страны пользователя, вы можете понять, что, допустим, из этого миллиона только 50 000 было из Нидерландов, остальные из других стран сидят через VPN. Локализацию делать бизнесу невыгодно, деньги не потеряны. Так понятнее?
Ну в россии смотреть порно не запрещено
Это никак не относится к теме нашего обсуждения, я нигде не говорил про порно и РФ в одном контексте. VPN он не только в РФ нужен, вот это поворот.
То есть, получается, что скрывать доменное имя есть смысл только если нарушаешь метсные законы?
Давайте рассмотрим такое утверждение. Все люди - приматы. Значит ли это, что все приматы - люди? Вот ваша логика так и выглядит. Если так рассуждать, то и VPN используют только преступники.
Специально детектить в общем-то большого смысла я тоже не вижу, только может если метрики точнее собирать (например, юзер не из Нидерландов, а из РФ), либо делать сайт, который детектит эти утечки.
А смысл их закрывать следующий.
Например, есть страны, где просмотр порно, скажем так, сильно не одобряется на государственном уровне. Вот ты весь такой технически подкованный включаешь впн, и все равно смотришь. А в это время твой провайдер по днс запросам знает, на какие сайты ты ходишь, и может на тебя настучать. Таким образом, будешь наказан, несмотря на впн.
Есть и другие приколы похожего рода, например, интернет пропал на минутку, впн отключился, и запретное видео дальше автоматом идет через незащищенный канал. Опять встрял.
Таких нюансов много, поэтому впн клиенты надо тщательно выбирать.
Про DNS запросы - кажется, вы описываете DNS IP leak. Тут ещё нужно генерировать какой-то рандомный поддомен (чтобы точно ничего нигде не кешировалось), и убедиться, что ваш сервер якобы его резольвит. DNS клиент (как минимум в Windows) по умолчанию отправляет DNS запросы сразу по всем интерфейсам, поэтому и палится оригинальный IP, несмотря на подключенный VPN. Точнее, видно только DNS сервер, от которого приходит запрос, но владелец этого DNS сервера знает, куда вы ходите, несмотря на VPN.
В нормальных VPN клиентах эта уязвимость исправляется, чаще всего на уровне WFP.
Интересная тема, подскажите один момент - вот есть боты для онлайн игр, использующие распознавание изображений, и имитацию действий мышкой/клавиатурой с произвольной задержкой. Если упростить, допустим, у нас есть AutoIt скрипт под конкретный сайт, который в настоящем браузере как настоящий юзер чего-то там кликает. Понятно, что по эффективности такой бот будет проигрывать. Но тем не менее, как быть в такой ситуации?
У меня такое чувство, что мы говорим о разных вещах. Взять те же UI тесты. По-хорошему, слой логики UI (view model) существует отдельно от самого UI (view) - т е лёгким движением руки мы можем вместо WPF натянуть ASP.NET MVC или консоль, и так далее. Соответственно, то, что будет происходить при нажатии кнопок и так далее - легко тестируется без самого UI (если грамотно подойти к архитектуре), интеграционными тестами. Главное, отрезать в правильных местах. А UI тесты - это уже про appearance, типа кнопки метки в правильных местах правильного цвета, сообщения об ошибках и тд. В любом случае, если ваш подход работает для вас - не смею вас переубеждать.
И так далее. Очевидно, тут мы не выполняем CRUD операции над ресурсами, а выполняем действия. Это и есть RPC. Если бы я такой API обозвал REST на работе - меня б с позором выгнали :) Вообще, если API использует HTTP и JSON, и имеет схему OpenAPI - это ещё совсем не значит, что это REST.
Допустим, строим дом. Протестили все кирпичи, раствор, проводку, сантехнику и тд. Заходим смотреть - открыли дверь - крыша упала. Как же так, ведь все протестировано.
Дом ещё и не типовой, а экспериментальный продукт так сказать - все время проект дорабатывается, что-то меняется, добавляется, убирается. Заказали новые кирпичи, потратили время на разработку тестовых испытаний для них - через месяц архитектор говорит их надо выкинуть, и брать другие. Время и силы потрачены впустую. С другой стороны, заказчик уверен, что в доме должна быть дверь, через которую он может войти, и эта часть проекта вряд ли когда-то изменится.
Я не против юнит тестов. Моё мнение такое, что всё подряд ими покрывать не только бесполезно, но ещё и вредно. Какие-то конкретные важные базовые компоненты - пожалуйста. Бизнес логику - не думаю. Юнит тест проверяет, что логика компонента работает так, как написано в юнит тесте, не больше, не меньше. Когда логика компонента часто меняется (рефакторинг вью моделей, например) - юнит тест придётся так же часто менять.
Если подумать - то с точки зрения клиента (пользователя API клиента) это действительно так. Вообще, в реальном коде, даже автосгенерированный клиент никто не будет использовать напрямую как есть. Будет какой-то удобный для потребителя интерфейс INotesClient, который уже в свою очередь будет что-то куда-то мапить, и вызывать сгенерированный клиент. В тестах будет тестовая реализация. Для потребителя, соответственно, это будет выглядеть так, как будто он вызывает какие-то методы - но это не значит, что под капотом RPC (взять хотя бы тестовую реализацию). По-моему, это называется абстракция, и делать выводы по интерфейсу не совсем корректно.
Для начала, покажите мне локальный IPC на основе REST (например, когда локальный сервис при запуске говорит UI клиенту - покажи главное окно). Конечно, можно придумать синтетический пример типа `POST /displayedWindows`, интересны реальные проекты.
Смысл в том, что в случае с REST мы не вызываем методы явно, а работаем с ресурсами. Естественно, на каком-то уровне какой-то код своим запросом мы выполним, но в случае REST нам неважно, что делает этот код, до тех пор, пока он выполняет нужные нам операции с ресурсами. Например, это может быть какой-то API сервис заметок - где мы будем создавать заметки, обновлять заметки, получать их и удалять, типа такого:
GET /notes
GET /notes/{id}
PUT /notes/{id} (или POST /notes)
PATCH /notes/{id}
DELETE /notes/{id}
Т е наш API не даёт нам возможность вызвать какую-то процедуру, давая нам вместо этого возможность работать с ресурсами. В случае с RPC можно было бы сделать какой-то такой API:
POST /getAllNotes
POST /getNoteById
POST /createNote
POST /updateNote
POST /deleteNote
Т е мы своими вызовами явно выполняем какие-то конкретные действия. Теперь мы можем сделать то, что обычно в REST не делается, например:
POST /backupNotes - такой метод мог бы сделать бэкап заметок, и отправить его куда-нибудь
POST /emailNote - типа отправить заметку на почту
POST /printNote - распечатать заметку
И так далее. Конечно, для работы с ресурсами (как заметки) - REST подходит намного лучше, даже выглядит как-то красивее и лаконичнее.
Ох если бы бэкенд состоял только из крудов :) Поживём - увидим
Да все понятно и очень явно :) Тут, конечно, дело вкуса, а о вкусах не спорят. Я не предлагаю называть филды mName или pName - все это точно такой же camelCase. Всё же, мои соображения таковы:
Параметры метода - camelCase. Как и локальные переменные (обычно). У нас не какой-то супер-кастомный code style, +- все так делают (это пусть будет аксиома)
Вот смотришь на ревью, добавлена строчка
name = 1. Будем считать, что присваивать значения input параметрам метода - плохая практика. Это локальная переменная, или человек забыл написатьthis? А если есть и локальная переменная с таким именем, и филд - как понять? А если написано_name = 1- всё сразу ясно и понятно.В принципе и так всегда должно быть понятно, что ты хочешь сделать. Код, который не требует комментариев, все дела. Если необходимо уточнять свои намерения, добавляя
this- код уже ну типа не очень ясный. Если это не нужно - то иthisне нужен.Отдельный смак - это проперти. Будем считать, что проперти пишутся в PascalCase (в C# +- все так делают, не знаю, есть ли проперти в Java). Писать
this.Name = 1- чтобы что? Неужели где-то в глобальной области видимости естьNameкоторый можно присвоить?А вызовы методов?
this.Method()- как и в прошлом пункте, шанс того, что тут можно что-то перепутать, крайне невелик.Таким образом, в зависимости от вкуса, модификатор может быть нужен только для филдов, и то, если не хватило мотивации называть их как-то по-другому. Во всех остальных случаях - не нужен никогда. А для одного частного случая, можно чуть заморочиться, и облегчить всем жизнь. Моё такое мнение.
Насчет человека со стороны. У нас люди не так часто меняются, но все же, когда это происходит - есть .editorconfig, stylecop и набор анализаторов, так что проблем с тем, чтобы вникнуть, не возникает. Даже без этого, если человек на основе одного-двух файлов не может понять, что к чему - может лучше с ним и не работать вообще.
Давно не писал на javascript, на C# решаем проблему соглашениями по именованию. Т е чтобы не писать
this.name = nameпишем, например,_name = nameилиName = name. Вообще, для меня использованиеthis- плохой тон, почти всегда (вообще всегда, кроме пары синтетических примеров) можно обойтись без него. В C# конечно.Ну, тут упор на то, что он знает. Конечно, он может построить историю, но факт построения истории не является такой уж большой проблемой, т к без VPN он и так знает вашу историю, а с VPN её знает ещё и владелец VPN.
Речь была про тот случай, когда хочешь скрыть от провайдера, куда ты ходишь. А про историю это отдельная большая ортогональная тема, никак не связанная с dns ip leak.
Я про историю просмотров/посещений вообще ни слова не говорил нигде :) Туннели да прокладывают, но не на основе истории отдельно взятого юзера, а на основе агрегированной статистики. С утечками это не имеет ничего общего.
О чем и речь, говорю же, смысла нет. Что у вас бомбануло так, я не понимаю.
Поищите метрику DAU, это +- то же самое только посередине connected. Мне кажется, я вам говорю про тёплое, а вы мне - про мягкое. Не вижу смысла это продолжать.
Ну, я наверное плохо объясняю, раз так тяжело понять. Истории про сервисы, которые ведут себя по-разному в зависимости от того, откуда вы пришли - они не высосаны из пальца. И я не призываю, опять же, никого платить - сам не пользуюсь. Когда надо, на работе прошу админов настроить рабочий впн, чтобы и наружу тоже работал.
А про нарушение закона - ну вот на одной из прошлых работ мы делали впны. Собираешь те же метрики dcu - юзеры в основном из стран типа пакистана, ирана, египта, азербайджана. Смотришь куда они в основном ходят, делаешь туннели чтобы не тормозило. Фичи добавляешь востребованные :) Просто бизнес, ничего личного. Судя по dcu, либо там по полстраны народа преступников, либо тезис ну не совсем состоятельный.
А в курилке таким хвастаться ну это типа вообще не уровень. Вообще хвастаться это как-то по-детски что ли. Кому надо - тот молча дела делает
Одно другому вообще-то не мешает. Кто-то может перфекционист, и чувствует себя неуютно, когда утечка адреса есть. Где-то может быть сервис, который использует расширенную геолокацию, чтобы блокировать доступ (вспомнить хотя бы волну про-украинских сайтов, запрещающих доступ из РФ/если стоит русская локаль/и т.д.). Совершенно необязательно нарушать закон. Жаль, что у вас такая ассоциация :)
Честно говоря вообще не вижу смысла доказывать, для чего нужно скрывать утечки своего адреса. Хочу - и баста, я думаю, это достаточно сильный аргумент :)
И я могу, но не строю всю свою жизнь исходя из этого. Более того - не могу представить, чтобы такая ситуация произошла.
И при чём же здесь национальность? Не думаю, что кто-то собирает такую метрику, а если и собирает кто-то, то не только лишь все, потому что это непросто. Я про что в данном контексте.
Вот есть у вас продукт - пусть это будет сайт. Вы собираете некоторые метрики - например, сколько всего уникальных пользователей в день зашло, и откуда. И, предположим, видите, что из Нидерландов сегодня был миллион уникальных юзеров. Бизнес может принимать решения на основе этих метрик - например, сделать локализацию сайта. Имея более точное определение страны пользователя, вы можете понять, что, допустим, из этого миллиона только 50 000 было из Нидерландов, остальные из других стран сидят через VPN. Локализацию делать бизнесу невыгодно, деньги не потеряны. Так понятнее?
Это никак не относится к теме нашего обсуждения, я нигде не говорил про порно и РФ в одном контексте. VPN он не только в РФ нужен, вот это поворот.
Давайте рассмотрим такое утверждение. Все люди - приматы. Значит ли это, что все приматы - люди? Вот ваша логика так и выглядит. Если так рассуждать, то и VPN используют только преступники.
Специально детектить в общем-то большого смысла я тоже не вижу, только может если метрики точнее собирать (например, юзер не из Нидерландов, а из РФ), либо делать сайт, который детектит эти утечки.
А смысл их закрывать следующий.
Например, есть страны, где просмотр порно, скажем так, сильно не одобряется на государственном уровне. Вот ты весь такой технически подкованный включаешь впн, и все равно смотришь. А в это время твой провайдер по днс запросам знает, на какие сайты ты ходишь, и может на тебя настучать. Таким образом, будешь наказан, несмотря на впн.
Есть и другие приколы похожего рода, например, интернет пропал на минутку, впн отключился, и запретное видео дальше автоматом идет через незащищенный канал. Опять встрял.
Таких нюансов много, поэтому впн клиенты надо тщательно выбирать.
Действительно, через групповые политики. Но надёжнее в любом случае заблочить DNS пакеты на всех интерфейсах, кроме VPN.
Про DNS запросы - кажется, вы описываете DNS IP leak. Тут ещё нужно генерировать какой-то рандомный поддомен (чтобы точно ничего нигде не кешировалось), и убедиться, что ваш сервер якобы его резольвит. DNS клиент (как минимум в Windows) по умолчанию отправляет DNS запросы сразу по всем интерфейсам, поэтому и палится оригинальный IP, несмотря на подключенный VPN. Точнее, видно только DNS сервер, от которого приходит запрос, но владелец этого DNS сервера знает, куда вы ходите, несмотря на VPN.
В нормальных VPN клиентах эта уязвимость исправляется, чаще всего на уровне WFP.
Проверяйте свои VPN клиенты :)
https://browserleaks.com/dns
https://browserleaks.com/webrtc
Интересная тема, подскажите один момент - вот есть боты для онлайн игр, использующие распознавание изображений, и имитацию действий мышкой/клавиатурой с произвольной задержкой. Если упростить, допустим, у нас есть AutoIt скрипт под конкретный сайт, который в настоящем браузере как настоящий юзер чего-то там кликает. Понятно, что по эффективности такой бот будет проигрывать. Но тем не менее, как быть в такой ситуации?
У меня такое чувство, что мы говорим о разных вещах. Взять те же UI тесты. По-хорошему, слой логики UI (view model) существует отдельно от самого UI (view) - т е лёгким движением руки мы можем вместо WPF натянуть ASP.NET MVC или консоль, и так далее. Соответственно, то, что будет происходить при нажатии кнопок и так далее - легко тестируется без самого UI (если грамотно подойти к архитектуре), интеграционными тестами. Главное, отрезать в правильных местах. А UI тесты - это уже про appearance, типа кнопки метки в правильных местах правильного цвета, сообщения об ошибках и тд. В любом случае, если ваш подход работает для вас - не смею вас переубеждать.
Это вот этот вот протокол? https://docs.docker.com/reference/api/engine/version/v1.45/
Он частично REST, частично RPC, например:
POST /containers/{id}/resize
POST /containers/{id}/start
POST /containers/{id}/stop
POST /containers/{id}/restart
POST /containers/{id}/kill
POST /containers/{id}/update
POST /containers/{id}/rename
POST /containers/{id}/pause
POST /containers/{id}/unpause
И так далее. Очевидно, тут мы не выполняем CRUD операции над ресурсами, а выполняем действия. Это и есть RPC. Если бы я такой API обозвал REST на работе - меня б с позором выгнали :) Вообще, если API использует HTTP и JSON, и имеет схему OpenAPI - это ещё совсем не значит, что это REST.
Хорошо, если REST это RPC, жду примеров локального IPC на основе REST. Я такого почему-то никогда не видел.
Допустим, строим дом. Протестили все кирпичи, раствор, проводку, сантехнику и тд. Заходим смотреть - открыли дверь - крыша упала. Как же так, ведь все протестировано.
Дом ещё и не типовой, а экспериментальный продукт так сказать - все время проект дорабатывается, что-то меняется, добавляется, убирается. Заказали новые кирпичи, потратили время на разработку тестовых испытаний для них - через месяц архитектор говорит их надо выкинуть, и брать другие. Время и силы потрачены впустую. С другой стороны, заказчик уверен, что в доме должна быть дверь, через которую он может войти, и эта часть проекта вряд ли когда-то изменится.
Я не против юнит тестов. Моё мнение такое, что всё подряд ими покрывать не только бесполезно, но ещё и вредно. Какие-то конкретные важные базовые компоненты - пожалуйста. Бизнес логику - не думаю. Юнит тест проверяет, что логика компонента работает так, как написано в юнит тесте, не больше, не меньше. Когда логика компонента часто меняется (рефакторинг вью моделей, например) - юнит тест придётся так же часто менять.
Если подумать - то с точки зрения клиента (пользователя API клиента) это действительно так. Вообще, в реальном коде, даже автосгенерированный клиент никто не будет использовать напрямую как есть. Будет какой-то удобный для потребителя интерфейс
INotesClient, который уже в свою очередь будет что-то куда-то мапить, и вызывать сгенерированный клиент. В тестах будет тестовая реализация. Для потребителя, соответственно, это будет выглядеть так, как будто он вызывает какие-то методы - но это не значит, что под капотом RPC (взять хотя бы тестовую реализацию). По-моему, это называется абстракция, и делать выводы по интерфейсу не совсем корректно.Для начала, покажите мне локальный IPC на основе REST (например, когда локальный сервис при запуске говорит UI клиенту - покажи главное окно). Конечно, можно придумать синтетический пример типа `POST /displayedWindows`, интересны реальные проекты.
Тут есть ещё момент с парсингом сообщений, парсинг json далеко не бесплатный.
Смысл в том, что в случае с REST мы не вызываем методы явно, а работаем с ресурсами. Естественно, на каком-то уровне какой-то код своим запросом мы выполним, но в случае REST нам неважно, что делает этот код, до тех пор, пока он выполняет нужные нам операции с ресурсами. Например, это может быть какой-то API сервис заметок - где мы будем создавать заметки, обновлять заметки, получать их и удалять, типа такого:
GET /notes
GET /notes/{id}
PUT /notes/{id} (или POST /notes)
PATCH /notes/{id}
DELETE /notes/{id}
Т е наш API не даёт нам возможность вызвать какую-то процедуру, давая нам вместо этого возможность работать с ресурсами. В случае с RPC можно было бы сделать какой-то такой API:
POST /getAllNotes
POST /getNoteById
POST /createNote
POST /updateNote
POST /deleteNote
Т е мы своими вызовами явно выполняем какие-то конкретные действия. Теперь мы можем сделать то, что обычно в REST не делается, например:
POST /backupNotes - такой метод мог бы сделать бэкап заметок, и отправить его куда-нибудь
POST /emailNote - типа отправить заметку на почту
POST /printNote - распечатать заметку
И так далее. Конечно, для работы с ресурсами (как заметки) - REST подходит намного лучше, даже выглядит как-то красивее и лаконичнее.