"Are you implying that a scalable Data Warehouse solution could be implemented using Python and serialised files?"

Not "implying". I'm trying to state it as clearly as I can. A scalable data warehouse solution involves a lot of flat file processing.

ETL, for example, is mostly a flat-file pipeline. It …

We process a fair amount of externally-prepared datasets. 40,000 rows of econometric data that we purchased from a third-party. Mostly, the data is in a usable format: .CSV or .XSLX.

Once in a while, we get CSV with |. A few times, we got fixed-format COBOL-style records.

Recently, we got …

Check out this question on Stack Overflow: "Python: replace a string by a float in txt file".

The question is confusing, but it appears to be a longish and confused description of simple formatting or template substitution. It's hard to be sure, but it sounds like one of Those Things …

Someone sent me this: "“Building Skills in Python” – Steven F. Lott".

I had a vague idea that this book would get some traction. This response was surprising. I guess I should get to work on the upgrades.

And focus on the "no-nonsense" comment.

During chapter technical reviews, the question of technical depth has come up time and again. Essentially, in every single chapter. In the older Building Skills in Python book, there are a number of topics that feel "digressive" to the reviewer and editor. Too much depth.

However, there are a number …

Just started learning about "Hackerspace". Without really knowing what I was doing, I fell into the 757 Labs Hackerspace. The 757 Python Users' Group, specifically. What a great idea. Bright people. Interested in the same area of technology. It's like hanging around with sailors at a marina.

Tonight (May 25th). Red Dog. Colley Ave. Ghent. I'll be wearing my Stack Overflow shirt. I'll be there about 7. I know that at least one other person won't be there until 8.

The Meetup link.

I like this meetup idea a lot. Probably because the WFH life-style is a …

http://www.meetup.com/757-Python-Users-Group/

I'm looking forward to meeting other Python developers in Hampton Roads.

Tonight. 7:00 PM. See you there.

A single poorly-made decision can have profound ripple-effects. Once your stuck with it, you make accommodations, hacks and work-arounds. Eventually, things work, but the result is less than ideal.

Changing tack requires sometimes pervasive rework to the application. How can we reduce the risks and improve the value created?

After reverse engineering procedural code in C, VB or even Python, I'm finding that procedural programming inevitably leads to bad, bad code-rot.

Consider some of the common design patterns.

Strategy. Confronted with alternative strategy choices, a purely procedural code solution is either

• If-statements everywhere the strategy is involved.
• Block comments …