четверг, 30 сентября 2010 г.

Потребление и потребители / Валентин Перция

Сегодня (2003 год) потребление фасованной воды в СТРАНЕ составляет 20 л в год на человека. В абсолютном исчислении это почти миллиард литров в год – 833 560 000 л. Разумеется, при рассмотрении профиля потребителей становится ясно, что почти все 100 % такой воды «выпивает» городское население, причем в основном те, кого можно отнести к группе «работоспособный возраст, доход средний-плюс и выше».

Среди городского населения питьевую газированную воду потребляют 87,4 %, негазированную – 25,7 %. В 2002 году цифры были: 85,2 % и 18,3 % соответственно. Можно сказать, что рынок газированной питьевой воды уже практически насытился, тогда как негазированной питьевой растет почти по 50 % в год (табл. П1).

Таблица П1. Потребление воды в СТРАНЕ

Как видно из табл. П2, происходит перераспределение потребления: население предпочитает пить все больше и больше негазированную воду. Причем рост потребления столовой воды в упаковке более 5 л – самый интенсивный. Несмотря на то что всего четверть городского населения пьет негазированную воду (в любой упаковке) параллельно с газированной (около 90 %), динамика почти в два раза выше у потребления негазированной воды.

Таблица П2. Рост сегмента в представлении по категориям вод в 2003 году по сравнению с 2002 годом


вторник, 21 сентября 2010 г.

Выполняйте тесты с использованием реальных объемов данных, которые будут отображаться в вашем приложении / А. Г. Гузикевич

Обычная ошибка, которую допускают при написании кодов пользовательских интерфейсов. заключается в том, что в процессе проектирования и тестирования интерфейса используются данные меньшего объема, чем тот, с которым приходится сталкиваться при развертывании мобильного приложения. Алгоритм, который прекрасно справляется с извлечением из базы данных 20 элементов данных и их передачей пользовательскому интерфейсу, вовсе не обязательно сделает хорошо то же самое для 200 элементов данных. Если вы тестируете интерфейс, используя лишь небольшие наборы данных, то тем самым оставляете открытыми двери для множества неприятных сюрпризов, ожидающих вас на последующих стадиях разработки или при развертывании приложения, когда настанет черед работать с реальными объемами данных. Гораздо лучше выявлять все проблемы производительности еще на ранней стадии, когда для их преодоления могут быть найдены наиболее конструктивные решения; вносить изменения в проект впоследствии всегда труднее, это может нарушать стабильность работы приложения и почти всегда приводит к менее удовлетворительным результатам.

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

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


Работа с параметрами командной строки сценария / Андрей Владимирович Попов

Используя аргументы командной строки, в сценарии можно передавать различную информацию, скажем, те или иные переключатели или имена пользователей и рабочих станций. При задании аргумента можно указать либо только его значение, либо имя вместе со значением в следующем формате: "Имя_аргумента:Значение".

Замечание

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

Например, выполнив в командном окне строку

cscript Example.js /Имя:"Андрей Попов" /Возраст:30

или

cscript Example.js /Возраст:30 /Имя:"Андрей Попов"

мы передадим в сценарий Example.js два параметра: "Имя" со значением "Андрей Попов" и "Возраст" со значением "30". Значения этих параметров можно было передать и как безымянные параметры:

cscript Example.js "Андрей Попов" 30

Однако в последнем случае при задании безымянных аргументов будет важен порядок их указания в командной строке.

В WSH для обработки параметров командной строки служат следующие объекты-коллекции:

? WshArguments (содержит все параметры, как именные, так и безымянные);

? WshNamed (содержит только именные параметры);

? WshUnnamed (содержит только безымянные параметры).

Замечание

Описание аргументов командной строки в сценариях можно задавать с помощью XML-элементов <runtime>, <named> и <unnamed> (см. главу 3).

Для доступа к коллекциям, содержащим аргументы командной строки, в сценарии сначала нужно создать переменную-экземпляр объекта WshArguments; для этого используется свойство Arguments объекта WScript. Пример на языке JScript:

var objArgs=WScript.Arguments;

Для создания экземпляров коллекций WshNamed и WshUnnamed используются соответственно методы Named и Unnamed объекта WshArguments. Например:

var objNamedArgs=objArgs.Named;

var objUnnamedArgs=objArgs.Unnamed;

Методы и свойства коллекций WshArguments, WshNamed и WshUnnamed подробно описаны в главе 1. Отметим здесь только, что для корректной работы с параметрами командной строки, имена которых содержат символы кириллицы, эти имена в сценарии должны быть написаны в кодировке Windows.

В листингах 2.21 и 2.22 приведены примеры сценариев на языках JScript и VBScript, которые выводят на экран общее количество параметров командной строки, количество именных и безымянных аргументов, а также значения каждой из этих групп параметров. Результат работы этих сценариев, запущенных в консольном режиме, представлен на рис. 2.8.

Рис. 2.8. Результат работы сценария Args.js


Листинг 2.21. Доступ к параметрам командной строки запущенного сценария (JScript)

/********************************************************************/

/* Имя: Args.js                                                     */

/* Язык: JScript                                                    */

/* Описание: Работа с аргументами запущенного сценария              */

/********************************************************************/

