Несколько недель назад я обнаружил пост "Окисляем Source Maps с Rust и WebAssembly"
распространяющийся по Твиттеру и расказывающий о выигрыше в производительности от замены обычного JavaScript в библиотеке source-map на Rust, скомпилированный в WebAssembly.

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

Так что я скачал библиотеку с GitHub и отправился в небольшое исследование производительности, которое я документирую здесь практически дословно.

Сегодня команда ASP.NET анонсировала, что проект Blazor был перемещён в репозиторий организации ASP.NET. Мы начинаем стадию эксперимента, чтобы понять сможем ли мы развить Blazor в поддерживаемый продукт. Это большой шаг вперёд!



Что такое Blazor? Это фреймворк для браузерных приложений, написанный на .NET и запускающийся с помощью WebAssembly. Он даёт вам все преимущества богатых современных одностраничных приложений (SPA), позволяя при этом использовать .NET от начала и до конца, вплоть до общего кода на сервере и клиенте. В посте с анонсом подробно описаны основные случаи применения, сроки и так далее.

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

Последние три года я занимаюсь разработкой серверов на Node.js и в процессе работы у меня накопилась некоторая кодовая база, которую я решил оформить в виде фреймворка и выложил в open-source.

Основными особенностями фреймворка можно назвать:

• простую архитектуру, без всякой JS – магии
• автоматическую сериализацию/десериализацию моделей (например, не нужно проверять пришло ли поле с клиента, все проверяется автоматически)
• возможность генерации схемы API
• генерацию документации на основе схемы
• генерацию полностью типизированного SDK для клиента (на данный момент речь про JS frontend)

В данной статье мы поговорим немного о Node.js и рассмотрим данный фреймворк

Всем кому интересно – прошу под кат

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

Такой способ создания программного обеспечения используется в процессах Непрерывной интеграции (Continuous Integration) и Непрерывного развертывания (Continuous Deployment), или CI/CD-цепочке. В этой статье мы пройдем по всем шагам настройки такой цепочки, используя для ее построения бесплатные облачные сервисы.

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

Статья будет полезна тем, кто хочет:

— в общих чертах понять, что такое авторское право (но лучше обратиться к юристу);
— подобрать свободную лицензию для своего проекта;
— разобраться, что нужно писать в шапке файла исходного кода.

Приветствую.

Существует приложение для iOS — Tydlig, которое буквально переосмысливает калькулятор, и делает его потрясающе удобным. Попользовавшись один раз этим приложением, остаешься его любителем.

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

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

Поиск чего-то похожего на Tydlig ничего не дал, и было принято решение писать свое приложение.

Что из этой затеи получилось:

При работе с WPF/Silverlight, периодически приходится создавать кастомные DependencyProperty, в основном при создании контролов. Стандартный подход объявления и работы с ними не идеальный и имеет минусы, о которых будет сказано ниже. Соответственно, появилась идея упростить запись регистрации и работы с DependencyProperty.

Привет, Хабр!

Хочу поделиться с общественностью своей небольшой (всего 6 Кбайт) js-библиотекой, которая сильно облегчает мне работу с формами при разработке сайтов, и позволяет сократить написание кода.

Каждый разработчик Windows Store приложений должен знать гайдлайны.
Guideline в переводе с английского — рекомендации, руководящие указания. Для того, чтобы приложение попало в Store не обязательно следовать рекомендациям, но следовать им желательно. Есть несколько особенностей, или иноземно выражаясь фич (англ. feature), которые желательно иметь каждому приложению. Я решил рассмотреть эти особенности, а заодно сделать шаблон C#/XAML приложения Windows Store, с которого можно начинать разработку. Ведь, так или иначе, часто приходится заходить в разработанные ранее приложения или MSDN, чтобы скопировать код сниппета для определенной функции.
Описанные далее возможности не только сделают ваше приложение соответствующим гайдлайнам, но и украсят его дополнительным функционалом, привлекающим внимание пользователей, а также помогут в продвижении.

