text:
|Vinay Sajip <vinay_sajip at red-dove dot com>
This page contains a number of recipes related to logging, which have been found useful in the past.
Multiple calls to logging.getLogger('someLogger') return a reference to the same logger object. This is true not only within the same module, but also across modules as long as it is in the same Python interpreter process. It is true for references to the same object; additionally, application code can define and configure a parent logger in one module and create (but not configure) a child logger in a separate module, and all logger calls to the child will pass up to the parent. Here is a main module:
import logging
import auxiliary_module
# create logger with 'spam_application'
logger = logging.getLogger('spam_application')
# create file handler which logs even debug messages
fh = logging.FileHandler('spam.log')
# create console handler with a higher log level
ch = logging.StreamHandler()
# create formatter and add it to the handlers
formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
# add the handlers to the logger
logger.info('creating an instance of auxiliary_module.Auxiliary')
a = auxiliary_module.Auxiliary()
logger.info('created an instance of auxiliary_module.Auxiliary')
logger.info('calling auxiliary_module.Auxiliary.do_something')
logger.info('finished auxiliary_module.Auxiliary.do_something')
logger.info('calling auxiliary_module.some_function()')
logger.info('done with auxiliary_module.some_function()')
Here is the auxiliary module:
import logging
# create logger
module_logger = logging.getLogger('spam_application.auxiliary')
class Auxiliary:
def __init__(self):
self.logger = logging.getLogger('spam_application.auxiliary.Auxiliary')
self.logger.info('creating an instance of Auxiliary')
def do_something(self):
self.logger.info('doing something')
a = 1 + 1
self.logger.info('done doing something')
def some_function():
module_logger.info('received a call to "some_function"')
The output looks like this:
2005-03-23 23:47:11,663 - spam_application - INFO -
creating an instance of auxiliary_module.Auxiliary
2005-03-23 23:47:11,665 - spam_application.auxiliary.Auxiliary - INFO -
creating an instance of Auxiliary
2005-03-23 23:47:11,665 - spam_application - INFO -
created an instance of auxiliary_module.Auxiliary
2005-03-23 23:47:11,668 - spam_application - INFO -
calling auxiliary_module.Auxiliary.do_something
2005-03-23 23:47:11,668 - spam_application.auxiliary.Auxiliary - INFO -
doing something
2005-03-23 23:47:11,669 - spam_application.auxiliary.Auxiliary - INFO -
done doing something
2005-03-23 23:47:11,670 - spam_application - INFO -
finished auxiliary_module.Auxiliary.do_something
2005-03-23 23:47:11,671 - spam_application - INFO -
calling auxiliary_module.some_function()
2005-03-23 23:47:11,672 - spam_application.auxiliary - INFO -
received a call to 'some_function'
2005-03-23 23:47:11,673 - spam_application - INFO -
done with auxiliary_module.some_function()
Loggers are plain Python objects. The addHandler() method has no minimum or maximum quota for the number of handlers you may add. Sometimes it will be beneficial for an application to log all messages of all severities to a text file while simultaneously logging errors or above to the console. To set this up, simply configure the appropriate handlers. The logging calls in the application code will remain unchanged. Here is a slight modification to the previous simple module-based configuration example:
import logging
logger = logging.getLogger('simple_example')
# create file handler which logs even debug messages
fh = logging.FileHandler('spam.log')
# create console handler with a higher log level
ch = logging.StreamHandler()
# create formatter and add it to the handlers
formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
# add the handlers to logger
# 'application' code
logger.debug('debug message')
logger.info('info message')
logger.warn('warn message')
logger.error('error message')
logger.critical('critical message')
Notice that the 'application' code does not care about multiple handlers. All that changed was the addition and configuration of a new handler named fh.
The ability to create new handlers with higher- or lower-severity filters can be very helpful when writing and testing an application. Instead of using many print statements for debugging, use logger.debug: Unlike the print statements, which you will have to delete or comment out later, the logger.debug statements can remain intact in the source code and remain dormant until you need them again. At that time, the only change that needs to happen is to modify the severity level of the logger and/or handler to debug.
Let's say you want to log to console and file with different message formats and in differing circumstances. Say you want to log messages with levels of DEBUG and higher to file, and those messages at level INFO and higher to the console. Let's also assume that the file should contain timestamps, but the console messages should not. Here's how you can achieve this:
import logging
# set up logging to file - see previous section for more details
format='%(asctime)s %(name)-12s %(levelname)-8s %(message)s',
datefmt='%m-%d %H:%M',
# define a Handler which writes INFO messages or higher to the sys.stderr
console = logging.StreamHandler()
# set a format which is simpler for console use
formatter = logging.Formatter('%(name)-12s: %(levelname)-8s %(message)s')
# tell the handler to use this format
# add the handler to the root logger
# Now, we can log to the root logger, or any other logger. First the root...
logging.info('Jackdaws love my big sphinx of quartz.')
# Now, define a couple of other loggers which might represent areas in your
# application:
logger1 = logging.getLogger('myapp.area1')
logger2 = logging.getLogger('myapp.area2')
logger1.debug('Quick zephyrs blow, vexing daft Jim.')
logger1.info('How quickly daft jumping zebras vex.')
logger2.warning('Jail zesty vixen who grabbed pay from quack.')
logger2.error('The five boxing wizards jump quickly.')
When you run this, on the console you will see
root : INFO Jackdaws love my big sphinx of quartz.
myapp.area1 : INFO How quickly daft jumping zebras vex.
myapp.area2 : WARNING Jail zesty vixen who grabbed pay from quack.
myapp.area2 : ERROR The five boxing wizards jump quickly.
and in the file you will see something like
10-22 22:19 root INFO Jackdaws love my big sphinx of quartz.
10-22 22:19 myapp.area1 DEBUG Quick zephyrs blow, vexing daft Jim.
10-22 22:19 myapp.area1 INFO How quickly daft jumping zebras vex.
10-22 22:19 myapp.area2 WARNING Jail zesty vixen who grabbed pay from quack.
10-22 22:19 myapp.area2 ERROR The five boxing wizards jump quickly.
As you can see, the DEBUG message only shows up in the file. The other messages are sent to both destinations.
This example uses console and file handlers, but you can use any number and combination of handlers you choose.
Here is an example of a module using the logging configuration server:
import logging
import logging.config
import time
import os
# read initial config file
# create and start listener on port 9999
t = logging.config.listen(9999)
logger = logging.getLogger('simpleExample')
# loop through logging calls to see the difference
# new configurations make, until Ctrl+C is pressed
while True:
logger.debug('debug message')
logger.info('info message')
logger.warn('warn message')
logger.error('error message')
logger.critical('critical message')
except KeyboardInterrupt:
# cleanup
And here is a script that takes a filename and sends that file to the server, properly preceded with the binary-encoded length, as the new logging configuration:
#!/usr/bin/env python
import socket, sys, struct
with open(sys.argv[1], 'rb') as f:
data_to_send = f.read()
HOST = 'localhost'
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
print('sending config...')
s.send(struct.pack('>L', len(data_to_send)))
Sometimes you have to get your logging handlers to do their work without blocking the thread you're logging from. This is common in Web applications, though of course it also occurs in other scenarios.
A common culprit which demonstrates sluggish behaviour is the SMTPHandler: sending emails can take a long time, for a number of reasons outside the developer's control (for example, a poorly performing mail or network infrastructure). But almost any network-based handler can block: Even a SocketHandler operation may do a DNS query under the hood which is too slow (and this query can be deep in the socket library code, below the Python layer, and outside your control).
One solution is to use a two-part approach. For the first part, attach only a QueueHandler to those loggers which are accessed from performance-critical threads. They simply write to their queue, which can be sized to a large enough capacity or initialized with no upper bound to their size. The write to the queue will typically be accepted quickly, though you will probably need to catch the queue.Full exception as a precaution in your code. If you are a library developer who has performance-critical threads in their code, be sure to document this (together with a suggestion to attach only QueueHandlers to your loggers) for the benefit of other developers who will use your code.
The second part of the solution is QueueListener, which has been designed as the counterpart to QueueHandler. A QueueListener is very simple: it's passed a queue and some handlers, and it fires up an internal thread which listens to its queue for LogRecords sent from QueueHandlers (or any other source of LogRecords, for that matter). The LogRecords are removed from the queue and passed to the handlers for processing.
The advantage of having a separate QueueListener class is that you can use the same instance to service multiple QueueHandlers. This is more resource-friendly than, say, having threaded versions of the existing handler classes, which would eat up one thread per handler for no particular benefit.
An example of using these two classes follows (imports omitted):
que = queue.Queue(-1) # no limit on size
queue_handler = QueueHandler(que)
handler = logging.StreamHandler()
listener = QueueListener(que, handler)
root = logging.getLogger()
formatter = logging.Formatter('%(threadName)s: %(message)s')
# The log output will display the thread which generated
# the event (the main thread) rather than the internal
# thread which monitors the internal queue. This is what
# you want to happen.
root.warning('Look out!')
which, when run, will produce:
MainThread: Look out!
Let's say you want to send logging events across a network, and handle them at the receiving end. A simple way of doing this is attaching a SocketHandler instance to the root logger at the sending end:
import logging, logging.handlers
rootLogger = logging.getLogger('')
socketHandler = logging.handlers.SocketHandler('localhost',
# don't bother with a formatter, since a socket handler sends the event as
# an unformatted pickle
# Now, we can log to the root logger, or any other logger. First the root...
logging.info('Jackdaws love my big sphinx of quartz.')
# Now, define a couple of other loggers which might represent areas in your
# application:
logger1 = logging.getLogger('myapp.area1')
logger2 = logging.getLogger('myapp.area2')
logger1.debug('Quick zephyrs blow, vexing daft Jim.')
logger1.info('How quickly daft jumping zebras vex.')
logger2.warning('Jail zesty vixen who grabbed pay from quack.')
logger2.error('The five boxing wizards jump quickly.')
At the receiving end, you can set up a receiver using the socketserver module. Here is a basic working example:
import pickle
import logging
import logging.handlers
import socketserver
import struct
class LogRecordStreamHandler(socketserver.StreamRequestHandler):
"""Handler for a streaming logging request.
This basically logs the record using whatever logging policy is
configured locally.
def handle(self):
Handle multiple requests - each expected to be a 4-byte length,
followed by the LogRecord in pickle format. Logs the record
according to whatever policy is configured locally.
while True:
chunk = self.connection.recv(4)
if len(chunk) < 4:
slen = struct.unpack('>L', chunk)[0]
chunk = self.connection.recv(slen)
while len(chunk) < slen:
chunk = chunk + self.connection.recv(slen - len(chunk))
obj = self.unPickle(chunk)
record = logging.makeLogRecord(obj)
def unPickle(self, data):
return pickle.loads(data)
def handleLogRecord(self, record):
# if a name is specified, we use the named logger rather than the one
# implied by the record.
if self.server.logname is not None:
name = self.server.logname
name = record.name
logger = logging.getLogger(name)
# N.B. EVERY record gets logged. This is because Logger.handle
# is normally called AFTER logger-level filtering. If you want
# to do filtering, do it at the client end to save wasting
# cycles and network bandwidth!
class LogRecordSocketReceiver(socketserver.ThreadingTCPServer):
Simple TCP socket-based logging receiver suitable for testing.
allow_reuse_address = 1
def __init__(self, host='localhost',
socketserver.ThreadingTCPServer.__init__(self, (host, port), handler)
self.abort = 0
self.timeout = 1
self.logname = None
def serve_until_stopped(self):
import select
abort = 0
while not abort:
rd, wr, ex = select.select([self.socket.fileno()],
[], [],
if rd:
abort = self.abort
def main():
format='%(relativeCreated)5d %(name)-15s %(levelname)-8s %(message)s')
tcpserver = LogRecordSocketReceiver()
print('About to start TCP server...')
if __name__ == '__main__':
First run the server, and then the client. On the client side, nothing is printed on the console; on the server side, you should see something like:
About to start TCP server...
59 root INFO Jackdaws love my big sphinx of quartz.
59 myapp.area1 DEBUG Quick zephyrs blow, vexing daft Jim.
69 myapp.area1 INFO How quickly daft jumping zebras vex.
69 myapp.area2 WARNING Jail zesty vixen who grabbed pay from quack.
69 myapp.area2 ERROR The five boxing wizards jump quickly.
Note that there are some security issues with pickle in some scenarios. If these affect you, you can use an alternative serialization scheme by overriding the makePickle() method and implementing your alternative there, as well as adapting the above script to use your alternative serialization.
Sometimes you want logging output to contain contextual information in addition to the parameters passed to the logging call. For example, in a networked application, it may be desirable to log client-specific information in the log (e.g. remote client's username, or IP address). Although you could use the extra parameter to achieve this, it's not always convenient to pass the information in this way. While it might be tempting to create Logger instances on a per-connection basis, this is not a good idea because these instances are not garbage collected. While this is not a problem in practice, when the number of Logger instances is dependent on the level of granularity you want to use in logging an application, it could be hard to manage if the number of Logger instances becomes effectively unbounded.
An easy way in which you can pass contextual information to be output along with logging event information is to use the LoggerAdapter class. This class is designed to look like a Logger, so that you can call debug(), info(), warning(), error(), exception(), critical() and log(). These methods have the same signatures as their counterparts in Logger, so you can use the two types of instances interchangeably.
When you create an instance of LoggerAdapter, you pass it a Logger instance and a dict-like object which contains your contextual information. When you call one of the logging methods on an instance of LoggerAdapter, it delegates the call to the underlying instance of Logger passed to its constructor, and arranges to pass the contextual information in the delegated call. Here's a snippet from the code of LoggerAdapter:
def debug(self, msg, *args, **kwargs):
Delegate a debug call to the underlying logger, after adding
contextual information from this adapter instance.
msg, kwargs = self.process(msg, kwargs)
self.logger.debug(msg, *args, **kwargs)
The process() method of LoggerAdapter is where the contextual information is added to the logging output. It's passed the message and keyword arguments of the logging call, and it passes back (potentially) modified versions of these to use in the call to the underlying logger. The default implementation of this method leaves the message alone, but inserts an 'extra' key in the keyword argument whose value is the dict-like object passed to the constructor. Of course, if you had passed an 'extra' keyword argument in the call to the adapter, it will be silently overwritten.
The advantage of using 'extra' is that the values in the dict-like object are merged into the LogRecord instance's __dict__, allowing you to use customized strings with your Formatter instances which know about the keys of the dict-like object. If you need a different method, e.g. if you want to prepend or append the contextual information to the message string, you just need to subclass LoggerAdapter and override process() to do what you need. Here's an example script which uses this class, which also illustrates what dict-like behaviour is needed from an arbitrary 'dict-like' object for use in the constructor:
import logging
class ConnInfo:
An example class which shows how an arbitrary class can be used as
the 'extra' context information repository passed to a LoggerAdapter.
def __getitem__(self, name):
To allow this instance to look like a dict.
from random import choice
if name == 'ip':
result = choice(['127.0.0.1', '192.168.0.1'])
elif name == 'user':
result = choice(['jim', 'fred', 'sheila'])
result = self.__dict__.get(name, '?')
return result
def __iter__(self):
To allow iteration over keys, which will be merged into
the LogRecord dict before formatting and output.
keys = ['ip', 'user']
return keys.__iter__()
if __name__ == '__main__':
from random import choice
levels = (logging.DEBUG, logging.INFO, logging.WARNING, logging.ERROR, logging.CRITICAL)
a1 = logging.LoggerAdapter(logging.getLogger('a.b.c'),
{ 'ip' : '126.96.36.199', 'user' : 'sheila' })
format='%(asctime)-15s %(name)-5s %(levelname)-8s IP: %(ip)-15s User: %(user)-8s %(message)s')
a1.debug('A debug message')
a1.info('An info message with %s', 'some parameters')
a2 = logging.LoggerAdapter(logging.getLogger('d.e.f'), ConnInfo())
for x in range(10):
lvl = choice(levels)
lvlname = logging.getLevelName(lvl)
a2.log(lvl, 'A message at %s level with %d %s', lvlname, 2, 'parameters')
When this script is run, the output should look something like this:
2008-01-18 14:49:54,023 a.b.c DEBUG IP: 126.96.36.199 User: sheila A debug message
2008-01-18 14:49:54,023 a.b.c INFO IP: 220.127.116.11 User: sheila An info message with some parameters
2008-01-18 14:49:54,023 d.e.f CRITICAL IP: 192.168.0.1 User: jim A message at CRITICAL level with 2 parameters
2008-01-18 14:49:54,033 d.e.f INFO IP: 192.168.0.1 User: jim A message at INFO level with 2 parameters
2008-01-18 14:49:54,033 d.e.f WARNING IP: 192.168.0.1 User: sheila A message at WARNING level with 2 parameters
2008-01-18 14:49:54,033 d.e.f ERROR IP: 127.0.0.1 User: fred A message at ERROR level with 2 parameters
2008-01-18 14:49:54,033 d.e.f ERROR IP: 127.0.0.1 User: sheila A message at ERROR level with 2 parameters
2008-01-18 14:49:54,033 d.e.f WARNING IP: 192.168.0.1 User: sheila A message at WARNING level with 2 parameters
2008-01-18 14:49:54,033 d.e.f WARNING IP: 192.168.0.1 User: jim A message at WARNING level with 2 parameters
2008-01-18 14:49:54,033 d.e.f INFO IP: 192.168.0.1 User: fred A message at INFO level with 2 parameters
2008-01-18 14:49:54,033 d.e.f WARNING IP: 192.168.0.1 User: sheila A message at WARNING level with 2 parameters
2008-01-18 14:49:54,033 d.e.f WARNING IP: 127.0.0.1 User: jim A message at WARNING level with 2 parameters
You can also add contextual information to log output using a user-defined Filter. Filter instances are allowed to modify the LogRecords passed to them, including adding additional attributes which can then be output using a suitable format string, or if needed a custom Formatter.
For example in a web application, the request being processed (or at least, the interesting parts of it) can be stored in a threadlocal (threading.local) variable, and then accessed from a Filter to add, say, information from the request - say, the remote IP address and remote user's username - to the LogRecord, using the attribute names 'ip' and 'user' as in the LoggerAdapter example above. In that case, the same format string can be used to get similar output to that shown above. Here's an example script:
import logging
from random import choice
class ContextFilter(logging.Filter):
This is a filter which injects contextual information into the log.
Rather than use actual contextual information, we just use random
data in this demo.
USERS = ['jim', 'fred', 'sheila']
def filter(self, record):
record.ip = choice(ContextFilter.IPS)
record.user = choice(ContextFilter.USERS)
return True
if __name__ == '__main__':
levels = (logging.DEBUG, logging.INFO, logging.WARNING, logging.ERROR, logging.CRITICAL)
format='%(asctime)-15s %(name)-5s %(levelname)-8s IP: %(ip)-15s User: %(user)-8s %(message)s')
a1 = logging.getLogger('a.b.c')
a2 = logging.getLogger('d.e.f')
f = ContextFilter()
a1.debug('A debug message')
a1.info('An info message with %s', 'some parameters')
for x in range(10):
lvl = choice(levels)
lvlname = logging.getLevelName(lvl)
a2.log(lvl, 'A message at %s level with %d %s', lvlname, 2, 'parameters')
which, when run, produces something like:
2010-09-06 22:38:15,292 a.b.c DEBUG IP: 188.8.131.52 User: fred A debug message
2010-09-06 22:38:15,300 a.b.c INFO IP: 192.168.0.1 User: sheila An info message with some parameters
2010-09-06 22:38:15,300 d.e.f CRITICAL IP: 127.0.0.1 User: sheila A message at CRITICAL level with 2 parameters
2010-09-06 22:38:15,300 d.e.f ERROR IP: 127.0.0.1 User: jim A message at ERROR level with 2 parameters
2010-09-06 22:38:15,300 d.e.f DEBUG IP: 127.0.0.1 User: sheila A message at DEBUG level with 2 parameters
2010-09-06 22:38:15,300 d.e.f ERROR IP: 22.214.171.124 User: fred A message at ERROR level with 2 parameters
2010-09-06 22:38:15,300 d.e.f CRITICAL IP: 192.168.0.1 User: jim A message at CRITICAL level with 2 parameters
2010-09-06 22:38:15,300 d.e.f CRITICAL IP: 127.0.0.1 User: sheila A message at CRITICAL level with 2 parameters
2010-09-06 22:38:15,300 d.e.f DEBUG IP: 192.168.0.1 User: jim A message at DEBUG level with 2 parameters
2010-09-06 22:38:15,301 d.e.f ERROR IP: 127.0.0.1 User: sheila A message at ERROR level with 2 parameters
2010-09-06 22:38:15,301 d.e.f DEBUG IP: 220.127.116.11 User: fred A message at DEBUG level with 2 parameters
2010-09-06 22:38:15,301 d.e.f INFO IP: 220.127.116.11 User: fred A message at INFO level with 2 parameters
Although logging is thread-safe, and logging to a single file from multiple threads in a single process is supported, logging to a single file from multiple processes is not supported, because there is no standard way to serialize access to a single file across multiple processes in Python. If you need to log to a single file from multiple processes, one way of doing this is to have all the processes log to a SocketHandler, and have a separate process which implements a socket server which reads from the socket and logs to file. (If you prefer, you can dedicate one thread in one of the existing processes to perform this function.) This section documents this approach in more detail and includes a working socket receiver which can be used as a starting point for you to adapt in your own applications.
If you are using a recent version of Python which includes the multiprocessing module, you could write your own handler which uses the Lock class from this module to serialize access to the file from your processes. The existing FileHandler and subclasses do not make use of multiprocessing at present, though they may do so in the future. Note that at present, the multiprocessing module does not provide working lock functionality on all platforms (see http://bugs.python.org/issue3770).
Alternatively, you can use a Queue and a QueueHandler to send all logging events to one of the processes in your multi-process application. The following example script demonstrates how you can do this; in the example a separate listener process listens for events sent by other processes and logs them according to its own logging configuration. Although the example only demonstrates one way of doing it (for example, you may want to use a listener thread rather than a separate listener process – the implementation would be analogous) it does allow for completely different logging configurations for the listener and the other processes in your application, and can be used as the basis for code meeting your own specific requirements:
# You'll need these imports in your own code
import logging
import logging.handlers
import multiprocessing
# Next two import lines for this demo only
from random import choice, random
import time
# Because you'll want to define the logging configurations for listener and workers, the
# listener and worker process functions take a configurer parameter which is a callable
# for configuring logging for that process. These functions are also passed the queue,
# which they use for communication.
# In practice, you can configure the listener however you want, but note that in this
# simple example, the listener does not apply level or filter logic to received records.
# In practice, you would probably want to do this logic in the worker processes, to avoid
# sending events which would be filtered out between processes.
# The size of the rotated files is made small so you can see the results easily.
def listener_configurer():
root = logging.getLogger()
h = logging.handlers.RotatingFileHandler('mptest.log', 'a', 300, 10)
f = logging.Formatter('%(asctime)s %(processName)-10s %(name)s %(levelname)-8s %(message)s')
# This is the listener process top-level loop: wait for logging events
# (LogRecords)on the queue and handle them, quit when you get a None for a
# LogRecord.
def listener_process(queue, configurer):
while True:
record = queue.get()
if record is None: # We send this as a sentinel to tell the listener to quit.
logger = logging.getLogger(record.name)
logger.handle(record) # No level or filter logic applied - just do it!
except (KeyboardInterrupt, SystemExit):
import sys, traceback
print('Whoops! Problem:', file=sys.stderr)
# Arrays used for random selections in this demo
LEVELS = [logging.DEBUG, logging.INFO, logging.WARNING,
logging.ERROR, logging.CRITICAL]
LOGGERS = ['a.b.c', 'd.e.f']
'Random message #1',
'Random message #2',
'Random message #3',
# The worker configuration is done at the start of the worker process run.
# Note that on Windows you can't rely on fork semantics, so each process
# will run the logging configuration code when it starts.
def worker_configurer(queue):
h = logging.handlers.QueueHandler(queue) # Just the one handler needed
root = logging.getLogger()
root.setLevel(logging.DEBUG) # send all messages, for demo; no other level or filter logic applied.
# This is the worker process top-level loop, which just logs ten events with
# random intervening delays before terminating.
# The print messages are just so you know it's doing something!
def worker_process(queue, configurer):
name = multiprocessing.current_process().name
print('Worker started: %s' % name)
for i in range(10):
logger = logging.getLogger(choice(LOGGERS))
level = choice(LEVELS)
message = choice(MESSAGES)
logger.log(level, message)
print('Worker finished: %s' % name)
# Here's where the demo gets orchestrated. Create the queue, create and start
# the listener, create ten workers and start them, wait for them to finish,
# then send a None to the queue to tell the listener to finish.
def main():
queue = multiprocessing.Queue(-1)
listener = multiprocessing.Process(target=listener_process,
args=(queue, listener_configurer))
workers = []
for i in range(10):
worker = multiprocessing.Process(target=worker_process,
args=(queue, worker_configurer))
for w in workers:
if __name__ == '__main__':
A variant of the above script keeps the logging in the main process, in a separate thread:
import logging
import logging.config
import logging.handlers
from multiprocessing import Process, Queue
import random
import threading
import time
def logger_thread(q):
while True:
record = q.get()
if record is None:
logger = logging.getLogger(record.name)
def worker_process(q):
qh = logging.handlers.QueueHandler(q)
root = logging.getLogger()
levels = [logging.DEBUG, logging.INFO, logging.WARNING, logging.ERROR,
loggers = ['foo', 'foo.bar', 'foo.bar.baz',
'spam', 'spam.ham', 'spam.ham.eggs']
for i in range(100):
lvl = random.choice(levels)
logger = logging.getLogger(random.choice(loggers))
logger.log(lvl, 'Message no. %d', i)
if __name__ == '__main__':
q = Queue()
d = {
'version': 1,
'formatters': {
'detailed': {
'class': 'logging.Formatter',
'format': '%(asctime)s %(name)-15s %(levelname)-8s %(processName)-10s %(message)s'
'handlers': {
'console': {
'class': 'logging.StreamHandler',
'level': 'INFO',
'file': {
'class': 'logging.FileHandler',
'filename': 'mplog.log',
'mode': 'w',
'formatter': 'detailed',
'foofile': {
'class': 'logging.FileHandler',
'filename': 'mplog-foo.log',
'mode': 'w',
'formatter': 'detailed',
'errors': {
'class': 'logging.FileHandler',
'filename': 'mplog-errors.log',
'mode': 'w',
'level': 'ERROR',
'formatter': 'detailed',
'loggers': {
'foo': {
'handlers' : ['foofile']
'root': {
'level': 'DEBUG',
'handlers': ['console', 'file', 'errors']
workers = []
for i in range(5):
wp = Process(target=worker_process, name='worker %d' % (i + 1), args=(q,))
lp = threading.Thread(target=logger_thread, args=(q,))
# At this point, the main process could do some useful work of its own
# Once it's done that, it can wait for the workers to terminate...
for wp in workers:
# And now tell the logging thread to finish up, too
This variant shows how you can e.g. apply configuration for particular loggers - e.g. the foo logger has a special handler which stores all events in the foo subsystem in a file mplog-foo.log. This will be used by the logging machinery in the main process (even though the logging events are generated in the worker processes) to direct the messages to the appropriate destinations.
Sometimes you want to let a log file grow to a certain size, then open a new file and log to that. You may want to keep a certain number of these files, and when that many files have been created, rotate the files so that the number of files and the size of the files both remain bounded. For this usage pattern, the logging package provides a RotatingFileHandler:
import glob
import logging
import logging.handlers
LOG_FILENAME = 'logging_rotatingfile_example.out'
# Set up a specific logger with our desired output level
my_logger = logging.getLogger('MyLogger')
# Add the log message handler to the logger
handler = logging.handlers.RotatingFileHandler(
LOG_FILENAME, maxBytes=20, backupCount=5)
# Log some messages
for i in range(20):
my_logger.debug('i = %d' % i)
# See what files are created
logfiles = glob.glob('%s*' % LOG_FILENAME)
for filename in logfiles:
The result should be 6 separate files, each with part of the log history for the application:
The most current file is always logging_rotatingfile_example.out, and each time it reaches the size limit it is renamed with the suffix .1. Each of the existing backup files is renamed to increment the suffix (.1 becomes .2, etc.) and the .6 file is erased.
Obviously this example sets the log length much too small as an extreme example. You would want to set maxBytes to an appropriate value.
When logging was added to the Python standard library, the only way of formatting messages with variable content was to use the %-formatting method. Since then, Python has gained two new formatting approaches: string.Template (added in Python 2.4) and str.format() (added in Python 2.6).
Logging (as of 3.2) provides improved support for these two additional formatting styles. The Formatter class been enhanced to take an additional, optional keyword parameter named style. This defaults to '%', but other possible values are '{' and '$', which correspond to the other two formatting styles. Backwards compatibility is maintained by default (as you would expect), but by explicitly specifying a style parameter, you get the ability to specify format strings which work with str.format() or string.Template. Here's an example console session to show the possibilities:
>>> import logging
>>> root = logging.getLogger()
>>> root.setLevel(logging.DEBUG)
>>> handler = logging.StreamHandler()
>>> bf = logging.Formatter('{asctime} {name} {levelname:8s} {message}',
... style='{')
>>> handler.setFormatter(bf)
>>> root.addHandler(handler)
>>> logger = logging.getLogger('foo.bar')
>>> logger.debug('This is a DEBUG message')
2010-10-28 15:11:55,341 foo.bar DEBUG This is a DEBUG message
>>> logger.critical('This is a CRITICAL message')
2010-10-28 15:12:11,526 foo.bar CRITICAL This is a CRITICAL message
>>> df = logging.Formatter('$asctime $name ${levelname} $message',
... style='$')
>>> handler.setFormatter(df)
>>> logger.debug('This is a DEBUG message')
2010-10-28 15:13:06,924 foo.bar DEBUG This is a DEBUG message
>>> logger.critical('This is a CRITICAL message')
2010-10-28 15:13:11,494 foo.bar CRITICAL This is a CRITICAL message
Note that the formatting of logging messages for final output to logs is completely independent of how an individual logging message is constructed. That can still use %-formatting, as shown here:
>>> logger.error('This is an%s %s %s', 'other,', 'ERROR,', 'message')
2010-10-28 15:19:29,833 foo.bar ERROR This is another, ERROR, message
Logging calls (logger.debug(), logger.info() etc.) only take positional parameters for the actual logging message itself, with keyword parameters used only for determining options for how to handle the actual logging call (e.g. the exc_info keyword parameter to indicate that traceback information should be logged, or the extra keyword parameter to indicate additional contextual information to be added to the log). So you cannot directly make logging calls using str.format() or string.Template syntax, because internally the logging package uses %-formatting to merge the format string and the variable arguments. There would no changing this while preserving backward compatibility, since all logging calls which are out there in existing code will be using %-format strings.
There is, however, a way that you can use {}- and $- formatting to construct your individual log messages. Recall that for a message you can use an arbitrary object as a message format string, and that the logging package will call str() on that object to get the actual format string. Consider the following two classes:
class BraceMessage:
def __init__(self, fmt, *args, **kwargs):
self.fmt = fmt
self.args = args
self.kwargs = kwargs
def __str__(self):
return self.fmt.format(*self.args, **self.kwargs)
class DollarMessage:
def __init__(self, fmt, **kwargs):
self.fmt = fmt
self.kwargs = kwargs
def __str__(self):
from string import Template
return Template(self.fmt).substitute(**self.kwargs)
Either of these can be used in place of a format string, to allow {}- or $-formatting to be used to build the actual "message" part which appears in the formatted log output in place of "%(message)s" or "{message}" or "$message". It's a little unwieldy to use the class names whenever you want to log something, but it's quite palatable if you use an alias such as __ (double underscore – not to be confused with _, the single underscore used as a synonym/alias for gettext.gettext() or its brethren).
The above classes are not included in Python, though they're easy enough to copy and paste into your own code. They can be used as follows (assuming that they're declared in a module called wherever):
>>> from wherever import BraceMessage as __
>>> print(__('Message with {0} {name}', 2, name='placeholders'))
Message with 2 placeholders
>>> class Point: pass
>>> p = Point()
>>> p.x = 0.5
>>> p.y = 0.5
>>> print(__('Message with coordinates: ({point.x:.2f}, {point.y:.2f})',
... point=p))
Message with coordinates: (0.50, 0.50)
>>> from wherever import DollarMessage as __
>>> print(__('Message with $num $what', num=2, what='placeholders'))
Message with 2 placeholders
While the above examples use print() to show how the formatting works, you would of course use logger.debug() or similar to actually log using this approach.
One thing to note is that you pay no significant performance penalty with this approach: the actual formatting happens not when you make the logging call, but when (and if) the logged message is actually about to be output to a log by a handler. So the only slightly unusual thing which might trip you up is that the parentheses go around the format string and the arguments, not just the format string. That's because the __ notation is just syntax sugar for a constructor call to one of the XXXMessage classes.
Every logging event is represented by a LogRecord instance. When an event is logged and not filtered out by a logger's level, a LogRecord is created, populated with information about the event and then passed to the handlers for that logger (and its ancestors, up to and including the logger where further propagation up the hierarchy is disabled). Before Python 3.2, there were only two places where this creation was done:
This has usually meant that if you need to do anything special with a LogRecord, you've had to do one of the following.
The first approach would be a little unwieldy in the scenario where (say) several different libraries wanted to do different things. Each would attempt to set its own Logger subclass, and the one which did this last would win.
The second approach works reasonably well for many cases, but does not allow you to e.g. use a specialized subclass of LogRecord. Library developers can set a suitable filter on their loggers, but they would have to remember to do this every time they introduced a new logger (which they would do simply by adding new packages or modules and doing
logger = logging.getLogger(__name__)
at module level). It's probably one too many things to think about. Developers could also add the filter to a NullHandler attached to their top-level logger, but this would not be invoked if an application developer attached a handler to a lower-level library logger – so output from that handler would not reflect the intentions of the library developer.
In Python 3.2 and later, LogRecord creation is done through a factory, which you can specify. The factory is just a callable you can set with setLogRecordFactory(), and interrogate with getLogRecordFactory(). The factory is invoked with the same signature as the LogRecord constructor, as LogRecord is the default setting for the factory.
This approach allows a custom factory to control all aspects of LogRecord creation. For example, you could return a subclass, or just add some additional attributes to the record once created, using a pattern similar to this:
old_factory = logging.getLogRecordFactory()
def record_factory(*args, **kwargs):
record = old_factory(*args, **kwargs)
record.custom_attribute = 0xdecafbad
return record
This pattern allows different libraries to chain factories together, and as long as they don't overwrite each other's attributes or unintentionally overwrite the attributes provided as standard, there should be no surprises. However, it should be borne in mind that each link in the chain adds run-time overhead to all logging operations, and the technique should only be used when the use of a Filter does not provide the desired result.
You can use a QueueHandler subclass to send messages to other kinds of queues, for example a ZeroMQ 'publish' socket. In the example below,the socket is created separately and passed to the handler (as its 'queue'):
import zmq # using pyzmq, the Python binding for ZeroMQ
import json # for serializing records portably
ctx = zmq.Context()
sock = zmq.Socket(ctx, zmq.PUB) # or zmq.PUSH, or other suitable value
sock.bind('tcp://*:5556') # or wherever
class ZeroMQSocketHandler(QueueHandler):
def enqueue(self, record):
data = json.dumps(record.__dict__)
handler = ZeroMQSocketHandler(sock)
Of course there are other ways of organizing this, for example passing in the data needed by the handler to create the socket:
class ZeroMQSocketHandler(QueueHandler):
def __init__(self, uri, socktype=zmq.PUB, ctx=None):
self.ctx = ctx or zmq.Context()
socket = zmq.Socket(self.ctx, socktype)
QueueHandler.__init__(self, socket)
def enqueue(self, record):
data = json.dumps(record.__dict__)
def close(self):
You can also subclass QueueListener to get messages from other kinds of queues, for example a ZeroMQ 'subscribe' socket. Here's an example:
class ZeroMQSocketListener(QueueListener):
def __init__(self, uri, *handlers, **kwargs):
self.ctx = kwargs.get('ctx') or zmq.Context()
socket = zmq.Socket(self.ctx, zmq.SUB)
socket.setsockopt(zmq.SUBSCRIBE, '') # subscribe to everything
def dequeue(self):
msg = self.queue.recv()
return logging.makeLogRecord(json.loads(msg))
See also
Below is an example of a logging configuration dictionary - it's taken from the documentation on the Django project. This dictionary is passed to dictConfig() to put the configuration into effect:
'version': 1,
'disable_existing_loggers': True,
'formatters': {
'verbose': {
'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s'
'simple': {
'format': '%(levelname)s %(message)s'
'filters': {
'special': {
'()': 'project.logging.SpecialFilter',
'foo': 'bar',
'handlers': {
'null': {
'formatter': 'simple'
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler',
'filters': ['special']
'loggers': {
'django': {
'propagate': True,
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': False,
'myproject.custom': {
'handlers': ['console', 'mail_admins'],
'level': 'INFO',
'filters': ['special']
For more information about this configuration, you can see the relevant section of the Django documentation.
The following working example shows how logging can be used with multiprocessing using configuration files. The configurations are fairly simple, but serve to illustrate how more complex ones could be implemented in a real multiprocessing scenario.
In the example, the main process spawns a listener process and some worker processes. Each of the main process, the listener and the workers have three separate configurations (the workers all share the same configuration). We can see logging in the main process, how the workers log to a QueueHandler and how the listener implements a QueueListener and a more complex logging configuration, and arranges to dispatch events received via the queue to the handlers specified in the configuration. Note that these configurations are purely illustrative, but you should be able to adapt this example to your own scenario.
Here's the script - the docstrings and the comments hopefully explain how it works:
import logging
import logging.config
import logging.handlers
from multiprocessing import Process, Queue, Event, current_process
import os
import random
import time
class MyHandler:
A simple handler for logging events. It runs in the listener process and
dispatches events to loggers based on the name in the received record,
which then get dispatched, by the logging system, to the handlers
configured for those loggers.
def handle(self, record):
logger = logging.getLogger(record.name)
# The process name is transformed just to show that it's the listener
# doing the logging to files and console
record.processName = '%s (for %s)' % (current_process().name, record.processName)
def listener_process(q, stop_event, config):
This could be done in the main process, but is just done in a separate
process for illustrative purposes.
This initialises logging according to the specified configuration,
starts the listener and waits for the main process to signal completion
via the event. The listener is then stopped, and the process exits.
listener = logging.handlers.QueueListener(q, MyHandler())
if os.name == 'posix':
# On POSIX, the setup logger will have been configured in the
# parent process, but should have been disabled following the
# dictConfig call.
# On Windows, since fork isn't used, the setup logger won't
# exist in the child, so it would be created and the message
# would appear - hence the "if posix" clause.
logger = logging.getLogger('setup')
logger.critical('Should not appear, because of disabled logger ...')
def worker_process(config):
A number of these are spawned for the purpose of illustration. In
practice, they could be a heterogenous bunch of processes rather than
ones which are identical to each other.
This initialises logging according to the specified configuration,
and logs a hundred messages with random levels to randomly selected
A small sleep is added to allow other processes a chance to run. This
is not strictly needed, but it mixes the output from the different
processes a bit more than if it's left out.
levels = [logging.DEBUG, logging.INFO, logging.WARNING, logging.ERROR,
loggers = ['foo', 'foo.bar', 'foo.bar.baz',
'spam', 'spam.ham', 'spam.ham.eggs']
if os.name == 'posix':
# On POSIX, the setup logger will have been configured in the
# parent process, but should have been disabled following the
# dictConfig call.
# On Windows, since fork isn't used, the setup logger won't
# exist in the child, so it would be created and the message
# would appear - hence the "if posix" clause.
logger = logging.getLogger('setup')
logger.critical('Should not appear, because of disabled logger ...')
for i in range(100):
lvl = random.choice(levels)
logger = logging.getLogger(random.choice(loggers))
logger.log(lvl, 'Message no. %d', i)
def main():
q = Queue()
# The main process gets a simple configuration which prints to the console.
config_initial = {
'version': 1,
'formatters': {
'detailed': {
'class': 'logging.Formatter',
'format': '%(asctime)s %(name)-15s %(levelname)-8s %(processName)-10s %(message)s'
'handlers': {
'console': {
'class': 'logging.StreamHandler',
'level': 'INFO',
'root': {
'level': 'DEBUG',
'handlers': ['console']
# The worker process configuration is just a QueueHandler attached to the
# root logger, which allows all messages to be sent to the queue.
# We disable existing loggers to disable the "setup" logger used in the
# parent process. This is needed on POSIX because the logger will
# be there in the child following a fork().
config_worker = {
'version': 1,
'disable_existing_loggers': True,
'handlers': {
'queue': {
'class': 'logging.handlers.QueueHandler',
'queue': q,
'root': {
'level': 'DEBUG',
'handlers': ['queue']
# The listener process configuration shows that the full flexibility of
# logging configuration is available to dispatch events to handlers however
# you want.
# We disable existing loggers to disable the "setup" logger used in the
# parent process. This is needed on POSIX because the logger will
# be there in the child following a fork().
config_listener = {
'version': 1,
'disable_existing_loggers': True,
'formatters': {
'detailed': {
'class': 'logging.Formatter',
'format': '%(asctime)s %(name)-15s %(levelname)-8s %(processName)-10s %(message)s'
'simple': {
'class': 'logging.Formatter',
'format': '%(name)-15s %(levelname)-8s %(processName)-10s %(message)s'
'handlers': {
'console': {
'class': 'logging.StreamHandler',
'level': 'INFO',
'formatter': 'simple',
'file': {
'class': 'logging.FileHandler',
'filename': 'mplog.log',
'mode': 'w',
'formatter': 'detailed',
'foofile': {
'class': 'logging.FileHandler',
'filename': 'mplog-foo.log',
'mode': 'w',
'formatter': 'detailed',
'errors': {
'class': 'logging.FileHandler',
'filename': 'mplog-errors.log',
'mode': 'w',
'level': 'ERROR',
'formatter': 'detailed',
'loggers': {
'foo': {
'handlers' : ['foofile']
'root': {
'level': 'DEBUG',
'handlers': ['console', 'file', 'errors']
# Log some initial events, just to show that logging in the parent works
# normally.
logger = logging.getLogger('setup')
logger.info('About to create workers ...')
workers = []
for i in range(5):
wp = Process(target=worker_process, name='worker %d' % (i + 1),
logger.info('Started worker: %s', wp.name)
logger.info('About to create listener ...')
stop_event = Event()
lp = Process(target=listener_process, name='listener',
args=(q, stop_event, config_listener))
logger.info('Started listener')
# We now hang around for the workers to finish their work.
for wp in workers:
# Workers all done, listening can now stop.
# Logging in the parent still works normally.
logger.info('Telling listener to stop ...')
logger.info('All done.')
if __name__ == '__main__':
RFC 5424 requires that a Unicode message be sent to a syslog daemon as a set of bytes which have the following structure: an optional pure-ASCII component, followed by a UTF-8 Byte Order Mark (BOM), followed by Unicode encoded using UTF-8. (See the relevant section of the specification.)
In Python 3.1, code was added to SysLogHandler to insert a BOM into the message, but unfortunately, it was implemented incorrectly, with the BOM appearing at the beginning of the message and hence not allowing any pure-ASCII component to appear before it.
As this behaviour is broken, the incorrect BOM insertion code is being removed from Python 3.2.4 and later. However, it is not being replaced, and if you want to produce RFC 5424-compliant messages which include a BOM, an optional pure-ASCII sequence before it and arbitrary Unicode after it, encoded using UTF-8, then you need to do the following:
Attach a Formatter instance to your SysLogHandler instance, with a format string such as:
'ASCII section\ufeffUnicode section'
The Unicode code point U+FEFF, when encoded using UTF-8, will be encoded as a UTF-8 BOM – the byte-string b'\xef\xbb\xbf'.
Replace the ASCII section with whatever placeholders you like, but make sure that the data that appears in there after substitution is always ASCII (that way, it will remain unchanged after UTF-8 encoding).
Replace the Unicode section with whatever placeholders you like; if the data which appears there after substitution contains characters outside the ASCII range, that's fine – it will be encoded using UTF-8.
The formatted message will be encoded using UTF-8 encoding by SysLogHandler. If you follow the above rules, you should be able to produce RFC 5424-compliant messages. If you don't, logging may not complain, but your messages will not be RFC 5424-compliant, and your syslog daemon may complain.
Although most logging messages are intended for reading by humans, and thus not readily machine-parseable, there might be cirumstances where you want to output messages in a structured format which is capable of being parsed by a program (without needing complex regular expressions to parse the log message). This is straightforward to achieve using the logging package. There are a number of ways in which this could be achieved, but the following is a simple approach which uses JSON to serialise the event in a machine-parseable manner:
import json
import logging
class StructuredMessage(object):
def __init__(self, message, **kwargs):
self.message = message
self.kwargs = kwargs
def __str__(self):
return '%s >>> %s' % (self.message, json.dumps(self.kwargs))
_ = StructuredMessage # optional, to improve readability
logging.basicConfig(level=logging.INFO, format='%(message)s')
logging.info(_('message 1', foo='bar', bar='baz', num=123, fnum=123.456))
If the above script is run, it prints:
message 1 >>> {"fnum": 123.456, "num": 123, "bar": "baz", "foo": "bar"}
Note that the order of items might be different according to the version of Python used.
If you need more specialised processing, you can use a custom JSON encoder, as in the following complete example:
from __future__ import unicode_literals
import json
import logging
# This next bit is to ensure the script runs unchanged on 2.x and 3.x
except NameError:
unicode = str
class Encoder(json.JSONEncoder):
def default(self, o):
if isinstance(o, set):
return tuple(o)
elif isinstance(o, unicode):
return o.encode('unicode_escape').decode('ascii')
return super(Encoder, self).default(o)
class StructuredMessage(object):
def __init__(self, message, **kwargs):
self.message = message
self.kwargs = kwargs
def __str__(self):
s = Encoder().encode(self.kwargs)
return '%s >>> %s' % (self.message, s)
_ = StructuredMessage # optional, to improve readability
def main():
logging.basicConfig(level=logging.INFO, format='%(message)s')
logging.info(_('message 1', set_value=set([1, 2, 3]), snowman='\u2603'))
if __name__ == '__main__':
When the above script is run, it prints:
message 1 >>> {"snowman": "\u2603", "set_value": [1, 2, 3]}
Note that the order of items might be different according to the version of Python used.


text:
Almond & Olive Cleanser is a transparent body cleanser made especially for Dry Skin. Made using a blend of Almond, Jojoba & Olive oils , known for their moisturizing properties
Also helps in balancing Pitta (for soothing), Vata (for relaxing) and Kapha (for rejuvenating).
- Provides a natural and effective emollient effect for mature and dry skin
- Acts as a gentle cleanser
- Helps to maintain the required ph-balance of skin thus protecting it from adverse environmental conditions
Side effects:None

subset: commoncrawl


text:
Considering the number of rumours about the new Xbox circling around right now, we're considering changing April to Xbox-ril here at TechRadar. And as the stories have come flooding in, the gaming community has been unsurprisingly vocal in letting us know how it feels.
Until now, word has been that the new Xbox will have a feature that would make it only playable online, while saying goodbye to backwards compatibility and - though this third one's the least likely – blocking the use of old games.
MS seems to consider its competitors to be Apple and Google in the console space. MS seems to be following a different path then Sony. Sony has changed its stance from "It only does everything" on the Ps3 to a very "Gamercentric" experience on the Ps4. MS has seemed to be setting its site on every living room in the developed world. So when a mom goes into a shop and sees the Xbox 720 she says:
"Hey whats that?" ....."So wait you telling me I can watch TV, do Zumba fitness and my son can play Call of War. Count me in." So if Sony's Ps4 is considered "Next gen" but MS calls its competitors Apple and Google and hasnt even mentioned Sony and Valve, is MS actually trying to win this Next Gen of GAME consoles or are they trying to win a different war over IOS(Apple TV) and Android(Google TV) in the living room.
None of that will make it win next gen. Sony already has all the great exclusives and so far unless the xbox is way more powerful or something, sony are looking to come out on top. It may sell more sure but it doesn't look like it will succeed for the hardcore gamers.
Why does anyone need to "win" anything? How about articles like "how can Sony/MS/Nintendo be profitable and provide better experiences for gamers"? Next Gen isn't here yet and these articles are already getting on my nerves. How can all 3 be winners? Just make your consoles enjoyable for your customers.


text:
- 5 Year Frame warranty
- Direct from the manufacturer
- No risk 21 day home trial
High Back Chairs
If you are looking to add a touch of regality to your home, a high backed chair might be just the ticket.
Whether you are looking for a high back leather armchair for your old style drawing room or a more contemporary fabric piece for the lounge, a high back chair will always add a certain 'je ne sais quoi' to any space.
It can also be a blessed relief for those in need of excellent posture and back support!
Harriet Highback Chair
Was £479 Sale £359
Louis Companion Chair
Was £519 Sale £389
Emily Companion Chair
Was £469 Sale £349
Blenheim Highback Chair
Was £519 Sale £389
Woburn Highback Chair
Was £429 Sale £319
Hampton Highback Chair
Was £509 Sale £379
Banbury Highback Chair
Was £479 Sale £359
Ludlow Highback Chair
Was £459 Sale £339


text:
To paraphrase an old saying: what strange economic times we live in.
Following a theme I've sounded in this space more than a few times, the U.S. economy just can't seem to make up its mind as to what it's about: Is the recovery gaining speed? Or are we headed for another crackup? No one is quite sure.
Indeed, even the experts seem confounded by the highly confusing mix of economic data out there (click here to read an excellent analysis of this very issue by noted business columnist Robert Samuelson) and that's muddying up the forecasting waters even for truck manufacturers and their suppliers, too.
For example, take this story generated from comments and interviews during the 2013 Mid America Trucking Show last week: there's enough "certain uncertainty" out there (to steal Martin Daum's clever turn of phrase) to give anyone in the trucking business a big moment of pause.
Yet the economic environment can't be viewed entirely in a negative light because, frankly, a lot of good things are going on. Joe McAleese, president and CEO of Bendix Commercial Vehicle Systems, touched on more than a few of them during a press event at Mid America last week, which you can view in the video below:
Yet others closer to the front lines in trucking stressed to me that things are much tougher than they should be, especially if many economic indicators are flashing the "green light" as indicated by Bendix's McAleese.
"These are tough times for our drivers; fuel prices are up but rates are not going up," Brian Helton, head of contract relations at Mercer Transportation, told me during Mid America last week.
"I spoke to one of our 20-year Mercer veterans – one of our top revenue producers – and he said it's becoming harder to make a living at this [driving trucks] because fuel prices are high, all the regulatory changes are making it more costly to operate, yet we can't seem to squeeze any more money out of shippers to haul their freight."
Helton noted that back during the last freight "boom" in 2007 shippers in need of capacity would ask how much it would cost. Today, though, shippers are offering their loads at a set price – and no more.
"We need to get a rate that's cost-effective for our owner-operators, for them to make a living," he explained. "Right now it's hard to negotiate that."
Yet it may not be hard for much longer to get the necessary rate increases, at least according to the portents Bruce Carlton, president and CEO of the National Industrial Transportation League (NITL), sees developing on the horizon.
In a conference call last week hosted by Wall Street firm Stifel Nicolaus, Carlton said the NITL's attempt to slow down the July 1 implementation of the new hours-of-service rules "has fallen on deaf ears" and that what he dubs those "productivity sapping rules" will potentially throw the supply and demand balance in the trucking industry out of kilter – into the favor of the truckers.
"Ultimately, it will be the mandated use of electronic on-board recorders (EOBRs) that will most certainly shrink effective capacity," he added.
The big critical metric for trucking, though, will be gross domestic product (GDP) growth in the coming months, John Coll, VP-global marketing for Eaton Corp., told me during Mid America.
"There's nothing tangible yet in this regard but the tailwinds are there: industrial production is up, housing is up, and tonnage is up," he said. "But until we reach 3% GDP, we will not see the [trucking] industry adding any capacity."
Coll said that right now trucking is in what he calls a "state of equilibrium" where there's just the right amount of trucks to haul the freight being tendered. One factoid confirming that analysis to his mind comes from the big uptick in demand from truck leasing firms over the past two years.
"Why is that? Well, when you are uncertain, you lease trucks rather than buy them," he explained. "And over the last two years demand for trucks has been very strong from the truck leasing segment."
Still, that won't translate into an uptick in truck production quite yet, as Eaton is projecting what it calls "total build" numbers for 270,000 Class 8 units in North America this year versus 279,000 in 2012. "It's all about economics 101 right now: everyone is waiting for [freight] demand to really pick up before buying new trucks," Coll said.
The question is; how much longer will we have to wait for that moment to arrive?


text:
Saint Cwenburgh of Wimborne
Sister of King Ina of Wessex in England; sister of Saint Cuthburgh of Wimborne. Benedictine nun. With Cuthburgh, she founded a monastery in Wimborne, Dorset, England, and served as abbess there. Many of her Wimborne sisters worked as missionaries to Germany.
- Book of Saints, by the Monks of Ramsgate
- Our Sunday Visitor's Encyclopedia of Saints


text:
MOSCOW, May 27 (RIA Novosti) – Russian President Vladimir Putin discussed the situation in Ukraine in a phone conversation with Italian Prime Minister Matteo Renzi on Tuesday, calling for an end to violence in the crisis-hit country, the Kremlin said Tuesday.
During the phone conversation, Putin expressed condolences to the Italian prime minister for the death of an Italian journalist in Ukraine, and called for an immediate halt of violence in southeastern Ukraine.
"The leaders of the two countries have exchanged opinions on the situation in Ukraine over the results of the presidential election that was held May 25," the Kremlin said in a statement.
The statement said that Putin had stressed the necessity to stop the punitive operation in southeastern Ukraine and to establish peaceful dialogue between Kiev and the regions.
Italian photographer Andrea Rocchelli and his interpreter Andrei Mironov were killed by mortar fire on the eve of Sunday's presidential elections near the eastern city of Slaviansk. According to media reports, a group of foreign reporters came under mortar fire in the village of Andreyevka, in the city outskirts. French photographer William Roguelon was injured in the same incident.
Billionaire businessmen Petro Poroshenko has been declared the provisional victor in the election with over 95 percent of ballots counted. He will take over the post from President Viktor Yanukovych, who fled the country during a series of violent protests which led to his unconstitutional overthrow on February 22.
Voting took place in a total of 189 constituencies of Ukraine amid a large-scale military operation launched by the new Kiev authorities to crack down on protesters refusing to recognize the legitimacy of the government. Twenty-one candidates ran in the race.
Moscow has said it is ready for dialogue with Poroshenko.


text:
Lower Neuse Riverkeeper Mitch Blake of Chocowinity has resigned the post and Lauren Wargo has been named acting Lower Neuse Riverkeeper.
Lower Neuse Riverkeeper Mitch Blake of Chocowinity has resigned the post and Lauren Wargo has been named acting Lower Neuse Riverkeeper.
Neuse Riverkeeper Foundation President Jim Starr said, �Mitch has been a valued member of the NRF staff for the past 18 months, and the Neuse Riverkeeper Foundation board and staff wish him well.�
For the past few months, Wargo has been the Neuse Riverkeeper Foundation�s watershed monitoring specialist, working out of the New Bern office and handling its Concentrated Animal Feeding Operation sampling program.
She has a BA in Environmental Science and Botany from Miami University and worked for several years as a legal assistant providing analysis of scientific data to support litigation.
Wargo has other experience including work in plant cataloging, invasive species analysis, public relations, special events coordination and outreach for museums and nature centers in the Cleveland, Ohio, area.
Blake officially resigned Aug. 16. Wargo�s appointment was effective Aug. 23.
In his resignation letter, Blake wrote that because of his family obligations, including supervising construction of his new home, it would be a disservice to the Neuse Riverkeeper Foundation to try to maintain the Riverkeeper position.
�I would like to thank you and the board for the privilege of working for the NRF and the experiences I had as Riverkeeper,� Blake wrote. �I look forward to seeing the NRF do great things for the future of the Neuse River.�
Wargo is on the job, working out of the Neuse Riverkeeper Foundation office in New Bern office at 2207 Trent Blvd., and can be reached at 637-7972 to report problems on the Neuse River and its tributaries.
She will be working with Upper Neuse Riverkeeper Matthew Starr, no relation to Jim Starr, based in Raleigh, who can be reached at 919-856-1180.
Neuse Riverkeeper Foundation�s mission is to improve water quality of the Neuse River and educate the public about water quality issues.
Sue Book can be reached at 252-635-5665 or email@example.com. Follow her on Twitter@SueJBook.


text:
Henry F. Kupfer papers, 1940-1953 | Morse Department of Special Collections
Extent: 0.5 Linear Feet
Subjects (links to similar collections)
Scope and Contents: This collection contains items related to the military service of Henry F. Kupfer, a Kansas State University alumnus of the class of 1940, including military service records (personnel records, medical examinations, certifications, memoranda, discharge documents, etc.) dating from 1940 to 1953, the February 28, 1944 issue of the 6th Air Force magazine Carribean Breeze, a leatherbound scrapbook/photo album dating from 1942 to 1944 (the binding is likely from South or Central America), and Kupfer's service diary, containing entries from 1936 to 1944 including recollections of travel, duty assignments, promotions, medical examinations, and social activities. (Note: the blank diary itself has a copyright date of 1941; entries from 1936-1940 were entered later, and briefly delineate Kupfer's time in the Kansas State University Reserve Officer Training Corps). Also included is a compact disc labelled "Henry Kupfer - Veterans History Project," which was not readable at the time this entry was written.


text:
UW-Oshkosh and UW-Whitewater fight for first place in the WIAC on Saturday (Oct. 20) in Whitewater. The defending national champion Warhawks (5-1/3-0 WIAC) rank fifth in the D3football.com poll, while the Titans (6-0/3-0 WIAC) are 10th.
UW-Whitewater has won four straight games against WIAC teams since dropping a 7-6 contest to Buffalo State (N.Y.) on Sept. 15. The past two weeks, the Warhawks notched victories of 35-0 over UW-River falls and 41-7 at UW-Stout.
This game pits the nation's top run defense against one of the country's best rushing offenses. UW-Whitewater leads the NCAA Division III by allowing just 29 yards per game. Meanwhile, UW-Oshkosh ranks ninth with 296 rushing yards per game. The Warhawks are also among the top-three nationally in total defense (212 yards), scoring defense (7.8 points) and turnover margin (+13).
Running back Desmin Ward paces the UW-Whitewater offense. Ward has 626 rushing yards and five touchdowns to rank second in the WIAC. The passing game goes through Lee Brekke, who owns 882 yards, eight touchdowns and four interceptions. Steve Morris is the team's top receiver with 23 catches and 247 yards.
The Warhawk defense intercepted 18 passes this year, while giving up three touchdowns through the air. Ryan Wenkman owns four picks, in addition to three by Andrew Kiester, Cole Klotz and Marcus McLin. Kyle Wismer owns a team-high 33 tackles, including seven for loss.
UW-Oshkosh has scored 34+ points six times during its eight-game win streak. The Titans rank 10th nationally in total offense (518 yards per game) and 12th in total defense (247 yards). The first half has belonged to UW-Oshkosh this year, as it outscored its opponents by a 135-26 margin.
Quarterback Nate Wara (Sr. • Oshkosh) guides the Titan offense with averages of 219 passing yards and 81 rushing yards. Cole Myhra (Jr. • Menomonee Falls) has been strong in the backfield, running for at least 83 yards in every contest. The receiving duo of Zach Kasuboski (So. • Wautoma) and Caleb Voss (Jr. • Van Dyne) gives UW-Oshkosh balance. Voss owns 493 yards on 25 catches, while Kasuboski has 285 yards on 27 grabs.
The Titan defense also excels at taking the ball away, recording seven interceptions and four fumble recoveries. Tim Filter (Sr. • New Berlin) leads the team with three interceptions, while Taylor Goodman (Sr. • South Wayne) has three forced fumbles. Goodman also owns 46 tackles, as Andrew Thompson (Sr. • Greendale) boasts 3.5 of UW-Oshkosh's league-leading 18 sacks.
Last season's contest between these squads went down to the final minute. The Titans led late in the third quarter before UW-Whitewater pulled out a 20-17 victory. The Warhawks own a 72-26-5 edge in the series dating back to 1897.


text:
This is a work of FICTION for ADULTS only. Do NOT read this if you are under 18 or if you are not an adult according to the laws of your State or Country. Do NOT read this if you are easily offended or if you are not interested in fantasies involving young boys. This file contains sexually EXPLICIT material.
The author does not condone any of the acts in this file. This story was not written to advocate sexual activity with minors. Agatha Christie wrote about murderers all her life. She was not a criminal.
Please support free speech and stop censorship.
You can send comments to firstname.lastname@example.com
Flames are deleted.
I've been experiencing problems with me email. If you did not get a response. Please write again!


text:
Hip dysplasia diagnosis (program ID: 227973)
University Hospital Würzburg
Maximilian RudertSpecialized in: orthopedics
The Department of Orthopedics König-Ludwig-Haus under the direction of Prof. Dr. med. Maximilian Rudert deals with the diagnosis and treatment of all diseases and injuries of the musculoskeletal system. The Department specializes in endoprosthetics, foot and ankle surgery, sports orthopedics and arthroscopic operations, shoulder and elbow surgery, pediatric orthopedics, spine orthopedics, tumor orthopedics, neuro-orthopedics, rheumatoid orthopedics and osteology.
The range of services in the field of orthopedics at the University Hospital of Würzburg covers all conservative and surgical techniques, while the Department is primarily oriented at surgical treatment. Within the framework of various focuses, there are treated congenital conditions, degenerative or inflammatory rheumatic diseases, injuries or injury sequelae, as well as soft tissue and bone tumors. The Section of Surgery with 5 operating rooms is equipped with the cutting-edge technology in order to perform operations. Non-surgical treatment includes reconstruction of disorders of the musculoskeletal system forms and functions with the use of bandages, physical therapy and therapeutic gymnastics, as well as pain therapy by drugs and local injections.
Endoprosthetics makes up an important focus of the clinical activity of the Department of Orthopedics at the University Hospital of Würzburg. The Department of Orthopedics König-Ludwig-Haus under the direction of Prof. Dr. med. Maximilian Rudert is the first in Bavaria and the third in Germany, which was certified as the Center for Endoprosthetics of maximum care. The voluntary quality control confirms an excellent quality of hip and knee replacement. There are annually implanted over 1000 artificial hip and knee joints.
The Department of Orthopedics annually treats over 4,000 inpatients and 20,000 outpatients. The Department employs about 330 persons and has 123 beds, which are located in four different sections. 5 operating rooms are used for over 4,000 surgeries a year.
The Department of Orthopedics König-Ludwig-Haus under the direction of Prof. Dr. med. Maximilian Rudert is recommended by the FOCUS list of top specialized orthopedic clinics in 2017.
The main treatment focuses of the Department of Orthopedics at the University Hospital of Würzburg include:
- Arthroscopy
- Endoprosthetics
- Foot and ankle surgery
- Pediatric orthopedics
- Neuro-orthopedics
- Osteology / osteoporosis
- Tumor orthopedics
- Rheumatic orthopedics
- Shoulder and elbow surgery
- Sports orthopedics and spine orthopedics
Program includes:
- Initial presentation in the clinic
- clinical history taking
- review of medical records
- physical examination
- X-ray of hip joint
- CT/MRI scan (on indication 650/1200 €)
- nursing services
- consultation of related specialists
- consultation of the chief physician and all leading experts
- development of individual treatment plan
You may also book
About hospital
Accommodation in hospital
- Program [Description]
Hip dysplasia diagnosis
- Hospital: University Hospital Würzburg
- Type:
- access_time Duration:
- date_range
There are 79 hip dysplasia diagnostic hospitals on Booking Health websiteShow all clinics


text:
Snacks to Sustain: Menu for a Late-Night Study Session with Friends
The Scene
You, your study buddies, a night of open books and scratching pens before you. Some carefully chosen snacks to sustain your study session.
Make It Happen
Unless you're inviting the whole class over to study, you probably won't need all of these snacks. I'd pick one or two sweet snacks and one or two savory ones. They can all be either made ahead or made easily in a few minutes while you're taking a break. The cheesy black-eyed pea dip is also served warm and a good choice if you'd like something with a little more substance. Boba tea is a snack and a beverage in all in one, and chai is good for both comfort and caffeine.
What are your favorite study snacks?
(Images: see linked posts)
Published: Jan 31, 2013


text:
Hanover's Three-Point Barrage Sinks Wabashby Brent Harris • November 21, 2006 Share:
If you knew going into Tuesday night's basketball between Wabash and Hanover that Andrew Zimmer and Gary Simkus would record their first double-doubles of the season, you would think the Little Giants would take an easy victory.
Instead it was the long-range shooting of Hanover's Clint Parker and 23 turnovers by the Little Giants that led to a 90-85 loss for Wabash at Chadwick Court.
Click here to view photos from Tuesday night's game.
Zimmer grabbed a career-best 17 rebounds and scored 20 points, while Simkus had 10 boards and 14 points. Freshman Chase Haltom led the Little Giants with a career-best 21 points.
But it couldn't overcome Parker's shooting from the field. The junior was 11-for-23 from the field, but all 11 baskets came from behind the three-point arc. Parker was 11-of-21 from three-point range and 5-for-5 from the free throw line.
Wabash not only struggled keeping Parker from getting good looks at the basket, but also found the going tough against Hanover's full court press. The Little Giants' 23 turnovers led to 28 points, while Wabash would manage just four points on four Panther mistakes.
The Little Giants owned an eight-point lead five minutes into the contest, but saw the advantage cut to three at the halftime break. Hanover continued to bomb away from long distance, connecting on a total of 16 three's out of 43 attempts. The Panthers were 29-of-77 overall for the game.
Wabash shot well, pounding the ball inside again and again for 45 points in the paint. The Little Giants were 30-of-56 from the field, led by Zimmer with a 7-for-10 effort.
Aaron Brock had 14 points and Brian Maloney added 11 to join Haltom, Simkus, and Zimmer in double-figure scoring. Marc O'Leary had 14 points and Jake Inman tossed in 12 for the Panthers.
Wabash (1-2) will attempt to regroup after the Thanksgiving break. The Little Giants travel to Greencastle, Indiana to play DePauw University next Tuesday at 7:30 p.m.
Photos - (top right) Andrew Zimmer recorded his first double-double of the season, scoring 20 points and grabbing a career-best 17 rebounds.
(bottom left) Freshman Aaron Brock had career-highs in points (14) and rebounds (7) in the Wabash loss.


text:
Hilarious: The Most Countriest Dog Owner From Alabama! "C'mon Joby Bring The Ball Back Over Here" (Sounding Like Cleveland From The Cleveland Show)
Dog smarter then he is?
Please click the "Report" button below if the video on this page is not working properly.
Comments will only be displayed by verified emails. No Spamming or Racism.


text:
UPDATE: Nominations are closed - now it's time to vote for the best VST plug-in synth in the world today at the bottom of the page!
There are now so many VST, AU and RTAS plug-in synthesizers on the market that it would take a lifetime to master them all, so at some point, you're going to have to pick a few and stick with them.
But which should that few be? In 2010, we put this very question to MusicRadar users, which eventually resulted in the compilation of our list of the 17 best VST plug-in synths in the world today.
Now it's time for the 2011 vote: does LennarDigital's Sylenth1 still deserve its number 1 ranking, or should something else usurp it?
Only you can answer this question; all 17 of last year's favourites will go forward to the voting stage again, but if you think that any other synths deserve to be nominated - be they new releases from the past year or old favourites that were overlooked last time - we want to hear from you.
A few guidelines: we'll leave free synths off this list, so only nominate those that you have to pay for. To narrow down the field a little more, we'll also exclude samplers, and we'll knock out dedicated drum machines, too.
Otherwise, it's game on: once all the nominations have been rounded up, we'll put them to the vote once again.


text:
States that have experienced technical problems running their own health care enrollment websites are getting some help from the Obama administration.
The administration quietly issued a health law fix Thursday to help those states. Several Democratic-led states, including Oregon, Maryland, Massachusetts and Hawaii, are still trying to solve website problems that have eclipsed those experienced earlier by the federal HealthCare.gov site, now largely repaired.
Although the new policy fix is available to any state, Republican governors basically defaulted to federal control of online sign-ups in their states. Those who stand to benefit the most are Democratic governors who plunged ahead and ran into problems. Some are facing sharp criticism at home, from both sides of the political aisle.
(Read more: Obamacare hits 4 million sign-ups as bar lowers)
"Today's news means that many more Oregonians will be able to access better coverage at a more affordable cost," said Oregon Democratic Gov. John Kitzhaber, whose state is near the bottom on enrollments.


text:
Hi. Thanks so much for all the good work on Bible Analyzer!
Bible Analyzer won't start. (Using the latest download from your page.) This happened before on an old system; it's happening again. Here are some details.
I've checked my new system (Bodhi Linux), and it installs the Python version necessary for Bible Analyzer to run. But Bible Analyzer fails. The message I get is Error: Dependency is not satisfiable: python-wxgtk2.8 (>= 22.214.171.124). According to my software repositories, the installed version 184.108.40.206. Should work fine, but it fails.
Perhaps your Linux person can figure this out. Thanks!


text:
Evening classes canceled Feb. 7, 2018. Learn more.
Home | Academics | Our Schools | School of Arts and Sciences | Arts and Sciences News and Features
More than 200 students, faculty, staff and community members packed into the George Rowland White Theater to hear political activist and best-selling author Barbara Ehrenreich, Ph.D., speak at the Fifth Annual "An Evening With…" Global Cultural Studies Public Speakers' Series.
Ehrenreich's presentation on Nov. 14 at Point Park focused on the topic of poverty and the class stereotypes that affect poor people. "I get really upset when I hear anyone speak disrespectfully about people in poverty. We tend to have a society that persecutes the poor," said Ehrenreich. "Poverty is simply a shortage of money caused by a lack of adequate pay in the work force."
In her presentation, Ehrenreich spoke about how as a journalist she went undercover to experience life in the minimum wage world as a waitress, hotel maid, house cleaner, nursing-home aide, and Wal-Mart salesperson. This became the inspiration for her book Nickel and Dimed: On (Not) Getting By in America. Through these experiences, Ehrenreich learned that "every job takes intelligence, skill and concentration and deserves our complete respect."
"Dr. Ehrenreich was bold and broke the traditional rules of journalism by actually living the life of a minimum wage worker. After hearing about her experiences, I respect her even more and believe in what she has to say," remarked Kelly Cline, a senior double majoring in global cultural studies and photojournalism.
Shaquela Myrick, a senior advertising and public relations major, admires Ehrenreich for her "great courage and determination." "I'm happy and proud that Point Park provides a platform for these types of discussions," said Myrick.
An advocate for health care, peace, women's rights, and economic justice, Ehrenreich is the author of 21 books, including best-sellers Nickel and Dimed: On (Not) Getting By in America (2001) and Bright-Sided: How Positive Thinking Is Undermining America (2010). She is also a frequent contributor to the New York Times, Harpers, The Progressive and Time magazine, and has appeared on Oprah, The Daily Show, The Colbert Report and The Joy Behar Show.
"I thought the event was a success. The composition of the audience proves that we performed a good public service and from the people who spoke to me — strangers — it was clear that the name of Point Park University is now also being associated with intellectual and social concerns," remarked Channa Newman, Ph.D., professor of French and cultural studies, director of the global cultural studies program, and coordinator of modern languages for the humanities. "Dr. Ehrenreich's impressions of Point Park were also positive," added Newman.
According to Ehrenreich, there are proactive things that can be done to combat poverty such as offering affordable housing, raising the minimum wage, making serious investments in college education and cutting executive compensation at the top.
"The first step toward making changes is to become informed. And that's what the global cultural studies major at Point Park is trying to do," said Cline.
"Patricia Sheridan's Breakfast With...Barbara Ehrenreich"Nov. 11-17: Cultural events around town
"Nickel and Dimed author Barbara Ehrenreich talks with CP, Activist to speak at Point Park University"
Directions to Campus
Faculty & Staff |
Current Students
Online | News | Calendar
| Directory | Library | Give
Site Map | Contact Us | Directions to Campus | Careers at Point Park | Privacy Policy & Legal Statement
© Copyright Point Park University | 201 Wood Street Pittsburgh, PA 15222-1984 | 412-391-4100


text:
Convergence is here to stay. It is the combination of forces from all sides—technological, economic and social—that are reinventing the human services environment. It is driving a clear and immediate need for new ways of working—from new operating models to creative partnerships centered on serving the whole person.
There is no doubt that the dynamics of convergence are a force to be reckoned with in human services—and there is potential for great peril or exciting promise here. So how can agencies ensure that they benefit from the rewards of convergence without the risks?
This was the focus of the fifth annual Human Services Summit, and this report offers the key highlights and important takeaways from this inspirational and foundational event for the human services community.
Leadership for a Networked World originally published this report.
Download the full report to explore the dynamics of convergence in detail


text:
Fullerton residents Stanley and Lila Pesner returned to their Avenida Del Norte home from a late Friday service to find a sea of broken glass and a set of heavy armoires crushing their bed.
Friday's magnitude-5.1 earthquake centered near La Habra splintered the elderly couple's home of 44 years, sending cracks through at least two walls and separating a portion of an exterior wall from the garage. Thirty-five place settings of china smashed to the floor, and glass covered the kitchen.
"It was lucky we were at services last night," Lila Pesner said Saturday afternoon. "We could have been hurt."
A collection of decorative elephants gathered around the world collapsed through a display case and a $1,500 piano's leg snapped, the couple said. All throughout their home damage from the La Habra earthquake could be found.
The earthquake shifted parts of their house, making it impossible to shut the gate to their fence. It slid their staircase an inch from its previous anchoring.
The couple's family came immediately to help out. Son Barry Pesner threw broken glasses, plates and other objects into a trash can Saturday.
"I'm just trying to get them a sense of normalcy by getting their kitchen back," he said. He said he didn't know if they would be able to live in the house once the structural damages were assessed.
"After all these years, it finally happen," Lila Pesner said.
Next door, Richard Nesbit was sitting in bed when the room started to shake. Furniture fell beside him. He attributed his lack of injuries to luck.
"I just happened to be sitting in the right spot to not get hit," he said.
Wall hangings lifted off their hooks and dropped to the floor, he said. All of the glass in his wet bar shattered.
"They all fell right on the bar and broke," he said.
The longtime Californian has lived through several earthquakes but never before experienced damage to his property, he said.
The two Fullerton homes were among six that officials said sustained enough damage to be deemed unsafe. Little indicators — a collapsed stone wall or fallen shingles — throughout the neighborhood showed signs of the earthquake's strength.
Across town, the Fullerton Fire Department declared 20 apartments uninhabitable on Associated Road.
Cracks cut across a northern building in the apartment complex, and tape blocked residents from using multiple sets of stairs.
"We're on the second story, so we felt it pretty hard," said resident Jeff Malloy. "Then we come out and we just see those cracks up there like right near our building."
While some of the complex was evacuated, other parts remain open.
"We're very concerned right now about the safety of this apartment complex," Malloy said.
Another resident in the complex, Jenny Kouyoumdjian, said she did not know people had to evacuate.
"I haven't heard anything," she said.
Kouyoumdjian had a light fixture fall in her kitchen. Her pet rabbit got cut on some glass broken during the earthquake, she said.
As a former Northridge resident, Kouyoumdjian said the La Habra earthquake is one of the worst she'd felt since.
"This one wasn't as bad, but it was probably the second-strongest I've felt," she said. "There was glass breaking all around us."
A 5-year-old at the time the 1994 Northridge quake, she said she still reacts strongly to tremors because of her memories.
"I just started screaming, I didn't even know what to do," she said.


text:
Everpure EV9607-56 Filter Replacement SGF-96-43 CTO by Swift Green Filters
Know Your Product
Everpure EV9607-56 Filter Replacement SGF-96-43 CTO by Swift Green Filters
The Swift Green Filters SGF-96-43 CTO commercial water filter is a compatible Everpure replacement providing fresh, clean, and great tasting drinking water. This high quality filter reduces: - chlorine taste and odor - sediment, dirt and rust - cartridge: 7TO. Our filters are made with activated carbon produced using a new technology that carbonizes dried coconut shells. Coconut carbon is superior to other sources of activated carbon. It has 50% more micro-pores for capturing contaminants. For more information please visit the Swift Green Filters Website.
From the Manufacturer :-
We offer a variety of filters that are compatible with all leading brands. Swift Green Filters are the Green alternative to the conventional filter, our products being environmentally conscious while cost effective. We aim to provide you with the cleanest and healthiest water filtration for your home and business by making sure the materials we use are to the highest quality standard.
Change filter frequency:
Depending upon your usage of water, For Best performance we recommend the replacement every 3- 6 months.
Our mission is to Save Health !! Great alternative to expensive refrigerator branded filters. Does not remove minerals which may be beneficial to health
American Made Quality
Made in the U.S.A using ONLY certified NSF/ ANSI lab tested raw material for its quality & performance. "100% Guarantee for Highest Performance in its class and Capacity in the Industry". Buy with confidence. Our Raw Material are BPA, Lead, Arsenic free
Eco friendly filter uses coconut shell carbon ( Renewable Resource), the earth's most powerful natural filter while keeping plastic water bottles out of our landfills water
100% satisfaction guarantee; Outstanding quality; Easy filter replacement; DIY, no tools required to replace this water filter. Replace every 3- 6 months for best performance.
Industry certificated to meet NSF / ANSI 42.This high quality filter reduces: - chlorine taste and odor - sediment, dirt and rust - cartridge: 7TO.
Compatible Replacement ForEV9607-56
We Also Recommend
Everpure 'EV9618-02 Filter Replacement SGF-96-05 VOC-L-Chlora-S-B by Swift Green Filters
Everpure 'EV9692-96 Filter Replacement SGF-96-07 VOC-L-Chlora-S by Swift Green Filters
Everpure EV9590-06 Filter Replacement SGF-96-17 SED by Swift Green Filters
Everpure EV9601-00, EV9600-00 Filter Replacement SGF-96-18 VOC by Swift Green Filters


text:
The go-go boots were long gone when Linda Rodin peaked as a model.
Last winter, at age 65 — decades after being scouted by photographers in Italy — she was cast in the pre-fall ad campaign for The Row, the high-end fashion house of Mary-Kate and Ashley Olsen. Two years earlier, J.Crew booked Rodin for its fall catalog. She posed for Vogue in August 2011 and more recently for the Dutch magazine Rika.
"I find it hysterically funny that 40 years later, when I'm wrinkled and a mess, they love me," Rodin said. "I'm 66 and still look cool in jeans, I guess."
During her four-decade hiatus from modeling, she moved back to her native New York from Italy, owned...


text:
Electromagnetic fields
- What are electromagnetic fields?
- Static and low-frequency fields
- What are static and low-frequency electric and magnetic fields?
- Direct and alternating voltage
- Application/occurrence
- Effects of static and low-frequency fields
- Protection
- Reports & Evaluations
- Radiation protection relating to the expansion of the national grid
- Basics transfer of electrical power
- What are high-voltage lines?
- Electric and magnetic fields
- Field strain due to high-voltage lines
- High-voltage direct current transmission
- Effects
- Protection
- Basics transfer of electrical power
- High-frequency fields
- What are high-frequency fields?
- Applications high-frequency fields
- Effects
- Protection
- Radiation protection in mobile communication
- What is mobile communication?
- Effects
- Protection
- Reports and evaluations
Optical radiation
- What is optical radiation?
- UV radiation
- What is UV radiation?
- Sun but safe!
- Sunbeds
- Effects of UV radiation
- Protection against UV radiation
- UV index
- Infrared radiation
- Laser
Ionising radiation
- What is ionising radiation?
- Radioactivity in the environment
- Where does radioactivity occur in the environment?
- What is the level of natural radiation exposure in Germany?
- Air, soil and water
- Radon
- Foodstuffs
- Building materials
- Relics
- Industrial residues (NORM)
- BfS laboratories
- Applications in medicine
- Diagnostics
- Radiotherapy
- Radiation protection in medicine: international activities
- Applications in daily life and in technology
- Radioactive radiation sources in Germany
- Register high-level radioactive radiation sources
- Type approval procedure
- Cabin luggage security checks
- Radioactive materials in watches
- Ionisation smoke detectors (ISM)
- Effects
- What are the effects of radiation?
- Effects of selected radioactive materials
- Consequences of a radiation accident
- Cancer and leukaemia
- Genetic radiation effects
- Individual radiosensitivity
- Epidemiology of radiation-induced diseases
- Ionising radiation: positive effects?
- Risk estimation and assessment
- Radiation protection
- Basic information
- Occupational radiation protection
- Nuclear accident management
- What is an emergency?
- What happens in an emergency?
- Federal and state tasks
- In the event of an emergency
- Measuring networks
- Exercises for emergency situations
- Defence against nuclear hazards
- Service offers
- Radon measurements
- Incorporation monitoring
- Biological dosimetry
- ProZES
Media centre
Media centre
- Multimedia
- Brochures
- Reports
- Online library
The BfS
The BfS
- About us
- Science and research
- Research concept
- Scientific collaborations
- EU research framework programme
- BfS research programme
- Third-party funded research
- Departmental research
- Selected research projects
- Selected research results
- Professional opinions
- Science Council
- Laws and regulations
- BfS Topics in the Bundestag
- Links
What are high-voltage lines?
The electricity supply at home has a voltage of 230 volts (230 V). However, much higher voltages are used to deliver electricity to homes. Overhead lines carry up to 380.000 volts (380 kV) to transport electricity from power stations to towns and urban centres.
High voltages are more suitable than low voltages for the transmission of electrical energy because loss of energy due to conductor resistance is less with high voltages. However, the voltage cannot be increased indefinitely. Therefore, the voltage on a wire is chosen according to the distance to be covered for transmission and to the power needed by the recipient.
|Example / application
|Up to 1.000 V
supply to residential and commercial users
|10 kV, 20 kV, 30 kV;
local/regional distribution grids, supply to villages and industry
(limit is not uniformly defined)
|110 kV;
supply to relatively small power plants, regional transport grids, supply to towns and large-scale industry
|Extra high voltage
(limit is not uniformly defined)
|220 kV and 380 kV;
supply to large power plants, wide-area transmission grids, power trading
Direct and alternating current
When power grids were first developed in the early 20th century, alternating current was technically required to operate high-voltage grids. In contrast to direct current, alternating current constantly changes flow direction, in Western Europe 100 times per second. This equals a frequency of 50 Hertz (50 Hz).
Today it is possible to operate high-voltage grids using direct current. This helps avoid loss of energy, caused by the changes of flow direction in the case of alternating current. Therefore, the high voltage direct current (HVDC) transmission is an alternative to ac-technology. Up to now HVDC is mainly applied to transmit electricity via sea cable in West Europe.
Overhead lines and underground cables
Overhead lines and underground cables are used for overland transmission of electrical energy.
So-called ropes are used as electric conductors in the case of overhead lines. Since ropes – other than cables – are not surrounded by an insulating layer, they are separately attached to masts out of the reach of people. High and extra high voltage lines are mostly overhead lines in Germany. However, low-voltage lines to supply residential users are also designed as overhead lines with roof stands, particularly outside of large cities.
Underground cables have one or several conductors, which are individually insulated to prevent them from coming into contact with each other. As a result, the conductors can be laid at a much closer distance to each other than in the case of overhead lines. Underground lines are mainly used in the low-voltage range, i.e. to supply residential and commercial users. Extra high voltage lines can be installed as underground cables, too.
Gas insulated transmission lines are also being discussed which have, however, only been used over very short distances in Germany up to now. They are comparable to a high voltage cable. Gas insulated transmission lines are made up of an aluminium conductor laid within an aluminium tube. For insulation, the tube is filled with a gas.
Typical overhead lines
The voltage applied for an overhead transmission line is not obvious at a glance. However, the masts give some clues:
- high- and extra high voltage lines are usually mounted to high steel lattice masts,
- smaller wood, concrete or tubular steel masts are used for low- and medium voltage lines.
Taking a closer look at the conductor ropes can give an idea of the voltage level:
Extra high voltage lines:
In the case of 220 and 380 kV - lines, respectively, the conductor rope often consists of two, or three to four, single ropes which are parallel and close to each other (conductor bundles). Spreaders of a length of a few centimetres are mounted between the single ropes at regular distances of a few metres as can be seen in the above picture showing the 380 kV overhead line.
More information
The Video "Stromleitungen und Strahlenschutz" (in German only) answers many questions related to voltage lines and radiation protection.
State of 2018.09.28


text:
|Job Title:
|Traboulay Agency
|Job Category:
|Sales/Retail - Brampton , ON, Canada Sales/Retail - Brampton , ON, Canada
|Job Type:
|New Graduate
|Job Title:
|Sales/Retail - Brampton , ON, Canada
|Job Description:
We just recently opened a new office in Brampton, On! We are looking for motivated, passionate candidates to help expand our operation in the Brampton and Mississauga area. There are a couple different positions we are currently hiring for with respect to customer service, sales, and entry level management. You will be responsible for acting as a liaison between customers and companies, assisting with complaints, orders, errors, account questions, billing, cancelations, and other queries. PRIMARY RESPONSIBILITIES *** • Cancel or upgrade accounts. • Advise on company information. • Take payment information and other pertinent information such as addresses and phone numbers. • Act as the company gatekeeper. • Suggest solutions. • Sell products and services. • Work with customer service manager to ensure proper customer service is being delivered. • Handle changes in policies or renewals. • Compile reports on overall customer satisfaction. Strong customer service skills and work ethic required, as well as access to a vehicle. No formal education needed although sales, customer service and management experience are an asset. EXCELLENT PAY, BENEFITS & FLEXIBLE SHIFTS, FULL TRAINING Room for growth and progression into upper management is very achievable. ***