var

 i,objArgs,s,objNamedArgs,objUnnamedArgs;  //Объявляем переменные

objArgs = WScript.Arguments;  //Создаем объект WshArguments

//Определяем общее количество аргументов

s="Всего аргументов: "+objArgs.Count()+"\n";

for (i=0; i<=objArgs.Count()-1; i++)

 s+=objArgs(i)+"\n"; //Формируем строки со значениями аргументов

objUnnamedArgs=objArgs.Unnamed;  //Создаем объект WshUnnamed

//Определяем количество безымянных аргументов

s+="\nБезымянных аргументов: "+objUnnamedArgs.length+"\n";

for (i=0; i<=objUnnamedArgs.length-1; i++)

 //Формируем строки со значениями безымянных аргументов

 s+=objUnnamedArgs(i)+"\n";

objNamedArgs=objArgs.Named; //Создаем объект WshNamed

//Определяем количество именных аргументов

s+="\nИменных аргументов: "+objNamedArgs.length+"\n";

//Проверяем, существует ли аргумент /Имя:

if (objNamedArgs.Exists("Имя")) s+=objNamedArgs("Имя")+"\n";

//Проверяем, существует ли аргумент /Comp:

if (objNamedArgs.Exists("Comp")) s+=objNamedArgs("Comp")+"\n";

WScript.Echo(s);  //Выводим сформированные строки

/*************  Конец *********************************************/

Листинг 2.22. Доступ к параметрам командной строки запущенного сценария (VBScript)

'********************************************************************

' Имя: Args.vbs

' Язык: VBScript

' Описание: Работа с аргументами запущенного сценария

'********************************************************************

Option Explicit

Dim i,Arg,objArgs,s,objNamedArgs,objUnnamedArgs  ' Объявляем переменные

Set objArgs = WScript.Arguments  ' Создаем объект WshArguments

' Определяем общее количество аргументов

s="Всего аргументов: " & objArgs.Count() & vbCrLf

For Each Arg In objArgs

 s=s & Arg & vbCrLf  ' Формируем строки со значениями аргументов

Next

Set objUnnamedArgs=objArgs.Unnamed  ' Создаем объект WshUnnamed

' Определяем количество безымянных аргументов

s=s & vbCrLf & "Безымянных аргументов: " & objUnnamedArgs.length & vbCrLf

For Each Arg In objUnnamedArgs

 ' Формируем строки со значениями безымянных аргументов

 s=s & Arg & vbCrLf

Next

Set objNamedArgs=objArgs.Named  ' Создаем объект WshNamed

' Определяем количество именных аргументов

s=s & vbCrLf & "Именных аргументов: " & objNamedArgs.Length & vbCrLf

' Проверяем, существует ли аргумент /Имя:

If objNamedArgs.Exists("Имя") Then

 s=s & objNamedArgs("Имя") & vbCrLf

End If

' Проверяем, существует ли аргумент /Comp:

If objNamedArgs.Exists("Comp") Then

 s=s & objNamedArgs("Comp") & vbCrLf

End If

WScript.Echo s   ' Выводим сформированные строки

'*************  Конец *********************************************


Cушка древесины / Наталья Гавриловна Коршевер

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

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

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

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

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

Чуть подсохшие доски смазывают с торцов садовым варом или клеем ПВА. Заготовки из ценных пород древесины необходимо смазывать не только с торцов, но и с боковых сторон, чтобы при сушке не образовались трещины. Такого же правила следует придерживаться и при сушке древесины плодовых деревьев. Слой ПВА можно заменить обычной бумагой, которая приклеивается к сторонам бруска крахмальным клейстером.

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

В зависимости от того, какого размера выбраны заготовки, время на сушку может варьироваться. Толстые и длинные доски сохнут намного дольше, чем тонкие и короткие.

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


4.6.6 Параметры по Умолчанию / Мюррей Хилл

Часто в самом общем случае функции требуется больше праметров, чем в самом простом и более употребительном случае. Например, в библиотеке потоков есть функция hex(), порождащая строку с шестнадцатиричным представлением целого. Второй параметр используется для задания числа символов для предтавления первого параметра. Если число символов слишком мало для представления целого, происходит усечение, если оно сликом велико, то строка дополняется пробелами. Часто програмист не заботится о числе символов, необходимых для предсталения целого, поскольку символов достаточно. Поэтому для нуля в качестве второго параметра определено значение «использвать столько символов, сколько нужно». Чтобы избежать засорния программы вызовами вроде hex(i,0), функция описывается так:

extern char* hex(long, int =0);

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

cout «„ „**“ «« hex(31) «« hex(32,3) «« «**“;

интерпретируется как

cout «„ „**“ «« hex(31,0) «« hex(32,3) «« «**“;

и напечатает:

** 1f 20**

Параметр по умолчанию проходит проверку типа во время описания функции и вычисляется во время ее вызова. Задавать параметр по умолчанию возможно только для последних парамеров, поэтому

int f(int, int =0, char* =0); // ok int g(int =0, int =0, char*); // ошибка int f(int =0, int, char* =0); // ошибка

Заметьте, что в этом контексте пробел между * и = явлется существенным (*= является операцией присваивания):

int nasty(char*=0); // синтаксическая ошибка