C# *

Всем привет!

Как многие хабровчане уже знают, уже через 4 недели в Москве мы проведём конференцию для .NET-программистов .NEXT 2014 Moscow. В кратчайшие сроки, буквально за пару недель, нам удалось собрать мощнейшую команду докладчиков. В ней и тулмэйкеры из JetBrains и DevExpress, и евангелисты из Microsoft (куда ж без них?), и внезапно топы местного .NET-хаба.

На сегодняшний день (вт, 11 ноября) мы анонсировали18 докладов (UPDATE: уже 19 — добавился Дино Эспозито, автор крутейших книг по ASP.NET), но это ещё не всё. Программа сформирована примерно на три четверти. Изначально мы хотели сделать 3 параллельных зала, но теперь, видимо, придётся сделать и четвёртый.

Хотите узнать, что у нас получилось? Давайте под кат.

Добрый день, читатели Хабра!

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

В Москве в C# есть сложившийся рынок труда с уровнем сопротивления в 120-130.000 и условным потолком в 180.000 рублей. На этих уровнях достаточное предложение качественной рабочей силы при ограниченном количестве позиций. Скоро этот рынок будет перекроен из-за изменения курса доллара. Как быстро дойти до этих уровней и даже преодолеть их?

Для этого важно понять, что успех на рынке труда зависит в первую очередь от сочетания навыков, а не от глубины владения каким-то одним вопросом. Важно, какую дорогу вы выберете, а не как быстро по ней пойдете. Как узнать, куда идти? Нужно ли обгонять коллег или все могут зарабатывать больше?

Часто у новичков в той или иной IT области ощущается острый дефицит знаний и знакомых, у которых можно что-либо «спросить» по теме. Да, StackOverflow, Google и другие подобные ресурсы — просто кладезь полезной информации, однако, согласитесь, бывают и ситуации, когда вопрос настолько общий, что ответ на него может дать только опытный человек работающий в этой сфере не первый год.

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

И вот тут пролетела мысль — а почему бы не сделать IT-чаты и разбить их на определённые темы/технологии? Ок, попробуем. И Skype нам тут поможет.

Если вы хотите узнать, почему был выбран Skype, каким образом можно «обойти» лимит в 300 человек на один чат или у вас просто спряталась альтруистичная IT-нотка и вы любите помогать коллегам — берите печеньки и добро пожаловать под кат.

Если у вас есть некий процесс, который может выполняться долго и возвращать несколько промежуточных результатов с течением времени, то Реактивные Расширения (.NET Framework Reactive Extensions) позволят вам упростить код и лучше управлять им.



В большинстве случаев вы просто вызываете метод и получаете результат на выходе. Но некоторые процессы устроены по-другому. Например, метод может выполняться в течение продолжительного промежутка времени. Или, что хуже, метод не только выполняется долго, а ещё и нерегулярно возвращает какие-то промежуточные результаты во время исполнения. Конечно, в том числе и для этого, в .NET Framework есть события, с помощью событий один объект может вызвать метод второго объекта, передавая некоторую информацию, в тот момент времени, когда это необходимо.

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

Пример редактора уровня в игре.

Если вы когда либо играли в игры типа Guitar Hero, Osu или Bit Trip Runner вы знаете, как сильно погружает в «поток» простая зависимость геймплея от музыки играющей на фоне. Удивительно, что таких игр, на самом деле не так уж и много. Кроме того, такая синхронизация может быть полезна для создания спецэффектов, но тем не менее почти нигде не встречается, кроме обозначенных выше игр типа rhythm. Вот и я решил воспользоваться таким бесхитростным приемом в собственной игре, а также поделиться наработками.

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

Привет, хабраюзер! В этом посте я расскажу, как можно сделать свой код на Хабре более «живым» благодаря простому способу сохранения его оригинальной цветовой схемы. А также предлагаю сравнить различные варианты расцветки кода.

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

Не будет:
• Классического Unit Test;
• Принижения влияния Code Behind;
• Неожиданных открытий в MVC.

Будет:
• Unit Test и Stub;
• MVC;
• Внедрение подхода на базе существующего продукта.

В процессе разработки плагина для Unity 3D понадобилось сделать хранение относительно большого количества данных. В моем случае это хранение данных нодов для визуального программирования (так же применим и к реализации сохранения игры). Способ хранения должен отвечать заданным требованиям:

