So I decided to install Java …

I’m not a Java coder. I work primarily in PHP, with Python on the side. I’ve been rewriting an old PHP project to conform with modern standards, including testing. I decided to use Codeception for PHP testing, mainly because it looked like PHPUnit was included and unit/integration/acceptance testing looked easy (if you follow the example given in the website). I had used Gherkin to write BDD tests, so I was happy to see it with PHP. I also saw auto-testing with PhpBrowser and … Selenium!

I had used Selenium for testing several years ago. I remembered that all I had to do was fire up the Selenium server and run the tests to catch any Javascript browser issues. I remember that being very helpful, so I downloaded the Selenium server and tried to fire it up. … Wait a minute. I don’t have java on this machine any more? The OS upgrades probably turned it to toast. OK. I’ll install that first.

I spent a few days thinking about how to install it. Since I use brew to install other command-line applications, I wondered how brew would handle a JDK installation. It turns out that my Google search: “jdk homebrew” came up with several web pages that did not fully work. I had to put together instructions from these pages.

For starters, I ran into a command that mentioned casks. Eventually, after another Google search (“homebrew install cask”), I discovered that “cask” is a way of managing graphical applications through brew. Anyway, after some review, I finally have Java (1.8.0_131) running on my El Cap box. Yay, me! You’re welcome to try these or to review the pages linked above to figure out yourself. It looks like it will work either way.

brew update
> brew install caskroom/cask/brew-cask  …  (probably did nothing)
> brew tap caskroom/cask
> brew cask install java

Note that I did not choose to install “jenv”, which creates virtual environments similar to “virtualenv” or “venv” (?) with Python. Somewhere in one of these pages, there was a note that I needed to install Java 7 first. I never found a reason why it was needed, so I skipped it. We’ll see if I do need it.

Interesting GitHub question

I have most of my private repositories hosted on BitBucket.org. They provide free space for private repos. GitHub requires a paid plan to host private repos. I have lots of private repos. However, it seems that everyone wants to see coding samples. GitHub no longer requires a paid plan to host public (open source) repositories, so why not take a fresh look?

I don’t want to show off all my mistakes in the public GitHub account, so I’m keeping the private BitBucket account. How do I push additional BitBucket snapshots that are sort-of cleaned up to the public GitHub account?

Step 1: Set up a public GitHub repository
That’s easy. I already have a GitHub account that I used when I was taken the Berkeley Coursera class. The account was private while I was taking the class, but became public when the class ended. Setting up a new repo in GitHub is easy and they provide help pages if you have questions.

Step 2: Figure out how to push the local repos
I already use GitHub Desktop (for Mac) to clone tutorials. In the end, I decided not to use it to clone and push the BitBucket repos to GitHub because I was concerned the alias to BitBucket would be overwritten.

Step 2a: Use the command line interface to create another alias
GitHub (and BitBucket) will automatically create a remote alias when creating a remote repository and use it to push snapshots up to that repository. I’m already using that alias (origin) and was concerned that GitHub Desktop would overwrite the alias to github if I reset it using GitHub Desktop. However, I can use the CLI to create a new alias.

> git remote add github git@github.com:rachavez/tournament-score-keeper.git

When I check the aliases using “git remote -v”, I see another set of aliases pointing to a different server.

So, while I’m stuck with dead end and intermediate steps, commits go to BitBucket. Once I figure everything out and arrive at a good stopping point, the commits all get pushed as a block to GitHub.

> git push github master

I can live with it. Even better, I noticed in SourceTree (Atlassian/BitBucket’s Mac desktop app) that the new alias appears in the remotes list. Potentially, I could update SourceTree settings to go back and forth between both repositories. Interesting.

Cleaning up Mercurial & Git repos

Recently, I cloned a repo that I created on my laptop and pushed to Bitbucket back down to my desktop. At that point, I discovered that I had included all the vendor files for the project within the repository. That’s a no-no. It’s a waste of space, mainly because the dependent libraries can be downloaded by running composer once the new clone is created. So, I decided to remove the vendor files from the repository without dropping them from the file directory.

I thought I had solved the problem by updating Mercurial’s .hgignore file, which is used by Mercurial to mark which files and folders to not track. Unfortunately, the vendor files had been included in the initial repository creation. Going forward, .hgignore would ignore new files and folders in the vendor directory, but I still needed to forget the files already listed. It turns out that ‘hg forget file_name’ would do the trick.

I wanted to be sure it worked, so I created a ‘tests’ folder and touched a file inside that folder. Sure enough, the file appeared in Mercurial’s commit list. I ran a commit, then tried

> hg forget a.php

This removed the file from the committed list, but the file still appeared in the staging area, which did not make sense. When I updated .hgignore to not track the ‘tests’ directory, the new file disappeared from the staging area. That’s what I wanted.