Интернет на волне всеобщей прослушки и связанной с этим паранойи постепенно переходит на тотальный SSL. К сожалению, пока это сделать не очень просто и обычно не бесплатно. Из бесплатных сервисов годные сертификаты, поддерживаемые всеми браузерами, предоставляет сервис StartSSL. В середине 2015 года при поддержке Mozilla, Cisco и других уважаемых организаций будет организована раздача бесплатных сертификатов в автоматическом режиме.

29 апреля 2015 года в Москве прошла бесплатная конференция сообщества SkillsWiki о профессиональном развитии.

Что интересного было на конференции? Какие навыки требуются от .NET-разработчика на американском рынке? Вы смогли бы оценить, шагаете ли вы в ногу со временем. Только ли знания и навыки определяют уровень вашей заработной платы, или есть еще важные факторы, которые определяют вашу ценность с точки зрения работодателя? Как говорить с работодателем о вашем росте и повышении заработной платы?

Не смогли принять участие в конференции? Ничего страшного. В этой заметке представлены все материалы конференции. Но в будущем не пропускайте наши конференции и вступайте в сообщество SkillsWiki!

Камень преткновения — GC

Все managed языки такие как Java или C# имеют один существенный недостаток — безусловное автоматическое управление паматью. Казалось бы, именно это и является преимуществом managed языков. Помните, как мы барахтались с dandling-указателями, не понимая, куда утекают драгоценные 10KB в час, заставляя рестартать наш любимый сервер раз в сутки? Конечно, Java и C# (и иже с ними) на первый взгляд разруливают ситуацию в 99% случаев.

Так-то оно так, только вот есть одна проблемка: как быть с большим кол-вом объектов, ведь в том же .Net никакой магии нет. CLR должен сканировать огромный set объектов и их взаимных ссылок. Это проблема частично решается путём введения поколений. Исходя из того, что большинство объектов живёт недолго, мы высвобождаем их быстрее и поэтому не надо каждый раз ходить по всем объектам хипа.

Но проблема всё равно есть в тех случаях, когда объекты должны жить долго. Например, кэш. В нём должны находиться миллионы объектов. Особенно, учитывая возрастание объемов оперативки на типичном современном серваке. Получается, что в кэше потенциально можно хранить сотни миллионов бизнес-объектов (например, Person с дюжиной полей) на машине с 64GB памяти.

Однако на практике это сделать не удаётся. Как только мы добавляем первые 10 миллионов объектов и они “устаревают” из первого поколения во второе, то очередной полный GC-scan “завешивает” процесс на 8-12 секунд, причём эта пауза неизбежна, т.е. мы уже находимся в режиме background server GC и это только время “stop-the-world”. Это приводит к тому, что серверная апликуха просто “умирает” на 10 секунд. Более того, предсказать момент “клинической смерти” практически невозможно.
Что же делать? Не хранить много объектов долго?

Зачем

Но мне НУЖНО хранить очень много объектов долго в конкретной задаче. Вот например, я храню network из 200 миллионов улиц и их взаимосвязей. После загрузки из flat файла моё приложение должно просчитать коэффициенты вероятностей. Это занимает время. Поэтому я это делаю сразу по мере загрузки данных с диска в память. После этого мне нужно иметь object-graph, который уже прекалькулирован и готов “к труду и обороне”. Короче, мне нужно хранить резидентно около 48GB данных в течении нескольких недель при этом отвечаю на сотни запросов в секунду.

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

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

2ГИС выпускает справочники и карты городов с 1999 года. За это время мы прошли большой технологический путь — от одного ПК-приложения с данными для Новосибирска до API карт и справочника, десктопных приложений на Windows, Ubuntu и OS X, мобильных приложений на Android, iOS, Windows Phone и Blackberry с данными по 270 городам мира.

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

Этими инструментами с удовольствием делимся на Гитхабе, а для удобства сделали ещё и Open Source раздел на 2ГИС.Технологиях. Чтобы вы разобрались, что есть что, мы расскажем о наших флагманских инструментах с открытым кодом.

На перевод этой статьи меня подтолкнуло обсуждение записей «Почему WPF живее всех живых?» и «Семь лет WPF: что изменилось?» Исходная статья написана в 2011 году, когда Silverlight еще был жив, но информация по WPF не потеряла актуальности.

