Я думаю многим читателям блога .Net знакомо имя Jon Skeet. Особенно после вчерашнего прошлогоднего поста юзера SergeyT. Поэтому я не буду повторять про сравнение с Чаком Норрисом и первое место по карме на StackOverflow.com. А вот упомянуть лишний раз про его замечательную книгу “C# In Depth” точно лишним не будет. Центральное место в ней занимает LINQ вообще и LINQ to Objects в частности. Джон очень обстоятельно описывает все возможности языка C# и платформы .Net, которые сделали возможным появление LINQ в его нынешнем виде, а также подробности его реализации. Именно после прочтения этой книги я стал активно использовать LINQ to Objects в своих проектах. Однако в стандартной библиотеке не хватает нескольких крайне нужных операторов. К счастью, Джон Скит исправил это недоразумение. Так появилась небольшая, но очень полезная библиотка morelinq. А с конца прошлого года она доступна в виде NuGet-пакета.

Суть вопроса

В большинстве случаев .NET-приложения являются платформонезависимыми. Мы ожидаем, что наше приложение будет одинаково выполняться как в 32-хразрядной ОС, так и 64-хразрядной.

Так обычно и происходит до тех пор, пока нам не понадобится использовать внешние платформозависимые библиотеки, например неуправляемые. Если такая библиотека существует в вариантах и для x86, и для x64, то это может принести нам определенную головную боль. Будем исходить из того, что ограничивать наше приложение, например, только 32-хразрядным процессом не в наших правилах.

Возможно, нам придется поддерживать вдвое больше конфигураций проекта. В этом случае при отладке придется переключать конфигурации, ведь разработческий веб-сервер Cassini существует только в x86 варианте, а ReSharper может запускать тесты и в 64-хразрядном процессе. Кроме того, придется выпускать два дистрибутива и предоставлять пользователю при скачивании с сайта ох какой нелегкий выбор. Поэтому разумным решением выглядит выбор подходящей для работы библиотеки уже в runtime в зависимости от того, в каком процессе (32-х или 64-хразрядном) код выполняется. При этом сами проекты остаются AnyCPU.

В нашем приложении необходимо подключаться к к Oracle Database, для чего используются библиотеки Oracle Instant Client и Oracle Data Provider for .NET.

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

В свободное время я занимаюсь разработкой Snoop'a. Это отличное подспорье WPF разработчикам, которое не имеет хороших бесплатных аналогов в мире Silverlight. Snoop внедряет свою сборку в WPF процесс и раскладывает его по полочкам.

Мне стало любопытно: можно ли внедрить произвольную сборку в исполняющийся сильверлайт процесс извне браузера? (можно) Об этом и пойдет речь под катом.

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

Статья содержит перечень ресурсов для онлайн-обучения, представляющих интерес преимущественно для программистов.

Предисловие

Изменение .NET метода MSIL кода во время выполнения приложения – это очень круто. Это настолько круто, что можно перехватывать вызовы функций (hooking), сделать защиту своего ПО и другие удивительные вещи. Именно поэтому мне уже давно хотелось это осуществить, но была одна проблема – MSIL код компилируется в машинный код с помощью JIT перед тем, как мы сможем что-либо с этим кодом сделать. А так как .NET CLR не документирована и изменяется от версии к версии, то мы и будем искать стабильный и надёжный путь, независимый от точного расположения адресов в памяти.

Статья написана после прочтения статьи Копи деньги смолоду или пара утверждений, легко проверяемых в Excel.

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

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

Что может быть лучшим подарком на день знаний для программиста? Конечно, полезная книга ;) Поэтому команда переводчиков «Pro Git» поднапряглась и доделала перевод книги на русский язык.

«Pro Git» — это довольно обширная обучающая книга о Git от Скотта Шакона — активного участника разработки проектов Git и GitHub. Автор рассматривает в тексте всевозможные аспекты работы с Git'ом, начиная с установки программы и базовых принципов работы децентрализованных систем контроля версий, и заканчивая рассмотрением внутреннего устройства Git'а и созданием валидных объектов в базе Git'а собственными руками. Несмотря на довольно обширный материал и затрагивание довольно специфических тем, книга написана довольно простым языком, содержит массу примеров и иллюстраций, и поэтому должна быть понятна и новичкам, только начинающим знакомиться с системами контроля версий.

Последняя версия перевода книги доступна в форматах pdf, epub, mobi.
Также доступна онлайн-версия перевода, но она, к сожалению, не обновлялась с мая.

Написание качественной магистерской диссертации полноценно охватывающей все разделы проведенного исследования, основной работы, анализа и апробации результатов является сложной и комплексной задачей, ежедневно с различным успехом решаемой множеством студентов по всему миру. К сожалению, изучение существующей литературы [1, 2], посвященной тематике написания диссертационного исследования, указывает на отсутствие материалов описывающих практический опыт применения различных методов и инструментов, позволяющих не только оптимизировать работу над диссертацией, но и улучшить качество конечного результата.
В данной статье рассмотрим семь практических методов и инструментов, применение которых позволит обеспечить целостное структурирование и систематизацию задач, знаний и различных данных получаемых в ходе работы с диссертацией:

1. Формирование структуры задач.
2. Поиск литературы в каталогах.
3. Сбор, обработка и систематизация информации.
4. Формирование списка литературы.
5. Составление плана по вехам.
6. Определение предмета исследования.
7. «Summary» для научного руководителя.

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

Спешу поделиться хорошей новостью: мы открыли классное место, а именно коворкинг, «Рабочая Cтанция» в Парке Горького. «Рабочая Cтанция» — это далеко не первая наша вариация на тему коворкинга. И, похоже, теперь нам удалось создать то пространство, о котором мы давно мечтали.

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

Это шаблон описания сути вашей компании или проекта в одном предложении. Я открыл его для себя во время стажировки в США. Составив его, мы реально становимся сильнее. В последствии мне это помогло выбрать правильный курс, сфокусироваться и расставить приоритеты.

В прошлой статье я начал с основ CQRS + Event Sourcing. В этот раз я предлагаю продолжить и более подробно посмотреть на ES.

В примере который я выкладывал с моей прошлой статьей магия Event Sourcing’а была скрыта за абстракцией IRepository и двумя методами IRepository.Save() и IRepository.GetById<>().
Для того чтобы поподробнее разобраться что происходит я решил рассказать о процессе сохранения и загрузки агрегата из Event Store на примере проекта Lokad IDDD Sample от Рината Абдулина. У него в аппликейшен сервисах идет прямое обращение к Event Store, без дополнительных абстракций, поэтому все выглядит очень наглядно. Application Service — это аналог CommandHandler, но который обрабатывает все комманды одного агрегата. Такой подход очень удобный и мы тоже на него в одном проекте перешли.

Примерно, 3 недели назад я прочёл на хабре в этом топике о Dapper — ORM от одного из ведущих разработчиков популярного сайта Stackoverflow. Имя этого супергероя Sam Saffron (далее просто Сэм). Кроме того, до появления этого топика об архитектуре Stackoverflow было известно, что в ней используется Linq-to-Sql. Это главная причина, почему я, как и другие разработчики, принялся изучать исходный код Dapper. Как оказалось его немного, а точнее всего один файл. Внимательно просмотрев его, я подумал – а можно ли его сделать ещё быстрее. Ускорять код Сэма было не просто, слишком качественно он был написан. Дальше я опишу мои микрооптимизации в виде советов другим разработчикам. Но для начала хочу предостеречь некоторых разработчиков. Описанная оптимизация ускорила Dapper на 5% и это существенно для такого проекта как Stackoverflow, но может быть не существенным для вашего проекта. Поэтому всегда рассматривайте вариант макрооптимизации (примеры в конце топика) по результатам профилирования и прибегайте к микрооптимизации только в особых случаях.

Недостаточно писать код хорошо читаемым: он также должен быстро выполняться.

Существует три базовых правила для написания такого T-SQL кода, который будет работать хорошо. Они кумулятивные – выполнение всех этих правил окажет положительное влияние на код. Пропуск или изменение любого из них – скорее всего приведет к отрицательному влиянию на производительность вашего кода.

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.

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



Понять последних можно, ведь большинство статей и agile-евангелистов говорят, примерно следующее: «Делайте так, как говорит методология, и ваш проект попадёт в рай. Если нарушите хотя бы одну из практик, то Agile покарает вас»

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

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

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

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

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

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

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

• Часть I: акции, мажоритарии, контроль над компанией.
• Часть II: стоимость акций, биржа, самый лучший способ торговать картошкой, и кого же можно встретить на рынке бирже.
• Часть III: процесс IPO, его польза для компании, основателей и владельцев, а также почему у руководства компании при открытии торгов такой замученный вид.
• Часть IV: влияние IPO на доход от адулт-партнёрок.
• Часть V: жизнь после IPO.
• Часть VI: сложности выбора — два Lamborghini Gallardo или один Aventador?
• Часть VII: про инсайд.
• Часть VIII: о мотивации.

Итак, часть I: акции, мажоритарии, контроль над компанией.

Что такое акции, и для чего они нужны?