Skip navigation

Managing my own blog has proved to be a bit too cumbersome for me. I’ve moved both blog.bencarson.net and catsandcode.com to a free wordpress.com blog.

This allows for a free SSL-encrypted connection, plus I figure my site’s backend will be more professionally maintained. I am giving up a lot of freedom in the choice of plugins and themes that I can use, but it is worth it to me. I wasn’t really using anything anyway.

Bonus: they made it super easy to add Google Analytics and Bing Webmaster tracking. Hopefully this will give me a better picture of my visitors than Piwik, because, again, I tend to break shit when I manage my own apps.

Betwixt chores and binges of Borderlands 2, I have been attempting to learn the Ruby programming language. First inspired by Arlo and Eric over at the dev1.tv podcast, and getting my first lessons on the language from codecademy, I’ve been really excited about this language. Primarily because its available for free on my Dreamhost hosting, but also because, combined with the Rails framework, it is so damn simple to build a web app!

I plan on chronicling my experiences here as both a writing exercise as well as creating a cookbook for how I’ve done things. I know that inevitably my dumb ass will forget so this blog will become a valuable resource for me to fall back upon.

I think that most people know that poinsettias are poisonous to animals. But just recently, I learned that lilies are highly toxic to cats as well. Our newest guy, Ezio decided to make a snack out of the flower bouquet I brought home for Sarah this past Friday. Among the flowers in the bouquet were three lilies and a few peruvian lilies. I didn’t think it was an issue, but fortunately Sarah knew better. In 24-48 hours lily ingestion in cats can cause severe kidney damage in cats. We rushed him to the Emergency Animal Hospital and they started to work on getting the lilies up. Unfortunately, all attempts to get him to vomit up the offending plant matter did not work. The vet on duty gave him some activated charcoal and told us they would need to keep him 3 days to monitor his kidney function. Fortunately, we caught this early enough and he is home safe & sound.
If you have a cat, I’d definitely recommend taking a look at the ASPCA’s toxic plant tool. There are a huge number of plants that are harmful to both dogs & cats.

I’ve been using command-line git for about a year now. I recently decided to tackle my problem of not knowing how to delete remote branches.

I’ve pushed quite a few branches to some remote repos as a means of transporting projects to/from home/work. As a result there are quite a few useless branches in most of my git projects and it makes working with

git branch -a

more cumbersome than it need be.

In searching for an answer, I actually found out that it is much simpler than I had anticipated. Very similar to what I was already doing to push the branch to the remote repo.

git push origin :<branchname>

That’s it! I just have to add a colon to the remote branch name and git deletes it. Not at all intuitive, but very easy to remember.

I despise working with file paths in Java. I can never remember where, in the project’s folder structure, the jvm considers root. And it gets even more complicated once you start running your applications in a server container. However, I did find a quick way to determine where a running JVM considers root.

import java.io.File;

...

File f = new File("dummy");
 _log.info("file is at " + f.getAbsolutePath());

This should print out the absolute path to where this File object would be saved. You can use this as a starting point and do any sort of relative filepathing you need to from here.

Ezio sees something

Ezio sees a new blog post!

I have the privilege of beginning my new blog with a happy post.

My fiance and I spent this past summer doing a TNR program with our neighborhood feral cat colony. It has been a bit of an emotionally challenging, but ultimately rewarding, experience.

It started with a pair of adult cats that were breeding on our street. We and our neighbors decided to help out a little by leaving food and water for them. It became clear early on in the year, that the queen was pregnant. We decided there that we should do something more to help. We named the queen, Mama Cat and the tom, Larry. Mama Cat had two litters this year. One in April (that is where our beloved Ezio Auditore da Firenze was born) and one in August.

Rescued kitties

Freddie and Fiona, the first day that we captured them. Eye infection, upper respiratory infection, flea infestation, and worms. 🙁

The litter that Mama Cat had in August had two kittens in it. We had no idea where the litter had been delivered, so we waited until they were old enough to make an appearance. About a month after we noticed Mama Cat was no longer pregnant, two sickly little kittens, one male, one female, emerged from the crawlspace of a neighborhood house.

After getting them vetted, quarantined, and healthy, we were able to find homes for them. The male was adopted by a wonderful cat-loving couple in Charlotte. They are big Queen fans, so they named him Freddie Mercury.

Mr. Mercury eats dinner

Freddie about to go “Om Nom Nom!”