• Высокая скорость обработки;
• Высокий уровень сжатия данных;
• Возможность хранения своих классов и структур;
• Чтение\запись в Unity, а так же в отдельной программе (Visual Studio Application, C#);
• Работать со старыми версиями сохраненных данных (при изменении структуры);
• Не должен требовать наличие дополнительно установленных пакетов и др. ПО у пользователей;
• Работать на мобильных устройствах;
• Язык: C#.

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

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

Создадим класс под названием “Peer” далее подключим пространства имен “SetNet“ и унаследуем класс “Peer” от базового класса “PeerBase“. Класс должен иметь следующий вид:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using SetNet;
using SetNet;
 
namespace Server
{
    class Peer:PeerBase
    {
 
    }
}

Что же такое SetNet? SetNet (SetNet Server, sns) — Это сетевое решение, написанное на C#. С помощью данного решения Вы легко сможете создать приложения с поддержкой сети или же для сетевых игр.

В этой публикации я постараюсь предельно просто рассказать, как можно легко и быстро сделать динамическое освещение в 2D игре на XNA; без шейдеров, карт нормалей и вообще, без дополнительных ресурсов. Целью у нас будет красивая игровая сцена с ночным небом, темным задним фоном, освещенным фонарями, передним фоном и игровым меню. Количество источников света не ограничено (в разумных пределах, конечно), форма произвольная. Освещается только передний фон. Читателю желательно иметь элементарные навыки работы с XNA, поскольку будет много кода.

От многой мудрости много скорби, и умножающий знание умножает печаль: чем глубже вникаешь в особенности мира IT, особенно той его части, которая про защиту информации, тем крепче паранойя. И это совсем не означает, что за тобой не следят. В очередном приступе тревоги за сохранность нажимаемых кнопок я удалил Punto Switcher. Однако без переключения раскладки после уже набранного слова, к которому я так привык, стало очень тоскливо. Никаких вменяемых альтернатив я так и не нашел, поэтому пришлось написать небольшую обертку над парой функций win api.

Возможно, результат нескольких дней тыканья веточкой в user32.dll понадобится еще нескольким людям, в виде самой программки, либо в качестве примера отправки сообщений окнам из .Net, так что вот: аналог punto switcher, без свистелок, перделок и яндекс бара.

К сожалению, в скайпе так и не работает. Буду благодарен, если кто-то опытный укажет мне на ошибки в коде.

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

Я пытаюсь восстановить исходники по .dll-библиотеке и .pdb-базе. Использование IDA конечно принесло кое-какие результаты, но не удовлетворительные. Возможно я просто недостаточно усидчив. Поэтому я начал с другой стороны — с восстановления каркаса проекта библиотеки. Так как у меня есть .pdb-база я вполне могу это сделать. Теоретически. Теоретически, потому что в базу записывается информация с препроцессированых файлов, а не с исходников. А значит нужно работать дальше.

Данная публикация навеяна другой. Она называется «Контроллер для домашней пивоварни Mega Brewery. Part I» и опубликована за авторством megadenis.

С чего все началось?

Я студент технического ВУЗа. Однажды, сидя в кафе с другом, который тогда учился в медицинском университете, решили открыть бар. Было много идей, которые, в принципе, заслуживали некоторого внимания. Например, танц-пол, который изменяет угол наклона в зависимости от стиля музыки… Но, наряду со всем многообразием идей, так же была еще одна —

… а не сварить ли нам свое пиво?

Через пару недель я сварил пиво, взяв ингредиенты с пивзавода, на котором работал друг отца. Но многие технологические процессы были нарушены, поэтому вместо пива вышло что-то с не очень приятным запахом.

Через несколько лет решил повторить процесс, немного автоматизировав его с помощью Arduino UNO. И вот, что получилось.

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

• Трекинг источников установок (такие инструменты как Mobile App Tracking, AppsFlyer и ADXtracking, используются, как правило, для продвижения приложений);
• Аналитика внутри приложения (наиболее известные инструменты – это Flurry, Google Analytics, Яндекс.Метрика и Mixpanel, которые предоставляют возможность наблюдать за поведением пользователей внутри мобильного приложения, что позволяет принять решение о дальнейшем развитии вашего продукта);
• Сбор статистики из магазинов приложений (самые популярные сервисы – это App Annie и Distimo, позволяют отслеживать позицию в сторе как вашего приложения, так и конкурентов).

Поскольку данная статья предназначена для разработчиков, речь в ней пойдет о том, как внедрить аналитику в приложение Windows Phone. В качестве системы аналитики будет рассмотрена Flurry Analytics.

Добрый день, читатели Хабра!

Сейчас моим языком разработки является C# и я веду парочку своих проектов, где выполняю роль менеджера и программиста. Мое программирование на C# первые годы шло с «задержкой в развитии». Хотя я не совсем бестолковый программист, еще студентом я сделал несколько программных продуктов на Access+VBA и некоторые «живы» уже более 10 лет.

В чем я отставал: долго пересаживался с Visual Basic на C#, не знал всех средств языка – делегатов, лямбда выражений, linq. Много раз слышал слова, но так и не понимал, зачем нужны design patterns. Долго «слезал» с WinForms, долго переходил на MVC с обычных Asp.Net WebForms, не использовал контроль версий. Да много чего еще проходило мимо меня.

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

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

Сейчас объем доступного контента для обучения превышает наш бюджет времени. Поэтому самое важное – это определить, куда развиваться, так сказать «куда копать».
Тем не менее, события, анонсы которых я периодически вижу, не давали того, что я хотел.
Например, я не хочу долго сидеть на стуле в аудитории и вынужденно слушать долгий доклад.
И не хочу платить завышенную цену за «эксклюзивный» контент, который я могу найти в интернете.
Не хочу прийти и уйти, ни с кем не познакомившись. Каким может быть полезное решение? Об этом далее.

С давних времён я был большим поклонником System.Collections.Concurrent и BlockingCollection в особенности. Сколько раз это чудо инженерной мысли выручало в самых разнообразнейших ситуациях — не счесть.

С чуть менее давних времён в обиход прочно вошли async/await. Казалось бы, жизнь прекрасна, но есть одно «но»: асинхронный код миксовать с блокирующим кодом как-то не очень-то хочется. А BlockingCollection, как несложно догадаться (хотя бы из названия), в ряде случаев поток блокирует.

Жило-было консольное приложение, которое создавало appdomain и запускало в нём сервис на основе Topshelf. Но однажды в нём появился баг – после нажатия Ctrl-C оно не завершало свою работу, а сообщало о получении команды на выключение и зависало в таком состоянии. Краткий анализ показал, что зависало оно на выгрузке домена, но, что странно, не выкидывало исключение CannotUnloadAppDomainException.

Готовился я как-то к собеседованию по C# и среди прочего нашел вопрос примерно следующего содержания:

«Как организовать потокобезопасный вызов события в C# с учетом того, что большое количество потоков постоянно подписываются на событие и отписываются от него?»

Вопрос вполне конкретно и чётко поставлен, поэтому я даже не сомневался в том, что ответ на него можно дать также чётко и однозначно. Но я очень сильно ошибался. Оказалось, что это крайне популярная, избитая, но до сих пор открытая тема. А еще заметил не очень приятную особенность — в русскоязычных ресурсах этому вопросу уделяется очень мало внимания (и хабр не исключение), поэтому я решил собрать всю найденную и переваренную мной информацию по данному вопросу.
До Джона Скита и Джеффри Рихтера тоже дойдем, они то, собственно, и сыграли ключевую роль в моем общем понимании проблемы работы событий в многопоточной среде.

Особо внимательный читатель сможет найти в статье два комикса в стиле xkcd.
(Осторожно, внутри две картинки примерно по 300-400 кб)

— Xamarin Insights — новая система мониторинга отслеживает все происходящее в приложении от непойманных исключений до кликов на кнопки, включая продолжительность операций и данные об устройстве

— эмулятор Xamarin Android Player запускается на Windows или Mac с помощью аппаратной виртуализации и позволяет быстро отлаживать приложения

— Sketches позволяют быстро набросать код на C# или F# и сразу увидеть результаты его выполнения включая интерфейс пользователя

— Xamarin Profiler собирает информацию по проблемах с производительностью и утечках памяти

— улучшения Xamarin Test Cloud включают в себя Xamarin.UITest — новый фреймворк для автоматического, кросс-платформенного тестирования пользовательского интерфейса в Xamarin Test Cloud, видеозапись происходящего на экране устройства во время теста и гиперпараллельное тестирование на большом количестве устройств, сокращающее время прохождения тестов

— шесть крупнейших разработчиков компонентов для .Net — Syncfusion, Telerik, Infragistics, Steema, ComponentOne, DevExpress, перенесли их на Xamarin.Forms. Все компоненты будут доступны в Xamarin Component store в этом году. Компоненты от SyncFusion и Telerik доступны прямо сейчас. Заключено партнерское соглашение с IBM, выражающееся в выпуске IBM MobileFirst SDK for Xamarin и IBM MobileFirst Add-Ons для Xamarin Studio и Visual Studio