В статье речь пойдет об одном очень не новом проекте, который создавался совсем в другое время и совсем в других условиях. Это моя старенькая RTS под названием Земля онимодов (Onimod land). Чтобы было сразу понятно, что она собой представляет, можно посмотреть коротенькое видео:

С приходом весны и дождей на улице в глаза все чаще бросается одна проблема. Вот эта:



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

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

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

Под катом — описание алгоритма и пара примеров его работы для реальных питерских дворов.

Известно, что дерево – довольно сложная структура. И если чтение успешно реализуется в том числе рекурсией (которая не лишена своих проблем), то с изменением дела обстоят совсем не хорошо.

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

Классическое концептуальное объяснение зиппера, выглядит как-то так: это взгляд изнутри на древовидную структуру как бы вывернутую наизнанку, вроде вывернутой перчатки.

Это образное объяснение, если поскрипеть мозгами, обычно, конечно же, понимается только отчасти. Далее зипперы откладываются в сторону, потому что «это непонятная какая-то функциональная заморочка, типа монад, потом разберусь».

У автора «потом» уже наступило. Эта статья – попытка дать альтернативное объяснение зипперов (не путать с объяснением для альтернативно одаренных, хотя…) такое, что позволит быстро понять и немедленно начать использовать зипперы в практических задачах.

Мы продолжаем нашу колонку по теме ASP.NET Core очередной публикацией от Дмитрия Сикорского ( DmitrySikorsky) — руководителя компании «Юбрейнианс» из Украины. В этот раз Дмитрий рассказывает о своем опыте разработки модульного кроссплатформенного фреймворка на базе ASP.NET Core. Предыдущие статьи из колонки всегда можно прочитать по ссылке #aspnetcolumn — Владимир Юнев

Из-за специфики моей задачи, последнее время достаточно много приходится размышлять о модульной и расширяемой архитектуре веб-приложений на ASP.NET Core (а до этого — на ASP.NET предыдущей версии). В результате появился ExtCore — небольшой кроссплатформенный фреймворк с открытым кодом, позволяющий буквально простым подключением NuGet-пакета превратить ваше веб-приложение в модульное и расширяемое.

Основные возможности

ExtCore умеет обнаруживать и использовать типы (а также, представления и статический контент), определенные как в проектах (в виде исходного кода или NuGet-пакетов), на которые есть явные ссылки в зависимостях, так и в проектах, которые размещены в определенной папке в виде скомпилированных DLL-сборок.

Для удобства, опционально, эти проекты могут быть условно объединены в расширения (т. е. каждое расширение может состоять из одного или многих проектов). Также, каждое расширение может иметь класс (в одном из проектов), реализующий интерфейс IExtension, а ExtCore, в свою очередь, позволяет в любой момент получить доступный набор экземпляров всех классов, реализующих этот интерфейс. Эти классы можно использовать для предоставления метаданных, описывающих расширения, инициализации расширений (например, регистрации маршрутов) и т. д.

Хотя непосредственно сам фреймворк и не содержит какого-либо функционала, связанного с работой с данными, но все, что для этого необходимо (в т. ч. единый контекст хранилища для всех расширений), реализовано в расширении ExtCore.Data, о котором ниже.

Представляю вашему вниманию перевод документа "Coding Guidelines for C# 3.0, 4.0 and 5.0".

Целью создания этого списка правил является попытка установить стандарты написания кода на C#, которые были бы удобными и практичными одновременно. Само собой, мы практикуем то, что создали. Эти правила являются одним из тех стандартов, которые лежат в основе нашей ежедневной работы в AvivaSolutions. Не все эти правила имеют четкое обоснование. Некоторые из них просто приняты у нас в качестве стандартов.

Статический анализатор кода VisualStudio (который также известен как FxComp) и StyleCop могут автоматически применять многие из правил кодирования и оформления путем анализа скомпилированных сборок. Вы можете сконфигурировать их таким образом, чтобы анализ производился во время компиляции или был неотъемлемой частью непрерывной или ежедневной сборки. Этот документ просто добавляет дополнительные правила и рекомендации, но его вспомогательный сайт www.csharpcodingguidelines.com предоставляет список правил анализа кода, необходимых в зависимости от того, с какой базой кода вы работаете.

