В предыдущей статье я вывел формулу успешности приложения. Под приложением я понимаю простую, казуальную игру, разработанную под iOS. Что-то вроде тетриса, кроссворда, судоку, 2048, японского дурака, косынки. На создание которого уходит неделя программисткого труда. Для проверки формулы необходима достаточно большая статистическая выборка — порядка 10.000 честно загруженных приложений. Я попытался решить эту задачу при помощи обзоров на 4-х русских и 2-х зарубежных площадках. Кроме того, отследил в первой версии программы наиболее популярные нажатия на кнопки, убрал второстепенные элементы управления, учел замечания игроков и получил следующие результаты.

Всем привет!
Хочу начать вольный перевод замечательной книги «Learning Three.js- The JavaScript 3D Library for WebGL». Я уверен, что эта книга будет интересна не только новичкам, но и профессионалам своего дела. Ну не буду долго затягивать вступление, только приведу пример того, что мы совсем скоро сможем делать:

Мы продолжаем рассказывать о технологиях, используемых на нашем сервисе email-маркетинга Pechkin-mail.ru. Одной из ключевых задач любого сервиса, связанного с данными клиентов, является загрузка этих данных на сервис. Для Печкина очень важно быстро и без проблем для пользователя загружать адресные базы, содержащие email-адреса, имена, фамилии и другие дополнительные данные.

Что использовать в качестве инструмента?

В качестве базового стандарта, используемого при импорте адресных баз, мы взяли Microsoft Excel. Объясняется это просто:

• это стандартный инструмент, которым на базовом уровне владеют 100% пользователей компьютеров. Более того, в бизнесе — это де-факто корпоративный стандарт и используется даже, если на рабочих компьютерах Mac или Linux.
• Практически все CRM-, CMS-, облачные или десктопные системы имеют экспорт в Excel или CSV, который простым пересохранением приводится к формату XLS или XLSX.
• Известно также, что “90% ошибок ПО сидит в полуметре от монитора”. Не в обиду будет сказано рядовым пользователям, но мы должны учитывать самый базовый уровень подготовки и тех. поддержке для объяснения достаточно сказать “Загрузите Excel-файл”, а не объяснять процедуру подготовки файла в нужном формате.

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

Яблочный рынок приложений, или Apple App Store, потребляет и порождает деньги. Чем больше Вы вкладываете денег, тем выше отдача. Однако, заработанное не всегда больше потраченного. С недавних пор в моей голове вдруг сформировался типичный график потраченных/полученных средств.



Зеленая прямая — график потраченных денег. На что потраченных? На покупку траффика. В результате Ваше приложение выходит в ТОП100, ТОП25 или (ого!!) ТОП10 США и начинает приносить деньги. Красная линия — это заработанное. Если заработанное больше потраченного, то красная линия на графике выше зеленой и Вы отдыхаете на Гавайях, пересыпая между ладоней белый песок Вайкики.

-Чему равна точка Ж?,- спросит сообразительный читатель.

В 2011 году она равнялась 5000 долларов, этого хватало войти в ТОП10. Приложение приносило не менее 1000 долларов в день. Те времена ушли. Теперь в 2014 году надо потратить 50000 долларов, приложения из ТОП10 зарабатывают в день не менее 10000 долларов в день.

Хочу заметить, что речь идет об успешных приложениях, которые после искусственного прыжка в ТОП, сами начинают поднимать свой рейтинг и держаться на гребне успеха не менее 5 дней. Математически красную параболу можно характеризовать показателем степени. Если показатель степени больше 1 — это круто, Вы и Ваше приложение — молодцы. Если меньше-равно 1 — получаем голубой график и дырку от бублика. То есть, сколько денег не вкладывай — дерево не вырастет.

Как же определить показатель степени для Вашего приложения? Для этого не надо тратить 50000 долларов.
Ловко я Вас заманил под кат?

8 апреля 2014 года в мире высоких технологий случилось страшное — Microsoft наконец официально прекратила поддержку своей самой популярной операционной системы Windows XP. Операционная система осталась без заплаток для угроз нулевого дня, миллионы пользователей оказались в опасности заражения вирусами. Тем не менее, далеко не все спешат переходить на новые версии как этого желает софтверный гигант — кому-то жалко денег, кто-то привык к до боли знакомому интерфейсу и нескучной обоине с зелеными холмами. Намного серьезнее все обстоит в корпоративной среде, где на Windows XP работают тысячи машин, обновление которых выльется в миллионные траты и непредвиденные проблемы с годами отточенным корпоративным софтом.

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

