Create global .gitignore for user settings

ignored

When it comes to ignoring files in a git repository I do something I think many others have done.  I’ve added user level settings files to my .gitignore because I don’t want them included in my git repository.  You know, the files created by an IDE, operating system, or other applications.  Such as ‘.project’ created by Zend Studio or ‘.idea’ created by PHPStorm, and there are many others.

While it may be acceptable to add them to the .gitignore file in a private repo, should they be ignored in a publicly shared repository?  To answer this let me explain that I believe in “freedom”, and think everyone is entitled to do what they want, as long as it doesn’t hinder someone else’s freedom.  This is important when it comes to code.  Therefore, these files should NOT be ignored in the .gitignore of a public repo because someone creating a clone of the repo may desire to do something different.  So marking these files to be ignored, or not, should totally be a personal decision made by the user.

However, there is a way to have our cake, and eat it too.  We can inform our local instance of git to have a system global .gitignore file.  Therefore while the individual repository has a clean .gitignore file, with only references specific to the project, we can still have our user level ignores in place.  Here is how to do it.

From command line issue the following command: (command is non-Windows because of the file location, I’m not sure what it would be on a Windows machine, so perhaps someone can comment with a Windows friendly command)

$ git config --global core.excludesfile ~/.gitignore_global

This command creates a global setting in our systems git configuration informing git of an excludes file containing additional files to ignore globally.  The file name will be called ‘.gitignore_global’ and will be located in the users home directory.

Adding this –global config setting to git does not create the file for us, so we will still need to create this file in the location we specified. (The home directory in this case.)  Here is what mine looks like:

.idea
.buildpath
.project
.settings
.vagrant
.DS_Store
nbproject
.thumbs

Meanwhile my project level .gitignore might look like:

/vendor
local.config.php

For more on this topic, and perhaps a better explanation, please see https://help.github.com/articles/ignoring-files.

Fun with Travis CI and PHP projects

I know I should have done this a long time ago, but I finally got my hands dirty with Travis CI.  I wanted to set up a php project on github to use Travis CI to monitor the status, in case I forgot to run the tests prior to pushing.  Unfortunately it was not as easy as it’s made out to be.  But now that I’ve done it once, it’ll be easier next time.  So, here is how I tackled it.

First, creating an account and getting started was easy.  I simply clicked the “sign in” link on the Travis CI site and entered my github credentials which authorized Travis CI to connect to my account. (the site informs you exactly what Travis CI will have access to)  Once that’s done Travis gets all my repos, so I can then activate them for Travis CI.  If that doesn’t happen automatically there is a handy “sync now” button to coax Travis CI.

NOTE: To connect public repos you would use https://travis-ci.org, while for private repos you would use https://travis-ci.com.  While pubic repos are free private ones cost money, though you do get 100 pushes free to get you started.

Second, it’s now time to click the + and add a new repo to be tracked by Travis CI.  After clicking you will be presented with a list of your repos to choose from.  It is simply a matter of turning the repo ON by clicking the switch.  I also clicked the wrench to select the option to “Built only if .travis.yml is present”.

Travis CI add repo

The structure of the app I added looks like this: (including all files needed for travis and unit testing) https://github.com/adamculp/api-consumer

Application structure

Third, I needed to create the .travis.yml file with the directives needed to make it all work.  Here is what my file looked like.

travis.yml file

Pretty simple.  Here is what it all means: I specified what language to use (php), and what versions of the language to test with (5.3, 5.4, and 5.5), I also instructed to have Composer install prior to any other scripts run (needed to ensure there was an autoloader, created by Composer), and finally I add the phpunit command and tell it where to find the phpunit.xml file (in this case it was in the tests directory).

Fourth, ensure that PHPUnit runs as expected locally.  Yes, you will need unit tests on your code.  That’s like one of the main reasons to do this in the first place.  Here is what my phpunit.xml and bootstrap.php look like:

phpunit.xml file

