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

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

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

Что же это за проблемы?

8 июня 2013 года прошла онлайн-конференция RuHaxe — первое событие в рунете, посвященное Haxe-платформе.

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

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

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

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

«Качество появляется только тогда, когда кто-нибудь несёт ответственность лично».
— Фредерик Ф. Брукс



Привет, хабр!

Предлагаю вашему вниманию вольный перевод эссе "A Generation Lost in the Bazaar" Пола-Хеннинга Кампа, повествующего нам о печальной судьбе поколения IT-профессионалов, выросших в период бума доткомов, а также о фундаментальных проблемах в UNIX, напрямую влияющих на качество и портабельность ПО. Обо всём по порядку.

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

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

Моя стажировка в Microsoft Windows Azure началась ровно два года назад, сразу после колледжа, и проходила она в той же команде, с которой я проработал последние восемь месяцев.

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

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

Итак, поехали.

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

Сегодня в программе:

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

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

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

• Использование команд (Solution commanding). Используйте для реагирования на действия пользователя.
• Контекст региона (Region context). Используйте для передачи контекстной информации от host-элемента управления к представлениями в регионе. Этот подход в некотором роде аналогичен DataContext, но не полагается на него.
• Общие службы (Shared services). Вы можете вызвать метод на сервисе, который, в свою очередь, сгенерирует событие, на которое могут быть подписаны получатели. Используйте этот подход в том случае, если все остальные подходы не применимы.
• Агрегация событий (Event aggregation). Для передачи сообщений между моделями представлений, презентерами, или контроллерами при отсутствии ожиданий о непосредственной реакции на сообщение.

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

Существует множество причин, из-за которых программист может начать работать над сторонним проектом. Это хороший способ держать руку на пульсе современных технологий, которые сейчас на пике популярности в отрасли. Это может помочь вам отточить свои навыки программирования. И это весело! Ну или должно быть весело.
Но то, что мы привыкли называть “жизнью” может не только усложнить вам завершение проекта, но даже не дать начать работать над ним. Мы часто тратим много времени чтобы придерживаться напряженного графика, и может показаться невозможным использовать хотя бы минутку для личного проекта.
Я начал работать на моим первым сайд-проектом два года назад, и я не эксперт в этом вопросе, чтобы это не значило. Спустя два года, я сделал несколько наблюдений о начале работы над сторонними проектами, которые я начал, почему я смог некоторые закончить, а некоторые нет. То, что я попытаюсь описать не претендует на новаторство, ни на пошаговое руководство, а является исключительно лишь наблюдениями, которые могут оказаться полезными.

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

Но сначала история…

Это было <вставьте период времени, который не будет делать меня нелепо старым> в то время, когда я был молодым разработчиком (1). В колледже я был лучшим на занятиях по программированию, будучи младшим разработчиком, я мог взломать код и решить любую поставленную передо мной задачу быстрее, чем кто-либо ожидал. За выходные я мог изучить новый язык и продуктивно на нем работать (или, по крайней мере, мне так тогда казалось).

Таким образом, как и должно было произойти, у меня появился свой собственный проект. Менеджер по работе с крупными клиентами объяснил мне в общих чертах, чего хочет клиент, мы это обсудили, и я сказал: «На эту работу уйдет 3 недели.» «Хорошо», — ответил он. И так я приступил к программированию.

Как вы думаете, сколько времени у меня ушло на этот проект? Четыре недели? Может быть пять?

Мм, вообще-то: три месяца.

У меня остались четкие воспоминания о том времени – мое представление о себе было тесно связано с ощущением, что я — «хороший программист», в чем я сильно разочаровался. Я потерял сон, у меня случались небольшие приступы паники. И этому Не Было Конца. Я помню, что у меня сосало под ложечкой при разговоре с тем менеджером, я снова и снова объяснял, что у меня до сих пор нет ничего, что можно ему показать.

В один из таких черных периодов я решил, что Больше Никогда Не Буду Совершать Подобных Ошибок.

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

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

