Month: July 2012

2012-07-19 Dry Fire Practice

/ hsoi / 2 Comments

Following the TLG 4-week sample dry fire routine.

Week 1, Day 4

Basic routine

  1. 20 reps of Wall Drill, from extension 2H
  2. 5 reps of Wall Drill from extension, SHO
  3. 5 reps of Wall Drill from extension, WHO
  4. 20 reps of Wall Drill from press-out, 2H
  5. 5 reps of Wall Drill from press-out, SHO
  6. 5 reps of Wall Drill from press-out, WHO

I need to ask Karl about something with trigger work during dry fire. Because we don’t have reset and because I’m so conditioned to “the break” and then other artifacts of dry fire, like holding the trigger back, manually cycling the slide, then reset and fire again, I notice that I always hold the trigger back. I started instead pressing the trigger, click, then releasing the trigger to about where the reset point is. So basically, working the trigger like you really would, tho there’s no reset. I think that’s better and more correct, and creates less training artifacts. But could it have any other side-effects? Hrm.

Anyways, I did that through most of the practice, and I noticed my front sight moving less. I think when I hold the trigger back I end up holding the trigger back. Coupled with my grip, it basically forms a big tight squeeze and my brain is basically thinking to clench the hell out of the gun… which causes front sight to dip, which is no good. But when I just press and release, like a real trigger press should be, dip goes away. Hrm.

Maybe I’ve been doing my dry practice wrong all this time? *sigh*

True Nutrition Whey Flavor #8 – Coconut

/ hsoi

I bought the TrueNutrition.com 38 Flavor sample pack.

Coconut

I figured this would be white powder and stay white when mixed… but in the back of my head somewhere I secretly wondered if it was going to turn blue. Nope. White.

I was surprised by this flavor. When I pulled it out of the box, I had a “awww” reaction. I didn’t want it. I do like coconut, but all too often artificial coconut flavor is nasty to me. I was surprised by the strawberry coconut and especially the chocolate coconut in that they weren’t too bad. And this continued that trend. I was pleased at how good it did taste. It was more of a “dried/roasted” type of flavor than the sugary candy sweet you can get from a lot of coconut flavorings. I dug that. And that’s probably why, because I find while I like sugary artificial stuff to an extent, I can’t have it for long. It’s probably “candy” association in my head. We all know too much candy is bad for you, and while I love candy (have a bag of Swedish Fish and a bag of Jolly Ranchers at my office desk), I can only have it in moderation else my body revolts at the sugar overdose and lack of functional nutrition. So more “natural” or perhaps better to say “savory” flavors my body registers more as “good”. Thus this coconut registered a bit nicer for me since it didn’t taste like I was eating a Mounds bar. Tasted more like coconut bits you’d find in a trail mix, if you will.

I probably will still not have this as a regular thing, only because I can only take coconut in moderate amounts. But still, I found this was a nice and welcome flavor.

Setting up Jenkins… things I’ve learned so far

/ hsoi / 3 Comments

At the day job I’ve been tasked with setting up an automated build system. This is a Good Thing™ and I actually volunteered to do this task. I’m interested in doing what can help us make our code better, deliver our products faster, and make our lives easier in terms of automating things we don’t necessarily need to be involved in. So a Mac Mini was obtained to be a build machine, and I’ve been working to set things up.

I should note that I’m not a dedicated buildmeister. I know at larger companies they can have a person (or persons) whose full-time job is dealing with builds, but I’ve never been one of those people. I’ve done some build hacking in the past, but it was always homebrewed scripts and systems. This time around, let’s use an established system instead of homebrew.

It seems the modern hotness is Jenkins. Yes there are other options, but all signs via Google searching point to it. As well, it seemed (note the verb tense) like the more Mac-friendly solution. If nothing else, it had a nice Mac OS X installer. 🙂

I’m still far from having our complete build system, and I reckon as I learn more things on this list will change. But I’ve already learned a few useful things and I felt like sharing and adding to the greater knowledge-base out there that, through Google-Fu, helped me get this far. Maybe with my additions, someone else can be helped and maybe with a little less frustration and time sink.

The Project

A little context about the project being built.

