Customer satisfaction is increasingly being linked to revenue growth for field services companies, with a recent Aberdeen report finding that organizations that achieved a 90% rating in customer satisfaction also enjoyed a 6.1% growth in their service revenues and a 3.7% growth in overall revenue. In light of the link between delighting the customer and the benefits a company can expect in return, the industry is looking to technology for disruption in customer service practices. (more…)
As python programmers we are sometimes faced with using an API that is, well, unpythonic.
Unpythonic? Pythonic? Huh? Have you ever tried running this:
python -m this
Maybe you’re using a C library via ctypes, or you have inherited a collection of functions. Regardless, you find yourself wishing you can use the API in a more idiomatic manner.
Sidebar: this post is not really about redis, but if you don’t know about it or haven’t given serious thought to using it as a datastore, run right over to http://redis.io/ and read up on this amazing in-memory, key-value store. If you’re familiar with memcached, then you’ll have a general idea of redis, but redis goes well beyond simple key-value pair storage. It also has functionality for storing lists, sets, sorted sets and hashes. Redis is often described as an in-memory data structure server.
In using redis-py, you acquire an instance to a monolithic object that manages a connection pool as well as the underlying redis protocol, offering a method for every redis command. While being feature complete, the object is a bit unwieldy, imho. Typical usage might look like this:
>>> import redis >>> >>> conn = redis.StrictRedis() >>> conn.set('foo', 'bar') >>> print conn.get('foo') bar >>> for c in 'this is a test': ... conn.sadd('myset', c) >>> print conn.smembers('myset') set(['a', ' ', 'e', 'i', 'h', 's', 't'])
Every command for every data structure is attached to an instance of
StrictRedis. If you look at the redis command set you will see there are some commands that apply to all data structures, while others apply to one data structure or another. For example, commands like
ttl can be used against any key in the datastore, while commands
incr, can only be applied to strings, and
hset can only be applied to hashes.
A picture begins to form for the potential for an abstract base class,
Key, with concrete subclasses
We will explore how to create a more pythonic interface for redis, building off the powerful redis-py implementation, using minimal code by using advanced python attribute access and delegation.
The above diagram shows two ways to place a grid on an HTML page. The
<TABLE> version on the left is the old school way of managing layout. The web was positively littered with such code before widespread use of CSS (and browser manufacturer adoption of standards), which freed designers from use of tables or framesets for managing layout. The
<DIV> version on the right is a sample of modern accepted practice, specifically in this example, using Bootstrap 3 styling.
You will find no one suggesting using tables for HTML layout (except when it comes to formatting HTML email. It’s ugly out there) today. Many a rant exists on the web exhorting all to separate presentation from structure, yet aren’t the two examples shockingly similar? Can the
<DIV> version be that much better, when it looks like a one-for-one mapping of one element to another?
To answer the questions asked in the image, yes, the HTML on the left is bad layout and the sample on the right is OK. The reasons behind the answers come with an understanding of semantic HTML.
Alright, maybe your grandmother doesn’t need tips for using ssh. In fact, she probably doesn’t even know ssh is a secure shell for accessing a remote host. Go figure.
But I know when I reach the age of grandparenthood and I begin contemplating shuffling off this mortal coil, I will still be using ssh and exploiting its power. (Just you wait: Senior Citizen Geeks, hacking for the pleasure of it…we’re coming sooner than you think.)
As software engineers, particularly those of us who work remotely, we are very dependent on ssh. We use it for remote login. We use it to run remote commands. We use it as a transport for secure software repository access (e.g., git over ssh). The savvy among us install public keys to do this without passwords. But did you know:
- You can proxy your ssh connection from one host (say, a gateway to a remote site) to another (i.e., an internal host at the remote site)?
- Forward arbitrary ports from your computer to the remote host? For example, you are developing a database application and want to test your local development branch against the schema running on the remote server.
- You can use ssh as a SOCKS server, using your remote connection as your browser’s proxy server?
- You can use it to subvert firewalls that block that port you need, including the ssh port, 22?
- You can collect options into a configuration file to run all the above simultaneously without hassle?
In my experience, ssh is one of the most underutilized tools by remote workers. It is my sincere hope that this brief introduction will whet your appetite.