2 года назад в статье «Continuous Delivery & Sitecore: наша реализация» я представлял нашу систему автоматической доставки веб-приложений основанных на Sitecore. Это были первые маленькие шаги в направлении мира полной автоматизации.

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

Когда я показываю босу, что окончательно пофиксил баг



Когда проджект-менеджер входит в офис

Я поделюсь 30 практиками для достижения максимальной производительности приложений, которые этого требуют. Затем, я расскажу, как применил их для коммерческого продукта и добился небывалых результатов!
Приложение было написано на C# для платформы Windows, работающее с Microsoft SQL Server. Никаких профайлеров – содержание основывается на понимании работы различных технологий, поэтому многие топики пригодятся для других платформ и языков программирования.

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

Добрый день.

Мы живем в мире тотальной глобализации как в реальной жизни, так и в виртуальной. Я имею в виду, что нам хочется иметь одни и те же данные, одни и те же настройки и одно и то же поведение программ на разных устройствах. Такой синхронизации всего и вся в наше время легко добиться с помощью облаков. Об этом и пойдет речь в данной статье, а именно о скрещивании приложения для Windows 8 (WinRT) с облаком Windows Azure для хранения данных и метаданных.

Вводная

Итак, предположим, что у нас есть приложение для Windows 8 (пусть это будет сервис хранения неких текстовых записей), которое:
1) Должно отображать список записей с минимальной информацией о каждой из них (допустим, заголовок или дату создания). Назовем это метаданными.
2) Должно иметь возможность показать подробную информацию о записи (контент) при переходе к конкретному элементу. Назовем это данными.
3) Должно синхронизировать данные между различными устройствами под управлением Windows 8 (создал запись дома, просмотрел ее же на работе).

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

По ходу этой статьи мы познакомимся с Windows Azure Mobile Services для хранения метаданных и Windows Azure Blob Storage для хранения данных. Впереди много текста и картинки.

Поздравляю всех с пятницей и в качестве небольшого развлечения предлагаю представить, как бы выглядел популярный CSS-фреймворк Twitter Bootstrap, если бы он был от Google? Встречайте Plusstrap.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

Большинство сайтов можно отнести к маленьким и очень маленьким проектам, масштаба единиц человеко-месяцев. В силу малости размеров такие проекты спокойно поддаются хорошему продумыванию и легко реализуются с помощью водопадной модели, достаточно просто не лениться на каждом этапе разработки (от написания ТЗ до сдачи проекта). Применять к этим проектам гибкие методологии разработки нет смысла, а как раз есть смысл применять хорошее ТЗ. К тем сайтам, которые не попадают под водопадную модель не стоит применять описанный ниже подход.

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

От переводчика: Это перевод статьи от одного из разработчиков ASP.NET, в которой подробно рассказывается о механизме управления состоянием страницы — ViewState'е. Несмотря на то, что статья написана в 2006 году, она до сих пор не потеряла своей актуальности.

ViewState — очень непонятное существо. Я попытаюсь положить конец всяческим кривотолкам, и постараюсь объяснить, как на самом деле работает механизм ViewState'а, от начала до конца, посмотрев на него с различных точек зрения.

Есть множество статей, авторы которых пытаются развеять мифы о ViewState'е. Можно даже подумать, что это все — борьба с ветряными мельницами (где ViewState – ветряные мельницы, а Интернет – инструмент борьбы). Но, я вам доложу, мельницы ещё не остановились. Как раз наоборот, они вертятся и заполняют собой вашу гостиную. Пора бы нанести по ним ещё один удар. Не тревожьтесь, при написании этой статьи ни одна ветряная мельница не пострадала.

Здравствуйте хабровчане.


Sitecore мало освещается на хабре, однако это очень функциональная (и дорогая) CMS довольно популярна у тех, кто может её себе позволить. Вместе с тем, люди разрабатывающие (и особенно поддерживающие) сайты на sitecore часто жалуются на трудности модификации темплейтов. Так, простое переименование темплейта или одного поля может привести к непредсказуемым и, главное, трудно поддающимся диагностике и исправлению нарушениям в работе сайта. Причём вылезти они могут только через несколько месяцев. Кроме того, использование стандартных сайткоровских FieldRenderer-ов затрудняет контроль над разметкой, что было критично в нашем случае.

Зачем велосипед?

Существуют решения для генерации классов на основе темплейтов (как trac.sitecore.net/CompiledDomainModel), однако они не очень удобны в использовании и не устраняют привязку к структуре темплейта, именам полей. Упомянутый CompiledDomainModel требует регенерации всех моделей после любых изменений. Также он слабо подходит для совместной разработки (постоянные конфликты в сгенерированном коде), требует уникальных имён для всех темплейтов, завязывается на пути к темплейтам и ID-шки и генерирует чудовищный код одним файлом (на одном из проектов там было больше 60 000 строк и открыть его в VS было делом очень не быстрым).