Когда мы говорим “джаваскрипт”, мы подразумеваем много разных вещей:
Когда мы говорим “джаваскрипт”, мы подразумеваем TypeScript. Никакой разработки на чистом JS, в современном мире вестись не должно. (Если вы, конечно, не извращенец).
Короче, из коробки JS годится лишь для написания очень маленьких вещей
Никакой разработки на чистом JS, в современном мире вестись не должно. (Если вы, конечно, не извращенец).
Фронтенд это боль
Я так и не увидел технологии на которой фронтенд делать проще и дешевле. Qt и GTK непредлагать.
из джаваскрипта ничего нельзя удалить
А из Go что-то удаляли?
TypeScript не помог
Еще как помог, а Bun помог еще больше.
Далее, TypeScript не дает никаких гарантий. Вообще.
Я всегда думал, что мы большую часть времени решаем, что конкретно нужно сделать для ожидаемого результата и куда этот код засунуть в имеющейся кодовой базе.
Надо делать на веб-стеке. PWA/TWA и меньше играться с нативом. Почти за бесплатно получается веб-версия которую можно оперативно тестировать и которая плюс-минус будет одинаково работать на всех девайсах.
Конечно же VUE наше все.
А если приложению уж очень надо нативные API, их можно сделать в обёртке и мокнуть в Web-версии. Но опять-таки Web-api настолько мощное, что на нём можно делать драйвера (WebHid, WebUsb).
Проблема с поиском работы есть не только у 40+, но и у 30+, и у 20+. Процессы найма у большей части компании неадекватные. Но также отметить, что большой опыт у 40+, не означает, что он весь релевантен вакансии и здесь стоит корректировать зарплатные ожидания. А так да, проблема все та же, нанимают не за трудовые качества, а за навыки проходить собеседования.
Не стоит выбрасывать старые книги – лучше подарить им вторую жизнь, адаптируя и дополняя под современные реалии. Когда я читал классический «Clean Code» в 2018 году, уже тогда многие примеры написанные на Java, решались бы средствами языка C# образца 2018 года, а многие проблемы решаются линтером. Я предлагаю составить детальный список правил линтера с пояснениями, почему каждое правило введено. Те моменты, которые невозможно формализовать через линтер – стоит описать отдельно.
Пересмотреть так же стоит ООП. Сейчас многие используют data-объекты, а в C# добавили record для удобной работы с ними. И это все не смотря на то, что data-объекты противоречат идеалогии ООП.
Также полезно привязывать паттерны к конкретным языкам программирования и фреймворкам, а в вопросах архитектуры систем – формулировать основные принципы и сопоставлять их с реальными технологиями, например, сравнивая Kafka с RabbitMQ или DynamoDB с CosmosDB. Еще важна поддержка проверенных шаблонов проектов.
Когда знания разрозненны и черпаются из множества источников, становится сложно донести информацию до каждого. Именно поэтому так актуальны отраслевые стандарты и поддерживаемые сообществом источники опыта. Это позволит отправить сотрудника почитать конкретную книгу или статью, и вести с ним разговор на одном языке, опираясь на единые понятия.
Большая часть известных книг по архитектуре и паттернам устарела. Их нужно переработать и переосмыслить в текущих реалиях и с современными языками и фреймворками. И я не отрицаю то, что там написано, я лишь указываю на неактуальность части сведений. Тот же принцип High Cohesion очень важен и про него мало кто знает. Но вот тот же Creator, существует только потому, что когда-то ООП не допускало создавать DTO. В современном мире почти никто не наследует классы, а только интерфейсы и во всю практикуются принципы функционального программирования.
Так же проблема в том, что не существует хорошей терминологии для общения бизнес-аналитиков с программистами-архитекторами. У нас нет строгих отраслевых стандартов по ведению документации проекта, каждый придумывает что-то с переменным успехом. Нам не хватает списка плохих и устаревших технологий. Нам не хватает шаблонов для типовых задач. Все придумывают свои велосипеды и героически превозмогают трудности, вместо того, что бы делиться своим опытом с другими. Потому что мы до сих пор ссылаемся на книги 20-летней давности.
Я в 15м поставил себе Linux Mint, это как убунту, только больше похожая на Windows, и более отполирована. Мой старый принтер HP, плохо работает на Windows 7, 10 и даже 11. Мне приходилось по 5 раз переустанавливать драйвер и перезагружать комп, что бы принтер начал работать, и даже после этого уходит около 20 секунд, что бы передать одну страницу на печать (видимо драйвер по какой-то причине снижает скорость канала). На Linux Mint, без каких либо действий, он печатает одну за одной. Хотя раньше на Windows XP таких проблем не было. То же самое со старым МФУ от HP. Более того, есть варианты с другими Desktop Environment, который визуально проще, но потребляют меньше ресурсов. Поэтому всегда можно подобрать образ под очень старое железо. По умолчанию ставим Cinnamon, если лагает, то пробуем Xfce. Если и Xfce лагает, тогда можно попробовать Gentoo, но это уже совсем другая история.
Мне не нравится, что cursor это форк vscode, а не расширение для обычного vscode. Разработчики cursor говорили, что они упёрлись в ограничения extension api.
Вот, видимо Microsoft таким образом стимулирует cursor комитить в upstream, чтобы cursor всё-таки стал расширением. Майкам потом будет проще новые фичи для Copilot пилить.
Образование должно трансформироваться в сторону расширения кругозора, что бы можно было понимать и анализировать, то что выдает ИИ. Для этого нужно иметь хотя бы базовые знания предметной области. Так же нужно уметь работать с источниками. Так же нужно составлять справочники с проверенными знаниями в духе международной классификации болезней по которым можно будет проверять факты которые выдал ИИ.
Linux Mint более стабильна чем Ubuntu. Она основана на LTS версии Ubuntu. У меня ОС за несколько лет ни разу не слетала после обновлений софта или даже минорной версии ОС.
Linux Mint Cinnamon - это самый лучший выбор. Ключевая её особенность в том, что интерфейс очень похож на Винду, при этом это все та же популярная Ubuntu под которую адаптирована львиная доля linux-софта, и для которой описано как делать в консоли ту или иную операцию. Плюс есть менеджер программ, менеджер драйверов, менеджер обновлений, которые дадут возможность не пользоваться консолью.
Статья абсолютно бесполезная: из нее нельзя сделать каких-то выводов или переиспользовать опыт автора.
Во-первых, какая методология подсчёта экранного времени? На каких устройствах осуществлялся этот подсчет, как разделалась активность по работе и по безделью?
Во-вторых непонятно, что там автор делал перед сном. Автор начал читать книгу, а делал ли он это ранее на телефоне, или он смотрел цепляющие внимание тиктоки? Может быть было достаточно сменить потребляемый контент?
В текущем виде статья выглядит как: я что-то сделал, стал чувствовать себе лучше, вы тоже можете попробовать посоревноваться с друзьями.
Это просто неадекватный рейтинг с непонятной методологией, которому нельзя доверять. Мне не понятен двойной рост популярности питона за год, низкой базой это не объяснить. Такое кажется невероятным.
Скорее всего изменилась методология подсчёта, либо источники данных (поисковики) начали выдавать свои результаты по-другому.
Так вам и не нужно гуглить, вы же уже знаете название опенсорс модели уровня GPT4. Вот и назовите её, а я попробую её запустить и убедиться, что она действительно работает на таком уровне.
Какую модель такого уровня я могу скачать и где? Как её запустить? Могу ли я например подключить к этой модели какой-нибудь анализатор кода, который ей будет направлять вопросы и получать ответы в определенном формате.
То что кто-то где-то добился каких успехов в AI это здорово, но сейчас в отрасли проблема в том, что я не могу адаптировать эти результаты к своим задачам за разумное время.
Такая проблема есть не только в AI, но и в алгоритмах, хотя те же GPT могут адаптировать алгоритм под мою задачу, но не всегда хорошо, а если бы была хорошая библиотека обобщенных алгоритмов для того же JS, то было бы проще.
С этого момента код будет опрятным и шелковистым. Вы просто не сможете сделать коммит, если у анализатора есть вопросики к коду.
Нет, нет и нет. Это очень плохой подход и на опыте неоднократно в этом убеждался.
Во-первых, вы можете застейджить не весь код. Скрипт отработает, но потом если другой разработчик переключиться на вашу ветку будет иметь дело со сломанным комитом.
Во-вторых, есть тулы которые прячут незастейдженые изменения, делают проверку и возвращают все как было. И вроде как проблема решена, но иногда, если линтер может зависнуть или захочется его вырубить, может оказаться что спрятанные изменения не вернулись обратно.
В-третьих, бывает какому-то из разработчиков нужно быстро уйти (домой или обед) и передать наработки хоть в каком-то виде. И тут линты падают, а разобраться некогда, хорошо что я знаю, что если удалить папку hooks из папки .git, то вся эта ерунда работать не будет.
В-четвёртых, у разработчиков есть возможность обходить эти хуки, а так же может быть ситуация, когда в ветке А все работает, в ветке Б все работает, а если их смержить то Линт будет падать. Самый простой пример в обе ветки был добавлен import / using в разные места, это не приводит к мерж конфликту, но зато к падению линта.
В общем от хуков очень много геморроя и решают они проблему на 50%. Как же решить это проблему на 100%?
Ответ: CI.
В проекте делаем разделение на публичные ветки (main, dev, dev-new-big-feature) и приватные (i.popov/task-342-add-super-button).
В публичные ветки запрещается пуш и форс-пуш. В публичные ветки разрешается мерж ПР, только если проходят все проверки линтов на результате мержа, а не на последнем коммите из ПР, то есть предварительно смержили и запустили линт). Если пушится коммит в одну из веток (source или destination), то проверка запускается заново.
Приватные ветки никто не трогает кроме автора, они используются только как хостинг результатов работы, в них разрешаются форс пушы и прочее баловство. Для тех кто скажет, мол не пуш пока не приведешь все в порядок, я отвечу, что у меня был такой проект где я не пушил пару дней и именно в эти 6 месяцев произошел отказ жёсткого диска с потерей изменений. Мерж из приватной в публичную ветку происходит по squash -стратегии то есть все промежуточные коммиты сливаются воедино, что бы не захламлять историю. Что очень сильно помогает когда делаешь git bisect.
Go уже доступен нативно в ОС без компиляции и линковки?
Когда мы говорим “джаваскрипт”, мы подразумеваем TypeScript. Никакой разработки на чистом JS, в современном мире вестись не должно. (Если вы, конечно, не извращенец).
Никакой разработки на чистом JS, в современном мире вестись не должно. (Если вы, конечно, не извращенец).
Я так и не увидел технологии на которой фронтенд делать проще и дешевле. Qt и GTK непредлагать.
А из Go что-то удаляли?
Еще как помог, а Bun помог еще больше.
https://github.com/GoogleFeud/ts-runtime-checks
Если вы не писали на Nemerle, советую попробовать, вы удивитесь, насколько жизнь может быть приятнее.
Библиотеку и фреймворк сравнивают, потому что они взаимоисключающие. Вы берете что-то одно и строите на этом проект, а дальше возникают нюансы.
Я всегда думал, что мы большую часть времени решаем, что конкретно нужно сделать для ожидаемого результата и куда этот код засунуть в имеющейся кодовой базе.
Надо делать на веб-стеке. PWA/TWA и меньше играться с нативом. Почти за бесплатно получается веб-версия которую можно оперативно тестировать и которая плюс-минус будет одинаково работать на всех девайсах.
Конечно же VUE наше все.
А если приложению уж очень надо нативные API, их можно сделать в обёртке и мокнуть в Web-версии. Но опять-таки Web-api настолько мощное, что на нём можно делать драйвера (WebHid, WebUsb).
Проблема с поиском работы есть не только у 40+, но и у 30+, и у 20+. Процессы найма у большей части компании неадекватные. Но также отметить, что большой опыт у 40+, не означает, что он весь релевантен вакансии и здесь стоит корректировать зарплатные ожидания. А так да, проблема все та же, нанимают не за трудовые качества, а за навыки проходить собеседования.
Не стоит выбрасывать старые книги – лучше подарить им вторую жизнь, адаптируя и дополняя под современные реалии. Когда я читал классический «Clean Code» в 2018 году, уже тогда многие примеры написанные на Java, решались бы средствами языка C# образца 2018 года, а многие проблемы решаются линтером. Я предлагаю составить детальный список правил линтера с пояснениями, почему каждое правило введено. Те моменты, которые невозможно формализовать через линтер – стоит описать отдельно.
Пересмотреть так же стоит ООП. Сейчас многие используют data-объекты, а в C# добавили record для удобной работы с ними. И это все не смотря на то, что data-объекты противоречат идеалогии ООП.
Также полезно привязывать паттерны к конкретным языкам программирования и фреймворкам, а в вопросах архитектуры систем – формулировать основные принципы и сопоставлять их с реальными технологиями, например, сравнивая Kafka с RabbitMQ или DynamoDB с CosmosDB. Еще важна поддержка проверенных шаблонов проектов.
Когда знания разрозненны и черпаются из множества источников, становится сложно донести информацию до каждого. Именно поэтому так актуальны отраслевые стандарты и поддерживаемые сообществом источники опыта. Это позволит отправить сотрудника почитать конкретную книгу или статью, и вести с ним разговор на одном языке, опираясь на единые понятия.
Большая часть известных книг по архитектуре и паттернам устарела. Их нужно переработать и переосмыслить в текущих реалиях и с современными языками и фреймворками. И я не отрицаю то, что там написано, я лишь указываю на неактуальность части сведений. Тот же принцип High Cohesion очень важен и про него мало кто знает. Но вот тот же Creator, существует только потому, что когда-то ООП не допускало создавать DTO. В современном мире почти никто не наследует классы, а только интерфейсы и во всю практикуются принципы функционального программирования.
Так же проблема в том, что не существует хорошей терминологии для общения бизнес-аналитиков с программистами-архитекторами. У нас нет строгих отраслевых стандартов по ведению документации проекта, каждый придумывает что-то с переменным успехом. Нам не хватает списка плохих и устаревших технологий. Нам не хватает шаблонов для типовых задач. Все придумывают свои велосипеды и героически превозмогают трудности, вместо того, что бы делиться своим опытом с другими. Потому что мы до сих пор ссылаемся на книги 20-летней давности.
Я в 15м поставил себе Linux Mint, это как убунту, только больше похожая на Windows, и более отполирована. Мой старый принтер HP, плохо работает на Windows 7, 10 и даже 11. Мне приходилось по 5 раз переустанавливать драйвер и перезагружать комп, что бы принтер начал работать, и даже после этого уходит около 20 секунд, что бы передать одну страницу на печать (видимо драйвер по какой-то причине снижает скорость канала). На Linux Mint, без каких либо действий, он печатает одну за одной. Хотя раньше на Windows XP таких проблем не было. То же самое со старым МФУ от HP. Более того, есть варианты с другими Desktop Environment, который визуально проще, но потребляют меньше ресурсов. Поэтому всегда можно подобрать образ под очень старое железо. По умолчанию ставим Cinnamon, если лагает, то пробуем Xfce. Если и Xfce лагает, тогда можно попробовать Gentoo, но это уже совсем другая история.
Мне не нравится, что cursor это форк vscode, а не расширение для обычного vscode. Разработчики cursor говорили, что они упёрлись в ограничения extension api.
Вот, видимо Microsoft таким образом стимулирует cursor комитить в upstream, чтобы cursor всё-таки стал расширением. Майкам потом будет проще новые фичи для Copilot пилить.
Хорошо это или плохо пока непонятно.
Образование должно трансформироваться в сторону расширения кругозора, что бы можно было понимать и анализировать, то что выдает ИИ. Для этого нужно иметь хотя бы базовые знания предметной области. Так же нужно уметь работать с источниками. Так же нужно составлять справочники с проверенными знаниями в духе международной классификации болезней по которым можно будет проверять факты которые выдал ИИ.
Linux Mint более стабильна чем Ubuntu. Она основана на LTS версии Ubuntu. У меня ОС за несколько лет ни разу не слетала после обновлений софта или даже минорной версии ОС.
Linux Mint Cinnamon - это самый лучший выбор. Ключевая её особенность в том, что интерфейс очень похож на Винду, при этом это все та же популярная Ubuntu под которую адаптирована львиная доля linux-софта, и для которой описано как делать в консоли ту или иную операцию. Плюс есть менеджер программ, менеджер драйверов, менеджер обновлений, которые дадут возможность не пользоваться консолью.
Статья абсолютно бесполезная: из нее нельзя сделать каких-то выводов или переиспользовать опыт автора.
Во-первых, какая методология подсчёта экранного времени? На каких устройствах осуществлялся этот подсчет, как разделалась активность по работе и по безделью?
Во-вторых непонятно, что там автор делал перед сном. Автор начал читать книгу, а делал ли он это ранее на телефоне, или он смотрел цепляющие внимание тиктоки? Может быть было достаточно сменить потребляемый контент?
В текущем виде статья выглядит как: я что-то сделал, стал чувствовать себе лучше, вы тоже можете попробовать посоревноваться с друзьями.
Вложенность выравниванием сделает все хуже.
Это просто неадекватный рейтинг с непонятной методологией, которому нельзя доверять. Мне не понятен двойной рост популярности питона за год, низкой базой это не объяснить. Такое кажется невероятным.
Скорее всего изменилась методология подсчёта, либо источники данных (поисковики) начали выдавать свои результаты по-другому.
Чем этот проект лучше ts-runtime-checks?
https://github.com/GoogleFeud/ts-runtime-checks
Проект есть, но в продакшн мало кто его подключает, мне пока сложно понять почему. Вы изучали проблемы внедрения подобных анализаторов в проект?
Так вам и не нужно гуглить, вы же уже знаете название опенсорс модели уровня GPT4. Вот и назовите её, а я попробую её запустить и убедиться, что она действительно работает на таком уровне.
Какую модель такого уровня я могу скачать и где? Как её запустить? Могу ли я например подключить к этой модели какой-нибудь анализатор кода, который ей будет направлять вопросы и получать ответы в определенном формате.
То что кто-то где-то добился каких успехов в AI это здорово, но сейчас в отрасли проблема в том, что я не могу адаптировать эти результаты к своим задачам за разумное время.
Такая проблема есть не только в AI, но и в алгоритмах, хотя те же GPT могут адаптировать алгоритм под мою задачу, но не всегда хорошо, а если бы была хорошая библиотека обобщенных алгоритмов для того же JS, то было бы проще.
Нет, нет и нет. Это очень плохой подход и на опыте неоднократно в этом убеждался.
Во-первых, вы можете застейджить не весь код. Скрипт отработает, но потом если другой разработчик переключиться на вашу ветку будет иметь дело со сломанным комитом.
Во-вторых, есть тулы которые прячут незастейдженые изменения, делают проверку и возвращают все как было. И вроде как проблема решена, но иногда, если линтер может зависнуть или захочется его вырубить, может оказаться что спрятанные изменения не вернулись обратно.
В-третьих, бывает какому-то из разработчиков нужно быстро уйти (домой или обед) и передать наработки хоть в каком-то виде. И тут линты падают, а разобраться некогда, хорошо что я знаю, что если удалить папку hooks из папки .git, то вся эта ерунда работать не будет.
В-четвёртых, у разработчиков есть возможность обходить эти хуки, а так же может быть ситуация, когда в ветке А все работает, в ветке Б все работает, а если их смержить то Линт будет падать. Самый простой пример в обе ветки был добавлен import / using в разные места, это не приводит к мерж конфликту, но зато к падению линта.
В общем от хуков очень много геморроя и решают они проблему на 50%. Как же решить это проблему на 100%?
Ответ: CI.
В проекте делаем разделение на публичные ветки (main, dev, dev-new-big-feature) и приватные (i.popov/task-342-add-super-button).
В публичные ветки запрещается пуш и форс-пуш.
В публичные ветки разрешается мерж ПР, только если проходят все проверки линтов на результате мержа, а не на последнем коммите из ПР, то есть предварительно смержили и запустили линт). Если пушится коммит в одну из веток (source или destination), то проверка запускается заново.
Приватные ветки никто не трогает кроме автора, они используются только как хостинг результатов работы, в них разрешаются форс пушы и прочее баловство. Для тех кто скажет, мол не пуш пока не приведешь все в порядок, я отвечу, что у меня был такой проект где я не пушил пару дней и именно в эти 6 месяцев произошел отказ жёсткого диска с потерей изменений.
Мерж из приватной в публичную ветку происходит по squash -стратегии то есть все промежуточные коммиты сливаются воедино, что бы не захламлять историю. Что очень сильно помогает когда делаешь git bisect.