У нас сотни программных проектов на поддержке, некоторые из них поддерживаются нами почти десять лет. Нетрудно догадаться, что понятие maintainable кода (переведу это понятие как код, легкий в поддержке) является у нас одним из основных. По счастливому стечению обстоятельств легкий в поддержке код также является и легким для (unit-)тестирования, легким для освоения новыми членами команды и т.д. Скорее всего, это связано с тем, что для создания maintainable кода приходится озаботиться хорошей архитектурой проекта и завести несколько хороших привычек.
В этой статье и поговорим о таких привычках, благодаря которым часто хорошая архитектура получается сама собой. Постараюсь также иллюстрировать все хорошими примерами.

Можно прочитать много книг по базам данных, написать кучу приложений на аутсорс или для себя. Но при этом невозможно не наступить на грабли, при работе с действительно большими базами/таблицами особенно, когда downtime на большом проекте хочется свести к минимуму, а еще лучше совсем избежать. Вот здесь самые простые операции, как например изменение структуры таблицы может стать более сложной задачей. Наиболее интересные случаи, проблемы, грабли и их решения из личного опыта с которыми нам на проекте Pushwoosh пришлось столкнуться описаны под катом. В статье нет красивых картинок, зато есть много сухого текста.

За последние лет пять я вижу очень много статей по «удачным» рецептам построения систем деплоймента и управления конфигурацией на базе Chef/Puppet/Vagrant/Ansible. Я потратил около 7 лет на решение задач автоматического деплоймента в компании, в которой я в то время работал, и теперь считаю, что имею достаточно опыта, чтобы покритиковать многие распространенные инструменты.

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

В качестве предисловия

Наверное, многие из вас в своей практике сталкивались с задачей сбора почты с ряда ящиков. Зачем это может быть нужно? Наверное, потому что это универсальный механизм обмена данными между системами. Множество библиотек под любые языки, реализующих SMTP, POP3, IMAP, готовые решения по реализации стэка сообщений (как я сложно назвал почтовый ящик...) и т.д.

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

Кому достаточно приведенного ниже кода — дальше могут не читать:

         foreach (var mailbox in mailboxes)
                using (var client = new Pop3Client())
                {
                    client.Connect(Hostname, Port, false);
                    client.Authenticate(User, Password);

                    var count = client.GetMessageCount();
                    for (var i = 0; i < count; i++)
                    {
                        Mail = client.GetMessage(i + 1);
                        var cat = SortMail(Mail);
                        DoSomething(Mail, cat);
                    }
                }

От переводчика: некоторые скорее всего уже читали этот титанический труд от Мартина Фаулера и его коллеги Джеймса Льюиса, но я все же решил сделать перевод этой статьи. Тренд микросервисов набирает обороты в мире enterprise разработки, и эта статья является ценнейшим источником знаний, по сути выжимкой существующего опыта работы с ними.

Термин «Microservice Architecture» получил распространение в последние несколько лет как описание способа дизайна приложений в виде набора независимо развертываемых сервисов. В то время как нет точного описания этого архитектурного стиля, существует некий общий набор характеристик: организация сервисов вокруг бизнес-потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.

От переводчика: с момента выхода популярной статьи Мартина Фаулера «Микросервисы» (перевод на Хабре) прошло уже достаточно времени, чтобы автор смог дополнить свои наблюдения свежим опытом проектирования и разработки микросервисов в различных компаниях, и рассказать о нем в новом посте, чей перевод представляется вашему вниманию.
Многие команды разработчиков нашли архитектурный стиль микросервисов подходом, превосходящим монолитную архитектуру; другие команды выяснили, что для них микросервисы — лишняя обуза, подрывающая производительность разработки. Как и у любого стиля архитектуры, у микросервисов есть свои плюсы и минусы. Для того, чтобы делать осознанный выбор, вы должны понимать эти свойства и уметь рассматривать их на фоне собственных конкретных условий.

Микросервисы дают преимущества…	…ценою издержек
Жесткие границы модулей Strong Module Boundaries Микросервисы усиливают модульную структуру, что особенно важно для больших команд разработчиков.	Распределённость Distribution Распределенные системы тяжелее программировать, поскольку удаленные вызовы медленные и всегда рискуют неудачей-отказом.
Независимый деплоймент Independent Deployment Простые сервисы проще деплоить, и, поскольку они автономны, меньше вероятность отказа системы в случае, если что-то идет не так.	Консистентность в конечном счете Eventual Consistency Поддержка cтрогой консистентности чрезвычайно сложна для распределённых систем, и это означает, что придется иметь дело с консистентностью в конечном счете.
Технологическое разнообразие Technology Diversity С микросервисами вы можете смешивать несколько языков, фреймворков и технологий хранения данных.	Эксплуатационная сложность Operational Complexity Вам потребуется опытная команда эксплуатации для управления множеством сервисов, которые будут регулярно редеплоиться.

Чаще всего deadlock описывают примерно следующим образом:
Процесс 1 блокирует ресурс А.
Процесс 2 блокирует ресурс Б.
Процесс 1 пытается получить доступ к ресурсу Б.
Процесс 2 пытается получить доступ к ресурсу А.
В итоге один из процессов должен быть прерван, чтобы другой мог продолжить выполнение.
Но это простейший вариант взаимной блокировки, в реальности приходится сталкиваться с более сложными случаями. В этой статье мы расскажем с какими взаимными блокировками в MS SQL нам приходилось встречаться и как мы с ними боремся.

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

Некоторые из них напрямую или косвенно связаны с когнитивными искажениями человеческого сознания – в этих случаях я даю ссылки на соответствующие вики-статьи. Также интересен список известных когнитивных искажений.

1 Преждевременная оптимизация

В 97% случаев надо забыть об эффективности малых частей программы: преждевременная оптимизация – корень всех зол. Но в 3% случаев об оптимизации забывать не нужно.
Дональд Кнут

Хотя никогда зачастую лучше, чем прямо сейчас
Тим Питерс, Зен языка Python

Что это

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

Почему плохо

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

Как избежать

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

Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).

В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.



Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…

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

В последние месяцы проблематика миграции работающих систем на open-source решения для хранения данных захватила умы отечественных разработчиков. Особой популярностью в роли целевой платформы пользуется PostgreSQL. Причин тому можно назвать несколько:

1. Пребывающая у всех на слуху политика импортозамещения, внедряемая правительством;
2. Популяризация PostgreSQL силами энтузиастов и развитие российского сообщества благодаря таким мероприятиям как PG Day и PGConf;
3. Расширение функциональных возможностей PostgreSQL, позволяющих разработчикам строить гибкие и «schema-less» приложения, не теряя при этом всех преимуществ СУБД, таких как честные транзакции, отказоустойчивость, возможности масштабирования и др.

Нам удалось убедиться в эффективности PostgreSQL несколько лет назад. Внедрение СУБД позволило ликвидировать серьезный технологический кризис на одном из крупных проектов компании. Подробный рассказ об этой success story состоялся на PG Day’14 Russia, прошедшем в прошлом году в Санкт-Петербурге. С тех пор нам довелось попробовать базу данных для решения широкого спектра проблем.

1. От автора

1.1. Это ответы ИТ-менеджера своему боссу на его часовой матерный монолог в стиле — «Когда мне понадобится твое мнение, я тебе его скажу!»

1.2. Эти ответы позволят ИТ-боссу или тому, кто еще только собирается им стать, открыть для себя много нового.

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

1.4. Эти ответы так же не претендуют на истину, правоту или любую другую абсолютную правду. Это просто другой взгляд на ту же самую разработку ПО, который, как я скромно надеюсь, позволит тебе увидеть проблемы ИТ-отрасли бинокулярным зрением. Сделает их более объемными и, следовательно, откроет их тебе с другой и, скорее всего, неожиданной для тебя, стороны.

1.5. Автор, таки, претендует на определенный опыт в ИТ, поскольку пашет в этом бизнесе уже 35 лет, причем 25 из них является ИТ-менеджером.

1.6. Поэтому буду говорить не о том, что видел и слышал, а о том, от чего остались шрамы на шкуре и на языке, как верно заметил старик Адизес.

Предлагаю читателям «Хабрахабра» перевод статьи «Spotting bad actors: what your logs can tell you about protecting your business» из официального блога Elasticsearch. Статья рассказывает о том, как можно использовать возможности Elasticsearch для анализа логов веб-сервера с целью обнаружения подозрительной активности на сайте.

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

Но на сколько бы изменилась ситуация, если бы мы могли заблаговременно получать развернутую информацию обо всех IP-адресах и подсетях, которые проявляют подозрительную активность и блокировать именно их? Звучит здорово, не правда ли?

Мы можем легко сделать это вместе с Elasticsearch.

последняя редакция статьи доступна на сайте makeloft.xyz

Материалы этой статьи описывают механизмы компоновки, компрессии, динамической загрузки, а также пути элементарной защиты .NET-сборок стандартными средствами среды разработки Visual Studio. Однако, возможно, нижесказанное будет в некоторой степени справедливо и для других программных платформ.

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

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

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

Новости хаба .Net на Хабре занимают 33 страницы или 328 постов. Что говорит о том что новости появляются почти каждый день =) Посмотрим на самое интересное из них (на мой скромный взгляд). Ну и загляните под кат: до ката, конечно же, не все.

Доступен новый JIT: теперь с поддержкой SIMD
Как работает декомпиляция в .Net или Java на примере .Net
Microsoft раскрыла исходный код компилятора С#
Consulo: ~1000 коммитов, или как прошла осень
Под капотом у Stopwatch
Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

Много времени прошло с момента появления AngularJs (в масштабах веб-технологий конечно). Сейчас в интернетах есть огромное количество постов восхваляющих этот фреймворк до небес, что это манна небесная не иначе, а критики не так уж и много как он того заслуживает. Но такие статьи уже потихоньку начинают появляться, и меня это радует, надеюсь индустрия переболеет ангуляром так же, как переболела MooTools, Prototype, %какой-нибудь новый язык под JVM%, %другая-супер-революционная-технология%. Не знаю почему, но в IT-области такие революционные технологии, которые поднимают шум, а потом пропадают, появляются довольно часто. Хороший разработчик должен уметь отличать очередную модную технологию, от работающего инструмента. И для этого очень важно критически смотреть на вещи. Моя статья — это компиляция самых весомых выводов из других статей, и моих личных умозаключений. Ангуляр создает хороший вау-эффект, когда видишь его впервые: «ух ты, я написал ng-repeat, и реализовал эту логику одними тегами и все само обновляется!», но как только приходится реализовывать реальные приложения, а не очередной TODO-лист, то все становиться очень печально. Сразу хочу сказать, что фреймворк я знаю хорошо, даже больше чем мне хотелось бы его знать, я программировал на нем в течении 2 лет. И для следующего проекта я его точно не выберу, и это хорошо, все мы учимся на ошибках. Так что же не так с ангуляром? Тут нет однозначного ответа, слишком много разных недостатков, которые создают такой облик фреймворку. Если одним словом – непродуманная архитектура. Под катом я привожу конкретику, так что устраивайтесь поудобнее. ДА НАЧНЕТСЯ ХОЛЛИ ВАР!

Тем, кто работает с телефонией, приложениями связанных со звонками и т.п. время от времени приходится сталкиваться с вопросами: «а можно определять с какого региона этот звонок?» и «а этот номер какого мобильного оператора?»

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

Но ведь можно автоматизировать этот поиск? Конечно. И многие аккуратно парсят этот CSV и складывают к себе в базу данных. А затем используют. Я тоже так делаю.

Но недавно с моим коллегой мы решили немного это упаковать и сделать npm для быстрого подключения ресурса нумерации к проекту на node.js.

Ссылка на гитхаб, ссылка на npm.

Далее немного деталей.

Самое сложное перед Новым Годом — это составить график, когда инженеру нельзя бухать. Дело вот в чём: у «икс-команды» выездных инженеров есть стандартная дежурная смена, там бойцы просто сидят в офисе. А ещё у нас есть обычные проекты, и по тем, где есть услуга поддержки, всегда должен оставаться кто-то на связи. Поэтому мы и носим с собой ноутбуки и телефоны-модемы даже на вечеринки. И — обязательно — не пьём, если сегодня нужно страховать.

Из примеров — мой коллега как-то пошёл на свидание, и вместо общения с девушкой удалённо поднимал сервер.

А ещё на Новый Год резко меняется адекватность заявок в техподдержку. Один раз, например, 31-го у нас вылетело критичное оборудование: оказывается, заказчик «затушил» стойку, чтобы вызвать инженера. Понимали, заразы, что так его с дежурства не выпустят. Сделали сервисный случай именно под него. Приехал, а там поляна с водкой, довольной заказчик и подарок на Новый год за хорошую работу.

В общем, берите чай, печеньку — и заходите, буду рассказывать.

Сегодня в Нью Йорке проходит конференция Microsoft Connect(), на которой анонсированы новые продукты и технологии. Выпущена предварительная версия Visual Studio 2015, специальная бесплатная редакция Visual Studio Community 2013, Visual Studio 2013 update 4, открывается исходный код .NET Server Core, выпущена предварительная версия .NET 2015, обновлены инструменты кросс-платформенной разработки на базе Apache Cordova, в Visual Studio появился эмулятор ОС Android. Это действительно новый этап в развитии инструментов разработки Microsoft, и мы рады рассказать о деталях.

Основное

• Reference Source для .NET 4.6 перелицензируется под MIT;
• В дальнейшем фреймворк будет с открытыми исходниками и поставляться по частям через NuGet, можно будет с приложением поставлять свою сборку, которая будет изолирована от всего остального;
• Разработка переезжает на GitHub;
• Скоро откроют исходники рантайма, включая RyuJit и сборшик мусора;
• Для всего этого счастья планируется официальная поддержка никсов.

​

​

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

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

Под катом — 5 первых названий с описаниями от меня, для затравки.
update 1. В комментариях ещё 10+ названий.