The female we named Fiona Fuzzybritches, the Duchess of Nom. We were able to quickly find a home for Ms Fiona through with the help of Sandra from the Kitten Action Team. She found a loving home on the first day she was up for adoption!

The Duchess of Nom

Fiona Fuzzybritches, The Duchess of Nom

With the successful adoption of Freddie and Fiona, things are settling down in our house now. All of the feral cats in our neighborhood have been fixed and can hopefully live happier, healthier lives.

We and our neighbors continue to feed the three remaining members of our colony and really enjoy seeing these guys running around the neighborhood.

I am sure I’ll be writing about them more in the future.

I don’t have a lot of money, and this blog is more of a hobby than anything, so I haven’t bought any SSL-encryption for this domain.

Thanks to lifehacker though, I have learned that two-factor authentication is catching on with several popular services, not just Gmail. To that end, I just installed the Google Authenticator plugin on this blog for a little bit of added security. It certainly doesn’t bullet-proof my site, but it does make it a little bit more secure than it was previously.

I am working on building an after-work schedule, but didn’t want to do everything manually on paper. A quick Google spreadsheet would be perfect for this. It will keep all my data organized and automatically compute time changes so I can experiment to find the most efficient and practical schedule for myself.
However, after creating my outline, I found out that there isn’t a simple technique or formula available in Google Docs for adding time (or even dates for that matter). But I did manage to find a partial answer on StackOverflow. Google stores it’s dates as floating point values that appear to represent hours. This means that multiplying the number of hours in a day (24) by the number of minutes in an hour (60) will give me the floating point  value that represents the number of minutes I need to add.

So here’s what I did:

how to add minutes to a Google Doc spreadsheet

Adding minutes to a Google spreadsheet

The formula looks like this:

=<original time>+(<# of minutes to add>/(<number of minutes in an hour> * <number of hours in a day>))

In more simple terms:

<time next task begins> = <time previous task begins> + (<number of minutes task takes to complete>/<total minutes in a day>)

Somehow, I broke my Fedora installation this weekend.

After having a great time getting started on my Gravatar project this past Saturday, I settled in for some Labor Day programming yesterday. However, as soon as I tried to open Eclipse, I was given an error message telling me that the command ‘java’ was not in the PATH variable (or something like that)

I have no idea what the hell happened between Saturday and Monday, my laptop was shutdown between those times.

At first, I thought it might be some leftover quirks from the time that Fedora shut itself down when my battery died (the fact that it didn’t warn me is pretty crappy). I ran some fsck’ing on a few mounts. But I don’t know what I’m doing there, so I wasn’t surprised when that didn’t work.

I decided to go for the obvious and just fix the PATH variable. This required me to figure out where this damn variable is in Linux. I also wanted to uninstall Oracle’s JDK 7 as I thought that might have been a part of the problem. First, linuxquestions.org helped me uninstall all java packages with the ‘yum upgrade -y’. I don’t know what it does, but it set me back to using openjdk7. Then a stackoverflow post helped immensely by showing me where my PATH variable was and how to alter it.

After I added the openJDK filepath to my PATH variable, I logged out and logged back in. ‘java’ at the command line works again and Eclipse opens without a problem.

Issue resolved.

Our CTO came to me recently with the results of a PCI audit. One area of non-compliance that the audit discovered was the need to have users log in only through a SSL encrypted gateway. I set about finding a way to accomplish this with Liferay. Thankfully, it was a pretty easy change and didn’t require any custom log in code (as I initially feared.)

At first, I just happened to come across a relevant property in my portal-ext.properties file.

servlet.always.encrypt=false

On my local machine, I changed this value to true, restarted the server, and all traffic on my local server redirects to the ssl encrypted version on port 8181!

“Hooray”, I thought. “I’m done!” I talked to our Ops team to get the changes made in our other environments and he promptly burst my this-is-too-easy bubble. “Why is it encrypting our marketing site? We shouldn’t be encrypting everything, just the stuff we need protected.” Damnit! Now I have to find an alternative. Fortunately for me, the same Ops guy found the relevant properties to include in our portal-ext.properties file:

#require https for login
web.server.http.port=8080
web.server.https.port=8181
company.security.auth.requires.https=true

This is exactly the technique we needed. Our site doesn’t encrypt any public-facing page (unless you are already logged in) and all logged-in traffic is SSL-encrypted. Liferay team really did me a solid by making this so easy to configure. Thanks girls & guys of Liferay!

%d bloggers like this: