Почему нельзя в заголовок вакансии писать титульную технологию? Не Backend developer, а .NET Backend Developer? Разве, это сложно?
Почему нельзя писать зарплатную вилку? Вы хотите торговаться по з/п? Так торгуйтесь. Вы потратите больше денег, если кандидат пройдет все этапы, а потом вы не сойдетесь по з/п? Это особенно классно, когда сами HR-пишут в linkedin и пытаются переманить человека с текущего места. Кандидат спокойно сходит на собеседование, что бы быть в тонусе.
Зачем супер подробно рассказывать, про историю компании, а особенно про географию клиентов? Лучше расскажите, про процессы, да банально в какое время стоят миты. Читайте дальше по методичке, только включите в неё нужную информацию.
Если вам интересен фидбек по описанию вакансии, можете написать мне в telegram: @swatoplus
Temporal действительно классная вещь, но мы его уже лет 5 ждём. Я не понимаю почему коммитет тянет. Это очень важный стандарт и нужно бросить все силы, что бы довести его до stage 4.
Ценник, конечно, конский. Пол года аренды сравнимо с ценой нового девайса. Но все равно, это не то, что нужно для CI. Для CI нужен облачный сервер с поминутной тарификацией.
Вот, статья конечно хорошая. Но свести её можно к "используйте Cordova для заворачивания pwa в twa". Это все понятно, но проблема появляется во всем остальном. Как собрать? Как собирать на CI (вот у selectel можно арендовать мак девайсы? Или же есть кросс-компиляция). Как это подписать и что для этого нужно? Ну и как публиковать в стор?
Вот я сейчас разрабатываю на electron под Винду и мак ос. Собираю под мак руками. Для CI нужен мак девайс. Вот если вы мне дадите конфиг, назовёте тарифы, я с радостью понесу вам свои деньги.
Есть процесс называемый трансляцией (я его назвал сборкой, сути это не меняет). Это преобразование кода на одном языке в другой (Go в машкод, C# в MSIL, TS в JS), принципиальной разницы в этом нет. Если в MSIL, есть типы, то в машкоде их нет, как и в JS. Разработка в JS, это конечно не тоже самое, что в машкоде, но принцип тот же.
Если на Go, DLL вызывается неправильно происходить SEGFAUL, что более страшно, чем плохо написанные .d.ts. Вы так же можете нарваться на такие же проблемы.
Проблема заключается в обмазыванием тонной тулинга
Один прекрасно настроенный Vite все решает, или Bun для консольных приложений. В том же C# есть msbuild, nuget, roslyn analyzers и там тоже есть что по изучать.
Нет это Вы предъявите мне причины почему я должен использовать TypeScript
Вот эта причина:
Цель создания TS это просто попытка решения проблемы слабой типизации языка JavaScript вызывающей падения в рантайме чтобы можно было отловить их на компайл тайм. Именно эту проблему решает TS засчёт обязательного требования по указанию всех типов параметров и созданию интерфейсов
А что касается полифилов:
Внезапно оказывается, что даже если собирать нативный бинарник, он может не запуститься на голой ОС из-за отсутствия библиотек. И надо либо ставить библиотеки, либо раздувать бинарник. То же самое в JS-мире -- хочешь поддержку старых браузеров, раздувай бандл полифилами.
Как это относиться к сабжу про TS?
TS в плане поддержки "старья" ничем не отличается от других технологий.
А на машине разработчика нельзя скомпилировать TS в es5 со всеми полифилами?
Можно но как это относиться к тому что все должны немедленно начать писать на TypeScript?
В Go есть процесс сборки, в C# есть процесс сборки, а на JS можно без сборки, но лучше на TS со сборкой, что бы получить преимущества типизации. У Go, перед TS в этом плане нет никакого преимущества. Проблемы в том, что бы использовать TS из-за того, что его не поддерживает браузер нет. Перечитайте:
До тех пор пока TypeScript не появиться в браузере говорить о том что только в нем надо писать весь код а все кто не согласен извращенцы крайне спорно.
Нет ни единой причины не использовать TypeScript в браузере, да посредством сборки, но сути дела это не меняет. Если не согласны приведите контрпример.
А то что в Стиме половина игр ставят на комп vc++ redistributable?
Это тут вообще причем?
Внезапно оказывается, что даже если собирать нативный бинарник, он может не запуститься на голой ОС из-за отсутствия библиотек. И надо либо ставить библиотеки, либо раздувать бинарник. То же самое в JS-мире -- хочешь поддержку старых браузеров, раздувай бандл полифилами.
По моему опыту, главная сложность RxJS в том, что все разновидности потоков сваливаются в один тип — Observable. В результате:
есть «горячие» и «холодные» потоки;
есть потоки, которые просто отдают единственное значение (как Promise);
есть BehaviorSubject, который сразу возвращает текущее значение.
Было бы здорово хотя бы разделить Behavior и обычные потоки. Представьте себе:
BehaviorObservable (наследник Observable) с полем value, которое синхронно отдает текущее значение;
SingleObservable для одноразовых эмиссий, аналогичный Promise; // хотя зачем если есть Promise?
…и т. д. для остальных сценариев (cold / warm).
Такая иерархия позволила бы сразу понять, чего ждать от конкретного объекта, не заглядывая в документацию.
Отдельный лайфхак для Angular-разработчиков: для HTTP запросов зачастую удобнее использовать нативные Promise — они проще по семантике и не требуют дополнительных ухищрений для единственного ответа. (Это уже не про RxJS, а про выбор инструмента в Angular.)
А на машине разработчика нельзя скомпилировать TS в es5 со всеми полифилами? Или это другое? А то что в Стиме половина игр ставят на комп vc++ redistributable?
Когда мы говорим “джаваскрипт”, мы подразумеваем много разных вещей:
Когда мы говорим “джаваскрипт”, мы подразумеваем 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, но это уже совсем другая история.
Почему нельзя в заголовок вакансии писать титульную технологию? Не Backend developer, а .NET Backend Developer? Разве, это сложно?
Почему нельзя писать зарплатную вилку? Вы хотите торговаться по з/п? Так торгуйтесь. Вы потратите больше денег, если кандидат пройдет все этапы, а потом вы не сойдетесь по з/п? Это особенно классно, когда сами HR-пишут в linkedin и пытаются переманить человека с текущего места. Кандидат спокойно сходит на собеседование, что бы быть в тонусе.
Зачем супер подробно рассказывать, про историю компании, а особенно про географию клиентов? Лучше расскажите, про процессы, да банально в какое время стоят миты. Читайте дальше по методичке, только включите в неё нужную информацию.
Если вам интересен фидбек по описанию вакансии, можете написать мне в telegram: @swatoplus
Temporal действительно классная вещь, но мы его уже лет 5 ждём. Я не понимаю почему коммитет тянет. Это очень важный стандарт и нужно бросить все силы, что бы довести его до stage 4.
А можно версию где в query params пишется girl's name?
Ноль, целковый... Остаётся гадать, оригинальную идею сгалюцинировал LLM или же человек. Если второй вариант, то требуется помощь нарколога.
Используйте Typescript с линтером и забудьте об этом. Не пишите на чистом js. Относитесь к js как к машинному коду.
Ценник, конечно, конский. Пол года аренды сравнимо с ценой нового девайса. Но все равно, это не то, что нужно для CI. Для CI нужен облачный сервер с поминутной тарификацией.
Вот, статья конечно хорошая. Но свести её можно к "используйте Cordova для заворачивания pwa в twa". Это все понятно, но проблема появляется во всем остальном. Как собрать? Как собирать на CI (вот у selectel можно арендовать мак девайсы? Или же есть кросс-компиляция). Как это подписать и что для этого нужно? Ну и как публиковать в стор?
Вот я сейчас разрабатываю на electron под Винду и мак ос. Собираю под мак руками. Для CI нужен мак девайс. Вот если вы мне дадите конфиг, назовёте тарифы, я с радостью понесу вам свои деньги.
Есть процесс называемый трансляцией (я его назвал сборкой, сути это не меняет). Это преобразование кода на одном языке в другой (Go в машкод, C# в MSIL, TS в JS), принципиальной разницы в этом нет. Если в MSIL, есть типы, то в машкоде их нет, как и в JS. Разработка в JS, это конечно не тоже самое, что в машкоде, но принцип тот же.
Если на Go, DLL вызывается неправильно происходить SEGFAUL, что более страшно, чем плохо написанные .d.ts. Вы так же можете нарваться на такие же проблемы.
Один прекрасно настроенный Vite все решает, или Bun для консольных приложений. В том же C# есть msbuild, nuget, roslyn analyzers и там тоже есть что по изучать.
Вот эта причина:
А что касается полифилов:
TS в плане поддержки "старья" ничем не отличается от других технологий.
В Go есть процесс сборки, в C# есть процесс сборки, а на JS можно без сборки, но лучше на TS со сборкой, что бы получить преимущества типизации. У Go, перед TS в этом плане нет никакого преимущества. Проблемы в том, что бы использовать TS из-за того, что его не поддерживает браузер нет. Перечитайте:
Нет ни единой причины не использовать TypeScript в браузере, да посредством сборки, но сути дела это не меняет. Если не согласны приведите контрпример.
Внезапно оказывается, что даже если собирать нативный бинарник, он может не запуститься на голой ОС из-за отсутствия библиотек. И надо либо ставить библиотеки, либо раздувать бинарник. То же самое в JS-мире -- хочешь поддержку старых браузеров, раздувай бандл полифилами.
По моему опыту, главная сложность RxJS в том, что все разновидности потоков сваливаются в один тип —
Observable. В результате:есть «горячие» и «холодные» потоки;
есть потоки, которые просто отдают единственное значение (как
Promise);есть
BehaviorSubject, который сразу возвращает текущее значение.Было бы здорово хотя бы разделить Behavior и обычные потоки. Представьте себе:
BehaviorObservable(наследникObservable) с полемvalue, которое синхронно отдает текущее значение;SingleObservableдля одноразовых эмиссий, аналогичныйPromise; // хотя зачем если есть Promise?…и т. д. для остальных сценариев (cold / warm).
Такая иерархия позволила бы сразу понять, чего ждать от конкретного объекта, не заглядывая в документацию.
Отдельный лайфхак для Angular-разработчиков: для HTTP запросов зачастую удобнее использовать нативные
Promise— они проще по семантике и не требуют дополнительных ухищрений для единственного ответа. (Это уже не про RxJS, а про выбор инструмента в Angular.)А на машине разработчика нельзя скомпилировать TS в es5 со всеми полифилами? Или это другое? А то что в Стиме половина игр ставят на комп vc++ redistributable?
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, но это уже совсем другая история.