Book Review: Pro Drupal Development


BookPHPReviews

Book Site | Sample Chapter: The Theme System | Table of Contents

Many of you are aware of my current total infatuation with Ruby, and that I’ve used PHP for about 6 years and at one point decided I hated PHP…until, I needed it for a quick one-off page and then realized that PHP had its place. Then again, I was totally frustrated with Ruby when making my moms bakery site and then turned to Drupal and Gallery (another fine PHP project), which saved my bacon and I got a website and photo gallery up in a weekend. So, PHP and I have had our moments but I’m not abandoning it!

Drupal powers some big sites, its not just for joe smoe’s blog. This is an interesting page about Is Drupal Right For You? and if you are wondering if its something that would even work for you.

I was excited to get my hands on a review copy of Pro Drupal Development. Its no secret that coders hate documentation and Drupal has one of the most complete online documentation I’ve seen for an Open Source project, but its almost too hard to find what you need amongst so much. The Pro Drupal Book is a godsend for the drupal programmer, new and experienced alike. I wish it was written a year ago!

The book starts off with a quick overview of how Drupal is structured and defines terms such as hooks, node and blocks in just 10 pages. Chapter 2 is a A step-by-step tutorial with making a module. That is a great idea to start off quickly writing code. It get the reader involved and hands on. I really tire of books that have to start off with the history of the internet, html and how things have evolved. Get to the code dangit!! Kudos to the Authors for that! Chapter 3 gets into module specific settings, like how to get your module to show up on the admin page and storing user settings that your module needs.

After you’ve had some experience with the code then the book goes into details on the specific parts of Drupal:

  • Menu System
  • Databases
  • Users
  • Nodes
  • Themes
  • Blocks
  • Form API
  • Filter System
  • Searching and Indexing
  • Files
  • Taxonomy
  • Caching
  • Sessions
  • JQuery
  • Localization
  • Using XML-RPC

Drupal is a pretty amazing framework, when I read the code I say “why didn’t I think of that?” … the module and hook system is genius.

Then some more general topics:

  • Writing Secure code
  • Development Best Practices
  • Optimizing Drupal
  • Installation Profiles

One of the chapters I skipped ahead to read was The Form API. In my years of PHP I’ve often tried to come up with a framework for doing forms and I wanted to see how they did it. This chapter follows a tutorial style as well. The Form API allows you to define fields, their label, their value, description. Some frameworks take the template approach, where you hammer out your HTML. Some are more configuration based like Drupal making a multi-dim array with keys and values. I can see advantages to both. There is a hook function for validation which allows you to write your validation checks.

PHP gets a bad wrap for security, partly because its pretty easy to learn PHP and newbies don’t always realize what they are doing. There is a chapter devoted to security and includes even some things I didn’t know about — encoding mail headers. The Form API is very secure,  one thing it does is check values that come from dropdowns were actually in the options and it wasn’t something that the hacker made up.

Developer Best Practices are great for the new developer, it talks about using cvs, tags, branches. It talks about how to create and apply patches (hint – you can contribute back to drupal). That is awesome. Alot of open source projects are like “HELP us, submit patches!” and the new user is left with uhhhhhh..how?

Caching is another interesting chapter. You will learn  how caching works and how Drupal Core uses it. There is a Cache API that has methods for module creators to make their modules faster.

JQuery … I am not sure if I like it or not, but its part of Drupal 5! I skipped ahead to this chapter to see what its all about. There is a javascript hook built into Drupal making it easy to add, thats pretty cool.

One thing I found lacking in the book is anything about Testing. There are few pages on debugging and some modules to help with testing, but I would like to see more. At least some talk about selenium, which is great for a site made with any framework/cms.

Over all, Thanks APress for another great book!

Let’s All Evolve Past This: The Barriers Women Face in Tech Communities


BookCherryPyEventsIntroductionsReviewsSoftwareThoughts

Topics of this Article:

Introduction