I now had all the files in the vendor directory for forget. I moved to the vendor directory and entered the following command to forget the .json files:

> hg forget -I **.json .

That removed the .json files from the commit list. I did the same for .js, .map, .txt, .conf, .tpl, .yml, .css and .html files. Oddly, only one .php file was forgotten in this manner in the vendor directory. I wonder what might happen if I try ‘ > hg forget -I vendor/** .’ ? (I may try that if I have to clone this repo again.)

Git

It takes less command line work to forget files in git. This command did it all:

> git rm -r –cached vendor

where rm (folder remove) -r (recursively) –cached (from index only) vendor (the folder name). That’s much easier.

Catching up with Python

I always forget that major software upgrades in OS X reset permissions in /usr/local. When I checked my brew install, I saw that message. I played around with write permissions only, but in the end, did what brew recommended and reset the permissions as described. That allowed me to update brew and move on to the next task: updating Python3.

I was not as far back as I expected. I was sitting on Python 3.4. The upgrades went smoothly and I’m back to Python 3.5.1. I thought I had modules installed, but I’m not getting any list of local modules installed. It’s very possible, since I never did much with on the desktop. That will be the next task.

Resetting after El Cap install

I have some more free time, so I decided to reset my El Capitan system as a development machine again.

I bought my license for BBEdit 11.5, so I installed that. I’ve used Visual Studio Code at work. I like how the window can take over the entire screen, but I don’t like how only three tabs for files are allowed per window. If you need more files open, you need to open another window. It seems weird. I’ve used TextMate. Again, I like how tabs are used to show files instead of the list used by BBEdit. I’m used to BBEdit’s quirks, so I’ll go with that for the moment

I need to reload Apache. I use the standard setup:

sudo apachectl start

However, Apache would not start this time. Running

apachectl configtest

shows an error with something called LockFile.

After some searches with StackExchange, I find out that LockFile is an Apache directive active for Apache <= 2.2. El Capitan runs Apache 2.4.16. Comment out the section that includes the LockFile directive and restart Apache. Localhost is working again.

I’m using the instructions in this page to activate Apache and PHP. phptest.php works after restarting, but I have the PHP timezone problem again. I had to copy a php.ini file from the included php.ini.default, set the timezone to “America/Los_Angeles” and restart Apache. Problem solved. More stuff coming soon.

installed intl extension for PHP

I’m getting ready to install CakePHP 3.1.3 on my laptop. I discovered that I needed the intl PHP extension installed as a requirement for CakePHP. I tracked down several web pages with instructions and I decided to use this one, considering I had good luck with the page the last time I needed to install the intl extension. The page is for OS X Mavericks. I found no significant changes when I followed along for my Yosemite laptop. The only real change that I saw was that there was a new version of the ICU installer (56.1 as opposed to 52.1 described on the page).

I was surprised that I needed to install PECL and PEAR, considering that I don’t use PEAR that much any more. PEAR did not give me trouble. However, pecl.php.net was down the afternoon I wanted to install the software, so I had to wait until the next morning to install it.

Like I mentioned, the ICU installation instructions are almost the same. The only difference is the updated version of ICU, 56.1. Substituting the new version into the suggested Terminal commands went well

I thought I already had AutoConf installed, from what I saw in some libraries in /usr/local, but I decided to install it again to be sure. I had no trouble with it.

PECL gave me no trouble when I wanted to install the intl extension. Somehow, my php.ini file had been updated with the extension command pointing to intl.so. I thought that was odd, but I let it go. When I checked phpinfo(), there was a new entry for the intl extension. Very nice.

odd home-brew issue with permissions,

I was going to update files installed through home brew and I noticed an odd error message:

Error: unable to unlink old ‘share/man/man1/brew.1’ (Permission denied)

or something like that. That’s never happened before. /usr/local should not have a permissions problem, unless MySQL is involved somehow. (B’). I run ‘brew doctor’ on the command line and it suggests permission fixes for /usr/local/bin/, /usr/local/share, /usr/local/share/man and /usr/local/share/man/man (?). Why did this happen?

I know that “rootless” access is being enabled in OS X 10.11, El Capitan. The idea is this “System Integrity Protection” will make it difficult for malware to install itself in /System, /bin, /sbin, and /usr. However, /usr/local was supposed to be left alone. Also, I’m running Yosemite, not El Cap. Even so, I need to run my updates, so I run the following in Terminal

sudo chown -R “$USER”:admin /usr/local/bin

sudo chown -R “$USER”:admin /usr/local/share

When I run “brew update” again, my system is ready for brewing.

From what I can tell, it looks like folder permissions may be reset during each system software update. I can’t confirm it, but it makes sense. If I had problems after a system update, I would run the Disk Utility and have it repair permissions. Usually, whatever problem I had would go away. It looks like OS X wants to be helpful, but also interferes with the way I have things set up. I’ll make it work.