В этой статье я хочу рассказать о своей реализации паттерна под названием Long Polling для фреймворка Nancy. Коду моего модуля уже более четырёх лет, в течение которых он успешно работал в ряде проектов на ASP .Net MVC. На этой неделе я решил оформить его в виде модуля Nancy и выложить на гитхаб для всеобщего блага, поскольку аналогичного решения найти мне не удалось.

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

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

Хочу поделиться нашим opensource-решением для генерации docx документов, которое позволяет заполнять документы по шаблону, оформление которого можно менять в Word без переписывания кода.

Для начала — немного вводных.

Что нам было нужно от шаблонизатора

• Шаблон создается в Word и сразу видно, на что будет похож результирующий документ, шаблон без лишнего мусора.
• Результирующий документ после скачивания содержит все необходимые данные, не подтягивая их с внешних источников.
• Возможность заполнять списки, таблицы, и иногда еще и таблицы с вложенными в них списками.
• Шаблон можно доверить секретарю клиента, чтобы он мог сменить логотип, реквизиты компании, или как-либо еще подкорректировать оформление. И все это уже после сдачи проекта, не модифицируя наш код.

TL;DR: кроссплатформенный клон WPF. От других попыток сделать нечто с XAML-ом выгодно отличается наличием полностью своей системы отрисовки со сменными бакэндами (сейчас поддерживается Direct2D и Cairo). В наличии инспектор, дизайнер (см. видео). Биндинги сделаны на стероидах под названием ReactiveExtensions (старый стиль тоже можно использовать). Умеет работать с Windows/Linux/MacOS, поддержку мобильных платформ планируется добавить в начале следующего года посредством отрисовки через MonoGame.

Это вторая статья из миницикла статей про функциональный C#.

• Functional C#: Immutability
  
• Functional C#: Primitive obsession
  
• Functional C#: Non-nullable reference types
  
• Functional C#: работа с ошибками
  

Я написал небольшую, но полезную библиотечку для любителей TypeScript и ASP.NET MVC. Очень хотелось бы про нее рассказать — возможно какому-то разработчику на вышеупомянутой комбинации технологий (а возможно и целой команде) она существенно облегчит жизнь. Писать полноценную документацию на английском пока что времени нет. К ней вообще нужно подходить осмысленно, с чувством, толком и расстановкой. Поэтому я решил написать статью на Хабрахабр, и вот прямо сейчас, под катом, я сделаю краткий обзор и покажу какую магию можно делать этой штукой. Добро пожаловать.

Это первая статья из небольшой серии, посвященной программированию на C# в функциональном стиле. Серия не про LINQ, как можно было бы подумать, а про более фундаментальные вещи. Навеяно F#-ом.

• Functional C#: Immutability
  
• Functional C#: Primitive obsession
  
• Functional C#: Non-nullable reference types
  
• Functional C#: работа с ошибками
  

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

Здравствуйте, меня зовут Константин, я работаю front-end-разработчиком на информационно-развлекательном портале, основную долю контента которого составляют новости и статьи. И, конечно же, нам было крайне важно организовать удобную работу с порталом для наших редакторов. О том, каких успехов мы добились на данном поприще, и будет эта статья.

Здравствуйте, уважаемые читатели.

Сегодня мы хотели поговорить с вами на тему «все новое — это хорошо забытое старое» и вспомнить об акторах, описанных Карлом Хьюиттом еще в начале 70-х. А все дело в том, что недавно вышла вот такая книга:



Она довольно объемная — в переводе должна получиться более 500 страниц.

Несмотря на подчеркнутую элитарность книги (Akka и Scala), ее автор Вон Вернон (крупнейший специалист по DDD) уверен, что архитектурные паттерны, описанные в этой работе, вполне реализуемы на .NET и C#, о чем рассказывает в приложении. Мы же размещаем под катом перевод статьи, автор которой допускает перенос акторной парадигмы на язык Java. Поскольку рейтинг книги на Amazon стабильно высок, а тема универсальна, просим поделиться вашими мнениями как о ней, так и об акторной архитектуре в принципе.