This subject has been on the minds of many tech women for years. The issue is discussed regularly, almost cyclically at times, as we spin our collective wheels to try to find causes and solutions. I was reluctant to write about it, since I find the subject matter daunting, and the problem almost insurmountable at times. But three different sources approached me simultaneously, asking for this article. This article feels as if it is manifesting through me rather than from me, as a collective opinion and observation from the many tech women with whom I’ve worked and spoken. So many factors are in play when discussing this issue that I can only hope to address many of them without writing a tome.

My tendencies are to pick up on patterns, in human interaction, in data, in almost everything. I am a computer science/math major, and my brain loves to seek out the unobvious patterns in whatever I am observing. One of my favorite pastimes is to figure out broken elevator algorithms: what event causes the doors to close too quickly, how are the cars distributed amongst the people requesting the elevators, etc. One of the not-so-favorite puzzles my brain likes to do is to pick up on patterns of human behavior from both men and women which affect how tech women are treated both on and off the job. This article is all about the patterns I and other women have found in human interaction, office and online environments, which make them less conducive to tech women participation.

The less obvious

I won’t be addressing the more obvious problems affecting women in tech environments such as the pay scale gap between women and men, the blatantly inappropriate sexism and personal harassment that has taken place, and persists. My reasons are because I feel these issues have been properly and effectively addressed by other women in tech (they’re not resolved by any means, but at least public awareness is rising). With this article, I am attempting to address the less obvious or unobvious reasons why some tech environments are intolerable for many women.

The material for this article came about through my participation in both women-only and mixed gender groups of many kinds. When I wonder why tech groups aren’t tolerable for many women, I look at the inverse of the problem: What makes women-only tech groups more tolerable for women? My observations follow.

Why do women-only tech groups exist?

Over the years I had participated in many different types of women-only groups. Women-only drumming groups, women-only political groups, women-only tech groups, have all provided what women consider to be a “safe haven” to freely learn these arts, share ideas, expose each other to paid “gigs”, and help each other accomplish tasks. Women in these groups usually had nothing else in common except for the fact that they (1) were female, and (2) shared an interest and experience in drumming/politics/tech. Their professions, ages, skill levels, hobbies, sexual orientations, life experiences, marital status, children/grandchildren/no children, everything else about these women varied vastly.

My brain began to try and pick up on patterns which would explain why all of these different types of women feel as if they need a women-only group, and what such a group can provide that a mixed gender group cannot. Here are my observations.

Community plays an important and prevalent role in women-only/women-friendly groups.

No matter the group or the reason for gathering, _all_ of the women-only, and most of the successful women-friendly groups to which I have belonged had a strong sense of community. They make a tremendous effort to communicate well, to be fair with each other, and to provide support related to the groups goals, sometimes even extending outside of the groups goals.

This mindset is so common that women come to expect it when joining these groups, and foster it once they have joined. The implied message is that a strong, focused, collective effort will be spent to run things fairly and treat all members equally, and collective discussion happens when this is not accomplished. This is the lure to women-only groups.

Communication style is directly affected by this sense of community

I have never seen a woman harshly criticize another woman in these groups. Never have I seen or heard anything like “You suck”, “You’re wrong, idiot” when women in these groups communicate. Differences are usually discussed in a civilized manner. There is the occasional strong disagreement or ousting of a member now and again, but it happens after a discussion involving the entire group, and an effort to work out their differences. I am sure harsh criticism happens somewhere in some women’s groups. But I am also sure that it’s not tolerated for very long by other female members.

This style of communication is directly at odds with much of the harsh criticism and disdain found in predominantly male public comments, especially in most public online tech comment spaces, unfortunately.

Destructive criticism is the best way to keep a site predominantly male. It implies that there is no concern about whether a person can learn from a response or not, or whether they would find offense. It is an outward display of ego, a territorial “pissing rite” in which most women do not and will not participate.

