Процент с продаж может быть только у продавца.
Бонусы за лидов — у маркетологов.
У программиста должна быть зп чтобы он не думал где ему жить, что поесть и премии при достижении результатов значимых.
Если вклад в развитие компании очень существенный что есть доля — это дивиденды.
Вообще у компаний и у людей есть разные этапы на которых нужны разные люди — когда нет денег, все горит, людей мало, работы много — нужны с горящими глазами, за идею и тд — если вдруг так окажется что компания усилиями этих горящих глаз начнет развиваться — ей жизненно необходимо будет выстраивать процессы и горящие глаза тут станут вторичными, а первичной предсказуемость, стабильность, системность — если вы старались «с самого основания компании» а спустя время перестали в нее вписываться — это нормальный процесс, тут нечего обижаться — лучше самому этот момент понять и подготовиться к тому что скоро что то поменяется в отношениях с компанией из за несоответствия ее текущим потребностям
Как говорится — когда нанимаешь сотрудника, нужно знать за что ты его уволишь. Так же и нанимаясь на работу нужно знать из за чего ты уйдешь и сразу же озвучить свою позицию прямо на собеседовании — не клясться в вечной верности, а сказать что «если я уйду по какой то причине — я постараюсь это сделать максимально корректно и минимизировать ущерб»
На мой взгляд одна из основных проблем обид, страданий, потраченных лучших лет жизни и т.д. достаточно банальна — непонимание/незнание что разойтись можно корректно, минимизировав боль для обеих сторон. Бывал в разных ситуациях и с одной и с другой стороны — сам по молодости и неопытности бывало подставлял людей, тем что внезапно пропал и просто отморозился из за того что не умел в принципе отказывать в чем то людям в лицо, да и просто соперничать ментально со значительно более сильными и опытными руководителями — когда нет опыта и наработанного навыка отказывать людям или высказывать свою позицию без дискомфорта — в итоге силы заканчиваются и остается только пропасть с радаров и постараться забыть побыстрее этот неприятный этап.
Научился я этому когда сам в итоге влез в шкуру руководителя и разгребая последствия очередного внезапного ухода сотрудника подумал «ну неужели он не понимает что на нем свет клином не сошелся, что найду замену, как то подготовлюсь, в планировании учту… я ведь уточнял тактично что если расходятся сейчас пути это не значит что мы теперь враги — зачем уверять что все отлично и бросать проект недоделанный без предупреждения...»
А потом вспоминал себя и понял — действительно не понимает, я тоже не понимал, я вообще слабо понимал чем руководитель занимается, очень тяжело поставить себя на его место если никогда в жизни не было подобного опыта — свои мысли и проблемы (достаточно локальные и временные зачастую) поглощают сознание и болезненный уход становится вопросом времени.
Интересно наблюдать за собой сейчас — нахожусь в процессе ухода из стартапа — разошлись видения с руководителем. В процессе ухода — это значит что я документирую, ввожу в курс дел и нюансов команду, помогаю всячески в общем не потерять на ровном месте результаты своего же труда — я его ценю, не хочу спускать в унитаз — пусть приносит пользу. При этом на душе совершенно спокойно — понимаю что именно такое расставание должно быть нормой.
Если в какой то момент разошлись жизненные пути с компанией/человеком — это не означает что нужно терпеть до последнего — и в итоге хлопнув дверью всех подставить, поступив как говнюк. Последний месяц который обычно «досиживается» на работе чтобы получить зарплату и уйти можно потратить на то чтобы предупредив спокойно о своем решении дать руководителю время на это отреагировать и просто поступить по человечески передав свои дела и разойтись, ну если не друзьями, то хотя бы с уважением друг к другу. Возможно в будущем пути опять пересекутся — зачем на ровном месте наживать врагов?
P.S. Решил опытом поделиться — если вдруг у вас душевные муки — тема рабочая, просто предупреждаете заранее, дорабатываете спокойно передав дела, получаете свою зарплату и благодарность руководителя и ощущаете себя красавчиком
А как решались проблемы с помехами и энергетической насыщенностью среды? Когда дуги проскакивают — электромагнитное поле вышибает большую часть современной элементной базы
Окей — система автоматически понижает частоту когда начинает перегреваться, а есть какая нибудь информация о необходимом охлаждении? Достаточно ли пассивного радиатора или нужно активное охлаждение? Замечал просадку по производительности еще на rpi2 когда на opencv зрение для робота делал, установка пассивного радиатора в целом решало проблему. Но каких то численных исследований не проводил — можно ведь замеры сделать по каким нить бенчмаркам — сопоставить зависимость попугаев от температуры. В целом — для операционной системы по сути и не нужно знать какое там абсолютное значение частоты процессора — прерывания для планировщика генерируются таймером, а его частота не меняется, просто за квант времени выполняется меньше операций. Да и частота может и не меняться — просто такты пропускаются(троттлинг). Поидее никто не мешает используя ассемблерные команды обратиться к регистрам процессора и прочитать значения счетчиков PMU infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500j/BIIDADBH.html
ну рано говорить про руководителя — он не должен разбираться в технических деталях всех мельчайших, станция далеко не основной продукт яндекса — все таки это средство доставки основного цифрового продукта. Даже если в какой то момент разработки стало понятно что получается не очень — все равно с точки зрения бизнеса будет правильней доделать как есть продукт и зарелизиться чем чистить команду, менять все и откладывать все на год. Как инженер я вижу конечно ряд моментов которые можно было бы улучшить, в какие то вещи вроде подмеченных выше вообще верить не хочется что это продакшн компании уровня яндекса
Но потом я вспоминаю что это делала с нуля компания которая никогда ничего подобного не делала, вспоминаю как тяжело найти в России сейчас компетентных хоть более менее инженеров которые еще не свалили отсюда, вспоминаю специфику работы с такими инженерами и насколько она отличается от работы с программистами и понимаю что выпустить в принципе что то более менее рабочее включающее в себя достаточно непростую в плане разработки область типа фазированных микрофонных решеток — и язык не поворачивается сказать что это фуфло.
Хорошо ли отработало руководство проекта в итоге определяется тем насколько это решило бизнес задачи и принятыми решениями после анализа ошибок, которые всегда будут в первом продукте, без опыта. Интересней посмотреть на дальнейшее развитие, я честно говоря вообще не верю в рынок голосовых помощников в России — думаю история скорее имиджевая, ну или задел на будущее, не думаю что на данный момент даже с офигенной реализацией это какие то прибыли заметные — сколько должен продуктов яндекса больше начать потреблять пользователь с колонкой или потреблять других продуктов через яндекс колонку чтобы отбить RnD?
Сейчас просто нет ни механик рабочих нормальных, ни какого то рынка реально устоявшегося голосовых ассистентов — это скорее платформа для разработчиков, закинутая удочка чтобы начинать какой то опыт пользовательский анализировать и прорабатывать.Это явно таймфреймы не один год на которые это все рассчитывается — опять же, лучше с какими то данными и пользовательским опытом уже начинать работать, чем делать идеальную колонку и релизить ее без собственно контента которая тебя слышит из туалета, только вот ничего ответить тебе не может по делу
P.S.
Я так понимаю какие то личные обиды есть — по моему опыту чем раньше это отпустить тем лучше для всех, думаю следят за темой участники команды и примут к сведению замечания. А делать выводы о целесообразности и правильности чего то не зная всего процесса не вижу смысла — нам часто кажется что область в которой мы специалисты это самое важное, но самое важно для любой компании это зарабатывать деньги и наша область это всего лишь один из факторов который на это влияет
тоже удивился микрофонам от ST за полбакса с SNR 65dB когда уже 74dB делают, как бы экономить пару баксов, теряя при этом 6dB-10dB в динамическом диапазоне в устройстве у которого речь это единственный и основной источник ввода данных — ну такое.
Я не могу разглядеть на фото, но похоже что конденсаторы развязки по постоянному току керамические, а не пленочные? Тогда еще докинуть к шумам можно микрофонный эффект керамических конденсаторов.
АЦП тоже интересно было бы посмотреть, но смущает немного компоновка и разводка платы и то что я не вижу ни одного электролитического конденсатора и разделения аналоговой и цифровой части — дифференциальный выход на микрофонах это конечно хорошо, но цифровые шумы по питанию никто не отменял.
Была возможность потестить немного на конференции — в шумном помещении открытом расстояние 1м примерно рабочее стабильно, кроме того — не со всех направлений слышит, но в целом — вполне достойное распознавание благодаря тем кто делал ЦОС. Но чтот с аналоговой частью как то да — не особо как то похоже на аналогово цифровые платы которые я привык видеть. Обработка это замечательно конечно и снимаю шляпу что программа из этого что то вытаскивает, но ведь эти 6-10dB динамического диапазона они ничего не стоят же — купить микрофоны чуть подороже, чуть получше развести плату и это бы сэкономило время программистов которые из худшего сигнала пытались выжать вменяемый результат, про то что при этом детектирование, наведение и вот это вот все работало бы автоматически гораздо лучше и в нормальных условиях давало лучший пользовательский опыт я не говорю уже — ведь от того как фазированная решетка навелась, как отсекла шумы и тд и тп зависит то какого качества запись будет для распознавания в облаке. Получается что из за пары баксов сэкономленных на микрофонах и разработчиках аналогово-цифровых устройств — падает качество работы всей системы.
P.S.
На самом деле — как разработчик могу сказать что для чисто софтверной компании результат очень и очень достойный, найти и привлечь разработчиков с принципиально новой для компании компетенцией, производство наладить, промышленный дизайн и еще куча всяких областей в которых у компании нет компетенции, процессы не выстроены под это, нет опыта HR таких людей и вообще работы с ними… И в итоге всех найти, организовать, состыковать и выпустить в продакшн продукт который сравнивают с лидерами мировыми — это очень круто, думаю пройдет немного времени, набьют шишек, найдут людей и все будет в разы лучше
Спасибо — недавно перешел с C/C++ embedded в python и веб хайлоад)
Открыл некоторые вещи незнание которых было бомбой замедленного действия — например про ссылки, формально знал об этом, но так как в основном поведение было как у переменных — бдительность усыпило
а для чего тогда такая возможность в яндексе добавлена если это не совсем законно? Тут речь идет о сборе пожертвований — это вполне законно. Также вполне законно получать оповещения о поступлениях
Мне ничего не мешает — есть и ИП и ООО, но когда речь идет о каких то тестовых небольших проектах — например Telegram ботах — для многих разработчиков дополнительные сложности могут быть проблемой, на начальных этапах можно вполне принимать донаты таким способом — на мой взгляд это лучше чем никак не принимать.
Так можно протестировать идею — готовы ли за это люди платить или нет
можно ботом разве что подхватывать текст сообщений и заменять своим с упоминанием автора, предлагал подобное сделать в некоторые чаты, но в большинстве на сцену выходит синдром вахтера(в большинстве чатов админы школьники) — кто же тогда будет прикрикивать и наказывать нарушителей, кстати таким образом можно решить проблему одновременного потока мыслей нескольких человек — бот определяет каждое в свой блок и удаляет
Ну даже если не применительно к этому случаю, а в общем задача — как можно гарантировать при помощи криптографии, что исполняемая на сервере программа соответствует опубликованной? Чтобы при изменении кода доступ к аккаунту терялся
я согласен что это может (и должно) быть сделано средствами клиента, но в ближайшее время не думаю что стоит ожидать от Telegram обновлений по клиентам, кроме того — должны тогда все клиенты обновиться.
В BotAPI есть флаг enable_notification — при помощи него можно контролировать ботом — получит уведомление на это сообщение пользователь или нет.
Идеально я вижу так — в мейл агенте в волосатых годах была функция «разбудить собеседника» — аналогично в телеграме есть флаг notify_members при закреплении сообщения в чате. Нужно просто сделать возможность отключать по каждому пользователю, а не чату оповещения на время либо вручную либо автоматически, но при этом чтобы отправитель имел возможность форсировать оповещение на конкретное сообщение — то есть сделать не только жесткий мьют, но и мягкий — если что то действительно важное-отправитель имеет возможность оповестить.
Сообщения склеивать неправильно — это отдельные объекты должны быть, но клиент должен их визуально отображать по другому — группировать с возможностью выбора как группы, так и по отдельности
ага — неплохая идея. На самом деле ключевой момент который я бы хотел обсудить — как можно сделать подобного демона как сервис? Я могу хоть сейчас его запустить как веб сервис, чтобы не нужно было себе на VDS ничего ставить, а просто залогиниться и все, включать/выключать и настраивать через веб кабинет. Но встает тогда вопрос — как пользователь может быть уверен в том, что давая доступ к своему аккаунту этому демону — он дает его именно той программе исходный код которой опубликован и что его данные будут обрабатываться так как описано в этом коде
Подумал и понял что можно — просто мьютить чат на время, если идет поток сообщений от одного человека автоматически, а после таймаута возвращать обратно, но это уже должен и получатель пользоваться таким демоном
да-есть такое, какая то особенность десктопного клиента, но переводчик такой больше нужен на смартфоне — с пк проще вкладку с переводчиком открыть, а со смартфона — пока переключишься на приложение, пока скопируешь
Наличие или отсутствие у меня проблем с формальной логикой — это не конструктив,
Это мое оценочное суждение, я просто предположил
выражение досады по поводу сообщества.
по каким словам вы сделали вывод что я выразил досаду?
Я пока ничего не предлагаю
Да ладно
Вы же хотели не только новых идей, но и обсуждение, вот мы и обсуждаем.
Что обсуждаем? Безграмотность? Новый принцип гуманитарной индукции?(если бот не помогает в придуманном малозначимом случае значит он не работает вообще)
Бонусы за лидов — у маркетологов.
У программиста должна быть зп чтобы он не думал где ему жить, что поесть и премии при достижении результатов значимых.
Если вклад в развитие компании очень существенный что есть доля — это дивиденды.
Вообще у компаний и у людей есть разные этапы на которых нужны разные люди — когда нет денег, все горит, людей мало, работы много — нужны с горящими глазами, за идею и тд — если вдруг так окажется что компания усилиями этих горящих глаз начнет развиваться — ей жизненно необходимо будет выстраивать процессы и горящие глаза тут станут вторичными, а первичной предсказуемость, стабильность, системность — если вы старались «с самого основания компании» а спустя время перестали в нее вписываться — это нормальный процесс, тут нечего обижаться — лучше самому этот момент понять и подготовиться к тому что скоро что то поменяется в отношениях с компанией из за несоответствия ее текущим потребностям
Научился я этому когда сам в итоге влез в шкуру руководителя и разгребая последствия очередного внезапного ухода сотрудника подумал «ну неужели он не понимает что на нем свет клином не сошелся, что найду замену, как то подготовлюсь, в планировании учту… я ведь уточнял тактично что если расходятся сейчас пути это не значит что мы теперь враги — зачем уверять что все отлично и бросать проект недоделанный без предупреждения...»
А потом вспоминал себя и понял — действительно не понимает, я тоже не понимал, я вообще слабо понимал чем руководитель занимается, очень тяжело поставить себя на его место если никогда в жизни не было подобного опыта — свои мысли и проблемы (достаточно локальные и временные зачастую) поглощают сознание и болезненный уход становится вопросом времени.
Интересно наблюдать за собой сейчас — нахожусь в процессе ухода из стартапа — разошлись видения с руководителем. В процессе ухода — это значит что я документирую, ввожу в курс дел и нюансов команду, помогаю всячески в общем не потерять на ровном месте результаты своего же труда — я его ценю, не хочу спускать в унитаз — пусть приносит пользу. При этом на душе совершенно спокойно — понимаю что именно такое расставание должно быть нормой.
Если в какой то момент разошлись жизненные пути с компанией/человеком — это не означает что нужно терпеть до последнего — и в итоге хлопнув дверью всех подставить, поступив как говнюк. Последний месяц который обычно «досиживается» на работе чтобы получить зарплату и уйти можно потратить на то чтобы предупредив спокойно о своем решении дать руководителю время на это отреагировать и просто поступить по человечески передав свои дела и разойтись, ну если не друзьями, то хотя бы с уважением друг к другу. Возможно в будущем пути опять пересекутся — зачем на ровном месте наживать врагов?
P.S. Решил опытом поделиться — если вдруг у вас душевные муки — тема рабочая, просто предупреждаете заранее, дорабатываете спокойно передав дела, получаете свою зарплату и благодарность руководителя и ощущаете себя красавчиком
Но потом я вспоминаю что это делала с нуля компания которая никогда ничего подобного не делала, вспоминаю как тяжело найти в России сейчас компетентных хоть более менее инженеров которые еще не свалили отсюда, вспоминаю специфику работы с такими инженерами и насколько она отличается от работы с программистами и понимаю что выпустить в принципе что то более менее рабочее включающее в себя достаточно непростую в плане разработки область типа фазированных микрофонных решеток — и язык не поворачивается сказать что это фуфло.
Хорошо ли отработало руководство проекта в итоге определяется тем насколько это решило бизнес задачи и принятыми решениями после анализа ошибок, которые всегда будут в первом продукте, без опыта. Интересней посмотреть на дальнейшее развитие, я честно говоря вообще не верю в рынок голосовых помощников в России — думаю история скорее имиджевая, ну или задел на будущее, не думаю что на данный момент даже с офигенной реализацией это какие то прибыли заметные — сколько должен продуктов яндекса больше начать потреблять пользователь с колонкой или потреблять других продуктов через яндекс колонку чтобы отбить RnD?
Сейчас просто нет ни механик рабочих нормальных, ни какого то рынка реально устоявшегося голосовых ассистентов — это скорее платформа для разработчиков, закинутая удочка чтобы начинать какой то опыт пользовательский анализировать и прорабатывать.Это явно таймфреймы не один год на которые это все рассчитывается — опять же, лучше с какими то данными и пользовательским опытом уже начинать работать, чем делать идеальную колонку и релизить ее без собственно контента которая тебя слышит из туалета, только вот ничего ответить тебе не может по делу
P.S.
Я так понимаю какие то личные обиды есть — по моему опыту чем раньше это отпустить тем лучше для всех, думаю следят за темой участники команды и примут к сведению замечания. А делать выводы о целесообразности и правильности чего то не зная всего процесса не вижу смысла — нам часто кажется что область в которой мы специалисты это самое важное, но самое важно для любой компании это зарабатывать деньги и наша область это всего лишь один из факторов который на это влияет
Я не могу разглядеть на фото, но похоже что конденсаторы развязки по постоянному току керамические, а не пленочные? Тогда еще докинуть к шумам можно микрофонный эффект керамических конденсаторов.
АЦП тоже интересно было бы посмотреть, но смущает немного компоновка и разводка платы и то что я не вижу ни одного электролитического конденсатора и разделения аналоговой и цифровой части — дифференциальный выход на микрофонах это конечно хорошо, но цифровые шумы по питанию никто не отменял.
Была возможность потестить немного на конференции — в шумном помещении открытом расстояние 1м примерно рабочее стабильно, кроме того — не со всех направлений слышит, но в целом — вполне достойное распознавание благодаря тем кто делал ЦОС. Но чтот с аналоговой частью как то да — не особо как то похоже на аналогово цифровые платы которые я привык видеть. Обработка это замечательно конечно и снимаю шляпу что программа из этого что то вытаскивает, но ведь эти 6-10dB динамического диапазона они ничего не стоят же — купить микрофоны чуть подороже, чуть получше развести плату и это бы сэкономило время программистов которые из худшего сигнала пытались выжать вменяемый результат, про то что при этом детектирование, наведение и вот это вот все работало бы автоматически гораздо лучше и в нормальных условиях давало лучший пользовательский опыт я не говорю уже — ведь от того как фазированная решетка навелась, как отсекла шумы и тд и тп зависит то какого качества запись будет для распознавания в облаке. Получается что из за пары баксов сэкономленных на микрофонах и разработчиках аналогово-цифровых устройств — падает качество работы всей системы.
P.S.
На самом деле — как разработчик могу сказать что для чисто софтверной компании результат очень и очень достойный, найти и привлечь разработчиков с принципиально новой для компании компетенцией, производство наладить, промышленный дизайн и еще куча всяких областей в которых у компании нет компетенции, процессы не выстроены под это, нет опыта HR таких людей и вообще работы с ними… И в итоге всех найти, организовать, состыковать и выпустить в продакшн продукт который сравнивают с лидерами мировыми — это очень круто, думаю пройдет немного времени, набьют шишек, найдут людей и все будет в разы лучше
Удобно для впн-всякие яндекс музыка и тд работают и при этом заблокированные ресурсы доступны
Открыл некоторые вещи незнание которых было бомбой замедленного действия — например про ссылки, формально знал об этом, но так как в основном поведение было как у переменных — бдительность усыпило
Мне ничего не мешает — есть и ИП и ООО, но когда речь идет о каких то тестовых небольших проектах — например Telegram ботах — для многих разработчиков дополнительные сложности могут быть проблемой, на начальных этапах можно вполне принимать донаты таким способом — на мой взгляд это лучше чем никак не принимать.
Так можно протестировать идею — готовы ли за это люди платить или нет
В BotAPI есть флаг enable_notification — при помощи него можно контролировать ботом — получит уведомление на это сообщение пользователь или нет.
Идеально я вижу так — в мейл агенте в волосатых годах была функция «разбудить собеседника» — аналогично в телеграме есть флаг notify_members при закреплении сообщения в чате. Нужно просто сделать возможность отключать по каждому пользователю, а не чату оповещения на время либо вручную либо автоматически, но при этом чтобы отправитель имел возможность форсировать оповещение на конкретное сообщение — то есть сделать не только жесткий мьют, но и мягкий — если что то действительно важное-отправитель имеет возможность оповестить.
Сообщения склеивать неправильно — это отдельные объекты должны быть, но клиент должен их визуально отображать по другому — группировать с возможностью выбора как группы, так и по отдельности
Это мое оценочное суждение, я просто предположил
по каким словам вы сделали вывод что я выразил досаду?
Да ладно
Что обсуждаем? Безграмотность? Новый принцип гуманитарной индукции?(если бот не помогает в придуманном малозначимом случае значит он не работает вообще)