Category: Development


Development Security isn’t an Add-on

May 4th, 2013 — 12:48pm

Thanks to O’Reilly’s “DRM Day” promotion yesterday, I picked up a copy of a book I’ve been meaning to but could justify because a) full price of the ebook is around $25 USD and b) it was written back in 2003 – almost ten years old! The book, “Secure Coding: Principles and Practice” is more of an overview of things to think about when it comes to secure development and less about specific language-related tips. What’s interesting to me is that, despite the book being 10 years old, it seems like the same challenges they were facing then, we’re still facing now.

Even the introduction reinforces something I’ve been trying to advocate in the PHP community for a while now – security is not an “add on” that you can drop in at the end of the development process. Security must be a part of the planning and architecture of your applications from the beginning. If you “go back and secure things” you’re doing it wrong. Now, this doesn’t mean you have to have some kind of security review process retrofitted into your SDLC. I know of lots of teams that have their workflow down and are cranking out the code and features like there’s no tomorrow. How does a team like this start “thinking secure” without having to add a lot of extra overhead? It’s pretty easy really – all it really takes is a shift in mindset.

When most developers I know start out on problems, they ask themselves questions to figure out how to start in on their solution. They wonder about things like the “best way to do it” or “the most efficient way” to get the job done. Their minds start filling up with object structure and SOLID principles, trying to find the best solution (and maybe even technologies) for the job. To start thinking secure, all it takes is one more question:

How can I break this?

Easy, right? Well, like anything else in development, one question always leads to at least 10 more. This one simple question sets you down the right path, though. It’s too easy to get focused on making things work and writing up unit tests that pass when everything’s good. I want to challenge you as a developer to do one thing in your next project. I want you to take a step back from the code – maybe grab a fellow developer to help – and look at the application from the outside and determine what could be exploited and where (the “attack surface“). A lot of times this is easier when you’re not neck deep in the code, so if you have doubts, find an outsider.

Here’s some related websec.io articles I hope can help get you in the right state of mind as you work to integrate secure principles into your development. There’s lots of other topics in there that devs would find useful, but this will get you started:

Let’s all help make the integration of security and development a thing of the past. Then, ten years down the line, people wil be reading books from 2013 and wonder what it was like “before”. :)

1 comment » | Development, PHP, security, websec.io

“It Depends”

November 30th, 2012 — 3:35am

In my research and writings that I’ve already done, I’ve noticed something about trying to share helpful security advice to fellow developers – you can provide all of the code examples and describe the threats all you want, but the problem really boils down to two words:

“It depends”

Much like other development-related issues, there’s a lot of things you have to take into consideration when thinking about the security of your application. Code security by itself is good, and there’s some best practices for that that have been shared all over the web. Unfortunately, this only paints a small part of the picture. Web applications, by their nature, are really complex systems composed of multiple pieces of software all running together to make this useful, functional service for its consumers. If you’re a PHP developer, there’s things you can do to help prevent common attacks (like XSS, CSRF or SQL injection to name some popular ones), but unless you look at the bigger picture, you’re getting a false sense of security.

“But I’m only responsible for the code!” you say. You like the idea that your code can be as secure as possible by filtering output, escaping user input and using defensive coding techniques. You commit your code, run your tests and happily go about your business, thinking things are good. Unfortunately, if you don’t consider the ecosystem your application lives in, chances are you missed something.

I’m not talking about code challenges here – preventing things like XSS or SQL injections is relatively easy (as long as you know what to do). The problems I’m talking about are things that may be true for one environment but not for another – things like:

  • Working with multiple databases and storing their credentials securely
  • Effective logging to a remote syslog server
  • Potentially protecting your data from a physical intrusion
  • Working with sensitive data
  • Bridging authentication/authorization across applications
  • Concurrency issues coming from multiple installations of the same application

