Patrick Schwisow

Temporary Composer Changes During Development

Most Composer documentation and tutorials focus on how to use it when your dependencies are (relatively) stable and your “main” project is under development. This is certainly the most common use case, but you’re pretty much left to figure it out yourself if your workflow doesn’t fit these parameters. As a contributor to Phergie, I’ve worked in a very different flow, where the “main” project only contains composer.json and config.php (see Phergie documentation for users). The code for the bot, the underlying IRC client, and all the plugins comes from separate repositories and is installed by Composer. Doing development on these dependencies can be simplified with a few different Composer strategies.

Normal (Production) Configuration

Let’s start with the normal, traditional use of Composer as a baseline.

{
  "require": {
    "phergie/phergie-irc-bot-react": "~1",
    "phergie/phergie-irc-plugin-react-commandhelp": "~1",
    "phergie/phergie-irc-plugin-react-joinpart": "~1",
    "phergie/phergie-irc-plugin-react-pong": "~1",
    "pschwisow/phergie-irc-plugin-react-puppet": "~1"
  },
  "require-dev": {
    "phpunit/phpunit": "4.1.*",
    "phake/phake": "2.0.0-beta2"
  }
}

This is a very basic setup with a minimal set of plugins. Realistically, you’ll have many more plugins, but all the lines will look pretty much the same. Even when we employ different strategies for some dependencies, most of your dependencies will continue to be “normal” entries as shown above.

If we wanted to do work on pschwisow/phergie-irc-plugin-react-puppet, we could check out that repository (as a separate project) and commit changes on a branch. For example, to test a bug fix committed on fix-critical-bug branch, change that line to "pschwisow/phergie-irc-plugin-react-puppet": "dev-fix-critical-bug" and run composer update.

Limitations:

  • All packages must be submitted to Packagist.
  • All changes must be committed and pushed to GitHub before testing.
  • Branches to be tested must be on the same repository as registered in Packagist. (You cannot test changes in a fork of the official repository.)

Non-Packagist Repositories / Overriding Repositories

If the package you want install is not in Packagist (because it’s new) or you want to override the version in Packagist to use your own fork, you can specify the location of the package in composer.json. If we wanted to use a fork of phergie/phergie-irc-bot-react with changes from the standard version, your composer.json might look like:

{
  "require": {
    "phergie/phergie-irc-bot-react": "dev-my-branch as 1.3.0",
    "phergie/phergie-irc-plugin-react-commandhelp": "~1",
    "phergie/phergie-irc-plugin-react-joinpart": "~1",
    "phergie/phergie-irc-plugin-react-pong": "~1",
    "pschwisow/phergie-irc-plugin-react-puppet": "~1"
  },
  "require-dev": {
    "phpunit/phpunit": "4.1.*",
    "phake/phake": "2.0.0-beta2"
  },
  "repositories": [
    {
      "type": "vcs",
      "url":  "git@github.com:PSchwisow/phergie-irc-bot-react.git"
    }
  ]
}

Take note of the use of “as 1.3.0” in the requirements for the bot. This is an alias that tells Composer to treat the installed version of the package as 1.3.0 for the purposes of satisfying other dependencies. If (for example) phergie/phergie-irc-plugin-react-pong requires “~1” of the bot, Composer will be unable to resolve the dependency tree. (You cannot simultaneously install multiple version of the same package.) Aliases are often necessary to avoid these problems when you modify one part of a set of interdependent packages. I chose 1.3.0 specifically because it was the version that was installed prior to these changes. You can check composer.lock to determine the currently installed version of any dependency.

Problems Solved:

  • Packages no longer need to be submitted to Packagist.
  • Branches can reside in any repository you can reach.

Limitations:

  • All changes must be committed and pushed to GitHub before testing.
  • When overriding existing dependencies, you are responsible for ensuring the code loaded is compatible with other dependencies.

A Development Approach

The strategies shown so far require changes to be committed and pushed. In the case of new development or debugging efforts, this may not be desirable. If you want to avoid pushing incomplete code or temporary logging statements, you may want to run the latest local version of a dependency. While you always have the option to change files inside the vendor folder, this can get “messy” and has the disadvantage of not including dev dependencies on the package you are working on.

You can avoid these complications by keeping a separate copy of the package you are working on outside of your “main” project. For new development, this code need not even be under version control. (To clarify, I’d recommend you start using your VCS locally from the beginning of a project, but this is not strictly necessary and you certainly do not have to push to a remote repository at the earliest stages.)

As an example, let’s say we’re creating a new plugin “Foo” that resides in /home/pschwisow/code/foo. Rather than add it as a Composer dependency, we can add an autoload section so that Composer’s autoloader can load the classes from their current location.