The phpunit.xml file is fairly simple.  It informs where PHPUnit can find the bootstrap.php file (same directory as a the phpunit.xml), and sets a whitelist of directory where code can be found (some use a blacklist and specify not to use the /vendor directory), and what directory to find tests in (the current directory).

phpunit bootstrap.php file

The bootstrap.php file specified by the phpunit.xml file is even simpler, as it only specifies where to find the autoload.php file created by the Composer install.

Fifth, take a quick peek at the settings for the repo on github and you will notice that Travis CI should be already set up and ready for something to be pushed.

github settings

Final, that’s it!  That is everything needed for Travis CI.  Of course this example is very simplistic, since the repo and tests are only on a single wrapper class I created.  But it’s good enough for a start, and if you need more the documentation is pretty good.  With these files created, all that remains is for me to commit changes to git, then do a push to origin at github.  Once the push to origin happens a Travis CI trigger at github fires and informs Travis CI to create a new build on a VM (virtual machine) then run the tests on the newest code.  After Travis CI finishes it lets you know with an email, and through the site. (green = good)

Travis CI feedback

One last thing you may want to do is add the Travis CI image to your README.md at github.  This will allow you and others to see whether the current master branch had a successful build, or if it failed.

[![Build Status](https://travis-ci.org/adamculp/api-consumer.svg?branch=master)](https://travis-ci.org/adamculp/api-consumer)

Travis CI build status indicator

Enjoy!

Developer advice

As the organizer of the SoFloPHP User Group I am often approached by entry to mid-level developers asking what they can do to advance in their career or become better developers.  Of course I am nowhere near perfect but have been around long enough to get a few bumps and bruises along the way, so below is what I usually share as some pointers:

Note: While some of these items are kind of PHP specific, others may find useful items as well.

  • No self-respecting person should be up at 4:05am sending emails.  Get some sleep. 🙂  It is OK to stay up late once in awhile, but force yourself to get to bed at a decent time (10) each day.  And try to get up early each day also (6 or 7), which will help you get much more out of your days. 😉
    • The myths about developers working all night on caffeine are false.  Yes, it happens sometimes, but it is rare.  Well rested developers learn more, write better code, and get more work done…period!
  • Track your time, and get in the habit of knowing what you did with each hour.  I personally use Hamster religiously, and find that I get much more done each day as a result. (I have it set to nag me every 15 minutes if I have not set an activity.)  If you are not using Linux as your desktop environment I am sure there are time trackers for the other operating systems, find one.
  • Certifications will not actually carry much value on your resume, so I would not make them a main focus.  Sure they do carry some value, but perhaps not in the way you desire.  Achieving a certification is a great personal accomplishment and will make you feel better about yourself, as well as give you bragging rights among developers.  (Most developers tell you they don’t care about certifications, but deep inside they are simply envious.)  While many certifications are not a true gauge of actual knowledge, they do represent a certain amount of skills.  However, I have found that most employers do not even notice certifications.  I am not saying don’t get them. What I am saying is to be aware the actual accomplishment may be different than you perceive.  When I started getting certifications it reinforced, in my own mind, that I knew what I was doing.  That gave me more confidence overall in my jobs, and was still a big “win”.  But do them in your spare time, not as a focus item.
  • Pick an IDE to use and learn it FULLY. I will not recommend one in this post, so explore and find one that fits how you want to work.  Then learn it COMPLETELY, and use it ALWAYS.
    • If an IDE causes you pain, don’t use it any more.  Pick another one.  This tool will be where you spend most of your day, so you should not be forced to spend your time debugging and fixing your IDE.  It should not crash regularly.  You should not dread opening it, instead you should look forward to launching it.
    • Use all parts of your chosen IDE. (FTP, version control, testing, coding, debugging, issue tracking, etc.)
    • Learn the keyboard shortcuts, they will save you time.
    • Just because an IDE is free does not mean it is good.  You should base purchases on value provided, not $$$.
  • Pick a plain text editor, and learn it well.  There are times you just need to do a quick edit, and opening an IDE, creating a project, etc. is just overkill for this.  Again, there are many of these available so I will not recommend a certain one.  Pick what you like best.
    • The best ones come with syntax highlighting.
    • There are some free ones, but don’t be afraid to pay a few bucks for a good one.
  • Pick a pet “full stack” PHP framework to learn, FULLY.  I recommend either Zend Framework 2, Symfony2, or CakePHP 2.* since these 3 are the most common.  But as with an IDE you should learn one COMPLETELY, and use it most of the time.  Each framework has its strengths and weaknesses, so choose one that works best for you.
    • Good frameworks have mechanisms in place where you can add plugins, modules, or helpers in case the framework does not fully support what your trying to do.  But stick to the framework as much as possible.
    • Feel free to write your own framework, but ignore the urge to use it for employers.  As professional developers we owe it to our employers to use more widely available frameworks.  It is just smart business.  It means businesses can find other developers easier, onboard them faster, and train the group more.
  • Always strive to make yourself replaceable.  If you are replaceable you are also promotable, and you can go on vacation pain free.
  • Learn to use GIT for source control, and use it for EVERY project you do no matter how small.  Sure there are other source control products out there, but currently GIT is the way to go.  All it takes is the command ‘git init’ in a directory and you are of and running.  No excuses!
  • Do things publicly so others can see.  Such as github, BitBucket, etc.  I recommend having code in some sort of public place for others to see how you code.  Don’t be shy.  I’ve had other developers provide feedback on code I posted on github, in a constructive way, and it helped me advance my skills.
  • Your LinkedIn profile is your best career tool as a developer.  Tweak it, adjust it, get everyone you can to contribute to it.  Add projects to it, etc. (See “Build your brand” below.)  Don’t connect with everyone who pops up, and be stingy with what recruiters you allow to connect with you.  If someone is not going to help your career in some way, they do not belong in your connections on LinkedIn.
  • Pick up small projects here and there that are NOT urgent, and you can take your time on.  These little projects will afford you a way to learn new things.
  • Get active in the PHP community.  I mean really active.  Sure, it’s OK to be a member of other communities as well, but the PHP community (world-wide as well as local) is what will really “do it” for you. (If you are going to make a career doing PHP.)
  • Give talks at local user groups, blog about your experiences, follow other blogs of good people (phpdeveloper.org is a good place to see activity of PHP community members blogs. Chris Cornutt does a great job at filtering out relevant posts and adds the best of them on this site.)
  • Get somewhat active on Twitter, join IRC channels, travel to a couple of conferences each year and get to know people “doing things”.  Then eventually start submitting talks to the conferences so you can go talk, and have your expenses covered to go to it.
  • Build your “brand”.  By this I mean to say YOU are the product.  Everything you say and do is your offering.  Your name is your “brand”.  Build the reputation carefully, and before you do anything ask yourself, “Will my customers like/buy this?”  If the answer is “yes”, then go for it.  If the answer is “no” re-evaluate.
  • If you are a woman, be careful.  While women are becoming a larger part of the tech community there are still many men who are not used to it yet.  They are jerks, and your feelings will get hurt sometimes in the process.  Learn to ignore them and focus on the good parts as you grow.  KNOW you are going to do great things, and work toward that progress.
  • Learn Linux via command line.  No need to go crazy with this one, but since most web servers are on Linux it is a good idea to have some knowledge in this area.  You should at very least know:
    • Basic vim commands to edit files on the server.
    • Be able to navigate the OS files and directories.
    • Be able to manipulate files on the server. (cut, copy, paste)
  • Spend some time each day on Stackoverflow.  Try to pick a problem someone posted and help them.  “Doing” is the best way to learn, and there are plenty of problems posted to Stackoverflow daily.  This is addictive, so manage your time and limit yourself.  But do it!

Of course there are many more tips, but I wanted to hit on some key items without writing a book on this blog post.  I hope you find this information helpful, and if you can think of some other hints and tips please feel free to share in the comments.

Good luck!!!