While a lot of these kinds of concerns revolve around the architecture of the application, developers still need to keep them in mind when creating their applications. At the very least, you need to keep these kinds of concerns in mind when writing your code. Like anything else, there’s ways to structure the code to make things like this simpler to change. The trick is to keep things loosely coupled enough to make life simpler down the road.

Comment » | Development, Opinion, PHP, security, websec.io

Innovation’s Not The “Ah-Hah!”

May 25th, 2012 — 10:29pm

After reading through his “Confessions of a Public Speaker” (as a beginning speaker, I learned some good things from this one – I’d suggest it if you do any kind of speaking) I was anxious to check out some of Scott Berkun’s other books. The topics of some of the others didn’t really appeal to me, but the one that’s caught my attention recently is his “Myths of Innovation” book. I’m maybe a third of the way through it right now, and there’s one thing that keeps resonating in my mind as I go through it. In a previous chapter, he makes the point that innovation, despite what the history books and popular culture would have us assume – it’s less of an “Ah-hah!” and more of a “Finally!”.

See, most of the common stories of innovators out there leave out something that’s very important – the reference frame of their lives. They don’t provide a larger picture of who someone is (like Einstein or Newton) and how all of their work, everything they’ve done in their career led up to the discoveries that they’re known for.

I think this is important to remember as software developers, too. All of us start projects and never finish them, it’s just a fact of life in the world of a coder. We find something that we either think is the “Next Big Idea” or something that we’ll find amazingly useful and latch onto it, giving it our all for a week, maybe a month. Nine times out of ten, though, that project falls by the wayside. Now, don’t get me wrong, there’s some folks out there that do a great job with anything they touch, but for the average developer, it’s all about hacking away at the latest “shiny”.

Sometimes it’s about the technology (“everyone’s learning Backbone.js, why shouldn’t I?”) and other times there’s a bit of pride that kicks in (“I could do this so much better if…”) but there’s always one thing to remember. It doesn’t matter if the project you’re working on goes anywhere. Remember this. Just like some of the great innovators of the past, it takes a lot of dedication and work to get to be the “Ah-hah Guy” that wows the world with something new and amazing. Don’t forget that the code of the Next Great App isn’t just going to fly from your fingertips.

Work hard at your craft and it will pay off. Maybe not in fame and glory, maybe in making real, useful contributions to the culture and technology around you. Don’t stop trying to innovate, don’t focus on the failures and, above all, keep learning and keep doing.

4 comments » | Community, Development, Opinion, PHP

Book Review: “Code Simplicity”

April 17th, 2012 — 9:40am

Last night I finished my latest read from O’Reiily, Code Simplicity – The Science of Software Development. I spotted the book the other day when O’Reilly was running a special on a few books and the ebook was cheap so I figured it couldn’t hurt to give it a try. After all, the “science” part in the title made it sound like there might be some hidden truths that could be applied anywhere in development. Unfortunately, most of the book just ended up being more of a rambling journey though things that most software developers that have any years of experience (even the bad ones) would already know.

The author spent a good bit of the book dedicated to definitions and explanations about various practices and ideas in development, as if he thought that maybe the audience reading the book wasn’t savvy on the topic. The first few chapters also included several sections about the book itself – why it was relevant and mentions of a “science” that never seemed to fully resolve. Granted, trying to make a “science” (more a set of laws than just best practices) out of something so varied as software development is a pretty difficult task, but I felt like the author tried a little too hard to make his case for the book and less time actually defining something that could have been interesting.