{
  "require": {
    "phergie/phergie-irc-bot-react": "~1",
    "phergie/phergie-irc-plugin-react-commandhelp": "~1",
    "phergie/phergie-irc-plugin-react-joinpart": "~1",
    "phergie/phergie-irc-plugin-react-pong": "~1",
    "pschwisow/phergie-irc-plugin-react-puppet": "~1"
  },
  "require-dev": {
    "phpunit/phpunit": "4.1.*",
    "phake/phake": "2.0.0-beta2"
  },
  "autoload": {
    "psr-4": {
      "PSchwisow\\Phergie\\Plugin\\Foo\\": "/home/pschwisow/code/foo/src"
    }
  }
}

The same approach can be used for existing packages if you have a separate copy (outside the vendor directory) by just adding the autoload section as shown above. (Autoload directives in your “main” composer.json override what is declared for the same namespaces in the dependencies’ composer.json files.) Once the need for these temporary measure have passed, you should switch to one of the earlier strategies as a more permanent configuration.

Problems Solved:

  • Changes need not be committed / pushed to GitHub.

Limitations:

  • When overriding existing dependencies, you are responsible for ensuring the code loaded is compatible with other dependencies.

Consolidating Doctrine Migrations

Doctrine Migrations are a great way manage changes in your database structure, but over time migration files can pile up and turn into an unmaintainable mess. Migration usage is well-documented, but developers are left to their own devices when it comes to long-term maintenance. This article outlines a process to clean-up the mess and start fresh with a new base migration with minimal impact on existing database instances.

Note: This article was originally published in the March 2015 issue of php[architect].

Read the rest of this entry »

Farewell to php[tek] Chicago

At the close of php[tek] 2015, Eli White announced that tek would be moving to St. Louis in 2016. While I admit that this seems to be the right thing for the conference, I am saddened by the news. I have been lucky to have such a great conference right here in my hometown, and I will miss it. It feels like something is coming to an end, and I cannot help but look back at what it has meant to me.

php|tek 2011 (back when it used the pipe character in its name) was my first PHP conference and my first introduction to the great community we have. As an introvert in a new environment, it was somewhat difficult to open up and connect with people, but I joined Twitter (as that’s where everyone seemed to be) and sidestepped my insecurities to begin to forge some great friendships. The first person I met (other than the organizers) was Matthew Turland, and now I count him as one of my closest friends. So many others from that first year have become my network of friends. That is who I think of as “the community”. I have only added on to that, and so many I have met in person for the first time at tek.

tek gave me my start at a conference speaker. First by wisely rejecting me when I was not really ready in 2012, then by giving me a shot to take the stage in 2013. As a nervous first-time speaker, I made it through, but I always expected I’d be back again with a good dose of additional confidence and experience. I’ve spoken at other conferences, and I will continue to do so, but none will be the conference rooms I know so well.

There are the constants of tek… the faces I saw every year: Beth Tucker Long, Michelangelo van Dam, Ed Finkler… And the little things that were so entertaining and memorable: Sara Golemon throwing balsa gliders and then pretending to have nothing to do with it when one hit an unsuspecting attendee, the time that I “stole” Keith Casey’s bag and “held it for ransom” to get a conference patch, a well-timed escape to go eat cookies with Elizabeth Naramore and Ed…

So many firsts for me: first PHP conference I attended, the first time someone I had never met in person recognized me and sought me out to meet me, first conference I spoke at, first conference I have worked at (as a volunteer). Certainly you cannot go back and have those firsts again, but it was so comforting to know that I could always go back. After 5 years of tek, it felt like a kind of home. It’s time to move on, but tek will always be special to me. I hope to be able to attend tek again in it’s new home next year, but I know it will not be my tek.

Farewell, and thank you for giving me my start in this great community. You will be missed, php[tek] Chicago!

The End of an Era

After nearly five years at OpticsPlanet, my time there has come to an end.  Moving on has made me reflect on all the learning and growing I’ve done in that time.  Not only was I fortunate enough to work with a lot of amazing people, but I also joined the larger PHP community during this time.  It was great for me and my career.  Here are a few of the things that made an impression on me during this time.

The Team is Greater than the Individual

A software developer can accomplish a decent amount on his / her own, but working as a team is a natural force multiplier.  If a team of six developers is working effectively, their combined output will be greater than the sum of what each individual could achieve alone.  Conversely, a team with serious problems may find that they are producing less than the sum of the individuals.  Building and managing teams effectively is the only way for an organization to truly scale.

Everyone has a Valuable Role to Play

Not everyone within a team comes in with the same skills and abilities.  A junior dev cannot accomplish the same things in a day that a senior dev can accomplish.  A back-end developer cannot do the same things that a front-end designer can do.  Specialized roles like Product Owners and QAs probably don’t write code at all.  Just because everyone cannot do the same thing does not mean they are any less valuable.  Each member of the team contributes in whatever way they can to maximize the team’s accomplishments.