That being said, there are many men who flock to women-only groups for the same reasons as women. They do not want to be subjected to the predominantly male style of communication where there is no sense of community, or even just simple accountability. They grow tired of the “pissing rite”, the absurd declarations of false boundaries, the outward display of insecurity through harsh criticism, implicit claims of “my way, my expertise, my right, never yours”, and poor display of ego. This mode of communication is an unproductive waste of time, and many men realize this as well. “I feel at home here because I really don’t want to deal with that male ego bullshit”, one male member of our political group stated to me.

Men who seek out women’s groups are usually welcome, or a splinter group is formed to accommodate these men, once it is determined that they do not seek membership for the wrong reasons. Some of the wrong reasons are:

(1) “I will be the only male member, and will therefore have my choice of ‘chicks’”. Nope. It’s not happening.
(2) “I will be the only male member, and I’ll guide/help/protect these lost/vulnerable/endangered women”. This is not only unnecessary, but laughable. Women find the implications of these assumptions both offensive and so primitive that it is hysterically funny.
(3) “I will infiltrate because I hate women, and want to try to dissolve the group in some way” This is very rare, but happens. The good news is that the motives of both men and women who attempt this become very obvious very quickly.

Women-only/women-friendly tech groups and gatherings offer a level of awareness of and accountability for behavior not found in most mixed gender tech groups/gatherings.

Awareness of and accountability for behavior in women’s groups means a lot more than just safety from sexual harassment, or discrimination. It means that if one is treated unfairly or harshly in any manner that a person finds offensive, the entire community will hear your claim. They will give you advice, opinions, and will collectively decide if action should be taken.

There has recently been a call for all public message board admins to get tougher about removing blatantly discriminatory, harassing, or sexually objectifying comments. This is a very necessary, damned good start. But to genuinely make an online tech community women-friendly, it needs even tighter moderation against harsh/demeaning criticism, elitist commentary, and exclusionist statements, the three most prevalent and women-unfriendly types of communication found in almost all moderated online tech message boards. There is no better way to give women a message that their comments are not welcome than implying that: (1) this is forbidden territory, women have no expertise here (2) your comments are stupid, wrong, or ridiculous, (3) we’re so much smarter than you.
Discussion, constructive criticism, even heated debate happens in women-only groups, but these methods of communication are avoided.

Both online and off, I have seen men who communicate this way with everyone, and men who only choose to communicate this way with women. I have also seen this behavior tolerated or ignored for the most part. Here are my observations on why this happens.

Men are generally very good at ignoring bad behavior.

This is both a blessing and a curse. In my most recent office environment, we had situations where a male colleague’s behavior was abrasive in one of these three ways mentioned. “That sucks, doesn’t it?” I asked another male colleague. “Yeah, but I just ignore it. That’s just the way he is. He is always like that” He responded. This is what I’ve seen as the general male way of coping with this poor communication style.

It’s a blessing that many men can ignore it, in the sense that most men do not get caught up in deep analysis of why this person said a specific thing, and what this person could have really meant, etc. When almost everything is taken at face value, and not overanalyzed, the ability to ignore communication issues makes it is easier to resolve the simple issues, and move on. I have seen some women in office environments do the over analysis, and take offense when there never was one given. I don’t see men do this very often, and it makes communication quicker and easier.

Ignoring communication issues is also a curse because one obnoxious person is allowed complete freedom to make excessive noise, be rude and disruptive, or explicitly offensive. Most men, online or in the office, will ignore it. Most women will notice it but not say or do anything about it, for a variety of reasons which are tangential to this article. The offender often thrives on the fact that no one told them to stop, so they continue. Sometimes the offender is not socially adept enough to pick up on the fact that ignoring implies intolerance at some level. They somehow missed the message most three year olds learn: I’m ignoring you because I don’t like your behavior, so they continue the intolerable behavior.

This is so prevalent in online tech communities that it is the primary reason why many women do not participate. The poor communication and behavior of even one boorish, ego-driven, elitist, socially inept geek is just simply intolerable for most women. Women generally tend to assume that everyone will be conscious of and annoyed by this behavior. Men tend to assume that everyone will ignore it. This causes problems in offices as well as in online communities, where women will complain about such behavior, and men will issue responses such as “toughen-up”, or “what’s the big deal?” because this is how they cope with the problem. A female-friendly group addresses and tries to resolve these issues, while the average group ignores it until/unless the person does something heinous.