All this being said, if you don’t worry too much about him trying to propose a “science” to it all, there were some good best practices reminders in here for developers of any language:

  • Don’t rewrite, rework – a reminder that, despite it seeming easier to chuck the whole system and start over with the knowledge you now have, you’d do better in the long run to change things from the inside out, a piece at a time (hint: unit tests make a world of difference here)
  • Know the problem before writing the solution – listen and understand the problem before you start with even one piece of code. If you don’t fully understand the problem, you’ll end up with half-assed software that only does part of what was needed.
  • Think specific, not general – if you immediately jump to the “well, if I use a plugin architecture for this part…” chances are you’ve already added too much complexity. Think small first – make it work, then make it better (I’m a big fan of iterative development)
  • Use more experienced developers as a sounding board – chances are, if someone’s been in the development biz longer than you, they’ve come across your situation before. Sometimes you have to seek out that person on a specific topic, but don’t just forge ahead blindly. At the very least, try to find blog posts or articles that you can use as a guide.
  • Don’t forget that time is important too – most developers (me included) easily forget that time is a factor in their development. No, I’m not talking about the actual time to write the code or the looming deadline to finish it by. I’m talking more about the time you’ll need to do research, try things out or even consult with fellow developers. Time put into something to gain knowledge is an investment too…don’t forget to remember the value of it.

There were other points made throughout the book, some more relevant than others, but I wish the author had spent less time focusing on definitions and more on expanding the sections with some more practical advice. This (relatively short) book probably could have been summed up in a small series of blog posts and been just fine.

Book: Code Simplicity – The Science of Software Development
Publisher: O’Reilly
Author: Max Kanat-Alexander
Pages: 92

3 comments » | Book Review, Development, PHP

The Accidental ScrumMaster

November 15th, 2011 — 9:07am

Since my role has changed over the past few months away from being a pure developer to a lead of an agile (scrum) group here, I’ve started blogging some about my experiences over at The Accidental ScrumMaster:

Let me start off by saying this – I have been a developer for just about all of my professional career (with some syadmin and networking tossed in to spice things up). I’ve helped to lead other developers in projects where we were focused on just the software and didn’t have to worry too much about outside forces. At my current job, this has changed. Over the last few months, due to some changes in staffing (read that as “people moved on”) holes were left in the team for certain roles. Before those people transitioned out of their jobs, they started to approach me with some of the responsibilities they had and showed me the ropes.

Suddenly I wasn’t just another developer anymore – I was the person managing our Jira project, I was the one doing the code merges and releases and I was the one tracking the progress of the project on a day to day basis.

I hope what I post there can be beneficial to other developers out there who find themselves with extra the responsibilities of making agile happen in their jobs.

Comment » | Agile, Development

You’re Open Source…Now What? (Communication – Part 3)

June 24th, 2011 — 9:01am

So, what started out to be a post or two on some of the important things to consider about communication in open source projects, has now turned into it’s own little mini-series. In part one I talked about some of the important things to consider when it’s you, the organizer, talking to the people that come in and want to get involved with your project. In the second part I covered some of the organizer-to-organizer communication techniques to keep the project running smoothly.

In this part I’m going to focus on something that’s a bit harder to control, but can still make a huge amount of difference in your project’s life. Contributors talking back and forth with the organizers is fun and all, but sometimes they just want to skip a step and go directly to another developer. Dev-to-dev communication is absolutely necessary to make a project thrive. If a developer comes in and the only chatter they see on a mailing list is the project’s admin taking to various people, chances are they won’t stick around too long. People want to see life, they want to see lively discussions and ideas being explained and played off one another.

There only one real issue – you can’t control this.

You can, however, make use of some tools that make it a lot easier. As I mentioned, mailing lists are great tools to have for your contributors to ask questions and get their own ideas across. You have to encourage this, though – it’s not just going to magically happen. Sometimes you have to get the ball rolling by asking a few questions yourself first, but once that ice is broken conversations will more easily pop up. Even just a response or two to a question you posed to the list can spark ideas from other developers not even interested in the original thread. Challenge yourself to, at the start of every week, try to come up with a topic that you think needs to be discussed on the project and start a thread on the list. It’s okay if the majority of the activity at the project’s start is from the organizer(s). Lots of people have their opinions, some are just more forthcoming than others with them. Having a good “feel” for the list helps bring these out.

