Disclaimer: Я пишу в основном про Azure с точки зрения инфраструктуры (DSC, IaaS, Hybrid\Private Cloud, OMS, ASR, Backup и т.д.). Не про разработку под Azure (хотя иногда что-то проскакивает).

Продолжаем читать про Azure, третий выпуск. Было много довольно шумных новостей, из разряда SQL на линукс, поддержка Raspberry Pi 3 в Windows 10, но что прошло незамеченным?
Benjamin Armstrong про маленькие секреты Hyper-V. (offtop)

Electron — система позволяющая создавать кроссплатформенные приложения используя одни только веб-технологии, такие как HTML, CSS и конечно, JS.

Нужно отметить, что разработка на Электроне очень во многом отличается от обычного браузерно-серверного приложения на Node. О чем и будет эта статья.

Компания Microsoft анонсировала поддержку операционных систем семейства Linux в следующей версии SQL Server.

Это очередной шаг по выходу на рынок Linux систем после заключения партнерского соглашения с RedHat.

Также, анонс прокомментировал Марк Шаттлворт, основатель компании Canonical:
“Мы рады работать с Microsoft, когда они приносят SQL Server на Linux. Заказчики уже используют сервисы Azure Data Lake на Ubuntu, а теперь разработчики будут иметь возможность строить новые приложения со всеми возможностями промышленного SQL Server'а.”

На сайте SQL Server также уже появилась информация относительно новых возможностей СУБД.

Релиз версии ожидается в середине 2017 года.

Мы в «Латере» занимаемся созданием биллинга для операторов связи. В блоге на Хабре мы не только рассказываем об особенностях нашей системы и деталях ее разработки (например, обеспечении отказоустойчивости), но и публикуем материалы о работе с инфраструктурой в целом. Разработчик и системный архитектор Михаель Виттиг (Michael Wittig) написал в блоге Cloudonout интересный материал о наиболее распространенных ошибках при работе с сервисом AWS (Amazon Web Services). Мы представляем вашему вниманию основные тезисы этой заметки.

Мы рады поделиться с вами очередной статьей из серии статей о облачных сервисах Microsoft Azure. В этот раз Андрей Антюфеев — руководитель программ Microsoft из команды SQL Server и Azure SQL Database, продолжит свой рассказ о работе с индексами в облачной БД Azure SQL Database. — Владимир Юнев

Всем привет, эта заметка будет полезна всем, кто пользуется Azure SQL Database.


В прошлой раз, мы обозревали первую версию Index Advisor. C тех пор помощник успел дорасти до GA, повысив стабильность, и обзавестись новым возможностями:

• возможность автоматически применять рекомендации помощника
• новые рекомендации (Drop Index)
• визуализация нагрузки после создания индекса
• другие улучшения

Забудьте об управлении индексами

Процесс создания новых индексов происходит в несколько этапов:

Началась эта история довольно давно, когда я впервые попытался работать с UI не из UI-потока. И когда я начал ловить различные “глюки”, я понял, что делать это нужно осторожно. Позднее я столкнулся с этим в дотнет мире и именно в тот момент я впервые познакомился с SynchronizationContext. Но тогда, почитав про устройство этого объекта, я посчитал, что этих знаний мне достаточно. Сделать это можно, например, здесь: SynchronizationContext — когда MSDN подводит.

Вспомнил про SynchronizationContext я только с выходом c# 5 и его async/await, т.к. этот механизм взаимодействует как раз с этим самым контекстом синхронизации. Делается это для того, чтобы после асинхронной операции, код мог выполняться в вызывающем асинхронную операцию потоке, что очень удобно при работе с UI. Но запустив этот небольшой код в UI-потоке и любом другом:

Debug.WriteLine(Thread.CurrentThread.ManagedThreadId);
await Task.Run(() => Debug.WriteLine(Thread.CurrentThread.ManagedThreadId));
Debug.WriteLine(Thread.CurrentThread.ManagedThreadId);

Мы увидим, что код возвращается в исходный поток только при запуске в UI-потоке. Все дело в том, что контекст синхронизации задан только в UI-потоке (кроме wcf и т.д.). В голову сразу же приходит мысль, нужно просто задать контекст синхронизации нужному потоку. Но здесь нас ждет проблема, стандартная реализация SynchronizationContext не дает нам нужных возможностей. Она позволяет продолжать исполнять код в текущем потоке или в потоке из пула. После того, как я не нашел реализации, которую можно просто скопировать, запустить и увидеть желаемый результат, я решил попробовать реализовать свою и представить, как бы оно могла выглядеть на деле. Об этом и пойдет речь ниже.