The sense of community fosters a protective behavior within that community.

If you do something awful to one woman in a women-only community, all will hear and know about it, and you are ousted. Most of the time this is first discussed and voted on by many group members. Many times the women’s group will even make an effort to explain the offense to the oblivious offender. But if the offender is still oblivious and/or offending, the offender is out. This is done to protect the interests and goals of the group. Many male dominated online groups don’t run this way. Most if not all women’s groups run this way, whether online or off. This relates to the awareness and accountability mentioned before. It’s an essential element of all women-only groups, and seems necessary for women-friendly groups to draw women.

Women’s groups generally have a few vocal, and many silent, members
The vocal few express their opinions, and either gain support or do not gain support. The ones who gain support usually implicitly become the spokespeople for the silent many.
The silent many usually let the vocal few, with whom they agree, do the job of ousting, protecting the sense of community, and publicly representing the silent many. The silent many support the vocal few. The community in turn supports and protects the rights and privileges of the silent many.

Why this happens is again a dynamic which is tangential to this article. But it seems that many women in group participation give either their silent support or rejection, speaking up only occasionally. Because of this behavior, if a communication problem arises in any type of group, whether women-only or not, and there is not a vocal few who will attempt to resolve it, the silent many will often silently leave. The silent many often don’t want to complain, for fear of having to deal with the additional frustration of the unaware/unconcerned “toughen-up”, or “what problem?” type of responses. For the silent many, it’s easier and less frustrating to just leave. I think it is important for groups that want to advertise themselves as being women-friendly, to be aware of this pattern.

One of the challenges of any women-only/women-friendly group is encouraging the silent many to speak up. Many women deal with demeaning and discriminatory behavior so often in their lives that they are too emotionally exhausted to deal with even the possibility of an online onslaught of anonymous discriminatory and demeaning comments. Many women spend time observing online groups before deciding if they will participate, for this very reason. They want to ensure that they will not feel verbally attacked once speaking up, and that their issues, comments and contributions will be heard and handled fairly.

Women generally do not arm themselves for battle during tech discussions

Women generally do not work things out through verbal battle. By the time they
reach that point of wanting to argue, they are already so offended that they are in pure self-defense mode. Women treat the discussion of tech issues like the discussion of many other issues. It’s not competitive, and they wish to bi-directionally share information.

Many tech men envision a technical debate as a battle, and celebrate the supposed victory, exhibiting classic “Alpha Male” behavior. I have personally seen it so many times in my profession that I brace myself for it when discussing tech issues with new groups of men. So many of them arm themselves with weapons of aggression, demeaning comments, and behavior which encourage more of a filibuster than a healthy debate. The supposed tech discussion becomes a test of verbal and emotional endurance, where whomever can argue the hardest and last the longest wins.

They can shake hands afterwards and congratulate each other over a “good fight” after a technical debate. “I like the challenge of a good argument, which is why I do that” one male colleague explained to me. “I like a good technical debate too, but I don’t want to feel verbally or emotionally abused afterward. Women don’t fight for fun, they fight for personal issues.” I explained to my male colleague.

Unfortunately, the anonymity offered by many public wikis and message boards encourages the worst behavior in people. Even moderated tech chat areas and comment boards are rife with elitist, demeaning comments encouraging “the fight”. Some of it is due to oblivion, lack of knowledge that this is offensive to tech women. Some of it, unfortunately, is very intentional.

Apparently there are males online, in tech communities, who still believe that, like the cigar rooms of the Victorian Era, tech rooms should be male-only. Back then, the predominant purpose of smoking cigars in a common room was to have male-only space, and similarly today, the purpose of the demeaning and fight-provoking attempts is to maintain the male-only presence of some online tech spaces. I know for a fact this happens with intent in some online chat rooms and message boards. It is not simply an act of oblivion, but a concentrated, misogynistic effort between like-minded men to keep women out.

