Saturday, April 30, 2016

Hi everyone!

Anyone who knows me, knows that I listen to a LOT of podcasts. In an attempt to blog more regularly, and to be able to search for things that 'I know I heard somewhere!' I'm going to try to keep track of things of interest in podcasts and blogposts that I've read.  If I I can keep active enough with this, I may try rolling it up into a weekly feature!

SE-Radio #225: Monicia Beckwith on Java Garbage detection.

This episode talked about the history of java garbage collection algorithms.  I found the discussion on generational garbage collection really fascinating. That was how copying young objects back and forth performs automatic compaction. You also can 'age' the data, since your program typically has  two types of memory.. quickly allocated and abandoned objects and long lived objects.

There was some discussion about GC usage and optimizations, about how some systems with really tight 'worst case' latency requirements actually will have a clustered design, and take nodes offline and manually initiate their really slow, but full heap garbage collection while the other nodes are still online and accepting traffic.  There were some command line flags mentioned, but I was mowing and didn't write them down, but they are useful for looking at some of the really simple information put out by the GC, and you can view them with histogram tools to analyze your usage patterns in preparation for tuning.  

Things to ponder...  The GC patterns are dependent on your application and it's usage patterns.. I wonder how the signature of garbage collection changes when you are using immutable data structures, and some of the other languages that run on the JVM?

Partially Derrivative: S2E8: The Love child of Princess Leia and Jabba the Hutt
They talked about using Machine Learning and Data Science to categorize StarWars spoilers and help keep people from seeing them.  The persons work was made available as a chrome extension..

Also, they had a segment where they talked with Micheal Kennedy of Talk Python to me about Software Engineering tips, and he gave a discussion on Generators and Co-routines. This is a topic I've heard about, but need to get more in-depth with.  I've been hearing lots of episodes talking about different functional programming techniques, and need to start seeing how I can incorporate them into some of the things I do each day.

Things to Ponder... He gave a list of languages which have concepts like generators and co-routines... Do any of the langues I use have them?  How could it be applied?

Thursday, April 7, 2016

Testing Custom puppet facts

Hey everyone!

I've been a bit distracted for a while, but just wanted to post this tidbit here..

I recently stumbled across this post on testing Custom Facter facts  over at the blog unethicalblogger.com, written by the creator of the Jenkins module for puppetR. Tyler Croy.  

It highlights a solution to one of the problems that I faced when I started learning how to test my puppet code.  For unit tests of functions and and manifests/catalogs, rspec-puppet and the puppetlabs_spec_helper gem are great places to start testing your code (along with some great examples from rnelson0.com). 

There are still some holes in your unit testing strategy (ignoring beaker for integration testing for now).  Custom Types/Providers and custom Facter facts!  The link above addresses the custom factor facts.  

Only having dabbled in ruby (mostly to aid my understanding of puppet), I haven't been fully versed on the full power of rspec. So it's good to seen an example where they take a more rubyish approach to the layout of their code to aid in testability.  It may not seem that important for your own small module that only you use, but if you start to have facts which are full of moderately complicated logic, you have multiple people on your team editing your modules, and you want to prevent regressions, it seems like the way to go.  

I won't rewrite the article here, but basically they take the 'script' feeling of a traditional Facter fact, which is hard to test, and they refactor it into a proper collection of ruby modules/classes, add in tests for all of the parts of the module, break up behavior into separate easily testable methods.  To plug the 'ruby' code into facter, they have an '#install' method which just calls the module's main entry point, and returns it's values to Facter.add().

Happy trails everyone, and I hope that some of this information can help guide you to having some solid tests on your puppet module's facter facts!