У зарубежных компаний история с ИТ-инфраструктурой очень простая: они как росли себе на Западе, так там всё и осталось. В России, как правило, нет даже инженеров, а все сервисы предоставляются откуда-нибудь из Ирландии, Франкфурта, Бостона или других городов, где находится головная организация и её дата-центры.

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



Сложностей море, например, такие:

• Полное отсутствие ИТ-персонала в российском офисе, занимающегося миграцией систем и управлением всего проекта в целом — нужно общаться с сетевиками из Европы или США и разработчиками, например, из Шанхая.
• Мало поднять прокси-структуру — нужно реально по факту обрабатывать данные в России. А, значит, в Москве (или в другом городе, но, как правило, действие происходит в столице) должен быть развёрнут инстанс CMS, почты, прикладного ПО для работы с продажами, бухгалтерия и так далее.
• Нужно перевезти всё это быстро и без существенных простоев, а потом ещё и поддерживать в плане инфраструктуры (приклад в данном случае поддерживают «родные» ИТ-команды).

В этой статье я расскажу об опыте поставки и конфигурирования многочисленных взаимосвязанных продуктов (непричастные называют это просто «созданием инсталляторов»).

Итак, представьте разбросанный по нескольким серверам набор приложений: 12 штук. Приложения разнородные, разработаны разными компаниями в разное время. Реализованы различные методы интеграции от примитивных экспортов/импортов через файловую систему, до продвинутой на базе web-сервисов. Приложения используют базы данных SQL Server и Oracle. Все эти приложения работают в сотнях разных окружений конечных заказчиков.

Установить и сконфигурировать все это стоит немалых трудов и ресурсов. Хорошо, установили. А обновления, которые для бухгалтерских систем должны выпускаться в соответствии с изменениями в законодательстве? Масштабирование приложений? А новый функционал? Что насчет новых клиентов с их «особенными» конфигурациями? Вручную – дорого и долго, если у вас, скажем, 150 клиентов и хотя бы 2 обновления такого «монстра» в год.

Шанс потерять свой домен имеет каждый, у кого какой-нибудь домен есть. Это если перефразировать песню «Если у вас нет собаки...». В этой же статье мы увидим наиболее яркие примеры потери доменов и убедимся, что даже масштаб компании не спасает от таких банальных проблем. Кроме того, рассмотрим процедуру утилизации домена, если его так и не продлили. Сколько он будет вас ждать и как быстро его сможет приобрести кто-то другой? И как от этого спастись? Об этом ниже.

Конференция Azov Developers Meetup 2015 прошла 12 декабря в Таганроге. Мы наконец-то закончили видеомонтаж и публикуем все материалы.

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



Почему импортные конференции? Российские тоже очень интересны, но иногда хочется совместить приятное с полезным: не только послушать умных людей и наладить новые связи на профильных для нас рынках США и Западной Европы, но и посмотреть какой-нибудь приятный город.

Мы публикуем вольный перевод статьи Mashable. Оригинал здесь

Ответьте без раздумий: сколько стоит билет из Москвы в Сочи?

Любой, кому приходилось покупать авиабилеты, знает, что ответ на этот вроде бы простой вопрос требует много уточнений. Когда вы летите? В какое время? Только туда или обратно тоже? Пересадка возможна? Аэропорт нужен какой-то конкретный? Готовы ли вы прилететь в другой город неподалеку? Багаж будет? И так далее, и тому подобное.

«Я всегда воспринимала как данность, что понятие цены на авиабилет не имеет смысла, — рассказывает фотограф и блогер Фрейя Доусон. — Вам просто предлагают согласиться с тем, что есть. Сегодня я собиралась забронировать билет в Сенегал, и поискала на Skyscanner. Получилось £700 за 24-часовой перелет. Потом я проверила на Momondo, и там оказалось £450 и восемь часов».

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

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

Сегодня я протестирую популярные, на данный момент, библиотеки для работы с HTML, а именно: AngleSharp, CsQuery, Fizzler, HtmlAgilityPack и, конечно же, Regex-way. Сравню их по скорости работы и удобству использования.


TL;DR: Код всех бенчмарков можно найти на github. Там же лежат результаты тестирования. Самым актуальным парсером на данный момент является AngleSharp — удобный, быстрый, молодежный парсер с удобным API.

Тем, кому интересен подробный обзор — добро пожаловать под кат.

После прочтения статьи о полезных и бесплатных плагинах для SSMS — TOP (10) бесплатных плагинов для SSMS, я решил поделиться своим списком бесплатных инструментов, которые могут быть очень полезны разработчикам баз данных, и не только. Инструменты ориентированны на разработку под Microsoft SQL Server. Некоторые инструменты, платные, однако содержат достаточно полнофункциональные бесплатные редакции, которых с головой хватает для небольших проектов.

12 декабря в Таганроге пройдет первая (и надеюсь, ежегодная) конференция Azov Developers Meetup 2015. Будут обсуждаться вопросы web и мобильной разработки, тестирования и управления проектами.
Приходите, будет интересно!

Хочу поделиться опытом разработки с использованием Xamarin (звучит как Замарин) на двух крупных проектах. Первый проект был под Windows Store и iOS, второй только под Андроид, но c использованием Xamarin.Forms. Xamarin быстро развивается, поэтому некоторые описываемые здесь моменты, могли уже стать неактуальными. Например: ещё летом мы переживали из-за дикого потребления памяти в Андроид и даже вручную вызывали сборщик мусора в некоторых местах, но в конце лета вышло обновление, которое закрыло многие наши проблемы с памятью.

Как юристы в сфере ИТ, мы готовим договоры на создание ПО как для разработчиков, так и для заказчиков. В договоре необходимо учесть особенности различных моделей разработки ПО, выделить возникающие в связи с этим риски клиента и постараться их нивелировать.

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

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

1. Договор с фиксированной ценой (Fixed Price)

Условия применения. Применяется в стандартных проектах с понятными решениями и требованиями, поддающимися детализации. Требования к результату выносятся в отдельное техническое задание. Фиксируются сроки выполнения работ и их стоимость.

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

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

Зайдите на сайты дата-центров, предоставляющих виртуальные машины и сервера, Вы заметите, что появляется всё больше предложений аренды инфраструктуры с предустановленным программным обеспечением. Причём встречаются разнообразные конфигурации: от образов операционных систем до серверов баз данных и CRM/ERP. Рынок диктует свои условия — и провайдеры, ЦОДы и просто владельцы мощностей идут навстречу клиенту и готовы помочь в разворачивании практически любой инфраструктуры. Но так ли всё безоблачно в этих облаках?



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

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

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

Многие из нас работают над большими проектами. Тот, о котором расскажу я, живет вот уже 15 лет и имеет в своём составе пару десятков веб-приложений на ASP.NET WebForms, главное из которых содержит в себе около полутора тысяч aspx-страниц.

Зачем так много? Желание подстроиться под заказчиков с различными требованиями даёт о себе знать. Каждый хочет какую-нибудь свою особенную функциональность и в итоге получает её. Но речь не об этом. В довесок к большому числу страниц у нас было много стилей CSS. Очень много.


Источник: Ursus Wehrli. The Art Of Clean Up

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

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

1. Какие существуют подходы к обеспечению совместного редактирования?
2. Насколько они сложны в реализации?
3. Можно ли взять готовую библиотеку и использовать ее в своем проекте?
4. Можно ли вести разработку без оглядки на совместное редактирование?

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

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

Вступление

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

Вот список основных требований к реализуемому модулю:

• Возможность выполнения основных операций с IIS:
  
  • создание сайта
  • создание virtual application
  • создание virtual directory
  • настройка bindings для сайтов, включая установку сертификатов SSL
  • создание пулов приложений с детальной настройкой
• Поддержка параллельной работы с несколькими IIS на разных серверах фермы
• Поддержка IIS версии 8.0 (более ранние версии поддерживать не нужно).

Одним словом, модуль должен был уметь практически всё, что можно сделать через IIS Manager.

Continuous Integration и Continuous Delivery де-факто являются неотъемлемой частью современной разработки проектов. Для автоматизации CI существует множество программ от различных вендоров, а вот с автоматизированием развертывания приложений дела обстоят скромнее. Одним из помощников развертывания является Octopus Deploy.