A second tool that can be invaluable for any project, just starting out or already mature with its contributor base in hand, is something that several of the code repository sites (like github or Bitbucket) offer as a part of their service – the ability to look at the changes someone’s committed to their branch (or to trunk), see the differences and comment on them right in the same page. Previously, version control systems have sent out commit emails that might have included the diffs from one version to another. This is good and all, but developers would need to respond to these emails with their suggestions and, well, as I’ve already mentioned, email is really more about the point-to-point rather than for lengthly discussions.

There’s a huge benefit to having a record of all comments related to change in the code right there in front of you. Github will even let you make a comment about a specific line in the change and all parties involved in the discussion are notified. No more batting around emails and trying to keep track of how many “Re:” there are in the latest response.

The final recommendation I’ll make is probably the most tricky depending on the size of the project. If at all possible having developers on your project physically in the same room makes amazing things happen. Take, for example, the Hackathon that happened at the last php|tek conference. Several developers were all there with the intent of working out some of the bugs in the Joind.in project as well as several others (including writing tests for PHP itself). Remote communications can be efficient, but there’s nothing quite like sitting across the table from another developer poking around the same code you are and hashing things through. Obviously, the Hackathon was a rare event, but if you’re even able to just get two or three contributors together, do it. Conferences are a great place to organize things like this – there’s people from all over that already know the project and look forward to the community that comes with other developers on the same project. There’s even the possibility of drafting new recruits!

Developer -to-developer communications is one of the hardest to get right mostly because it’s not really something you can control. It’s more of a “throw it and hope it sticks” kind of thing that can really pay off in the future of your project.

2 comments » | Development, opensource, PHP

You’re Open Source…Now What? (Communication – Part 2)

June 23rd, 2011 — 9:03am

In case you missed it, this post is a continuation of another post looking a some of the things I’ve learned in the time I’ve spent as an open source project organizer for Joind.in. In this second post I’m going to keep looking at communication and the role it plays in the project. The focus will be a little bit different, though – this time it’s more about internal communication.

Keeping all of the contributors to your project informed and involved is a task to itself, but this should be only half of your focus. It’s easy to get caught up in the code merges, mailing list threads and even heated IRC conversations about the next fixes that need to be made. It can be fun, trust me – there’s times when it’s easier to just think about the code and where the popular opinion says it should go. Unfortunately, this almost always leads to bad decisions.

See, one of the core things you can’t forget about when you’re organizing an open source project is to keep the “staff” all on the same page too. When you start off small and it’s maybe you and a few casual committers, it’s easy. You can pull out the decisions without having to worry about anyone else. This all changes when you have one or more others come in and start to be a part of the project. It’s a tough transition for a lone gunman developer used to calling the shots to flip that switch in their head labeled “ask the team”. It’s crucial that everyone involved in running the project be on the same page about things. If they’re not, that’s when bad things can happen like major code forks or worse – a poisoning of the project’s community.

I know in the previous article I advocated keeping things out in the open when dealing with the project and its intentions, but there’s a “but” that comes with it. Contributors and casual observers don’t need to be in on some of the organizational decisions related to the project. There’s things related to the code of the project and then there’s things related to the project itself. It’s up to you and your fellow organizers to make the call on what discussions belong where. Usually the line is pretty clear, but somethings a “let’s ask the community what they think” is the right way to go.

So, how does a (possibly) completely remote team keep up with one another? Well, here’s a few ways, some being better than others:

  • Email – one of the more cumbersome techniques due to it’s nature as more of a point to point method. This can work if there’s only 2-3 of you, but when it starts growing past that, this just gets confusing
  • Mailing List – this is a step above the emailing method and at least will give you a way to review the threads in case questions pop back up. Still not great, but better
  • Online project management apps – these can be great if you need something with a bit more superpower to help manage the project. Even something as easy as Basecamp can help.

The real key is to finding something that works well for your project, though. Sometimes it’s enough to just keep a running list of decisions/future plans made about the project, but I’ll warn you that you’ll outgrow this pretty quickly. It just doesn’t scale very well for anything other than a 2-3 person project.

