AIMP под Wine работает, но помехи в звуке слышал. Сейчас переставил, но все равно не особо зашел Wine. Как-нить попробую Office по Wine, но боюсь за комбинации клавиш - с Ubuntu переучился переключать русский через CapsLock
Есть темы, которые стоит вспомнить: 1) RAW типа негатива в пленочной съемке, где химически можно получить оригинальный отпечаток. Все камеры предназначены выдавать готовый JPEG пользователю. С заведомо большими характеристиками, чем ему надо в жизни. Куча людей потрудилась, чтобы камера выдавала правильный результат - рынок высококонкурентный! 2) Есть серьезный аргумент типа что процессор на десктопе сильно производительнее чем в камере. И можно использовать большее количество алгоритмов для обработки. Но по факту это нужно меньше 1% пользователей. В бизнесовом спортивном репортаже, например, важно отправить побыстрее один снимок из тысячи - редактор прямо на фотокамере + вафля. Важно, что камера делает "стандартный jpeg" из RAW, отрезая какие-то диапазоны оттенков. А они нужны вообще? У меня был опыт сравнить около 10 тыс RAW и JPEG - как я в лайтруме с RAW не пыжился, получилось близко к jpeg из камеры, а возни и тяжелых файлов дофигища. Я к тому, что RAW мутная тема, о которой все знают, но мало кто будет пользоваться в реале.
ИМХО, эрудиция начинается с детской любознательности. В детстве единственным источником знаний была библиотека, и много времени провел просто листая энциклопедии. Есть некоторые перегибы: зачем-то знаю металлургию, металло- и деревообработку, кубометр инструментов дома и 10+ лет риелторства. Но как остановиться - кто бы сказал?! 2-3 месяца назад прочитал интересную мысль, которая созвучна. Если семени дать землю, воду и солнце, то семя не может не прорасти и вырастет в огромное дерево. И вот тоже про людей.
С декабря тусуюсь в Ubuntu - полет нормальный. Бесила верхняя строка, начал накатывать приблуды, заблудился так, что переставлял систему. Сейчас поставил "Panel-to-Dash" - починил строку десктопа, живу спокойно. Far2l типа FarManager, но не оно. В основном mc. Не хватает нормального плеера - AIMP обещают в следующем году. Еще бы кто-то Faststone Image Viewer бы пообещал - и всё. Ну и для мелочей типа Office/Photoshop есть VirtualBox
...Что будет с начинающими разработчиками, я не представляю. А мы ведь хотим просто внедрить зависимости.
Имею неудачный опыт uber/fx на новом для меня проекте. Скажу, что вместо того, чтобы пронумеровать модули и последовательно изучать, в такой темной магии приходится знать ВСЁ-И-СРАЗУ. Что невозможно и превращается в НИ-ЧЕ-ГО. Я читал отдельные функции, но пока стало выстаиваться в какую-то картину закончился испытательный срок. Аргументация типа "раньше было еще хуже". Но для меня uber/fx теперь синоним того, что бэкенд решил не напрягаться с архитектурой проекта.
Пардонюсь, какие-то слова относились к тому проекту, который видел. Обобщу - какую-то структуру делают все. Как говорится "любой план лучше никакого". А названия модулей и разделение по слоям - где остановиться?! - холиварная тема. Точно антипаттерн - писать универсальные слои абстракции. Это примерно как дженерики в гошке - они решают тему копипасты, но точно не бизнеса. И то же самое, но в позитивной формулировке - хороший код хорошо описывает бизнес... оппа вижу тут интересную тему, что я пишу про бизнес-код (наверно, потому что про сущности), а интерфейсные вещи типа http-сервера пусть будут абстрактными. То есть мой тезис - бизнес-код должен быть максимально конкретным, чем точнее тем лучше описывает бизнес.
Сейчас расстаюсь командой, которая пишет проект по похожей структуре модулей. Вы еще забыли написать, что дофига чего (транзакции) передается через контекст. Доступ в таком бардаке невозможно определить - потому чужеродный rbac в виде мидлвари сервера, а изнутри нет сведений об авторизации. Как вишенка - каждый файл это структура с методами - и все зависимости через uber-fx... Читать это - такое себе! Сначала ждет истерика - я хотел вопить в голос и бить мебель или забиться в угол и плакать. 1. Важно, что такая структура делается, когда неинтересно изучать бизнес. А имхо, программисты описывают бизнес в коде, и если не изучают, то на выходе - говно. 2. Ужасная организация CRUD, потому что типа REST. На моем проекте нагенерировали говнокрудов, где на входе куча лишних данных - и они тупо передаются в базу. Когда в реале один пользователь может только одно поле, другой два других поля - и это красиво сделать через два разных запроса, чем жуть через REST. 3. "Обработка ошибка бизнес-логики в обработчике" - холиварная тема. У меня перед глазами пример, когда люди не поняли где запрос, а где бизнес - и от слоя контроллеров осталось одно название. Я совсем недавно познал дзен и теперь для меня wr-обработчик является бизнес-логикой. Охренеть, как красиво в результате получается. 4. Менять бд - а сколько раз видели такое? Логика очень сильно привязана к хранилищу. И даже в моем проекте ребята как ни пыжились, то все равно у них отдельно постргя и отдельно эластик - и абстракция жирно поверх - грим на язвы! 5. Из-за того, что лень изучать бизнес, то куча неявных вызовов и зависимостей. Названо это "модульная архитектура, можем удалять целыми модулями - и красота!". В реале никто модули удалять не будет - удалишь один и теперь поддерживать ДВА продукта! 6. И почему-то не используется изоляция через internal. Да, через интерфейсы есть изоляция. Но это показывает то, что разраб не знает что ему нужно от модуля. 7. Тестить это не реально. Юзаются http-тесты и всё!
Напечатать - удобно для работы. А в жизни важно невербальное общение. Даже телефонный разговор кроме слов добавляет громкость, тембр, паузы и ошибки речи. В личке еще и мимика и жесты. И тактильные ощущения. То есть человек задействует больше сенсорных систем - и мозги закипают от впечатлений.
Это и есть проект - цель, время и ресурсы. Слово универсальное, в разных сферах обрастает специализацией. В "обычной" компании для проектов выделяются линейные спецы на неполную занятость - матрица проектного управления. В словах автора я больше вижу заботу о птенчиках и чтобы они "встали на крыло". Это совсем не бизнес-задача, но и организация - это больше чем бизнес. Замечу, что становление специалиста - это не только "материнская любовь", но и преодоление конфликтов внутри себя и снаружи. Потому окружающая среда должна быть конкурентной и травматичной. Хотя бы просто потому, что не дети, а уже взрослые.
В большой компании это рутинный процесс. Но в рамках отдела и начальника это разовый проект. Если вернуться к теме статьи - крупные игроки формируют рынок труда. Из-за удаленки и повсеместного ажиотажа с микросервисами у компаний проблемы. Но это отражение мировых проблем. Когда-нибудь будет благодатная почва для вашей инициативы, но пока нет, потому что организации далеки от созревания.
В этих словах как раз проблема описана: средний уровень не должен добывать ресурсы для проекта. Или! только это прямая задача отдела - добывать ресурсы. Но очевидно, что в должностных обязанностях отсутствует. Современный наём специалистов - это проект! куда временно прикрепляются специалисты разного уровня и функционала. Но это краткосрочный проект. Изменение системы образование - долгосрочный проект вне рамок обязанностей среднего уровня. И больше про компании, которые осознали свою системообразующую роль в отрасли.
Рентабельность - это про прибыль. Прибыль - явление продаж. Эффективность - это сравнение цели с ожиданиями. А была ли цель?! Статья - это манифест к изменению IT-компаний - их целей в первую очередь. Все вокруг "за всё хорошее и против всего плохого", но бессмысленно ожидать, что кто-то всерьез поменяет цели компании. Вроде на днях был какая-то новость, что обяжут крупные IT-компании заказывать спецов в вузах - но это государственный уровень управления, у них свои задачи. Здесь больше про средний уровень управления - у них вообще может не быть цели образования. Такая опция больше про "жырные" компании, где компания выступает спонсором и заодно "управление репутацией" - но вообще не про взросление спецов.
В психологии занимаются только тем, кто лично обращается. Так и про эту статью. Максим - ГГ, его и обсуждаем. А так - вообще бизнес виноват и платит за всё!
Включает, конечно. А выводов много. Если психологию поднять, то почему вы категорично ограничиваетесь только одним утверждением? Даже, во "врать надо меньше" можно перевернуть любое слово и получить варианты "правда / можно / много". Конкретно выше автор не осуждает, и называет "травматичным" опыт. У всех он есть. Я одобряю, что нужно описывать негативный опыт - есть счастливчики, которые слушают не только вредные советы.
Это первый уровень сложности ;) У меня вот три зонта, но мне нравится в мембранке под дождем гулять. А кто-то выберет голышом... Есть трюк с итерациями "зачем?" и красок в жизни становится сильно больше чем две.
AIMP под Wine работает, но помехи в звуке слышал. Сейчас переставил, но все равно не особо зашел Wine.
Как-нить попробую Office по Wine, но боюсь за комбинации клавиш - с Ubuntu переучился переключать русский через CapsLock
Есть темы, которые стоит вспомнить:
1) RAW типа негатива в пленочной съемке, где химически можно получить оригинальный отпечаток. Все камеры предназначены выдавать готовый JPEG пользователю. С заведомо большими характеристиками, чем ему надо в жизни. Куча людей потрудилась, чтобы камера выдавала правильный результат - рынок высококонкурентный!
2) Есть серьезный аргумент типа что процессор на десктопе сильно производительнее чем в камере. И можно использовать большее количество алгоритмов для обработки. Но по факту это нужно меньше 1% пользователей. В бизнесовом спортивном репортаже, например, важно отправить побыстрее один снимок из тысячи - редактор прямо на фотокамере + вафля.
Важно, что камера делает "стандартный jpeg" из RAW, отрезая какие-то диапазоны оттенков. А они нужны вообще? У меня был опыт сравнить около 10 тыс RAW и JPEG - как я в лайтруме с RAW не пыжился, получилось близко к jpeg из камеры, а возни и тяжелых файлов дофигища.
Я к тому, что RAW мутная тема, о которой все знают, но мало кто будет пользоваться в реале.
ИМХО, эрудиция начинается с детской любознательности. В детстве единственным источником знаний была библиотека, и много времени провел просто листая энциклопедии. Есть некоторые перегибы: зачем-то знаю металлургию, металло- и деревообработку, кубометр инструментов дома и 10+ лет риелторства. Но как остановиться - кто бы сказал?!
2-3 месяца назад прочитал интересную мысль, которая созвучна. Если семени дать землю, воду и солнце, то семя не может не прорасти и вырастет в огромное дерево. И вот тоже про людей.
С декабря тусуюсь в Ubuntu - полет нормальный. Бесила верхняя строка, начал накатывать приблуды, заблудился так, что переставлял систему. Сейчас поставил "Panel-to-Dash" - починил строку десктопа, живу спокойно.
Far2l типа FarManager, но не оно. В основном mc. Не хватает нормального плеера - AIMP обещают в следующем году. Еще бы кто-то Faststone Image Viewer бы пообещал - и всё. Ну и для мелочей типа Office/Photoshop есть VirtualBox
Имею неудачный опыт uber/fx на новом для меня проекте. Скажу, что вместо того, чтобы пронумеровать модули и последовательно изучать, в такой темной магии приходится знать ВСЁ-И-СРАЗУ. Что невозможно и превращается в НИ-ЧЕ-ГО. Я читал отдельные функции, но пока стало выстаиваться в какую-то картину закончился испытательный срок.
Аргументация типа "раньше было еще хуже". Но для меня uber/fx теперь синоним того, что бэкенд решил не напрягаться с архитектурой проекта.
Пардонюсь, какие-то слова относились к тому проекту, который видел.
Обобщу - какую-то структуру делают все. Как говорится "любой план лучше никакого". А названия модулей и разделение по слоям - где остановиться?! - холиварная тема.
Точно антипаттерн - писать универсальные слои абстракции. Это примерно как дженерики в гошке - они решают тему копипасты, но точно не бизнеса.
И то же самое, но в позитивной формулировке - хороший код хорошо описывает бизнес... оппа вижу тут интересную тему, что я пишу про бизнес-код (наверно, потому что про сущности), а интерфейсные вещи типа http-сервера пусть будут абстрактными. То есть мой тезис - бизнес-код должен быть максимально конкретным, чем точнее тем лучше описывает бизнес.
Сейчас расстаюсь командой, которая пишет проект по похожей структуре модулей. Вы еще забыли написать, что дофига чего (транзакции) передается через контекст. Доступ в таком бардаке невозможно определить - потому чужеродный rbac в виде мидлвари сервера, а изнутри нет сведений об авторизации. Как вишенка - каждый файл это структура с методами - и все зависимости через uber-fx... Читать это - такое себе! Сначала ждет истерика - я хотел вопить в голос и бить мебель или забиться в угол и плакать.
1. Важно, что такая структура делается, когда неинтересно изучать бизнес. А имхо, программисты описывают бизнес в коде, и если не изучают, то на выходе - говно.
2. Ужасная организация CRUD, потому что типа REST. На моем проекте нагенерировали говнокрудов, где на входе куча лишних данных - и они тупо передаются в базу. Когда в реале один пользователь может только одно поле, другой два других поля - и это красиво сделать через два разных запроса, чем жуть через REST.
3. "Обработка ошибка бизнес-логики в обработчике" - холиварная тема. У меня перед глазами пример, когда люди не поняли где запрос, а где бизнес - и от слоя контроллеров осталось одно название. Я совсем недавно познал дзен и теперь для меня wr-обработчик является бизнес-логикой. Охренеть, как красиво в результате получается.
4. Менять бд - а сколько раз видели такое? Логика очень сильно привязана к хранилищу. И даже в моем проекте ребята как ни пыжились, то все равно у них отдельно постргя и отдельно эластик - и абстракция жирно поверх - грим на язвы!
5. Из-за того, что лень изучать бизнес, то куча неявных вызовов и зависимостей. Названо это "модульная архитектура, можем удалять целыми модулями - и красота!". В реале никто модули удалять не будет - удалишь один и теперь поддерживать ДВА продукта!
6. И почему-то не используется изоляция через internal. Да, через интерфейсы есть изоляция. Но это показывает то, что разраб не знает что ему нужно от модуля.
7. Тестить это не реально. Юзаются http-тесты и всё!
Я бы добавил: делай как умеешь сейчас. Через несколько месяцев всё равно полностью перепишешь.
Я такой ;) Но чего-то особого спроса не наблюдаю. И так как сильно меньше матерюсь, когда в окне вижу го, то позиционируюсь дальше на него.
Добрый день. Ссылка битая, поправьте.
Напечатать - удобно для работы. А в жизни важно невербальное общение. Даже телефонный разговор кроме слов добавляет громкость, тембр, паузы и ошибки речи. В личке еще и мимика и жесты. И тактильные ощущения. То есть человек задействует больше сенсорных систем - и мозги закипают от впечатлений.
shot, beer нет? Походу я на другой волне и изюма юмора не понял
Алкоголь с незнакомыми людьми? Это ж как скучно должно быть?!
Это и есть проект - цель, время и ресурсы. Слово универсальное, в разных сферах обрастает специализацией. В "обычной" компании для проектов выделяются линейные спецы на неполную занятость - матрица проектного управления.
В словах автора я больше вижу заботу о птенчиках и чтобы они "встали на крыло". Это совсем не бизнес-задача, но и организация - это больше чем бизнес.
Замечу, что становление специалиста - это не только "материнская любовь", но и преодоление конфликтов внутри себя и снаружи. Потому окружающая среда должна быть конкурентной и травматичной. Хотя бы просто потому, что не дети, а уже взрослые.
В большой компании это рутинный процесс. Но в рамках отдела и начальника это разовый проект.
Если вернуться к теме статьи - крупные игроки формируют рынок труда. Из-за удаленки и повсеместного ажиотажа с микросервисами у компаний проблемы. Но это отражение мировых проблем. Когда-нибудь будет благодатная почва для вашей инициативы, но пока нет, потому что организации далеки от созревания.
В этих словах как раз проблема описана: средний уровень не должен добывать ресурсы для проекта. Или! только это прямая задача отдела - добывать ресурсы. Но очевидно, что в должностных обязанностях отсутствует.
Современный наём специалистов - это проект! куда временно прикрепляются специалисты разного уровня и функционала. Но это краткосрочный проект.
Изменение системы образование - долгосрочный проект вне рамок обязанностей среднего уровня. И больше про компании, которые осознали свою системообразующую роль в отрасли.
Рентабельность - это про прибыль. Прибыль - явление продаж. Эффективность - это сравнение цели с ожиданиями. А была ли цель?!
Статья - это манифест к изменению IT-компаний - их целей в первую очередь. Все вокруг "за всё хорошее и против всего плохого", но бессмысленно ожидать, что кто-то всерьез поменяет цели компании. Вроде на днях был какая-то новость, что обяжут крупные IT-компании заказывать спецов в вузах - но это государственный уровень управления, у них свои задачи.
Здесь больше про средний уровень управления - у них вообще может не быть цели образования. Такая опция больше про "жырные" компании, где компания выступает спонсором и заодно "управление репутацией" - но вообще не про взросление спецов.
В психологии занимаются только тем, кто лично обращается.
Так и про эту статью. Максим - ГГ, его и обсуждаем.
А так - вообще бизнес виноват и платит за всё!
Включает, конечно. А выводов много. Если психологию поднять, то почему вы категорично ограничиваетесь только одним утверждением? Даже, во "врать надо меньше" можно перевернуть любое слово и получить варианты "правда / можно / много".
Конкретно выше автор не осуждает, и называет "травматичным" опыт. У всех он есть. Я одобряю, что нужно описывать негативный опыт - есть счастливчики, которые слушают не только вредные советы.
Это первый уровень сложности ;) У меня вот три зонта, но мне нравится в мембранке под дождем гулять. А кто-то выберет голышом...
Есть трюк с итерациями "зачем?" и красок в жизни становится сильно больше чем две.