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

Недавно я писал о том, как можно совершенно легально загрузить самый последний Microsoft Office с сайта Microsoft — как корпоративную версию, так и коробочную Retail — любые языки и продукты, со всеми интегрированными обновлениями. Сегодня я расскажу, как сделать то же самое и с операционной системой — средствами предоставляемыми самой Microsoft.

Но для начала я хочу рассказать о версиях Windows 8.1. Не об изданиях — этого добра в сети много, а именно о публичных версиях сборок ОС. Ведь для любого администратора удобно загрузить образ со всеми интегрированными обновлениями, чем устанавливать сотню самостоятельно. Причём загрузить образ с сайта Microsoft, а не самодельную сборку с торрентов. Всё что я буду рассказывать о версиях ОС Windows 8.1 применимо и к Windows Server 2012 R2, за исключением канала для бесплатной загрузки образов для переустановки ОС. Но давайте всё по порядку.

Нет. Это не самогонный аппарат.

Конструкторский макет бортового источника питания для новейшего кислородно-водородного разгонного блока тяжелого класса (РБ КВТК) для тяжелой ракеты Ангара

NASA отправили человека на Луну и обратно, а сейчас на смартфонах, которые превышают вычислительную мощность компьютеров NASA, люди отправляют друг другу «Yo!», и птиц в свиней.

С 3d-печатью практически такая же ситуация. Понятное дело, металлические 3d-принтеры уже творят чудеса, на них напечатали и жидкотопливный реактивный двигатель для космического аппарата, и газотурбинный двигатель. Но вот с пластиком что? Печатать свистки или чехольчики для телефонов?

Что полезного (реально полезного) напечатали ABS/PLA пластиками в России? Кинул клич своим однохакспейсникам, те посоветовали обратиться в компанию, которая производит пластик для 3d-принтеров REC (как-то раз я ходил к ним в гости и описал процесс производства PLA). Помимо костюма железного человека (более 10 км пластика, более 1200 часов печати) есть и практически полезные примеры из медицины и ракетостроения.

Спустя 2 года после начала писательства на Хабре про 3d-принтеры, я все же смог проникнуть в цех с металлическим принтером. И подержал в руках засекреченный ракетный движок. Коротенький обзор промышленного металлического принтера. Теперь каждый может почувствовать себя Илоном Маском и напечатать свой ракетный двигатель. Или зайчика.

Вопросам представления действительных чисел в формате с плавающей точкой/запятой, который закреплен в стандарте IEEE754, посвящено немало работ. В том числе и на Хабрахабре. Не являясь программистом, автор попытался разобраться с этим зверем с точки зрения простой школьной математики. Отталкиваясь не от утвержденных в стандарте форматов, а от естественных представлений о числах. Возможно, что такой взгляд со стороны будет интересен и профессионалам-программистам. Особенно это касается вопросов, связанных с денормализованными числами.

В прошлом топике (1 ) мы говорили о числах с плавающей точкой/запятой, нормализованных в соответствии со стандартом IEEE754. Там же были рассмотрены денормализованные числа, искусственное введение которых в стандарте привело к чудовищным программно-аппаратным затратам, тормозящим процессы компьютерной обработки чисел в десятки и сотни раз. Но, так уж ли нужна эта самая нормализация и тем более оправдано ли введение экзотического класса денормализованных чисел в компьютерную арифметику? Попробуем разобраться с этим вопросом.

В сети уже есть довольно немало сравнений Entity Framework и NHibernate, но все они по большей части фокусируются на технической стороне вопроса. В этой статье я бы хотел сравнить эти две технологии с точки зрения Domain Driven Design (DDD). Мы рассмотрим несколько примеров кода и увидим как эти две ORM позволяют нам справляться со сложностями.

В предыдущих заметках (часть I, часть II) об async/await в C# 5 я написал, что подобный подход реализован в таких языках, как Haskell, F# и Nemerle, но, в отличие от C#, эти языки поддерживают концепцию более высокого уровня, которая позволяет реализовать асинхронные вычисления в стиле async/await в виде библиотеки, а не на уровне языка. Забавно, что в Nemerle сама эта концепция реализована в виде библиотеки. Имя этой концепции — монада. Помимо асинхронных вычислений монады позволяют реализовать другие вкусности, такие как list comprehension, continuation, превращение грязных функций в чистый блок, через который неявно протаскивается состояние, и множество других.

Некоторые монады реализуют такие «хотелки» C# программистов, как yield коллекции или yield foreach и yield из лямбда выражения.

Цель этой заметки — введение в асинхронное программирование и computation expressions в Nemerle, но она так же может быть полезна тем, кто изучает F#, так так реализация асинхронного программирования в Nemerle была сделана с оглядкой на него в F#. С другой стороны, кому-нибудь может быть интересно, как некоторые задачи, которые являются проблемой в других языках (После всех асинхронных вызовов), решаются с помощью computation expressions в пару строк.

Продолжение: часть III.

Прошлая заметка о async (часть I) была введением. В этой я продолжу начатую тему: я расскажу о том, что async взаимодействует с SynchronizationContext, и как это влияет на разработку асинхронных графических приложений.

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

Привет, Хабр! Тема async/await в .NET Framework и C# 5.0 не нова и объезженна: все давно знают, что это, как оно работает, все знакомы с тем скромным фактом, что это очень текучая абстракция и поведение зависит от SynchronizationContext. Об этом очень много писали на хабре, ещё чаще этот вопрос размусоливался в блогах различных респектабельных персон .NET-сообщества.

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

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

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

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

В компаниях сейчас больше данных на сотрудников, чем когда либо в истории и анализ Больших Данных (big data) довольно быстро входит в практику HR. В анализе работы персонала нет ничего нового, но масштаб собираемых и анализируемых данных выходит за пределы норм.

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

Предметом внимания вчерашнего поста на Хабре стал фреймворк распределенных вычислений от Microsoft Research — Dryad.

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

В этой статье обсудим компонент верхнего уровня программного стэка фреймворка Dryad – язык запросов к распределенному хранилищу DryadLINQ.

Введение

Слишком много раз я встречал приложения, о которых говорили, что у них есть модель предметной области и приложение было спроектировано на основе это предметной области. Однако в действительности всё, что я видел, было коллекцией сущностей (я бы даже сказал DTO), имеющих кучу свойств без какой бы то ни было реальной логики, связанной с сущностью. Кроме того, я могу найти много сервисов всех видов, которые содержат красочную смесь бизнес-логики и/или инфраструктуры. Если приложение вдобавок использует шину сообщений (как NServiceBus, Mass Transit Bus или Azure Bus), то конечно же заметно, что некие сообщения передаются от одного модуля к другому или нескольким модулям. К сожалению, сообщения часто имеют очень обобщённые названия, содержащие слова “обновить”, “изменить”, “добавить” или “удалить”, и несут большое количество полезной нагрузки — десятки разнообразных свойств. Часто из названия сообщения совершенно не очевидно, является ли оно командой или событием, и чтобы определить это, приходится глубоко зарыться в реализацию.

Я искренне хотел бы, чтобы все написанное выше было бы преувеличением или же имело смысл только для «старых» приложений, которые разрослись и вышли из-под контроля. Но печальная истина в том, что это относится ко многим новым проектам, даже тем, которым всего несколько месяцев от роду. Почему так происходит? Конечно, есть много разных причин: отсутствие знаний является одной из наиболее важных.

Продолжение по ссылкам: часть II и часть III.

На PDC2010 Хейсберг объявил, что следующая версия C# будет поддерживать примитивы для удобной организации асинхронных вычислений, кроме анонса была представлена CTP версия расширения для студии (скачать), которая позволяет попробовать улучшенное асинхронное программирование уже сейчас.

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

Не смотря на то, что упрошенное асинхронное программирование является нововведением в C#, сам подход нельзя назвать инновационным, так как реализация async на основе монад есть в Haskell, F# и Nemerle. На самом деле поддержка языком монад позволяет реализовать даже большее, поэтому я был немного удивлен, когда посмотрел презентацию Хейсберга и понял, что в язык был встроен только частный случай.

В недавно вышедшей Visual Studio 11 Beta встроена новая и главная фишка будущего C# 5 — асинхронное программирование с помощью async/await. Про нее уже написано достаточно много статей в том, числе на хабре — например, эта серия статей. Однако, я для себя так и не понял в чем суть нового синтаксиса, пока сам не попробовал его в деле. Данная статья — попытка самому структурировать и до конца разобраться с этим достаточно интересным инструментом и поделиться результатами с сообществом, рассказав про него немного иначе. Итак, поехали…

Ключевые слова async и await, введённые в C# 5.0, значительно упрощают асинхронное программирование. Они также скрывают за собой некоторые сложности, которые, если вы потеряете бдительность, могут добавить проблем в ваш код. Описанные ниже практики пригодятся вам, если вы создаёте асинхронный код для .NET приложений.

Каждому иногда приходится размышлять над тем, что же происходит в ИТ, как оно будет дальше развиваться, и как потом с этим жить. Хотелось бы этим постом ответить на статью «Мысли об идеальном языке программирования».

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

Эта статья — продолжение статьи C#: коллекции только для чтения и LSP. Сегодня мы посмотрим на интерфейс IEnumerable с точки зрения принципа подстановки Барбары Лисков (LSP), а также разберемся, нарушает ли этот принцип код, имплементирующий IEnumerable.

Вопрос о том, что такое класс объектов, существует ли он в природе, обсуждается мной вот уже на протяжении двух статей: Класс объектов или объекты класса? , Особенности концептуального моделирования предметной области . Я задаюсь вопросом: можно ли, описывая предметную область, связать семантической связью объект и класс объектов?

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

Моделирование при помощи UML подливает масла в огонь, потому что во-первых, не позволяет моделировать классы объектов (Моделирование функциональных и физических событий в логической парадигме), а во-вторых, не позволяет связать семантикой класс объектов и объект. Таким образом, в области моделирования предметных областей наблюдается пока не изученное пустое пространство. Я позволю себе немного порезвиться на этом поле, чтобы показать, как на самом деле это забавно. Сегодня я расскажу про то, как мой вопрос связан с понятием исчисляемости и неисчисляемости существительного.