• Разработка мобильных приложений и веб-программирование - можно ли совместить?

    @azShoo
    Между этими сферами много "пересекающихся" областей, но и очень много вещей специфических для одной из.
    По личному опыту: знаю разработчиков одинаково подкованных и в веб(бэкенд) и мобильной разработке. Но, я бы сказал, что если бы эти люди сконцентрировались на одной сфере, а не на двух - стали бы гуру. А сейчас же - среднестатетический хороший разработчик.

    Объединить это в одном стеке технологий и решений - не получится.
    Одинаково ориентироваться в двух стеках - вполне возможный вариант. Все упирается в опыт и количество потраченного времени.
    Опять же, есть люди, которые быстро учатся. Для них стек технологий и набор библиотек - не более чем инструмент, и они очень просто переключаются с одного на другой. Сел, разобрался за месяц-другой и все хорошо.
    Есть люди, которые переключение между спецификой даже в рамках одной платформы (или даже стека) дается тяжело. Для них это "обучение программированию с 0", а не "почитал, понял особенности, погуглил нужные библиотеки, понял как это работает".

    Вопрос ещё в том, что в определенный момент вам может быть _выгоднее_ (с точки зрения интереса, времени, денег или ресурсов) сконцентрироваться на одной из сфер (приложениях), а веб отдать партнеру\коллеге\фрилансеру\работнику.
    Просто потому, что пользы будет больше.
    Ответ написан
  • Как решить Tower Defence игру?

    @azShoo
    Вам нужна книга мат.моделирование для чайников.
    В целом, одним экселем вам не обойтись, как и одним ответом на тостере.
    Если максимально все упростить, то вам нужно:
    Составить модель стороны защиты:
    - Схему самой локации
    - Схему расположения башен
    - Карты урона (зоны покрытия башен, в зависимости от range и dps\dpt)

    Составить схему стороны атаки:
    - Точки респа и "пути" для юнитов.
    - Список и юнитов.
    - Расчитать КПД для каждого типа юнитов (сколько живет в той или иной зоне урона, сколько успевает пройти\нанести урона в той или иной зоне урона и пр.)

    Дальше наложить эти показатели друг на друга и смоделировать сражение.
    Если потенциальное время жизни юнитов в данной зоне урона больше, чем время необходимое на нанесение урона > чем HP башни -> башня разрушена.
    (учитываем планомерную смерть юнитов и соответствующее снижение DPS\DPT)

    Ну, а дальше все упирается в сложность\нелинейность логики и возможность макро- и микро-контроля со стороны игрока.
    Ответ написан
  • Есть ли потребность в социальной сети для студенчества и вообще обучения?

    @azShoo
    Скажите, найдет ли свою аудиторию проект? Есть потребность?

    И аудитория, и потребность у этой аудитории напрямую зависит от того, что вы хотите предложить.
    Если просто "добавляшки в друзья", чатики по группам, выкладывание лекций и домашек в файлообменник и расписание занятий - то таких проектов хватает.

    Факт 1:
    Вам нужно предлагать пользователю что-то, чего он не может\не удобно делать в VK.
    В противном случае - выберут VK, так все зарегистрированы по умолчанию.

    Факт 2:
    Вам нужно иметь конкурентное преимущество перед другими проектами в нише. Гуглите 4-5 существующих проектов, смотрите что умеют, чего не умеют.
    Вам нужно сделать больше и лучше, в разных пропорциях. Или 20% уникального функционала, 80% на усовершенствование существующих аналогов. Или наоборот, или поровну.

    В целом, надо понимать что почти в любой нише сейчас есть минимальная, но все таки конкуренция. Вопрос "взлетит или не взлетит" упирается в то, сможете ли вы предложить что-то, ради чего пользователю надо будет идти именно к вам.
    Ответ написан
  • Как протестировать динамический элемент в веб-интерфейсе с Selenium?

    @azShoo
    Самый простой вариант - передавать "движение вниз" по вариантам дропдауна с помощью send_keys(Keys.ARROW_DOWN) до тех пор, пока не сработает флаг isDisplayed() на нужном вам элементе.
    Ну, а дальше клик. :)
    Ответ написан
  • Время начала разработки по методологии Agile начинается когда уже проект продуман и расставлены задачи? или вообще с голой идеи до MVP за 2-3 недели?

    @azShoo
    Время разработки начинается с "открытия" спринта. Спринт открывается, когда сформированы и поставлены задачи на первый спринт. (Ну, и далее - > после окончанию предыдущего. )
    Формально, у нас есть голая идея самого проекта - глобальное представление, что должно получиться.
    Есть некий роадмап по его развитию, где для каждого этапа реализации есть свои цели и задачи.
    Старт первой итерации (которая умещается или выходит за рамки первого спринта, но начинаются они одновременно) - фактический старт разработки.
    Для того, что бы получить спринт, нужно иметь представление о том, какой функционал будет реализован в рамках этой итерации, и иметь всё необходимое для разработки этого функционала.
    А дальше, все уже зависит от проекта и особенностей процесса.
    Например, не-наукоемкий стартап без жесткой привязки к макетам может стартовать первый спринт с посадочной страницы, и для этого, по сути, нужно 3 таски в форме:
    1) Фронтент - сделать посадочную страницу, с необходимыми элементами (картиночки и тексты в аттаче)
    2) Бэкенд - организовать обработку данных с формы регистрации на посадочной странице.
    3) Задеплоить, развернуть.
    Все.

    Если проект наукоемкий или в первую итерацию заложен значительный функционал - то к моменту разработки логично иметь описание\исследование\тз, дабы разработчик знал, что от него требуется.
    Ответ написан
  • Как сделать, чтобы при запуске, экран поворачивался ?

    @azShoo
    Вам нужно закрепить экран на вращательном сервоприводе и запитать его от блока питания вашего компьютера. Ах, хотя приложения... Тогда не важно, можно и отдельно.
    Дальше нужны, думаю, драйвера и сенсор состояния, что бы ваш компьютер ненароком не взлетел а-ля геликоптер на бесконечно вращающемся экране.
    Ну а далее bool isActive, if true -> rotateClockwise, else -> rotateCounterClockwise

    Но в целом как-то так.
    Ответ написан
  • Подойдёт ли 4s для iOS разработки?

    @azShoo
    Подойдет, но исключительно "на старте", приведенные выше айпэды и айподы так же подойдут.
    В целом же, если говорить о "серьезной" разработке - то нужны целевые девайсы, причем в живом виде.
    Учитывая фетиш эппл-пользователей на новую техницу, последняя линейка нужна.
    Ответ написан
  • Какой софт существует в помощь QA для визуальной проверки страниц?

    @azShoo
    Первое, что должен сказать, мне кажется вы смотрите немного не в ту сторону.
    Если вопрос стоит как "QA не успевает" - вам нужно автоматизировать наиболее ресурсоемкие (с точки зрения тестирования) тест-кейсы, к которым непосредственно верстка относится очень косвенно.

    Теперь по инструментам.
    Есть автотесты. Например, Selenium. Автотесты штука довольно универсальная и масштабируемая, но к проверке верстки их прикручивать довольно бессмысленно (хотя и можно).
    Селениумом, как правило, имеет смысл проверять непосредственно наличие элементов, взаимодействие с ними и их работу.
    (Напр. ввел номер телефона -> появилась следующая въюха, но проверять расположение въюхи селениумом - дело не благодарное).
    На мой взгляд - это оптимальный вариант, т.к. пройтись по страницам и проверить, что нет "уехавших" или расползшихся элементов - не занимает много времени. Много времени занимают именно функциональные кейсы.

    Второй вариант больше похож на то, что вы искали. Это т.н. "скриншотное" тестирование, например Sikuli. В общих и упрощенных чертах - загружаете скриншот страницы, урл, Сикули проверяет соответствие одного с другим.
    Минусы? Псевдосрабатывания и бесконечный ад обновлений при динамично меняющемся интерфейсе.

    В общем, мое имхо, как тестировщика, автоматизация непосредственно верстки имеет смысл тогда, и только тогда, когда есть хорошее покрытие регрессионными и интеграционными автотестами, и по сути автоматизировать больше нечего.
    Ответ написан
  • Можно ли обойти gameguard?

    @azShoo
    Обойти можно любую защиту.
    Нет такой системы защиты, которая не могла бы быть "сломана" тем, или иным способом.
    Вопрос в:
    а) Сложности
    б) Целесообразности
    в) Полезности

    Но, как это сделать вам никто, конечно же, рассказывать не будет.
    Те, кто уже сделал это самостоятельно или используют это сами, или разрабатывают на основе этого ботов и прочее добро и продают.
    Те, кто могут, но им это не надо - просто потому, что им это ненадо.
    Ответ написан
  • В каком языке программирования легче всего писать тесты?

    @azShoo
    На почти любом языке можно комфортно писать тесты, фреймворков и библиотек для этого дела навалом.
    Например: пайтон - pyunit, py.test, robot framework, selenium
    C# - тот же селениум, nunit, тестнг.
    Тесты на Javа, как уже говорилось выше, тоже вполне просто пишете.

    В общем тут скорее надо выбрать язык, который вы знаете\вам нравится\хотелось бы изучить по каким-то причинам\на котором удобнее реализовать нужную вам функцию, а дальше нагуглить фреймворк для юнит-\авто- тестов на данном языке.
    Ответ написан
  • Как можно улучшить процесс тестирования сайта?

    @azShoo
    Все зависит от того, что хотите улучшать.
    В отрыве от существующих проблем есть, фактически, следующие направления:
    1) Оптимизация и распаралелливание выполнения тестов.
    Цель - делать тестовые прогоны быстрее.
    Способ - рефакторинг, параллельные запуски, оптимизация с точки зрения тест-дизайна.

    2) Оптимизация тестового набора: или в ширь (увеличение тестового покрытия) или в глубь (большее количество тестовых данных и тестовых сценариев)
    Цель - ловить больше дефектов.
    Способ - оптимизация тест-дизайна, генерация новых тестовых данных.

    3) Стабильность и поддерживаемость. Опять же рефакторинг и оптимизация.

    4) Юзабилити. Прикручивание автотестов к билдпланам, генерация отчетов об их прохождении, генерация дефектов в багтрекере при падениях и прочее.
    В общем более плотная интеграция с остальной тестовой инфраструктурой.

    Это так, на вскидку.
    В целом что бы сказать "куда развивать" нужно понимать, чего нехватает.
    Тесты не стабильны (псевдо-падения) -> рефакторить, пропускается много багов по покрытыму функционалу - > допиливать тестовый набор\тестовые данные, много времени тратите на анализ результатов прогона и заведение багов - оптимизировать генерацию отчета о тестировании, делать авто-репорт в багтрекер.
    Опять же, если на проекте часто актуальны баги типа "правили в одном месте - отвалилось в другом" - нужно максимально актуализировать скорость прогона и прикручивать к билдплану проекта. Запушили изменения - запустились тесты.
    Ответ написан
  • Разработка приложения для iOS - с чего начать?

    @azShoo
    1. Как вы считаете, кого не хватает в команде?

    Стандартный "стартап" комплект это:
    1) Идеолог (продакт оунер, евангелист и вообще основной идейный лидер)
    2) Технолог (человек, занимающийся реализацией - разработкой, взаимодействием с подрядчиками, принятием решений в области реализации)
    3) Бизнес (человек, занимающийся бизнес вопросами - продвижением, внутренней огранизацией, партнерами, инвесторами и прочими.

    В некоторых случаях роли могут объединяться, где-то делиться на N человек и т.д.

    2. 30% от общей прибыли за программинг - это не много? Каков адекватный процент по вашему мнению?

    Адекватный процесс соотносится с вкладом человека в продукт.
    Распределение долей зависит от вклада каждого из участников. Если человек просто пишет код по поставленной ему задаче, в рамках уже определенной реализации, по макетам и ТЗ - 30% это много.
    Если человек берет на себя техническую реализацию (читай воплощение "идеи" в жизнь) - проработку логики, выбор инструментов и технологий, проектирование и создание инфраструктуры и т.д. и т.п. - то разумно деление в равных долях.

    3. Так же, каков реальный процент, который можно предложить человеку, который будет заниматься помощью с выводом приложения на рынок?

    Аналогично пункту 2, зависит от того, что может предложить человек.
    Сама идея приложения не стоит ничего. Идея и дизайн - так же довольно мало. Основные факторы что бы взлететь это 1) грамотно реализовать, 2) грамотно "продвинуть".
    Если все, что может предложить ваш "продажник" - это реклама в паблике в ВК и рекламные посты на хабре, то 30% за его участие в проекте это слишком.
    Если он берет на себя обеспечение нужных связей, общение с инвесторами, вывод на рынок, пиар продукта в нужных кругах, построение правильной продуктовой и пиар политики и прочие бизнесовые вопросы - то он заслуживает равный с другими основателями кусок пирога.
    Ответ написан
  • Где взять информацию по игровому балансу?

    @azShoo
    Вопрос из цикла "откуда взять информацию по программированию".
    По геймдизайну масса информации в этих ваших интернетах.
    В целом, путь к построению баланса примерно таков:
    1) Отыграть миллион часов в игры нужного вам жанра. В разные - топовые в своем сегменте, "середнячки", провальные, инди и пр.
    Не просто залипать на экран, а вдумчиво разбираться в особенностях игры - куда игровой баланс ведет пользователя, где создаются точки потребности, и все такое прочее.
    2) Найти от 3 до 12 тематических порталов, всякие dtf, инди-геймдев и etc.
    Почитать мануалы. Да, да. Не вваливаться на борду с тонной вопросов в надежде услышать единый how-to, а въедливо читать мануалы по геймдизайну для новичков, ответы на схожие вопросы, обзоры и прочее.
    3) Скачать полгига книг, лекций, обзоров, статей и прочего. Книг по геймдизайну относительно мало, но при умении пользоваться гуглом они находятся очень быстро. Так же обратите внимание на видео-лекции, программы курсов по тематическим специальностям и прочему.
    В общем тэг "Game Design" вам в помощь.
    4) Проанализировав все написанное создать прототип и прорабатывать детали, отсекая ненужное. 5) Написать более-менее примитивного бота под вашу механику, и запускать игры bot vs bot до бесконечности.
    6) Опробовать на себе, коллегах, товарищах.
    7) Проанализировать результаты п.5 и п.6, и переделывать пока вас не будет устраивать результат.
    Ответ написан
  • Возможно ли симулировать сеть или сервер Apple, чтобы послать сигнал разблокировки iPhone?

    @azShoo
    А вы разве не слышали?
    iДевайсы с последней версией iOS автоматически анлочатся, если их заряжать через микроволны на часоте 800-1200 около полутора минут.
    Я себе атк пару айфонов уже разлочил, все что нужно - самая примитивная микроволновка.
    Хотя, если что, мультиварка тоже сойдет.
    Ответ написан
  • Есть ли хорошие книги на русском по программированию Java + IDE NetBeans?

    @azShoo
    Книг по Java масса, зависит от пожеланий, интересных тем и предпочтений к формату текста.
    Начиная от o`Reily "Изучаем Java", "Java, полное руководство" (Шилдт) и упомянутой выше Философии.

    Можете не привязываться к среде разработки (нетбинс), от любых других IDE он слабо отличается.
    Ответ написан
  • Как набирать аудиторию на свой сервис и сколько это стоит?

    @azShoo
    Тут, по сути, стоит несколько последовательных задач:
    1) Первоначальное наполнение контентом.
    Если речь идет о контентном сервисе (напр. блогоферме, вроде жежешечки), то пользователю не интересен "пустой" портал.
    Следовательно надо "налить" первоначального контента.
    Это можно делать самому, если позволяют ресурсы, либо, что оптимальнее - привлекать сторонних авторов. Сёрфите аналогичные по тематике порталы, ищете интересных вам авторов, связываетесь и предлагаете сотрудничество.
    В зависимости от автора, объемов необходимого контента и тематики - расценки будут меняться от минимальных до заоблачных.
    Многие площадки злоупотребляют кросс-постами (тянут и ре-постят посты с других источников), но тут стоит понимать, что при отсутствии уникального контента привлечь аудиторию будет сложнее.

    2) Когда первоначальный контент сформирован - привлечение первого круга ЦА -> здесь уже идет чистый SMM. В помощь - опять же договоренности с авторами на платные посты, кросс-посты в тематических соц.сетях, всяческая пиарщина. Опять же все зависит от тематики.

    3) Удержание и преувеличение аудитории. Когда первая волна аудитории получена - начинается самый ад. Надо удерживать аудиторию и максимально стимулировать её к шарингу с кругом знакомых. Плюс, конечно же, привлечение новых людей по модели из шага 2.
    Нужно мониторить показатели и при необходимости стимулировать генерацию контента, запускать холи-вары и прочее.

    В целом, этим занимаются целые отделы пиарщиков и SMM-щиков, так что просто так взять и сказать "сделай вот это и все будет ок" - нельзя.

    btw, в первую очередь нужно определиться с:
    1) Целевой аудиторией. Без понимания типичной целевой аудитории делать социальный проект - заранее провальная идея.
    2) Исходя из п.1 определитесь с основными конкурентами за вашу ЦА, заранее выделите популярных авторов и "сердце" данного сообщества. В общем всячески анализируйте конкурентов.
    3) Подумайте, реально подумайте, что вы можете предложить своей ЦА. На мой взгляд, рынок блого-платформ сейчас прибывает в убытке. Большинство блоговых платформ было убито либо соц.сетями, либо лидерами отрасли. Что бы пользователи к вам шли - они должны понимать, зачем это им нужно.

    А дальше скачиваете гигабайт книжек по тэгам "Продвижение проектов", "SMM" и прочее, выкидываете оттуда 90% воды, вычерпываете 10% полезных мыслей и стараетесь остаться после этого на плаву.
    Ответ написан
  • Реализация проекта в вебе и автоматизация тестирования, с чего начать?

    @azShoo
    Беритесь за Python, он отлично подходит для обеих целей.
    Для разработки собственных решений пайтон хорош, потому что:
    1) Низкий порог входа - простой и понятный синтаксис, куча обучающего материала.
    2) Тысяча реализованных библиотек, которые пригодятся в своих веб-проектах.
    3) Джанго в качестве фреймворка для веб.

    По автоматизации на питоне литературы и всяческих обучалок тоже достаточно.
    Естественно, разработка на пайтоне и написание автотестов на оном - совершенно разные вещи, тем не менее, общая база в виде ЯП и использования общих библиотек вполне могут помочь в том, что бы освоить оба аспекта сразу.

    Касательно литературы об обучении. Для основ питона я бы посоветовал codecademy, а дальше книжки и\или видеогайды по вкусу. В любом случае этого добра в интернетах навалом, просто используйте гугл.
    Ответ написан
  • Генерация контента или общение. Что стимулировать в соцсети?

    @azShoo
    Я бы сказал, что стимулировать генерацию контента важнее (хотя безусловно, нужно поддерживать оба аспекта).
    Прежде всего потому, что появление нового контента (считай информационный повод) - само по себе является стимулом для его (контента) обсуждения, как в форме "написал коммент и ушел", так и в форме разгоряченных холиваров с другими участниками.
    Так же стоит учитывать, что наиболее популярным паттерном поведения для нового для пользователя портала является вышеупомянутое "оставить коммент и уйти".
    Пользователь потребляет контент и, как максимум, оставляет один-два комментария к наиболее интересным для него новостям.
    Если контента генерируентся мало - шансов, что пользователь найдет тему, на которую захочет высказаться - мало, что в итоге скажется на том, что после первого-второго-возможно даже третьего захода пользователь поймет, что делать тут больше нечего и станет мертвым.
    Ответ написан
  • Как можно протестировать верстку сайта во всех размерах и браузерах?

    @azShoo
    Вариантов довольно много, на самом деле.
    Тут нужен ряд уточняющий вопросов:
    1) Вам нужно проверять _регулярно_ или единоразово (сдаешь проект - проверил - забыл)?
    2) Какие браузеры и разрешения вам реально нужны? Тут надо определить две вещи:
    Под какие браузеры вы разрабатываете, и готовы обеспечивать поддержку, и нужно ли это вашим пользователям? Первое определяется исходя из ваших ресурсов, второе - исходя из статистики посещений сайта и прочего.
    Поддерживать "ВСЕ БРАУЗЕРЫ" и "ВСЕ РАЗРЕШЕНИЯ!!" - бессмысленный кейс. Вы потратите много времени на поддержку древних браузеров и разрешений, существующих на двух нетбуках в мире, но не получите ничего.
    3) Сколько вы готовы тратить времени, сил и денег на подобные тесты?
    4) Какая "погрешность" в результатах тестирования вас устроит?

    Вариант 1) Виртуалки. Много разных, с разными версиями браузеров, осей и пр.
    Разрешения экранов там отлично настраиваются, масштабируется все соответственно.
    Плюсы:
    - Высокая вероятность воспроизведения багов с реальных устройств.
    - Кастомизируемость - все, что нужно сделать, это развернуть N виртуалок, и накачать на них нужные вам версии браузеров.
    Минусы:
    - Миллиард виртуалок, которые надо создать и актуализировать.
    Вариант 2) Специализированные сервисы. Упомянутый выше BrowserStack и прочее.
    Аналогичные сервисы есть и для мобильных и MacOS устройств отдельно.
    Плюсы:
    - Простота - купил, открыл, проверил.
    Минусы:
    - Низкое соответствие. Часто вместо реальных старых версий используются "эмуляторы" старых версий, которые выдают ложные результаты.
    - Далеко не везде можно прописать хосты и прочие радости для доступа к "внутренним" стендам.

    Ну, и отдельно стоит упомянуть, что если смотрите сервис для тестирования на мобилках и MacOS - ищите те сервисы, которые предоставляют доступ к "железным" машинам, а не эмуляторам.
    Эмуляторы - плохой вариант.

    Вариант 3) Собственный "зоопарк" устройств.
    Особенно актуально для мобильных устройств. В большинстве случаев проще завести свой парк устройств, к которым настроить доступ "из вне". Для этого, тоже, кстати, есть готовые решения.
    Плюсы:
    - Реальное железо = реальная работа этого железа, а не псевдосрабатывания эмуляторов.
    - Кастомизируемость - только то, что нужно, и настроенное так, как надо.
    Минусы:
    - Дорого.
    - Необходимо постоянно пополнять "коллекцию" устройств.

    Ну, или отдать на откуп индийским аутсорсерам.
    Ответ написан
  • Как организовать структуру игры?

    @azShoo
    Могу ошибаться, т.к. в целом на данный момент экспериментирую в том же направлении.
    Для себя реализовал это примерно следующим образом:
    1) GUI - видимо то, что вы понимали под "экранами". Графический интерфейс с отрисовкой и точками входа для действий пользователя (KeyListener и иже с ними). Никакой логики здесь нет, только соответствующая отрисовка.
    2) Engine, грубо говоря - "движок": здесь содержится вся игровая логика. Карты, юниты, итемы, состояния и прочее. Все взаимодействия между объектами и экземплярами классов - описаны здесь.
    3) Непосредственно Game - непосредственный "поток", включаемый по запуску приложения, который обуславливает взаимодействие GUI и Engine. Здесь инициализируется запуск Engine и GUI, а дальше по мере получения информации от движка и\или "экранов" - нужным образом обрабатывается взаимодействие.

    Но, как я уже говорил, на правильность подобного деления не претендую.
    Ответ написан