The same holds true for the organization as a whole.  A marketing person cannot write software any more than I can plan an effective marketing campaign.  We should respect each other’s efforts and recognize that everyone is valuable.  The organization would be less effective if any individual were removed from it.

Workflow and Standards Ensure Consistency

The key to building software with consistent quality in a predictable amount of time is to create a process optimized for these things.  Determine an appropriate workflow for your team that ensures every issue that is worked on meets the requirements and does not introduce additional bugs or technical debt.  Create standards so every developer must meet the same minimum requirements with all the code they write.  Identify any problems with the process and make adjustments to address them.  If there are too many problems that make it to production, increase efforts in code review and testing.  If parts of the process are too time-consuming, look for ways to automate.

The results of the team’s work also depend on outside factors, so these must be considered as well.  If the team accepts work with poorly written requirements, it is impossible to determine what should be built and how long it will take to build it.  If additional requirements can be added at any time, scope creep kills forward momentum.  If the team develops and tests in an environment that does not closely match production, it will be difficult to avoid “production-only bugs”.

There is a Larger Community Out There (and You Should Be Part of It)

Prior to attending php|tek 2011, I vaguely knew there were people out there working on open-source projects.  During and after tek, I came to realize that rather than a bunch of disparate project teams, there is a great and thriving community out there.  (Or more accurately, there are hundreds of communities that all overlap and for “The PHP Community”, which itself overlaps with other software communities.)  Being part of the community is an awesome thing.  It provides technical advice, insight into new and upcoming technology, professional mentoring, career networking, and oftentimes friendship.  Be active in whatever way fits you best: Twitter, IRC, conferences, local user groups, open source projects, or any combination of these.  It will help advance your knowledge and your career, and it helps keep you passionate and engaged as a software developer even when your day job starts to get you down.

Find Your Professional Needs and Wants

As I have progressed from junior to mid-level to senior and then to team lead, I came to recognize the things that I am passionate about and what makes for a good or bad work environment for me.  I want to always strive to create the best quality software that I can.  Bugs bother me, especially when I discover that the bug was something that was avoidable (with better review or testing before code goes to production).  Technical debt is a reality of all software projects, but we should always be making efforts to track it, avoid it (unless there is reason we choose to incur it), and make it a priority to pay it down.  These are my own professional needs, and I could not work in an organization with values that conflict with them.  I also want things like continuous integration, automatically enforced coding standards, and automated deployment processes, but I am willing to compromise on my wants.

Everyone’s professional needs and wants will vary, but you should identify them and take steps to see that they are being met.  If you do not pay attention to them, you may find you are in a job that makes you miserable with no idea what needs to change.

The Next Chapter

I have accepted a position with POLITICO.com and look forward to working with the awesome Samantha Quiñones starting in a few weeks.  It’s exciting and terrifying to move on.  I am very optimistic about the new adventure, and I am absolutely certain that I will learn and improve in the process.

Don’t Be a “Chet”

I recently read Ashe Dryden’s brutally honest indictment of the tech community, We deserve better than this. (If you haven’t read it, do it now! I will wait…) I am not completely naive to the fact that women in tech face many additional challenges, but to me this has always seemed like a distant problem. I have never personally witnessed any of these egregious acts, and this led me to believe that it’s not happening in my community (the PHP community). Thanks to Ashe, I now realize that I have been making a lot of foolish assumptions and overlooking signs that all is not well in the community that I love. I can’t afford to continue believing that the problem does not exist or is “not that bad”.

Ashe’s post sparked a lot of discussion and provoked a wide range of reactions. Many were positive and supportive (most notably, Aaron Vegh’s), but unfortunately some people attempted to play down the issue or even attack Ashe. I will not mention any of these negative replies specifically because they’re honestly not worth reading.

As for my own reaction, I will attempt to persuade you to be a part of the solution not part of the problem, and I will show you how to do it.

Don’t Be a Chet!

I originally planned to entitle this post “Don’t be an Asshole”, but instead of repeatedly throwing that word at you, I’ll only write it once. I am substituting Chet, the obnoxious brother from Weird Science, a thoroughly unredeemable character who took every opportunity to be unpleasant to everyone he interacts with. For those who have seen the movie, I think you’ll find that he is a suitable equivalent. No one wants to be around him, and no one wants to be like him in any way.

How to Avoid Being a Chet

It’s really not that hard to avoid being a terrible person. Just think about what you do and say. If you think something you say is likely to be interpreted in a negative way, don’t say it. If your actions might make others uncomfortable, don’t do them. Humans have reason and self-control. Use them!

