Что это?

Это очередное AngularJS приложение, которое добавляет в обычную таблицу возможности сортировки, фильтрации, разбиения на страницы и пр.

Разумеется, существует несколько готовых решений (1, 2, 3, 4, 5), но они не подходили по ряду причин. В итоге, было решено создать свой вариант, тем более, что я не имею большого работы с AngularJS, а изучать этот фреймворк и его потрясающие возможности лучше на практике.

Интервью с бывшим сценером, русским, участником топовой crack-группы в середине 2000-х. Вопросов было задано не слишком много, поэтому он ответил на все. Похожие вопросы я объединил, если что потерялось — пишите, добавлю. Структура и принципы работы сцены уже давно известны, поэтому здесь мы их почти не касались, но чтобы заполнить возможные пробелы в ближайшее время я продолжу перевод сайта «aboutthescene», первую часть которого публиковал ранее. Несмотря на то, что было уже много статей про сцену, практически в каждой из них всплывает вопрос, получают ли сценеры какую-то прибыль от своей деятельности. И в этом интервью он снова был задан. Ответ на него и все остальные — под катом.

Код с одной и той же структурой в двух и более местах — верный признак необходимости рефакторинга. Если вам нужно будет что-нибудь изменить в одном месте, то, скорее всего, нужно также сделать то же самое и в других местах. Но есть близкая к 100% вероятность не найти эти места или попросту забыть за них.

Большинство понимает, что многократное повторение кода (или copy-paste) в примере ниже — зло:

Тестирование – очень важный этап разработки мобильных приложений.

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

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

Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.

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

Был недавно на курсах + вчера пересмотрел Фарго.

И захотелось запостить картинку из одного из слайдов с курсов:

Yac 2013 посетил Jason Rudolph из GitHub. Я считаю его доклад про API был одним из самых интересных на конференции. Яндекс обещал выложить в сеть записи, так что советую на досуге посмотреть его всем, кто не видел.

Но речь пойдет не о докладе. На картинке график релизов GitHub на продакшн.



Когда я услышал цифру, я не поверил своим ушам. У GitHub'а сотни обновлений в неделю. В команде около сорока разработчиков и ни одного QA.

К счастью Джейсон после доклада еще какое-то время находился рядом со сценой и я смог расспросить его с пристрастием о том как они это делают.

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

Вопрос

Иногда в жизни бывают ситуации, которые описываются предложениями типа: «я знаю, что ты знаешь, что я знаю… что-то». Представьте себе, что вы испекли вишневый пирог и положили его остывать на подоконнике, а я потом втихаря его съел. Приведем список все более и более сложных предложений, которые все ближе и ближе подводят нас к полному знанию о происходящем. Например,

: «Я знаю, что вы испекли пирог и положили его остывать на подоконник; но вы не знаете, что я знаю». В таком случае, если я съем пирог, то об этом скорее всего никто и не узнает.

: «Я знаю, что вы испекли пирог и положили его остывать на подоконник; вы знаете, что я знаю; но я не знаю, что вы знаете, что я знаю». Если я съем пирог, то это может привести к довольно к щекотливой ситуации для меня.

: «Я знаю, что вы испекли пирог и положили его остывать на подоконник; вы знаете, что я знаю; я знаю, что вы знаете, что я знаю; но вы не знаете, что я знаю. что вы знаете, что я знаю». В таком случае после того как я съем пирог у меня останется надежда вывернуть ситуацию так, что вы не узнаете о моем преступлении.
…

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

Есть ли какие-либо ситуации в жизни, будь-то реальные или искусственные, где переход от к для больших значений может реально повлиять на стратегию действий? А что насчет ? Как такие ситуации моделируются в математике?

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



Вы хотите узнать больше информации о самых действенных методах? Вам интересно, как с помощью маленькой картинки определить разрешение экрана, локальное время и сменить парочку паролей? Добро пожаловать под кат!

Предисловие к переводу:
2-го октября на Хабре была опубликована статья с информацией о задержании владельца Silk Road – онлайн магазина в сети Tor, позволяющего анонимно покупать и продавать за bitcoin различные вещества, запрещенные к свободному обороту. В обсуждении статьи была также приведена ссылка на скан обвинительного акта (PDF, 3.3 MB) от 27.09.2013 г., на 39 листах, в котором живописно изложены злодеяния владельца и администратора Silk Road. Помимо юридической и технической стороны описания злодейств, акт содержит отчет агента ФБР о том, каким образом была раскрыта личность владельца Silk Road Росса Уильяма Ульбрихта (страницы 24–32, параграфы 33-45). Я решил, что было бы неплохо сделать его более доступным русскоязычному сообществу, и вот, перевод этой части обвинительного акта предлагается вашему вниманию.