Видео про 8 способов противостояния формуле нужды оказалось неожиданно популярным, набрав 8,000 просмотров за два дня. Мы решили продолжить тему.

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

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



10 реальных ситуаций, которые удалось осветить — под катом:

Приветствую вас, уважаемые хабравчане! Сегодня я бы хотел осветить вопрос рендеринга в веб-разработке. Конечно, на эту тему уже написано много статей, но, как мне показалась, вся информация довольно разрознена и отрывочна. По крайней мере, чтобы собрать всю картину в своей голове и осмыслить её, мне пришлось проанализировать немало информации (в основном — англоязычной). Именно поэтому я решил формализовать свои знания в статью, и поделиться результатом с сообществом Хабра. Думаю, информация будет полезна как начинающим веб-разработчикам, так и более опытным, чтобы освежить и структурировать свои знания.

Данное направление можно и нужно оптимизировать на этапе вёрстки/frontend-разработки, поскольку, очевидно, что разметка, стили и скрипты принимают в рендеринге непосредственное участие. Для этого соответствующие специалисты должны знать некоторые тонкости.

Как-то раз коллеги из отдела HR i-Free обратились ко мне с просьбой написать небольшую статью для молодых специалистов, которые стремятся устроиться в IT-компанию. Причины, побудившие их это сделать в целом понятны, в компании основным нанимателем молодых специалистов является отдел под моим управлением, мы берем только что закончивших вуз ребят (а иногда и студентов последних курсов), и у нас они проходят некий курс «молодого бойца».
Естественно, я не претендую на объективность, а лишь хочу дать несколько советов для тех, кто хочет начать свой путь с работы в IT-компании. Статья выражает сугубо моё мнение о том, как нанимать молодого специалиста, и очень надеюсь, что кому-то из студентов старших курсов сей краткий опус поможет в будущей карьере.
В общем, тех, кому интересно, прошу под кат.

Привет, Хабр!
Одна из главных причин тяжёлых увечий дизайнеров претензий к неопытным дизайнерам от верстальщиков, при получении от них PSD-макетов — это наличие слоёв с заданными режимами смешивания, отличными от normal. Вполне возможно, что скоро это уйдёт в прошлое!

Все последние версии браузеров поддерживают HTML5, следовательно, индустрия находится на пике готовности принять технологию и адаптироваться к ней. Сама технология создана такой, чтобы сделать простым процесс включения и обработки графического и мультимедиа-контента в вебе, без использования третьих плагинов или API. Эта статья расскажет о новых типах атак, которые HTML5 «подарил» миру.

Перевод статьи Ричарда Корнфорда Javascript Closures.

• Введение
• Разрешение имен свойств объектов
  
  • Присваивание значений
  • Чтение значений
  
  
• Разрешение имен идентификаторов, контексты исполнения и цепь областей видимости
  
  • Контекст исполнения
  • Цепь областей видимости и свойство [[scope]]
  • Разрешение имен идентификаторов
  
  
• ...

Введение

Замыкание

Замыкание — это выражение (обычно функция), которое может иметь свободные переменные, вместе со средой, которая привязывает эти переменные (т.е. “замыкает” это выражение).

Замыкания относятся к наиболее мощным особенностям ECMAScript (javascript), но они не могут быть применены должным образом без понимания. Несмотря на то, что их легко создать, даже случайно, их создание может иметь пагубные последствия, в частности, в некоторых относительно распространенных окружениях браузеров. Чтобы избежать случайных столкновений с недостатками и использовать преимущества замыканий, необходимо понимать их механизм. Это сильно зависит от роли цепи областей видимости в разрешении имен идентификаторов (identifier resolution) и от разрешения имен свойств в объектах.

Самое простое объяснение замыкания в том, что ECMAScript допускает вложенные функции, определения функций и функции-выражения (function expressions) внутри тел других функций. И эти вложенные функции имеют доступ ко всем локальным переменным, параметрам и функциям, находящихся внутри их внешней функции (внешних функций). Замыкание образуется, когда одна из этих вложенных функций становится доступной вне той функции, в которую она была включена, таким образом, она может быть выполнена после завершения внешней функции. В этот момент она все еще имеет доступ к локальным переменным, параметрам и внутренним декларациям функций (function declarations) своей внешней функции. Эти локальные переменные, параметры и декларации функций (изначально) имеют те же значения, которые были во время завершения внешней функции и могут взаимодействовать с внутренней функцией.

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