От переводчика:
Многие знают, что ffmpeg — это сила, но не все знают, какая именно. Он многогранен и безграничен, а его man объёмен и местами малопонятен, лишь немногие постигли дао профессиональной работы с ним. И тем не менее, этот инструмент может быть полезен почти всем, кто хоть иногда работает с видео и звуком, даже на бытовом уровне. О некоторых полезных консольных командах ffmpeg и пойдёт речь в статье. В некоторых местах я взял на себя смелость вставить ссылки на поясняющие статьи.

ffmpeg — это кроссплатформенная open-source библиотека для обработки видео- и аудиофайлов. Я собрал 19 полезных и удивительных команд, покрывающих почти все нужды: конвертация видео, извлечение звуковой дорожки, конвертирование для iPod или PSP, и многое другое.

1. Получение информации о видеофайле

ffmpeg -i video.avi

2. Превратить набор картинок в видео

ffmpeg -f image2 -i image%d.jpg video.mpg

Эта команда преобразует все картинки из текущей директории (названные image1.jpg, image2.jpg и т.д.) в видеофайл video.mpg

(примечание переводчика: мне больше нравится такой формат:

ffmpeg -r 12 -y -i "image_%010d.png" output.mpg

здесь задаётся frame rate (12) для видео, формат «image_%010d.png» означает, что картинки будут искаться в виде image_0000000001.png, image_0000000002.png и тд, то есть, в формате printf)

Вступление

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

Вот список основных требований к реализуемому модулю:

• Возможность выполнения основных операций с IIS:
  
  • создание сайта
  • создание virtual application
  • создание virtual directory
  • настройка bindings для сайтов, включая установку сертификатов SSL
  • создание пулов приложений с детальной настройкой
• Поддержка параллельной работы с несколькими IIS на разных серверах фермы
• Поддержка IIS версии 8.0 (более ранние версии поддерживать не нужно).

Одним словом, модуль должен был уметь практически всё, что можно сделать через IIS Manager.

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



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

Целевая аудитория: системы, которым нужна несложная CMS, не влияющая на архитектурное решение. (CMS, как хранилище контента, без генерации форм и т.п.)

Цель данной статьи – в «2х словах» показать, как можно использовать Umbraco CMS в качестве источника данных, от которого глобально не зависит основное приложение (ведь источник в любой момент можно заменить на любой другой), другими словами, как вынести CMS в отдельный проект.

Некоторое время назад я узнал об Umbraco CMS, которая сразу привлекла мое внимание. Одним из основных ее преимуществ для меня явилось ее free openSource, со всеми вытекающими. Достаточно простой и эффективный дизайн, несложный бэкграунд, большое комьюнити и широкий ассортимент бесплатных расширений. С полным списком преимуществ и недостатков можно ознакомиться в сети. Меня огорчили всего два момента:

1. СMS предъявляет определенные претензии к структуре и платформе основного приложения, роутингу и т.п. Программирование на C# сводится к написанию User-контролов.
2. Исходя из первого пункта, на данный момент последнюю версию (4.10) невозможно использовать с ASP.NET MVC, который я так люблю. (видел в сети вариант с проектом «смешанного типа» — ASP.NET + ASP.NET MVC, но мне он тоже не понравился)

Мне же хотелось использовать CMS исключительно как модуль администрирования контента, данные которого я мог бы получить просто подключив пару-тройку библиотек к любому другому проекту. И, насколько я понял, Umbraco не предоставляет такой возможности по умлочанию. Кроме того, мне хотелось бы самостоятельно писать разметку страниц, логику биндинга данных на C#, определять layout, не возится с xslt, на котором построен ui-engine umbraco. Проведя некоторое время в поисках и не найдя ничего подходящего пришлось решить эту задачу самостоятельно.

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

Привет!

Сегодня и на ближайшие две недели в нашем хаброблоге тематическая секция — и посвящена она тому, чему последние несколько лет уделяется много внимания как от крупнейших корпораций (Microsoft, Intel, HP и др.), так и компаний меньшего масштаба, но с не менее интересными проектами (например, Aura) — а именно Интернету Вещей. Мы расскажем обо всём, что делаем.

Доброе утро, дорогие читатели.

