A blog by the Brick Factory The Brick Factory

Summer Internship at The Brick Factory

We are looking for an intern to join our team for the summer. The job description is below as well as instructions for how to apply. We’d love to hear from you!

Summer Internship at Brick Factory

The Brick Factory plans and executes world-class digital campaigns for non-profits, trade associations, advocacy groups and brands. We believe in simple solutions, setting clear goals and objectives, and providing great service to our clients. We believe a good website or campaign is never done and the launch of a website is the beginning, not the end.

The Brick Factory intern will be responsible for supporting our Strategists in conception, implementation and analysis of many digital initiatives. This includes website, social media, email, mobile and other digital marketing efforts that support new business and client programs. This position calls for an individual with strong communication skills, analytic skills and creative thinking ability. This position requires a highly resourceful individual who can think on their feet and can focus under pressure.

What you can expect from this internship:

  • To Work: Do not be fooled, you will be put to work. Researching, creating, outlining, and executing strategic plans to the highest ability will be your average Monday.
  • To Grow: The Brick Factory has high expectations of all interns and believes that in order for you to get the most of your time here, meeting and exceeding mutually defined goals is of top priority.
  • To Compete: A summer internship at the Brick Factory will provide you will the skills and experience necessary to compete in the fast-paced, ever-changing digital technology industry.

What we expect from you:

  • You’re a fun person to be around.
  • You have a passion for work in the digital industry and are excited to explore the digital-sphere
  • You’re a problem solver. You would rather figure out the best solution than be told how to do it.
  • You’re organized. You can manage multiple projects at once and are dedicated to hitting deadlines.
  • You have some experience with HTML, marketing and sales research, and analytics tools.

What you can expect from us:

  • A great work environment, with plenty of opportunity to learn
  • A metro accessible office in downtown Washington, DC
  • Compensation during the extent of your internship
  • A fun team of enthusiastic and talented people

The Details:

Dates May 15, 2013 through August 15, 2013 (can be flexible for the right candidate)
3 days a week in the office

Sound interesting? Take a look around our website, blog, Facebook and Twitter. If you think we’d be a good fit please send a resume and cover letter to jobs@thebrickfactory.com.

Tyopograhy inspiration

What’s Your Type? 5 Sites with Great Typography

It is said that a picture is worth a thousand words, but what is said when the design itself lies within the formatting of the word? Each letter, each stroke has a meaning, has a purpose and makes a statement all its own. So how many words, ideas and expressions are portrayed in a perfectly curated and properly polished typography based website? Two-thousand? Three? Fifty? It is my perspective that this expression of sophisticated design cannot be quantified, rather simply appreciated for what it is.

So much lies in a word. A single word can stir emotions, spark excitement, cause a raucous, and make you stop and ponder, all within the meaning, purpose and in the web world, the design of the word itself. Below is a list of some of my favorite typography based websites. I chose these for the use of tailored fonts specific to their brand, the use of specific color to highlight their chosen text, and the seamless integration of just the right number of fonts used. (more…)

Selecting the right tool for the job

Using the Right Tool for the Job

The Brick Factory’s development team has been writing custom PHP applications for ourselves and clients since 1999, and PHP development has changed quite considerably since then. At that time, and for years after, there were few available frameworks with which we could build our applications on, so all of our applications were developed from the ground up, with later applications taking advantage of some reusable code libraries (most of which came from our ImpactWatch application, and others from our online training service).

In 2005, we started using WordPress for blog sites, and later, in 2007, we started to use Drupal for more complicated sites. Both can, to varying degrees, be called application frameworks (Drupal considerably more so than WordPress), and using these tools allowed us to create many websites covering a wide range of needs for our clients must faster than we could have if we had to write everything from scratch.

Actually, at one point before we adopted Drupal, we started to write our own CMS tool, and stopped when we realized that the amount of time we’d have to spend building it to meet our needs would be considerably larger than just using an existing open-source platform. And even if we succeeded in building something that met our standards, ultimately, we’d just be re-inventing the wheel that Drupal, WordPress, Joomla, and 40+ other CMS systems (according to Wikipedia) have spent years refining. And where’s the fun in that?

So, we’ve spent the last several years refining our skills with Drupal, even contributing back a few bug fixes and a Drupal module (Splashify) to the community, and we think we’ve gotten pretty good at Drupal site and module design and implementation.

In December, we started planning for Sway, our next internal project. We have some ambitious goals with Sway, and we wanted to get something to market relatively quickly, so it was obvious early on that we had to use a framework of some sort. This meant we couldn’t use the internal workings of ImpactWatch or Training, as aside from a few reusable components, they were never designed and developed to the point of being significantly useful in other applications.

It also put Drupal out of consideration, as what we had in mind would require so much custom work that the strengths Drupal brought to the table would be outweighed by the time we’d spend working against it. Also, we wanted a chance to use the latest and greatest technologies. PHP 5.4 has been available for just over a year, and we wanted to be able to use it. Drupal 7, by comparison, doesn’t take advantage of many of the new features in PHP 5.3, let alone PHP 5.4.

Ultimately, we settled on Symfony, and in January, started developing Sway using Symfony 2.1 (and quickly upgraded to Symfony 2.2 in March after it was released).

As an added bonus, working on Sway will give us a head-start in learning to use Drupal 8, which is expected to be released later this year. Core components from Symfony are being used in Drupal 8, so we’ll be able to put some of our experience working on Sway to use on any Drupal 8 sites we start working with. Both Symfony 2 and Drupal 8 use the Twig template engine, so our designers will have time to become familiar with Twig before we have to start using it on Drupal sites.

