Хватит менять размер окна браузера, хватит его насиловать! Готов спорить, вы не раз слышали это. Хорошо, возможно и не слышали. Но если вы профессионально занимаетесь разработкой адаптивных сайтов, вы понимаете о чем я: любое изменение DOM или правка CSS, и вы снова начинаете тянуть край браузера вперед, назад, тестируя изменения и просматривая ничего ли не сломалось.

Целью ваших движений является имитация экранов различных устройств.

В корпоративной среде зачастую, у вас есть множество гаджетов предоставленных компанией для теста. На моей работе в моем распоряжении есть iPad, iPod, другие планшеты, ноутбуки, а также настольные мониторы. Если у вас нет такой роскоши, приходится использовать то, что под рукой.

К счастью, есть внушающий набор онлайн инструментов, имитирующих различные диагонали устройств. Конечно, каждый из них имеет свои преимущества и недостатки, мы рассмотри несколько таких инструментов.

Для тестирования я выбрал реально адаптивный сайт PajamasOnYourFeet.com, сайт построено на основе HTML5 шаблона, бесплатно предоставленным EGrappler.

Disclaimer:
Данная статья представляет собой вольный художественный пересказ-перевод первой главы книги "App Savvy
Turning ideas into ipad and iphone apps customers really want"

Она может заинтересовать людей, которые только приходят в мир мобильной разработки, и думают, с чего им начать. Если вы опытный бизнесмен, уже имеющий стабильный доход от собственных мобильных приложений — скорее всего, она покажется вам бесполезной и очевидной.


Чтобы полностью оценить жизнеспособность идеи вашего приложения, сначала вы должны понять текущую ситуацию с приложениями в App Store, оценить стоимость запуска вашего приложения, и реалистично смотреть на возможность попадания вашего приложения в каталог App Store. Под «вами» и «вашей идеей» я подразумеваю не только лично вас, а всех людей — родственников, друзей и коллег — с которыми вы прорабатываете вашу идею. Оцениваете ли вы идею в одиночку, или с кем-то, я хочу предложить вам схему, следуя которой вы сможете получить более структурированную оценку вашего приложения. В конце статьи будут приведены ссылки на полезные ресурсы и инструменты, которые помогут вам оценить вашу идею.

Скорость загрузки любого сайта во многом зависит от количества и качества используемых изображений. Поэтому очень важно уметь их оптимизировать. Существует множество веб сервисов для этого, но большинство из них обладает недостатками:

• Нет возможности оптимизировать автоматически много файлов
• Сложно и неудобно использовать в рабочем процессе

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

Оптимизация изображений с помощью командой строки

Для каждого png файла используются optipng и pngcrush, а для jpg — jpegtran. Для начала опробуем optipng:

От переводчика

Это перевод статьи Drew Crawford «Why mobile web apps are slow», опубликованной 09 июля 2013. Статья очень интересная, но большая — ошибки возможны — прошу простить и присылать замечания в личку.
Поскольку затронута острая тема, прошу заметить, что переводчик не обязательно разделяет мнение автора статьи!
При переводе текст слегка видоизменялся, поскольку прямой перевод не всегда понятно передает смысл. Для перевода термина «native code» был использован англицизм «нативный код», который понятнее и короче, чем «родной для платформы код». Термин «word processing» переводится как «верстка текста», хотя это немного сужает первоначальный смысл. Термин managed код («управляемый код») не был переведен, так как удачного перевод (на взгляд переводчика) не существует. Под «терминированием» приложения подразумевается его принудительное завершение операционной системой.
Повествование в статье ведется от первого лица: автора статьи.

Здравствуйте, пользователи Хабрахабр. Несколько дней назад я получил на тест 2-е поколение Nexus 7. Мне попалась модель на 16 ГБ без LTE.

С первых минут использования стало ясно, что обновленная «семерка» это претендент на звание лучшего 7-дюймового планшета на Android.

