PHP

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, Joind.in 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 Joind.in 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:
[php]
mkdir lorna
cd lorna
git init
git remote add lorna git://github.com/lornajane/joind.in.git
git remote add joindin git@github.com:enygma/joind.in.git
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
[/php]
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!

An Interesting TEKX Promotion…

Thinking about attending a PHP conference anytime soon and looking for an offer that you can’t refuse? Check out this interesting move from the MTA folks (the group that puts on the “tek” conferences each year) for attending the TEK-X conference in the spring. The regular ticket price after the Early Bird pricing time has passed checks in at $1,000 USD per ticket. For this low, low price you get full access to the conference – tutorials and sessions for the full time of the conference. What? You don’t think that’s a good deal? Well, good – because that’s not the deal I’m talking about.

If you’re one of those folks that don’t really care about what the schedule might eventually hold and just want to reserve your spot for the conference, check out this (quite frankly, amazing) deal from the MTAers for next year’s TEK-X conference – sign up before January 6th, before the schedule is announced, and you’ll be rewarded with a 35% discount. That’s a full attendance pass for the whole week for a fraction of the cost – $650 USD. If you were planning on attending the conference anyway, it’s a win win.

There’s only one catch – there’s only 50 of these passes up for grabs so you’ll have to get in quick if you want to snag one, you’ll need to sign up quick. It’s an interesting idea from a group that’s always been keenly aware the pulse in the PHP community. Personally, I think it’s an excellent idea and only reinforces the fact that they know their target audience…PHP community members that are out there to support the community, regardless of the event. It’s nice to see a company putting so much stock in the community itself and not just in the appeal of the discount (not that it’s a bad thing!)

Microsoft Web Dev Summit 2009

See my pics from the event here!

I had the opportunity this past week to go back up to Microsoft for the second year to attend the Microsoft Web Developers Summit. The event brings together a wide range of people related to web development in the PHP community. This year the group was made a bit more diverse because of the inclusion of a few members of some of three communities of PHP-driven applications: WordPress, Joomla and Drupal. It made for a nice mix and, really, for what I think was one of the more interesting parts of the event (but more on that later).

Over the three days we were there, presentations were given from groups all around the company including the Web Platform Installer folks, the IIS team, the SQL Server team and a pretty cool showing from the Bing group on their mapping offerings. Showing off the products seemed to, usually, be a secondary mission for most of the groups though. Out of the number of sessions crammed into each day, most of them were either the PHP community talking to Microsoft (in the form of free-form discussions) or the Microsofters sitting down and really talking with us and asking questions about what we were doing and how they can help us do it better.

In my opinion, these discussions were worth the cost of the whole conference alone. Last year’s conference seemed a bit more chaotic and less structured. There was a lot of miscommunication (it seemed) and several things that we, as a community, weren’t terribly interested in. This year was leaps and bounds over that in terms of both quality and planning. The sessions that weren’t the discussion times were mostly relevant and almost everyone that represented MS seemed to know at least a little bit about what was going on in the world of PHP (with the exception of the ASP.NET folks but really, they sort of have an excuse – they were very happy to get the answers to their questions, though).

Leaders make all the difference in events like this and we had some of the best – our own Cal Evans helped to keep things on task and get the conversation jump started when it needed it, Karri Dunn (the ringleader and organizer) did an excellent job of making sure things were moving along smoothly and that we were able to talk to other groups in the company too (even those not involved in the summit), Josh Holmes (evangelist extraordinate) who has really jumped into the PHP community feet-first and has become one of our key voices back to Microsoft in general and, last but not least, to the leadership within the PHP community – the represenatives from WordPress/Joomla/Drupal, the core developers, the user group leaders and general community members.

A major thank you to all of you (including those I haven’t mentioned that made the event a success) for taking the MS Web Dev Summit up to the next stage in its evolution. I love the direction the event is heading – don’t lose that momentum and don’t lose touch with the PHP community. Last year everyone took their planes home and there was some random communication between MS and us via emails/twitter/etc but most of the connection was dropped. This year there’s already an effort underway to keep those lines open and to make a real dialogue between the web-related groups of each side flow. This, in my opinion, is a real deal-maker. It’s one thing to have a company that brings you up to talk with them for a few days and that’s it. It’s a whole other thing to have one that’s really excited about what’s going on with you and your community and wants to engage you and get input on their next moves.
Web Platform Installer (WebPI). I seriously hope they consider some of the suggestions we gave them as to its future and what we thought could really make it more than it is without sacrificing the simplicity it already has.

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?