Thankfully, keeping your project’s “staff” informed isn’t as difficult as keeping up with the general contributor base. It’s easier to just tell them where they need to go rather than trying to get the message out to as many people as possible and hoping it sticks.

Do you and your project have a tool or method that you use to keep all of the admins on the same page? Share it in the comments!

Comment » | Development, opensource, PHP

You’re Open Source…Now What? (Communication – Part 1)

June 22nd, 2011 — 8:55am

I’ve had an idea rolling around in the back of my mind for a little while now and the Call for Papers for ZendCon brought it up and into focus in the last few weeks. I am a part of the Joind.in project, a community event feedback site that’s also an open source project. My co-conspirator Lorna Mitchell and I have worked hard over the past year or so really trying to make the project the best it can be. There’s been a lot of learning that’s gone on during that time, so I wanted to share some of that in a series of blog posts.

This first post, as the title mentions is about communication. I’m going to break it up into two parts because there’s really two different sides to this one word when it comes to a project with so many moving pieces.

Communication with the Group

The first and more obvious form of communication people of think of when working with an open source project is talking to the community at large. Once you take that step an decide to open the source for your application, you’re no longer alone in its development. Sure, you might be the only one committing code to the project, but that doesn’t mean there’s not interested parties out there keeping an eye on your work. This is the first thing to consider as communication from your project to the outside world – the code you write. Even the best, most elegant code without some kind of commenting or internal documentation will fall flat. If there’s nothing helping an outside developer to understand your code and the design of it, chances are they’ll abandon it before they even get started.

Following this same line of thought, there’s the next most important (maybe more important?) form of communication for you to share with potential developers – project documentation. I know it’s been hounded to death by this point, but please don’t wait until the very end of your coding to write documentation. Yes, it’s a pain, but with so many tools out there (like the excellent DocBlox) to help you generate documentation, you have no excuse. Auto-generated docs are great, but real human-made files that include examples and descriptions are even better. Don’t forget to put a human side on your project – it draws in more contributors than just code comments alone.

