Этой статьей я открываю авторскую колонку про технологии, секреты, советы и лучшие практики новой версии ASP.NET5. Платформа .NET стремительно движется к кроссплатформенности и ее веб-часть – ASP.NET – в том числе. Вы уже слышали и можете найти массу информации в сети и в том числе на Хабре о том, что .NET становится opensource, о выпуске новых версий и официальной поддержке .NET на OSX, Linux. Вместе с этими анонсами и ASP.NET5 становится доступным на большем числе платформ для большего круга разработчиков.


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

Тема первого выпуска – работа со статическими файлами в ASP.NET5 – задача насколько тривиальная, настолько же и важная.

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

Трем программистам предложили пересечь поле, и дойти до дома на другой стороне. Программист-новичок посмотрел на короткую дистанцию и сказал, «Это не далеко! Это займет у меня десять минут». Опытный программист посмотрел на поле, немного подумал, и сказал: «Я мог бы добраться туда за день». Новичок посмотрел на него с удивлением. Гуру-программист посмотрел на поле и сказал. «Кажется минут десять, но я думаю пятнадцати будет достаточно». Опытный программист рассмеялся.

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

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

Гуру программист пустился в путь, и пошел прямо через поле. Целеустремленно и прямо. Он достиг цели всего за десять минут.
«Как тебе это удалось?» — спросили двое других — «Как ты умудрился не зацепить ни одной мины?»
«Легко» — ответил он. «Я не закладывал мины на своем пути».

Как ни прискорбно, придется признать – мы сами закладываем себе мины. В первой части я подробно разобрал основные риски в разработке ПО и описал технологические и методологические способы ослабления этих рисков. За прошедший год я получил множество комментариев, основной смысл которых сводился к следующему: «все круто, но с чего начать и как все это будет выглядеть в реальном мире». Действительно, первый текст носит скорее теоретический характер и представляет собой каталог ссылок. В этой статье я постараюсь привести как можно больше примеров.

Жили-были в двух соседних деревушках Вилларибо и Виллабаджо две команды разработчиков. И те и другие делали ревью кода, писали тесты, приводили рефакторинг, но через год разработки в Вилларибо уже выпустили релиз и вышли в продакшн, а в Виллабаджо все еще проводят рефакторинг и чинят баги. В чем же дело?

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.

Почему об этом следует думать разработчику, если есть менеджер?

1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

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

Эта статья — взгляд на тестирование ММО с «другой стороны баррикад», с точки зрения геймера. Я хочу рассказать о том, как сделать альфа-тест, ЗБТ и ОБТ эффективнее. И о том, почему бета-тестеры перестают писать баг-репорты и переходят «в оппозицию» к проекту.

Предисловие

За свою жизнь я участвовал в ЗБТ и ОБТ примерно 30 игр. И самый главный вывод, который я для себя сделал – гейм-девелоперы совершенно не умеют распоряжаться теми людскими ресурсами в виде нескольких тысяч жаждущих прокликать весь функционал геймеров, которые им сваливаются на голову. И именно поэтому и был написан данный материал. От геймера – разработчику, сидящему по ту строну экрана. От тестера – компаниям, которые не понимают, как правильно организовать процесс тестирования усилиями игроков.

Статья разбита на четыре раздела и написана в разговорном стиле. Я по порядку разбираю ошибки разработчиков на альфа-тесте, ЗБТ/ОБТ и при наборе тестеров после релиза. Те, кто хочет конкретики без долгих прелюдий и размышлений, могут сразу листать к последнему абзацу каждого раздела и выводам.

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

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

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

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

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

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

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

Главная цель данной статьи – помочь преодолеть страх, который возникает у тестировщиков ПО (как начинающих, так и опытных) к предстоящему интервью в связи с незнанием грядущего.

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

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

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

Последнее время IPv6 перестал быть новым, возможно это относится только к моей среде общения, но говорить об IPv6 как о новом протоколе — перестали. Читать о том как здорово поднимать туннели ради доступа к заветному и недоступному уже совсем неинтересно. IPv6 стал одним из… Казалось бы, наконец-то, можно кричать «Ура!», но став одним из, он потерял драйвер роста, превратившись в заурядный. Доказать потребителю что ему надо именно это стало сложнее, потребитель не готов платить за один из…

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

Для чего вообще нужно внедрять свои DLL-ки в чужие процессы и устанавливать там хуки? Для того, чтобы понять какие функции будет вызывать это приложение, с какими параметрами и что эти функции вернут. Таким образом мы можем понять внутреннюю логику работы этого приложения, узнать к каким файлам оно пытается получить доступ, какие данные пересылает по сети, мы можем добавить в него логирование, профилирование, отладить баг, получить из приложения некоторые данные или наоборот — добавить в его интерфейс что-нибудь нужное нам. Хуки использует известная утилита Spy++ для работы с окнами приложений, DirectX-отладчики вроде RenderDoc, некоторые утилиты от SysInternals, программы типа ApiMonitor и т.д.

Некоторое время назад я писал вводные статьи об использовании хуков на примерах библиотек Microsoft Detours и madCodeHook (если вы совсем не знакомы с хуками — это то, с чего можно начать). Описанных там техник достаточно для работы с обычными приложениями, но время не стоит на месте и вот сегодня у нас уже есть Metro Modern-приложения, входящие в комплект Windows 8 и Windows 10, а также распространяющиеся через Microsoft Store программы сторонних производителей. К примеру, новый браузер Spartan — это Modern-приложение. Внедрение DLL в эти процессы имеет свои особенности и на первый взгляд может даже показаться невозможным, но это не так. В этой статье я расскажу, как мы можем залезть внутрь Modern-приложения и установить в нём хуки в своих коварных целях.

Изучая язык программирования C#, я сталкивался с особенностями как самого языка, так и его средой исполнения, *некоторые из которых, с позволения сказать, «широко известны в узких кругах». Собирая таковые день за днем в своей копилке, что бы когда-нибудь повторить, чего честно сказать еще ни разу не делал до этого момента, пришла идея поделиться ими.

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

Два месяца назад Microsoft с гордостью объявила о публикации исходного кода CoreCLR, среды исполнения .NET Core, которая представляет собой модульную реализацию .NET.

Исходники CoreCLR опубликованы на Github под лицензией MIT и с отдельным патентным обещанием.

Это замечательная новость, которую можно только приветствовать, если бы не одно «но» — печальное прошлое Microsoft, которое содержит множество фактов агрессивного использования софтверных патентов против свободного ПО.

Поэтому неплохо бы разобраться в деталях.

Мы наконец-то довыкладывали книгу «Играй на победу» известного киберспортсмена и гейм-дизайнера Дэвида Сирлина. Ниже — выжимка самого интересного из третьей части и ссылки на полные главы (очень много букв).

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

Многие считают, что html — это подмножество xml. И, соответственно, пишут код в том же стиле. Но это не так, между этими разметками есть различия. Есть некоторые правила xml, которые неприменимы в html.

Я рассмотрю три основные ошибки тех, кто пытается писать html в стиле xml.

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

• Как поставить человека на место: 10 реальных вопросов про давление в переговорах
• Управленческие инструменты: 4-фазный алгоритм решения проблем с людьми или «А чего ты хочешь, если ты такой хреновый менеджер?»
• Как обсуждать деньги с руководством или почему иногда останавливаются карьеры?
• [кейс] Как вернуть долг от бывших работодателей или про хитрые переговорные стратегии

Не так давно общаясь с директором одной крупной ИТ-компании мы как раз обсуждали эту тему. И он высказал мысль, что отрасль IT — это отрасль, где люди больше всего общаются друг с другом. Несмотря на, казалось бы, большое количество времени, которое мы проводим наедине с компьютером, много времени мы проводим и в общении: с коллегами по команде, коллегами из других городов и стран, заказчиками и т.д. Пообщаться за один день с ребятами из Новосибирска, Москвы, Питера, Санта Клары, Шанхая и Бангалора — в порядке вещей. Причем и письменно, и устно, и на совещаниях и в чатах — как хочешь. Сплошные переговоры. Это, вероятно, и объясняет столько плюсов в постах по этой теме.

Сегодня мы решили продолжить эту тему и опубликовать главу из новой книги Дмитрия Коткина «Переговорная книга быстрых рецептов».

Как распознавать манипуляции и быстро обезвреживать их

На Хабре уже неоднократно рассказывали о таком мощном и удобном средстве мониторинга HTTP-трафика, как Fiddler. Все имеющиеся статьи, однако, рассказывают о встроенных фичах программы, не акцентируя внимания на возможностях её расширения, которых существует целых две: с помощью встроенного языка FiddlerScript и с помощью написания .NET-плагинов. В этой статье мы рассмотрим и то, и другое, а чтобы было интереснее — используем их для решения вполне практической задачи, о которой я писал в своей прошлой статье (подмене битых ссылок на картинки в статьях на Хабре на рабочие).

Итак, давайте вспомним для начала, чем закончилась прошлая статья: мы получили список нерабочих ссылок на картинки и соответствующих им рабочих ссылок на веб-архиве. Теперь нужно отдать их браузеру и для этого мы напишем расширения к Fiddler (одно на FiddlerScript и одно на .NET). Обратите внимание на удобства полученного решения: да, нам нужно будет запустить Fiddler, но зато битые ссылки будут подменяться на рабочие независимо от домена статьи (хабр, гиктаймс или мегамозг), независимо от используемого браузера (лишь бы имел поддержку прокси) и даже мобильные устройства можно будет настроить на использование установленного на компьютере Fiddler в качестве прокси.

Привет Хабражители!

Мы выпускаем не только компьютерные книги (вы удивлены ?), дающие знания, но и книги для форматирования мозга.



1. Быстрые решения не приводят к успеху. Пойми, что хочет твой мозг, и сделай наоборот. Автор: Дэвид Ди Салво
Прототип: What Makes Your Brain Happy and Why You Should Do the Opposite

2. Прокачай свой мозг! Стань умнее. Автор(ы): М. Фотухи, К. Бреда Антониадес
Прототип: Boost Your Brain: The New Art and Science Behind Enhanced Brain Performance

3. Перезагрузи мозг. Решение внутренних конфликтов. Автор(ы): С. Хайес, С. Смит
Прототип: Get Out of Your Mind and Into Your Life: The New Acceptance and Commitment Therapy (A New Harbinger Self-Help Workbook)

Мы рады сообщить что CoreCLR теперь находится на github и теперь вы имеете доступ ко всем его исходным кодам. CoreCLR является средой исполнения .NET Core, выполняя такие функции как сборку мусора или компиляции в конечный машинный код. .Net Core – это модульная реализация .Net, которая может быть использована как база для огромного количества сценариев, масштабы которых варьируются от простых консольных утилит до веб-приложений, хостящихся в облаке. Чтобы понять, чем отличается .Net Core от .Net Framework, посмотрите на пост «Введение в .Net Core»

Теперь вы можете скачивать исходники CoreCLR, бранчеваться, и делать pull requests, также вы можете компилировать его прямо на своем ПК. Мы выпустили полную и актуальную реализацию CoreCLR, которая включает RyuJIT, .Net GC, родной Interop и множество других компонент .Net runtime. Данный релиз следует тем же принципам, что и все наши последние релизы библиотек, вышедших в open-source: сделать весь .Net Framework open sourced.

Сегодня ядро .Net компилируется и отрабатывает (видимо имеется в виду CI) на Windows. Мы добавим имплементации для специфических для Mac и Linux платформенных вещей в ближайшие пару месяцев. Также мы уже имеем некоторый специфический для Linux код в .Net Core, однако мы только начали портировать с Windows на остальные платформы. Напротив, мы хотели открыть исходные тескты с самого начала, чтобы вы вместе с нами пропутешествовали бы к другим платформам, возможно, внося свой вклад.

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