Мы начнем неделю с такого информативного, пусть и несколько тезисного перевода, который поможет нам уточнить, насколько аудитория заинтересована в издании книг по ASP.NET. Практика показала, что книги Питера "Разработка приложений с испоользованием ASP.NET и AJAX" и "Программирование с использованием Microsoft ASP.NET 4" не пользовались бешеным спросом. Однако вполне возможно, что по результатам данного поста мы все-таки решимся замахнуться на ASP.NET 5 и MVC 6.

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

Меня зовут Илья Гребцов, я работаю Java/JS Developer в DataArt. Хочу поделиться кое-чем полезным с теми, кто работает с Salesforce.

В Salesforce часто возникает задача массово создать/изменить/удалить группу связанных записей в нескольких объектах, аналогах таблиц в реляционной базе данных. Например, часто используемые стандартные объекты Account (информация о компании клиента), Contact (информация о самом клиенте). Проблема в том, что при сохранении записи Contact необходимо указать Id связанной записи Account, т. е. аккаунт должен существовать на момент добавления записи контакта.

В реальности связи могут быть еще сложнее, например, объект Opportunity ссылается и на Account, и на Contact. Плюс возможны ссылки на какие-либо нестандартные (custom) объекты. В любом случае, запись по ссылке должна быть создана раньше записи, на нее ссылающуюся.

Рассмотрим варианты решения этой проблемы:

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

Для статьи я подобрал наиболее полезные дополнения «на все случаи жизни».

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

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

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

Требования

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

• самозацикленные графы объектов (деревья с back-references)
• массивы структур (value types)
• классы/структуры с readonly полями
• инстансы существующих .Net коллекций (Dictionary, List), которые внутренне используют custom-сериализацию
• большое кол-во инстансов типов, специализированных для конкретной задачи

Речь пойдёт о трёх аспектах, которые очень важны в распределённых кластерных системах:

• скорость сериализации/десериализации
• объём объектов в сериализированном виде
• возможность использовать существующие объекты без надобности “украшения” этих объектов и их полей вспомогательными атрибутами для сериализации

Камень преткновения — 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-запросов в секунду.

Жил — был древний код эпохи динозавров

Дано: адов кодярник работающий с 16ю разными версиями одного и того же «ах какого» продукта. COM, Interop, интерфейсы, реализации, сигнлтоны с факторями, паттерны с антипаттернами, модули и прочие ошметки крывавого ынтырпрайзу. Стандартный набор. Рос, мужал и матерел тот кодярник лет семь. Пока однажды очередной фикс не привел к исправлению массового копипаста в 16 модулях. Если кому интересно — foreach на for меняли.

Помучившись, провели исследование. Копипаст на 95% идентичен, различаются только имена пакетов из интеропов.

А можно ли как-то писать так чтобы не оборачивать сотни и сотни функций в свои врапперы, плюс ручками боксинг / анбоксинг этих врапперов?

Есть же ключевое слово dynamic!

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

Много времени прошло с момента появления AngularJs (в масштабах веб-технологий конечно). Сейчас в интернетах есть огромное количество постов восхваляющих этот фреймворк до небес, что это манна небесная не иначе, а критики не так уж и много как он того заслуживает. Но такие статьи уже потихоньку начинают появляться, и меня это радует, надеюсь индустрия переболеет ангуляром так же, как переболела MooTools, Prototype, %какой-нибудь новый язык под JVM%, %другая-супер-революционная-технология%. Не знаю почему, но в IT-области такие революционные технологии, которые поднимают шум, а потом пропадают, появляются довольно часто. Хороший разработчик должен уметь отличать очередную модную технологию, от работающего инструмента. И для этого очень важно критически смотреть на вещи. Моя статья — это компиляция самых весомых выводов из других статей, и моих личных умозаключений. Ангуляр создает хороший вау-эффект, когда видишь его впервые: «ух ты, я написал ng-repeat, и реализовал эту логику одними тегами и все само обновляется!», но как только приходится реализовывать реальные приложения, а не очередной TODO-лист, то все становиться очень печально. Сразу хочу сказать, что фреймворк я знаю хорошо, даже больше чем мне хотелось бы его знать, я программировал на нем в течении 2 лет. И для следующего проекта я его точно не выберу, и это хорошо, все мы учимся на ошибках. Так что же не так с ангуляром? Тут нет однозначного ответа, слишком много разных недостатков, которые создают такой облик фреймворку. Если одним словом – непродуманная архитектура. Под катом я привожу конкретику, так что устраивайтесь поудобнее. ДА НАЧНЕТСЯ ХОЛЛИ ВАР!