Ну что же, попробую и я описать свое отношение по windows vs linux :-)
Windows, как линейка операционных систем, всегда выезжала за счет двух вещей — совместимость и юзабилити. Совместимость с любым железом, совместимость с софтом под предыдущие версии ОС. Идея же «всё можно сделать мышкой» очень нравится конечным пользователям, которые не хотят курить мануалы по командной строке.
Даже фиг с ней, с нестабильностью старых версий Windows — во времена до win7 взять и переустановить систему было типичным развлечением более-менее продвинутого пользователя. Главное, что отличало удачную версию ОС от неудачной версии ОС — это тормоза.
Теперь смотрим на десятку: активно использует диск без спроса и через это тупит, убирает графические настройки, перенося их в консольные утилиты. Не говоря уже про типичные болезни линукса — многочисленные баги и немалый шанс что-то сломать с очередным обновлением (от которого еще и отказаться нельзя)
Теперь Линукс:
Ко всему, что не имеет отношения к десктопу, претензий нет и быть не может. Что касается всего остального…
— 95% настроек — только через консоль и текстовые файлы. Уже спасибо убунте, что больше не требуется считать на калькуляторе частоту строковой развертки для смены разрешения экрана.
— драйвера на «несерверное» железо пишутся «на отвали» и по остаточному принципу. Или не пишутся вообще. Их установка может превратиться в увлекательный квест, по ходу которого можно многое узнать о работе PnP и модулей ядра. А если не повезет, то и о волшебном мире С.
— Банальнейшие, с точки зрения пользователя, вещи делаются специфичным для дистрибутива образом через консоль. К примеру, в убунте нельзя просто взять и создать ярлык. Или открыть файл конкретным исполняемым файлом.
— apt-get upgrade с хорошим шансом сделает из графической оболочки мессиво, не подлежащее восстановлению (убунта)
— установка обновлений тоже может что-нибудь испортить — от добавления небольших багов до (очередного) падения видео драйверов
И о плюсах:
— Линукс не делает ничего без ведома пользователя. Т.е. он работает *быстро* и всегда можно что-то ускорить, сознательно отказавшись от какой-нибудь функциональности.
— конфигурабельность — можно настроить всё, если хватит времени и желания разбираться
— инструменты разработчика — под ним удобнее программировать (за вычетом разнообразных косяков в GUI, которые в принципе можно решить — потратив время)
Помимо перечисленного другими людьми, в десятке меня убивает «честное» разделение ресурсов. Когда при копировании файлов тормозит GUI и заикается музыка — это ужасно. Первое впечатление, когда поставил убунту — система реагирует на клик СРАЗУ.
Да, мне понравилась идея проектирования алгоритмов в виде автомата. НО — такую схему непросто переложить в код без внутреннего состояния — это же противоречит самой идее автоматов.
Человеческий разум устроен так, что ему проще понимать алгоритмы, которым скармливают данные на входе и получают данные на выходе, и результат зависит только от входа, но не от внутреннего состояния. Такие «чистые функции» проще понимать, тестировать и использовать повторно. Также их легче использовать в многопоточном окружении, что актуально для современных многоядерных серверов.
Программа, спроектированная как автомат, будет, конечно же, наиболее эффективной по цпу и памяти, но и наиболее сложной для понимания, так что, имхо, это только техника оптимизации, но не общая техника программирования:
— код, который невозможно понимать и дорабатывать без документации (к тому же, графической документации!) — это слишком дорого для большинства применений
— модификация такого кода может привести к пересмотру хранимого состояния, т.е. придется держать в уме весь код, который этим состоянием пользуется
— состояние перед началом работы нужно инициализировать — этот код тоже «хрупкий» и потребует частых доработок при внесении изменений в логику. А ошибки в нем приведут к сложным багам.
Реализация графа состояний подозрительно напоминает генеренный код — быть может, её и правда можно генерировать по графу состояний? Правда, ни один графический язык пока не взлетел, ну кроме BPML.
Имхо, полезно только для машин без динамической аллокации памяти или для глубокой оптимизации, т.к. код на выходе без исходной диаграммы состояний ни читать, ни тем более править не получится.
При наличии ресурсов, значительно более понятное решение можно построить в два шага:
— преобразовать входную строку в структуру данных, описывающую, что и куда рисовать
— передать эту структуру данных в рендер, который занимается отрисовкой
Система тикетов очень полезна обоим сторонам. Админ, с одной стороны, не сможет «забыть» или забить на потребности сотрудников, и, с другой стороны, сможет использовать тикеты как обоснование для закупок железа.
Чугунный кирпич на складе — это вообще убытки, а не прибыль. Пока он не продан, не получится заплатить зарплату, отдать кредит, реинвестировать в производство…
Про печенки не согласен — наличие печенек в компании — большой плюс. Опция не слишком дорогая для работодателя и тем самым ярко показывает его отношение к работникам.
Опытный разработчик может забыть определение интерфейса и абстрактного класса, тем более, что эти понятия в современных языках достаточно размыты.
Но он точно не может забыть, когда он использует интерфейсы, а когда — абстрактные классы. От джуна стоить ждать определения, от сеньора — устное эссе на 200 слов по теме.
Видите, в какой хорошей стране мы живем — в РФ наемного работника без материальной ответственности не могут оштрафовать на сумму, превышающую его месячный оклад.
Джун, конечно же, не виновен. Джун *в принципе* не может быть в виновен в одиночных косяках. Виновен ответственный за невозможность случайного нанесения вреда продакшну. Или тот, кто этого ответственного не назначил.
Я очень люблю табы, т.к. они значительно упрощают навигацию по коду «стрелочками». Но — современная мода требует использования пробелов, во всех гайдах пишут про пробелы, git diff рисует табы ярким красным цветом, многие редакторы работают в пробельном режиме…
Так что мне пришлось перейти на пробелы, чтобы не отстать от жизни. С понижением зарплаты.
Я бы сказал, что в контексте данной статьи, правильнее будет сказать, что тяжелая работа = вредная работа.
Если человек растрачивает своё здоровье во время работы — то это тяжелая работа
Если человек посвящает работе время в ущерб личной жизни, спорту и сну — то это, несомненно, тоже тяжелая работа.
Многие недостатки п.3 исчезают, если вместо flyway использовать собственную утилиту для накатывания базы.
Что можно сделать лучше:
— вместо нумерации changeset-ов просто вести файлик со списком .sql файлов — тогда если разработчики обзовут файлы одинаково или занесут свои изменения одновременно, то будет конфликт.
— в том же файле указывать, как исполнять эти файлы — однократно (сохраняя в базу хеш файла и предупреждая, если он изменился), каждый раз или только при изменении
— дорабатывать под свои нужды — к примеру, придумать синтаксис для заливания BLOB-ов в базу из локальных файлов
— Если хочется видеть историю изменений потаблично без применения grep — никто не мешает новые ALTER-ы раскладывать по папкам с именами таблиц. Или даже использовать синтаксис, аналогичный п.4
— Этот подход также позволяет другую, крайне важную фичу — удобную интеграцию скриптов отката изменений.
Windows, как линейка операционных систем, всегда выезжала за счет двух вещей — совместимость и юзабилити. Совместимость с любым железом, совместимость с софтом под предыдущие версии ОС. Идея же «всё можно сделать мышкой» очень нравится конечным пользователям, которые не хотят курить мануалы по командной строке.
Даже фиг с ней, с нестабильностью старых версий Windows — во времена до win7 взять и переустановить систему было типичным развлечением более-менее продвинутого пользователя. Главное, что отличало удачную версию ОС от неудачной версии ОС — это тормоза.
Теперь смотрим на десятку: активно использует диск без спроса и через это тупит, убирает графические настройки, перенося их в консольные утилиты. Не говоря уже про типичные болезни линукса — многочисленные баги и немалый шанс что-то сломать с очередным обновлением (от которого еще и отказаться нельзя)
Теперь Линукс:
Ко всему, что не имеет отношения к десктопу, претензий нет и быть не может. Что касается всего остального…
— 95% настроек — только через консоль и текстовые файлы. Уже спасибо убунте, что больше не требуется считать на калькуляторе частоту строковой развертки для смены разрешения экрана.
— драйвера на «несерверное» железо пишутся «на отвали» и по остаточному принципу. Или не пишутся вообще. Их установка может превратиться в увлекательный квест, по ходу которого можно многое узнать о работе PnP и модулей ядра. А если не повезет, то и о волшебном мире С.
— Банальнейшие, с точки зрения пользователя, вещи делаются специфичным для дистрибутива образом через консоль. К примеру, в убунте нельзя просто взять и создать ярлык. Или открыть файл конкретным исполняемым файлом.
— apt-get upgrade с хорошим шансом сделает из графической оболочки мессиво, не подлежащее восстановлению (убунта)
— установка обновлений тоже может что-нибудь испортить — от добавления небольших багов до (очередного) падения видео драйверов
И о плюсах:
— Линукс не делает ничего без ведома пользователя. Т.е. он работает *быстро* и всегда можно что-то ускорить, сознательно отказавшись от какой-нибудь функциональности.
— конфигурабельность — можно настроить всё, если хватит времени и желания разбираться
— инструменты разработчика — под ним удобнее программировать (за вычетом разнообразных косяков в GUI, которые в принципе можно решить — потратив время)
Core i7, 32G RAM.
Человеческий разум устроен так, что ему проще понимать алгоритмы, которым скармливают данные на входе и получают данные на выходе, и результат зависит только от входа, но не от внутреннего состояния. Такие «чистые функции» проще понимать, тестировать и использовать повторно. Также их легче использовать в многопоточном окружении, что актуально для современных многоядерных серверов.
Программа, спроектированная как автомат, будет, конечно же, наиболее эффективной по цпу и памяти, но и наиболее сложной для понимания, так что, имхо, это только техника оптимизации, но не общая техника программирования:
— код, который невозможно понимать и дорабатывать без документации (к тому же, графической документации!) — это слишком дорого для большинства применений
— модификация такого кода может привести к пересмотру хранимого состояния, т.е. придется держать в уме весь код, который этим состоянием пользуется
— состояние перед началом работы нужно инициализировать — этот код тоже «хрупкий» и потребует частых доработок при внесении изменений в логику. А ошибки в нем приведут к сложным багам.
Реализация графа состояний подозрительно напоминает генеренный код — быть может, её и правда можно генерировать по графу состояний? Правда, ни один графический язык пока не взлетел, ну кроме BPML.
При наличии ресурсов, значительно более понятное решение можно построить в два шага:
— преобразовать входную строку в структуру данных, описывающую, что и куда рисовать
— передать эту структуру данных в рендер, который занимается отрисовкой
У меня убунта, обновился:
Версия значительно старше, но дата сборки — вчерашняя. Уязвима она или нет?
Но он точно не может забыть, когда он использует интерфейсы, а когда — абстрактные классы. От джуна стоить ждать определения, от сеньора — устное эссе на 200 слов по теме.
> не будет получен ответ от кеша изображений, кеша предварительной загрузки, кеша сервис-воркера и HTTP-кеша
Кто-нибудь может просветить насчет всех этих кешей? Я был твердо уверен, что кеш в браузере один.
Джун, конечно же, не виновен. Джун *в принципе* не может быть в виновен в одиночных косяках. Виновен ответственный за невозможность случайного нанесения вреда продакшну. Или тот, кто этого ответственного не назначил.
Так что мне пришлось перейти на пробелы, чтобы не отстать от жизни. С понижением зарплаты.
Если человек растрачивает своё здоровье во время работы — то это тяжелая работа
Если человек посвящает работе время в ущерб личной жизни, спорту и сну — то это, несомненно, тоже тяжелая работа.
Что можно сделать лучше:
— вместо нумерации changeset-ов просто вести файлик со списком .sql файлов — тогда если разработчики обзовут файлы одинаково или занесут свои изменения одновременно, то будет конфликт.
— в том же файле указывать, как исполнять эти файлы — однократно (сохраняя в базу хеш файла и предупреждая, если он изменился), каждый раз или только при изменении
— дорабатывать под свои нужды — к примеру, придумать синтаксис для заливания BLOB-ов в базу из локальных файлов
— Если хочется видеть историю изменений потаблично без применения grep — никто не мешает новые ALTER-ы раскладывать по папкам с именами таблиц. Или даже использовать синтаксис, аналогичный п.4
— Этот подход также позволяет другую, крайне важную фичу — удобную интеграцию скриптов отката изменений.