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



Для таких целей подойдет оценка медианы. То есть такая статистика, что половина значений выборки меньше, а половина больше. Более формально: упорядочим значения выборки по порядку и выберем среди них с порядковым номером . У такой оценки есть несколько преимуществ. Она менее подвержена влиянию ошибочных данных, значение всегда будет из того множества, что встречалось в выборке, но есть и неприятные недостатки, главный из них, это сложность подсчета, даже для довольно распространенных распределений не существует общей формулы расчета (точнее есть, но ее сложно применить на практике, смотрите Распределение порядковой статистики).

В данной статье я хотел бы вкратце рассказать про самые последние best practices от Google. Я постарался выделить самые основные моменты, чтобы читатель сразу мог понять, что именно какая-либо фича дает разработчику. Не удивляйтесь, если где-то повторяюсь. Конспектировал + добавлял от себя по ходу просмотров видео в www.youtube.com/channel/UCVHFbqXqoYvEWM1Ddxl0QDg

Также к каждому пункту приводятся все необходимые ссылки для более подробного ознакомления с конкретной best practice.

Содержание:

• Разработка через тестирование – что это?
• Три закона TDD
• Примеры применения
• Преимущества и недостатки
• Литература и ссылки

Разработка через тестирование – что это?

Разработка через тестирование (Test-driven development) — техника разработки программного обеспечения, которая определяет разработку через написание тестов. В сущности вам нужно выполнять три простых повторяющихся шага:
— Написать тест для новой функциональности, которую необходимо добавить;
— Написать код, который пройдет тест;
— Провести рефакторинг нового и старого кода.

Мартин Фаулер

Сегодня завершился финал Яндекс.Алгоритма — ежегодного чемпионата по спортивному программированию, который организует Яндекс. В 2015 году состязание проходило полностью в онлайне — на платформе Яндекс.Контест. Заявки на участие подали программисты из 73 стран. Больше всего участников — из России, Украины, Беларуси, Казахстана, Индии, США, Японии и Китая, но вообще география чемпионата крайне обширна — Бразилия, Индонезия, Перу, Доминиканская Республика, Мозамбик, Сенегал, Каймановы острова. 8,9% зарегистрировавшихся — девушки. Примерно половина всех участников — студенты. Всего мы получили заявки от 3722 человек, из которых до финала дошли 28.

А победителем Яндекс.Алгоритма-2015 стал Геннадий Короткевич. Он по привычке показал лучший результат, решив в финальном раунде пять из шести задач и получив при этом 80 минут штрафного времени. Геннадий занимал первое место в чемпионате Яндекса и в 2013, и в 2014 годах.



Второе место занял Пётр Митричев, а третье — Евгений Капун. Они решили по четыре задачи, при этом Пётр набрал 31 штрафную минуту, а Евгений — 79 минут. Результаты всех финалистов можно посмотреть на сайте Яндекс.Алгоритма.

Задачи для Яндекс.Алгоритма составляет международная команда, в которую входят как сотрудники Яндекса, так и приглашённые эксперты — в том числе победители и финалисты состязаний ACM ICPC и Topcoder Open. И мы по традиции подготовили для вас разборы всех заданий. Решить все из них никому не удалось. Больше всего участников справились с задачей B, а вот задания A и D решило всего по одному человеку.

Многие люди сталкиваются с вопросом покупки или продажи недвижимости, и важный критерий здесь, как бы не купить дороже или не продать дешевле относительно других, сопоставимых вариантов. Простейший способ — сравнительный, ориентироваться на среднюю цену метра в конкретном месте и экспертно добавляя или снижая проценты от стоимости за достоинства и недостатки конкретной квартиры. Но данный подход трудоемок, неточен и не позволит учесть все многообразие отличий квартир друг от друга. Поэтому я решил автоматизировать процесс выбора недвижимости, используя анализ данных путем предсказания «справедливой» цены. В данной публикации описаны основные этапы такого анализа, выбрана лучшая предиктивная модель из восемнадцати протестированных моделей на основании трех критериев качества, в итоге лучшие (недооцененные) квартиры сразу помечаются на карте, и все это используя одно web-приложение, созданное с помощью R.

Началось все с того что Adsense в очередной раз понизил оценку эффективности страниц:

А все мы знаем, что скорость сайта – один из факторов ранжирования в выдаче Гугла.

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

Изначально имеется сайтик со статьями, коих в интернете миллионы: CMS Wordpress 4.2, два десятка плагинов, тема, сверстанная фрилансером и shared хостинг.

Мы продолжаем знакомить вас с лучшими статьями по веб-дизайну. Сегодня мы перевели свежую статью на Medium о создании эффективных посадочных страниц. Перевод выполнен «Я люблю ИП».

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

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

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

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

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

Я расскажу, что вы сами можете сделать уже сейчас, чтобы занять выгодную стратегическую позицию на будущем рынке. И покажу это на примере того, как у нас, еще молодого стартапа, получилось создать совместный с Mail.Ru Group сервис по проверке сайтов на вирусы, который сейчас работает с более чем 1 миллионом сайтов. Итак, пора действовать.

Особенности:

• Около 30 строк обычного JavaScript
• Использованные библиотеки: отсутствуют
• Синтаксис как в Excel (формулы начинаются с "=")
• Поддерживаются произвольные выражения(=A1+B2*C3)
• Обнаруживаются циклические ссылки
• Автоматическое сохранение в localStorage

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

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

В данной статье я постараюсь провести краткий юридический ликбез для разработчиков по некоторым положениям Гражданского кодекса, имеющим значение в контексте деятельности индивидуальных предпринимателей и организаций, применяющих упрощенную систему налогообложения, в работе по договорам с Apple, Google и другими компаниями, а также обратить внимание на некоторые не всегда очевидные налоговые нюансы, которые, как показал личный опыт изучения данной темы, довольно часто ускользают от внимания разработчиков или вызывают множество вопрос и споров.

Прочтите внимательно эту статью, если вы применяете упрощенную систему налогообложения с объектом налогообложения «доход» по ставке 6 процентов и продаете игры или приложения в Google Play, Apple App Store, а также прочий цифровой контент — например, 3D-модели — в Steam, Unity Asset Store или на других площадках, в условиях договоров с которыми фигурируют комиссии, агентские вознаграждения и прочие формы разделения выручки между сторонами.

Из материала вы узнаете:

• Почему разработчику желательно обладать хотя бы базовой юридической грамотностью
• Чем с точки зрения Гражданского кодекса являются игры и приложения и какие права на них есть у разработчиков помимо авторского права
• Что такое агентский договор и почему все это важно при работе по договору с Apple или Google
• Кто такой налоговый суслик и почему он может превратиться в пушного зверя
• Какой «подвох» существует для применяющих «упрощенку» в части определения налоговой базы
• Почему налог на добавленную стоимость (НДС) продолжает преследовать нас, даже когда мы не являемся его плательщиками
• Как, с точки зрения Федеральной налоговой службы, облагаются НДС внутриигровые покупки (InApp Purchases)

Рады поделиться с вами видео докладов с конференции «РИТ++». Отдельным постом выложим видео и слайды с LoveQA митапа.

1.«Реалтайм статистика скорости работы нативных и веб-приложений у реальных пользователей», Павел dpp Довбуш (Badoo).
Рассказали как сделана статистика и аналитика скорости работы (UX) приложений Badoo (Web, Mobile-web, iOS, Android, Windows). Про общие концепции и примеры, что и как измерять. Про то, как собирать данные со 100% пользователей проекта и выдержать нагрузку.
А также о том, как из OpenSource решений собрать систему сбора и визуализации статистики для своего проекта.
Бонус: выложили наше «real user monitoring» решение Jinba в OpenSource.

Я хотел бы рассказать вам об утилите, с которой вы сможете забыть о боли создания документации для Web API. О том как это сделать прошу всех под кат.

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

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

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

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

1. Предыстория

Шел 2006 год. Мой путь системного аналитика начался в очень большой компании с хорошо налаженным жизненным циклом разработки.
Аналитики, менеджеры проектов, программисты, тестировщики, архитекторы работали в компании уже не один год. Задолго до моего появления в команде, в компании был утвержден формат спецификации требований, для всех удобный, привычный и понятный.

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

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

Сложилась ситуация, что участвую в проекте, который работает с достаточно большой нагрузкой. Как уже написал — 36 млн запросов в час. Я много чего прочитал и перепробовал за последний месяц, настраивая сервер; хотелось бы просто сжато и компактно выдать тезисно то, что работает хорошо в такой конфигурации.

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Мы перевели и адаптировали оригинальную подборку книг на тему стартапов. Уверены, что она пригодится как начинающим предпринимателям, так и тем, кто работает над своим очередным проектом.

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

В современных корпоративных реалиях большое количество важной для организации информации храниться в виде так называемых неструктурированных или полуструктурированных данных в виде отдельных файлов и папок на файловых хранилищах, коллекциях сайтов SharePoint, архивов электронной почты на серверах Exchange и т.д. Объем роста таких данных составляет, в среднем, около 30-50% в год. Причем такими темпами происходит не только количественный рост объемов потребляемых для хранений байт (зачастую с приставкой Гига- или все чаще и чаще Тера-), но и качественное увеличение важных или даже жизненном необходимых для компании данных, «размазанных» по одному или нескольким (иногда 20-30) файловым серверам с разными операционными системами, идеологиями хранения и обработки информации (Exchange, SharePoint, Windows, SAN/NAS).

Штрафы за разные нарушения суммируются.

242-ФЗ подсказывает нам, что оператор обязан обеспечить запись, хранение, изменение и извлечение персональных данных граждан Российской Федерации (это всё, что прямо или косвенно относится к субъекту ПДн. И номер телефона, и даже уровень защищенности его данных можно отнести сюда согласно 152-ФЗ) с использованием баз данных, находящихся на территории Российской Федерации. С 1 сентября 2015 года. За использование первичной базы за пределами РФ вам светит относительно небольшой штраф и, что куда хуже, блокировка ресурсов в течение 3 рабочих дней с даты судебного решения. При этом разблокировать доступ и «выйти» из реестра можно будет только по решению суда.