Первая - "Recommendations on how to handle business calls". Среди нас не только программисты!
Вторая - "Сессии PHP. Часть 1.".
Recommendations on how to handle business calls
10 things never to say on a business call
Good phone manners have always been important, of course. Yet too few companies make any effort to train employees in phone etiquette, says Nancy Friedman, president and founder of the Telephone Doctor, a St. Louis-based customer service training company. The result is often lost business, irate customers and squandered opportunities, she says.
Twenty years ago, Friedman and her husband Dick founded their company after Friedman suffered some particularly bad (and clearly inspirational) service from an insurance company. Friedman says she's still amazed at the number of corporations, small businesses and even call centres that ignore basic phone courtesies.
The No. 1 complaint from business professionals and consumers alike, according to Telephone Doctor surveys, is being put on hold. "Always ask, 'Are you able to hold?'" Friedman advises. "Putting people on hold without asking permission is a no-no."
Coincidentally, or not, rudeness is on the rise nationwide, according to a 2003 survey called "Aggravating Circumstances," conducted by Public Agenda, a non-profit research arm of The Pew Charitable Trusts. A whopping 8 out of every 10 Americans (79%) say that a lack of respect and courtesy should be regarded as a serious national problem. One dramatic finding was that rudeness knows no boundaries, as all regions and demographic audiences in the United States were equally at fault.
Customer service by phone evoked one of the survey's most negative reactions. Some 94% of the respondents called it "very frustrating" to call a company and be greeted by a recording rather than a person.
I canvassed communications and customer-service experts to bring to you the worst 10 things you can utter on a business call. These are, of course, in addition to that peremptory no-no: "Hold on." Keep in mind that phone courtesy, like all good manners, is largely based on common sense. You want to respond in the way you like to be treated.
Среди читателей, я уверен, есть такие, кто в PHP совсем не разбирается, кто только начал изучать, и такие, кто полагает, что он давно со всем разобрался и ничего нового узнать о PHP не сможет. Последние явно заблуждаются: всегда можно найти интересную задачу, которая вытащит на свет множество интересных и ранее не изученных (или плохо изученных) моментов. И тогда рытье в документации и эксперименты обеспечены.
В этой серии статей речь пойдет о сессиях PHP, хранении данных сессии, собственных обработчиках и т.д.
Свое изложение я решил начать с самого простого - чтобы было понятно и новичкам, и постепенно буду подходить к более интересному и сложному.
Сессии PHP. Механизм идентификации сессии.
Когда мы посещаем сайты, часто ли задумывается мы, как серверная программа помнит такие вещи, как введенный логин, какие сообщения мы еще не читали, какие товары мы положили в "корзину покупателя" и т.п.? Посетителю сайта нет необходимости знать это, а web-программисту эти знания лишними не будут.
Работает этот механизм просто, но в то же время довольно сложно.
Серверная программа запоминает переданные пользователем данные в сессии (сеансе) и достает их оттуда при следующем обращении на сервер. Но пользователей, работающих с одним сайтом, может быть несколько и для того, чтобы понять, где чья сессия, нужен какой-либо механизм идентификации. Так как же точно идентифицировать данную сессию?
Первое, что приходит на ум - использовать для этого IP-адрес компьютера пользователя. Вполне возможно, что на заре web-программирования так и делали, но с одного IP-адреса могут посылать запросы несколько пользователей. Например, если они работают через один proxy-сервер, или находятся в одной локальной сети и выходят в Интернет через NAT-шлюз, назначающий им один и тот же внешний IP-адрес. Да и за время посещения сайта адрес пользователя может поменяться (например, при восстановлении прерванного модемного
соединения). Т.е., механизм этот не надежен.
Выход только один - пользователь должен сам передавать свой идентификатор, сообщенный ему сервером.