When I discuss this with people and we ask each other how this can be prevented, I feel overwhelmed. How do we stop any/all of the human behavior which prevents us from evolving further? I have no answer to this, but I am certain that if less of this behavior is tolerated online, we at least squeeze people who discriminate into their own, personal hidden online spaces. There is no reason why we need to be subjected to every single person’s beliefs or comments in the name of the First Amendment. We all have a right to remove from our lives anything and everything which holds us back in some way, even that which is subtly harmful or offensive. Web admins have a right to remove useless, demeaning, even subtly harmful comments in the best interest of an online community. The operative word here is “community”, and the appropriate questions is: Does your public comment space contribute to a community, or is it just an open toilet that everyone can vandalize and pollute?

Did you know?

When it was illegal for women to publish writing during various times in history throughout various countries, women published their work under male pseudonyms. Today, many tech women still use male pseudonyms when posting to lists or publishing tech articles. The reasons are to have their work read without bias, and to avoid misogynistic “hyper-scrutiny” of their work. I have experimented with this myself using a male pseudonym to post articles, and being told that the articles are informative, useful, great. Six months later I republish the exact same article, using a different title and a female pseudonym, and suddenly the article is horrible, technically incorrect, useless. It’s a fascinating study. I would love to see some prominent male techs publish under female pseudonyms, and watch the responses.

Women find it awkward to brag about their writing accomplishments published under male pseudonyms. For this reason, most of this work never gets credited to the correct person, and is never acknowledged on resumes or during job interviews. “How do I explain to a male ‘potential boss’ why I have chosen to use a male pseudonym, without bringing up the whole discrimination issue?” is what one female tech friend asked me. I had no answer for her. I have also let my work published under male pseudonyms fall between the cracks, into oblivion, not knowing what else to do.

To make an online community more women-friendly, try these suggestions:

(1) Monitor the public comments. Treat the public comments interface much like the
front door to your home. You don’t simply leave it open for any idiot to waltz in.
You can be selective regarding who comes in, and what they do once they’re in.

Useless comments get deleted as quickly as they appear. Any non-technical,
offensive, destructive, or off-topic comment is removed. This gives a clear
message about will and will not be tolerated. As useful comments accumulate,
useless ones are much less likely to appear.

(2) The technically correct but aggressive/demeaning/overly harsh comment gets returned
to the sender, asking the person to re-word using constructive criticism.
Sounds like overkill, but it’s not. The “You’re wrong, here’s the right answer”
type of response constitutes picking a battle that most women won’t fight, or won’t even bother dealing with.

(3) Treat your online space like a community. The web admin should act is if they’re on the board of chosen freeholders, voting on issues which affect themselves and the entire community. Don’t just throw up the comment space and leave it abandoned for vandals and other jerks. Maintain it according to the rules by which you want everyone to abide, and stick by your decisions. Have accountability for comments. Create a space where open discussion happens as if it were in an educational surrounding, not a seedy bar.

(4) Explicitly state that your site is women-friendly. Doing this will encourage the silent many to speak up. Kick out the jerks who don’t want your online space to take this direction.

For the men who care: Tips for communicating with women in Tech environments, online and Face-to-Face

(1) Tech women usually express great enthusiasm about their work. They do what they love, and they love what they do. When a woman gets enthusiastic about her work and shares that enthusiasm with you, it has absolutely nothing to do with you, or sex. I cannot tell you how often I have seen this. Some men mix up their incoming signals, and a women’s enthusiasm at work somehow translates to someone flirting with them at a bar. I have no idea how this happens, but it’s profoundly sad to see it happen again and again. If you’re lacking something in your life, please do not look to your female tech colleague to fill that niche. Do not even presume her mind is there even if yours is not, because hers is not, and your signal indicator needs serious recalibration.