The “human touch” brings me to the next topic under communication – personal interaction. Comments and documentation on the project are one thing, but if you really want to get people involved and get them as excited about the project as you are, you need to reach out to them on a personal level. There’s lots of ways to make this happen including:

  • mailing lists (we have ours split into “developers”, “features” and “site news”)
  • an IRC channel (#joind.in on Freenode, stop on by and say “hi”)
  • a blog
  • a Facebook page
  • a Twitter account

It’s an easy thing for a developer of a project to just want to stick with the code and get tunnel vision when it comes to the overall project. I’m going to go so far, though, as to say that if you don’t choose at least one of the things from the list above, your project will not succeed past the point of you and maybe a few other developers hacking on the code. At the recent php|tek conference in Chicago, there was a hackathon one night where several (I think it was around 8 or 9) folks all sat down and worked on Joind.in bugs. This was excellent except for the fact that I, one of the project leads, wasn’t able to be at the conference. This is where the IRC channel became invaluable – Lorna was there helping but there was only so much of her to go around. Me being able to have an official place for those people to come and ask questions was a huge boost in productivity over something like email.

Two things to remember, though – having these things is great, but don’t spread yourself too thin. You don’t have to have all of the things from the above list to make a successful project. Pick what fits your needs and the needs of your group. Remember, not everyone that’s interested may be a developer. Also, and this goes hand in hand with #1, don’t forget to nurture the communities you build. I’ve seen first-hand how things can drop off if the driving forces behind the project aren’t there to help drive these interactions. The past few months my time was increasingly eaten up by the conference I was planning and I just wasn’t able to spend the time with Joind.in that I wanted to. As a result, the mailing lists ran a bit dry and even the IRC channel was sparse. I’m on a mission to turn this around, though and am doing what I can to keep our current developers and bring in those shiny new faces eager to hack away.

Disclaimer: Okay, so I lied a little bit – turns out there’s more to say on this topic than I thought, so the second part of the “communication” idea will be in a “Part 2″ post coming soon. Until then, here’s a few suggestions for the project organizers out there about communication with your developers:

Suggestions

  • Be transparent – don’t hide decisions from your community. No one likes surprises, so do them a favor and let them give their input
  • Be consistent – you and the other project leaders need to present a united front on decisions. No “ask him, he’ll say yes” sort of thing
  • Be polite – yes, there’s going to be “those people” that seem to live to cause trouble, but deal with them politely. You never know who’s listening
  • Be a dev leader – this is an easy one for the project leads that are still developing, but for the others this could mean moderating pull requests or being familiar enough with the code structure to answer some high-level questions

In the next post I’ll talk more about the flip side of this – communication within the project between organizers and some of the difficulties that are hiding in there.

2 comments » | Development, opensource, PHP

Process Oriented vs Product Driven

April 10th, 2011 — 9:45am

Advice I like from 101 Things I Learned in Architecture School (Matthew Frederick):

Being Process Oriented, not Product Driven, is the most important and difficult skill for a designer to develop.

Being process oriented means:

  • seeking to understand a design problem before chasing after decisions
  • not force fitting solutions to old problems onto new problems
  • removing yourself from prideful investment in your projects and being slow to fall in love with your ideas
  • making design investigations and decisions holistically (that address several aspects of a design problem at once) rather than sequentially (that finalize one aspect of a solution before investigating the next);
  • making design decisions conditionally – that is, with the awareness that they may or may not work out as you continue toward a final solution;
  • knowing when to change and when to stick with previous decisions
  • accepting as normal the anxiety that comes from not knowing what to do;
  • working fluidly between concept-scale and detail-scale to see how each informs the other;
  • Always asking “What if…?” regardless of how satisfied you are with your solution.

Not a far stretch to make to software engineering. I especially love the “be slow to fall in love with your ideas” line. It’s easy to be seduced by how sexy something is and be blind to the fact that it sticks out like a sore thumb. Admit it, you’ve done it too. Above all, be flexible, consider more than just what you see right now and remember that software is constantly evolving – you should too.

Even if you have no intentions of learning anything more about architecture, 101 Things I Learned in Architecture School is a nice read with lots of good parallels, I highly suggest it.

2 comments » | Development, PHP

I don’t understand the 9-to-5

February 11th, 2011 — 9:08am

No, this isn’t another post about taking that step out of the corporate world’s 9-to-5 routine and venturing out on your own. (Though that would make for an interesting future post). This post is more of me asking a question of the development community – PHP or otherwise – to help clear up something in my mind. Let me set the stage…

I’ve been developing PHP for….well, let’s just say a long time now and in that time I’ve come to appreciate the quirks of the language and have had a real hunger to find out more about it. It’s a constant friend in my day to day life. I have multple side projects going that use it (PHPDeveloper.org and Joind.in), so PHP is a huge part of my life. Along with this comes the community, a constant stream of new information and people I can sincerely call friends even though we’ve only met a handful of times. It’s the language that brings us together.

Now, back on my wheel again – what I don’t understand is this completely foreign concept of people that just do this as a 9-to-5 job. They come and sit at their workstation and write their code then, at the end of the day, they switch it off and go do something else. I see them writing their code (yes, some of it’s pretty bad) and I wonder how they can’t have that drive to constantly better themselves by doing more than just pushing buttons and earning a paycheck.

So, dear internets, if you could help me out on this – I’d really like to understand the mindset of these folks. I don’t know if I’ve ever been in their shoes and I’d really like a glimpse inside their heads.

Some comments from IRC and Twitter so far:

  • jbafford: they’re people who think they can make good money programming, as opposed to, people who program to solve problems
  • pierrejoye: usually having other time consuming activities don’t allow one to do more. The few doing nothing but 9-5 are social cases

40 comments » | Development, PHP

Back to top