Спасибо за ваш комментарий! Разумеется, речь не идет о том, что резюме с такими неточностями не станут рассматривать. Мы ни в коем случае не заявляем, что резюме, не прошедшее обработку редактором, отвергнут, например, HR-менеджеры DataArt. Считаем ли мы, что грамотно оформленное резюме выглядит лучше? Да. Может ли это повлиять на выбор кандидата? Скорее всего, только при прочих равных условиях. Денег за обработку мы не требуем.
Пример с формошлёпством на Django показался нам симпатичным. Последний список не подборка «Не делайте так ни в коем случае».
Это не клиентский, это наш внутренний проект, собственно, на Skillotron DataArt тоже ничего не зарабатывает. Нам приятно, что сервис оказался востребованным, мы хотим развивать сообщество, нам вообще нравится быть хорошими. Данные мы никому не передаем, в конце концов мы же не агентство подбора персонала для сторонних организаций. И мы уверены, что инженеры далеко не дураки, зачем же пытаться кого-то обмануть. Особенно здесь. А название DataArt у нас с самого начала — с 1997 года.
Мы не торгуем персональными данными — не имеем такого права и никоим образом в этом не заинтересованы. Это было бы, мягко говоря, странной бизнес-моделью, категорически не в нашем стиле. Да и в ее финансовых перспективах возникают серьезные сомнения!
Требования к обработке персональных данных довольно четко сформулированы на уровне законов, и сервис работает в строгом соответствии с этими требованиями. Собственно, об этом написано в пользовательском соглашении и согласии на обработку персональных данных. Скрывать нам нечего :)
Для DataArt CV Duck — это на 99 % вклад в развитие IT-сообщества, на 1 % — возможность встречи с кандидатами, интересными именно нам (примерно такова статистика появления в сети резюме, соответствующих нашим вакансиям). В этих случаях мы связываемся с людьми индивидуально, но преследовать их себе не позволяем.
Спасибо за отзыв, вопрос с pdf-файлами мы тоже считаем актуальным. Тем не менее, решили открыть доступ к существующей версии. Все же резюме в .doc/docx есть у многих. Высокие ожидания от любого сервиса только приветствуем!
Справедливости ради, в этом случае сервис как раз предлагает любому IT-специалисту привести все термины и падежи в общепринятый вид, не более того. Оценок авторам резюме никто не выставляет, замечания к документу видят только сами авторы. Нам все же кажется, что диалог между инженерами и HR-специалистами необходим. Здорово, если удастся хоть немного способствовать его дальнейшему развитию!
Именно из-за проблем с многопоточностью я использовала Realm-объекты только в классах, отвечающих непосредственно за хранение/выдачу информации из базы данных. Дальше они маппились на обычные структуры, которыми я уже спокойно оперировала в остальных частях приложения. Чтобы обновлять свои объекты при изменении Realm-объектов, использовала нотификации, подписывалась на изменения результатов запросов.
Все операции с Realm-объектами происходили в соответствующих методах слоя работы с бд, в каждом методе я создавала instance Realm’а, с которым проводила операции по чтению или записи информации, так что Realm-объекты не передавались между потоками. Перед блоком операции записи проверяла, что мы не в главном потоке.
1. Тестировщики? А это кто? (шутка). Нет, в этом случае не тестировал, т. к. жизн-бол.
2. В 90% случаев — да.
В 10 % случаев — нет. Frida — это инструмент как раз для таких 10 процентов.
+ у нас не было как такового креша, у нас была ошибка в логике обработки пушей.
Можно.
В моем случае сборка с APNS багом была уже относительно старой, и чтобы ее собрать, надо было откатится довольно далеко по коммитам назад, что тоже не проблема.
Просто я находился в таком положении, когда мне надо было максимально точно показать, что косяк на стороне приложения (сначала я хотел показать, что косяк не на стороне приложения, но потом это оказалось не так).
И если бы я пересобрал сборку заново, то мои вышестоящие коллеги могли бы сказать, что это разные приложения: «Может, вы там может что-то починили/поменяли, пока пересобирали».
Мне нужо было работоть с тем, что максимально близко ушло в релиз.
Довольно специфическая ситуация :)
Пример с формошлёпством на Django показался нам симпатичным. Последний список не подборка «Не делайте так ни в коем случае».
Для DataArt CV Duck — это на 99 % вклад в развитие IT-сообщества, на 1 % — возможность встречи с кандидатами, интересными именно нам (примерно такова статистика появления в сети резюме, соответствующих нашим вакансиям). В этих случаях мы связываемся с людьми индивидуально, но преследовать их себе не позволяем.
Все операции с Realm-объектами происходили в соответствующих методах слоя работы с бд, в каждом методе я создавала instance Realm’а, с которым проводила операции по чтению или записи информации, так что Realm-объекты не передавались между потоками. Перед блоком операции записи проверяла, что мы не в главном потоке.
2. В 90% случаев — да.
В 10 % случаев — нет. Frida — это инструмент как раз для таких 10 процентов.
+ у нас не было как такового креша, у нас была ошибка в логике обработки пушей.
В моем случае сборка с APNS багом была уже относительно старой, и чтобы ее собрать, надо было откатится довольно далеко по коммитам назад, что тоже не проблема.
Просто я находился в таком положении, когда мне надо было максимально точно показать, что косяк на стороне приложения (сначала я хотел показать, что косяк не на стороне приложения, но потом это оказалось не так).
И если бы я пересобрал сборку заново, то мои вышестоящие коллеги могли бы сказать, что это разные приложения: «Может, вы там может что-то починили/поменяли, пока пересобирали».
Мне нужо было работоть с тем, что максимально близко ушло в релиз.
Довольно специфическая ситуация :)