В реальности же тоже хорошо если программист решает именно поставленную задачу, или нет? Плохо если он сделал меньше (т.е. не выполнил ТЗ). И плохо если он сделал больше. Больше значит дольше, а дольше значит дороже.
Эту задачу люди взяли с литкода я так подумал. Пошел искать её там, и она действительно там есть. Пришёл к такому же решению как и вы, через разницу суммы всех элементов от арифм. прогрессии. Только вот в условиях задачи явно не обозначили (либо я невнимательный такой), но элемент может повторяться не один раз. Моё решение завалилось на кейсе [2,2,2,2,2].
У меня вот на текущей работе эта самая атмосфера. И знаете, когда все привыкли к подходу - "давайте сейчас напишем хрень, потому что быстро надо, а потом исправим (нет)", то и сам начинаешь по этому принципу работать. И даже оправдание себе находишь - "если всем похер, то почему мне должно быть дело?".
ООП про объекты, а не про классы. Т.е. про штуки которые могут делать некоторые дела по запросу, и сохранять целостным свое внутреннее состояние. Можно сказать, что в Go есть объекты.
А на 10 строчек 80 строк коментов. Что-то это противоречит утверждению о простоте языка. Ну так в целом с маленькими скриптами я согласен, проблем нет. Недавно пришлось отлаживать скрипт на 2000 строк, который впн ставит и конфигурирует. Плюнул - переписал в итоге.
Тоже посмеялся с этого пункта. Где-то в интернете есть поверие, что баш скрипты одноразовые. Потому что после написания, через пару дней легче написать новый скрипт, чем отладить существующий.
Потому что тестам тоже нужно доверять. Это не панацея. Вы уверены, что понимаете все кейсы которые вы покрыли? Вы уверены, что покрыли все кейсы? Была у меня ситуация. Нужно поменять некоторую логику в одном модуле. Тесты есть. Меняю. Тесты проходят. Через неделю оказывается, что в базе были хранимые процедуры (для тригеров) которые перестали работать как надо. В итоге модуль который я правил работал как надо, а данные которые обновлялись тригерами были некорректными, в следствии чего другой модуль перестал корректно работать. Да тут можно сколько угодно говорить про архитектуру и связанность кода, но факт есть факт - тесты были, но не помогли.
Я бы даже сказал не информации а воды. Для новичков не подходит, потому что можно захлебнуться, а бывалые и так все это знают (я надеюсь). Для матерых лучше почитайте "Python к вершинам мастерства".
Ситуации разные бывают. Я вот недавно работу менял. В списке требований было ну прям очень много чего написано. По итогу - на собесе про это не спросили, а в реальной работе - не используют. Тот же elasticsearch. Я спросил у лида потом, на кой х они это написали в требованиях, на что он честно признался - вакансия просто копипаста с другой вакансии.
Так в том и суть DRY, если у чего-то разные причины изменения, то нет нарушения DRY. Простое дублирование функционала нормально в моменте. Есть у вас две функции делают на текущий момент одинаковые вещи, это вовсе не значит, что вы нарушаете DRY, потому что завтра одна из функций может начать делать немного отличающиеся вещи, и это как бы уже не одна функция.Так что да - при чем тут DRY не понятно.
Вы говорите про инженеров, а не "работников". Если по системе математика --> программирование обучать сегодняшних программистов, то рабочих систем мы будем получать в час по чайной ложке. Ну и математика хорошо понимается уже после того как начал, что-то в программировании понимать. Я об "программистской математике", а не о "чистой". Это конечно мое ИМХО. Я например как человек, не получавший классического образования в ВУЗе, не проходившего эти дисциплины на парах, но интересующегося основами программирования проходил учебник Колмогорова по мат логике, было дело 7 лет назад, ну очень мало чего понял. Тогда я не сталкивался еще с SQL. После того как столкнулся с SQL, начал копать в сторону реляционной модели и тогда уже открыв еще раз учебник для меня показались такими родными эти множества, высказывания, предикаты и т.д.. Опять же моё ИМХО, мат. теорию и вообще информатику как науку лежащую в основе программирования как ремесла стоит изучать либо после практики самого программирования, либо параллельно, показывая, что вот табличка ваша в БД, это n-арный предикат и всё в таком духе.
Господи как же я раньше-то читал документацию с деепричастными оборотами, и тремя и более запятыми! Спасибо, что просвятили. Больше не буду такого делать.
Это не обзор софта, а статья о том как делают фильмы. Я как композер(да да, тот самый человек, который собирает сцены на финальном этапе) могу сказать, что ваш скульптрис, и софтимаж используется чуть реже чем никогда на больших проектах, да и на средних редко(это именно в кино, в других сферах не знаю как дела обстоят). Так что данные программы тут вполне справедливо забыты. Остальное — промышленный стандарт.
Вы тут как политик включили так называемые «безжалостные вычисления»? Можно ли спасти миллиард убив миллион? Охота на гомосекусалистов вполне конкретное явление, в начале этого года видел в вк группу по охоте на них. Примерно 20 видео, где они явно уже избитые, хоть и без явно выраженных телесный повреждений, извиняются что они такие какие есть. Это у них хватило мозгов выложить только такие видео. А представьте, что самые отбитые из этих охотников не выложили? Как вам такая перспектива. Есть даже на ютубе по мотивам Марценкевича и его оккупай [Роскомнадзор], видео где «люди» ловят гомосеков(так писать короче), на живца. А вы предлагаете дианон этих самых ЛГБТ, чтобы их еще проще было найти.
Так вот вы правда считаете, что сотни людей которые могут быть осуждены из-за откровенно глупых законов, сотни ЛГБТ пойманых и избитых, или еще хуже стоят 1 терракта, который не факт, что раскроют? Ну флаг вам руки и попутного ветра с такими рассуждениями.
Это не английский, это рунглиш. You понравится, if я буду вот так write?
А вообще напомнило анекдот:
В реальности же тоже хорошо если программист решает именно поставленную задачу, или нет? Плохо если он сделал меньше (т.е. не выполнил ТЗ). И плохо если он сделал больше. Больше значит дольше, а дольше значит дороже.
Эту задачу люди взяли с литкода я так подумал. Пошел искать её там, и она действительно там есть. Пришёл к такому же решению как и вы, через разницу суммы всех элементов от арифм. прогрессии. Только вот в условиях задачи явно не обозначили (либо я невнимательный такой), но элемент может повторяться не один раз. Моё решение завалилось на кейсе [2,2,2,2,2].
У меня вот на текущей работе эта самая атмосфера. И знаете, когда все привыкли к подходу - "давайте сейчас напишем хрень, потому что быстро надо, а потом исправим (нет)", то и сам начинаешь по этому принципу работать. И даже оправдание себе находишь - "если всем похер, то почему мне должно быть дело?".
ООП про объекты, а не про классы. Т.е. про штуки которые могут делать некоторые дела по запросу, и сохранять целостным свое внутреннее состояние. Можно сказать, что в Go есть объекты.
А на 10 строчек 80 строк коментов. Что-то это противоречит утверждению о простоте языка. Ну так в целом с маленькими скриптами я согласен, проблем нет. Недавно пришлось отлаживать скрипт на 2000 строк, который впн ставит и конфигурирует. Плюнул - переписал в итоге.
Тоже посмеялся с этого пункта. Где-то в интернете есть поверие, что баш скрипты одноразовые. Потому что после написания, через пару дней легче написать новый скрипт, чем отладить существующий.
Есть же куча тестовых баз, например от PostgresPRO, с полноценными схемами и кучей связей между таблицами.
Потому что тестам тоже нужно доверять. Это не панацея. Вы уверены, что понимаете все кейсы которые вы покрыли? Вы уверены, что покрыли все кейсы? Была у меня ситуация. Нужно поменять некоторую логику в одном модуле. Тесты есть. Меняю. Тесты проходят. Через неделю оказывается, что в базе были хранимые процедуры (для тригеров) которые перестали работать как надо. В итоге модуль который я правил работал как надо, а данные которые обновлялись тригерами были некорректными, в следствии чего другой модуль перестал корректно работать. Да тут можно сколько угодно говорить про архитектуру и связанность кода, но факт есть факт - тесты были, но не помогли.
Это пожалуй лучшее объяснение SOLID, что я когда либо слышал, не приведя даже не строчки кода. У вас прям талант объяснять.
Эта статья прекрасна просто во всех отношениях. Спасибо автор.
Я бы даже сказал не информации а воды. Для новичков не подходит, потому что можно захлебнуться, а бывалые и так все это знают (я надеюсь). Для матерых лучше почитайте "Python к вершинам мастерства".
Ситуации разные бывают. Я вот недавно работу менял. В списке требований было ну прям очень много чего написано. По итогу - на собесе про это не спросили, а в реальной работе - не используют. Тот же elasticsearch. Я спросил у лида потом, на кой х они это написали в требованиях, на что он честно признался - вакансия просто копипаста с другой вакансии.
Её не будет покуда у вас не установлен dns резолвер systemd'шный. Она собственно поставляется вместе с пакетом systemd-resolved
Hidden text
apt-file search resolvectl
fish-common: /usr/share/fish/completions/resolvectl.fish
manpages-de: /usr/share/man/de/man1/resolvectl.1.gz
systemd-resolved: /usr/bin/resolvectl
Так в том и суть DRY, если у чего-то разные причины изменения, то нет нарушения DRY. Простое дублирование функционала нормально в моменте. Есть у вас две функции делают на текущий момент одинаковые вещи, это вовсе не значит, что вы нарушаете DRY, потому что завтра одна из функций может начать делать немного отличающиеся вещи, и это как бы уже не одна функция.Так что да - при чем тут DRY не понятно.
Вы говорите про инженеров, а не "работников". Если по системе математика --> программирование обучать сегодняшних программистов, то рабочих систем мы будем получать в час по чайной ложке. Ну и математика хорошо понимается уже после того как начал, что-то в программировании понимать. Я об "программистской математике", а не о "чистой". Это конечно мое ИМХО. Я например как человек, не получавший классического образования в ВУЗе, не проходившего эти дисциплины на парах, но интересующегося основами программирования проходил учебник Колмогорова по мат логике, было дело 7 лет назад, ну очень мало чего понял. Тогда я не сталкивался еще с SQL. После того как столкнулся с SQL, начал копать в сторону реляционной модели и тогда уже открыв еще раз учебник для меня показались такими родными эти множества, высказывания, предикаты и т.д.. Опять же моё ИМХО, мат. теорию и вообще информатику как науку лежащую в основе программирования как ремесла стоит изучать либо после практики самого программирования, либо параллельно, показывая, что вот табличка ваша в БД, это n-арный предикат и всё в таком духе.
Так вот вы правда считаете, что сотни людей которые могут быть осуждены из-за откровенно глупых законов, сотни ЛГБТ пойманых и избитых, или еще хуже стоят 1 терракта, который не факт, что раскроют? Ну флаг вам руки и попутного ветра с такими рассуждениями.