It’s fairly easy avoid offending someone with the same sensibilities as yourself. Consider who you’re speaking to and also who else will hear you. Empathize. Consider what you know about the other people and how well you know them. With people you know well, you likely know where to draw the line. For people you don’t know, err on the side of caution.

Also consider your current setting. While your friends may enjoy your sense of humor over drinks, they probably don’t want you cracking jokes while they’re trying to listen to a conference talk. (Well, maybe they do; you know your own friends better than I do.) On the subject of conferences, people generally attend in order learn and network with their peers. With very, very few exceptions, they did not come to the conference to “hook up”. Keep it professional!

Tolerating Chets Makes You One Too

All it takes for the Chet-culture to survive is for good people to let it exist. If you see or hear something that you think is offensive (or even suspect could be offensive), do not stand idly by. Either call the Chet out for this behavior, or report it to the appropriate authority (a boss, human resources, conference organizers).

It doesn’t matter if you are the (potentially) offended person or just a witness. Stand up for what’s right! Victims have it hard enough. They shouldn’t have to face it alone.

D’oh! I Was a Chet. What Can I Do?

Even with the best intentions, you will cross the line at some point and say or do something that offends or annoys another person. Due to misunderstood sarcasm and overly stubborn debating, I have found myself acting like a Chet on several occasions. In some cases, I have been fortunate to have a friend call me out on it. In other cases, I inadvertently burned some bridges.

When you realize you’ve been a Chet, apologize! It may not have been intentional, but suck it up and say you’re sorry. If you’re lucky, you will be forgiven and there will be no permanent damage. If you’re unlucky, you might not be forgiven. There’s not much else you can do about it. Perhaps it will take some time, or maybe you have permanently lost a friend. You’ve made your bed; now you must lie in it.

Zero Tolerance… FTW!

It is possible to be a Chet to anyone: man, woman, child, animal, etc. Though I personally find certain types of Chet-ness to be particularly egregious, this type of behavior is unacceptable in all forms. Your behavior has consequences. It can hurt other people, it can hurt your reputation, and it can close a lot of doors for you. If you don’t care about these things, you may be a sociopath, and you should seek professional help.

If we work together, we can squash the scourge of Chet-ness out of existence in our community. Don’t tolerate it! Speak up if you see it. If you let this behavior go unchecked, it will silently grow in the shadows and pop up more and more frequently.  Let everyone know this is NOT ACCEPTABLE! Either the Chets must change their ways or they will no longer be welcome here.

Response to “On Visibility in OOP”

I just read Matthew Weier O’Phinney’s On Visibility in OOP.  Aside from being an excellent and easy to follow explanation of public / protected / private / final in PHP, MWOP’s experiences dealing with private and final in framework and library classes somewhat echo my own.

In the example he presented, he was unable to extend and improve Doctrine\Common\Annotations\DocParser due to the fact that it has private members and is marked as final. This proved a significant roadblock to interoperability between Zend Framework 2 and Doctrine 2.

In my case, I also encountered a roadblock in Doctrine 2, but for me it was a block to testability. Doctrine\ORM\EntityManager is marked as final, and while I understand the reasoning behind the statement “this should not be extended”, I would propose that in the case of creating tests, this reasoning no longer applies. To allow the flexibility necessary to create effective tests, it is frequently necessary to extend a class in order to create a mock or proxy. If the class in question is final or makes most of its inner workings private, we must resort to overly complex and less realistic methods to create tests for code that touches it.  This in turn decreases the chances that our tests are actually covering the cases we intend them to cover and increases the chances of false positives and false negatives from the test suite. In short, we’re forced to choose between “hacking” someone else’s code to change visibility or creating very brittle tests.

Interview on Voices of the ElePHPant

When I was at php|tek 12 a few weeks ago, I had the pleasure of recording an episode of the Voices of the ElePHPant Podcast with The Cal Evans. The episode published today, so I guess I’m now #internetfamous. In all honesty, I was pretty nervous about it, so I’ll be listening along with everyone else to hear what I said. I know I talked about PHP User Groups, Community, and Conferences.

One thing I intended to do was thank all the wonderful sponsors who helped Lake / Kenosha PHP get off the ground with the generous donations of “swag” for the new members.  I’ll take the time to thank them now:

Thank you all for your generous support of of the community, and thank you also to the other companies who generously provided the next round of giveaways for LKPUG and many other user groups at php|tek this year.

Post php|tek Resolution

This year’s php|tek was my second, and it was a great experience. (More about that in later posts.) After tek11, my steps into the community were joining twitter (a small step) and founding a local PHP User Group (a much bigger step). This year’s plan:

And here is the blog in question! I have now fulfilled the first half of the resolution; now to write something other than “random crap”. Well, maybe next time…

 

Follow

Get every new post delivered to your Inbox.

Join 706 other followers