Behind Closed Doors

Written by Johanna Rothman and Esther Derby
Published by The Pragmatic Bookshelf

Management is a goal many people set for themselves.  For some it’s a skill set that comes naturally.  For other’s though it takes a lot of work.  Regardless of which camp you happen to sit in, this book will help you become a more approachable and proficient people’s person (otherwise known as a manager).

I’ve read a couple management books over the years.  And most come in a very dry and boring setting.  They approach teaching management as if it’s a science.  It’s not, and it shouldn’t be written about in such a way.  Johanna Rothman and Esther Derby have hit the nail on the head with Behind Closed Doors.  The book takes a very relaxed tone and has a story that underlines the first three quarters of the book (the remaining quarter is an indepth take on the various concepts and practices discussed through the book).  As you’re reading about Sam, the company’s new manager, you’re taken away from the story and given critical information about various management practices and techniques.  It’s the perfect integration of fiction and nonfiction.  The story acts as a role play of the concepts being discussed.  Yet it’s done in a way engaging enough that you want to read on, even if it’s only to see what happens next.

Read more

I am hosting illegal content, I should host it offshore!

I see this line of crap all of the time. People looking for offshore hosting and almost always for the wrong reasons. It’s the intention of this little… essay, I guess we’ll call it, to debunk many of the myths and fallacies regarding offshore hosting. It’s my hope that people will come to understand that what they’re doing is largely ineffective. And by coming to understand that, they will be able to make a better informed decision.

If, after reading this, you decide you still want to go with offshore hosting then so be it. I cannot, and will not, go out of my way to stop that from happening. But at least make sure it’s an educated decision. Ignorance may be bliss, but only until you receive a hard awakening. Hopefully I can stop that from happening to you.

Read more

Today’s random terminology is: atomicity.  This term is used specifically within the database design realm.  Other ways of referring to atomicity are: atomic (adjective) and atomic transaction (noun).

An atomic transaction is an update transaction within a database that will either complete fully or have no effect at all.  Atomicity is the guarantee that all update processes within a database will follow that rule: complete or nothing.  It’s similar to the sayings: all or nothing and go big or go home.  An atomic transaction is either done correctly or it doesn’t occur.

This may be a little awkward to picture without an example.  Let’s say we’re in charge of designing and administering the MLB’s databases.  When it comes to individual players there are a wide variety of table but specifically we’re looking at the salary table and the roster table.  Within the salary table is a listing of every player ID and the salary they’re earning.  Within the roster table is a listing of every player ID with the team ID they belong to.  Simple enough.

What happens when a player changes teams?  Well you’d update the roster table.  But a team change could come with a salary change (99 out of a 100 times it will).  We don’t want to update the player’s team but keep their old salary.  Both actions must occur or the update process has failed and we need to reexamine it.  As such, an atomic transaction in this case would be one where both tables are updated successfully.  For this situation to follow the rules of atomicity, that transaction must fail if one table cannot be updated.

I’ll go into this more within another article, but atomicity is actually one of four properties that must be present to ensure reliability within a database system.  These properties are known as ACID (atomicity, consistency, isolation and durability).

SQL and Relational Theory by C.J. Date

SQL and Relational Theory

Written by C.J. Date – Published by O’Reilly Media

Christopher J. Date (C.J.) has been involved in SQL and the relational model since its inception.  His expertise on SQL and relational databases is made excruciatingly clear throughout this book.  This book might as well be considered a must read by anybody with a firm interest in the theory behind relational databases and how to apply it in real world situations through SQL.

This book is not your normal introduction into SQL.  It’s not specific to any one relational database management system.  In fact, you won’t find the word “MySQL” or “PostgreSQL” anywhere throughout this book.  Rather, this is a fast-paced and very in-depth overview of the SQL language and why/how it works.  If you’re looking for a quick and easy introduction into MySQL then look elsewhere.  If you already have a firm understanding of SQL and want to improve upon it: this book may be for you.  If you’re interested in learning more about the relational model and how to better write SQL queries against it: this book is for you.

Read more

(Note: The following introduction to PDO was written by me a number of years ago.  The information is still however pertinent, hence putting it here.)

PDO: A Better Way to Work With Data

PDO (PHP Data Objects) is a powerful, yet lightweight, abstraction layer within PHP that allows you to work with a database without caring what system it actually happens to be. In short, through PDO you can write database-driven code that is entirely independent of the underlying server specifics. Through PDO you can work with MySQL, SQLite, PostgreSQL, MS SQL, Oracle, and a few others without having to write separate code for each software. In fact, the only line of software-specific code is the initial initialization of the PDO object. Sounds pretty damn useful already doesn’t it?The obvious advantage behind this is portability. Write once, use anywhere- a very useful concept, don’t you agree? This is achieved through one very powerful keyword in programming: abstraction. That is: the act of writing code at the most appropriate level possible. Think of programming layers as a pyramid. The further towards the base of the pyramid you go the more hard-written and specific the code is. Each layer above it gets a little more generic and forgiving. As such it gets more portable and maintainable. I cannot stress to programmers enough just how vital abstracting your code is.Anyways, enough on the abstraction lecture. How about we take a look at some PDO!

Read more