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

Я начал собирать рабочую станцию под задачи машинного обучения. Поставил в неё, кроме прочего, отличный процессор, много памяти, достойную видеокарту. Практически все мои задачи я решал в Ubuntu. Правда, для работы с текстами мне нужен был Microsoft Office. Онлайновый Office тогда ещё не появился, и, давайте называть вещи своими именами, LibreOffice — это просто ужас какой-то. Для меня решением стала двойная загрузка в конфигурации Ubuntu — Windows 10. Мне невероятно понравилось то ощущение свободы, которое испытываешь, переходя с ОС от Apple на Ubuntu. А возможности, которые открываются перед тем, кто сам собирает свой компьютер, практически бесконечны.



Двойная загрузка в течение долгого времени полностью меня устраивала. А когда я миллион раз ей воспользовался, появилась технология WSL (Windows Subsystem for Linux, подсистема Windows для Linux). Когда это случилось, я начал решать некоторые свои Linux-задачи в Windows. Правда, даже так, многого для полноценной работы мне ещё не хватало. Но теперь, с выходом WSL 2, у меня возникает такое ощущение, что новая версия WSL способна кардинальным образом изменить ситуацию. Сегодня я предлагаю поговорить о том, как, с помощью WSL 2, перенести задачи по разработке программ из Linux в Windows 10. Я расскажу о новых возможностях WSL 2, и о том, что можно ожидать от этой подсистемы в будущем.

Кто-то в детстве мечтает изобрести лекарство от рака, кто-то — стать космонавтом или владельцем свечного заводика. А я мечтал о том, что у меня появится климатическая система, и в квартире, наконец, не будет душно, вечная простуда от сквозняков исчезнет, а горло перестанет першить от сухости. И теперь мечта исполнена!

Примерно с декабря 2015 по июнь 2016 года я читал форумы, катался по строительным магазинам, собирал систему в квартире и на балконе, паял контроллер и писал прошивку — и добился своего.

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

Подробно о преобразовании асинхронного кода, осуществляемого компилятором

Механизм async реализован в компиляторе C# при поддержке со стороны библиотек базовых классов .NET. В саму исполняющую среду не пришлось вносить никаких изменений. Это означает, что ключевое слово await реализовано путем преобразования к виду, который мы могли бы написать и сами в предыдущих версиях C#. Для изучения генерируемого кода можно воспользоваться декомпилятором .NET Reflector или ILSpy. Это не только интересно, но и полезно для отладки, анализа производительности и других видов диагностики асинхронного кода.

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

Тем не менее, написание тестов сложно назвать увлекательным процессом. Инициализация тестовых данных, инициализация моков, создание объекта тестирования… Пока доберешься до вызова метода, который ты собственно хотел проверить, тестировать уже и не хочется ничего. Я конечно утрирую, юнит-тест по своей природе не должен брать на себя слишком много и содержать пару сотен десятков строк инициализации (хотя и такое бывает), однако писать один и тот же код быстро надоедает. И вот уже появляются фабрики тестовых объектов, иерархия базовых классов для тестов и прочие ООП примочки, призванные «упростить» создание теста. Приводит это как правило к тому, что шансов быстро понять, что же делает тест, не путешествуя по этим самым объектам, практически не остается.

Собственно, инструмент, о котором я хочу рассказать, как раз и призван упростить, а в некоторых случаях и полностью убрать фазу инициализации или Arrange фазу теста.

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

В этом посте я расскажу, почему так получилось: чего мы не смогли предвидеть, когда придумывали первую версию ПО Яндекс.Диска, и как создавали новую.



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

Хочу рассказать, как максимально удобно работать с XAML-ресурсами из Code-Behind. В этой статье мы разберемся, как работают пространства имен XAML, узнаем о XmlnsDefinitionAttribute, используем Т4-шаблоны и сгенерируем статичный класс для доступа к XAML-ресурсам.

Приветствую, Хабр!

Сегодня мы поговорим о рутине. Время от времени каждому программисту приходится совершать много нудной, объемной и шаблонной работы, которую постоянно так и хочется автоматизировать, да руки не доходят. Вот об одном малоизвестном способе упростить себе жизнь с помощью кодогенерации я и хочу сегодня рассказать сообществу дотнетчиков. Способ известен как Text Template Transformation Toolkit или попросту T4.

Животные и люди умеют обучаться, играя. В самом деле, что может быть лучше — и интересно, и познавательно. Компьютерные игры не являются исключением, с некоторыми из них можно учиться. Я очень удивился, когда, поискав по Хабру, узнал, что космический симулятор Orbiter всего пару раз мельком упоминался здесь. Бесплатный космический симулятор с открытой для аддонов архитектурой и честной ньютоновской физикой оказался незаслуженно обойдённым вниманием. Наверное, из-за своей требовательности к начинающему игроку.

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



Что мне вообще хочется:

1. Объединить диски с данными в один массив большого объема, чтобы не приходилось вручную сортировать файлы — что возникает при нескольких дисках (пусть даже при монтировании их в папки).
2. Иметь возможность добавлять/удалять/заменять диски в любой момент без развала массива.
3. Независимость информации на дисках друг от друга — чтобы смерть одного из них не приводила к недоступности остальных.
4. В идеале — какой-то метод хранения одного файла на нескольких дисках. Бэкапы — это хорошо и я их делаю, но лучше, когда к их помощи не приходится прибегать.

Российская компания ЗАО «Сетевые Технологии» и её отделение на Тайване «Communication Technology» Ltd. на грядущей выставке Computex 2014, проходящей с 3-го по 7-ое июня в Тайбэе, представляет три миникомпьютера на основе платформ Cedar Trail — Atom N2000, Chief River — 3rd gen Core i3/i5/i7 и Shark Bay — 4th gen Core i3/i5/i7.

В этом посте хочется поделиться личным опытом создания продукта с нуля. Путь «а давайте запилим/скопируем и выкинем на рынок» мы уже проходили. Такой подход чуть не убил нашу компанию.



По статистике, около 50% фич среднестатистического продукта никогда не используются и только 12% опций клиенты используют активно. Как всегда попадать в эти 12% функционала? А что, если я сам не являюсь пользователем этого продукта? Как сделать продукт простым и удобным? Наконец, стоит ли его вообще делать нашей компании? И как понять, будет ли продукт востребован рынком еще до его создания?

Одним из самых популярных топиков в нашем блоге стал рассказ о Джесси Сполдинге — парне, который заработал $500к на фондовом рынке, применив свои познания в программировании и понимание основ фондового рынка (часть 1, часть 2). В комментариях к этим текстам некоторые хабрапользователи выражали свое сомнение в реалистичности такого сценария в нашей стране. Также слышались фразы вроде «ну он раньше работал в этой сфере».

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

Примечание: Андрей Горьковенко раньше работал программистом в ITinvest. В частности, он трудился над проектом торгового терминала SmartX (история его создания описана в отдельном хабратопике). Позднее он создал универсальную механическую торговую систему, с помощью которой можно реализовывать различные стратегии торговли на фондовом рынке. Эта разработка приносит ему основной доход, который превышает среднюю зарплату разработчика в Москве.

Андрей, привет! Расскажи, как ты вообще оказался связан с фондовым рынком?

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

Всем привет. Это заключительная серия базовых уроков по Unity 3D от сайта Unity3DStudent. Далее будут еще два урока среднего уровня. Upd: планы изменились, этих уроков не будет, так как второй урок (по анимации) уже довольно сильно устарел, а выкладывать перевод только одного урока не вижу смысла. Пусть он останется на самостоятельное изучение =)

Ссылки на предыдущие уроки:

• Уроки B00-B03
• Уроки B04-B08
• Уроки B09-B12
• Уроки B13-B16
• Уроки B17-B20
• Уроки B21-B24

С чего всё начиналось

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

Немного погодя, оказалось, что все компоненты стоят вместе как готовый принтер и настрой сильно упал (Ох уж эти московские перекупщики), но на помощь пришел Китай со своими сверхдешевыми электроникой и электромеханическими компонентами. В порыве радости был заказан комплект электроники RAMPS 1.4 (Как самый простой в использовании по отзывам), 5 шаговых двигателей типа nema 17 (момент удержания должен быть не меньше 1.5кг/см, но я взял аж 4кг/см), 2 метра приводного ремня размера t2.5 с двумя алюминиевыми шкивами по 20 зубьев, а так же нагревательную платформу (mk2a самая распространенная), так же нужно не забыть взять 12 линейных подшипников lm8uu. На всё я потратил чуть больше 13 тысяч рублей, что, согласитесь, несколько меньше, чем, даже, комплекты для самостоятельной сборки в магазинах.

Спустя 2 месяца ожидания

За эти месяцы я успел познакомиться на форуме с несколькими интересными людьми, один из которых любезно распечатал на своем Replicator2 детали для моего принтера (Я выбрал конструкцию Prusa Mendel i2 из-за её дешевизны и простоты сборки). Кстати говоря, точность изготовления деталей мало на что влияет и, в принципе, можно их делать хоть из ложек, я лично сделал часть деталей для рамы из толстой фанеры. Большой проблемой было найти направляющие валы, которые стоят от 600 рублей за метр (Каленые и прочные, т.е. избыточная прочность), но решение было найдено на рынке: обычные прутки из нержавейки диаметром 8мм отлично подошли (Нужно всего 3 метра, как и что резать, написано на Вики), так же 6 метров шпилек м8 и 6 подшипников 608 (Как в роликах и скейтбордах). В качестве блока питания можно использовать что угодно от 400Вт 12-19В. Забрав с почты последнюю посылку (Не буду говорить про нашу почту, все и так всё знают. Битые и мятые коробки, ожидание, потерянные извещения), я понял, что предстоит много работы.

Здравствуйте, в данной статье я хотел бы поделиться опытом о том как прошел путь от идеи до готового устройства.
Мне очень нравиться читать Хабр, и вот я наткнулся на статью о том как быстро и без хлопотно можно привязать дозиметр к iphone (статья). Статья написанная lexeresser меня очень заинтересовала и мне захотелось попробовать сделать такую привзяку, но наткнулся на сложности: первый момент — бытовой дозиметр, который описывается купить не так просто, нашел всего два на продаже и они продаются не в России, второй момент — в статье описывалась программа для iphone, а у меня смартфон на Android. Я поставил себе задачу уложиться в 1000 рублей, т.к. дозиметры стоят от 3500 рублей. Чтобы уложиться в бюджет я решил не искать готовое устройство, а сделать самому, а программу для андроида создать. Данный проект я назвал SyGeiger и он не несет коммерческую идею, он просто для фана: Смогу ли я?

Самая первая спецификация продукта, частично устная, содержала требование – наличие кроссплатформенного(Windows, Linux, Mac) клиента под десктоп и облегченную версию мобильного(Windows, Android, iPhone). По возможности интерфейс должен быть максимально похожим на разных ОС.
Благодаря Mono мы можем писать кроссплатформенные приложения, но вопрос с GUI остается открытым. Имеющиеся технологии под .Net(Windows Forms, WPF) хорошо работают только под Windows, и у нас уже был печальный опыт портирования Windows Forms. Под Linux мы можем использовать GtkSharp, но идея ставить Mono на Windows при наличии .Net мне не нравится. В итоге приходится писать и поддерживать отдельный интерфейс под каждую ОС.
Что в этой ситуации могла придумать команда .Net(с уклоном под веб)? Решили встраивать Webkit и писать GUI на связке html-js-css.
На сегодняшний день мы 2 года успешно используем такой подход для Windows и год – под Linux и Mac. До мобильной платформы пока руки не дошли.

По работе я пишу тексты: посты на хабр, email-рассылку, статьи в СМИ. Пишу уже пару лет, последние полгода не меньше двух текстов в неделю. Значительным шагом в развитии моего навыка письма было открытие для себя информационного стиля и советов Максима Ильяхова.

Цель текста в информационном стиле — донести информацию до читателя. Информационный стиль: лаконичный, однозначный, точный и объективный. В информационных текстах нет лишних слов, эмоций, личного мнения. Они читаются легко и быстро.

Максим вводит понятие стоп-слов. Стоп-слова не характерны для текстов в информационном стиле и если вы встретили его — задумайтесь и перефразируйте это место. Стоп-слова это «кстати», междометия, модальные глаголы, отглагольные существительные и другие, всего около 100.

В какой-то момент мне стало сложно искать эти слова в текстах, поэтому я создал себе в помощь Test The Text. Test The Text выделяет в тексте слова нехарактерные для информационного стиля и объясняет почему.

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

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

Основным источником книг для меня стал rutracker.org (тогда еще torrents.ru). Там достаточно строгая модерация, стандартизированное оформление, большое количество отзывов под каждой книгой. Но однажды я заметил что поиск интересных книг начинает отнимать всё больше и больше времени, по нескольким причинам.
Во-первых раздачи сортируются не в порядке добавления, а в порядке обновления. Из-за этого всё постоянно перемешивается и нужно пролистывать много страниц в поисках непрочитанных книг.

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

Разделение книг по форумам тоже довольно неудобно. Фантастику, например, разделили на русскую и зарубежную, хотя лично мне удобнее было бы по жанрам. В результате приходится на глаз выискивать любимую НФ среди фентези, S.T.A.L.K.E.Rа и др.

Знакомая проблема?

• Пример 1 – Простое использование Command
• Пример 2 — Простое использование Command в паре с лямда функциями
• Пример 3 — Простое использование Command с параметрами
• Пример 4 – Включение и отключение Command
• Пример 5 – Command вызывающие события
• Пример 6 – Асинхронные Command
• Пример 7 — Асинхронные Command обновляющие интерфейс пользователя (UI)
• Пример 8 — Асинхронные Command с возможность отмены
• Пример 9 – Привязка событий к Command
• Как это работает – Класс Command
• Как это работает – Класс асинхронных Command
• Как это работает – Класс привязки данных к Command

Вступление

На примере приложения, использующего паттерн MVVM (Model View View-Model) рассмотрим работу с командами (Commands).