(2) Leave your libido at the door. Please. Women tech colleagues want to be appreciated for their brains, their technical expertise, their contributions and accomplishments. Tech women do not give a flying shit about what their male colleagues think of their attire, their make-up or their body parts. Believe me when I say this is true. Women may give you a polite response, but on the inside they are offended, seething, and considering whether or not to go to their attorney. They will ask other women in the office or field if they too suffer from this problem, building an alliance against men in their company who do this. And soon you will have a legal problem. Leave it at the door, pick it up on your way out. No one else wants it.

(3) Some tech women dress up for work. It is NEVER for you. Many tech women wear clothing which makes them feel good. For some, comfort is paramount, if for example the tech female is crawling through the ceiling, moving dusty panels and running CAT5 cable. For other tech women who would not get their clothes ruined at work, they like to dress up. “It makes me feel confident. I look at myself in the mirror and I feel good.” my female colleague told me. For tech women at work, feeling “good” does not mean “sexy”, and it is not for you at all. It is entirely about self-confidence, self-encouragement, and giving one’s self the extra strength to prove they know their stuff in a technical environment. Note the emphasis on “self”: it is entirely for her, by her, and your reaction is entirely irrelevant.

I have heard males say horrible things in professional environments like “Well, you wore that dress, you do look great in it, that must be the reaction you wanted. Isn’t that why you wear that dress?” The answer is no, fool, get over yourself.

(4) Tech women are generally open-minded about what is commonly called “guy humor” and “guy socialization”. Guaranteed, many of them, myself included, have male friends with which they hang out on a regular basis, so this is far from a foreign concept to tech women. Chances are, the tech women of your group would enjoy your jokes and would like to be invited out for beers, as long as points (1) through (3) above are met. I personally enjoy and share many of my own raunchy or lewd jokes if I feel safe around the people with whom I’m joking. I enjoy hanging out afterwards over a beer or two, or going out late with “the guys” to a bar to welcome the “new guy”. These things could be fun for everyone if (1) through (3) are in order.

(5) To the men who do not do any of this: Thank you so much. We notice, and greatly appreciate this. I have been fortunate to work with some excellent men in tech, and I wanted to thank you and the many others for not being this way.

(6) No, women are not perfect. This article doesn’t imply or suggest that women are close to prefect and men are far from it. I know there are female stereotypes not mentioned in this article, mostly because I personally don’t find them in tech environments. Your experience may vary. All of these points can be applied to both genders. But the fact that I was asked by several different sources to write this article proves that there is a recognized gender divide in many tech spaces. All of what I have posted is what I and others have observed and experienced. None of it is fiction.

(7) Is someone making you feel uncomfortable? Speak up! If someone at work makes you feel uncomfortable, tell them so. If you feel discomfort coming from another person, and you think you’ve caused it inadvertently, say so. Make it clear and shove it out of the way as quickly as you can, so work can continue. This applies from/to men and women.

(8) But isn’t creating a women-only group, and using terms like ‘male behavior’ reverse sexism? Doesn’t this defeat the very goal you wish to achieve? My response is no, not if these tools/verbiage are used to try to ultimately achieve equality. If it’s used for mudslinging, or through some act of elitist exclusion, yes, it is reverse sexism.

Credits: Many thank yous to Carla Schroder for sharing her infinite wisdom and encouragement. A huge thank you to all of the women at LinuxChix.org for your tireless support of the cause over the years. Thank you to DevChix.com for giving my wayward articles a very worthy home. Thank you to the many readers who have left constructive criticism and comments.

Book Review: Beginning Ruby On Rails E-Commerce


BookRailsReviews

Beginning Ruby On Rails E-Commerce
From Novice to Professional
by Christian Hellsten and Jarkko Laine
published by: Apress

Book Site | Sample Chapter | Table of Contents

I got this book to review and set it on the shelf for a few months… by the time I got to it Rails was up til version 1.2 and this seems to be written for version 1.1.2 – DOH! I tried a few examples and wasn’t compiling. After a little investigation there are only a few differences that would hinder this book from working with Rails 1.2. Namely, the assert_select has replaced assert_tag. That being said, this book is still great and applicable to Rails today. If you think about it, with as fast as Rails as grown it is impossible to keep 100% up to date!

