A couple of days ago, I went through the steps of enlarging my AWS instance volume as well as switching over from magnetic drives to SSD. I thought everything would just work magically when I restarted the instance but instead found that the file system did not recognize the change in disk size. I should not have assumed that the VM would know how I want to use the extra disk space.
The following shell output details the steps required to expand the Linux file system after increasing the instance volume size.
All day I had the pleasure of trying to get the Tomcat manager gui working on local instanced Tomcat. Manager had always loaded up fine when I ran Tomcat as a single server on my local machine. Today, I had a need to run multiple instances of Tomcat on my local computer and there are several resources that discuss the process1. However, I kept running into an issue where the manager for the instanced server wouldn’t work. The username/password prompt would show up but it would not accept the username/password that I had configured in the tomcat-users.xml file; it would just re-prompt me resulting in 401/403 html errors. Finally, I found a post2 that discussed a solution to the problem, though doesn’t go into the explanation of why this is the solution.
The purpose of the MemoryRealm implementation is to provide a mechanism by which Tomcat can acquire information needed to authenticate web application users, and define their security roles, from a simple text-based configuration file in XML format. This is intended to simplify the initial installation and operation of Tomcat, without the complexity of configuring a database or directory server based Realm. It is not intended for production use.
With that in mind, I still don’t know why it was unnecessary for the single instance Tomcat setup I had earlier…
Git was being a real pain in the ass today. I’m not the biggest fan of git rebasing, but I understand that some teams prefer to use it to keep the code history clean.
Today’s problem arose from canceling a pull request, then requiring new changes to be made on my feature branch while the master branch had ongoing development. By the time I had made my new changes and tried to rebase with master, I was experiencing a butt load of merge conflicts that I just didn’t want to deal with.
So the steps that lead to my problem was as follows:
create feature branch
write code in feature branch
rebase with master
commit and push feature branch
create pull request
decline pull request
write code in feature branch
team member simultaneously updated master
rebase with master
I was trying to rebase with master because my team practices rebasing with master before performing pull requests. However, that last rebase really screwed things up for me as far as merge conflicts go.
My solution to preventing all of that headache is as follows. Rather than performing a vanilla rebase with master that second time, perform git rebase --onto master. This changes the starting point at which to create new commits. Basically it changes your feature branch to look just like master. At this point if you perform git status you will see that your local branch and the remote branch have diverged commits. Now you can simply perform git pull to play the remote branch commits on top of your local branch. Now perform any necessary code changes as required before then commit and push. Last step is to drink a beer because PHEW that was hard work!
To summarize, if you think you need to rebase your feature branch with master, but you feel like you may run into a merge headache try: git rebase --onto master && git pull
Installing the 2.3.0 version of google protobuf using homebrew was being problematic. I ended up trying instead to make it manually using the source from google but ran into the same troubles. The solution1 never made its way to the homebrew repo, I guess, or google’s archive.