Working on Mac OS X, developing iOS apps. Thus we’re using Mac OS X 10.7 Lion as our dev runtime environment. We’re using Xcode 4.3.3. Jenkins is version 1.474. We use git and a mix of private and public repositories on github.com.

First Time Problems

Started with a brand new, fresh from the box Mac Mini. Of course, before attempting any of this CI-specific work, the box was brought up to date with OS updates, Mac App Store updates, and so on. Note! Jenkins is a Java app and Java is NOT installed by default. So after you run the Jenkins installer and it tries to start Jenkins, things will probably fail. The OS will prompt you to install Java, so you’ll have to do that, but then Jenkins should end up running. Not a big hurdle, but it’s there.

Make sure to launch Xcode.app (the GUI app) and get it properly happy. This is mostly ensuring the various downloadable components get downloaded and installed, like command line tools and such.

You will be using command line tools, thus you will have to run xcode-select. But being as this is Xcode 4, things are different.

$ sudo /usr/bin/xcode-select -switch /Applications/Xcode.app/Contents/Developer

This will ensure xcodebuild can be found. And note, the first time you run xcodebuild, it won’t run! While you agreed to the license agreement when you first launched the GUI Xcode.app, that’s not good enough for xcodebuild; you have to agree to it all over again via the command line. Just be aware. It’s not a big deal, it’s a first-time-only occurrence, but it’s there to deal with.

The User (login) Matters

This was the source of much fun and frustration for me.

The first time I installed Jenkins I had no idea what to expect. That it had a proper Mac OS X Installer .pkg was cool, but it was also hiding a secret. Any time there’s a “Customize” button I like to click it and see what options there are. I noticed it provided two options:

  • Start at boot as “daemon”
  • Start at boot as “jenkins”

I had no idea what the relevance of these two options were. The default was “daemon” and “jenkins” was unchecked. I just figured to trust the default installer settings. Ha ha ha…  This actually caused me the most trouble and pain. I won’t recount the many hours spent dealing with this, but I will explain the issues.

I opted to go with the installer’s default of “daemon” but that creates a problem because “daemon” is a special user. When Jenkins needs to do things, it’s going to look in non-typical places, like /var/root for ssh keys or the like. Basically, it’s going to cause you a lot of headache.

When you search around for information about this, everyone starts to talk about using the “dscl” command line tool to create a hidden secret “jenkins” user and run Jenkins that way. This makes sense because it creates a user of restricted ability so it helps to keep the system secure and minimize chance of damage should someone gain access to the system via the Jenkins system or login. But in practice, this turned out to be a big pain in the ass because of what we’re doing. I’m sure there are some projects where this won’t be that problematic. But writing iOS apps brings issues. Apple makes great products, but you find they are great as long as you color within the lines; the lines might be really wide and vast, but still you must color within them. Trying to deal with this secret “jenkins” user created various issues.

For Xcode (or xcodebuild) to do code signing, it needs access to private keys and certificates and other such things. Thus the Keychain is involved, but this hidden “jenkins” user doesn’t have one. Again, more searching will turn up possible solutions, but they are not ideal solutions. In fact, one solution of putting these into the “system” keychain really defeats the purpose doesn’t it? Then there are the .mobileprovision files needed during the signing process, and those must exist somewhere in the “jenkins” user structure. In my case, the provisioning files may be updated fairly often due to the addition of device UDID’s, and setting up the initial .mobileprovision files by downloading to the logged in user then copying it all into the hidden jenkins user locations… it was just turning into a massive pain in the ass. And you’ll have to do this at least once a year, when you renew your iOS account with Apple.

So I fumbled with various permutations of these user setups and it was all just frustrating to me.

In the end, I backed everything out and started over (for the umpteenth time). I created a “jenkins” user via the System Preferences. That is a full-on login-able user named “jenkins”, admin user. I then logged in as the “jenkins” user. I ran the Jenkins installer, customize, and selected the “start at boot as ‘jenkins'” option (and deselected the “start at boot as ‘daemon'” option). I ran the installer. That did not immediately succeed, but the resolution was simple. Stop the daemon (using launchctl). Edit the .plist for the Jenkins launchd job and changed the location of JENKINS_HOME to /Users/Jenkins. Then restarted the machine. Life was good.

