У нас из-за специфики продукта с подобным подходом есть одна проблема. Билд занимает 3-4 часа, smoke тесты ещё примерно час. Если в течение дня сделать хотя бы 4-5 коммитов, то всё это растянется очень надолго. Какие есть общепринятые практики или советы на этот случай? Пока из идей только запускать сборки не по коммитам, а настроить регулярные билды по расписанию (раз в день или в неделю, например, неважно).
Простите за, возможно, глупый вопрос, но не может ли получиться так, что низкие задержки сейчас просто из-за сильно меньшей популярности и, как следствие, нагрузки на сервис?
Если это приподнести как пример того, как делать не стоит, то конечно, нет проблем :) Просто нужно чтобы это явно было сказано с самого начала, чтобы понимание формировалось у студентов) Чтобы люди четко и ясно понимали, что так делать нельзя в общем случае) Поверьте, это может быть далеко не очевидно для многих)
Нет. Это совсем другое. В сортировке пузырьком нет ничего плохого, это нормальный код, это основы алгоритмизации. А это именно хак, причем вы сами даже затрудняетесь придумать пример, где такое может понадобиться.
Пожалуйста, только не давайте таких задач студентам с их неокрепшей психикой и несформировавшимся понятиями о том, что допустимо в промышленной разработке, а что нет. Опытным разработчикам, которые понимают границы применимости, — пожалуйста, но не студентам. Иначе подобный код всплывёт потом на работе просто потому что "а почему бы нет, работает же, стильно-модно-молодёжно" и будет очень больно.
Дерево — это такая структура данных, в которой каждый узел имеет как минимум два дочерних элемента.
Вы это серьёзно? Каждый узел, минимум два дочерних элемента? Оно бесконечное что-ли? А что тогда будет листом в таком дереве? Если речь идёт о дереве в общем, то там могут быть узлы и с одним дочерним элементом (вы даже дальше приводите пример вырожденного дерева). Если же о двоичном дереве (учитывая заголовок параграфа, из которого взята цитата), то там будет максимум два дочерних элемента.
Однозначно, очень вредная шпаргалка. Дальше читать не стал, простите.
а потом даже опровержения неверной информации нет. Журналист задачу выполнил — заходы/продажи поднял, а даже соответствие действительности никого не волнует.
Опровержение обязательно будет, если оно кому-то выгодно и выполнит ту же задачу, а именно привлечёт интерес и поднимет заходы/продажи :)
А в целом, вы правы, конечно. Печально, что по факту нет никакой ответственности за враньё в СМИ или публичных заявлениях.
Даже когда программное обеспечение приводит к катастрофам, мы видим заголовки день-два и потом ничего. Радио тишина.
По моим наблюдениям, это справедливо практически для любых катастроф, а не только вызванных программным обеспечением. Уж не знаю, к счастью или к сожалению, но люди по своей природе не хотят зацикливаться на негативных новостях, и подсознательно пытаются абстрагироваться от них, если события не связаны с ними или их близкими.
А что за мифический язык "C/C++" такой? Это C или C++? Или что-то другое? Прошу прощения, наверное глупый вопрос, но слишком давно мучает, много где встречается подобная формулировка. Не придираюсь, и не стеб, правда интересно, что вкладывают люди в этот термин.
Это ведь разные вещи, нисколько друг друга не отменяющие. Советоваться в таких вопросах нужно ещё до написания кода, code review — слишком поздно, так как ресурсы уже потрачены на разработку и тестирование) На этапе дизайна исправить ошибки, очевидно, на порядок дешевле.
Это неправда!
На шлюз отправляются пакеты не если в сети не найден этот адрес, а в случае если адрес не входит в подсеть интерфейса!
Если уж придираться, то и это тоже не совсем правда. У каждого устройства есть таблица маршрутизации, которая представляет собой набор правил вида "пакеты в такую-то сеть отправлять через такой-то gateway". Gateway может быть как IP-адресом, так и интерфейсом. Помимо маршрутов, добавляемых автоматически при конфигурировании интерфейса (настроили на интерфейсе адрес 10.0.0.2/14 — получили маршрут в сеть 10.0.0.0/14 через этот интерфейс), могут быть и другие маршруты: статические или динамические. То, что вы описали как шлюз, — это так называемый "default gateway", тоже маршрут: под который просто попадают те пакеты, для которых не нашлось своего маршрута.
Извиняйте за занудство, просто чтобы уж не вводить людей в дальнейшее заблуждение)
Возможно, это rm из недоверенного места, который автор и захотел проверить с помощью maybe, прежде чем запускать?) Теперь он увидел, что этот rm удалит совсем не то, что он просит, значит его запускать не надо, это вирус)
Не проверялся общий объём и макисмальный размер загружаемого файла.
Хоть этот параметр явно не учитывался, добавлю, что flickr даёт сразу бесплатно целый терабайт после регистрации. Так что если вдруг кто-то будет искать сервис в том числе для длительного хранилища множества фотографий, а не только для разового использования, как в статье, то этот факт может стать неплохим дополнительным плюсом.
Соглашусь. Более того, далеко не всегда (конечно, из моего личного опыта, не претендую на истину в последних инстанциях) есть возможность в принципе какой-то GUI запустить на Linux машине, где нужен gdb :) Чаще всего это какие-то сервера или встраиваемые системы, на которых консоль и только консоль, ибо большего не требуется) Иногда даже там сам gdb не помещался, только gdb-сервер, и приходилось отлаживать удаленно с другой машины.
У нас из-за специфики продукта с подобным подходом есть одна проблема. Билд занимает 3-4 часа, smoke тесты ещё примерно час. Если в течение дня сделать хотя бы 4-5 коммитов, то всё это растянется очень надолго. Какие есть общепринятые практики или советы на этот случай? Пока из идей только запускать сборки не по коммитам, а настроить регулярные билды по расписанию (раз в день или в неделю, например, неважно).
Простите за, возможно, глупый вопрос, но не может ли получиться так, что низкие задержки сейчас просто из-за сильно меньшей популярности и, как следствие, нагрузки на сервис?
Если это приподнести как пример того, как делать не стоит, то конечно, нет проблем :) Просто нужно чтобы это явно было сказано с самого начала, чтобы понимание формировалось у студентов) Чтобы люди четко и ясно понимали, что так делать нельзя в общем случае) Поверьте, это может быть далеко не очевидно для многих)
Нет. Это совсем другое. В сортировке пузырьком нет ничего плохого, это нормальный код, это основы алгоритмизации. А это именно хак, причем вы сами даже затрудняетесь придумать пример, где такое может понадобиться.
Пожалуйста, только не давайте таких задач студентам с их неокрепшей психикой и несформировавшимся понятиями о том, что допустимо в промышленной разработке, а что нет. Опытным разработчикам, которые понимают границы применимости, — пожалуйста, но не студентам. Иначе подобный код всплывёт потом на работе просто потому что "а почему бы нет, работает же, стильно-модно-молодёжно" и будет очень больно.
Вы это серьёзно? Каждый узел, минимум два дочерних элемента? Оно бесконечное что-ли? А что тогда будет листом в таком дереве? Если речь идёт о дереве в общем, то там могут быть узлы и с одним дочерним элементом (вы даже дальше приводите пример вырожденного дерева). Если же о двоичном дереве (учитывая заголовок параграфа, из которого взята цитата), то там будет максимум два дочерних элемента.
Однозначно, очень вредная шпаргалка. Дальше читать не стал, простите.
Опровержение обязательно будет, если оно кому-то выгодно и выполнит ту же задачу, а именно привлечёт интерес и поднимет заходы/продажи :)
А в целом, вы правы, конечно. Печально, что по факту нет никакой ответственности за враньё в СМИ или публичных заявлениях.
По моим наблюдениям, это справедливо практически для любых катастроф, а не только вызванных программным обеспечением. Уж не знаю, к счастью или к сожалению, но люди по своей природе не хотят зацикливаться на негативных новостях, и подсознательно пытаются абстрагироваться от них, если события не связаны с ними или их близкими.
А что за мифический язык "C/C++" такой? Это C или C++? Или что-то другое? Прошу прощения, наверное глупый вопрос, но слишком давно мучает, много где встречается подобная формулировка. Не придираюсь, и не стеб, правда интересно, что вкладывают люди в этот термин.
Ну тогда уж вот ещё: https://youtu.be/1S1fISh-pag
Это ведь разные вещи, нисколько друг друга не отменяющие. Советоваться в таких вопросах нужно ещё до написания кода, code review — слишком поздно, так как ресурсы уже потрачены на разработку и тестирование) На этапе дизайна исправить ошибки, очевидно, на порядок дешевле.
Если уж придираться, то и это тоже не совсем правда. У каждого устройства есть таблица маршрутизации, которая представляет собой набор правил вида "пакеты в такую-то сеть отправлять через такой-то gateway". Gateway может быть как IP-адресом, так и интерфейсом. Помимо маршрутов, добавляемых автоматически при конфигурировании интерфейса (настроили на интерфейсе адрес 10.0.0.2/14 — получили маршрут в сеть 10.0.0.0/14 через этот интерфейс), могут быть и другие маршруты: статические или динамические. То, что вы описали как шлюз, — это так называемый "default gateway", тоже маршрут: под который просто попадают те пакеты, для которых не нашлось своего маршрута.
Извиняйте за занудство, просто чтобы уж не вводить людей в дальнейшее заблуждение)
А если у вас паранойя, это ещё не значит, что за вами не следят!..
Возможно, это rm из недоверенного места, который автор и захотел проверить с помощью maybe, прежде чем запускать?) Теперь он увидел, что этот rm удалит совсем не то, что он просит, значит его запускать не надо, это вирус)
Большое спасибо за интересную статью! Было бы ещё очень здорово в таком же духе, но про x86_64.
… и bg (background), чтобы продолжить выполнение в фоне.
Как насчёт того, чтобы попробовать сравнить еще и Intel Distribution for Python?
Соглашусь. Более того, далеко не всегда (конечно, из моего личного опыта, не претендую на истину в последних инстанциях) есть возможность в принципе какой-то GUI запустить на Linux машине, где нужен gdb :) Чаще всего это какие-то сервера или встраиваемые системы, на которых консоль и только консоль, ибо большего не требуется) Иногда даже там сам gdb не помещался, только gdb-сервер, и приходилось отлаживать удаленно с другой машины.