Про Xperia Z1 начали говорить еще летом (тогда он был известен, как Honami), главным образом, конечно, из-за абсолютно новой 20-мегапиксельной камеры, которой, впрочем, его достоинства вовсе не исчерпываются. Пришедший на смену Xperia Z новый флагман, сохранил все хорошее, что было в его предшественнике и сделал это еще лучше. Предлагаем вашему вниманию подробный обзор новинки от Sony.

Когда проект маленький, особых проблем с ним не возникает. Список задач можно вести в текстовом файле (TODO), систему контроля версий, по большому счёту, можно и не использовать, для раскладки файлов на живой сервер их можно просто скопировать (cp/scp/rsync) в нужную директорию, а ошибки всегда можно посмотреть в лог-файле. Глупо было бы, например, для простенького сервиса с двумя скриптами и тремя посетителями в день поднимать полноценную систему управления конфигурациями серверов.

С ростом проекта требования растут. Становится неудобно держать в TODO-файле несколько десятков задач и багов: хочется приоритетов, комментариев, ссылок. Появляется необходимость в системе контроля версий, специальных скриптах/систем для раскладки кода на сервер, системе мониторинга. Ситуация усугубляется, когда над проектом работает несколько человек, а уж когда проект разрастается до нескольких серверов, появляется полноценная инфраструктура («комплекс взаимосвязанных обслуживающих структур или объектов, составляющих и/или обеспечивающих основу функционирования системы», Wikipedia).

На примере нашего сервиса "Календарь Mail.ru" я хочу рассказать о типичной инфраструктуре и жизненном цикле разработки среднего по размерам веб-проекта в крупной интернет-компании.

Добрый день, хабр!

Я давно плотно работаю с Linux системами, но в качестве десктопа предпочитаю Windows. Но для комфортной работы иногда нужно постараться.

Сегодня я хочу поделится опытом и впечатлениями о том как я пытался найти замену Tmux под cygwin и как я в конце концов победил Tmux и скомпилировал его под Cygwin + Windows. Кому интересно — прошу под кат.

Я, как и любой человек из IT сферы увлекающийся машинами, всегда поражался тому насколько медленно технологии приходят в автомобили. Нет, я сейчас не говорю про всякие там парковочные радары, системы активной безопасности и какие-нибудь модные источники освещения. Я сейчас говорю про развлекательные технологии. Вспомните сколько лет прошло с момента появления iPod'ов до момента, когда штатные бортовые системы стали их поддерживать? USB-носители информации, SD-карты, Bluetooth, Wi-FI, LTE — все это появлялось в машинах очень не сразу и первым делом попадало в модели самого дорогого сегмента.



Но не так давно ситуация стала меняться. Европейские производители сперва разработали каждый свою систему управления бортовым компьютером и мультимедиа-функциями (Command у Mercedes-Benz, MMI у Audi, iDrive у BMW, OnCall у Volvo и т.д.). Затем унифицировали эти систему по всему модельному ряду. А потом стали их «социализировать» посредством Интернета. Конечно, это не ускорит последующего внедрения сетей 5-6 поколений в автомобилях или USB 4.0 и Bluetooth 5.1, когда они появятся. Однако это наверняка позволит сократить пропасть в программном обеспечении между мобильными и автомобильными системами.

Утром 1 октября 2013 года календарь проделанной работы над открытым исходным кодом, расположенный на моей гитхабовской странице, выглядел вот как:



Это не было простой случайностью. Я нарочно решил (руководствуясь GTD-соображениями) достаточно долгое время стараться каждый день чего-нибудь делать на Гитхабе, а затем (если дело пойдёт) поделиться на Хабрахабре наиболее ценными впечатлениями от именно такой манеры работы (назовём её, скажем, calendar-driven development), когда впечатления накопятся.

И поделяюсь.

Я работаю над визуализацией парапланерных соревнований — пишу плеер просмотра гонки для Airtribune.com. В процессе работы мне попадаются интересные и нестандартные задачи. Одна из них — задача быстрой отрисовки маркеров и треков на карте google maps.

Масштабы такие: есть ~200 трекеров в довольно ограниченной области (50x50км), каждый передает данные о своем положении раз в 10 секунд. Нужно их все отрисовать на карте и плавно перемещать при изменении координат. За каждым маркером должен отрисовываться трек. Картинка примерно следующая:



Скоро обнаружилось, что встроенные объекты — google.maps.Marker и google.maps.Polyline — для данной задачи работают слишком медленно. Была куча идей по оптимизации, и в результате получилось решение на canvas-е, которое работает со скоростью 40fps даже на тысяче маркеров. Впрочем, fps вы можете померить сами — я собрал тестовое приложение для сравнения 4-х движков, в котором на лету можно подключать разные фишки и смотреть на скорость работы.

Доброго времени суток, Хабр!

Недавно я озадачился синхронизацией рабочего пространства среди всех используемых мной компьютеров. Я понял, что таскать все файлы и базы данных сайта с одного компьютера на другой, не вариант. Решив автоматизировать этот процесс, я обратил внимание на Dropbox \ Google Drive \ Yandex.Disk \ любой другой облачный диск ( выбрать свой вариант ).

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

