Мне вот правда интересно, были ли в реальности случаи осуществления MITM по отношению к пакетной системе Питона? Я понимаю, что если даже ничего такого не было, это не значит, что ничего такого произойти не может. Но с таким же успехом вы можете изначально поставить подмененный пакет, рассчитать для него хэш) Такая защита выглядит странно. Для исключения подмены пакетов уже давно придумана pgp подпись)
Написать можно все, что угодно. Пока ПО закрыто и проприетарно, никто вам не сможет точно сказать, что разработчики не заложили в него алгоритмы обхода этих правил намерено всегда, либо в определенных условиях.
Мне правда жаль, что у вас всегда недостаточно времени для качественного выполнения своей работы. Это в большинстве случаев проблема менеджмента. Поменяйте работу, поверьте, есть компании, в которых и планирование адекватное, и при этом даже ЗП хорошую платят, ну и проекты уж точно не скучные. А пользователю действительно пофиг, как вы правильно заметили. Ему ж не придётся поддерживать говнокод. А вам придётся, ну или вашим коллегам.
У вас фигово процессы настроены. То, что вы не укладываетесь в сроки, в большинстве — результат плохого планирования. Мудрый менеджер возьмёт оценку программиста, умножит ее на 2 и ещё добавит половину, и даже такую оценку стоит брать во внимание с учётом других факторов, которые могут не зависеть от сроков выполнения задачи. А юнит тесты хороши, как вспомогательный инструмент, как гарантия,, что реализованный код работает правильно на данном этапе, ну и для устранения регрессий, но уж точно не как гарантия того, что ваш код и все остальное будет работать в продакшене в связке. Для этого есть ревью кода, процедура приемки со стороны QA, стейджинг и много всего ещё по желанию. А если у вас все это есть, но проекты продолжают падать в проде, значит у вас где-то что-то не отрабатывает как надо, поскольку до прода непротестированный проект при хорошо поставленных процессах просто не доедет) Даже с лютым говнокодом и без тестов можно жить, если есть правильно поставленная проверка QA на стейджинге) Не так конечно хорошо, как с тестами и не так быстро, потому что количество возвратов и багфиксов возрастает, но в целом можно. А вот наоборот — нет.
Вы невнимательно читали. Я не писал ничего про архитектуру), я также не писал, что идеальный нерабочий код лучше, чем рабочий говнокод. А писал я про баланс. Если ваш бизнес не выделяет достаточно времени, чтобы писать нормальный код, то это может быть отправдано в следующих случаях: 1. У руководства есть понимание, что мы сейчас пишем быстро говнокод и в дальнейшем, если мы планируем поддерживать этот код, мы его причешем, перепишем и так далее. 2. Вы не планируете поддерживать написанный код, например, пишете прототип. Во всех остальных случаях руководство скорее всего не понимает проблему наличия говнокода и руководствуется планами только на ближайшую перспективу. Это, кстати, довольно распространенный подход. Хотя конечно, еще возможно, что денег много, и ничего страшного, если поддержка и внедрение фичей будут занимать больше времени. Ну тут, как говорится, "кто платит, тот и музыку заказывает", you are the boss)
А представляете, как было бы замечательно, если бы код был понятнее и его поддержка занимала в 2 раза меньше времени, например. На самом деле, очень важно найти золотую середину: не писать лютый говнокод, но и не стараться добиться идеальной структуры кода, который даже не работает ещё. Все упирается естественно в ресурсы, в том числе времени, но важно помнить, что сэкономив время сейчас и набросав говнокод, его поддержка потом может съесть больше времени, чем вы выиграли на данном этапе. Так что важен баланс
Разница только в том, что вы сами даете согласие на обработку персональных данных, когда регистрируетесь в Фейсбуке, и, понимая это, вряд ли будете выкладывать в Фейсбуке секретную информацию. Насколько мне известно, устанавливая антивирус, максимум, что он от вас требует, это отказ от ответственности в случае непреднамеренной порчи данных. И потом, Фейсбук не залезет в ваш компьютер, ему доступно только то, что выложили вы лично и не более. Антивирус имеет доступ ко всей локальной файловой системе со всеми вытекающими.
Ну тут вариантов масса) Можно, например, купить личное авто, но тогда придется стоять в пробках, можно попробовать найти садик поближе к дому, чтобы либо не ездить вообще, либо страдать недолго. Можно нанять няню, чтобы она ездила в час пик. Можно договориться в детском саду, что привозить детей вы будете позже, п жена будет забирать, например. Я ж вашей ситуации не знаю и финансовых возможностей. У нас садик рядом с домом, поэтому для нас пока такая проблема не стоит
> Едет он поэтому не быстро.
Все бы ничего, если бы у этого транспорта не было расписания на остановках, на которые, я собственно и ориентировался. А в итоге чуть не опоздал и оказалось, что расписанию они не особо следуют (или просто в тот день что-то случилось особенное). Хотя даже сами немцы советовали мне пользоваться U-Ban/S-Ban вместо автобусов. Я думаю, что это неспроста)
Ну тогда могу вам только посочувствовать. Но это не проблема транспорта конкретно в России. Вы с той же самой проблемой можете столкнуться независимо от региона проживания. В некоторых странах на общественном транспорте вообще не рекомендуют ездить в силу специфики самой страны и контингента, который на этом транспорте обычно ездит. Так что тут все от вас зависит.
Турция — очень специфичный регион. Не путаем туризм и постоянное проживание. Все ж Турция на 98% — исламское государство. А там совсем другие правила нежели в буддизме. В общем, на любителя.
Ну, могу только вам посочувствовать. Если есть возможность, переезжайте туда, где больше вариантов добраться до метро (больше автобусов, маршруток и так далее). В противном случае, можно попробовать приобрести свой транспорт, но мне проще на общественном, чем в пробке стоять (на некоторых дорогах есть выделенка для автобусов и маршруток).
Ну, у меня автобус в Мюнхене опоздал на 15 минут и это при том, что на дорогах даже намека на пробки не было. А вот в России как-то даже с наземным транспортом (естественно, рассматривая Москву, за другие города не знаю) пунктуальнее, не первый раз замечаю. Это конечно не в час-пик и когда пробок нет. Вариант с пробками мы не рассматриваем.
А я в час пик не езжу и вам не советую) В час пик в любом мегаполисе вы страдать будете в любом транспорте. Вы же в IT работаете, а, насколько мне известно, в IT в России большинство компаний предлагают гибкий график. Вот и пользуйтесь этим)
А дом случайно не рядом с автомагистралью был? А иначе откуда там скажи взяться. Вообще, в любом городе дома и микрорайоны рядом с автомагистралями — и будет ровно такая же ситуация как у вас. Так что тут сравнивать так наверное не совсем корректно. Вот если бы вы сравнивали высоту сажи в МО и Бангкоке, например, чтобы оба дома были равноудалены от дороги с похожей загруженностью. Вот тогда да, сравнение было бы репрезентативным)
В Москве отличный общественный транспорт, в частности, метро. В отличие от других городов, Я тут недавно был в Мюнхене. Вот там автобусы ходят отвратительно, мне даже местные об этом сказали. А в Москве практически по расписанию. Так что это вы зря. Ну и в целом, если сравнивать Москву и регионы, Москва за счёт метро очень сильно выигрывает)
Ну это если есть свое жилье и вы живете один и не Москве. Тогда, да — красота)) Ну и потом люди ж едут не просто там жить, как в России, верно?) Кто-то за климатом, кто-то окунуться в среду, кто-то попутешествовать по Азии. А если это ещё и мечта такая была, то и никаких денег наверняка не жалко)
Я и не отрицаю. Нормально != Преждевременная оптимизация.
В статье все же речь про языки программирования, а не языки выполнения запросов, потому что в последних свои нюансы, которые отличаются. И речь скорее всего про оптимизиции без предварительного профилирования, которые в большинстве не приносят существенной пользы, зато тратят время и даже могут ухудшать читабельность кода.
В общем, посыл такой, что не нужно заморачиваться на производительности при написании кода на языке программирования (не запросов), если эффективность этого кода не определена эмпирически и не доказана целесообразность увеличения его производительности. Иначе — это, с большой вероятностью, пустая трата времени.
Мне вот правда интересно, были ли в реальности случаи осуществления MITM по отношению к пакетной системе Питона? Я понимаю, что если даже ничего такого не было, это не значит, что ничего такого произойти не может. Но с таким же успехом вы можете изначально поставить подмененный пакет, рассчитать для него хэш) Такая защита выглядит странно. Для исключения подмены пакетов уже давно придумана pgp подпись)
Есть такая крутая штука, называется pyenv. Там вам и любая версия питона и автоматическая активация окружения при входе в нужную папку. Советую )
Написать можно все, что угодно. Пока ПО закрыто и проприетарно, никто вам не сможет точно сказать, что разработчики не заложили в него алгоритмы обхода этих правил намерено всегда, либо в определенных условиях.
У вас фигово процессы настроены. То, что вы не укладываетесь в сроки, в большинстве — результат плохого планирования. Мудрый менеджер возьмёт оценку программиста, умножит ее на 2 и ещё добавит половину, и даже такую оценку стоит брать во внимание с учётом других факторов, которые могут не зависеть от сроков выполнения задачи. А юнит тесты хороши, как вспомогательный инструмент, как гарантия,, что реализованный код работает правильно на данном этапе, ну и для устранения регрессий, но уж точно не как гарантия того, что ваш код и все остальное будет работать в продакшене в связке. Для этого есть ревью кода, процедура приемки со стороны QA, стейджинг и много всего ещё по желанию. А если у вас все это есть, но проекты продолжают падать в проде, значит у вас где-то что-то не отрабатывает как надо, поскольку до прода непротестированный проект при хорошо поставленных процессах просто не доедет) Даже с лютым говнокодом и без тестов можно жить, если есть правильно поставленная проверка QA на стейджинге) Не так конечно хорошо, как с тестами и не так быстро, потому что количество возвратов и багфиксов возрастает, но в целом можно. А вот наоборот — нет.
Вы невнимательно читали. Я не писал ничего про архитектуру), я также не писал, что идеальный нерабочий код лучше, чем рабочий говнокод. А писал я про баланс. Если ваш бизнес не выделяет достаточно времени, чтобы писать нормальный код, то это может быть отправдано в следующих случаях: 1. У руководства есть понимание, что мы сейчас пишем быстро говнокод и в дальнейшем, если мы планируем поддерживать этот код, мы его причешем, перепишем и так далее. 2. Вы не планируете поддерживать написанный код, например, пишете прототип. Во всех остальных случаях руководство скорее всего не понимает проблему наличия говнокода и руководствуется планами только на ближайшую перспективу. Это, кстати, довольно распространенный подход. Хотя конечно, еще возможно, что денег много, и ничего страшного, если поддержка и внедрение фичей будут занимать больше времени. Ну тут, как говорится, "кто платит, тот и музыку заказывает", you are the boss)
А представляете, как было бы замечательно, если бы код был понятнее и его поддержка занимала в 2 раза меньше времени, например. На самом деле, очень важно найти золотую середину: не писать лютый говнокод, но и не стараться добиться идеальной структуры кода, который даже не работает ещё. Все упирается естественно в ресурсы, в том числе времени, но важно помнить, что сэкономив время сейчас и набросав говнокод, его поддержка потом может съесть больше времени, чем вы выиграли на данном этапе. Так что важен баланс
Ну а можно вообще переехать туда, где нет час пика) Если есть возможность конечно
Ну тут вариантов масса) Можно, например, купить личное авто, но тогда придется стоять в пробках, можно попробовать найти садик поближе к дому, чтобы либо не ездить вообще, либо страдать недолго. Можно нанять няню, чтобы она ездила в час пик. Можно договориться в детском саду, что привозить детей вы будете позже, п жена будет забирать, например. Я ж вашей ситуации не знаю и финансовых возможностей. У нас садик рядом с домом, поэтому для нас пока такая проблема не стоит
Все бы ничего, если бы у этого транспорта не было расписания на остановках, на которые, я собственно и ориентировался. А в итоге чуть не опоздал и оказалось, что расписанию они не особо следуют (или просто в тот день что-то случилось особенное). Хотя даже сами немцы советовали мне пользоваться U-Ban/S-Ban вместо автобусов. Я думаю, что это неспроста)
А дом случайно не рядом с автомагистралью был? А иначе откуда там скажи взяться. Вообще, в любом городе дома и микрорайоны рядом с автомагистралями — и будет ровно такая же ситуация как у вас. Так что тут сравнивать так наверное не совсем корректно. Вот если бы вы сравнивали высоту сажи в МО и Бангкоке, например, чтобы оба дома были равноудалены от дороги с похожей загруженностью. Вот тогда да, сравнение было бы репрезентативным)
В Москве отличный общественный транспорт, в частности, метро. В отличие от других городов, Я тут недавно был в Мюнхене. Вот там автобусы ходят отвратительно, мне даже местные об этом сказали. А в Москве практически по расписанию. Так что это вы зря. Ну и в целом, если сравнивать Москву и регионы, Москва за счёт метро очень сильно выигрывает)
В статье все же речь про языки программирования, а не языки выполнения запросов, потому что в последних свои нюансы, которые отличаются. И речь скорее всего про оптимизиции без предварительного профилирования, которые в большинстве не приносят существенной пользы, зато тратят время и даже могут ухудшать читабельность кода.
В общем, посыл такой, что не нужно заморачиваться на производительности при написании кода на языке программирования (не запросов), если эффективность этого кода не определена эмпирически и не доказана целесообразность увеличения его производительности. Иначе — это, с большой вероятностью, пустая трата времени.