Если ты победил Каспарова, то да. А если проиграл - уже начинаются нюансы) Ведь в отличии от Шахмат, обычная жизнь не подчиняется чётким правилам и практически любой неуспех можно списать на обстоятельства, при вкачанной хитрожопости.
Какую голову, где вообще можно получить знания о том, что антенны сотовой связи могут быть опасны? В школе об этом не особо рассказывают. В ВУЗе эти знания можно получить, только обучаясь на соответствующих специальностях. В представлении большинства людей антенна - это безопасное устройство.
Я готов признать, что GUI очень удобен при настройки графики и всяких элементов системы, требующих визуального контроля (цвета, шрифты, размеры панелей и пр.).
С другой стороны, настройки сети, разделов, параметров мониторования ОС, конфигурация и запуск всяких демонов (SSH, docker, etc), обновление системы, установка/удаление приложений, создание/удаление пользователей, поиск по файлам и их содержимому, бекапы - в разы удобнее настраивать в консоли.
Из других очевидных плюсов - это всё можно автоматизировать. Совсем хорошая новость в том, что скрипты не зависят от DE, а значит не надо в каждой графической оболочке разбираться.
Руководствуюсь всегда простым правилом: если встретил зубодробительное - после того, как разобрался - оставляю огромный обстоятельный комментарий поясняющий буквально все взаимосвязи в этом костыле. Иногда в функции на 10 строчек, легко может быть комментарий строчек на 20.
Так вот собственно правило такое: если получается написать внятный и четкий комментарий, который точно не устареет завтра - вероятно это фатальный недостаток, вытекающий из сложности системы. Если комментарий писать тяжело, если взаимосвязи очень шаткие и любое дуновение ветра в другом месте системы разрушит этот мегазабористый код - это точно надо переписать)
Это ещё ничего. Работал я в одной компании. Пришёл туда молодым и горячим, ушел через пару лет на более хлебное место. Ещё через пару лет более хлебное место опостыло, и тут на старой работе появилась интересная вакансия. В общем, вернулся туда, но на новый проект.
Дело в том, что за полгода до первого увольнения я перешёл в другой проект. Там все делалось очень в спешке + первые два месяца я был единственным программистом в проекте. В общем, решил заглянуть через 2 года во что превратилась кодовая база, которую я растил с нуля :)
Моему удивлению не было предела. Во-первых, я увидел как архитектурные решения, которые я принимал, превратились в жутких монстров, тогда как два года назад они казались очень лаконичными :) Во-вторых, некоторые части кода были настолько плохи, что я понимал это еще при написании. Оставил огромные TODO, как это исправить. Но за 2 года никто и пальцем не пошевелил :) Так и висят там эпического масштаба костыли с моим именем на них :D
После этого я больше не удивляюсь откуда и почему в долгоживущих проектах появляются всякие нечистоты. Вся проблема почти всегда в двух вещах: отсутствие дисциплины и нехватка времени)
Это да, но кто-то же должен ей заниматься? :) Удивительный прикол жизни в том, что процессы реально меняющие что-то в этом мире - это огромный механизм, требующий очень много рутины для поддержания его работоспособности :) И главный вопрос в том, как сделать счастливыми именно тех, кто крутит педали в спортзале, а не тех, кто катается на мотоцикле по автобану)
Чёт не осилил это прочитать, но судя по табличкам формула простая: "чтобы было хорошо, надо работать в хороших компаниях" и "чтобы ваша компания была хорошей, надо делать хорошие проекты")
Зависит от того, какие гарантии ты обещал пользователям. В ядре Linux действительно пофигу какие цифры, т.к. никто обратной совместимости там не обещал никогда. В других продуктах это может быть вовсе не так.
Но таки определенные договоренности о гарантиях совместимости между версиями удобная вещь, когда нужно без глубокого и долгого анализа на глаз прикинуть "а взлетит моё ПО в этом окружении или нет, и сколько займет времени допиливание".
Я аж поперхнулся :) Я вроде не слишком старый, только приближаюсь к 30, но в принципе поперхнулся бы и в свои 23. Для меня загадка кому нужен GUI для конфигурирования. Это постоянно ж надо помнить и совершать тонны бессмысленных телодвижений.
Чтобы эта функция принимала на вход аргупент option? Не, в целом подход с lift функцией прикольный, но обработка ошибок в lift отсутствует полностью, так что для промышленной рвзработки такой код неприемлем.
Если ты победил Каспарова, то да. А если проиграл - уже начинаются нюансы) Ведь в отличии от Шахмат, обычная жизнь не подчиняется чётким правилам и практически любой неуспех можно списать на обстоятельства, при вкачанной хитрожопости.
Логируем все операции с БД
Забираем у админа доступ к БД с логами
И вот уже надо напоить двух админов. Ещё лучше - можно сделать открытое API, которое будет реплицировать логи на всех, кому захочется.
В Ubuntu ставятся в пару кликов.
Гспди, куда катится мир)
Какую голову, где вообще можно получить знания о том, что антенны сотовой связи могут быть опасны? В школе об этом не особо рассказывают. В ВУЗе эти знания можно получить, только обучаясь на соответствующих специальностях. В представлении большинства людей антенна - это безопасное устройство.
Новизны вроде и не заявляется в заголовке. Просто башкирские учёные открыли для себя этот патент
Думаю где-то в голове)
Концептуально Gnome более чем приятен и удобен, но из-за кривизны реализации впечатление портится)
Я готов признать, что GUI очень удобен при настройки графики и всяких элементов системы, требующих визуального контроля (цвета, шрифты, размеры панелей и пр.).
С другой стороны, настройки сети, разделов, параметров мониторования ОС, конфигурация и запуск всяких демонов (SSH, docker, etc), обновление системы, установка/удаление приложений, создание/удаление пользователей, поиск по файлам и их содержимому, бекапы - в разы удобнее настраивать в консоли.
Из других очевидных плюсов - это всё можно автоматизировать. Совсем хорошая новость в том, что скрипты не зависят от DE, а значит не надо в каждой графической оболочке разбираться.
Руководствуюсь всегда простым правилом: если встретил зубодробительное - после того, как разобрался - оставляю огромный обстоятельный комментарий поясняющий буквально все взаимосвязи в этом костыле. Иногда в функции на 10 строчек, легко может быть комментарий строчек на 20.
Так вот собственно правило такое: если получается написать внятный и четкий комментарий, который точно не устареет завтра - вероятно это фатальный недостаток, вытекающий из сложности системы. Если комментарий писать тяжело, если взаимосвязи очень шаткие и любое дуновение ветра в другом месте системы разрушит этот мегазабористый код - это точно надо переписать)
Это ещё ничего. Работал я в одной компании. Пришёл туда молодым и горячим, ушел через пару лет на более хлебное место. Ещё через пару лет более хлебное место опостыло, и тут на старой работе появилась интересная вакансия. В общем, вернулся туда, но на новый проект.
Дело в том, что за полгода до первого увольнения я перешёл в другой проект. Там все делалось очень в спешке + первые два месяца я был единственным программистом в проекте. В общем, решил заглянуть через 2 года во что превратилась кодовая база, которую я растил с нуля :)
Моему удивлению не было предела. Во-первых, я увидел как архитектурные решения, которые я принимал, превратились в жутких монстров, тогда как два года назад они казались очень лаконичными :) Во-вторых, некоторые части кода были настолько плохи, что я понимал это еще при написании. Оставил огромные TODO, как это исправить. Но за 2 года никто и пальцем не пошевелил :) Так и висят там эпического масштаба костыли с моим именем на них :D
После этого я больше не удивляюсь откуда и почему в долгоживущих проектах появляются всякие нечистоты. Вся проблема почти всегда в двух вещах: отсутствие дисциплины и нехватка времени)
Это да, но кто-то же должен ей заниматься? :) Удивительный прикол жизни в том, что процессы реально меняющие что-то в этом мире - это огромный механизм, требующий очень много рутины для поддержания его работоспособности :) И главный вопрос в том, как сделать счастливыми именно тех, кто крутит педали в спортзале, а не тех, кто катается на мотоцикле по автобану)
Чёт не осилил это прочитать, но судя по табличкам формула простая: "чтобы было хорошо, надо работать в хороших компаниях" и "чтобы ваша компания была хорошей, надо делать хорошие проекты")
Зависит от того, какие гарантии ты обещал пользователям. В ядре Linux действительно пофигу какие цифры, т.к. никто обратной совместимости там не обещал никогда. В других продуктах это может быть вовсе не так.
Но таки определенные договоренности о гарантиях совместимости между версиями удобная вещь, когда нужно без глубокого и долгого анализа на глаз прикинуть "а взлетит моё ПО в этом окружении или нет, и сколько займет времени допиливание".
Я аж поперхнулся :) Я вроде не слишком старый, только приближаюсь к 30, но в принципе поперхнулся бы и в свои 23. Для меня загадка кому нужен GUI для конфигурирования. Это постоянно ж надо помнить и совершать тонны бессмысленных телодвижений.
Если надо, перед передачей упаковать в Option
Не занимаемся. Чем этот действительно занимается - так это заметанием ошибок под ковёр.
Вот положим у меня цепочка вычислений из, ну скажем, 15 преобразований. Вернулся None. Надо понять почему. Как?
Чтобы эта функция принимала на вход аргупент option? Не, в целом подход с lift функцией прикольный, но обработка ошибок в lift отсутствует полностью, так что для промышленной рвзработки такой код неприемлем.
Что ж, в функции getSecondArg что-то пошло не так. Надо это залогировать и послать сообщение юзверю. Как?
Чем это лучше, чем просто текст в стиле: "на такой-то строке, в таком-то тэге, у вас неправильный атрибут"?
Зачем печатать что-то непонятное (дерево тэгов), если можно просто напечатать сам HTML. Он вполне себе читаемый.
Это я в курсе, но покажите мне код (с монадамм) после этого) Потому что это будет нечто невразумительное