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

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 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 ( 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 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 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:


  • 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.

Process Oriented vs Product Driven

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.

I don’t understand the 9-to-5

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 ( and, 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

How long is too long (for unit test method names)?

As I ws working on some new development in our codebase this morning, I started updating some
unit tests to match. I was looking through the code for one of them and came across a test name that was easily 50 characters long and
it got me wondering – what was the popular opinion on naming conventions and commenting in unit tests. Obviously, there’s some things
(like annotations) that have to be in comments, but do you sacrifice clarity of a comment for a method name that you can basically read
like a novel?

I mentioned something on Twitter about it and here’s some of the responses I got:


Rafael Dohms (rdohms)
@enygma @elazar @bdeshong taking into consideration PHPUnit and its use of method names (like testdox) i would focus more on name not doc
2 hours ago

weierophinney (weierophinney)
@enygma I don’t document my tests; the test name and test content *are* documentation. /cc @elazar @bdeshong
2 hours ago

weierophinney (weierophinney)
@enygma I do those all the time. For use with #PHPUnit’s testdox output. 🙂
2 hours ago

Ralph Schindler (ralphschindler)
@bdeshong @elazar @enygma if you are using PHPUnit, run the tests with –testdox, you’ll see the benefit of long test names 🙂
2 hours ago

Chris Cornutt (enygma)
@mwillbanks ah, good point…I can see how that’d be handy heh

Mike Willbanks (mwillbanks)
@enygma putting it in a docblock is nice, however, when running it on a CI server it is nice to see what broke by method name and test name
2 hours ago

Mike Willbanks (mwillbanks)
@enygma I think we have one that is almost 100 characters 🙂 here is 1 example: testEditActionRedirectWhenJournalEntryNotFound
2 hours ago

Brian DeShong (bdeshong)
@enygma @elazar 120 characters? 🙂
2 hours ago

Michael Maclean (mgdm)
@enygma around the 100 character mark? 🙂

2 hours ago

Chris Cornutt (enygma)
@elazar @bdeshong ah, but where should method names end and docblocks begin? 😉

Brian DeShong (bdeshong)
@enygma If the method name is long, but descriptive, then that’s good. Descriptive test method names are better than short ones.
2 hours ago

Matthew Turland (elazar)
@enygma Better to be verbose and accurately descriptive than overly concise and obscure? 😛
2 hours ago

jcarouth (jcarouth)
@enygma Hey, I’ll take that over testApp1() and testApp2() any day.
3 hours ago

Chris Cornutt (enygma)
well hello entirelyTooLongUnitTestMethodName, nice to meet you
3 hours ago


That last one was my not-so-innocent comment that started the whole thing off. I’m still interested, though, in what developers
out there think is a good point to switch from documenting via the test functions name and moving it up to a docblock comment. Seems
like there’s arguments for both sides and I’m not sure if there’s a “winner”, but it’s always fun to get opinions.

What are your preferences in unit test naming versus commenting?

Using Models in Fuel

In my previous post on using the Fuel framework I looked at the basics behind getting a site up and running. This time I want to take it a step further and tell you a bit about my experiences getting a Fuel application to talk to a database (in my case MySQL). To learn the process, I fell back on one of my standby sites that’s been rewritten in a few different frameworks now including Solar and a really, really old version of the Zend Framework. It’s not an overly complex site, but the version is starting to show its age. So, I usually take that as an opportunity to rewrite the site in something different, just for the experience.

I’ve already started on a version with the latest download of Fuel and, as a part of it, explored the database model connectivity feature. Now, all of this code is generated from me just looking at the source (since there’s no docs to speak of *cough*) so there’s probably a better way to do some of this that I don’t know. So, lets get started with a basic model.

In my database, I have a few tables – two of them are the “news” and “news_tags” tables. The relationship between the two is news.ID -> news_tags.news_id. Thankfully it works out that this is the default mapping for the relationships between the models. More on that later though…here’s my sample SQL:

create table news (
news_title VARCHAR(200),
news_story TEXT,
date_posted INT,
create table news_tags (
news_id INT,
tag_name VARCHAR(50),

Let’s start with the model files – one for each of the tables. Here’s the basic structure of the file:

namespace FuelAppModel;
use ActiveRecord;

class News extends ActiveRecord/Model
// define a sample method
public function getLatestNews()
$results = $this->find(‘all’,array(
‘select’ => array(‘news_title’,’news_story’,’date_posted’,’ID’),
‘limit’ => 10,
‘order’ => array(‘date_posted’,’desc’)
return $results;

This is enough for Fuel to now know about the “news” database table. Obviously, you’ll need to have the database connection information correct in your db.php to connect to your instance. A few things to note here – the namespace loads in the base Model functionality so the News class can extend the ActiveRecord bits it needs. The ActiveRecord functionality is contained in a package in the standard Fuel download.

In this model, I’ve defined a simple function to pull out the latest news from our “news” database table. This uses the “find()” method that comes with the ActiveRecord stuff. That first parameter can be one of a few things.

  • An ID number of the record you’re looking for
  • The string “all” to return all matching rows from the where
  • The string “first” that essentially puts a “limit 1” on the end of the statement

The second parameter sets up the rest of the SQL statement – the “select” array lists the columns to fetch, the “limit” restricts the results and the “order” allows you organize the results by a column. There’s also “offset” and “where” that can help get it more specific. The results are then returned back from the method. If you’re more in the “heavy controller” camp and want to do more complex stuff in there, you can also make a model object inside your controller:

namespace FuelAppController;

class News extends BaseController
public function action_index()
$News = new FuelAppModelNews;
$results = $News->find(‘all’,array(
‘select’ => array(‘news_title’,’news_story’,’date_posted’,’ID’),
‘limit’ => 10,
‘order’ => array(‘date_posted’,’desc’)

This essentially does the same thing. Now, lets talk about conventions for models here. If your table name is one word, it’s simple enough – for the “news” table, the model’s name is “News” and the file in /classes/models is “news.php”. For something a bit more complex like “news_tags”, you name the file “newstag.php” and the class “NewsTag”. Note that it looks for the singular version of things – “NewsTag” even though the table is “news_tags”.

Simple, right? Well, if all you need to do is make basic queries and pull that data back out, you’re all set. You can stop here. If, however, you need something a bit more complex like say, table relationships, keep reading. Sure, you can manually join all of your data together, making multiple queries and looping through endless loops to match things up. If you want to save some time you can use the table relationships build into Fuel to do the work for you. There’s currently three different kinds – belongs to, has many, and has one. For the sake of example, I’m only going to show you a “has many” example on our “news” to “news_tags” tables.

Setting up the relationship is super simple. In our News model, we’re going to set a new class property to tell the framework about the relationship:

namespace FuelAppController

class News extends BaseController
public $has_many = array(‘news_tags’);

public function getNewsDetail($newsId)
$results = $this->find($newsId,array(‘include’=>array(‘news_tags’)));
return $results;

Don’t look at the “find()” call yet, lets concentrate on the new property. This “$has_many” property lets us define the table names we want relations to. By default Fuel tries to look at the other table for a column matching the [current table]_id pattern. Thankfully, we have one of those: the “news” table’s ID relates to “news_tags.news_id”. Works like magic! Additionally you can also define other parameters to manually specify things like the column name to map to.

Okay, let’s look at that find now…we have our relationship defined to the other table, but Fuel knows we might not always want to include that data on every call. To let it know when to pull the news_tags data in, you have to specify it in the “include” parameter of the find() options. When the query runs and the data’s returned, you’ll have the news_tags data in $results->news_tags for your consumption.

There’s one slightly tricky thing that I came across when working with the model features. When it tries to do the join, it looks at the name of the model class it’s trying to use and pulls the name from there. In our case “NewsTag” isn’t the right name for the table. You can however define the table’s name in the $table_name property of the model, but that didn’t seem to cooperate either. It looks like the fault lies in this chunk of code in the “hasmany.php” extension of the ActiveRecord component, around line 212:

$dest_table = AppInflector::tableize($this->dest_class);
$source_table = AppInflector::tableize($this->source_class);
$source_inst = new $this->source_class;
$dest_inst = new $this->dest_class;
$columns = $dest_inst->get_columns();

In the above snippet it tries to run the “tableize” inflector on the model class’ name to pull out the table. In our case, though, the names don’t match and unfortunately the join() method doesn’t seem to care about the $table_name value and just keeps going on its merry way. It’s a pretty simple fix, thankfully:

$dest_table = (isset($dest_inst->table_name)) ? $dest_inst->table_name : $dest_table;

With this defined, you can tell it that “$table_name = ‘news_tags’;” and it’ll respect it.

For those used to the more object oriented method of models, there’s also the usual CRUD methods you can use to manipulate the objects:

  • save()
  • update()
  • destroy()
  • and, of course, the find() call

I hope this was helpful and like I said, I’m sure there’s a few things that I didn’t get quite right just because I was fishing through the source to figure them out. I’ve been working on some simple templating for the site, so maybe I’ll write up a post on that next. As always, please point out my mistakes 🙂 That’s the only way to learn!

One ToDo list to rule them all?

Okay, so _ I’m going to put this out there so I can get some feedback. I’m looking for a good To Do list manager with a few criteria:

  • I’d love for it to have desktop software that would sync with the site (or some other resource) and allow me offline access to the lists
  • It needs to be able to prioritize items
  • It should definitely allow main and sub-categories (one level of categories? that’s crazy talk)
  • The desktop software would need to be cross-platform (pc & mac) – maybe an AIR client?
  • Bonus points if it allows sharing between users or just public access to the lists (RSS?)
  • Mobile support is cool, but not required

I like the simplicity of some of the tools out there, but none of them seem to meet what I’m looking for. Is there anyone out there that’s come across something like this? It’s driving me nuts that there’s not one that’ll fit my needs.

A Partial Review of “Test-Driven JavaScript Development”

So ever since the fine folks at Addison Wesley sent over a copy of Test-Driven JavaScript Development (by Christian Johansen) I’ve been trying to wrap my head around a new sort of testing when it comes to web apps. I’m not even half-way through the book and I’ve already had my mind blown by advanced javascript and testing methods that I just never thought about when I work on my frontends.

I’m a big fan of unit testing and promote it whenever I can – not only does it help create a code base that a better quality, but it also lets you keep things consistent. No more of the “cross your fingers” kind of coding. A good, well-written set of unit tests can save you a whole world of hassle in the long run. Taking it one step further, you get to TDD (test-driven development) where you write your tests before you even write your code. You start with the usual “W”s – why, where, when, how (yes, I know that last one’s an “H”s) and develop the test for those rather than looking at a current chunk of code and testing what it already does. There’s some people that swear by it, one of them being the author of this book.

He starts with an introduction to TDD and a general how-it-works with javascript quickly followed by an introduction to his tool of choice – JsTestDriver. All of the test examples in the following chapters are run with this tool. Thankfully it’s simple to set up and even easier to write tests for. He shows some introductory tests to help you get familiar with things before diving into the next section – testing javascript itself.

I have to admit, this section left me at a loss for words. I thought I knew a good bit about how javascript works, both out in front and behind the scenes. I was surprised, however, just how much of the functionality he tested I had no idea worked that way. It’s pretty in-depth, so if you’re a beginning javascript dev, you might go read some more tutorials before diving right in.

I’m just now getting to the “Unobtrusive Javascript” part of the book (Part 2, Chapter 9) so I still have a ways to go, but each page is enlightening, especially for some one like myself that’s has a primary focus on backend work and unit testing. I’d definitely recommend this book to anyone looking to get into testing their frontends – it’s a great resource and can probably teach you a thing or two.

I’ll try to put up another post when I get closer to the end – it’s hard to find time to sit and read these days, but just little nibbles at a time work just fine.

Are You an Olympic Developer?

The Olympics have just started and I can’t help but look at those competing and liken them to the development work so many of us do. What’s the same, you ask? How could an international sporting event of the best of the best possibly connect with the work we do behind our keyboards? It’s simple – it’s all about being the best.

Olympians work most of their lives (if not all of them) trying to become the best at their sport that they can be. Some of the figure skaters have even been paired since they were little kids and know each other’s moves as if they were their own. They have honed their craft down to the point where they know in the first thirty seconds of a routine or race how well it’ll turn out in the end. They know the result because they know themselves. They’ve worked hard to get to where they’re at and they know that to compete on this new level, they’ll have to step things up and do even more than their best.

It’s easy to see how this relates to us, the software developers (or managers of these developers) all over the world. There’s no excuse for you to not look at things on a more global scale and try to be the best you can possibly be. Sitting in your chair and being comfortable in the knowledge you learned five years ago isn’t enough. Don’t lull yourself into thinking that, just because you know your current codebase, you’ve done all you can. Get out there, look at what other developers are doing and hone those skills. There’s tricks that you can learn from the best and tools that you can use to hone your own development work into a razor sharp edge that can cut through any problem and push you up into that next level of development.

Who knows…you might just find something you can apply that could make you and your development soar to new heights and help you feel the rush that you did when you were first learning a language – flying headfirst into the unknown, unsure about what was to come and where you might land.

Don’t be afraid. Take the risks. Become the best you can be.

Adventures in Git (Merging)

Starting out with a new version control system is always a unique experience. Half of your time is spent crossing fingers and hoping that you didn’t just cause irreparable damage to your repository and the other half is time spent pouring over manuals and Google results to try and get just the right commands so that the worst case (hopefully) never happens.

For a little bit now, I’ve been playing with git (due to my pet project, being moved and open sourced over on github. It’s a different sort of experience than I’m used to coming from a CVS and SVN world where there’s one server and everything you do goes through that. Git’s different in its distributed nature and it takes a bit of getting used to – some of the core concepts are a bit different since, essentially, your clone is a full copy of the repository (and is a repository all to itself). It’s a little strange and I don’t think I fully have a handle on it yet, but I’m getting (gitting? yeah, had to throw in a pun somewhere) there.

In the meantime, I came up against something today I hadn’t had to deal with on the project. Previously, the source was on a SVN server hosted on another machine. I had some other developers working with me on it while I was over there, and most of the changes were pretty easy to integrate with few conflicts. I’ve gotten used to handling merges in SVN, but since git’s “total repo” method is a good bit different than SVN’s approach, it took a little doing to figure out how to merge in changes from a forked repository on github and integrate them back into the master. I (finally) got it to cooperate so I wanted to share the steps I took to get it working. I know this isn’t the only way to make the merge happen, and probably isn’t even a true merge, but it got the job done.

In this example I’m going to be merging changes from Lorna Mitchell’s fork of the code back into the main line.

First off, for the impatient folks in the front row, here’s the full list of commands:
mkdir lorna
cd lorna
git init
git remote add lorna git://
git remote add joindin
git pull joindin master
git checkout -b lorna/master
git pull lorna master
git add path/to/file.php
git checkout master
git status
git commit -m’Merging in the changes from the fork’
git push –dry-run –repo=joindin
git push –repo=joindin
ul.mlist li { margin-bottom: 6px; }
Want a bit more? Alright – here’s the explanation for the steps above:

  • Start with an empty directory: You don’t have to do this, but it made me a bit more comfortable to keep things out of my working copy.
  • Go into the directory and make it git-controlled with the “git init”
  • Set up some aliases: This just makes things easier to refer to down the line. In this case we’re setting up aliases for the “joindin” and “lorna” repositories to point to the remote sources on github
  • Get the main line of code: Do a pull to get the master line of code from the joindin source
  • Create a branch: When you use the “checkout” command for git, you’re moving between branches. In this case, the “-b” flag tells it to make the branch too since it doesn’t exist. Our new “lorna/master” branch is created.
  • Pull in Lorna’s code: With the new branch in place, we can pull down the fork’s code and push it into the branch (the master line from her fork). This is where the fun starts. If you have conflicts that pop up, this is where you’ll see them. They’re easy to fix, though – the technique’s similar to other version control systems and you basically just delete what’s wrong.
  • Add the fixed files: There wasn’t a “resolved” command like SVN has that I could see. The only thing I saw was to “add” the files back into the commit once they’re ready to go.
  • Switch back to the master: Move back over to the master branch (of the “joindin” repo) by doing a checkout on it
  • Check your status: Use the “git status” command to see what’s going on and if there’s anything else that might need to be done before the commit.
  • Commit!: You’re ready to commit the changes to the master branch. Issue the commit and fire away. Remember, this is all local until you do the push, so if something freaks out, you can always start over.
  • Now push!: If all went well, you’re going to end up with an integrated version of your repository and you’ll be ready to push. The “git push” command also has a –dry-run option use can use if you want to check before you make the leap. The –repo option is used to defne which repo you want it applied to.

So there you go – it’s a little tricky, but not too bad once you know the steps. This was just a simple merge, so I know there’s more to it in the future, but I suppose I’ll work on that when I get there. Hopefully this helps someone out there!

Is it a Developer’s Responsibility?

Last night, several of us were treated to a dinner as a part of this year’s Microsoft Web Developer Summit (great dinner, by the way – Anthony’s in Kirkland, WA). Seems like there was just about a one-to-one ratio at one point of MS employees to PHP developers attending. It was interesting to see how this played out in conversations and in the general flow of the evening.

At the table I was sitting at there was a MS rep from the Windows team, Ani, who was pleasant, engaging and genuinely seemed interested in what “this PHP thing” was all about. Some of her questions could have been answered by a few trips to Google, but overall it was good to see the interest level from someone not in the usual web bubble PHP normally operates in. There were a few great debates that came out of her questions with the most memorable being about SEO. She had asked about our take on it and if it even played a part in the work that we did. Most at the table were of the opinion that, if it’s going to happen, it was someone else’s job – the responsibility of the front end folks as a part of making the site “pretty”.

This and another comment about application structure got me thinking…with a lot of the sites out there going with an MVC pattern for their structure, does this mean a sort of SEO-friendliness is already built in? I’m not talking that black magic, voodoo stuff that lots of firms pass off as SEO consulting. I mean the good placement of data, good content and a well though out site structure. By default, MVC makes this last one super simple. For most frameworks, it’s just a built in part of their routing to make search-engine friendly URLs. Of course, it’s still up to you to fill those URLs with good meaningful content, but it’s a start.

So, do we as developers still have a responsibility to create an application that will, in the end, make more sense to the outside world and to the major search engines? Should we step outside of our bubble and branch out into the wider ecosystem of the application, making sure that what we’re doing fits with the whole?