Я не говорил, что 4:3 плох :) Сегодня не так просто найти дисплей с разрешением 4:3. Без испытаний сложно сказать, на сколько был бы удобен монитор с разрешением 1920×1440.
По своему опыту могу сказать, что 1920×1200 24" очень удобен :) Когда переходил с обычного 19" монитора (1280×1024) казалось, что будет слишком «широко» и тесно, как было на экране моего ноутбука (1366×768). Но нет, работать за большим рабочим столом оказалось одно удовольствие, особенно если иногда нужно поработать с несколькими программами одновременно. Каждая на половину экрана — здесь горизонтальное разрешение очень кстати.
Вот подумалось, по горизонтали бы ещё чуть-чуть добавить, до 2048 пикселей. Чтобы сайты в браузере, развёрнутом на половину экрана, без нижнего скролла отображались :)
Интуитивно: информация чаще скроллится по вертикали, следовательно чем больше разрешение по вертикали, тем меньше придётся работать скроллом. Разрешение по горизонтали конечно тоже важно (для размещения всевозможных сайдбаров). При выборе между 1920×1080 и 1920×1200 я бы выбрал последний: лишние 120 пикселей для заголовка, тулбаров и таскбара не помешают :)
Знакомые, которые отличают вслепую lossless от lossy у меня есть.
Видел достаточно подобных заявлений, но ни разу не встречал подтверждений. Если вам не сложно, дайте вашим знакомым послушать 3 файла и определить, где оригинал, а где lossy: test1.wavtest2.wavtest3.wav. Один из этих файлов содержит оригинальный фрагмент, два других — закодированные в Ogg Vorbis 256kbps и 500kbps и декодированные обратно. После я опубликую в каком файле оригинал, а в каких — lossy. Если считаете, что фрагмент неудачный, можно провести эксперимент на другом подходящем материале.
Second, even if JIT were the only big issue, a JIT can never be as good as a regular optimizing compiler because a JIT compiler is in the business of being fast, not in the business of generating optimal code. Yes, JITters can target the user’s actual hardware and theoretically take advantage of a specific instruction set and such, but at best that’s a theoretical advantage of NGEN approaches (specifically, installation-time compilation), not JIT, because a JIT has no time to take much advantage of that knowledge, or do much of anything besides translation and code gen.
Собственно судя по страничке о совместимости почти всё остальное поддерживается. Полную поддержку WCF обещают в Mono 3.0. Если писать кроссплатформенное приложение без GUI — отличный инструмент. Если с GUI — никто не мешает установить Mono под Windows вместе с GTK#. Всё-таки Mono идёт своим путём, и некоторые полезные возможности есть только в Mono. Например, Mono Cecil, Mono.Simd, Comiler as a service и другое (можно поизучать на официальном сайте). Так что ребят можно только похвалить, что они проделали столько полезной работы, и продолжают этим заниматься. А Microsoft можно поругать, что не делится всеми исходными кодами .NET, так бы уже давно и WPF был на всех платформах, и совместимость бы была на высоте :)
Вы просто не представляете, на сколько Mercurial удобен :)
Вы же не программируете «методом тыка». Здесь тоже такой способ не подходит — необходимо читать документацию, чтобы понять, какие методы организации процесса разработки предлагает Mercurial, и что из этого вам будет удобно использовать.
Системы контроля версий дают достаточно преимуществ, чтобы потратить несколько часов на изучение десятка основных команд. Для совсем новичков есть статья «hg init».
После изучения и небольшого привыкания на поддержку процесса не будет уходить много времени. Все команды просты и логичны, поэтому быстро запоминаются. Если вы достаточно быстро печатаете, вам будет проще и быстрее набрать «hg commit -m «Initial Release»», чем сделать это же через GUI.
После выхода Windows 8 по логике вещей Microsoft должна заняться обновлённой серверной версией Windows. Интересно, а как там поступят с кнопкой Пуск? :)
Если вы пишете proxy-dll, то смысла дополнительно перехватывать проксируемые методы через Detours нет, поскольку вы и так можете писать свою реализацию этих методов. Если же вы хотите дополнительно отлавливать вызовы из других библиотек, то Detours здесь верный помощник.
Возможно помогут какие-то другие параметры, либо уже нужно будет дополнительно немного поправить код в самом бинарнике. Как правило, там не сложные модификации.
Перед тем, как писать свой велосипед, я пробовал эту программу. При отображении языка рядом с курсором он меняет свой вид, отбрасывает тень и не инвертирует под собой цвета, что не очень удобно.
Да, я в начале статьи указал, что работа ведётся в Visual Studio 2010. К сожалению, в таких мелочах производители различных компиляторов не договорились между собой о единых стандартах.
Будет очень полезно, если вы приведёте аналогичные по действиям участки кода для GCC :)
По своему опыту могу сказать, что 1920×1200 24" очень удобен :) Когда переходил с обычного 19" монитора (1280×1024) казалось, что будет слишком «широко» и тесно, как было на экране моего ноутбука (1366×768). Но нет, работать за большим рабочим столом оказалось одно удовольствие, особенно если иногда нужно поработать с несколькими программами одновременно. Каждая на половину экрана — здесь горизонтальное разрешение очень кстати.
Так что скорее всего там чудес не будет :)
Вы же не программируете «методом тыка». Здесь тоже такой способ не подходит — необходимо читать документацию, чтобы понять, какие методы организации процесса разработки предлагает Mercurial, и что из этого вам будет удобно использовать.
После изучения и небольшого привыкания на поддержку процесса не будет уходить много времени. Все команды просты и логичны, поэтому быстро запоминаются. Если вы достаточно быстро печатаете, вам будет проще и быстрее набрать «hg commit -m «Initial Release»», чем сделать это же через GUI.
Будет очень полезно, если вы приведёте аналогичные по действиям участки кода для GCC :)