@iamilya: Ну, шифрование запросов, вероятнее всего будет. + проверка контрольных сумм\соли добавляемой клиентом.
Насколько я знаю, раньше в архейдже с подменой пакетов все было просто, и это вылилось в довольно печальные последствия. Сейчас, надеюсь, им хватило ума прикрутить нормальную защиту.
По поводу средств: тут сложно сказать, на самом деле. Есть решения самописные, есть продаваемые анти-боты и анти-читы, все они работают по своему. Были в свое время приблуды, чуть ли не мониторящие развернутые на компе процессы и убивающие процесс игры чуть-что (было правда давно, и почти не правда).
Все упирается в желание разработчика избавиться от ботов.
В любом случае, 90% времени, которого вы потратите на написание бота, будет потрачено как раз на то, что бы выбудете разбираться с тем, как все это будет работать.
Написать перцептрон для "бегай - копай грядки" по таймеру - не сложно, сделать что бы оно работало с конкретной игрой - сложно.
А вариант "перестать быть физ. лицом" не рассматриваете в принципе?
На мой взгляд, при наличии постоянного взаимодействия с проверенными заказчиком - решается сразу ряд вопросов по взаимодействию.
@TostMaria: Ну, как вам сказать. Для всех платформ, где поддерживается ++, можно писать на ++.
Дальше все упирается в ваши знания и количество раз, которые вы сможете выстрелить себе в ногу из написанного чудо-юда. :)
Я бы сказал, что если стоит вопрос "На чем начать писать быстро и просто"- вам нужен Пайтон.
C++ нужен там, где есть требования к высокой производительности. В частности - в играх.
@igafonov Успехи, в целом, переменные. До смены деятельности пока не дошел - тяну знания до уровня, когда будет не стыдно проваливаться на собеседованиях :)
Для себя начинал obj-C на codeSchool (немного по-детски, но для понимания синтаксиса подача, на мой взгляд, идеальная).
А дальше накачал миллиард книг (начиная от, на мой взгляд, местами слишком детального O`Reily программируем под ios) и видеороликов и прибегал к ним по мере реализации тех или иных фичей.
@igafonov На самом деле все зависит от приложений, над которыми придется работать.
Есть совершенно общие для всех разработчиков вещи по процессу, типа TDD и работы с юнитами, умение работать с Git\SVN, знает, что есть ООП и прочее.
Есть более привязанные к непосредственному написанию кода - это многопоточность, работа с апи, и т.д.
Есть чисто iOS вещи, типа общие знание о Core Data, очереди, фреймоворки и прочее.
Самый просто способ - полистайте вакансии, выпишите по пунктам и вперед.
В целом, я наверное не самый лучший советчик, ибо сам не так давно парсил интернеты в поисках ответа на те же вопросы. :)
@igafonov Я считаю наиболее правильным, на данный момент, делать основной упор исключительно на Obj-C.
Т.е. основной мастхэв для iOS разработчика - знать, как та или иная задача решается в рамках Obj-C.
Swift - скорее приятное дополнение, и больше показывает что разработчик следит за индустрией и готов развиваться. Но на данный момент все, что нужно - действительно следить за новостями данного языка, соотносить их с теми или иными возможностями Obj-C.
И да, мне кажется очевидным преувеличением сложность Obj-C.
Он несколько перегружен, за счет тесного слияния с С, и нестандартен в плане синтаксиса, однако ничего запредельно сложного и неординарного тем нет.
Главное - понять принципы.
На ближайшие пару лет можете забыть о разработке на Swift без знаний Obj-C.
Если вам понадобится что-то серьезнее хеллоуворлда, то или вы будете писать велосипеды, или вы будете ориентироваться в Obj-C коде уже реализованных решений.
Про поддержку уже написанных на obj-c приложений даже и говорить не буду.
@zxmd ну, основной проблемой в применении сикули, насколько я могу судить, являются ложно-срабатывания и бесконечная актуализация, особенно если меняются элементы.
+ отдельные "ветки" тестов под разные разрешения.
В качестве альтернативы в голову приходят тесты на селениуме основанные проверке координат элемента на экране ( findElement(By).getLocation().getX() findElement(By).getLocation().getY() ) и сравнивающий с заданными.
Плюс в том, что фактически нужно реализовать один тест, а дальше вызывать его для всех нужных элементов задавая только id\name\xpath и пару координат.
Соответственно помимо расположения конкретных нужных вам элементов контент на странице может меняться.
Зачем оно надо? Ну, например актуально при наличии динамического контента на странице (баннеры, посты, результаты поиска и пр. пр.)
Наложение скриншот - экран в данном случае может давать ложное срабатывание (например - длинный пост, кнопка "ответить" уехала за пределы окна видимости.
А селениумовский тест можно будет завязать строгое положение координаты Y и динамическое (в пределах) координаты X.
Ещё один бегло нагугленный вариант - habrahabr.ru/post/190358
Но, честно говоря не возьмусь судить о его эффективности. Меня, лично, слегка коробит такой подход.
@mataleao Ну, что помошники есть я не сомневаюсь, но моя паранойя не позволяет им доверять. :)
Хотя, возможно в Сингапуре все проще, смотрел на страны ЕС - там личное присутствие требовалось.
@mataleao
К сожалению, по поводу регистрации компании ничего подсказать не могу, нет подобного опыта. Хотя идея "регистрации онлайн" вызывает во мне смутные сомнения. Вероятнее всего придется как минимум один раз съездить.
@Londoner Зависит от конечной цели. Что, в итоге, хотите понять? Где больше всего нуждаются в разработчиках, где больше всего платят разработчикам или где живется слаще всего?)
upd* Мой комментарий в форме ответа удалили, так что продублирую здесь в виде коммента.
Уровень зарплат в валюте - фактически бесполезная информация. Прежде всего потому, что эта сумма оторвана от остальных реалий этого места.
Нет поправки на уровень жизни, стоимость жизни, средний уровень зарплат в принципе и вне отрасли, и пр.
Причем эти показатели очень сильно могут различаться даже в рамках одной страны (напр. Москва - Питер при схожем уровне зарплат в айти очень сильно разнятся по стоимости жилья). Про Калифорнию и Аляску - молчу. :)
+ опять же "сложностью поиска специалистов" сложно характеризовать рынок труда. Для соискателя скорее актуально количество вакансий/период времени.
Если вакансий мало, но они быстро закрываются - не значит, что спрос на соискателей велик, скорее наоборот.
@yramarad31 Увы, ничего вам по этому поводу не скажу, данную книжку читать не приходилось. Беглый гуглинг по названию вернул не очень хорошие отзывы, но это дело вкуса.
В целом, мне кажется довольно странной сама связка "Изучаем #ЯПName в среде #IDEName".
Это, как мне кажется, то же самое что "Учимся готовить на плите Bosh". Безусловно, у каждого инструмента (в данном случае IDE) есть свои особенности - фичи интерфейса, хоткеи, аддоны и прочее. Но в контексте изучения языка программирование использование одной или другой ИДЕ - скорее дело привычки.
@Taraflex преступления, реально раскрытые за счет анализа данных из сети можно посчитать по пальцам даже там, где эти данные активно собираются.
Преступления, которые раскрыты подобным образом, и об этом сообщено прессе - думаю, можно посчитать по пальцам одной руки.
То, что никто не пишет в сми о том, что за вами следят не отменяет этого печального факта.
А коллег в офисе вы так же контролируете?
Подходите, садитесь рядышком, заглядываете в монитор и отечески так "Привет, как дела, что поделываешь? и повторяете это 9 раз в сутки, день изо дня?
@adept7771 Остановился на автотестах на Java (в основном в связи с продуктом, на котором на тот момент внедрялись автотесты) и приложениях на Objective-C Ж)
Но это уже совсем другая история.
Насколько я знаю, раньше в архейдже с подменой пакетов все было просто, и это вылилось в довольно печальные последствия. Сейчас, надеюсь, им хватило ума прикрутить нормальную защиту.
По поводу средств: тут сложно сказать, на самом деле. Есть решения самописные, есть продаваемые анти-боты и анти-читы, все они работают по своему. Были в свое время приблуды, чуть ли не мониторящие развернутые на компе процессы и убивающие процесс игры чуть-что (было правда давно, и почти не правда).
Все упирается в желание разработчика избавиться от ботов.
В любом случае, 90% времени, которого вы потратите на написание бота, будет потрачено как раз на то, что бы выбудете разбираться с тем, как все это будет работать.
Написать перцептрон для "бегай - копай грядки" по таймеру - не сложно, сделать что бы оно работало с конкретной игрой - сложно.