I think today I’m going to try doing it “yet again” tho… deleting the Jenkins user and creating it again, then installing again, and this time making a subfolder, like /Users/Jenkins/Jenkins_CI or something like that. That’ll contain all the stuff in one folder and not litter the actual home directory.

Is this the right thing to do? Well, from a pure security standpoint, no. It’s now an admin user that can log in and have all sorts of fun. But my feeling is this machine will be behind our firewall. If this box gets compromised, we have bigger problems anyways.  Could it mean bigger problems for me down the line with Jenkins-CI itself? Maybe. We’ll see. I’m not necessarily advocating taking this approach, but it’s just the one I’ve presently taken. It appears that it will create less long-term hell for me, especially in dealing with Xcode and the OS.

Authentication

Another source of pain was dealing with authentication issues.

Since we use private repositories on github, we need to authenticate. This proved to be more difficult than it should have been.

When I first tried a basic build of our project, I installed the various git plugins within Jenkins, created the new job, set it to obtain the source via the http protocol, and off we go. Well, that failed. The job just hung forever, I reckon waiting for authentication. So how can we authenticate? I saw no configuration options for it. So I started playing with ssh.

ssh would actually be a good thing in many ways, but with all the aforementioned user/login issues, it was becoming a massive pain. The way Mac OS X seems to handle ssh is by launching the ssh-agent on demand. Well… it can’t do that for the secret jenkins user. I tried all sorts of things, but I just could NOT get it working. *sigh*   Another vote for making a fully-realized jenkins users instead of this secret hacked one.

The one thing I had to then do was edit my ssh keys to not have a passphrase, and that would work (no need for ssh-agent, no need for interactive issues). But lacking a passphrase ain’t so hot. But it seemed to work… well, at first.

The next problem? Our git project has submodules. In the .gitmodules list, the “url” for each submodule used http as the protocol. And so, when the Jenkins-CI git plugin tried to obtain the submodules, we were back to the original problem. FML.

I tried fiddling with the repository URL as specified in the “git” section of the Jenkins-CI job to be something like:

https://:@github.com/path/to/repo.git

and while that worked for the top-level repository, the submodules still tripped me up. Plus, I did not like the idea of storing a password in plain text and sight like that.

I was able to solve it tho… through the magic of the .netrc file.

I created the following file in /Users/jenkins/.netrc

machine github.com
login <github username>
password <github password>

Saved it. Did a “chmod 600” on it. And lo…. everything worked. Huzzah!

I think the git plugin should have a way of doing authentication, but I’m still too much of a Jenkins n00b to know really where the fault lies.

More Ahead

At this point, I’m able to clone our git repository and build the app. It’s very basic at this point, with much configuration and fiddling yet to come. But I spent a good deal of time on these matters this past week and tried to sift through a bunch of search engine results to wind up here. So much of the information out there is Linux or Windows based, which is fine for the general but some of the little details aren’t there. And I can’t imagine we’re the first people to need to build in such a way, but I just couldn’t find anything specific to the particulars of our setup. So here’s hoping this helps contribute back.

As well, if you the reader have any information, insight, comment, etc. please share. I’m still learning, and constructive contribution is appreciated.

My brain hurts

/ hsoi

TLG posts about yet another SERPA ban.

And reading all the comments defending the SERPA make my brain hurt. Because all the problems are due to poor training and lack of practice, and all we need is more training and more practice and we’ll never have any problems. Or at least, I’ve never had any problems and my data set of 1 (or maybe a few more people, like my friends) never had any problems. And so my point is proven.

*sigh*

I don’t know. Maybe it’s the engineer in me that says things should be as simple as possible, but no simpler.

The SERPA is not as simple as possible.

It’s design intentionally plays into what your trigger finger is otherwise trained to do — thus now your trigger finger must learn to do two things, not one, thus things are more complicated. But really, your finger is doing the same thing in both instances, and that’s why people shoot themselves with this holster. So if you want to keep from injuring yourself, you now must learn two things instead of one. By definition that’s not simpler.

More dohickies and parts means more things that can break and more things that can go wrong. I know you have ninja-like skills and will never end up on the ground, and you take meticulous care of your gear such that a pebble or grit will never ever enter the release mechanism and cause it to jam. I know it will never happen to you. But it’s happened…. just not to you. Simpler holsters don’t have this problem.

The design of such holsters fails from an engineering perspective. It is unnecessarily complex. Let’s ignore the fact more people have shot themselves in use of this holster. Let’s ignore why non-LEO’s even need retention holsters in the first place. Let’s ignore these don’t conceal very well. Let’s skip the fact that even after tons of training and practice we can still revert to lizard brain when the pressure is on, especially if things don’t go as smoothly as we always fantasized it would. Let’s ignore that someone might have a critical need to use their tools before they had the 10,000 repetitions to ingrain the new skill. Let’s just look at it from a pure engineering perspective and ask why? What problem is this solving, and is this really the best way to solve that problem? is there really nothing better? can we be willing to admit failure, if it means we can improve? and if the solution isn’t here today, then why aren’t we working on something better?

But in the end, my brain just hurts reading endless comment from the defenders. Their reasons don’t hold up. It comes off as nothing more than emotional appeals to defend their personal choices. Which to an extent makes sense… it’s how we humans work. But what are you interested in? Defending your ego, or defending your life?

True Nutrition Whey Flavor #7 – Chocolate Coconut

/ hsoi

I bought the TrueNutrition.com 38 Flavor sample pack.

Chocolate Coconut

Breaking the pink trend, and the magical color-changing powder… this powder had a brown color to it, and mixed in milk it looked brown. Like you’d expect of chocolate.

This had a stronger coconut flavor than the strawberry coconut, but not in a bad way, just more present. I actually liked this better than the strawberry coconut, probably because the chocolate tasted more natural (the strawberry tastes like artificial strawberry flavoring).

Still, it’s not my thing. The coconut just doesn’t resonate with me. Still, it was good and I found it generally agreeable.

True Nutrition Whey Flavor #6 – Strawberry Coconut

/ hsoi

I bought the TrueNutrition.com 38 Flavor sample pack.

Strawberry Coconut

Turned pink… but coconut is white anyways so…. pink it is.

In the end… no. I mean, it tastes like you might think Strawberry NesQuik plus coconut would taste… maybe like a Mounds bar without any chocolate. That sort of sugary coconut sort of confectionary taste.

It’s not to my liking. I like coconut, but real coconut. Artificial is just to sweet-fake for me.

It’s not horrible, it’s not disgusting. Just not to my taste.

2012-07-18 dry fire practice

/ hsoi / 2 Comments

Following TLG’s sample dry fire routine.

Week 1, Day 3, reloads

  1. 10 reps of wall drill from press-out 2H
  2. 20 reps reload from slidelock, slow, 2H
  3. 20 reps reload from slidelock, 3/4 speed, 2H
  4. 10 reps reload from slidelock, slow, 2H
  5. 10 reps of wall drill form press-out, 2H

I need to get another set of weighted practice magazines, but I wish I didn’t have to buy through RINGS given my prior poor experiences with them. Well, I don’t need, but it does help to have magazines of full weight and that can also allow the slide to be cycled without locking.

 

True Nutrition Whey Flavor #5 – Strawberry Banana

/ hsoi

I bought the TrueNutrition.com 38 Flavor sample pack.

Strawberry Banana.

This one we guessed might be a sort of pink-yellow color, but no… just pink.

It tastes like strawberry banana… artificial, strawberry banana. It took a bit for me to find the right way to describe the banana flavor, but I think I know it: like a Banana “Now and Later”. That sort of really artificial banana flavor.

Not really my thing.

This wasn’t horrible by any stretch. In fact, I’ve been really happy that everything has tasted good so far. But it’s just a bit too artificial-flavored for me. Another one that I could probably have a few times, but there’d be no way I could stomach 10# of it.

A Girl and a Gun

/ hsoi

A local “a girl and a gun“, Julianna Crowder is featured in today’s (July 18,2012) issue of The Shooting Wire.

Founded in February of 2011 in Austin, Texas by Julianna Crowder, a female (obviously) firearms instructor, A Girl & A Gun Women’s Shooting League was born out of Crowder’s desire to build a stronger community of women shooters.

