В новостях Y Combinator проскочило упоминание очередного варианта реализации фреймворка для создания десктопных приложений на HTML5+CSS+JS. Этот проект называется AppJs.
Система строится на основе Node.js. На момент написания поста, проект имеет версию 0.0.2. Базовое открытие окон сделано только для Linux и немного для Windows. Для Mac пока ничего не работает. Исходники на GitHub.
Никакой большой коммерческой организации за проектом не замечено. Лицения MIT.
Некоторое время с мучался с тем, что в VisualStudio 2010 невозможно быстро перейти в чужие исходники. Надо было выкачивать, подключать и т.п.
Но сегодня я внимательно посмотрел на окно ReSharper -> Options -> External Sources. И, о чудо, там есть галочка «Allow downloading from external locations»! Для библиотеки Nancy, с которой я сейчас вожусь, исходники оказались, что мне сильно помогло. Буду надеяться с остальными опен-сорсными либами ситуация будет аналогичная.
И пожелание к JetBrains напоследок – сделайте, пожалуйста, напоминалку про эту фичу при переходе на дизассемблер чужих либов.
Система непрерывной интеграции Atlassiat Bamboo включает множество плагинов для работы с тестами, но поддержка xUnit.net в это множество, к сожалению, не входит. Но интеграция все же возможна, о ней и расскажем.
Итак, имеется solution, состоящий из множества проектов. Проекты, которые собираются в assembly, и названия которых заказчиваются на Tests являются комплектами xUnit тестов. Сборка всего решения построена на MSBuild, осуществляется сервером Bamboo. Для управления внешними сбоками используется NuGet.
Читать далее…
Сейчас я занимаюсь проектом, который разрабатывался достаточно большое время, но в разработке не применялось никаких правил оформления кода. Поскольку так жить нельзя, считаю важным привести свое видение того, как имеет смысл оформлять код на C#.
Использование такого стиля позволяет:
- Быстро ориентироваться
- Не задумываться над оформлением
- Применять автоматические инструменты контроля стиля (ReSharper)
Описание рассчитано на использование C# версии 3.5.
Читать далее…
В статье ранее я писал как сделать автоматическую реализацию INotifyPropertyChanged на основе расширений библиотеки NInject. К сожалению, моя жизнь с этой библиотекой не сложилась, NInject был заменен на Spring.NET. При этом схему автореализации надо было как-то перенести без особенных изменений прикладного кода. Объясню, что именно я сделал.
Читать далее…
Около полугода я следил на развитием проекта Titanium Desktop. Идея продукта состоит в том, что можно создавать полноценные desktop приложения на HTML+JS. Я подумывал использовать этот фреймворк в одном из своих проектов. Но сегодня, проверяя новости, обнаружил нерадостное – проект снимают с финансирования AppCelerator и передают сообществу разработчиков. Официальный пресс-релиз можно прочитать здесь.
Все это означает, что проект может приостановиться на неопределенный срок. А значит надо будет взвесить все «за» и «против» прежде чем использовать.
В качестве альтернативы предлагается chromiumembedded, который тоже находится в непонятном состоянии. По этому проекту даже с документацией есть проблемы, вся поддержка – через полуживой форум.
Таким образом, многоплатформенных технологий для создания desktop приложений на HTML+JS в доступности не видно. Разве что Adobe AIR, но он пугает чем, что Adobe.
При разработке для платформы .NET часто приходится делать так раздражающие всех реализации интерфейса INotifyPropertyChanged на классах-моделях. Типичный пример выглядит так:
class StatisticsRecord: INotifyPropertyChanged
{
private string name;
public string Name { get { return name; } set { name = value; NotifyPropertyChanged("Name"); } }
private void NotifyPropertyChanged(string name)
{
if (PropertyChanged != null)
PropertyChanged(this, new PropertyChangedEventArgs(name));
}
public event PropertyChangedEventHandler PropertyChanged;
}
На мой взгляд, с этим кодом есть 2 проблемы:
- Очень много повторений и кода вызванного необходимостью вызвать
NotifyPropertyChanged. Увеличивается количество «тупой» работы.
- Использование строковой константы Name в качестве аргумента. Рефакторинг может привести к разрушению биндинга к такому свойству.
Читать далее…
В начале создания авто-тестов в одном проекте на C# начал возникать System.BadImageFormatException при попытке запуска тестов из ReSharper. Выяснение показало, что проблема была в том, что сборка с тестами имела Any CPU. А тестируемые классы были в EXE, который был собран в x86. При этом Windows используется 64х битный, следовательно Any CPU = x64.
Решение просто – указать в тестовой сборке целевую платформу x86. Это делается в закладке Build свойств проекта тестовой сборки.
После установки ReSharper на Visual Studio 2010 (всем разработчикам на C# рекоммендую, кста) наиболее активно разражает подсвечивание названий методов, который автоматически генерируются Visual Designer для обработки событий, поскольку название типа «Form1_Load» никак не соответствует идеям начинать название с глагола и не использовать «_». Но это можно исправить.
Читать далее…
Я считаю, без каких-то новых знаний жить не особо интересно. Поэтому стараюсь учиться. А тут Стэнфорд предлагает уникальную возможность бесплатно поучиться computer science.
Читать далее…
Свежие комментарии