Мы делали пару лет назад бот одним ребятам и они его продвигали излишне непринужденно — просто писали всем юзерам из некой базы и приглашали.
Бот заблочили за спам, они написали в суппорт. Суппорт ответил в этот же день или на следующий и даже вернул к жизни бот, но с немного другим никнеймом.
В нашем случае не сработало.
Есть надежда что с TON они исправят этот момент
Спасибо, проверяем.
У нас была такая проблема при публичном старте, мы подошли основательно к ее решению, так как фильтрации по стэку не было — издержки слишком хитрого синтаксиса агрегаций монго — и всем сыпалось все, то были веселые несколько часов =)
Сейчас мы избрали такой механизм фильтрации: Если есть пересечение стэков, мы оповещаем, так как мы ограничиваем выбор стэка и пользователь указывает только ключевые позиции. Сначала выбор был ограничен 5 позициями, этого оказалось мало, сейчас — 10.
При этом если вам придет много вариантов, они будут отсортированы по количеству пересечения стэков — и тогда вы увидите самые актуальные в первую очередь
Цена пока не участвует в мэтчинге, только стэк и формат работы.
На неделе мы выпустим обновление с рядом усовершенствований и это будет в их числе.
Насчет мисмэтчинга по стэку — уверен, это недоразумение, но я обязательно проверю
Благодарю за непредвзятость и экспериментальный подход!
Заметил, что фраза «так себе» часто у вас ходу, поэтому не будем брать на свой счет =)
Разумеется, обеспечить равномерно предельный уровень качества непросто, но это — одна из наших задач и мы приступим к более плотной работе над ней как только поймем, что это бизнес-необходимость. На данном этапе мы только начинаем работу и изучаем рынок.
Уверен, однажды мы сможем найти контрагента и на ваш взыскательный вкус.
Спасибо за совет!
Эта статья посвящена временному аспекту поиска работы и тому, как на него влияет привычный нам ход вещей, что решения, которые в идеальных условиях могут быть приняты в течение нескольких минут, растягиваются на промежутки времени, которые выглядят несоответствующими. Мы сейчас сосредоточены на этой проблеме.
Ее решение — это мгновенный поиск встречных объявлений и сокращение нескольких коммуникационных этапов и связанных с ними практических лагов до времени, затрачиваемого на несколько запросов к базе данных.
Можно допустить, что если из 10 проектов которые вам понравятся, в 5 будет некорректная оценка, у вас останутся другие 5, в которых все будет нормально.
Вы изучили не стек на профессиональном уровне, а как профессионально по нему проходить собеседования.
Эта мысль отражена в статье, но спасибо что сделали ее еще более явной.
Уверен, мои знания вы вряд ли можете оценить по имеющимся у вас данным.
Проблема несколько в другом. Дело в том, что текущий объём используемых технологий в повседневной работе достаточно большой. Настолько большой, что приходится очень часто прибегать к разного рода справочникам (stackoverflow, zeal, wikipedia). А на собеседовании обычно ситуация выворачивается так, что только кандидат тупой, потому что до сих пор не запомнил всё это.
Бесспорно, я думаю проблема и в том и в том и еще в чем-то о чем мы с вами не знаем.
Всё у вас в кучу. Будущее проекта зависит в основном от умения его протолкнуть, а не правильности стека технологий. А выгорание сотрудника зависит от совокупности факторов, большая часть из которых связана с организацией труда, а не от того, есть ли на проекте jQuery.
Статья посвящена аспекту разработки проектов и квалификации сотрудника, а не их маркетинга и других сфер. Нам бы в рамках этой статьи с одной маленькой сферой разобраться. Так что в кучу все не у меня ;)
А что мы знаем о безопасности в телеграме?
Я знаю только то что Павел Дуров занимается экспериментальным голоданием, ходит во всем черном, хотя ему уже не 17, дружит с арабами, у которых в порядке вещей украсть туристку, и что телега полдня не работала когда остро вставал вопрос о доступе фсб к ней.
Безусловно, это факторы доверия.
Сейчас можно применить к любому синтаксису в котором не зарезервировано использование комментариев-меток вида /*-метка-*/ – что можно будет вскоре настроить.
Второе что можно будет настроить – это как раз файловая структура проекта. Сейчас заточено под стандартную схему фрнтендного проекта:
корневая папка
src (здесь — исходники, в которых aphs ищет разметку блоков)
node_modules (сюда устанавливается aphs и отсюда работает по относительному пути с src)
Я так понимаю, что это первоочередная задача, поэтому со следующим патчем зальем — благо много времени не требует.
Можно сделать плагин, мы делали с таким заделом. Когда node.js проходится по src, он сохраняет (или обновляет) в корень файл aphs.json — там находятся ссылки на файлы откуда брать и куда сохранять редактируемые в клиенте блоки кода и там же находится информация о контекстах, координатах блоков в них и тд. Надо продолжать использовать aphs.json, чтобы формировался единый стандарт – а в остальном смотреть серверный функционал в node_modules/aphs/aphs.js – там все односложно
Aphs можно приделать и к проекту на питоне – он работает со всем что находится в project-root/src. Если ваши исходники поместить в src и установить в корень aphs так чтобы node_modules лежала на одном уровне с src, то все будет. В скором времени решим вопрос гибкости структуры проекта
4.2*2.1 = 9, (корень: 3)
У меня получилось 8.82
Сложилось ощущением, что слегка под эндорфином писали =)
Бот заблочили за спам, они написали в суппорт. Суппорт ответил в этот же день или на следующий и даже вернул к жизни бот, но с немного другим никнеймом.
В нашем случае не сработало.
Есть надежда что с TON они исправят этот момент
У нас была такая проблема при публичном старте, мы подошли основательно к ее решению, так как фильтрации по стэку не было — издержки слишком хитрого синтаксиса агрегаций монго — и всем сыпалось все, то были веселые несколько часов =)
Сейчас мы избрали такой механизм фильтрации: Если есть пересечение стэков, мы оповещаем, так как мы ограничиваем выбор стэка и пользователь указывает только ключевые позиции. Сначала выбор был ограничен 5 позициями, этого оказалось мало, сейчас — 10.
При этом если вам придет много вариантов, они будут отсортированы по количеству пересечения стэков — и тогда вы увидите самые актуальные в первую очередь
На неделе мы выпустим обновление с рядом усовершенствований и это будет в их числе.
Насчет мисмэтчинга по стэку — уверен, это недоразумение, но я обязательно проверю
Заметил, что фраза «так себе» часто у вас ходу, поэтому не будем брать на свой счет =)
Разумеется, обеспечить равномерно предельный уровень качества непросто, но это — одна из наших задач и мы приступим к более плотной работе над ней как только поймем, что это бизнес-необходимость. На данном этапе мы только начинаем работу и изучаем рынок.
Уверен, однажды мы сможем найти контрагента и на ваш взыскательный вкус.
*произошли
Эта статья посвящена временному аспекту поиска работы и тому, как на него влияет привычный нам ход вещей, что решения, которые в идеальных условиях могут быть приняты в течение нескольких минут, растягиваются на промежутки времени, которые выглядят несоответствующими. Мы сейчас сосредоточены на этой проблеме.
Ее решение — это мгновенный поиск встречных объявлений и сокращение нескольких коммуникационных этапов и связанных с ними практических лагов до времени, затрачиваемого на несколько запросов к базе данных.
Можно допустить, что если из 10 проектов которые вам понравятся, в 5 будет некорректная оценка, у вас останутся другие 5, в которых все будет нормально.
Эта мысль отражена в статье, но спасибо что сделали ее еще более явной.
Уверен, мои знания вы вряд ли можете оценить по имеющимся у вас данным.
Бесспорно, я думаю проблема и в том и в том и еще в чем-то о чем мы с вами не знаем.
Статья посвящена аспекту разработки проектов и квалификации сотрудника, а не их маркетинга и других сфер. Нам бы в рамках этой статьи с одной маленькой сферой разобраться. Так что в кучу все не у меня ;)
Я знаю только то что Павел Дуров занимается экспериментальным голоданием, ходит во всем черном, хотя ему уже не 17, дружит с арабами, у которых в порядке вещей украсть туристку, и что телега полдня не работала когда остро вставал вопрос о доступе фсб к ней.
Безусловно, это факторы доверия.
Второе что можно будет настроить – это как раз файловая структура проекта. Сейчас заточено под стандартную схему фрнтендного проекта: