Очень смелое заявление. Это далеко не всегда так, здесь придется положиться на «здравый смысл», определяя, где он — предел разбиения.
Встречал такие ситуации, когда новичок, находясь в эйфории от «паттернов, ООП, вот этого всего» делал разбиения там, где это совершенно не нужно. Например, есть некий метод, который на основании одного флага (т.е. вариантов работы данного метода только два и всегда будет два, больше физически невозможно сделать). Вместо того, чтобы написать код вида:
… какие-то действия…
if () {
вариант 1
} else {
вариант 2
}
… еще какие-то действия
составляющий в сумме строчек 15, он создавал два разных класса с перегрузкой методов, скрывающих действия вариант1, вариант2. В итоге, когда потребовалось изменить поведение, пришлось ломать всю структуру классов и переделывать с нуля, причем в других местах потребовалась перегрузка, которая очень просто реализовалась, а в этом конкретном месте — вариант с if'ом. Ощущение было, что человек не решал проблему, а писал курсовую на тему «как написать простейший код так, чтобы он использовал все самые хитрые заморочки ООП». Разве только интерфейсов не хватало.
Или, например, работа с каким-либо файлом, например, log'ом. Реализована в виде простого метода: открыть файл, отформатировать строку, записать ее в файл, закрыть его. Вернуть признак ошибки.
Вместо этого был создан класс, в конструкторе которого файл открывался, потом отдельный метод для форматирования строки, причем с разными параметрами вместо стандартного sprintf'а (язык другой, не Си, суть та же). Закрытие в деструкторе, отдельное поле ошибки. В итоге вместо if(!DoLog(...)) do something; необходимо создать экземпляр класса, инициализировать его, вызвать запись, сохранить код ошибки, вызвать деструктор, проанализировать код ошибки.
Или когда создается отдельный класс для очень узкой, специализированной задачи, которая вызывается ровно один раз ровно в одном месте. Реализуется простой процедурой, класс не нужен вообще, но он создается. Со всеми прелестями конструирования его и деинициализации.
как люди любят тратить время на совещаниях на всякую ерунду, вместо того, чтобы обсуждать насущные проблемы. Конкретно, проектировщики атомной электростанции очень долго спорили, какой материал должен пойти на навес для велосипедов – bike-shed
Этот эпизод из «Закона Паркинсона» — он чуть о другом.
Там было заседание в мэрии, на котором обсуждались два вопроса — смета на постройку АЭС и смета на постройку сарая для велосипедов служащих мэрии. Обсуждение сметы АЭС прошло в стиле «По смете стоит X долларов. Принимаем? Да, я слышал, что строительство другой АЭС стоило больше. Принимаем». Приняли минут за пять. А вот навес для велосипедов обсуждали очень долго и в итоге вроде решили вообще не строить, точно не помню.
Суть тут не в том, что «много тратят времени на ерунду», это вообще не об этом. Суть в том, что у людей есть определенный уровень компетенции, и что такое АЭС, они не представляют, не представляют масштаб цен и поэтому их легко ввести в заблуждение и они даже ничего не поймут, т.к. некомпетентны. А вот что такое «сарай», сколько стоят жесть и гвозди, представляет всякий, поэтому готов это обусждать, и обсуждать очень долго.
Т.е. оно, конечно, выходит, что о ерунде спорят дольше, но это следствие, суть — в разном уровне компетенции. И, как следствие, то, о чем люди не имеют представления, пройдет легче, а о чем имеют — может вообще не пройти.
Это как с выборами — проголосовать за людей, о которых и о работе и компетентности которых представления мы не имеем, мы можем быстро и гладко, а вот обсуждать смету ТСЖ на ремонт подъезда будут месяцами и в итоге, может, к согласию и не придут.
Хм… интересно, можно ли из такой пары — цифровой вольтметр + интерфейс к ПК сделать осцилограф для сигналов низкой частоты при должной частоте измерений? Или измерение фиксированно по времени (0,3-5,0с как у вас указано)?
Версия ОС, наверно, ни при чем, потому что API для работы с разными DPI есть и в 2000. Шрифты/иконки правильно масштабирубтся и в XP. Т.е. вопрос именно в приложениях.
Просто таких моментов полно, в каждой второй статье. Каждый раз в личку не напишешь, а так всем видно. Ничего обидного в этих обсуждениях для авторов нет, в конце концов, это просто делает материалы на данном сайте лучше.
Зачем? Это искусственное, при том корявое словообразование. Не вижу этого слова в толковых словарях вообще.
Вот выше указаны хорошие варианты: «повысить уровень своей компетенции», «обладает бОльшим мастерством/более высокой квалификацией/более компетентен».
«вы увеличиваете свою экспертизу в нем» — «повышаете свой уровень компетенции в нем»
«обладает большей экспертизой в проекте» — «более компетентен в рамках данного проекта»
И с «экспертизой» получилась полная ерунда. В русском языке «экспертиза» употребляется в контексте «была проведена баллистическая экспертиза». Английское expertise переводится в данном случае иначе:
expertise Прослушать
[ˌɛkspɜːˈtiːz]
Существительное
специальные знания; компетентность; эрудиция (в какой-л. области)
Конечно, важно. «Достаточно» — оно очень расплывчато.
Большая часть на английском — значит, больше шансов получить информацию на английском. Быть программистом в современном мире и не знать английского — нонсенс.
И больше искажений при переходе через ноль (когда один транзистор открывается, а другой закрывается), которые более заметны на тихих сигналах.
Это скорее для каскадов класса Б/АБ, у автора же А, там нет перехода через 0. Да и то, в двухтактных все равно сколько-то сдвигают точку в линейную часть, чтобы не было ступеньки. Или я неправильно понимаю?
В среднем, кмк, чем лучше числа, тем приятнее ушам. Чем меньше искажений внес прибор — тем лучше. Ну, есть те, кому специальные искажения нравятся, что поделать.
Очень смелое заявление. Это далеко не всегда так, здесь придется положиться на «здравый смысл», определяя, где он — предел разбиения.
Встречал такие ситуации, когда новичок, находясь в эйфории от «паттернов, ООП, вот этого всего» делал разбиения там, где это совершенно не нужно. Например, есть некий метод, который на основании одного флага (т.е. вариантов работы данного метода только два и всегда будет два, больше физически невозможно сделать). Вместо того, чтобы написать код вида:
… какие-то действия…
if () {
вариант 1
} else {
вариант 2
}
… еще какие-то действия
составляющий в сумме строчек 15, он создавал два разных класса с перегрузкой методов, скрывающих действия вариант1, вариант2. В итоге, когда потребовалось изменить поведение, пришлось ломать всю структуру классов и переделывать с нуля, причем в других местах потребовалась перегрузка, которая очень просто реализовалась, а в этом конкретном месте — вариант с if'ом. Ощущение было, что человек не решал проблему, а писал курсовую на тему «как написать простейший код так, чтобы он использовал все самые хитрые заморочки ООП». Разве только интерфейсов не хватало.
Или, например, работа с каким-либо файлом, например, log'ом. Реализована в виде простого метода: открыть файл, отформатировать строку, записать ее в файл, закрыть его. Вернуть признак ошибки.
Вместо этого был создан класс, в конструкторе которого файл открывался, потом отдельный метод для форматирования строки, причем с разными параметрами вместо стандартного sprintf'а (язык другой, не Си, суть та же). Закрытие в деструкторе, отдельное поле ошибки. В итоге вместо if(!DoLog(...)) do something; необходимо создать экземпляр класса, инициализировать его, вызвать запись, сохранить код ошибки, вызвать деструктор, проанализировать код ошибки.
Или когда создается отдельный класс для очень узкой, специализированной задачи, которая вызывается ровно один раз ровно в одном месте. Реализуется простой процедурой, класс не нужен вообще, но он создается. Со всеми прелестями конструирования его и деинициализации.
Этот эпизод из «Закона Паркинсона» — он чуть о другом.
Там было заседание в мэрии, на котором обсуждались два вопроса — смета на постройку АЭС и смета на постройку сарая для велосипедов служащих мэрии. Обсуждение сметы АЭС прошло в стиле «По смете стоит X долларов. Принимаем? Да, я слышал, что строительство другой АЭС стоило больше. Принимаем». Приняли минут за пять. А вот навес для велосипедов обсуждали очень долго и в итоге вроде решили вообще не строить, точно не помню.
Суть тут не в том, что «много тратят времени на ерунду», это вообще не об этом. Суть в том, что у людей есть определенный уровень компетенции, и что такое АЭС, они не представляют, не представляют масштаб цен и поэтому их легко ввести в заблуждение и они даже ничего не поймут, т.к. некомпетентны. А вот что такое «сарай», сколько стоят жесть и гвозди, представляет всякий, поэтому готов это обусждать, и обсуждать очень долго.
Т.е. оно, конечно, выходит, что о ерунде спорят дольше, но это следствие, суть — в разном уровне компетенции. И, как следствие, то, о чем люди не имеют представления, пройдет легче, а о чем имеют — может вообще не пройти.
Это как с выборами — проголосовать за людей, о которых и о работе и компетентности которых представления мы не имеем, мы можем быстро и гладко, а вот обсуждать смету ТСЖ на ремонт подъезда будут месяцами и в итоге, может, к согласию и не придут.
Нельзя ли уточнить, что именно имеется в виду под «поддержкой DPI, отличных от 96»? Что именно в Windows не поддерживалось?
Вот выше указаны хорошие варианты: «повысить уровень своей компетенции», «обладает бОльшим мастерством/более высокой квалификацией/более компетентен».
«вы увеличиваете свою экспертизу в нем» — «повышаете свой уровень компетенции в нем»
«обладает большей экспертизой в проекте» — «более компетентен в рамках данного проекта»
Сравните с «обладает большей экспертностью».
expertise Прослушать
[ˌɛkspɜːˈtiːz]
Существительное
специальные знания; компетентность; эрудиция (в какой-л. области)
человеческий опыт, знание дела
квалификация; компетенция
искусство, мастерство, умение; сноровка
Синоним: skill
— Переводится и как «экспертиза», но именно в значении, о котором я писал выше.
Большая часть на английском — значит, больше шансов получить информацию на английском. Быть программистом в современном мире и не знать английского — нонсенс.
В сях наверняка буферизован ввод-вывод.
Это скорее для каскадов класса Б/АБ, у автора же А, там нет перехода через 0. Да и то, в двухтактных все равно сколько-то сдвигают точку в линейную часть, чтобы не было ступеньки. Или я неправильно понимаю?