«Право налогоплательщика избегать уплаты налогов с использованием всех разрешенных законом способов никем не может быть оспорено. Каждый имеет право вести свои финансовые дела таким образом, чтобы свести соответствующие платежи к минимуму…»
Дж. Сандерленд,
Судья Верховного Суда США

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

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

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

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

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

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


Иллюстрация Стивена Резига

Сегодня я вам хочу рассказать о крупной DDOS-атаке, усиленной с помощью тысяч отдельных сайтов на движке WordPress.

Любой WordPress сайт с включенным Pingback (который, между прочим, включен по умолчанию), может использоваться в DDOS-атаке на другие сайты [В конце статьи ссылка на онлайн-сервис для проверки вашего сайта на участие в уже известных атаках – прим. переводчика].

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

История

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

После того, как DNS были перенесены, мы, наконец, увидели, что происходит: это была мощная распределенная HTTP-flood Layer 7 атака, выполняющая сотни запросов в секунду к их серверу. Так выглядели эти запросы:

74.86.132.186 - - [09/Mar/2014:11:05:27 -0400] "GET /?4137049=6431829 HTTP/1.0" 403 0 "-" "WordPress/3.8; http://www.mtbgearreview.com"
121.127.254.2 - - [09/Mar/2014:11:05:27 -0400] "GET /?4758117=5073922 HTTP/1.0" 403 0 "-" "WordPress/3.4.2; http://www.kschunvmo.com" 
217.160.253.21 - - [09/Mar/2014:11:05:27 -0400] "GET /?7190851=6824134 HTTP/1.0" 403 0 "-" "WordPress/3.8.1; http://www.intoxzone.fr" 
193.197.34.216 - - [09/Mar/2014:11:05:27 -0400] "GET /?3162504=9747583 HTTP/1.0" 403 0 "-" "WordPress/2.9.2; http://www.verwaltungmodern.de" 
..

Вы, возможно, заметили, что у всех запросов есть случайный параметр ("?4137049=643182" и др.), благодаря которому запросы обходят кэш и требуют каждый раз полной перезагрузки страницы. Все это очень быстро убивает сервер.

Но самое интересное, что запросы поступают от других ничем ни примечательных WordPress сайтов. Да, другие WordPress сайты посылают множество запросов со случайным параметром и уводят жертву в оффлайн.

Простите, но накипело.
Много шишек уже набито на тему безопасности сайтов. Молодые специалисты, окончившие ВУЗы, хоть и умеют программировать, но в вопросе безопасности сайта наступают на одни и те же грабли.

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


Итак, каким должен быть безопасный сайт?

Австралийский дизайнер Уилл Дэйбл предлагает интересную метафору, помогающую разрабатывать простые и удобные интерфейсы. Разработчику, который знает свою систему вдоль и поперек, и отдаёт работе над ней значительную часть своей жизни, очень трудно представить, как будет работать с ней обычный пользователь, чья голова забита другими вещами. Особенно, если он пробует его продукт первый раз в жизни и ещё не уверен в его полезности. Чтобы представить, что творится в голове у пользователя, Уилл Дэйбл предлагает вообразить, что пользователь пьян. Его внимание рассеянно, он легко выходит из себя, он не слишком отчётливо видит и не очень уверенно двигается — если постоянно помнить об этом, интерфейс получится чище и проще. Суть метода Дэйбл рассказывает в этом пятиминутном ролике:

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

Привет, Хабр! Я Андрей Фролов, ведущий программист, работаю в Mail.Ru над Next-Gen MMORPG Skyforge. Вы могли читать мою статью про архитектуру баз данных в онлайн-играх. Сегодня я буду раскрывать секреты, касающиеся устройства сервера Skyforge. Постараюсь рассказать максимально подробно, с примерами, а также объясню, почему было принято то или иное архитектурное решение. По нашему серверу без преувеличения можно написать целую книгу, поэтому для того, чтобы уложиться в статью, мне придется пройтись только по основным моментам.

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