Вначале мы бы хотели обсудить, почему в некоторых ситуациях стоит идти к издателю. В нашей статье мы будем рассматривать только f2p-игры, поскольку именно эта модель монетизации приносит больше всего денег в магазинах мобильных приложений. В этом можно убедиться, посмотрев на AppStore Top Grossing US. Картинка ниже.



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

Данная статья является логическим продолжением предыдущей.

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

Для раскрытия понятийного аппарата и определения точки с которой возможно развитие представленной ранее таксономии, необходимо прежде всего ответить на вопрос «Какие признаки игры используются в математической теории игр?».
Характеризующими признаками подобных игр являются:

1. Наличие нескольких участников игры.
2. Неопределенность поведения участников, связанная с наличием у каждого из них нескольких вариантов действий.
3. Различие (несовпадение) интересов участников
4. Взаимосвязанное поведение участников, поскольку результат получаемый каждым из них, зависит от поведения всех участников.
5. Наличие правил поведения, известных всем участникам.

Как мы видим, уже первый признак игры пересекается с вопросом-разветвителем таксономии Кроуфорда — «Наличие соперника», что переносит математические игры в категорию "Конфликт".
Второй признак дополняет данный вывод заявляя, что соперник должен быть действующим агентом, т.к. алгоритмы искусственного интеллекта рано или поздно можно просчитать.
Третий и четвертый признаки не позволяют выйти нам за пределы данной категории, т.к. они одновременно удовлетворяют требованиям категории "Соревнование" и категории "Игра".
Пятый признак соответствует категории "Забава", но т.к. у нас есть признаки категории более низкого класса "Конфликт", то для развития мы выберем именно её.

Типы игр в математической теории игр

— Кооперативные, некооперативные и гибридные игры

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

Слева направо: 1. Настольная игра Dungeons&Dragons 2. Настольная игра Монополия 3. Шутер от первого лица Halo 4. Файтинг Mortal Kombat

Гибридные игры — игры, которые включают в себя элементы кооперативных и некооперативных игр. В таких играх игроки могут образовывать группы, но игра может вестись в некооперативном стиле (к примеру kill stealing в League of Legends).

Скриншот из игры League of Legends

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

Вступительное слово

Считается, что «киллер фичей» СКВ Git является легковесное ветвление. Я ощутил это преимущество в полной мере, ведь я перешел на Git с SVN, где ветвление было достаточно дорогим процессом: для создания ветки нужно было скопировать весь рабочий каталог. В Git все проще: создание ветки подразумевает лишь создание нового указателя на определенный коммит в папке .git/refs/heads, который является файлом с 40 байтами текста, хешем коммита.

Основными командами пользовательского уровня для ветвления в Git являются git-branch, git-checkout, git-rebase, git-log и, конечно же, git-merge. Для себя я считаю git-merge зоной наибольшей ответственности, точкой огромной магической энергии и больших возможностей. Но это достаточно сложная команда, и даже достаточно длительный опыт работы с Git порой бывает недостаточным для освоение всех ее тонкостей и умения применить ее наиболее эффективно в какой-либо нестандартной ситуации.

Попробуем же разобраться в тонкостях git-merge и приручить эту великую магию.

Здесь я хочу рассмотреть только случай благополучного слияния, под которым я понимаю слияние без конфликтов. Обработка и разрешение конфликтов — отдельная интересная тема, достойная отдельной статьи. Я очень рекомендую так же ознакомиться со статьей Внутреннее устройство Git: хранение данных и merge, содержащей много важной информации, на которую я опираюсь.

Дополнение к циклу переведенных статей.
Статьи: 1-3, 4-6, 7-9, 10-13, 14-15

Информация в статье относится к 5-й части руководства.

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

Введение.

Если отталкиваться от обывательской позиции человека, который разрабатывает базы данных, то внешние ключи – это удобно и упрощает жизнь (в большинстве случаев, всегда есть исключения.). Даже будучи невеждой в реляционной теории баз данных, к осознанной необходимости использования внешних ключей, на определенном этапе своего развития, приходит практически любой практик (утверждение — более относится к начинающим), который не стоит на месте в своем развитии и продолжает мыслить. Даже если он еще не знает, что то, что ему нужно называется связью по внешнему ключу, он начинает самостоятельно организовывать данные определенным образом, разбивать на отдельные таблицы и связывать их между собой. Настолько это становится очевидным.
Но при использовании внешних ключей, даже если не знать такого определения, возникает необходимость следить за связываемыми данными. Рассматриваемым объектом данной статьи является, если так можно сказать, своеобразный спутник, который следует за такой организацией данных. И в данном случае уже гораздо полезнее знать теорию, т.к. это может значительно упростить жизнь в процессе работы с базой данных.