Elasticsearch — поисковый движок с json rest api, использующий Lucene и написанный на Java. Описание всех преимуществ этого движка доступно на официальном сайте. Далее по тексту будем называть Elasticsearch как ES.

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

В этой статье я расскажу про основы ES на примере индексации постов блога. Покажу как фильтровать, сортировать и искать документы.

Доброго времени суток. В этот раз поговорим на тему, в которой начинал разбираться каждый уважающий себя адепт языка C# — асинхронное программирование с использованием Task или, в простонародье, async/await. Microsoft проделали хорошую работу — ведь для того, чтобы использовать асинхронность в большинстве случаев нужно лишь знание синтаксиса и никаких других подробностей. Но если лезть вглубь, тема довольно объемная и сложная. Ее излагали многие, каждый в своем стиле. Есть очень много классных статей по этой теме, но все равно существует масса заблуждений вокруг нее. Постараемся исправить положение и разжевать материал настолько, насколько это возможно, не жертвуя ни глубиной, ни пониманием.

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

Разрабатывая приложения, мы постоянно сталкиваемся с новыми подходами, языками и концептами. И постоянно мы мечемся в сомнениях «смогу ли я быть на волне, оставаться конкурентоспособным, учитывая все изменения и тренды?». Давайте задумаемся на мгновение, вспомнив фразу из моего любимого фильма «Касабланка» — в любви законов новых нет — так создан свет.

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

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


Советские геофизические ракеты Р-2А и Р-5А

Несколько месяцев назад, когда ASP.NET Core был еще в RC1, я делал первые неловкие попытки перевести свой тестовый проект с MVC 5 на ASP.NET Core. На тот момент в проекте уже использовалась IOC библиотека Simple Injector, и по этой причине я хотел продолжать использовать эту библиотеку, благо была поддержка с rc1. Я следил за выходом новых версий этой библиотеки и относительно недавно наткнулся на довольно интересную, на мой взгляд, статью, размещенную в тематическом блоге Simple Injector. Хоть статья и опирается на соответствующую библиотеку, но основная ее ценность в поднятии более общей проблемы — новой DI абстракции в ASP.NET Core.

Статья из блога IOC библиотеки Simple Injector
Автор Steve
Буду рад, если укажете на ошибки и неточности перевода.

Последние несколько лет Microsoft занималась разработкой новой версии платформы. NET: .NET Core. .NET Core — это полный редизайн существующей платформы .NET, нацеленный на настоящую кроссплатформенность и совместимость с облачными технологиями. Мы внимательно следили за развитием .NET Core и выпускали совместимые с платформой версии Simple Injector, начиная с RC1. С выпуском Simple Injector v3.2 мы официально поддерживаем .NET Core.

Как вы могли заметить, Microsoft добавила свою собственную DI библиотеку в качестве одного из основных компонентов фреймворка. Кто-то может воскликнуть «наконец-то!». Отсутствие такого компонента породило множество опенсорсных DI библиотек для .NET. И Simple Injector, очевидно, один из них.

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

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



В основе статьи — выступление Саши на конференции DotNext 2017 Piter. Саша работает техническим директором израильской тренинговой и консалтинговой компании Sela и не понаслышке знает, как проводить анализ производительности. Как его лучше начинать, чем завершать, какие инструменты стоит использовать, а каких избегать, читайте под катом.

Нужно ли вам представлять настоящего джедая .NET, performance-гуру, многократного Microsoft MVP, постоянного спикера конференции DotNext Сашу Гольдштейна? Наверно, не стоит. А если вдруг стоит, смотрите здесь.



В нашей беседе Саша делится профессиональными советами для разработчиков .NET и .NET Core. Рассказывает о том, на что обращать внимание при профилировании и отладке приложений и какими инструментами пользоваться.

Добрый день. Неделю назад я в третий раз применил библиотеку для создания\запуска .NET бенчмарков BenchmarkDotNet. Библиотека оказалась достаточно удобной, но практически не освещенной на хабре, что я сейчас и исправлю.

Под бенчмарком я подразумеваю измерение времени выполнения метода(ов). Для начала представим процесс написания бенчмарка руками. Создаем тестируемый метод, выбираем Release билд, создаем «замеряющий» метод, в нем собираем мусор, ставим StopWatch в начале и в конце, запускаем прогрев, запускаем тестируемый метод. Если тестируемый метод выполняется быстрее одного «тика» StopWatch, запускаем тестируемый метод много раз (пусть будет миллион), делим суммарное время на миллион, получаем результат (при этом нужно не забыть вычесть из суммарного времени время «холостого» прогона цикла на миллион операций).

