Утверждения о необходимости определения ЦА, меня всегда напрягало. Часто ЦА это действительно почти все. Давайте посмотрим на примерах некоторых существующих сервисов, итак какая ЦА у Калькулятора, Календаря, Pomodoro таймера, Бота для скачивания видео с ютуб, да того же Gmail? Я считаю что в большинстве проектов ЦА настолько широкая и разношёрстная что её определение не имеет смысла.
не-не-не ))) не подменяйте тут "знание" и "опыт" за несколько недель можно изучить новый язык но нельзя за несколько недель получить 3 года опыта работы с этим языком как с прошлым. а годы опыта с предыдущим языком - становятся не нужны.
переход с того же php на nodejs - это нормальная такая смена паттернов подходов и архитектуры так что старый опыт тут особо не подтянуть.
В общем вы спросили что там "сгорает" - вот нерелевантный современности устаревший опыт - сгорает, не надо теперь пытаться выкручиваться и говорить что это так везде и вообще ничего сложного ) На собеседовании через 5 лет это расскажете какой вы настоящий "разработчик" и у вас это вопрос пары недель ) и услышите что-то типа "ну а нам нужен человек с опытом"
ну может не 5ти но 10ти точно кому сейчас нужны навыки pixelperfect верстки под ie6 ? кто-то несколько лет кодил и изучал все тонкости первого angularjs и сейчас это просто мусорные знания опыт веб-дизайнера в photoshop перестал катироваться с ростом популярности figma а помните флешеров/ActionScript разработчиков? вот и я нет )
ПО регулярно обновляется, старые версии перестают использоваться и навыки работы с ними становятся не нужны
Актуальные знания это как раз где-то последние 3-4 года, на собеседованиях даже не интересуются чем вы там занимались на пред-пред-пред-предыдушем месте 7 лет назад. Вот и получается - вечный студент с разве что хорошей насмотренностью, на менедежеров и "бизнес", вот что годами не меняется в IT так это все эти "тасочки", "оценки", "сроки", "дедлайны", "маркетинг", "совещания"/"созвоны", "клиенты", "изменение требований", "правки", "мамкины бизнесмэны с идеями стартапов" ... хоть какая-то стабильность )
Всё так. Во многих других отраслях +/- то же самое.
Мне очень помогла взглянуть на эти вещи шире книга "Бредовая работа: Трактат о распространении бессмысленного труда. Дэвид Грэбер" , хоть в рассуждениях автора и есть изъяны, всё же рекомендую её к прочтению.
Эмм... Любить и уметь не одно и то же, ну допустим.
Видимо вы считаете своих коллег хорошими специалистами, просто так странно сформулировали, - чтож замечательно если такая команда собралась не в результате увольнений плохих сотрудников, а только из-за найма хороших.
Так вы и описали в статье исторически сложившиеся причины по которым процесс найма сломан ) Это и отношение к соискателю как к вещи / товару / потенциальной подделке и карго-культ, попытки подражать компаниям с которыми у вас ничего общего.
В сухом остатке то что получается - ну не можем мы никак на собеседовании отобрать нормальных спецов в команду - всегда это рулетка. Совсем идиотов отсеять - да можно, но дальше чистый рандом, чтобы в этом убедиться даже не нужно участвовать в процессе найма - просто посмотрите на своих коллег.
не забывайте отвязывать события, навешанные на кнопки с помощью метода offClick, чтобы при нажатии вы не вызвали все её предыдущие функции
Чтобы так не заморачиваться можно навесить на кнопку только один onClick - и далее в своем коде подменять функцию которая вызывается внутри, примерно так
let tgMainButtonActionFn = () => {}
window.Telegram?.WebApp.MainButton.onClick(() => {
if (typeof tgMainButtonActionFn === 'function') {
tgMainButtonActionFn()
}
})
function MainButtonOnClick(actionFn) {
tgMainButtonActionFn = actionFn
}
// Использование
MainButtonOnClick(()=> console.log('action 1') )
// затирает предыдущий экшн
MainButtonOnClick(()=>console.log('action 2') )
Ну а если где-то еще зачем-то понадобится слушать клики по этой кнопке то там уже использовать .onEvent('mainButtonClicked', ...)
В процессе разработки telegram mini web app столкнулся с тем что очень желателен туннель с https и фиксированным доменом, остановился на self-hosted решении - sish
"Я так долго все обдумываю что не важно что и остальное не быстро делаю" - что это за аргумент вообще?
Вы пользуетесь ide с автодополнеием и подсветкой синтаксиса, не в блокноте код набираете(а чего нет? там же незначительное совсем время на него нужно), пользуетесь git а не по email изменения отправляете. То есть используете инструменты ускоряющие вашу работу, но обесцениваете попытки автора пойти чуть дальше и просто немного лучше использовать те же инструменты.
Простите подгорело, под каждой статьей про эффективность есть комментарий типа вашего в стиле - долго думать, а код писать быстро - нет , не быстро, было бы быстро не выстрелил бы тот же copilot.
Неплохо! Хоть и можно было в данном случае информацию об отеле просто в "модалке" выводить и не рендерить каждый раз страницу результатов поиска при смене роута, а просто переключать свойство display, а для остального service-worker.
Но за статью спасибо, не знал о таких возможностях tanstack , надо будет доку получше почитать.
Нет проектов которые легко поддерживать спустя годы, потому что с годами меняются люди и подходы в разработке. Об этом косвенно свидетельствует опыт многолетней работы программистов на каком-нибудь одном предприятии, где они как специалисты "консервируются" и у них нет проблем с поддержкой проекта который работает уже 10 лет, но есть проблемы с трудоустройством в другие компании работающие уже на современном стеке. Если же они параллельно с работой развиваются , то у них регулярно чешутся руки всё переписать.
И наоборот, специалист с современными стеком вынужден ломать свои представления о разработке чтобы понять ту старую логику и те старые инструменты, которые в общем-то были хуже, труднее в использовании и т п
То есть поддержка старого кода всегда будет тяжёлой задачей, смиритесь с этим, тут либо стагнация, либо боль от встречи даже с самим собой из прошлого выраженного в том "бывшем" коде.
Cпасибо за подробный ответ! Я понял что нужно все что я описал реализовывать в модели, а статья у вас не про её внутренности, согласен. Мне тяжело вот так в уме представить всё это, я не видел подобных реализаций и вот показалось что это превратится в неповоротливого монстра если добавить всё что вы описали для работы с данными, будет огромное количество экшенов, частично или полностью дублирующих друг друга, раздутый стэйт и т п. но да - наверно это можно сделать более-менее красиво всё
Фронтендеры с этими многочисленными стейт-менеджерами из пустого в порожнее уже лет 15 переливают... и везде в примерах плохо работающая тудушка...
Минусы? Пока не обнаружены.
Минус вашего и многочисленных других подходов например в отсутствии синхронизации стейта между вкладками. Открыл пользователь пару вкладок с приложением - в одной например задачу добавил в тудушку - закрыл - в соседней вкладке все по старому. Если где-то какие-то данные регулярно обновляются тащатся с сервера через long-pooling например - то сколько вкладок открыто - столько запросов и будет отправляться. Какой-то недоглобальный стейт получается. Тут sharedWorker в помощь и слушатели изменения localStorage. Данные скорее всего одни и те же вытаскиваются по сто раз, не предусмотрено никакого кэширования. А что если еще и данных прям много? Нужна поддержка OPFS или может indexedDB. И как чистить стейт в таком случае от данных которые уже не нужны / не рендерятся больше?
Нет поддержки offline-mode - что если я хочу сидя в самолете набросать себе задач в туду-лист и чтобы они потом когда появится интернет отправились на сервер, а пока я бы мог их редактировать, может что-то бы уже отметил как выполненное пока летел.
Ну и пуш данных с сервера - чтобы если я с телефона что-то добавил - то оно в открытом сайте на компе отобразилось, опять же одного только сообщения через websocket тут не достаточно - крышка ноута то закрыта и он спит - нужно чтобы когда я открою ноут - сайт полез за обновлениями, а заодно отправил свои(ну те, из самолета).
Вот это всё сложные вопросы, не ясно как это лучше организовать, решений хороших и доступных просто нет, что-то платное(rxdb) или c vendor-lock(firebase) и еще с кучей своих ограничений. И если это все внедрять, то есть делать просто нормальное приложение которое не вводит в ступор пользователя, все подобные подходы превращаются в запутанного монстра, они не масштабируются нормально до такого уровня. А если не делать - то простите, но просто забрать фетчем json с сервака и не запутаться в том в какую переменную его засунул ума много не надо так что и проблем требующих какого-то решения и особенного подхода тоже нет.
То есть основной минус - невозможность масштабировать данный подход до уровня нормального приложения с синхронизацией большим объемом данных итп.
Думается мне, уволенные просто пойдут заниматься другим булшитом .
Нейросети не заменяют, а делают эффективнее людей. Потому освободившиеся люди просто займутся чем-то ещё. Ну то есть грубо, если раньше в геймдев компании было 10 художников, а теперь остался один+нейросеть , то вот эти 9 оставшихся уйдут в 9 новых компаний, которые появятся благодаря тому что на рынке появились свободные руки, благодаря тому что с нейросетями вход и конкуренция с крупными игроками стали дешевле. То есть мы как и весь последний век наращиванием обороты производства, больше освободившихся людей - больше новых производств
Утверждения о необходимости определения ЦА, меня всегда напрягало. Часто ЦА это действительно почти все. Давайте посмотрим на примерах некоторых существующих сервисов, итак какая ЦА у Калькулятора, Календаря, Pomodoro таймера, Бота для скачивания видео с ютуб, да того же Gmail? Я считаю что в большинстве проектов ЦА настолько широкая и разношёрстная что её определение не имеет смысла.
тут хорошо написано про попытки детально разобраться что же там происходит - https://habr.com/ru/articles/152593/
не-не-не ))) не подменяйте тут "знание" и "опыт"
за несколько недель можно изучить новый язык но нельзя за несколько недель получить 3 года опыта работы с этим языком как с прошлым.
а годы опыта с предыдущим языком - становятся не нужны.
переход с того же php на nodejs - это нормальная такая смена паттернов подходов и архитектуры так что старый опыт тут особо не подтянуть.
В общем вы спросили что там "сгорает" - вот нерелевантный современности устаревший опыт - сгорает, не надо теперь пытаться выкручиваться и говорить что это так везде и вообще ничего сложного ) На собеседовании через 5 лет это расскажете какой вы настоящий "разработчик" и у вас это вопрос пары недель ) и услышите что-то типа "ну а нам нужен человек с опытом"
ну может не 5ти но 10ти точно
кому сейчас нужны навыки pixelperfect верстки под ie6 ?
кто-то несколько лет кодил и изучал все тонкости первого angularjs и сейчас это просто мусорные знания
опыт веб-дизайнера в photoshop перестал катироваться с ростом популярности figma
а помните флешеров/ActionScript разработчиков? вот и я нет )
ПО регулярно обновляется, старые версии перестают использоваться и навыки работы с ними становятся не нужны
Актуальные знания это как раз где-то последние 3-4 года, на собеседованиях даже не интересуются чем вы там занимались на пред-пред-пред-предыдушем месте 7 лет назад.
Вот и получается - вечный студент с разве что хорошей насмотренностью, на менедежеров и "бизнес", вот что годами не меняется в IT так это все эти "тасочки", "оценки", "сроки", "дедлайны", "маркетинг", "совещания"/"созвоны", "клиенты", "изменение требований", "правки", "мамкины бизнесмэны с идеями стартапов" ... хоть какая-то стабильность )
.addEventListener('input',
Отлавливает все события
Всё так. Во многих других отраслях +/- то же самое.
Мне очень помогла взглянуть на эти вещи шире книга "Бредовая работа: Трактат о распространении бессмысленного труда. Дэвид Грэбер" , хоть в рассуждениях автора и есть изъяны, всё же рекомендую её к прочтению.
https://habr.com/ru/articles/685852/
Эмм... Любить и уметь не одно и то же, ну допустим.
Видимо вы считаете своих коллег хорошими специалистами, просто так странно сформулировали, - чтож замечательно если такая команда собралась не в результате увольнений плохих сотрудников, а только из-за найма хороших.
Так вы и описали в статье исторически сложившиеся причины по которым процесс найма сломан )
Это и отношение к соискателю как к вещи / товару / потенциальной подделке и карго-культ, попытки подражать компаниям с которыми у вас ничего общего.
В сухом остатке то что получается - ну не можем мы никак на собеседовании отобрать нормальных спецов в команду - всегда это рулетка. Совсем идиотов отсеять - да можно, но дальше чистый рандом, чтобы в этом убедиться даже не нужно участвовать в процессе найма - просто посмотрите на своих коллег.
Чтобы так не заморачиваться можно навесить на кнопку только один onClick - и далее в своем коде подменять функцию которая вызывается внутри, примерно так
Ну а если где-то еще зачем-то понадобится слушать клики по этой кнопке то там уже использовать
.onEvent('mainButtonClicked', ...)То есть факт наличия переменных с именами вас смутил, а переменная _ используемая только для export default норм? )
В процессе разработки telegram mini web app столкнулся с тем что очень желателен туннель с https и фиксированным доменом, остановился на self-hosted решении - sish
Hidden text
на локальной машине еще autossh использую чтобы само переподключалось при разрыве соединения
Спасибо за статью!
Обратите внимание на raycast для macos и его плагины , сильно ускоряет типовые действия
Может вы просто очень медленно думаете?
"Я так долго все обдумываю что не важно что и остальное не быстро делаю" - что это за аргумент вообще?
Вы пользуетесь ide с автодополнеием и подсветкой синтаксиса, не в блокноте код набираете(а чего нет? там же незначительное совсем время на него нужно), пользуетесь git а не по email изменения отправляете. То есть используете инструменты ускоряющие вашу работу, но обесцениваете попытки автора пойти чуть дальше и просто немного лучше использовать те же инструменты.
Простите подгорело, под каждой статьей про эффективность есть комментарий типа вашего в стиле - долго думать, а код писать быстро - нет , не быстро, было бы быстро не выстрелил бы тот же copilot.
Неплохо! Хоть и можно было в данном случае информацию об отеле просто в "модалке" выводить и не рендерить каждый раз страницу результатов поиска при смене роута, а просто переключать свойство display, а для остального service-worker.
Но за статью спасибо, не знал о таких возможностях tanstack , надо будет доку получше почитать.
Сама постановка задачи некорректная.
Нет проектов которые легко поддерживать спустя годы, потому что с годами меняются люди и подходы в разработке. Об этом косвенно свидетельствует опыт многолетней работы программистов на каком-нибудь одном предприятии, где они как специалисты "консервируются" и у них нет проблем с поддержкой проекта который работает уже 10 лет, но есть проблемы с трудоустройством в другие компании работающие уже на современном стеке. Если же они параллельно с работой развиваются , то у них регулярно чешутся руки всё переписать.
И наоборот, специалист с современными стеком вынужден ломать свои представления о разработке чтобы понять ту старую логику и те старые инструменты, которые в общем-то были хуже, труднее в использовании и т п
То есть поддержка старого кода всегда будет тяжёлой задачей, смиритесь с этим, тут либо стагнация, либо боль от встречи даже с самим собой из прошлого выраженного в том "бывшем" коде.
Cпасибо за подробный ответ! Я понял что нужно все что я описал реализовывать в модели, а статья у вас не про её внутренности, согласен.
Мне тяжело вот так в уме представить всё это, я не видел подобных реализаций и вот показалось что это превратится в неповоротливого монстра если добавить всё что вы описали для работы с данными, будет огромное количество экшенов, частично или полностью дублирующих друг друга, раздутый стэйт и т п. но да - наверно это можно сделать более-менее красиво всё
Фронтендеры с этими многочисленными стейт-менеджерами из пустого в порожнее уже лет 15 переливают... и везде в примерах плохо работающая тудушка...
Минус вашего и многочисленных других подходов например в отсутствии синхронизации стейта между вкладками. Открыл пользователь пару вкладок с приложением - в одной например задачу добавил в тудушку - закрыл - в соседней вкладке все по старому. Если где-то какие-то данные регулярно обновляются тащатся с сервера через long-pooling например - то сколько вкладок открыто - столько запросов и будет отправляться. Какой-то недоглобальный стейт получается. Тут sharedWorker в помощь и слушатели изменения localStorage.
Данные скорее всего одни и те же вытаскиваются по сто раз, не предусмотрено никакого кэширования. А что если еще и данных прям много? Нужна поддержка OPFS или может indexedDB. И как чистить стейт в таком случае от данных которые уже не нужны / не рендерятся больше?
Нет поддержки offline-mode - что если я хочу сидя в самолете набросать себе задач в туду-лист и чтобы они потом когда появится интернет отправились на сервер, а пока я бы мог их редактировать, может что-то бы уже отметил как выполненное пока летел.
Ну и пуш данных с сервера - чтобы если я с телефона что-то добавил - то оно в открытом сайте на компе отобразилось, опять же одного только сообщения через websocket тут не достаточно - крышка ноута то закрыта и он спит - нужно чтобы когда я открою ноут - сайт полез за обновлениями, а заодно отправил свои(ну те, из самолета).
Вот это всё сложные вопросы, не ясно как это лучше организовать, решений хороших и доступных просто нет, что-то платное(rxdb) или c vendor-lock(firebase) и еще с кучей своих ограничений.
И если это все внедрять, то есть делать просто нормальное приложение которое не вводит в ступор пользователя, все подобные подходы превращаются в запутанного монстра, они не масштабируются нормально до такого уровня. А если не делать - то простите, но просто забрать фетчем json с сервака и не запутаться в том в какую переменную его засунул ума много не надо так что и проблем требующих какого-то решения и особенного подхода тоже нет.
То есть основной минус - невозможность масштабировать данный подход до уровня нормального приложения с синхронизацией большим объемом данных итп.
Думается мне, уволенные просто пойдут заниматься другим булшитом .
Нейросети не заменяют, а делают эффективнее людей. Потому освободившиеся люди просто займутся чем-то ещё. Ну то есть грубо, если раньше в геймдев компании было 10 художников, а теперь остался один+нейросеть , то вот эти 9 оставшихся уйдут в 9 новых компаний, которые появятся благодаря тому что на рынке появились свободные руки, благодаря тому что с нейросетями вход и конкуренция с крупными игроками стали дешевле. То есть мы как и весь последний век наращиванием обороты производства, больше освободившихся людей - больше новых производств
так вот чья поделка звонит мне 24/7 с вопросом мечтал ли я когда-нибудь играть в группе )))