3. Прототипное наследование

До сих пор мы рассматривали, как определяются методы в объектах и как их повторно используют в других объектах при явном указании контекста, но это — всё же не лучший путь использования и расширения объектов.

Далее в игру вступает наследование. Оно лучше разделяет понятия, когда объекты наделяются своими методами на основе методов других объектов.

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

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

Среди звеньев цепочки эффективных интернет продаж, звено “маркетинг и предложение” пожалуй является самым неочевидным и недооцененным.

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

Проблемы git-flow

Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю о git-flow. Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится чем-то вроде стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба

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

Инструментирование JavaScript кода может понадобиться по целому ряду причин. Наиболее распространные: отладка, профилирование, трассировка, логирование. Как правило, движки в которых выполняется JavaScript предоставляют способы инструментирования кода без его изменения. В своей прошлой статье я описал некоторые средства которыми это осуществляется, а тажке существующие ограничения, в конечном итоге сподвигшие меня на начало описанного в той статье проекта и изучение вопроса инструментирования JavaScript путем автоматического изменения кода. Эта тема на мой взгляд обделена вниманием, но заслуживает раскрытия, тем более в комментариях был выражен интерес к концептуальному подходу модификации кода.

Многие инвесторы отказываются инвестировать в игровые стартапы из-за характера рынка игр — никогда не уверен, взлетит игра или нет, заработаешь ли ты, вернешь инвестиции или уйдешь в минус. «Индустрия игр завязана на хитах, это не бизнес, это удача», — часто приходится слышать от ИТ-инвесторов и бизнес-ангелов.

Действительно, рынок игр, а точнее, рынок мобильных казуальных игр развивается стремительно и быстро, появляются новые типы геймеров, меняются потребности и желания игроков, двигаются тренды игровой механики. И все же у опытных разработчиков и паблишеров получается понимать рынок, своего пользователя, выпускать новые всеми любимые хиты (маркетинговые бюджеты… маркетинговые бюджеты… ну да, не без них…). Но это на Западе…

Первая статья из цикла «Теория магии» носит обзорный характер. Ее цель — сформулировать основные вопросы рассматриваемой дисциплины преимущественно на качественном уровне, а так же разъяснить, какие принято выделять субдисциплины, и как аспекты, находящиеся в центре их внимания, связаны между собой.

Годами я использовал Chrome DevTools, Firebug и даже Opera Dragonfly для отладки, трасировки и профилирования моего JavaScript кода. Замечу, что использовал эти замечательные инструменты не только для работы с JavaScript, но и для отслеживания событий сети, отладки CSS, работы с DOM.

Однако иногда я попадал в некие зоны отчужднения, в которых приведенные выше инструменты помочь мне не могли по определенным причинам, а хотелось бы.

Меня зовут Дмитрий Астапкович, я являюсь руководителем команды кат-сцен Allods Team. В данный момент мы занимаемся созданием видеороликов для проекта Skyforge. В свое время я работал над большим количеством различных проектов: American Chopper 2, Biker Mice from Mars, Coded Arms: Contagion, Hot Brain, Insecticide и Prime World. В этой статье я расскажу о различных типах роликов и трудностях, с которыми сталкиваются разработчики в процессе создания кат-сцен.

Время идет, игры развиваются, и мы видим все более красивую картинку, слышим более яркие звуки и погружаемся во все более реалистичные игровые вселенные. Наше поколение еще помнит «Марио» и подобные игры, но покажи современному ребенку такую графику – он, скорее всего, не станет играть. Пользователи разбалованы, и их уже не завлечь стандартным сюжетом о спасении мира или красочными пейзажами. Война за внимание потребителей идет на более тонком уровне, и выигрывает ее тот, у кого получается вовлечь игрока в геймплей максимально глубоко.

Мы продолжаем цикл статей о том, как подключиться к бортовой системе своего автомобиля (см. Часть 1 и Часть 2 ) и сегодня расскажем как считывать данные.