Сначала я не хотел публиковать эту статью. Мне казалось, что это невежливо — о мертвых надо говорить либо хорошо, либо ничего. Но несколько бесед с людьми, чье мнение я очень ценю, заставили меня передумать. Вложившие много усилий в платформу Microsoft разработчики должны знать о внутренних особенностях ее работы, чтобы, зайдя в тупик, они могли понимать причины произошедшего и более точно формулировать пожелания к разработчикам платформы. Я считаю WPF и Silverlight хорошими технологиями, но… Если вы следили за моим Twitter последние несколько месяцев, то некоторые высказывания могли показаться вам безосновательными нападками на производительность WPF и Silverlight. Почему я это писал? Ведь, в конце концов, я вложил тысячи и тысячи часов моего собственного времени в течение многих лет, пропагандируя платформу, разрабатывая библиотеки, помогая участникам сообщества и так далее. Я однозначно лично заинтересован. Я хочу, чтобы платформа стала лучше.

Есть такой язык программирования, который называется C#. И есть очень много разработчиков, которым он очень нравится. А ещё есть такой язык программирования, который называется JavaScript. Как-то так сложилось, что он нравится далеко не всем C#-разработчикам. А теперь представьте ситуацию: есть заядлый C#-разработчик. Он очень любит C#, все-все проекты на нём пишет. Но судьба распорядилась так, что ему понадобилось написать клиентское веб-приложение. Знаете, такое, чтобы пользователю не нужно было себе ничего скачивать и устанавливать, чтобы он мог просто открыть любой браузер в любой операционной системе на любом устройстве — а приложение уже там. И вот тут у нашего лирического героя возникла проблема: вроде бы JavaScript идеально подходит для этой задачи, но вот писать на нём отчего-то не очень хочется. К счастью, в современном мире существует много языков, которые транслируются в JavaScript (всякие TypeScript, CoffeScript и тысячи других). Но наш разработчик оказался очень упрямым: он упорно не хочет изменять своему любимому C# с «вражескими» технологиями.

К счастью для него, счастливое будущее уже практически наступило. Есть такой проект, который называется DuoCode. Он умеет транслировать C#-код в JavaScript. Пока он в состоянии beta, но у него уже весьма неплохо получается: поддерживаются нововведения C# 6.0, Generic-типы, Reflection, структуры и LINQ, а отлаживать итоговый JavaScript можно на исходном C#. Давайте посмотрим внимательнее, что же представляет из себя продукт.

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

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

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

РТС Mathcad – это характерный пример математического ПО, предназначенного для осуществления, как численных, так и аналитических расчетов по формулам и визуализации их результатов в виде графиков.

Да-да, вы все правильно поняли, это статья об еще одном велосипеде — о моем Dependency Injection (DI) контейнере. За окном уже 2015-ый год, и самых разных контейнеров на любой вкус и цвет полным полно. Зачем может понадобиться еще один?

Во-первых, он может просто образоваться сам собой! Мы в Эльбе довольно долго использовали этот контейнер, и некоторые из описываемых в статье идей (Factory Injection, Generics Inferring, Configurators) изначально были реализованы поверх него через публичное API.

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

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

Эта статья — не введение в DI. На эту тему есть много других прекрасных публикаций, в том числе и на Хабре. Скорее здесь собран набор рецептов приготовления DI так, чтобы получившееся блюдо было вкусным, но не острым. Если у вас DI-контейнер в продакшене или вы написали свой собственный самый лучший контейнер, то здесь отличное место для холиваров о том, чей контейнер круче!

Часть первая, историческая

Сейчас историки пытаются преподнести,
что в тысяча пятьсот каком-то году
что-то там было.
Да не было ничего!
В. С. Черномырдин

Итак, все началось в далеком 2006 году, когда я попал в it-компанию, которая занималась разработкой решений в области телекоммуникаций. Наша команда разрабатывала приложение на C#, которое получало некоторые данные из базы данных MS Sql Server, обрабатывало их и складывало обратно. Сначала в нашей базе было около 10 таблиц и пара хранимых процедур. Со временем число таблиц и других объектов стало расти. Мы начали задумываться, как управлять этими объектами. Скрипты мы хранили в системе контроля версий.