We’re looking forward to what we’ll be able to accomplish with Sway, and with future versions of Symfony and Drupal. This should be an exciting year!

HTML5 Vs. Flash

Five Awesome HTML5 Interactive Pieces

The technology people use to browse websites has changed dramatically the last few years.  Smartphones and tablets have become ubiquitous.  Desktop monitors are getting bigger.  Connectivity is getting better.  Browsers are getting more sophisticated and powerful.

The approach to building website has evolved along with the technology people use to brose the Internet.  In the last few years Flash has gone from ubiquitous to scarce.  And HTM5 has gone from an experimental technology to a fairly common way to build websites.

The rise of HTM5 and the fall of Flash have had a particularly dramatic impact on Interactive pieces.

I remember seeing this Arcade Fire HTML5 interactive film back in 2010, and being blown away by the possibilities it presented. While it is still pretty great, pieces like this have become more and more common over the last few years.  Following are five HTML5 interactive pieces I’ve come across in the last few months that push the boundaries of what is possible in browser. (more…)

Injection attacks are still the number one security vulnerability

How to Protect Your Code Against Injection Attacks

When I started working with PHP years ago, the first thing I did was go online and try to find tutorials. I worked with someone who also did PHP (and was the primary driver for wanting to learn the language), but finding out how to do things on my own fit better into my schedule. Eventually I got to working with databases, and the tutorials I found looked like this:

This is perfectly valid code. In fact, if you look at a lot of examples today you will see the same thing. There’s a huge flaw in these examples, and one that has given PHP a bad name when it comes to security. It isn’t the fault of the language but of the way that many developers learned how to do things. PHP makes it easy to shoot yourself in the foot and it doesn’t help that developers keep showing new developers how to do it. Get gun, point at foot, pull trigger. That’s essentially what the above example is showing you.

So, what is so wrong with the example code? The problem is that we aren’t validating anything. Do we know what $_GET['id'] actually is? What happens if $_GET['id'] is set to something that isn’t an integer?

When mysql_query() runs it will return false. Depending on how well your code handles a false return, someone screwing around with the query variables will learn that we didn’t properly make sure that the id query variable is being checked. At the very least they learned that changing query string parameters does cause the code to change. Depending on the setup of our code, it might even expose what database we’re using. If it’s MySQL, they can get crafty and do something like this:

That little OR 1=1 bit will cause the SQL server to return all of the data in the user’s database. Let’s take this a step further, and say that we are authenticating a user. Most of the examples would look like this:

We’re doing one thing correctly (forcing this data to come through the POST array), but we’re still not really validating that $username or $password are actually good valid values. We can still do the following:

We’re in, and as a user where we didn’t even know the password. Why? The -- will comment anything after it, so we dropped the AND password= portion of the SQL and do the select based on just the username. It will return a single value just like the code will expect, so your code never knows that it was altered.

Both of these attacks are called “SQL Injection Attacks”, and is part of the OWASP Top 10’s #1 attack vector. The sad thing is that these are really easy to combat against. I see all the time on Reddit and Stack Overflow people asking for help and seeing this same sort of code. In 2013 we should have been able to stop this, but with years of old tutorials out there it is an uphill battle.

The reason that it sad to see this as still the #1 attack on OWASP is that it is easy to combat. The first and foremost is to stop using the mysql_* functions in your code. The module that handles those is old, and it doesn’t support the best way to handle SQL injections. Yes, it has mysql_real_escape_string(), but that relies on the developer remembering to use it. Better security comes from the developer having to not remember to do it and it just being built in.

Since PHP 5.0, PHP has shipped with something called PDO. PDO is a database abstraction layer that makes it easier to write cross-database code. If you write your app for MySQL, you can more easily port it to something like Postgres or MSSQL by doing nothing more than changing the connection parameter (assuming you haven’t written any engine specific code like using LIMIT, which MySQL and Postgres support but MSSQL doesn’t).

PDO has another big advantage in that it has support for something called a Prepared Statement. With a prepared statement, the SQL query is parsed by the engine by taking a SQL statement and a list of parameters and putting them together itself instead of relying on a fully built SQL statement. This becomes much safer because the DB engine does all the work on properly quoting the values coming in. The side effect of this is that the worry about the developer being safe is offloaded somewhere else, so by using PDO and prepared statements the developer doesn’t need to worry about if a parameter has been sanitized.

Let’s go back to our first example, with the $_GET parameter. What would this look like with PDO?

It’s a bit longer, but not so much that that there is a ton of extra work involved. What we did was create an SQL statement using placeholders, which in PDO can either be a ? or named like our example, which was :id. We run our SQL through the prepare() method on our PDO connection, which returns a statement object. This statement object gets executed, and at the same time we pass in the values for our placeholders. We can then get the user by calling the fetch() method on the statement.

We can rest assured that the SQL code is now safe from injections. That’s it! That is the single most effective way to combat SQL injections.

For older legacy applications switching out to PDO can be a major undertaking. Drupal did this in Drupal 7, where they replaced their underlying database abstraction layer to use PDO. Drupal didn’t use the database specific functions all over the codebase which made it somewhat easier to swap out, but if your application is riddle with calls to mysql_* or pg_* functions you will want to replace them all with PDO commands.

Do your part to help clean up the bad examples out there. If you ever do new code, use PDO. If you ever give examples, do it using PDO. Maybe we can make the internet a little better, and help knock SQL injections (and other injection types) off of the top of the OWASP Top 10.