Предполагается, что к текущему моменту у нас есть машина с диагностическим разъемом, отвечающим OBD-II стандарту, любимое мобильное устройство (ноутбук, смартфон, планшет) и адаптер на базе ELM327, который позволит соединить машину и мобильное устройство.

Как уже говорилось в предыдущей части, независимо от типа связи между мобильным устройством и адаптером (Bluetooth, Wi-Fi, USB) на логическом уровне, — это последовательное соединение. На программном уровне необходимо открыть Socket соединение между компьютером и адаптером поверх имеющегося соединения нижнего уровня. Практическая программная реализация будет зависеть от операционной системы и типа соединения, примеров можно найти массу под все ваши любимые языки программирования. В качестве базового примера можно брать реализацию соединения на примерах чат-программ для Bluetooth или TCP\IP. В данной статье мы не будем останавливаться подробно на реализации такого соединения, для экспериментов нам хватит возможностей имеющихся программ а-ля Telnet, для экспериментов под Андроид и iOS мы встроили простую командную консоль в наше приложение OBD Car Doctor.

«Ага!», подумал я, когда прочитал у Paul Tyma про то, что строить бизнес на продаже средств разработки, может быть не самой лучшей идеей.

Пол высказал мысль, что разработчики привыкли к тому, что большинство средств разработки доступно бесплатно, а значит продать разработчикам что-либо может быть сложно. В некоторых областях, таких как Java-разработка, якобы вообще не принято ничего покупать. С другой стороны, разработчики для Windows / .NET более склонны платить.

Когда я работал программистом, ко мне нередко подходили с просьбой помочь сделать проект за долю. В некоторых я участвовал. Но очень мало проектов взлетело.
Со временем я стал менеджером проектов, а люди все так же подходят. И сами вокруг делают стартапы. Взлетают единицы.
Почему же?


Быстро разбогатеть и уплыть на собственный остров просто, увы, лишь в мечтах.

Ответ, увы, кроется не в идее, реализации и даже не в рынке. Дело только в голове создателя стартапа. А точнее, в мифах, которыми она полна.

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

В этой статье я собрал одни из самых часто встречаемых мифов. И написал их опровержение, вкупе с реальными кейсами, как на самом деле нужно мыслить и действовать.

Эта статья предназначена для людей, которые хотят заняться (либо недавно занялись) геймдевом, но не имеют практического опыта в этой сфере. Здесь я поделюсь своим собственным опытом и расскажу основное из разных сфер разработки игры от дизайна интерфейсов до монетизации. Конечно, каждая из рассматриваемых тем достойна отдельной статьи, а в некоторых случаях – это целая наука, по которой пишут книги, и раскрыть их полностью в рамках одной статьи невозможно. Я лишь остановлюсь на основных моментах, приведу несколько примеров, чтобы дать вам отправную точку для вашей работы, акцентировать ваше внимания на важных нюансах, чтобы сэкономить ваше время. Итак, приступим.

Некоторое время назад промелькнула на Хабре вот эта статья о запуске игры. В ней автор делится своим опытом создания первой игры и публикации ее через издателя. На тот момент моя игра уже была выпущена и находилась в GooglePlay около месяца. Правда, я выбрал самостоятельный вариант публикации без какой-либо помощи издателей. А поскольку опыта в этой области у меня не было совсем никакого, то я сделал целый ряд ошибок, которые, по-моему, снизили и так небольшие результаты. Вот об этих ошибках, а также о детальной статистике на текущий момент, я и хотел бы рассказать…

Сегодня довольно много программистов думают о том, чтобы создать мобильное приложения, заработать свой первый миллион, сыскать славу успешного разработчика и продолжать работать над своими интересными и многообещающими проектами. Многие не только думают, но и принимают попытки, успешные и не очень. Так вот я не исключение и об одной такой попытке, приобретенном опыте и небольшом финансовом профите я и хочу рассказать.