BowerStudios.com

I am trying to train myself to write better commit messages. To that end, I have created an entry in my ~/.gitconfig
[commit]
template = ~/.gitmessage.txt

The conundrum is that I nearly always use:
git commit -m "Message here"
and sometimes:
git commit -am "Message here"
How can I prevent myself from using the -m flag, so that my template will be presented (and I will be reminded to use it)?
I don't need to absolutely enforce this in the project, but I would like to wean myself off of "-m".

I posed this question to StackOverflow, and in the ensuing lively discussion, received an excellent answer from "that_other_guy"

I modified it slightly to match the syntax of my existing bashrc functions (probably for no good reason) and changed the output of the annoy_me function:

Contents of ~/.gitmessage.txt
# FORMAT of Commit Message:
#
# BS-001 - Feature - New FooBar Widget added to home page
# Tracker Id - Type of Change - General Description - Details on a new line
 
# Change Types:
#
# Feature - New feature
# Fix - Bug Fix
# Remove - Remove feature
# Refactor - Refactor
# Style - Code Style / whitespace etc
 
# Tracker Ids:
#
# JIRA/BitBucket - BS-001
# GitHub - #1

About Thermocouples and TCO

• water-heater-repair-guide.com
• levcobuilders.com
• waterheatertimer.org

Assumptions:

• Two IPV4 networks (A & B) that are not connected to each other, and two machines (1 & 2).
• Machine 1 is a gateway NAT between the two networks, meaning it has one interface on Network A and one interface on Network B (192.168.42.1). Machine 1 gets its ip from a dhcp server on Network A. Machine 1 serves as the dhcp server on Network B.
• Machine 2 is a client on Network B with IP 192.168.42.2.
• You wish to forward a port on Machine 1's Network A interface to Machine 2's Network B interface

Follow the references below, the following config files for Machine 1 should fill in the blanks for what I used in my environment

Contents of /etc/network/interfaces:
# The loopback network interface
auto lo
iface lo inet loopback
#
# The Network A interface
auto eth0
iface eth0 inet dhcp
#
# The Network B interface
auto eth1
iface eth1 inet static
address 192.168.42.1
netmask 255.255.255.0

Some relevant bits of /etc/dhcp/dhcpd.conf:
option domain-name "hosting.bowerstudios.com";
option domain-name-servers 8.8.8.8, 8.8.4.4;
subnet 192.168.42.0 netmask 255.255.255.0 {
range 192.168.42.100 192.168.42.200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.42.255;
option routers 192.168.42.1;
}

Contents of /etc/rc.local
/sbin/iptables -P FORWARD ACCEPT
#Forward port 80 to web server, port 80
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to 192.168.42.2:80
/sbin/iptables --table nat -A POSTROUTING -o eth0 -j MASQUERADE
exit 0

References:

• IP-Masquerading on Ubuntu
• Ubuntuforums.org - Port forwarding from one machine to another
• Network Config on Ubuntu
• Dhcp Server setup on Ubuntu
• codeghar.wordpress.com Ipv4-nat gateway

I rarely have to build JSON manually, so I tend to forget the exact syntax. The JsonLint tool is a nice prompt for remembering.

There are many good options for testing mail in your java applications. The best option is to create a test that is repeatable and cuts out the mail server altogether, to verify your logic is correct.

That said, sometimes you just need to test something out quickly, and for that a mock smtp server can be handy. In this, FakeSMTP is exactly that.

Debugging with eclipse tips from codecentric.de

Particularly useful to me were the sections:
Navigation: Drop to Frame, Variables View: Show Logical Structure

The stuff on Detail Formatters was useful as well.

Note that Eclipse will truncate long strings in the detail view, but you can increase this limit. However, with very large values, you'll find it much easier to change the underlying code adding a log statement due to the detail view being really slow to render.

gives:
[id:a]
[id:b]
[id:c]
[[id:a], [id:b]]
[a, b]


I usually tend to just add
params.each{k,v ->
println "param $k: $v"
}

when I need it.

However, on whim I tried the Grails Debug Plugin, and was fairly pleased with the result. I would have liked the params to be logged by default, but they can be turned on fairly easily with this in your config file:

grails.debug.params=true
grails.debug.requestAttributes=true

There are additional bits available as well.

Never attribute to malice that which is adequately explained by stupidity.

I had was using:
myDomainInstance.errors.reject("message.code","default error message")
to add error messages to an object, and was really surprised when the object saved successfully. I carefully debugged the output and saw that the error was attached to the domain object successfully, but when the validate() method was called, the existing errors were wiped.

Burt Beckwith states that this is intended behavior on stackoverflow and explains why.

So, I ended up doing this:

if(myDomainInstance.hasErrors()){
//error flow here
}else{
if(!myDomainInstance.save()){
//error flow here
}
}

after adding my custom errors instead of this:

if(!myDomainInstance.save()){
// error flow here
}


The downside of this is that the errors do not accumulate, you either get the custom validations or the domain validations, not both.