Я надеюсь, что Xamarin просто выкинут своё собственное ядро, воткнут вместо него CoreCLR, допишут функционал для Linux и Mac. И будет тогда полное счастье.
В Олене уровень английского точно такой же, читается крайне просто. У меня обе книжки крайне легко пошли: я в таких случаях даже не всегда помню, что книжка в оригинале на английском была.
Но у некоторых людей (даже с приемлемым знанием языка) есть барьер, не дающий им читать английские книжки. Т.е. если книга не на русском, то они даже пробовать не будут. Это грустно, программисту в наше время без английского очень тяжело, но что поделать.
Ну, тогда птичку. Олень — это уже для тех, кто умеет чего-то считать и хочет насчитанное визуализировать. А птичка даст человеку основы самого языка.
Впрочем, возможно стоит переводить R for Everyone. Мне её не прокомментировать, руки ещё не дошли прочитать, но отзывы достаточно хорошие.
Книжки с оленем и птичкой хороши. Особую ценность они составляют на ранних этапах обучения, когда возможностей языка ещё толком не знаешь: можно получить замечательный обзор того, что вообще делать можно. Было бы здорово, если бы они были на русском: возможно популярность R в РФ подросла бы.
Я очень сильно сомневаюсь, что оптимизация Хемминга в реальном приложении даст хоть сколько-нибудь заметные результаты. Целевая функция дёргается один-единственный раз где-то в рефлексии. В коммите скорее отражено стремление делать даже мелкие вещи хорошо =)
Красивое решение. Очень хорошо подойдёт для каких-нибудь небольших проектов, которые нужно побыстрее и попроще сделать. Но, присоединюсь к bessony и onikiychuka, в большом продакшн-проекте я бы опасался использовать такой подход.
Проблема вашего скрипта в том, что в нём учитываются только адреса, которые начинаются с http://habrahabr.ru/post/. Если пост публикуется в блоге компании, то его адрес начинается с http://habrahabr.ru/company/<имя компании>/blog/. Таким образом, в рейтинг не попало много хороших постов, авторы которых поместили их в хаб своей компании.
несоответствие поведения у mono и ms компиляторов должно быть уже привычной вещью
Ну, это не значит, что будет лишним напомнить об этом людям.
оригиналу статьи скоро вот уже 5 лет и пока ничего не изменилось
Сейчас .NET-отрасль развивается очень активно. Я не удивлюсь, если после выпуска Roslyn MS начнут улучшать IL-генерацию и чего-нибудь поменяют. В этом случае будущий читатель вашей статьи скажет спасибо за то, что вы указали версии компиляторов, для которых всё это работает.
поведение компилятора mono, используемого в unity3d, пока-что повторяет поведение, указанное в статье
Да, Xamarin пофиксили поведение в Mono 2.10. Но это не отменяет того факта, что есть ещё индивидуумы, которые сидят под Mono 2.4.
1. Более глубокое понимание того, что происходит. «Вы должны понимать как минимум на один уровень абстракции ниже того уровня, на котором вы кодируете» (с) Ли Кэмпбел.
2. Понимание таких вещей очень полезно, если вы занимаетесь кодогенерацией, делаете IL-инъекции, активно используете Emit и т.п. Ну и, разумеется, это пригодится тем, кто ввиду специфики своего проекта активно работает с IL.
3. А ещё есть такая штука, как критичный по производительности код. Если вы хотите очень сильно разогнать ваше C#-приложение, то вам очень не помешает понимать какие IL-инструкции стоят за каждой C#-строчкой (а лучше бы ещё и иметь представление про итоговые машинные коды).
Впрочем, для среднестатистического разработчика, который пишет среднестатистический код, практической пользы не очень много. Материал ориентирован скорее на сеньоров, которые занимаются хардкорной и низкоуровневой работой.
Я бы на вашем месте сделал акцент на том, что всё это особенности текущей версии компилятора C# от Microsoft. Насколько я знаю, спецификации C# нам ничего подобного не говорят. Пример: под Mono 2.4 приведённый код превращался в точности в
Исследование очень интересное и полезное, но не стоит забывать, что Microsoft нам не гарантирует, что в будущих версиях компилятора поведение не поменяется. Поэтому разумно будет указать версии компилятора C#, для которых выводы справедливы. Roslyn выдаёт аналогичные результаты, но кто его знает, что будет потом.
Барт де Смет писал оригинальный пост в далёком 2008, ещё до выхода Mono 2.0. В то время люди вообще не задумывались о том, что могут быть альтернативы реализации от Microsoft. А вот в наши дни надо бы указывать (хотя бы в примечаниях переводчика), что это особенности конкретных компиляторов.
Ну, быть может и можно как-то запустить, но если вы собираетесь работать под Mono, то я бы всё-равно посоветовал переписать под NUnit. Думаю, это не должно быть такой уж большой задачей.
А в результате получился код который хорошо работает на приложенном наборе изображений,
Ну так автор же совершенно честно в этом признаётся. Это же не код для того, чтобы вы могли его скопировать и сходу использовать в своих задачах. Идея поста в том, чтобы показать рабочий иллюстрированный пример, который включает в себя некоторые основные базовые операции компьютерного зрения (морфология, бинаризация и т.п.) Подобные статьи с примерами картинок хороши для начинающих: люди получают первое представление о том, зачем какая операция нужна, что она делает, как это выглядит.
Ну, опять-таки, нужно смотреть что конкретно работает медленно. «Простое» — это не описание. Проседание производительности может вызвать «простой» код на несколько строк. Быть может, много объектов создаётся, и GC начинает грустить. Может быть рендерится что-то хитрое. Скорее всего проблемы со скоростью упираются в два-три важных момента, по которым нужно проводить оптимизацию.
Но у некоторых людей (даже с приемлемым знанием языка) есть барьер, не дающий им читать английские книжки. Т.е. если книга не на русском, то они даже пробовать не будут. Это грустно, программисту в наше время без английского очень тяжело, но что поделать.
Впрочем, возможно стоит переводить R for Everyone. Мне её не прокомментировать, руки ещё не дошли прочитать, но отзывы достаточно хорошие.
http://habrahabr.ru/post/. Если пост публикуется в блоге компании, то его адрес начинается сhttp://habrahabr.ru/company/<имя компании>/blog/. Таким образом, в рейтинг не попало много хороших постов, авторы которых поместили их в хаб своей компании.Ну, это не значит, что будет лишним напомнить об этом людям.
Сейчас .NET-отрасль развивается очень активно. Я не удивлюсь, если после выпуска Roslyn MS начнут улучшать IL-генерацию и чего-нибудь поменяют. В этом случае будущий читатель вашей статьи скажет спасибо за то, что вы указали версии компиляторов, для которых всё это работает.
Да, Xamarin пофиксили поведение в Mono 2.10. Но это не отменяет того факта, что есть ещё индивидуумы, которые сидят под Mono 2.4.
2. Понимание таких вещей очень полезно, если вы занимаетесь кодогенерацией, делаете IL-инъекции, активно используете Emit и т.п. Ну и, разумеется, это пригодится тем, кто ввиду специфики своего проекта активно работает с IL.
3. А ещё есть такая штука, как критичный по производительности код. Если вы хотите очень сильно разогнать ваше C#-приложение, то вам очень не помешает понимать какие IL-инструкции стоят за каждой C#-строчкой (а лучше бы ещё и иметь представление про итоговые машинные коды).
Впрочем, для среднестатистического разработчика, который пишет среднестатистический код, практической пользы не очень много. Материал ориентирован скорее на сеньоров, которые занимаются хардкорной и низкоуровневой работой.
Исследование очень интересное и полезное, но не стоит забывать, что Microsoft нам не гарантирует, что в будущих версиях компилятора поведение не поменяется. Поэтому разумно будет указать версии компилятора C#, для которых выводы справедливы. Roslyn выдаёт аналогичные результаты, но кто его знает, что будет потом.
Барт де Смет писал оригинальный пост в далёком 2008, ещё до выхода Mono 2.0. В то время люди вообще не задумывались о том, что могут быть альтернативы реализации от Microsoft. А вот в наши дни надо бы указывать (хотя бы в примечаниях переводчика), что это особенности конкретных компиляторов.
Ну так автор же совершенно честно в этом признаётся. Это же не код для того, чтобы вы могли его скопировать и сходу использовать в своих задачах. Идея поста в том, чтобы показать рабочий иллюстрированный пример, который включает в себя некоторые основные базовые операции компьютерного зрения (морфология, бинаризация и т.п.) Подобные статьи с примерами картинок хороши для начинающих: люди получают первое представление о том, зачем какая операция нужна, что она делает, как это выглядит.
А у вас не осталось где-нибудь номера бага?