С другой стороны несколько странно выглядят попытки выяснить квалификацию человека в какой то узкой специальности путем построения его психологического портрета сотрудниками, не разбирающимися в это специальности
Так ведь не профпригодность выясняли (я так понимаю, статью написал HR), а психологическую совместимость с коллективом. А кроме того, искали стратегию дальнейшего разговора, который уже будет технический специалист проводить.
Ресурсы вместо денег — разве это тип крафта? Мне кажется, это скорее игровой стиль, где вместо покупки предметов, их нужно создавать самостоятельно. Бывает так, что и самому создать можно и за деньги купить.
Найди рецепт — мне кажется, это тоже не вид системы крафта, а игровая фича, где для создания вещей нужны рецепты, а рецепты можно открывать по ходу игры.
Типами систем крафта скорее будут:
крафт по рецептам (рецепты доступны сразу, ищутся, покупаются, открываются случайным образом в результате импровизации и т.д.)
крафт комбинациями, где доступно несколько элементов (мана, энергия) и для крафта их нужно соединять между собой. Рецептов нет, все определяется тем, как и какие элементы будут объединены.
Я думаю, что вряд ли это так просто. Селектел — не частное лицо. И морока с продажей имущества клиента (что, кстати, еще нужно юридически обосновать, поскольку, насколько я знаю, если тебе должны денег, это еще не означает, что ты можешь пустить с молотка все принадлежащее должнику, до чего можешь дотянуться) компании не интересна.
она полномочия с себя сложила, а нового гендиректора не поставить
Я не думаю, что вы, как продавец услуг, должны пострадать только потому, что у кого-то организационные проблемы. Это ведь бизнес, не так ли? Что, если вы пойдете на встречу по доброте душевной, а из-за дальнейших внутренних проблем вы вообще эти полмиллиона долга больше не увидите? Скажем, директора поставить не удалось и… компания "самоликвидировалась".
Кстати, как подсказывают ниже, та ситуация все же немного отличается.
Я правильно понимаю, что ваша статистика показывает, что Мой Круг как ресурс практически не растет? Средние отклики и количества вакансий от месяца к месяцу вроде бы не демонстрируют тенденции к росту.
У меня прекрасное резюме — я составил его по курсам на ютубе, улучшил по курсам на hh и наполнил из чужих профилей linkedin.
А… Оно точно ваше после всего этого? :)
Когда мы задаем стандартные вопросы, это не значит, что нам больше не о чем спросить — просто мы хотим услышать ваши ответы именно на эти вопросы, чтобы узнать, чем вы в действительности хотите заниматься и что можете предложить компании
Когда мы даем стандартные ответы, это не значит, что нам больше нечего ответить. Просто мы устали в 100500 раз отвечать именно на эти вопросы и ждем, когда же у нас спросят что-нибудь действительно интересное
В мире Python и Ruby создание веб-сайтов с нуля — занятие довольно утомительное, поскольку эти языки для создания веб-сайтов не предназначались.
А PHP Расмус Лердорф изначально создавал как набор инструментов, написанных на С, позволяющих легко и быстро разрабатывать динамический HTML. PHP таким задумывался и таким остался, он сам и есть фреймворк.
А можно немного подробнее? В чем именно PHP является фреймворком и что именно в нем реализовано настолько лучше, чем в Python и Ruby? Я только поверхностно знаком с двумя последними, но не помню там ничего такого, в чем PHP их превосходил бы на голову.
У лида и клиента может очень сильно отличаться контактная информация. Например, лид компания могла получить на выставке. И в нем указано – какая выставка была, с кем общались, телефон контактный этого лица. А к моменту, когда лид становится клиентом, менеджер уже контактирует совсем с другими людьми, имеет много больше информации о компании, а потому и карточки в итоге значительно различаются.
И действительно, некоторые CRM-системы пошли по пути единого справочника Контрагентов, в которых меняется только признак в карточке – «лид, контакт, клиент и т.д.». На самом деле, такой подход не самый лучший, так как очень сильно ограничивает возможности CRM-системы.
Вы не могли бы пояснить эту мысль поподробнее? Мне кажется более удобным иметь одну карточку на каждое действующее лицо и видеть в этой карточке некую историю работы с лидом / клиентом / контактом. Тогда вся информация будет в одном месте, будет видно, с чего все начиналось, на какой выставке познакомились, что потом было и т.д. Зачем же заводить несколько карточек на одно и то же лицо, а потом собирать из них общий портрет?
Я думаю, в любом языке есть ситуации, которые трудно проанализировать статически. Но если число статических вызовов у вас в коде достаточно велико, пользу из статического анализа все же можно извлечь.
Мне кажется, для immutable классов такой вызов можно отследить еще на этапе парсинга скрипта до реального исполнения. Это ведь присваивание свойству класса, который объявлен неизменяемым.
И, очень хочется, чтобы разработчики Yii все-таки как-то это сделали «внутри» из коробки.
Что именно? Полную поддержку PGPool в ActiveRecord, который должен прозрачно работать не только с Postgres но и со многими другими БД?
Мне кажется, таких вещей, как noBalance(), который работает только для Postgres и только для PGPool в ActiveRecord во фреймворках лучше не реализовывать вообще.
По-моему, из статьи видно, что она вовсе не мистическая.
Так ведь не профпригодность выясняли (я так понимаю, статью написал HR), а психологическую совместимость с коллективом. А кроме того, искали стратегию дальнейшего разговора, который уже будет технический специалист проводить.
Интересно, будет ли uBlock блокировать "приемлемую" рекламу AdBlock? :)
Ресурсы вместо денег — разве это тип крафта? Мне кажется, это скорее игровой стиль, где вместо покупки предметов, их нужно создавать самостоятельно. Бывает так, что и самому создать можно и за деньги купить.
Найди рецепт — мне кажется, это тоже не вид системы крафта, а игровая фича, где для создания вещей нужны рецепты, а рецепты можно открывать по ходу игры.
Типами систем крафта скорее будут:
Я думаю, что вряд ли это так просто. Селектел — не частное лицо. И морока с продажей имущества клиента (что, кстати, еще нужно юридически обосновать, поскольку, насколько я знаю, если тебе должны денег, это еще не означает, что ты можешь пустить с молотка все принадлежащее должнику, до чего можешь дотянуться) компании не интересна.
Я думаю, это проблемы владельца, а не Селектела.
Кстати, как подсказывают ниже, та ситуация все же немного отличается.
Может быть, вы об этом напишете с цифрами?
Я правильно понимаю, что ваша статистика показывает, что Мой Круг как ресурс практически не растет? Средние отклики и количества вакансий от месяца к месяцу вроде бы не демонстрируют тенденции к росту.
Когда мы даем стандартные ответы, это не значит, что нам больше нечего ответить. Просто мы устали в 100500 раз отвечать именно на эти вопросы и ждем, когда же у нас спросят что-нибудь действительно интересное
Было бы неплохо делить текст на абзацы. Сплошное полотно плохо читается.
Спасибо за перевод!
Мне кажется, что то, что есть в PHP по работе с формами и выводом данных, не дотягивает до звания "фреймворк". Думаю, автор преувеличил.
А PHP Расмус Лердорф изначально создавал как набор инструментов, написанных на С, позволяющих легко и быстро разрабатывать динамический HTML. PHP таким задумывался и таким остался, он сам и есть фреймворк.
А можно немного подробнее? В чем именно PHP является фреймворком и что именно в нем реализовано настолько лучше, чем в Python и Ruby? Я только поверхностно знаком с двумя последними, но не помню там ничего такого, в чем PHP их превосходил бы на голову.
Вы не могли бы пояснить эту мысль поподробнее? Мне кажется более удобным иметь одну карточку на каждое действующее лицо и видеть в этой карточке некую историю работы с лидом / клиентом / контактом. Тогда вся информация будет в одном месте, будет видно, с чего все начиналось, на какой выставке познакомились, что потом было и т.д. Зачем же заводить несколько карточек на одно и то же лицо, а потом собирать из них общий портрет?
Это красиво, но абсолютно не читабельно :) Я сижу, читаю статью и пытаюсь убедить себя, что я все-таки не дальтоник :)
Я думаю, в любом языке есть ситуации, которые трудно проанализировать статически. Но если число статических вызовов у вас в коде достаточно велико, пользу из статического анализа все же можно извлечь.
Я имел ввиду конкретную ситуацию, которая приведена как пример в RFC.
Мне кажется, для immutable классов такой вызов можно отследить еще на этапе парсинга скрипта до реального исполнения. Это ведь присваивание свойству класса, который объявлен неизменяемым.
Что именно? Полную поддержку PGPool в ActiveRecord, который должен прозрачно работать не только с Postgres но и со многими другими БД?
Мне кажется, таких вещей, как
noBalance(), который работает только для Postgres и только для PGPool в ActiveRecord во фреймворках лучше не реализовывать вообще.