The Myth of “Good Code”

There’s an interesting dichotomy in software development – anyone wh has spent any amount of time in the field knows it all too well. There comes a point in every project where you have to make a choice – good code or fast code. Sure, you’ll get those “sweet spot” projects that’ll let you work on the “good code” side of things for as long as you’ll need (maybe a personal project?) but more often than not, you’re going to fall on the “fast code” side of the line. It’s sad, really it is.

Every good developer knows that the world could only benefit from having more “good code” in the world. Applications would not only do what they’re supposed to to but they’d do it well and have better performance while doing it. Things would flow smoothly through the paths the user laid out in the planning stages and everything would be magically delicious. Right? Sadly, even when you have the time to make the “good code”, it’s still not that good.

First off, throw out those personal projects – the timelines of those don’t really apply anyway. You can hack away at a framework you’re developing for years and only get most of the way done with it. Unless it gets some kind of larger following, chances are people aren’t going to be putting the pressure on you to make updates and add new feature. The whole realm of personal project timelines is an interesting one – maybe something I’ll look into later on. For now, though, we’re going to focus on software someone else wants you to write. This is where the major part of the problem is – it’s someone else’s timeline, someone else’s thoughts you’re trying to put into code.

I can’t tell you the number of times that I’ve been working on a project and have hd nothing but the best of intentions of how it was going to turn out. I’d planned out the pieces, worked up descriptions of the objects involved and laid out how they’d all integrate together. The code was well-structured and was something that could be both easy to maintain and simple to expand – that is until the customer decided to get involved.

If you’ve worked on any kind of larger project for any length of time, you know the cardinal rule – the customer never knows what they want. Even when they say they do, show them a demo. Their minds will freak out with new possibilities and new features that were never even conceived of in the first versions you’ve developed. Now, this isn’t so much of a problem if you have the customer/client reined in to keep these sort of things under control, but if you don’t…let the bad code pour in.

It never fails – at least one of the new features that the customer proposes as a “strongly like and might need” for this version will go against the code that you’ve already written. I don’t think I’ve ever heard of a project that was able to augment what they were doing mid-stream (yes, even you agile folks) to accomidate every request the customer could make. Some things are easy, but most of these sort of changes are hard.

This is when it gets very hard to keep that “good code” in place. It takes a lot of practice and skill to keep things flexible enough to make the impact of these sort of changes minimal. Writing good code from the beginning is easy – making that good code stick through to the end is hard.

How hard are you willing to work to keep that code good?

Photo credit snappED_up

Having Companies Involved in PHP (why not?)

After this year’s ZendCon, there’s a question that’s been sitting in the back of my mind, bugging me to come up with a good answer – what role should companies take in the developer community ecosystem? The problem with the question is simple, though, because no two user group situations are the same.

I’ve heard things from both ends of the spectrum on this one. Some groups prefer to keep the companies away from their groups and rely on the support of those that make it up (much like a lot of the general PHP community) and there’s others that swing far to the other side and want any and every company that could potentially help them out to come walk through their door. The tricky part comes up when you get into that gray area in the middle. Some groups want help when they need it, but don’t want a company coming in and using that same influence to change the course of the group or to try to leverage it for their own purposes (“sure, we’ll help you out with that if…”).

So, what I want to hear from all of you – where do you think companies fit in our corner of the world in the PHP community? There’s several large ones out there that can and do contribute and others that don’t…which is the right blend and, more importantly, what can we do to help the situation?

Outside the Bubble

So, given some of the comments from my previous post on conferences (and what they are/aren’t) I felt like I’d lost a bit of my “conference roots”. I’ve been to enough of them that my perception is, almost definitely, skewed in favor of the group of folks like me – the ones that seem to be making a career out of attending as many conferences as possible. We all know each other and we all have our own little bubble we float around in at most conferences. There’s comfort there, but there’s also one large problem – the bubble isn’t big enough.