Using a little marketing savvy and a variety of social media tools, including MeetUp.com, Crowder kicked off her A Girl & A Gun events, like Girl’s Night Out, Breakfast & Bullets, and “T” Time (the “T” is for “target” or “trigger”, natch), with just five or so participants.

And then it began to grow…and grow…and, grow faster.

This past February A Girl & A Gun celebrated its one year anniversary with 250 members. Today, they have approximately 470 members – a mere 88% growth in five months – with 11 chapters in Texas, one each in Colorado and Virginia, and chapters forming this year in Oklahoma, Louisiana, Alabama and Georgia.’

It’s been great watching Julianna work and her project grow as much as it has in such a short time.

But to author and editor Paul Erhardt, I do have to say:

A Girl & A Gun gives its members a fun, social atmosphere in which to learn about firearms, without the interference of what Michael Bane famously described as the “Little Lady Syndrome” where men are compelled to be the “experts” and end up coming across more condescending than chivalrous.

Sorry ladies. We can’t help it, it’s in our DNA.

Actually Paul, we CAN help being condescending.

Other than that, it’s a great article about Julianna’s efforts. Cheers!

Train to a higher standard

/ hsoi

There was a discussion on the Insights Training Center mailing list where someone posed a “what would you do in this scenario?” type of question. John Holschen posted some response, and this snippet in particular stood out to me:

If your question was really about the physiology of a hypothetical “hostage shot” that you have no choice but to take…
1. Anything other than a bullet in the brain or upper spine is unlikely to produce instant physiological incapacitation.
2. Not all bullets in the brain or spine will produce instant physiological incapacitation (especially from a handgun.) I.E. There are no guaranties.
On an additional note: I expect that most people in this situation would wish they were more competent in their firearms skills than they currently are (i.e. could more reliably deliver bullets to a smaller target area.)

It’s the last part that stands out.

It probably stands out to me because of this past Saturday’s Skill Builder class. We’re trying to get people to shoot to a higher standard. That B-27 target creates a horrible standard. Not just because it’s anatomically wrong, but on the TX CHL test if you get a hit within the 8 ring or higher, that’s a “good hit” earning the maximum 5 points. That 8 ring is HUGE. If you can only keep your shots within that 8 ring, you’re not doing too good. The reason is, under pressure your skills will degrade. If you can keep things in a 6″ circle even under the artificial pressure of class or competition, then when the flag flies you’ll be able to keep them i that 8-ring. If you can only keep them in that 12″ area when there’s no or very little pressure, when the flag flies you’re going to be making unacceptable hits.

I recently saw some pictures of some students that passed their TX CHL test, and the targets looked like they had been peppered by a shotgun blast (and one had a textbook case of trigger slapping/yanking). I am happy to see these folks seeking their CHL, and I hope they will seek further training to improve their skills.

In the Skill Builder, we shot at a 3″ dot and worked on groups in that 3″ dot. Then we worked to stay within the “-0″ ring of an IDPA target (8” circle) against the timer. Finally, we moved to the KRT-1 target, which has some rather small targets. The class ended with shooting the “3 Seconds or Less” drill on the A/B zones of the KRT-1, which is tougher than usual because the A/B zones on the KRT-1 are smaller than the corresponding zones on IDPA or IPSC targets.

Can you do this?

Can you do this on demand? Repeatedly?

Can you do this cold? because when you get attacked, you won’t have a chance to warm up.

You must understand that when the flag flies your skill and ability will degrade. Karl likes to bring up something Paul Ford said. Paul is ex-Austin PD and SWAT, been in a few gunfights, and Paul said something to the effect that in a gunfight you will do about 75% of your worst day at the range. So get that. It’s not your best day, it’s your worst day… and then you’ll do even worse than that. Think about your most recent bad day at the range when you just couldn’t hit shit, you just couldn’t perform. And now think about that being worse…. is that how you want to perform when your life or the life of someone you love is at stake? Or maybe you should do what it takes to ensure your worst day is at least better than most people’s best day. So that if you found yourself in that hypothetical situation that John Holschen spoke of, that you’ll have the confidence and knowledge that you can and will perform, instead of wishing you had trained harder.