Операторы не то чтобы блокируют ZT трафик целенаправленно, а, просто дико его режут по скорости и добавляют задержки и минимальный приоритет. Примерно как трафик торрентов.
Мне кажется это добавляет суматоху в понимании проблемы. У мобильных операторов более нестандартная ситуация - клиенты не статичны и разнообразны. В итоге у Nat-а огромное количество постоянно создающихся и теряющихся соединений, и для этого лучше подходят Symmetric NAT, а всякие UPnP и Ко просто бесполезны. Поэтому технология Port-Prediction просто практически не работает.
На каждую пару IP:Port своё соединение. То что сервер ZeroTier узнаёт IP:Port клиентов - это мало полезно. Нельзя угадать новый "соседний" порт нового прямого соединения для одновременно устанавливаемой связи. А часто это уже "соседний" IP NAT-а. ZeroTier сваливается в этом случае в проксирование, точнее не может с него переключиться на P2P. Да именно так. И вот которое потом просто режется, задерживается, понижается приоритет, не на уровне провайдера Мобильного оператора, а на всей цепочке: Клиент1 - ZT Proxy - Клиент2.
Он таки проксирует до 10% трафика. Не всякий NAT подвержен NAT Traversal. К примеру Symmetric генерирует произвольный новый порт на пару IP:Port, который предсказать (Port-Predicted) невозможно.
"Автор рыдает" - это всего лишь восприятие, хоть и коллективное, но всё же субъективное, порождённое через желание всё упрощать. Автор просто показал общественную игру, не он породил понятия социального контракта и всего остального, что крутится в обществе. Привычка видеть везде готовые решения, и негативно относиться к вопросам - это просто привычка.
Автору возможно всё понимает и его стандартные эмоции (негатив на якобы плач) ожидаемы, неинтересны, оправданы. Другое дело какой профит получил автор с этого. Например новые социальные контакты людей/сообществ/организаций.
А с другой стороны "изменение организации общества" - совершенно не сопоставимо по сложности с его жизнью. Это не то что не по плечу автору, оценка крайне субъективна, нет больших статистических данных по решению такого класса задач. А сколько спекуляций ...
Обратный эффект: Непривычна невозможность написать запроса к коду программы/модуля, а дайка получить все такие вызовы через посредника функции, в котором параметры ..., где ... и вычленить из них ... Особенно когда в принципе это можно таки сделать, но нету спроса на такую функционал. Ладно позавчера, когда слоёв мало и можно было довольствоваться одним уровнем, но сегодня этого точно мало.
В базе это легко и делается десяток другой таких мелких запросов, что бы убедится в возможности рефакторинга/оптимизации/расширения функционала. А в императивном коде один такой "запрос" долгий итеративный ручной процесс. Легче через полные тесты выявить. При этом обычно это решается каким-то паттерном, т.е. даже это хаком уже опасно назвать.
20 тысяч строк кода
Больше 500 это клиника, даже больше 50 уже подозрительно. Да, финтех. Но я понимаю, хороший спец по БД очень большая редкость.
При этом видел функции в 30 тысяч на каком-нидь C#. Ровно такой же унылый говнокод.
Но я знаю два таких эффекта:
Если весь код написан примерно равномерно многослойно (много разных фич, паттернов, абстракций), то практически нельзя оценить на сколько оно не оптимально. Просто потому что надо переписать 90% кода что бы эффект какой-то одной оптимизации был выявлен. Т.к. очень часто одно неизбежно цепляет за собой другое и т.д. И поэтому часто видишь такие случаи когда не получается оптимизировать узкое горлышко. Точнее совсем другое - кодеру кажется что быстрее уже физически невозможно.
Поэтому есть простое правило - кода должно быть как можно меньше, на сколько это допустимо.
Привычка. Привычка писать сразу неправильно, типа потом оптимизирую. Как ни крути пишется в каком-то стиле. В идеале всегда думаешь заранее, и это тоже не обязательно правильно ибо построено на каких-то представлениях о предмете. Но если это представление (и стиль в частности) не корректировать (тоже привычка) по опыту (с исследованиями), то в итоге, одни и те же грабли, плохой результат.
И вопрос, как покрытие юнит тестами влияют на размер кода (хранимок в частности)?
У меня на практике наличие понимания (желания дотянуться до реального понимания) и определяет уровень кодовой базы. Это норма, когда весь ИТ отдел заказчика говорит что быстрее невозможно, и после рефакторинга (когда кодовая база уменьшается многократно) узнают о CPU Core Parking, значительное уменьшении IO, и размеров потребляемых ресурсов. Видно что код строился на мифах, целом клубке их. И поэтому важно другое, лучше понимают что есть в коде и какова его логика и архитектура. Или пишут на рекламируемом EF и даже банально не замечают десяток дедлоков в минуту.
И у БД другая палка в колесе, хранение реальных, ценных данных, т.е. миграция не многогранно не бесплатна. Код модуля поправил протестил и заменил. Делов то. Но с базой так не пойдёт, не говоря о параллельной совместимости. И подходы в ней другие: структура данных строится под функционал, а не по наивной предметной области. И поэтому важно выявить статистические паттерны функционала, что бы не-было постоянных ненужных преобразований туда-обратно-вывернуть-развернуть. И поэтому если нет функционала свободно обратиться к кодовой базе в виде запросов, т.е. представить кодовую базу в любое представление - то значить и оценка эффективности всего решения будет более субъективная.
материалов очень большое разнообразие. Со всеми добавками и примесями. Волокнистые, могут кардинально влиять на процессы, в зависимости от размера и структуры "ворсинок". Которые могут меняться в зависимости от условий и времени. Всю гамму которых тяжело изучить, особенно на фоне экономических "оптимизаций", не способствующее развитию непредвзятых исследований.
Во взаимодействии участвуют два вещества (в простом случае). И не только набором свойств одной стороны (энергия разложения, ...) взаимодействия характеризуются. Вон интерференции белков, вещь только начинает исследоваться.
И не только быть катализатором, из-за особых диалектических свойств, стремятся покрывать поверхности, изменяя их потенциал и тем самым влияя на процессы, которые мы возможно не все изучили. И т.п. То что получился камень, говорит о пластичности.
Опять же, природа приспособиться, конечно, но как скоро? По сравнению с той скоростью эта природа наполняется по объему этими веществами. Это я повторяюсь.
Вы сами понимаете, что "хорошо изучены", или "недостаточно изучены" вещь чисто субъективная. Независимо от объема изучения научных статей каждым из нас. И не считая таких банальностей типа ТИМа (по Соционике).
И на счёт каучука. Наводя истерию типа "Пластик безвреден", без уточнения деталей. Не способствует здоровой атмосфере. В моем регионе часто используется переработанная вспененная резина на площадках (спортивных, детских), которая в других регионах планеты считается жутко канцерогенными. Даже если этот пост Ализара не стоит в принципе особого внимания. Хотя интересен в силу эрудиции - пластмассовые камни.
Проблема не в том что это пластик. Проблема в том что структурно (философски) невозможно получить адекватный ответ выйдя за рамки: времени, объёма инфрмации.
И не в том что "мы все умрём", никто это не утверждает, а в допустимых пределах "ответа". Тут некоторые бредят дожить до массовых полётов в космос, а не подождать следующего витка эволюции качественной жизни в "пластиковой" среде. Мы (этот вид) с вирусами/бактериями плохо справляемся. И пофег что бактерии/жизнь условно не убиваемы как принцип. Если все плохо-активные вещества, поглотились и осели раком умершими динозаврами за лям лет, размазавшись в толще пород, то потомки (не наши), могут также шутить про поглощённый пластик таким же способом.
Проблема что параметры системы меняются всё быстрее чем мы можем найти/оценить причины и последствия. Когда количество перейдёт в качество? Мои субъективные ощущения, что дело не в том что наши старики (за 70-80) умирают от рака (типа раньше такое не умели диагностировать), а то что умереть от рака в 50, станет обычной нормой.
Можно выходить на пластиковый пляж под палящим солнцем много лет подряд, и только через 10 лет начать жить с раком. Или в 50, когда какие-то ранее неизвестные процессы организма сдерживали последствия, и в силу естественного запрограммированного старения, показало результат. Который стал только через это десятилетие показывать 6 сигм статистической значимости.
И да, я предвзят. Когда у близких проблемы. Когда группа людей (6 человек) имела относительной небольшой контакт (от 3х месяцев, до 2х лет) с парами каучука, и больше не пересекалась, и не имела иной "химической" истории. И только спустя время, а может и в силу возраста все "попали". И в никакую статистику по заболеваемости, их причин, они не попали. Кроме вот такого субъективного ощущения.
Говоришь про пропорциональность? А ты её можешь правильно оценить? Думаешь купались в парах каучука?
И новость не об истерии пластика. А в том что модели по его распространению надо уточнять и больше усилий по исследованиям. Как и были изменены нормы по безопасности в работе с химическими веществами и/или изменению технологического процесса. Спектр "активности" веществ и типов влияния всё более растягивает и заполняется, в силу энтропии. Твоя "пропорциональность" хорошо работает?
Мне кажется это добавляет суматоху в понимании проблемы.
У мобильных операторов более нестандартная ситуация - клиенты не статичны и разнообразны. В итоге у Nat-а огромное количество постоянно создающихся и теряющихся соединений, и для этого лучше подходят Symmetric NAT, а всякие UPnP и Ко просто бесполезны. Поэтому технология Port-Prediction просто практически не работает.
На каждую пару IP:Port своё соединение. То что сервер ZeroTier узнаёт IP:Port клиентов - это мало полезно. Нельзя угадать новый "соседний" порт нового прямого соединения для одновременно устанавливаемой связи. А часто это уже "соседний" IP NAT-а.
ZeroTier сваливается в этом случае в проксирование, точнее не может с него переключиться на P2P. Да именно так. И вот которое потом просто режется, задерживается, понижается приоритет, не на уровне провайдера Мобильного оператора, а на всей цепочке: Клиент1 - ZT Proxy - Клиент2.
Он таки проксирует до 10% трафика. Не всякий NAT подвержен NAT Traversal.
К примеру Symmetric генерирует произвольный новый порт на пару IP:Port, который предсказать (Port-Predicted) невозможно.
"Автор рыдает" - это всего лишь восприятие, хоть и коллективное, но всё же субъективное, порождённое через желание всё упрощать. Автор просто показал общественную игру, не он породил понятия социального контракта и всего остального, что крутится в обществе.
Привычка видеть везде готовые решения, и негативно относиться к вопросам - это просто привычка.
Автору возможно всё понимает и его стандартные эмоции (негатив на якобы плач) ожидаемы, неинтересны, оправданы. Другое дело какой профит получил автор с этого. Например новые социальные контакты людей/сообществ/организаций.
А с другой стороны "изменение организации общества" - совершенно не сопоставимо по сложности с его жизнью. Это не то что не по плечу автору, оценка крайне субъективна, нет больших статистических данных по решению такого класса задач. А сколько спекуляций ...
И да, автор продолжает "рыдать"?
Обратный эффект: Непривычна невозможность написать запроса к коду программы/модуля, а дайка получить все такие вызовы через посредника функции, в котором параметры ..., где ... и вычленить из них ...
Особенно когда в принципе это можно таки сделать, но нету спроса на такую функционал. Ладно позавчера, когда слоёв мало и можно было довольствоваться одним уровнем, но сегодня этого точно мало.
В базе это легко и делается десяток другой таких мелких запросов, что бы убедится в возможности рефакторинга/оптимизации/расширения функционала. А в императивном коде один такой "запрос" долгий итеративный ручной процесс. Легче через полные тесты выявить. При этом обычно это решается каким-то паттерном, т.е. даже это хаком уже опасно назвать.
Больше 500 это клиника, даже больше 50 уже подозрительно. Да, финтех.
Но я понимаю, хороший спец по БД очень большая редкость.
При этом видел функции в 30 тысяч на каком-нидь C#. Ровно такой же унылый говнокод.
Но я знаю два таких эффекта:
Если весь код написан примерно равномерно многослойно (много разных фич, паттернов, абстракций), то практически нельзя оценить на сколько оно не оптимально.
Просто потому что надо переписать 90% кода что бы эффект какой-то одной оптимизации был выявлен. Т.к. очень часто одно неизбежно цепляет за собой другое и т.д.
И поэтому часто видишь такие случаи когда не получается оптимизировать узкое горлышко. Точнее совсем другое - кодеру кажется что быстрее уже физически невозможно.
Поэтому есть простое правило - кода должно быть как можно меньше, на сколько это допустимо.
Привычка. Привычка писать сразу неправильно, типа потом оптимизирую.
Как ни крути пишется в каком-то стиле. В идеале всегда думаешь заранее, и это тоже не обязательно правильно ибо построено на каких-то представлениях о предмете. Но если это представление (и стиль в частности) не корректировать (тоже привычка) по опыту (с исследованиями), то в итоге, одни и те же грабли, плохой результат.
И вопрос, как покрытие юнит тестами влияют на размер кода (хранимок в частности)?
У меня на практике наличие понимания (желания дотянуться до реального понимания) и определяет уровень кодовой базы. Это норма, когда весь ИТ отдел заказчика говорит что быстрее невозможно, и после рефакторинга (когда кодовая база уменьшается многократно) узнают о CPU Core Parking, значительное уменьшении IO, и размеров потребляемых ресурсов. Видно что код строился на мифах, целом клубке их.
И поэтому важно другое, лучше понимают что есть в коде и какова его логика и архитектура.
Или пишут на рекламируемом EF и даже банально не замечают десяток дедлоков в минуту.
И у БД другая палка в колесе, хранение реальных, ценных данных, т.е. миграция не многогранно не бесплатна. Код модуля поправил протестил и заменил. Делов то. Но с базой так не пойдёт, не говоря о параллельной совместимости.
И подходы в ней другие: структура данных строится под функционал, а не по наивной предметной области. И поэтому важно выявить статистические паттерны функционала, что бы не-было постоянных ненужных преобразований туда-обратно-вывернуть-развернуть.
И поэтому если нет функционала свободно обратиться к кодовой базе в виде запросов, т.е. представить кодовую базу в любое представление - то значить и оценка эффективности всего решения будет более субъективная.
Вам будет тяжело перечислить.
материалов очень большое разнообразие. Со всеми добавками и примесями. Волокнистые, могут кардинально влиять на процессы, в зависимости от размера и структуры "ворсинок". Которые могут меняться в зависимости от условий и времени. Всю гамму которых тяжело изучить, особенно на фоне экономических "оптимизаций", не способствующее развитию непредвзятых исследований.
Во взаимодействии участвуют два вещества (в простом случае). И не только набором свойств одной стороны (энергия разложения, ...) взаимодействия характеризуются. Вон интерференции белков, вещь только начинает исследоваться.
И не только быть катализатором, из-за особых диалектических свойств, стремятся покрывать поверхности, изменяя их потенциал и тем самым влияя на процессы, которые мы возможно не все изучили. И т.п. То что получился камень, говорит о пластичности.
Опять же, природа приспособиться, конечно, но как скоро? По сравнению с той скоростью эта природа наполняется по объему этими веществами. Это я повторяюсь.
Вы сами понимаете, что "хорошо изучены", или "недостаточно изучены" вещь чисто субъективная. Независимо от объема изучения научных статей каждым из нас. И не считая таких банальностей типа ТИМа (по Соционике).
И на счёт каучука. Наводя истерию типа "Пластик безвреден", без уточнения деталей. Не способствует здоровой атмосфере. В моем регионе часто используется переработанная вспененная резина на площадках (спортивных, детских), которая в других регионах планеты считается жутко канцерогенными. Даже если этот пост Ализара не стоит в принципе особого внимания. Хотя интересен в силу эрудиции - пластмассовые камни.
Можно мне поистерить? И немножко побредить.
Проблема не в том что это пластик. Проблема в том что структурно (философски) невозможно получить адекватный ответ выйдя за рамки: времени, объёма инфрмации.
И не в том что "мы все умрём", никто это не утверждает, а в допустимых пределах "ответа".
Тут некоторые бредят дожить до массовых полётов в космос, а не подождать следующего витка эволюции качественной жизни в "пластиковой" среде. Мы (этот вид) с вирусами/бактериями плохо справляемся. И пофег что бактерии/жизнь условно не убиваемы как принцип.
Если все плохо-активные вещества, поглотились и осели раком умершими динозаврами за лям лет, размазавшись в толще пород, то потомки (не наши), могут также шутить про поглощённый пластик таким же способом.
Проблема что параметры системы меняются всё быстрее чем мы можем найти/оценить причины и последствия. Когда количество перейдёт в качество?
Мои субъективные ощущения, что дело не в том что наши старики (за 70-80) умирают от рака (типа раньше такое не умели диагностировать), а то что умереть от рака в 50, станет обычной нормой.
Можно выходить на пластиковый пляж под палящим солнцем много лет подряд, и только через 10 лет начать жить с раком. Или в 50, когда какие-то ранее неизвестные процессы организма сдерживали последствия, и в силу естественного запрограммированного старения, показало результат. Который стал только через это десятилетие показывать 6 сигм статистической значимости.
И да, я предвзят.
Когда у близких проблемы. Когда группа людей (6 человек) имела относительной небольшой контакт (от 3х месяцев, до 2х лет) с парами каучука, и больше не пересекалась, и не имела иной "химической" истории. И только спустя время, а может и в силу возраста все "попали". И в никакую статистику по заболеваемости, их причин, они не попали. Кроме вот такого субъективного ощущения.
Говоришь про пропорциональность? А ты её можешь правильно оценить?
Думаешь купались в парах каучука?
И новость не об истерии пластика. А в том что модели по его распространению надо уточнять и больше усилий по исследованиям. Как и были изменены нормы по безопасности в работе с химическими веществами и/или изменению технологического процесса.
Спектр "активности" веществ и типов влияния всё более растягивает и заполняется, в силу энтропии. Твоя "пропорциональность" хорошо работает?