Мне кажется, что 95% юзеров достаточно markdown. А остальным 5% как будто следует использовать html+css, Latex или что-то подобное. А ещё есть typecell (Mark Down + Typescript + jsx).
Лично мне кажется, что так больше контроля на потоком данных и соблюдается принципы low coupling и high cohesion. Ну вот как-то по субъективным ощущениям это работает луше.
Я использую RxJS и Inversify в связке с react и это работает. А Redux, это просто очень много размазанного по системе бойлерплейта. Может быть я чего-то не понимаю, но для меня дебажить и писать новые фичи с Redux сложнее и дольше.
RxJS + Inversify позволяет хранить структуру данных вместе с методами их обработки. Соблюдается принцип high cohesion. Я вижу в одном месте связанные логически вещи и инкапсулирую состояние. Появляется иерархия сервисов. От простых для работы с localstorage, до сложных бизнес сценариев (например многошаговые формы, я могу создать сервис для всех этапов, и сервисы для конкретного шага, что позволяет выстроить нормальные и слабозависимые друг от друга шаги и отдать их разным разработчикам).
Вы хотели решить проблему, того что текущие сотрудники увидят эту вакансию и удивяться, что могут взять с улицы за большую сумму. Большая викла решает эту проблему, большой диапазон дает кандидату понять финасовые возможности компании, но так же показывает текущим сотрудникам, что они в этой вилке.
Моя проблема как кандидата, что мне прилетают приглашения на собес где самое максимальное предложения сильно меньше, чем я ожидаю. А для того, что бы это фильтрануть, мне надо пройти тех. собес и по сути дойти до оффера, что бы узнать уровень оплаты труда.
А теперь вопрос: почему на Python? Вакансии вообще существуют? Мне кажется, что даже на PHP проще работу найти чем на python. А ведь есть ещё прекрасный Typescript, С#, Ыыынтырпрайз Java.
Почему нельзя в заголовок вакансии писать титульную технологию? Не 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?
Мне кажется, что 95% юзеров достаточно markdown. А остальным 5% как будто следует использовать html+css, Latex или что-то подобное. А ещё есть typecell (Mark Down + Typescript + jsx).
Лично мне кажется, что так больше контроля на потоком данных и соблюдается принципы low coupling и high cohesion. Ну вот как-то по субъективным ощущениям это работает луше.
Я использую RxJS и Inversify в связке с react и это работает. А Redux, это просто очень много размазанного по системе бойлерплейта. Может быть я чего-то не понимаю, но для меня дебажить и писать новые фичи с Redux сложнее и дольше.
RxJS + Inversify позволяет хранить структуру данных вместе с методами их обработки. Соблюдается принцип high cohesion. Я вижу в одном месте связанные логически вещи и инкапсулирую состояние. Появляется иерархия сервисов. От простых для работы с localstorage, до сложных бизнес сценариев (например многошаговые формы, я могу создать сервис для всех этапов, и сервисы для конкретного шага, что позволяет выстроить нормальные и слабозависимые друг от друга шаги и отдать их разным разработчикам).
Розетки в откосах по земстандарту!
Вы хотели решить проблему, того что текущие сотрудники увидят эту вакансию и удивяться, что могут взять с улицы за большую сумму. Большая викла решает эту проблему, большой диапазон дает кандидату понять финасовые возможности компании, но так же показывает текущим сотрудникам, что они в этой вилке.
Моя проблема как кандидата, что мне прилетают приглашения на собес где самое максимальное предложения сильно меньше, чем я ожидаю. А для того, что бы это фильтрануть, мне надо пройти тех. собес и по сути дойти до оффера, что бы узнать уровень оплаты труда.
Звучит, как будто надо делать свою компанию, где всем будут править разрабы. Вот есть только одна проблема: где искать сбыт.
Пишите 500 - 5000 USD и проблем не будет. Компания покажет, что к нее есть бюджеты, но их надо заслужить.
А теперь вопрос: почему на Python? Вакансии
вообще существуют? Мне кажется, что даже на PHP проще работу найти чем на python. А ведь есть ещё прекрасный Typescript, С#, Ыыынтырпрайз Java.
Почему нельзя в заголовок вакансии писать титульную технологию? Не 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 уже доступен нативно в ОС без компиляции и линковки?