Добрый день, дорогие хабра: жители, читатели, писатели, негативно-комментаторы.

В качестве вводной части и чтобы снять некоторые вопросы немного расскажу о себе. Меня зовут Тамара. Оужас, я девушка! Кого это пугает — закрывайте статью и не читайте.

Для остальных: у меня за плечам незаконченный лет 10 назад МИРЭА, факультет кибернетики. Но все эти 10 лет практики сложились таким образом, что по большей части я занималась рекламой и в перерывах случалось работать в различных стартапах, связанных с интернетом и не только.



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

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



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

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

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

EDA – event driven architecture или событийно-ориентированная архитектура. Довольно известный подход к проектированию веб-приложений, который сильно облегчает разработку, когда связанные компоненты находятся на разных ветвях иерархии, делая их связь более прозрачной.

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



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

Чтобы понять, как все это работает, давайте начнем с показателей Stack Overflow. Итак, ниже приводится статистика за 12 ноября 2013 и 9 февраля 2016 года:


Вы можете спросить, почему существенно сократилась продолжительность обработки в ASP.Net по сравнению с 2013 годом (когда было 757 часов) несмотря на прибавление 61 миллиона запросов в день. Это произошло как и из-за модернизации оборудования в начале 2015 года, так и из-за некоторого изменения параметров в самих приложениях. Пожалуйста, не забывайте, что производительность – это наша отличительная особенность. Если Вы хотите, чтобы я более подробно рассказал о характеристиках оборудования – без проблем. В следующем посте будут подробные спецификации железа всех серверов, которые обеспечивают работу сайта.

Итак, что изменилось за прошедшие 2 года? Кроме замены некоторых серверов и сетевого оборудования, не очень многое. Вот укрупненный список хардварной части, которая обеспечивает работу ресурса (выделены различия по сравнению с 2013 годом):

• 4 Microsoft SQL Servers (новое железо для 2-х из них);
• 11 Web-серверов IIS (новое оборудование);
• 2 сервера Redis (новое оборудование);
• 3 сервера Tag Engine (новое оборудование для 2-х из 3-х);
• 3 сервера Elasticsearch (те же, старые);
• 4 балансировщика нагрузки HAProxy (добавлено 2 для поддержки CloudFlare);
• 2 брандмауэра Fortinet 800C (вместо Cisco 5525-X ASAs);
• 2 маршрутизатора Cisco ASR-1001 (вместо маршрутизаторов Cisco 3945);
• 2 маршрутизатора Cisco ASR-1001-x (новые!).

Что нам необходимо, чтобы запустить Stack Overflow? Этот процесс не сильно изменился с 2013 года, но из-за оптимизации и нового железа, нам необходим только один web-сервер. Мы этого не хотели, но несколько раз успешно проверили. Вношу ясность: я заявляю, что это работает. Я не утверждаю, что это (запуск SO на единственном web-сервере) — хорошая затея, хотя каждый раз выглядит весьма забавно.

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

Конечно же, практическая ценность была не в биографии автора, а в запросах, которые отправлялись приложением на сервер.

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

SELECT
    LogTruncations = (
        SELECT TOP 1 SUM(cntr_value)
        FROM ##tbl_cnt
        WHERE counter_name = 'Log Truncations'
    ),
    LogShrinks = (
        SELECT TOP 1 SUM(cntr_value)
        FROM ##tbl_cnt
        WHERE counter_name = 'Log Shrinks'
    ),
    LogGrowths = (
        SELECT TOP 1 SUM(cntr_value)
        FROM ##tbl_cnt
        WHERE counter_name = 'Log Growths'
    ),
    ...

Поскольку их можно написать на порядок проще и сократить логические чтения из таблицы:

SELECT
    LogTruncations = SUM(CASE WHEN counter_name = 'Log Truncations' THEN cntr_value END),
    LogShrinks = SUM(CASE WHEN counter_name = 'Log Shrinks' THEN cntr_value END),
    LogGrowths = SUM(CASE WHEN counter_name = 'Log Growths' THEN cntr_value END),
    ...
FROM ##tbl_cnt

На этом можно было бы и закончить… Но практически под конец я увидел, что приложение вызывает пользовательские хранимые процедуры из tempdb. Поймал себя на мысли: «Когда приложение успело их создать… и главное зачем?»

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Я часто собеседую разработчиков и часто задаю им простой, как кувалда, вопрос — как внутри работает JOIN в SQL? В ответ я обычно слышу бессвязное мычание про волшебные деревья и индексы, которые быстрее. Когда-то мне казалось, что каждый программист специалист должен знать то, с чем работает. Впоследствии жизнь объяснила мне, что это не так. Но мне все еще не понятно, как можно годами теребить базёнку, даже не догадываясь, а что там у нее «под капотом»?

Давайте проведем ликбез и вместе посмотрим, как же работают эти джойны, и даже сами реализуем парочку алгоритмов.

Как известно, в следующем январе сервис Parse будет закрыт. Большинство разработчиков ищут альтернативу для этого сервиса. В одном из проектов guthub собралось достаточно много альтернатив, со ссылками и описанием. Перед вами — перевод этой страницы.

Часть 1: универсальные сервисы

Провайдеры, предоставляющие информацию в реальном времени, помечены (*).

AnyPresence MBaaS (Mobile backend as a service). Упрощает процесс создания мобильных приложений предприятия, работающих на разных устройствах, не ущемляя гибкость средств, доступных разработчику. Легок в использовании даже для неопытных пользователей. Опытные разработчики получают доступ к исходникам всех компонентов.

ApiOmat позволяет процессам предприятия работать как мобильным приложениям. Мобилизует сложные бизнес-структуры и процессы путём объединения существующих IT-систем с мобильными приложениями и устройствами. Его можно устанавливать прямо в дата-центре компании, что позволит работникам выполнять свою работу через приложения вне зависимости от их местонахождения.

Appcelerator Arrow (*) Состоит из двух основных компонентов, Builder и Cloud. Arrow Builder позволяет быстро создавать API, модели данных и соединители данных как через мастер настройки, так и через написание кода. Arrow Cloud – это эластичный облачный сервис, где выполняются API и происходит анализ их использования, плюс обеспечивается работа двух десятков смежных сервисов (гео, хранение фотографий и т.п.) с использованием ArrowDB

Appery.io Интегрированные сервисы MBaaS – чтобы разработчики могли сконцентрироваться на приложениях, не отвлекаясь на инфраструктуру.

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

Речь сегодня пойдёт о JS-фреймворках. Нет, я не буду рассказывать про очередное готовое решение, не в том цель поста. Я лишь хочу посеять в ваших головах несколько простых идей, которые вы не встретите в документации ни к одному популярному фреймворку. А в конце мы постараемся сформировать видение идеальной архитектуры построения пользовательского интерфейса.

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

На днях JetBrains после пятилетней работы выпустила первый релиз языка Kotlin. Давайте посмотрим, что же это за язык, попробуем разобраться зачем и для кого он, какие имеет функциональные особенности. Скорее всего в статью затесались и личные впечатления от языка, но я старался, чтобы они не влияли на изложение полезной информации. Если вы еще ничего или почти ничего не знаете о Kotlin, то я завидую вам, ибо по моему ощущению почитать про инструмент, который ты долго ждал, сродни распаковке новогоднего подарка. Впрочем судите сами.

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

1. Electron;
2. React Native;
3. Прогрессивные веб-приложения;
4. Visual Studio Code;
5. Rollup;
6. WebAssembly.

На этой неделе случилось важное для нас событие — вышла первая версия языка программирования Kotlin! Так как почти вся разработка Kotlin велась в Питерском офисе компании JetBrains, многие хабровчане уже знают, что такое Kotlin и пробовали его на практике, поэтому этот пост больше для комментариев: задавайте любые вопросы и команда Kotlin ответит. Мы онлайн!

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

Скрипт получает список сессий qwinsta, выбирает сессии со статусом Диск ("*ЁбЄ*" — это тоже «Диск», просто в кривой кодировке, добавлено на всякий случай) и rwinsta сбрасывает сесии.
В скриптике rwinsta — закомментирована, чтоб сессии сбрасывались раскомментируйте.
В текущем виде скрипт просто покажет вам зависшие сессии.

Сегодняшний рассказ будет о методологии науки, в частности о том, каким образом мы можем устанавливать возраст археологических находок, какие основные методы при этом используются и какие физические принципы и процессы лежат в их основе.
Прелесть научных методов датировок состоит в том, что они взаимодополняемы и взаимопроверяемы, то есть с помощью одного метода мы можем проверить корректность другого и наоборот, при необходимости внося в него поправки. Также эти «часы» перекрывают огромный временной диапазон – около 9 порядков (на самом деле больше, но для исторических целей «быстрые» часы бесполезны, масштабы эволюционного времени захватывают семь или восемь порядков).
Это можно сравнить с работой опоздавших криминалистов, где нет непосредственных свидетелей с «места преступления», и нашедших лишь его следы.

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

В прошлом году я протестировал 198 аккумуляторов (44 модели AA и 35 моделей AAA). Тогда я измерял ёмкость аккумуляторов сразу после зарядки, а так же через неделю и месяц хранения.

Я провёл дополнительный тест большинства моделей аккумуляторов через семь месяцев после зарядки. Результаты получились интересными.

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

В этой статье мы поговорим о проектировании архитектуры и создании мобильного приложения на основе паттерна MVP с использованием RxJava и Retrofit. Тема получилась довольно большой, поэтому подаваться будет отдельными порциями: в первой мы проектируем и создаем приложение, во второй занимаемся DI с помощью Dagger 2 и пишем тесты unit тесты, в третьей дописываем интеграционные и функциональные тесты, а также размышляем о TDD в реалиях Android разработки.