In virtually all the applications and operations I write, I try to incorporate some level of logging so that my code can be adequately supported, particularly in Production environments. Some time ago, I wrote about how I generally log in my Python applications. Well, lately, I’ve switched from that approach to using Loguru and I must say I’m rather satisfied with its ease of use. Here’s a quick example I put together recently of the package:
Step 1: Do your standard imports
As I explained in other postson logging, I like adding a “run id” to each log line so that I can easily group lines together belonging to a single instance of my application, so I import the uuid package to help in that regard:
import os
import sys
import uuid
from loguru import logger
Step 2: Setup/customize my logging context
In one line, I can customize how each log line is written and set logging behavior like rolling the file when it hits 10 Mb in size:
def main(argv):
logger_ctx.info('Starting run of the loguru_example.py script')
# do some stuff
logger_ctx.info('Completing run of the loguru_example.py script')
if __name__ == '__main__':
main(sys.argv[1:])
And now you have a nice and easy log for your application:
Pretty darn simple! So now there’s no excuse: start logging today!
As far as I can tell, there are no logging APIs built into the PowerShell framework. So, when I have to write a code solution in PowerShell, I just add this snippet to meet some of my basic logging needs.
Set up some helper variables
I need to set the name and location of my log file. In addition, I like to add a “run id” to my logs so that I can easily group all the log entries associated with a given execution together for analysis or performance reporting:
Write-Log -logMsg "Starting up some script"
# do some work here
Sleep 2
Write-Log -logMsg "Finishing some script"
This produces a simple log like below. You can see my “run id” in the second column that helps me group log lines together by unique executions:
Sure, there are no log levels, no file rotations, no easy way to change the format…but in lieu of a built in API, this does the trick. One way it could be improved would be to stick this work into a module that I could simply import from script-to-script instead of copy/pasting this code around.
I’m not a big fan of wordclouds, but management seems to like them. Recently, I was working on a wordcloud of domains and generated some unexpected results. For demonstration purposes, I grabbed the domains of stories Firefox Pocket recommended to me and shoved them into a dataframe:
Then, I took a list of the domains and preprocessed them in the conventional way you do for the package: you join them together likes words of text with spaces in between:
text = ' '.join(df_domains.domain.tolist())
Finally, I loaded those words into a wordcloud object:
Excellent…except…where are the top-level domains? All the .coms, .nets, etc? By Jove, they’re not there! If you check out the frequency map the wordcloud created, you can start to get a clue about what happened:
The “generate” function removed all the .coms, .nets, and so on when it built the frequency map. A little more digging and we can see that the default regular expression is the problem: “\w[\w’]+”. It’s looking for words (and even apostrophes), but stopping with punctuation marks like periods. Now, you can futz around with providing your own regular expression that will include the full domain–I tried that–but regular expressions are hard and there’s actually a better way: the pandas value_counts function. The value_counts function will let you generate your own frequency map that you can provide to the wordcloud package directly. First, let’s just take a look at what value_counts produces. We’ll pipe the results to a dictionary so that the data is in a form the wordcloud package needs:
Recent Comments