Так как ранее я был разочарован количеством информации по этому вопросу, я решил восполнить этот пробел, собрав разные виды реализации 2Д платформеров, описав их сильные и слабые стороны и порассуждав над деталями реализации.

Моей целью было создать исчерпывающий и понятный путеводитель по реализации 2Д платформеров.



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

Четыре решения

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

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

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



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

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

После двух лет разработки закончена третья версия фреймворка PHPixie. Почему так долго? На самом деле за это время было написано не меньше трех ORM и шаблонизаторов, которые удалялись и переписывались опять, потому что «ааа, можно ведь сделать лучше». Особенно много времени ушло на тесты, без которых огромное количество улучшений просто не было бы замечено. Много раз хотелось просто оставить это дело, остановиться на второй версии и добавлять в нее модули. Но сейчас, когда все эти итерации были пройдены я могу уверенно сказать что это лучшая имплементация которую я знаю ( и на какую был способен ). Вот чем вас порадует PHPixie 3:

• Следование стандартам PSR-2 и PSR-4
• Поддержка PSR-7 запросов и библиотека для удобной работы с ними
• Шаблонизатор использующий простой PHP, но с поддержкой наследования и блоков как у Twig. Позволяющий легко добавлять свои расширения и другие форматы, например HAML итд.
• ORM который прост в использовании как ActiveRecord, но при этом разбивающий логику запросов, сущностей и репозиториев отдельно. Поддерживающий связи с коллекциями MongoDB и оптимизацию запросов над многими сущностями одновременно (например можно связать несколько статей с несколькими тэгами одним запросом)
• Подход с процессорами вместо привычных контроллеров позволяет создать произвольную архитектуру.
• Компонент конфигураций позволяющий разбивать настройки по в глубину по папкам (например ключ languages.en.plural.mouse может обратится к ключу plural.mouse в файле languages/en.php)
• Система бандлов позволяющая легко использовать один код в нескольких проектах и делится ним с другими пользователями. Бандлы устанавливаются через композер как любая другая библиотека.

А сейчас короткий туториал, который покажет вам все что надо знать чтобы начать разработку с PHPixie 3:

Те кто так или иначе связан с веб разработкой скорее всего знает что такое Bootstrap.
Лично я познакомился с фреймворком Bootstrap версии 2.x и он на меня произвел неизгладимое впечатление. Можно было без участия дизайнера получить вполне сносный интерфейс. Встроенный перфекционист ликовал. Можно ругаться, что интернет стал очень уж бутстраповым, но нужно отдать должное, парни, работающие над ним в целом молодцы и делают нужное, а то, что народ ленивый – проблема другая.

Сегодня день рождения этого замечательного фреймворка. В свой день рождения был объявлен Bootstrap 4.

Woohoo! Twitter Bootstrap, an open-sourced CSS/HTML framework from myself and @fat, just went live: http://t.co/3OOsQ5T #kaboom

— Mark Otto (@mdo) 19 августа 2011

Привет, меня зовут Глеб, и я занимаюсь автоматизацией тестирования в 2ГИС. Больше года назад я писал о нашем инструменте Cruciatus — с его помощью мы тестируем UI desktop-приложений под Windows.

Cruciatus отлично решает задачу доступа к контролам, но тесты пишутся строго на C#. Это мешает шарить знания и опыт между тестировщиками под разные платформы: mobile, web и desktop.

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

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

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

Как сказано на самом сайте, Fixie – Conventional Testing for .NET. Т.е. тестирование по соглашению. Под соглашениями здесь понимается то, к чему мы в целом привыкли – все операции выполняются на основе «устного» договора, джентельменского соглашения об именовании. Ближайший пример – scaffolding. Это когда мы договорились, например, что тестовые классы содержат слово Test, или что тестовые классы должны быть публичными и ничего не возвращать.  Тогда такие классы будут распознаны как тестовые. И больше никаких атрибутов и всего такого прочего. Просто классы и методы.

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