> Это означает, что размер любой структуры всегда будет кратен 4 (если размер структуры был 14, то в конец
> допишутся 2 ничего не значащих байта и размер станет равен 16).
Дополню: не обязательно в конец. Если внутри структуры идут, например, байтовые данные, они тоже выравниваются. Идея в том, что каждое поле структуры должно быть варавнено на 2/4 и т. д. байта.
Ну вот их и написали как раз те самые энтузиасты. А могли бы просто взять квейковский движок. :)
А если серьёзно, то писание движков практически с нуля — в гейм-девелопинге дело регулярное. Пишут часто, и это считается нормальным. Скажем, например, неповторимый стиль игре чужим движком не придать.
Берём продажи с сайта, вычисляем 5-10%, по глобальной статистике определяем, сколько времени будет актуален ИЕ6 — это возможная потерянная прибыль.
Считаем, сколько будет стоить разработка сайта с учётом ИЕ6 — это затраты.
После расчётов решение очевидно. :)
Но в целом, я придерживаюсь того мнения, что для таких случаев надо задействовать т. н. правило Парето — для практических нужд достаточно, чтобы сайт правильно показывался в 80% существующих браузеров.
Это если речь идёт о коммерческих сайтах. Для некоммерческих я бы предложил делать дизайн попроще. Такой дизайн кроссбраузерно верстается вполне нормально.
Мой опыт такой. Скорость набора была около 100-120 знаков в минуту до слепого метода. Слепому методу учился в 92-м году, как ни удивительно, тоже по методу Шахиджаняна, правда, тогда была обычная книжка «Соло на пишущей машинке». Ныне скорость за 300, давно не измерял.
Считаю слепой метод очень полезным методом, правда, какой именно методикой пользоваться — наверное, не так критично. Очень важно просто правильно поставить руки, чтобы пальцы работали каждый на своей территории.
Попытался кратко набросать — не вышло, в голове слишком много информации. Могу посоветовать тот путь, по которому шёл сам — вести учёт, попутно знакомясь с книгами. Очень многое можно найти в интернете.
Главная идея, которая не всегда озвучивается — тайм-менеджмент это инструмент. В начале надо разобраться с целями, понять, что нужно. Тогда тм работает.
Если цели выбраны неправильно, привести это может только к разочарованию.
Все механизмы работают, их надо просто применять, а ошибки учитывать.
Навскидку — у вас утрированное описание 3 из 4 механизмов. Доведённое до абсурда.
1. Не знаю, что вы за работу имеете в виду, когда пишете о параллельном выполнении задач, но для серьёзного программирования требуется серьёзная концентрация. Просто чтобы войти в задачу, может потребоваться 20 минут, а иногда и 2 часа. Подробнее эта тема освещена в книге «Человеческий фактор». Если не читали, почитайте, там интересно. Там рекомендуют сажать не более 2-х программистов в одну комнату и отключать телефон на время работы. Все положения книги подтверждены результатами экспериментов.
2. Тайм-менеджмент — это не одна-единственная система. Их, разных, существует не менее 20-ти. Далеко не каждая из них советует строгий распорядок дня. И ни одна из них не считает нарушение планов чем-то ужасным. Некоторые работают на то, чтобы у человека появилось «чувство времени». Скажем, зашкаливает телефонный разговор за 5 минут — включается лампочка в голове. Дальше можно сознательно решать — стоит разговор продолжать, отложить или совсем прекратить.
3. По поводу мотивации деньгами ничего не скажу — тема обширная, и к единому мнению так до сих пор и не пришли.
4. Пример с делегированием полномочий просто не выдерживает никакой критики. Ну, если вернуться к Вашему примеру, расскажу случай из своей жизни. Меня мама учила стирать носки и гладить рубашки. Если у меня что-то не получалось, перестировала не она, перестировал я — до тех пор, пока она не сказала «всё нормально». Удивительное дело, я до сих пор всё своё бельё стираю сам. Вот это пример правильного делегирования.
Согласен, правильнее было бы написать ~ вместо =. Естественно, я имел в виду не равно, а эквивалентно.
Что же касатеся «контекста шрифта», то здесь не согласен. Сам коэффициент, конечно, зависит от гарнитуры, но поскольку единицы относительны, сделать «на 20% больше» можно любую из них, результат будет одинаковым.
Там народ озаботился совместимостью со стандартами. С версии 2 можно делать сайт валидным без больших затрат времени, хотя, конечно, этим надо заниматься отдельно — в смысле, и самому ляпов не допускать.
Сторонние разработчики, когда свои расширения пишут, могут очень по разному реализовывать. Я вот столкнулся с XStandard (вебовский редактор), который генерировал ID не в соответствии со стандартом (что-то там было внутри, кажется $). Там ещё пара недоработок была, которые мне мешали, так я в конце концов просто написал компонент самостоятельно. Теперь он генерирует всё по человечески.
Не знаю, у кого как, у меня на Лебедева идиосинкразии нет. :)
А вот ответил я «неинтересно», по той причине, что за последние 5 или 6 лет, как парсер появился, он так и не стал значимым явлением в индустрии. Правильнее концентрироваться на том, что сообществом поддерживается как-то — python, ruby, php, c#.
Не чайник, это точно. Скорее, это особенности обучения.
Либо, что вероятнее, автор просто не стал плодить сущности, и точно так же не стал перечислять разного рода дюймы, сантиметры и пики. С точки зрения использования em и ex идентичны, 1.2em = 1.2ex = 120%.
Я лично для себя разделил контент и служебную информацию. С проблемой столкнулся ещё в 2000-м году, у шефа со зрением были проблемы (очень большая дальнозоркость, толстенные очки).
Нужно было сделать так, чтобы масштабирование шрифтов работало. Тогда, напомню, в опере не было функции «масштабировать всё». ;)
Оказалось, что на практике достаточно делать контент масштабируемым, а навигацию, разные кнопочки/логины и пр. — нет. На этом решении я остновился, и, в принципе, оно нормально работает.
Второе работающее решение (как здесь уже посоветовал aps) — отказаться от сложного дизайна. Тогда масштабирование навигации или кнопок не ухудшит ситуацию существенно. Хотя, случаи разные бывают.
> допишутся 2 ничего не значащих байта и размер станет равен 16).
Дополню: не обязательно в конец. Если внутри структуры идут, например, байтовые данные, они тоже выравниваются. Идея в том, что каждое поле структуры должно быть варавнено на 2/4 и т. д. байта.
А если серьёзно, то писание движков практически с нуля — в гейм-девелопинге дело регулярное. Пишут часто, и это считается нормальным. Скажем, например, неповторимый стиль игре чужим движком не придать.
Берём продажи с сайта, вычисляем 5-10%, по глобальной статистике определяем, сколько времени будет актуален ИЕ6 — это возможная потерянная прибыль.
Считаем, сколько будет стоить разработка сайта с учётом ИЕ6 — это затраты.
После расчётов решение очевидно. :)
Но в целом, я придерживаюсь того мнения, что для таких случаев надо задействовать т. н. правило Парето — для практических нужд достаточно, чтобы сайт правильно показывался в 80% существующих браузеров.
Это если речь идёт о коммерческих сайтах. Для некоммерческих я бы предложил делать дизайн попроще. Такой дизайн кроссбраузерно верстается вполне нормально.
С точки зрения разработчиков это в целом хорошо. Если пользователи не переходят на операу или файрфокс, значит, они переходят на новые версии ИЕ.
Больше шансов, что через пару лет верстать станет не в пример проще. Вот мы и радуемся.
Из последних, по-моему, Google активно участвует в финансировании.
Это война «бизнес против бизнеса».
Считаю слепой метод очень полезным методом, правда, какой именно методикой пользоваться — наверное, не так критично. Очень важно просто правильно поставить руки, чтобы пальцы работали каждый на своей территории.
Главная идея, которая не всегда озвучивается — тайм-менеджмент это инструмент. В начале надо разобраться с целями, понять, что нужно. Тогда тм работает.
Если цели выбраны неправильно, привести это может только к разочарованию.
Все механизмы работают, их надо просто применять, а ошибки учитывать.
Навскидку — у вас утрированное описание 3 из 4 механизмов. Доведённое до абсурда.
1. Не знаю, что вы за работу имеете в виду, когда пишете о параллельном выполнении задач, но для серьёзного программирования требуется серьёзная концентрация. Просто чтобы войти в задачу, может потребоваться 20 минут, а иногда и 2 часа. Подробнее эта тема освещена в книге «Человеческий фактор». Если не читали, почитайте, там интересно. Там рекомендуют сажать не более 2-х программистов в одну комнату и отключать телефон на время работы. Все положения книги подтверждены результатами экспериментов.
2. Тайм-менеджмент — это не одна-единственная система. Их, разных, существует не менее 20-ти. Далеко не каждая из них советует строгий распорядок дня. И ни одна из них не считает нарушение планов чем-то ужасным. Некоторые работают на то, чтобы у человека появилось «чувство времени». Скажем, зашкаливает телефонный разговор за 5 минут — включается лампочка в голове. Дальше можно сознательно решать — стоит разговор продолжать, отложить или совсем прекратить.
3. По поводу мотивации деньгами ничего не скажу — тема обширная, и к единому мнению так до сих пор и не пришли.
4. Пример с делегированием полномочий просто не выдерживает никакой критики. Ну, если вернуться к Вашему примеру, расскажу случай из своей жизни. Меня мама учила стирать носки и гладить рубашки. Если у меня что-то не получалось, перестировала не она, перестировал я — до тех пор, пока она не сказала «всё нормально». Удивительное дело, я до сих пор всё своё бельё стираю сам. Вот это пример правильного делегирования.
Что же касатеся «контекста шрифта», то здесь не согласен. Сам коэффициент, конечно, зависит от гарнитуры, но поскольку единицы относительны, сделать «на 20% больше» можно любую из них, результат будет одинаковым.
Сторонние разработчики, когда свои расширения пишут, могут очень по разному реализовывать. Я вот столкнулся с XStandard (вебовский редактор), который генерировал ID не в соответствии со стандартом (что-то там было внутри, кажется $). Там ещё пара недоработок была, которые мне мешали, так я в конце концов просто написал компонент самостоятельно. Теперь он генерирует всё по человечески.
А вот ответил я «неинтересно», по той причине, что за последние 5 или 6 лет, как парсер появился, он так и не стал значимым явлением в индустрии. Правильнее концентрироваться на том, что сообществом поддерживается как-то — python, ruby, php, c#.
Стратегически невыгодно.
Либо, что вероятнее, автор просто не стал плодить сущности, и точно так же не стал перечислять разного рода дюймы, сантиметры и пики. С точки зрения использования em и ex идентичны, 1.2em = 1.2ex = 120%.
Нужно было сделать так, чтобы масштабирование шрифтов работало. Тогда, напомню, в опере не было функции «масштабировать всё». ;)
Оказалось, что на практике достаточно делать контент масштабируемым, а навигацию, разные кнопочки/логины и пр. — нет. На этом решении я остновился, и, в принципе, оно нормально работает.
Второе работающее решение (как здесь уже посоветовал aps) — отказаться от сложного дизайна. Тогда масштабирование навигации или кнопок не ухудшит ситуацию существенно. Хотя, случаи разные бывают.