Представим, что вы хотите преобразовать свою систему из одного состояния в другое. Начальное состояние — это когда DateTime используется везде, в C# коде и в БД. Конечное состояние — когда везде используется DateTimeOffset. Вы хотите сделать переход плавно и внести как можно меньше изменений. Это описание может быть началом очень интересной задачи с тупиком в конце.

Рассмотрим некоторые части .Net Framework'a, выглядящие тривиальными, но вполне способными сделать ваш код более простым как в написании, так и в сопровождении.


Пишущие на .NET (а если вы этого не делаете, то зря читаете этот пост) наверняка время от времени используют для своих нужд структуру DateTime. Эта структура удобна для хранения дат, времени или даты/времени, относящихся к локальной временной зоне (или же к UTC).


Однако, бывают случаи, когда вам необходимо сохранить время в виде смещения, а не конвертировать его в локальное время. И вот здесь вам на помощь придёт структура, впервые появившаяся в .NET 3.5 — DateTimeOffset.

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

Опираясь на материал, описанный в первой и второй частях данной статьи, мы продолжим обсуждение темы обработки исключений в Windows x64.

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

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

Путем проб и ошибок мы пришли к следующему технологическому стеку:

1. SpecFlow (опционально): DSL
2. NUnit: тестовый фреймворк
3. PageObject + PageElements: UI-абстракиця
4. Контекст тестирования (информация о целевом окружении, пользователях системы)
5. Selenium.WebDriver

Для запуска тестов по расписанию мы используем TFS 2012 и TeamCity.
В статье я опишу, как мы к этому пришли, типовые ошибки и пути их решения.

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



То что вы делаете, называется интеграционным тестированием. Современные приложения достаточно сложны и содержат множество зависимостей. Интеграционное тестирование проверяет, что несколько компонентов системы работают вместе правильно.

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

Привет!

Будущие студенты Veeam Academy часто спрашивают нас о книгах, которые были бы полезны при подготовке к поступлению на наш курс по программированию на С#. Обычно мы рекомендуем несколько источников, сопровождая их своими комментариями, почему именно они будут полезны.

Однако большинство книг по программированию – это 1К+ страниц, и для их прочтения «от корки до корки» понадобится не один месяц и, возможно, даже не один год! Поэтому все наши рекомендации для абитуриентов Академии Veeam служат лишь ориентиром, а не обязательным требованием.

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

Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.

Как возникла необходимость отойти от классической Каскадной Модели жизненного цикла разработки

В 2009 году мне предложили выбрать и реализовать один из «гиблых» проектов. Приставку «Гиблый» каждый получил за то, что раньше за них уже пробовали браться, но ничего не вышло.

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

Большой пример: только оказавшись под санкциями и цене нефти в 50 долларов за баррель (против 110 ранее) руководство страны перешло от рассуждений и неспешных телодвижений к активным действиям по развитию высокотехнологичной экономики.

Так и один из моих Заказчиков созрел и я взялся сделать для него проект по разработке нового функционального модуля Корпоративной Информационной Системы (ERP-системы), который должен был добавить 400 новых пользователей системе и обеспечить проверку 40 000 ипотечных кредитов в год.

Этот пост будет не о том, как «перевести» код с C# на F#: различные парадигмы делают каждый из этих языков лучшим для своего круга задач. Однако вы сможете оценить все достоинства функционального программирования быстрее, если не будете думать о переводе кода из одной парадигмы в другую. Настало время любопытных, пытливых и готовых изучать совершенно новые вещи. Давайте начнем!

Все материалы из серии переводов русскоязычного сообщества F#-разработчиков вы сможете найти по тегу #fsharplangru.

Все мы знаем о том, что JavaScript-код веб-проектов может разрастаться до прямо-таки огромных размеров. А чем больше размер кода — тем дольше браузер будет его загружать. Но проблема тут не только во времени передачи данных по сети. После того, как программа загрузится, её ещё надо распарсить, скомпилировать в байт-код, и, наконец, выполнить. Сегодня мы представляем вашему вниманию перевод 14 части серии материалов об экосистеме JavaScript. А именно, речь пойдёт о синтаксическом анализе JS-кода, о том, как строятся абстрактные синтаксические деревья, и о том, как программист может повлиять на эти процессы, добившись повышения скорости работы своих приложений.