This book is totally fantastic for beginners – because it actually shows Test Driven Development. What you say? Most books say something like that “to keep code size down, tests and error checking have been left for an exercise to the reader” … Riiiiiiiiiiight. How are you going to teach people coding that way? Tests should just be an automatic task of a programmer. Write some test… write some code. I honestly can’t imagine anymore how you could code anyways without them!

Not only does this book cover testing (including acceptance testing with selenium in later chapters – whoo hoo!) it starts out with not using scaffolding. I think, and this happened to me, at first I used scaffolding for everything and didn’t really understand the process. The book first goes through the “scaffold process” by hand, writing each method and view – after writing the test. Very cool. Then it tells you how to use scaffolding for the next model in the sample application. Awesome.

It talks about common concepts for really any site – tagging, adding forum, adding a form to upload images, browsing a list of products, multiple language support. Even if you are not selling anything on your site, you will still find this book extremely helpful.

Impress your friends! Learn how to write a DSL for testing. This is cool stuff, DSLs fascinate me to no end. Any and all mentions of it I study intently. Rails is in a way, a DSL for web applications!

Being true to the title “e-commerce” it actually talks about how to do payments over the web. Most books who talk about shopping carts skip that important step!

When you are ready to make your millions on the web there is quite an extensive chapter on deploying your site. It talks about LightTPD, capastrano, caching, and security! Its really nice to have all this in a book, instead of constantly looking online for documentation

My only complaint is – it doesn’t specifically mention what version of rails it used, I assume from the output of script/about that is 1.1.2 … and they should of talked about how to check out a particular version of Rails, just in case you wanted to use the exact version that is used in the book. Which may not be a bad idea for new users.

Book Review: Pro PHP Security


BookPHPReviewsServers

ProPHP Security

Published by: Apress

Authors: Chris Snyder and Michael Southwell

Book Site | Sample Chapter: Preventing SQL Injection | Table of Contents

At first, I thought this book was all about cleaning your input variables and filtering your output, XSS attacks, SQL injections but I was most presently surprised to find that it was that and so much more! In fact, I would have called this “ProPHP Security and Administration” instead! It is absolutely fantastic. It really is about security in all of the facets of web development – from server, to code, to database to the system users.

The book is divided into 4 parts:

  • Part 1: The Importance of Security
  • Part 2: Maintaining a Secure Environment
  • Part 3: Practicing Secure PHP Programming
  • Part 4: Practicing Secure Operations

Here are some brief overviews of the sections and the tidbits I found interesting:

Part 1:

The first part is the shortest and gives a general overview the what and why of security.

Part 2:

The second is much more hearty and goes into detail about Shared hosts and why they are secure and how to make the more so. It even dips into alternatives for the traditional shared hosts and goes into Virtual Machines. This is valuable to not only to administrators but to PHP Developers. After reading this, I understand the “why” behind many of the things about shared hosting that I found frustrating.

One of the most important things I found in this chapter is how to maintain separate development and production environments. When I was helping to set this up at one of my past jobs it was a topic that I couldn’t find much information about. It also makes mention of version control, using wikis, bug tracking, sandbox and testing! Oh and here’s a concept…. pretend your live system failed — how well does your backup plan work?

How many times have I thought, I should make a cron job to back up my database to my home server every day/week? Have I ever done this? No! But now I have no excuse! Backing up a database and storing remotely is one of the sections in this chapter and code included! Fantastic.

There are chapters about Encryption theory and practice which I read several times to understand. It was interesting but it wasn’t something I have to do right now in my life, but I will return to this book to refresh my memory when I do.

Securing Network connections SSL and SSH, these proved helpful as I have become the “Reluctant System Admin” for one of my projects — partly because if they were to hire a part time person I’d rather they get a CSS person and I’d rather do the sys admin!