Some of my advice from before pertained to those attending these conferences that might not be a part of this bubble. This includes the large number of attendees that are at a conference for the first time. Ever. They may or may not have even been to a local user group meeting before and this could be their first wide-spread exposure to the Wonderful World of PHP (and might be for a while after). So, fellow residents of the bubble – what can we do to help make these people feel welcome in our community and leave them with the feeling like they’re appreciated and that they can contribute back to PHP in their own way? Here’s a few suggestions:

First off, an easy one – you were a newb once too, remember? No one was just born into the PHP community, it was a matter of discovery. Maybe you were working with Java or just learning HTML and how to design web sites. It’s possible you might have even glanced at PHP before but pushed it away as one of those “languages that’s just a fad” but have come back around. You explored the language, poking around in all of its nooks and crannys to figure out the best of the best practices for you and your code. How would one do this, you might ask? Well, it’s simple really – experienced users, much like you are now, took the time to sit with them and talk them through a problem they’re having. Or they did something as simple as stand at the front of a room and talk for an hour on something that interested you enough to want to devour any knowledge you could. In short, generations of folks from inside “the bubble” were the ones that helped you become the developer you are. Don’t forget that and don’t forget to follow their lead. We can’t have strong leadership in the language or community without guidance from those more experienced. Without it, our community will surely die.
Next, an even easier one – sometimes, it’s not really about the code. Trust me on this one…when meeting people at conferences, it’s only maybe 30% about the actual code. Sitting in the conference rooms and learning about the technology is one thing, but walking around and shaking hands with people you’ve never met before fills out the rest. After the sessions are done, you’ll be surprised by the number of people that just want to sit around and shoot the breeze about what they’ve learned or another related bit of web technology. If you’re lucky enough to be a speaker and happen to overhear someone talking about something you know well, stop and listen. Offer advice where it fits and help them on the path to understanding some of the more difficult concepts. I remember being at my first conferences and seeing the speakers walking around and talking with each other and wondering if I’d be able to break in and ask one of them my own questions. Remember speakers, it’s not always about the other attendees coming up to you – keep your ears open and listen for places you can offer advice. There’s going to be a *lot* of people at ZendCon next week, so be sure to be ready to be what you’re there for – some of the most knowledgeable in your area. Be sure to share!
And finally – the comfort zone is the danger zone (I bet you’re humming “Highway to the Danger Zone” now, aren’t you?) Jokes aside, this is just a quick one…don’t let yourself pass up an opportunity to share what you know with someone else because it’d be a step outside the usual. Remember, we’re all a part of the same community and if there’s no sharing going on, bad things happen.

Most of this is common sense and just about every speaker I know does this at one time or another, but I just wanted to remind those “bubble people” to get out there and mingle with the crowds and spread that knowledge around a bit. What you might see as one small comment to a random developer from a group could be the key to the problem they’ve been working on for months.

It’s not a conference…

As I sit here and prepare my liver for the onslaught coming next week (ZendCon, of course), I can’t help but think about those folks that’ll be attending the conference. I’ve been trying to think back to the first time I went to a PHP conference (php|tropics represent) and how I felt walking about with the people I’d only knew by name from books, blogs and articles I’d read. I was actually sitting there learning from *the* Wez Furlong and was there with *the* Andrei Zmievski learning about PHP and it was amazing and thought provoking and I felt like I could write and do anything while I was there, surrounded by all these great minds.

Fast forward a few years to 2009 and you’ll find me still attending conferences and still enjoying getting to be around some of the big thinkers in the PHP community, but it’s just different. It’s not the talks or the evening events – those are all pretty much the same. No, I’ve definitely changed my expectations of conferences and I think it’s something that can easily happen to any attendee, speaker or not: you forget.

Yup, two simple words sums it up. You’ve been to one conference, maybe three and the sameness of it all starts to catch up with you. You follow some of the same patterns: you wake up, you drink enough coffee to make it through the first session, head to a few more, then lunch and on through the afternoon. Lather, rinse, repeat for the remaining days of the conferences. You can see how it’s easy to get in a rut and just coast your way through the conference absorbing what you can and drifting out the other side to an airplane that will take you back home.

Here’s another two words for you – speaker or not, conference attendee or organizer: wake up! As much as it pains me to say it (being a speaker and all), these events are *not* about the talks. Want me to repeat that? Conferences are *not* about the talks. I think Keith hit the nail on the head with some of his comments in a recent post talking about the “hallway track” and meeting people. Conference organizers will promote the sessions and the panels and talks they’ve managed to pull in with the big names, both in the PHP community and outside it. They want you to come and see these people and feel good that you sat in a room listening to the folks that took a chunk out of their conference budget. This makes them happy and they hope it makes you happy.

I can tell you one thing from my years of going to PHP conferences – if you listen to them, you’re missing out on the best part of the conference. See, the other benefit of having large events like this that companies can feel good about sending their employees to is…well…that it’s a large event with lots of people at it. That’s the key right there – the people. Enlightenment is fun, but sitting around having beers with the “internet famous” people you know from blogs and articles is so much more interesting. I’ll say it again just to be sure it sinks in – conferences are not about the sessions, they’re about the people.

So, what can you do to make sure you get the most out of your conference experience? I’m going to blatently steal some of these ideas from Keith but with a few of my own dropped in:

Sessions are interesting, but people are fun – there are a *ton* of sessions happening at ZendCon this year. So much so that I have no clue where I’ll end up. Chances are, you’ve picked out a schedule that interests you and are just waiting to know which room they’re in. Do me a favor – each day, pick one talk that you’re on the edge about (yeah, you know the one) and don’t go. Yup, that’s right – don’t go, hang out in the hall or commons area or something. If you’re hesitant to go, chances are you’d just sit there and check your email or chat on IRC most of the time anyway. Do yourself a favor and get out and meet people. This kind of thing only comes around every once and a while, so make the most of it!
Make connections – Keith recommends business cards because they’re easy, but I’d say take it a step beyond that. Really get to know people – it’s funny how a “camp” atmosphere can help people bond more quickly than usual. Take advantage of this time and really talk with people – go beyond the “hi, so what do you do?” kind of thing and find out who someone is, why they’re there and something interesting about them. Then exchange the cards…and IMs…and IRC nicks…etc. Get to know these developers! They’re your comrades-in-arms, after all!
After-hours For The Win – The conference will have events after each of the full days of talks, that’s pretty much a given with any sort of conference. It’s what happens after that is some of the real fun. No, you don’t have to go out and party until the break of dawn (though there’s sometimes that too). I’m always a little bit disappointed that more people don’t stick around to hang out after whatever evening events might be going on. They scatter to the four corners of the hotel, not to be seen again until the start of the next day’s sessions. If you’re one of those types, trust me – being out just a bit longer won’t kill you. Plus you get an *amazing* benefit from it…you get to see people, speakers and non-speakers, how they are “off the clock”. Once the day is done, no one has to report to the next talk or worry about what the conference organizers will think. They sit down, stretch out and shake down until they’re just them. *This* is when real conversations start. If it hadn’t been for this time of the day joind.in might not even exist. Come, relax and just enjoy being around people – it doesn’t matter if they’re speakers, core developers or rockstars.

Complacent Developers Suck

We’ve all been there – we’ve reached the top of our current skills. We’ve met every expectation and conqured every issue in front of us. We are masters of our domain and no problem seems too difficult. This is the worst position you can be in. No really, trust me on this one. As soon as you become complacent in your practices, you’re doing something wrong.

One of the key things that separates great developers from good developers is their capacity to learn. Good developers will learn how to do something and know it well. They’ll be content in their knowledge of how to debug a script a certain way or refactor their applications to follow a pattern they know well. Great developers, on the other hand, take that next step and grow. They leave their comfort zone in the dust and look to the future to find out how they can conquer the next hurdle in an elegant and constructive way. They’re the ones constantly improving themselves, working to make themselves and their code a better place to work and play. They see challenges in their development as things to innovate around not just as problems to solve with a certain equation. Their joy is in flexible, resilient code that can adapt to any situation and can make not only their lives simpler but the lives of those down the line easier and less complicated.

Innovation is the key here – any developer can cut and paste examples from other website to make things work. In fact, there’s a whole crop of developers out there that do nothing but this. They don’t innovate, they don’t learn – all they do is take the information they find and regurgitate it back into their code. As you can imagine, this is a very, very bad practice and can only lead to code that’s both difficult to maintain and hard to extend.

Be careful – don’t let your past accomplishments make you lax in your development. It’s easy to fall into the trap that successful code can lay. You see things working and the code seems solid so you go along your merry way and do the same on future projects. The only problem with the situation is the innovation – no two software projects are the same and no matter how similar they seem to be, code without innovation is no code at all. You learn something from each implementation and this new knowledge should be applied to every new project you encounter. Reusing code is good, updating it to reflect the knlowedge you’ve learned is even better.

Don’t be complacent in your development – learn, grow and use this knowledge in your future development. If you don’t, you’re only hurting yourself. Learning is good, applying is better. Constantly learn and innovate. This is the only true way to be a better developer. Period.

The Beginner Pattern

You were there once, remember? You were the cautious explorer, venturing out into an unknown language with little idea what it might hold in store. You learned functions, found tutorials to help you take your first steps and maybe even reached out to other developers to help you along the way. You were a beginner – everyone has to start somewhere, after all – and every little bit helped.

So, it worries me when I see things like this talking about a move of the PHP community away from those introductory topics that we all came to know and love as we moved forward into our PHP development careers. Samuel doesn’t think it’s the PHP community’s fault, not by far. He does suggest, though, that we’re “forcing newcomers to our community to build their PHP homes from attic to basement” by not pointing out or writing up as many tutorials and articles targeting the introductory developers.

In the spirit of trying to bring PHP back to the masses, I’m going to suggest a “design pattern” of sorts that the PHP community can help to bring even more people into the language and help them really find the heart of the language and what it’s all about:

Learn – The first step in the pattern is to learn about the task you’re trying to accomplish. Obviously you can’t teach others if you don’t know about it first. Find out the best way to do it – the tips and tricks if you can – and remember them. They’ll come in handy in the next piece of the pattern.
Write – You don’t have to be the Hemingway of PHP to write a tutorial. This piece has an obvious fit with the first step of the process. Take what you’ve learned and write it up into something anyone can follow. Just posting a list of commands and code isn’t enough – sorry. Write it so that someone who doesn’t know anything about the topic can pick it up and run with it. Plain english (or whatever your native language is) is best…technical terms are good when they’re needed, but don’t try to use them to make yourself look important by using too many multisylabic words in too many places con only lead to trouble. And remember, tutorials don’t have to be about anything fancy. Find out something cool about an everyday PHP function? Write it up! Trust me, no one will think anything about an “advanced developer” writing about a cool thing they figured out about str_replace.
Share – Obviously, a good tutorial or article isn’t any good unless people know about it. Sharing is an integral part of this pattern. If you don’t let others know, you might as well not write it. You never know when someone might need a little nugget of the wisdom you’re sharing, so broadcast it out there. Don’t be ashamed to bring it to the masses in the forums or post about it on your blog. There’s nothing wrong with a little self-promotion if you can help out some developer in need with exactly what he needs.
Learn – Wait, this again? That’s right, the pattern loops back on itself in an endless cycle. Once you learn a new skill, write about it and share that knowledge with at least one other person, you’re back where you started. You’re moving forward in your development and coming across new challenges each day. So, guess what? Write about them! Share it! You get the idea…

The pattern is simple Learn then Write then Share. Learning is handled by one object (you) and then writes to a local resource (your brain, duh) and the resources are exported into external data sources for other objects to use. Simple, right?

So, go out there, learn something new, write a tutorial about it and share it with the masses. Idling in your development on a project? Think about the things you’ve learned so far and share those.

Remember, there’s new developers starting every day – help them out and share the tips and tricks you have stored in that head of yours. They’ll thank you for it.

Photo from pagedooley Creative Commons Attribution License