Когда-то я говорил, что к собеседованию должен готовиться не только соискатель, но и интервьювер. Теперь я сам провожу собеседования, но после десятого интервью все соискатели выглядят как китайцы – одинаково.

Когда-то я говорил, что опаздывать на встречи могут только пид$расы. Теперь я сам часто опаздываю на встречи, но в то же время не сплю с мужиками.

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

Azure Service Bus как Messaging System для «массовых» клиент-серверных приложений

Приветствую вас, хабровчане!

Перед тем, как расказать вам интересненького, позвольте для начала представиться. Мы — молодая компания, занимающаяся дистанционным обучением. В этом блоге мы будем делиться с вами нашими интересными находками, техническими хитростями и прочими вещами, которые, как мы считаем, должны быть достоянием сообщества.
Дальше будет несколько слов о нас и, собственно, вынесенный в заглавие рассказ о неочевидном применении Azure Service Bus.

Всем привет. Перед вами заключительная статья из цикла «Внутреннее устройство и архитектура сервиса AtContent.com». Здесь собраны лучшие практики из нашего опыта работы с Azure Table Storage и платформой в целом. Эта статья может стать отправной точкой при построении типовых структур данных и позволит более эффективно использовать ресурсы Windows Azure.



Горизонтальное масштабирование во многом опирается на разделение данных и платформа Windows Azure не исключение. Одной из составляющих частей платформы является Azure Storage Table — NoSQL база данных с неограниченным ростом. Но многие разработчики игнорируют её в пользу привычного и знакомого SQL. При этом довольно часто задачи решаются с помощью Azure Storage Table намного эффективнее, чем с применением Azure SQL.

Здесь вы найдете практику и сценарии применения Azure Storage Tables.

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

В качестве основного канала коммуникации между экземплярами рекомендуется использовать очереди Azure (Azure Queue). Но использование только этого канала не позволяет максимально эффективно использовать экземпляры сервиса. Итак, в этой статье вы узнаете как

• минимизировать задержку между отправкой задания на экземпляр и началом его обработки
• минимизировать количество транзакций к Azure Queue
• повысить эффективность обработки заданий

Сегодня вашему вниманию представляется вторая статья из цикла статей об архитектурных решениях сервиса AtContent.com.

В процессе работы над сервисом AtContent.com у нас возникла задача о синхронизации между экземплярами внутри роли, а также между ролями. Стандартные средства из SDK не позволяют решить эту проблему двумя строчками кода. Поэтому мы разработали собственное решение для коммуникации между экземплярами. Оно позволяет выполнять задания на всех экземплярах роли сразу, либо на одном экземпляре, который выбирается определенным образом либо случайно.

В этой статье приводится сравнение двух сервисов структурированного хранилища, поддерживаемых Windows Azure: Windows Azure Table Storage и Windows Azure SQL Database, ранее известного как SQL Azure. Целью данной статьи является сравнение этих технологий для того, чтобы вы могли понять их общие и различные характеристики. Это сравнение поможет вам вынести более обоснованное решение о том, какая из технологий будет лучше подходить под реализацию вашего сценария.

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

Введение

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

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

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

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

Введение

Windows Azure поддерживает два типа механизмов очередей: очереди Windows Azure и очереди шины обслуживания.

Очереди Windows Azure, входящие в состав инфраструктуры хранилища Windows Azure, поддерживают простой REST-интерфейс с функциями Get/Put/Peek (Получение/Запись/Считывание) для создания надежной и отказоустойчивой системы обмена сообщениями между службами и внутри них.

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

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

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

Добрый день, уважаемые коллеги!

WAS – система облачного хранилища, предоставляющая клиентам возможность хранить практически неограниченные объёмы данных в течение любого периода времени. WAS была представлена в production-версии в ноябре 2008. Ранее она использовалась для внутренних целей Microsoft для таких приложений, как, например, хранение видео, музыки и игр, хранения медицинских записей и др. Статья написана по мотивам работы с сервисами хранилища и посвящена принципам работы этих сервисов.

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