edge of sanity

I've been contemplating moving my server to a new provider for a very long time. It's a lot of work and I wasn't sure I wanted to deal with it. After a week of prep work, I finally made the move to Linode.com. There are a number of reasons for this move.

After spending a bit of time becoming familiar with the Mojolicious way of doing things, I think I finally have a grasp of how to handle it. It's a bit less framework than something like Catalyst, but you don't always need a Nuclear Weapon to handle things like a blog.

I think this will be a much more productive system for blogging as I can easily control publish date years, months, weeks, or days into the future. I also have all the flexibility of Markdown and can use any text editor to blog with.

More good things to come ..

I started out looking for a decent Perl blogging platform. While there are several very complete and interesting contenders, I ultimately rolled my own. I mean, can you really be a professional Perl Programmer without having reinvented a bloggin platform?

The main objectives for this software was a file system-based blogging platform that utilized Markdown to generate pretty HTML pages. There were some customizations done to the Markdown syntax to allow for application meta-data, tagging, and things like this "read more" break that you're about to experience ...

I married a Statistician, so this article sums the lectures I receive on a daily basis. Risk Management is statistical analysis, and I'm not sure how many folks in IT Security have Graduate level Stat exposure. So, the understanding of our statistical shortcomings is key. You need to read that entire article, twice. This statement struck me, as I've noticed a scary trend in IT Security:

"People who know a little bit of statistics - enough to use statistical techniques, not enough to understand why or how they work - often end up horribly misusing them. Statistical tests are complicated mathematical techniques, and to work, they tend to make numerous assumptions. The problem is that if those assumptions are not valid, most statistical tests do not cleanly fail and produce obviously false results."

As we outsource more security, and buy more products, we must be careful, as this statement is also true:

"People who know a little bit of IT Security - enough to use an IDS or SIEM, not enough to understand why or how they work - often end up horribly misusing them. Security tools use complicated technical techniques, and to work, they tend to make numerous assumptions. The problem is that if those assumptions are not valid, most security tools do not cleanly fail and produce obviously false results."

My wife's constant guidance in Statistics has been invaluable to my evaluations of IT Security Policy and Implementation. When I came across this article thanks to @alexhutton, I had to share it!

For several years I've managed to bend cfEngine 2.0's architecture to my will. Being an experienced Perl programmer, I was able to abuse the configuration language snytax in order to accomplish a number of strange things including Copy Back and automated management of OSSEC-HIDS. However, there comes a point when the managing the cfengine configs becomes a burdensome and incredibly unmanageable. I mean, sure, I know what they do. How will any of my co-workers understand them? After several colleagues recommending Puppet, I hesitantly began the slow, brain fscking process of:

1. Understanding exactly what I had accomplished with cfEngine.
2. Understanding Ruby (ugh, I'm so thankful for Perl)
3. Understanding how to express my cfengine feelings in a way Puppet will understand without hurting it's feelings
4. ...
5. Profit.

I love cfengine. There are tons of resources out there for managing all kinds of common and uncommon system administration tasks. Rather than regurgitate all that information I wanted to share how I worked around what has been noted as a short coming of cfengine, clients copying information back to the master server.

As a programmer, I've had the concept of "don't ever trust your users" beaten into my head. For programmers, this concept is incredibly important. Users almost always exceed your expectations for creativity with your new application. By planning for unexpected input, and properly cleaning all variables you can theoretically account for abuses of your system by malicious users and provide a graceful failure for users attempting to enter in bogus data.

This concept is key to programming. What I find astounding, is a large majority of corporations are adopting this practice for all IT related issues, and it's even saturating into HR and other areas of employment. Working as a Security Administrator, I'm surprised that most employers have decided to not trust their employees. If you can't trust them, then why would you hire them?

We've all found useful information on the web. Occassionally, its even necessary to retrieve that information in an automated fashion. It could be just for your own amusement, possibly a new web service that hasn't yet published an API, or even a critical business partner who only exposes a web based interface to you.

Of course, screen scraping web pages is not the optimal solution to any problem, and I highly advise you to look into APIs or formal web services that will provide a more consistent and intentional programming interface. Potential problems could arise for a number of reasons.

"Regular Expression" is a fancy way to say "pattern matcher." Humans can match patterns with relative ease. A machine has a bit more difficulty deciphering patterns, especially in text. As computing became more powerful, the methods for matching text grew into more flexible dialects.

Regular expressions can be one of the toughest concepts to grasp and use effectively in any programming language. Perl is no exception as its regular expressions engine is perhaps the most advanced regex engine in existence. Its power and flexibility also serve to confuse and intimidate many new comers. It is important to understand the Regular Expression engine as its often the cause of serious bottlenecks in programs of all shapes and sizes.