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

Введение

Разрабатывая и отлаживая проект в Visual Studio, вы, как правило, делаете это, компилируя код в Debug-конфигурации. На боевой же сервер проект выкладывается, откомпилированный в Release-конфигурации. И каждый проект рано или поздно разрастается настолько, что в нём появляется некий «отладочный» или «релизный» код — то есть, тот код, который должен работать только в одной из конфигураций. И если бы дело ограничивалось только кодом, то директива условной компиляции #if решала бы все проблемы. Но обычно за кодом ещё тянутся настройки, специфичные для каждой из конфигураций, а зачастую и разметка веб-страниц. В самом начале, когда такие проблемы только начинают появляться, и ещё не являются сильной головной болью, обычно используется банальное комментирование ненужных в конкретный момент строк с кодом/разметкой/настройками. Но это — Road To Hell в самом чистом виде. А вот о Stairway To Heaven я и хотел бы рассказать.



Когда я впервые столкнулся с такой проблемой и уже погряз в костылях из комментариев и наборов различных конфигурационных файлов, то в какой-то момент решил поинтересоваться чужим опытом, а также получше изучить возможности среды разработки и используемых инструментов. И внезапно выяснил, что все мои искусственные костыли являются абсолютно избыточными — проблема может быть решена стандартными средствами и без ухудшения читаемости кода. Итоги моего исследования я опишу в небольшом цикле статей, где рассмотрю и примеры проблем с окружением, и механизмы, с помощью которых весь код, настройки и html-разметку автоматически можно привести в нужный вид при публикации проекта. Речь при этом пойдёт о разработке ASP.NET MVC-приложений, как области, в которой я, в основном, и работаю. Однако, всё написанное будет применимо к любой .NET-разработке в Visual Studio.

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



Как тестировщик, я люблю, когда всё по порядку, но жизнь переполнена грязными хаками. Я люблю автоматизировать, подвязав Selenium к Python, но когда встречаюсь с проблемой ограниченности ресурсов, бросаюсь за тот инструмент, который позволяет сделать «всё то же самое, но быстрее». В этом посте я расскажу, что JMeter — прекрасный инструмент как для нагрузочного, так и для функционального тестирования.

PHP-разработкой я занимаюсь уже довольно давно, и за это время научился использовать преимущества этого языка и избегать, по возможности, его недостатков. Но что мне никогда не нравилось в PHP — это встроенный механизм шаблонизации. Обилие символов “<?php … ?>” и многословных языковых конструкций бьет по глазам, возможность использования в шаблоне произвольного PHP-кода не способствует соблюдению принципа разделения логики и представления.

Поэтому я благодарен судьбе (и сообществу разработчиков, конечно) за то, что существуют альтернативные движки шаблонизации, с гораздо более приятным синтаксисом при тех же функциональных возможностях. Ну, а поскольку большая часть PHP-проектов у нас, в Центре Высоких Технологий, разрабатывается на Symfony2 Framework, то нашим любимым шаблонизатором стал Twig. Помимо указанных выше преимуществ, он еще и безгранично расширяемый, что очень часто помогает в работе.

Но жизнь частенько преподносит сюрпризы. Вот и на меня недавно свалился небольшой, но довольно интересный проект, делать который нужно было на… Битриксе! К счастью, работать с Битриксом мне уже приходилось, но было это давно (и неправда), поэтому я воспринял проект как возможность посмотреть на свой прошлый опыт с новой точки зрения, применить накопленные знания и навыки в несколько ином контексте.
И первое, что мне захотелось сделать — “прикрутить” Twig, чтобы не мучиться с нативной шаблонизацией.

Вот что из этого получилось.