VSCode IMHO подходит в качестве гуя для гита лучше.
1. Есть встроенный терминал, так что не надо переключать окна для того, чтобы управлять гитом (я не переношу GUI для pull, merge, rebase, очень долго выходит) 2. Удобно добавять/удалять файлики в stage 3. Удобно делать stash одного файла, если очень надо 4. На мой взгляд разрешать merge-конфликты в VSCode в 7000 раз приятнее Meld. Сам пользовался Meld года 3, но один раз увидев как оно сделано в VSCode - забросил Meld навсегда. Правда недавно (вроде в 1.70) завезли 3-way merge, но он откровенный кал. Слава богу в настройках отключается на "классику". 5. Есть удобный плагин Git Lens, который по нажатию Alt + B делает git blame. Оч удобно.
Занятно, что я не так уж и стар (29 мне), но тоже помню DOS на Intel 486 и как я там в Civilization 1 играл)) Застал уходящую эпоху. В глубинку технологии с задержкой приходили))
Если ты победил Каспарова, то да. А если проиграл - уже начинаются нюансы) Ведь в отличии от Шахмат, обычная жизнь не подчиняется чётким правилам и практически любой неуспех можно списать на обстоятельства, при вкачанной хитрожопости.
Какую голову, где вообще можно получить знания о том, что антенны сотовой связи могут быть опасны? В школе об этом не особо рассказывают. В ВУЗе эти знания можно получить, только обучаясь на соответствующих специальностях. В представлении большинства людей антенна - это безопасное устройство.
Я готов признать, что GUI очень удобен при настройки графики и всяких элементов системы, требующих визуального контроля (цвета, шрифты, размеры панелей и пр.).
С другой стороны, настройки сети, разделов, параметров мониторования ОС, конфигурация и запуск всяких демонов (SSH, docker, etc), обновление системы, установка/удаление приложений, создание/удаление пользователей, поиск по файлам и их содержимому, бекапы - в разы удобнее настраивать в консоли.
Из других очевидных плюсов - это всё можно автоматизировать. Совсем хорошая новость в том, что скрипты не зависят от DE, а значит не надо в каждой графической оболочке разбираться.
Руководствуюсь всегда простым правилом: если встретил зубодробительное - после того, как разобрался - оставляю огромный обстоятельный комментарий поясняющий буквально все взаимосвязи в этом костыле. Иногда в функции на 10 строчек, легко может быть комментарий строчек на 20.
Так вот собственно правило такое: если получается написать внятный и четкий комментарий, который точно не устареет завтра - вероятно это фатальный недостаток, вытекающий из сложности системы. Если комментарий писать тяжело, если взаимосвязи очень шаткие и любое дуновение ветра в другом месте системы разрушит этот мегазабористый код - это точно надо переписать)
Это ещё ничего. Работал я в одной компании. Пришёл туда молодым и горячим, ушел через пару лет на более хлебное место. Ещё через пару лет более хлебное место опостыло, и тут на старой работе появилась интересная вакансия. В общем, вернулся туда, но на новый проект.
Дело в том, что за полгода до первого увольнения я перешёл в другой проект. Там все делалось очень в спешке + первые два месяца я был единственным программистом в проекте. В общем, решил заглянуть через 2 года во что превратилась кодовая база, которую я растил с нуля :)
Моему удивлению не было предела. Во-первых, я увидел как архитектурные решения, которые я принимал, превратились в жутких монстров, тогда как два года назад они казались очень лаконичными :) Во-вторых, некоторые части кода были настолько плохи, что я понимал это еще при написании. Оставил огромные TODO, как это исправить. Но за 2 года никто и пальцем не пошевелил :) Так и висят там эпического масштаба костыли с моим именем на них :D
После этого я больше не удивляюсь откуда и почему в долгоживущих проектах появляются всякие нечистоты. Вся проблема почти всегда в двух вещах: отсутствие дисциплины и нехватка времени)
Это да, но кто-то же должен ей заниматься? :) Удивительный прикол жизни в том, что процессы реально меняющие что-то в этом мире - это огромный механизм, требующий очень много рутины для поддержания его работоспособности :) И главный вопрос в том, как сделать счастливыми именно тех, кто крутит педали в спортзале, а не тех, кто катается на мотоцикле по автобану)
Чёт не осилил это прочитать, но судя по табличкам формула простая: "чтобы было хорошо, надо работать в хороших компаниях" и "чтобы ваша компания была хорошей, надо делать хорошие проекты")
Зависит от того, какие гарантии ты обещал пользователям. В ядре Linux действительно пофигу какие цифры, т.к. никто обратной совместимости там не обещал никогда. В других продуктах это может быть вовсе не так.
Но таки определенные договоренности о гарантиях совместимости между версиями удобная вещь, когда нужно без глубокого и долгого анализа на глаз прикинуть "а взлетит моё ПО в этом окружении или нет, и сколько займет времени допиливание".
Я аж поперхнулся :) Я вроде не слишком старый, только приближаюсь к 30, но в принципе поперхнулся бы и в свои 23. Для меня загадка кому нужен GUI для конфигурирования. Это постоянно ж надо помнить и совершать тонны бессмысленных телодвижений.
Единственный вопрос в связи с новостью - почему в комментариях все называют компанию "Логитеч", когда она читаться должна как "Логитек" :)
Итак, мы только вживую пронаблюдали, как очередной функциональный язык сам себе создал проблему из ничего, и героически её преодолел :)
VSCode IMHO подходит в качестве гуя для гита лучше.
1. Есть встроенный терминал, так что не надо переключать окна для того, чтобы управлять гитом (я не переношу GUI для pull, merge, rebase, очень долго выходит)
2. Удобно добавять/удалять файлики в stage
3. Удобно делать stash одного файла, если очень надо
4. На мой взгляд разрешать merge-конфликты в VSCode в 7000 раз приятнее Meld. Сам пользовался Meld года 3, но один раз увидев как оно сделано в VSCode - забросил Meld навсегда. Правда недавно (вроде в 1.70) завезли 3-way merge, но он откровенный кал. Слава богу в настройках отключается на "классику".
5. Есть удобный плагин Git Lens, который по нажатию Alt + B делает git blame. Оч удобно.
Занятно, что я не так уж и стар (29 мне), но тоже помню DOS на Intel 486 и как я там в Civilization 1 играл)) Застал уходящую эпоху. В глубинку технологии с задержкой приходили))
*что ты НЕ делаешь :)
Если ты победил Каспарова, то да. А если проиграл - уже начинаются нюансы) Ведь в отличии от Шахмат, обычная жизнь не подчиняется чётким правилам и практически любой неуспех можно списать на обстоятельства, при вкачанной хитрожопости.
Логируем все операции с БД
Забираем у админа доступ к БД с логами
И вот уже надо напоить двух админов. Ещё лучше - можно сделать открытое API, которое будет реплицировать логи на всех, кому захочется.
В Ubuntu ставятся в пару кликов.
Гспди, куда катится мир)
Какую голову, где вообще можно получить знания о том, что антенны сотовой связи могут быть опасны? В школе об этом не особо рассказывают. В ВУЗе эти знания можно получить, только обучаясь на соответствующих специальностях. В представлении большинства людей антенна - это безопасное устройство.
Новизны вроде и не заявляется в заголовке. Просто башкирские учёные открыли для себя этот патент
Думаю где-то в голове)
Концептуально Gnome более чем приятен и удобен, но из-за кривизны реализации впечатление портится)
Я готов признать, что GUI очень удобен при настройки графики и всяких элементов системы, требующих визуального контроля (цвета, шрифты, размеры панелей и пр.).
С другой стороны, настройки сети, разделов, параметров мониторования ОС, конфигурация и запуск всяких демонов (SSH, docker, etc), обновление системы, установка/удаление приложений, создание/удаление пользователей, поиск по файлам и их содержимому, бекапы - в разы удобнее настраивать в консоли.
Из других очевидных плюсов - это всё можно автоматизировать. Совсем хорошая новость в том, что скрипты не зависят от DE, а значит не надо в каждой графической оболочке разбираться.
Руководствуюсь всегда простым правилом: если встретил зубодробительное - после того, как разобрался - оставляю огромный обстоятельный комментарий поясняющий буквально все взаимосвязи в этом костыле. Иногда в функции на 10 строчек, легко может быть комментарий строчек на 20.
Так вот собственно правило такое: если получается написать внятный и четкий комментарий, который точно не устареет завтра - вероятно это фатальный недостаток, вытекающий из сложности системы. Если комментарий писать тяжело, если взаимосвязи очень шаткие и любое дуновение ветра в другом месте системы разрушит этот мегазабористый код - это точно надо переписать)
Это ещё ничего. Работал я в одной компании. Пришёл туда молодым и горячим, ушел через пару лет на более хлебное место. Ещё через пару лет более хлебное место опостыло, и тут на старой работе появилась интересная вакансия. В общем, вернулся туда, но на новый проект.
Дело в том, что за полгода до первого увольнения я перешёл в другой проект. Там все делалось очень в спешке + первые два месяца я был единственным программистом в проекте. В общем, решил заглянуть через 2 года во что превратилась кодовая база, которую я растил с нуля :)
Моему удивлению не было предела. Во-первых, я увидел как архитектурные решения, которые я принимал, превратились в жутких монстров, тогда как два года назад они казались очень лаконичными :) Во-вторых, некоторые части кода были настолько плохи, что я понимал это еще при написании. Оставил огромные TODO, как это исправить. Но за 2 года никто и пальцем не пошевелил :) Так и висят там эпического масштаба костыли с моим именем на них :D
После этого я больше не удивляюсь откуда и почему в долгоживущих проектах появляются всякие нечистоты. Вся проблема почти всегда в двух вещах: отсутствие дисциплины и нехватка времени)
Это да, но кто-то же должен ей заниматься? :) Удивительный прикол жизни в том, что процессы реально меняющие что-то в этом мире - это огромный механизм, требующий очень много рутины для поддержания его работоспособности :) И главный вопрос в том, как сделать счастливыми именно тех, кто крутит педали в спортзале, а не тех, кто катается на мотоцикле по автобану)
Чёт не осилил это прочитать, но судя по табличкам формула простая: "чтобы было хорошо, надо работать в хороших компаниях" и "чтобы ваша компания была хорошей, надо делать хорошие проекты")
Зависит от того, какие гарантии ты обещал пользователям. В ядре Linux действительно пофигу какие цифры, т.к. никто обратной совместимости там не обещал никогда. В других продуктах это может быть вовсе не так.
Но таки определенные договоренности о гарантиях совместимости между версиями удобная вещь, когда нужно без глубокого и долгого анализа на глаз прикинуть "а взлетит моё ПО в этом окружении или нет, и сколько займет времени допиливание".
Я аж поперхнулся :) Я вроде не слишком старый, только приближаюсь к 30, но в принципе поперхнулся бы и в свои 23. Для меня загадка кому нужен GUI для конфигурирования. Это постоянно ж надо помнить и совершать тонны бессмысленных телодвижений.