The Controlling Access section goes into details about using certificates with php, single sign-on, basic and digest http authentication … whoa this is some deep stuff! But good, when I was looking into this for a project a few years ago I couldn’t find anything helpful. It continues with then permissions and restrictions, a lot about Unix permissions and keeping things running where they should, securing databases and PHP Safe mode!

Part 3

Finally — the stuff that I thought the book would be about – validating user input, filtering output, preventing cross site scripting attempts, remote execution.. so much more to security than I thought! It talks about securing temp files, I always assumed the OS handled this and I didn’t need to worry.

Part 4

Ahh — Practicing Secure Operations… all you ever wanted to know about making sure your users are humans, verifying your users, setting roles for users, logging your users actions, preventing data loss, executing system commands safely, working with webservices and finally Peer Reviews! Sometimes it’s that extra pair of eyes that can see things you miss.

Something I find interesting – in the section about preventing data loss, it talks about setting a flag on records that are “deleted” and then making a db view of the “good” data and using that to select from. One of the things I like in Ruby On Rails is this “acts_as_paranoid” model option that does about the same thing. Neato.

Pro PHP Security is a most excellent read and so much deeper than my brief overview here. It will be a handy book on my shelf to keep me on my toes regarding security in all areas of web development, from the server to the code, to the users, to best practices of security you will find this is a helpful book too!

Book Review: Beginning Ajax with PHP by Lee Babin


BookJavascript/AJAXPHPReviews

Book Review
Beginning Ajax with PHP by Lee Babin, published by Apress

Book Site | Sample Chapter: 3 PHP and Ajax | Table of Contents

Although no stranger to Ajax, I received a review copy of Beginning Ajax with PHP expecting some watered down presentation of Javascript with some PHP thrown in. I was quite surprised to find a good presentation of using Ajax and PHP, easy enough for the beginner and still interesting for those who have done it for years.

The book starts out exactly how I would write it — SIMPLE! The first time I did Ajax with XHR (xml http request), I used a plain text file, which I then read into a DIV at the click of a link. This takes a similar approach and has data stored in an array which is then accessed with a simple call to a PHP file. The following chapter, takes it a step further and this building upon previous chapters is a common theme in the book.

After going through the basics, the book gets into more practical uses of Ajax. The latter chapters talk about using forms to pass along data to be processed by Ajax and doing form validation. It also gives a good explanation of the proper use of the form methods GET and POST. It goes into detail about uploading images and other files using a hidden form submit trick, since XHR doesn’t support file uploading (javascript is not allowed to access files on your harddrive). And this chapter is the perfect predecessor to the “Real-World Ajax Application” chapter where you will take what you have learned and create an Ajax based photo gallery. Practical, hand-on is the best way to learn something IMHO (Sorry “Hello World” scripts!). It is interesting that this chapter is in the middle of the book, when I would expect it at the end. Perhaps the author wanted the user to jump in and try it, instead of persevering to the end. I don’t know about you, but often the last few chapters of the book go unread by me.

After the reader has confidence on how to use AJAX, the book gives the warning, “Whoa! Wait a minute! AJAX isn’t appropriate for EVERYTHING!” It gives examples of when AJAX would be a good idea and when it would not. I think this is pretty important as each CEO now wants Ajax everywhere in their application but it’s not always the best solution! And it talks about the classic, “THE BACK BUTTON”, problem. Then, in the same chapter, the book takes sort of a funny turn (in my opinion) and gives an introduction to PEAR. The book explains how to use PEAR’s HTML_TABLE class to illustrate a good use for Ajax in creating an Excel-like grid that sums columns. This is a very cool class but would have been better suited for an appendix.

The rest of the book seems to be a random splattering of interesting topics: web services, map applications, cross-browser issues (touches again on the back button problem – but a solution this time!). There is also a brief mention of security. This should have been more in the middle of the book (see above for skipped last chapters syndrome). What then follows is a testing and debugging chapter which would have been more effective as the 3 or 4th chapter in the book. Finally there is a chapter about the browser DOM.

A great minor addition to the book would be an overview of some Ajax libraries such as Prototype, JQuery, Dojo, etc.