Wednesday, May 4, 2016

I've decided to pull my home automation code into Github. Why? because it's time to share :) When I did that I saw that at one time I had hooked my Github account up to this blog space.

This code has been humming along for about 3 years, all written in anger when we returned from Barcelona and started wrapping up our home's remodel.

What the code does is integrate our security and lighting systems, which are all high(er) end and not meant to be integrated by mere mortals ( fee-paying approved integrators.)  I also used it as a learning context for ... stuff.

Meaning I'm pretty good with Java, Oracle/fooSQL, all sorts of scripting languages, mad integration/gluing of desperate things blah blah.

But I hadn't been keeping up ( read: billing )  with the fractal fuzz going on in web integration.

The code is node.js, which is a bit ironic given how much time I spent working/billing with Livewire at the dawn of the commercial web.

The backend has been a few of these NoSQL databases.

ok back to it.

DFRobot Rainbow LED Ring hacks

Been a while. hmm.

I'm now living in Barcelona. Have been for a few months, as part of my wife's adventures with Mozilla.

anyhoo I've been doing some hackish things and thought I should annotate them for anyone else following this path.

The most immediate thing I hope to save someone some time with involves programming with the DFrobot Rainbow LED thingy.  A couple of quick notes

documentation is sparse. I haven't found the current specs.

OOTB its libraries require 022. A clever Italian dude has published suggestions for converting the provided libraries to 1.0.3 but my first pass didn't work.

The examples jump around between two different Optiboot hardware profiles, and show things which don't work at this point.

When using the Optiboot Lilipad ATMega 128 the only baud speed which works is 38400.
When using the Demiluva.... ATmega 128 the only serial baud speed which works is 19200.

when adding the Parallax Ping))) module use the NewPing library. The only hardware profile which works accurately is then the  Demiluva...Nano ATMega 128.

Holy Cats

... I had, in the midst of tearing down my house, moving to Barcelona, moving back, finishing the house and putting dear kiddo into a brand new STEAM high school - forgotten that this existed.


well. hmm. I have a fair number of projects at hand :O

Thursday, July 14, 2011

old notes: FCP development opportunities?

This was written a long time ago, serving as notes to myself for development opportunities outside of my usual sphere. Now that FCX is out these points are moot.

Summer 2010 attended DMA  Final Cut Studio integration class. Expected workflow and FCP server training. Didn't really get to much of that. Excellent. Mark Spencer, Motion expert, instructed; we hammered a lot of Motion projects out. Totally inspiring.

things which stood out:

 FCP/STPro: when you send from Final Cut Pro to Soundtrack Pro an entire sequence is sent. In and Out points in a given sequence are ignored. OPPORTUNITY: possible to build a FCP plugin which builds a new sub-sequence from the In and Out points and sends that? or to build a new stand-alone sequence and send that?

STPro: in class we did an exercise where we removed a chirping bird. this was done by 1) switching to spectral scaling, and then using the Spectrum vew HUD to dial in on a frequency range. we then used a bounding box to select the bird chirps and delete them. OPPORTUNITY: have a pencil tool which reduces the energy level / DB as one paints over the range in teh Spectrum view. Sort of like the older sound/frequency painting tools, or that crazy audio painting tool MetaSynth.

Preference files: STPro effect references are stored in .pst files. the finder lists these as logic pro files. it would be nice if there were a guided text editor for these.

FCP: when applying audio level fades to multiple clips in a track ( select forward tool ) ( once it's the "favorite" ) the scale filter will apply without taking into account the length of the clips. my notes show that there may be an opportunity in analyzing the ramp-in and out  of a crossfade and keeping the slope, altho right now I don't know what that entails. If that means keeping the slope then the time can't change. Or does that mean looking at the dB and scaling to match?

OS: Kenneth would like a file browser/view which will browse audio and video by durations of their content. used for picking content.

FCP / Compressor: Since scripts can be run one @ completion could make a mess of simple Growl scripts to provide notification within a server pool. heck most anything, tweets, macspeech

COLOR: there is a "Still Store" in color. Wouldn't it be cool to make a HTML document which contained JPEGs of the StillStore for 'approval' in a workflow? or at least cataloging peeps wld be crazy to approve tweaked video from  jpegs.

DVDSPro: transitions? apparently there are not a lot of transitions for menu selections. At least there could be some crazy ones. this would be quartz?

Wednesday, December 1, 2010

a branch of SlingRuby supporting remote integration ntesting

So I branched my stuff and started in by removing localhost hardcoding.

here is the multi-session worklog:

  •  add 2 new attributes, host and port.
  •  on init parse the 'server' argument extracting host and port
  •  add accessors for host and port.
  •  these changes will make it easier to port the older scripts which hardcode a localhost value.
kern-1105.rb - tried not to change the style of this test.
  •  replace hardcoded constants with framework server instance's accessors
  •  get adminuser auth from Slingusers::User.admin_user hmm may want to do this across the board in a later sweep
kern-568.rb - this one is of interest due to the chance that the timezone of the target host may be different than that of the testing box. In order to test the timestamps across timezones I modified the tests to parse the timestamps into a common, comparable format. Tested by poking against the Indiana QA server, a far different place than Belmont California.
  • Time.parse() introduced
kern-577.rb - This test's localhost issue is in the teardown. no biggie.
Wasn't able to run consistently against the Indiana QA server. Runs fine against localhost. 3akai is having proxy errors just now.
 I am finding is that kern-577 cannot consistently create a user at Indiana, and when it does it cannot consistently create a link to the user's test-uploaded document. ( gets a 500! ) It does sometimes pass, but it sure is flakey. ( return a day or two later) OK now. To be expected in a fluid environment.
  • use Sling.url_for()
kern-797.rb - another teardown tweak
  • use Sling.url_for()
kern-854.rb - just a couple of lines, but this fails on tear-down. I'll revert to be sure that it works without changes. yep, when getWidgetServiceConfiguration is called against remote hosts ( or Indiana ) it must not return whatever is expected. Lance's page shows that 854 fails when run locally too. OK I'll move on for now :)
  • Sling.url_for() in WidgetServices methods
kern-857.rb - this is simular to 854. works OOTB against localhost, but fails against remotehost due to hardcoding localhost URL The test has a utility method 'getWidgetServiceConfiguration' which is, well, getting the service configuration. This too currently fails on the QA server, so I'll just plug along with my code localhost changes...
(later) fixed this and 854 by changing the xWidgetServicesConfiguration foo methods to use the Sling classes url_for() method. The code was putting in double slashes, which were failing.
  • Sling.url_for() in WidgetServices method
kern-891.rb - is much like kern-577 a teardown use of localhost. swapped in the url_for method :)
  • Sling.url_for()

That's it for the kern's. now for the tests. The first on my list

  is a false positive. 

 had a few hardcoded localhost URLs which I modified to use the Sling service's setup

 This test had failed because I don't have mailtrap installed in my ruby repository of gem wonder. This test runs mailtrap on localhost, so changing it to something else doesn't make sense. Now to go see what mailtrap is. yeppers. makes no sense for a remote host test. sweet.

Next Steps

Roll this stuff into my branch, then update my checkout against the current master to see what I've missed.

modify tools/runalltests.rb to contain a 'remote' blacklist. Not sure how it could tell now :) I'll take a big swing, add a "remote" flag, and have runalltests.rb do the sed stuff I posted about earlier.

use one definition for admin user. this is just clean up, but it'll make it easier for folks who change their default admin user down the road.

modify / remove timestamp based userID generation to use new User service method using random numbers. ( check speed )
extend the users module thing to centralize creation of temporary users. doing this will reduce ID collisions in multi-load/thread testing

Tuesday, November 23, 2010

running Sakai3 Ruby tests against remote hosts

The Sakai 3 checkout comes with a nice set of Ruby test coverage. Reviewing tests is a good way to learn the landscape of a given system, which is why I'm poking around with this Ruby and Selenium stuff.

All the Ruby tests can be run via a utility script: tools/runalltests.rb

The tests run on localhost.

If you want to run the existing tests against a remote host you can manually modify the Ruby testing setup script to point at your target host. You'll get some errors, but later for that ;)

Or you can use this script to modify the testing framework, temporarily pointing it at an arbitrary host and then run all the tests. When it's done it returns the framework to the original state.

# edit test.rb to point to a remote server
# and then via tools/runalltests.rb run all tests
# found in:
#   SlingRuby/kerns
#   SlingRuby/tests

# make sure we have an argument

if [ $# -ne 1 ]
 echo "Usage: $0 TESTHOST_URL"
 exit 1


# some variables
# NAK_HOME needs to be set to your checkout/workarea

# the current runalltests script in NAK_HOME/tools expects to be run
#     from the SlingRuby directory

pushd $TEST_HOME

cp ./lib/sling/test.rb ./lib/sling/test.rb.bak

# in-place editing fun
sed -i ''  "s!Sling\.new()!Sling\.new('${TARGET_SERVER}')!" ./lib/sling/test.rb

# stash the result away for later inspection, or not.
cp ./lib/sling/test.rb /tmp/test.rb.EDIT

# run all the tests in TEST_HOME/kerns and TEST_HOME/tests
#  except now the test setup will point at your TARGET_SERVER


# repair changes to the testing framework
mv -f ./lib/sling/test.rb.bak ./lib/sling/test.rb

# go back to where ever you were

Remote targeting can be useful for quick A/B comparisons.

I suppose this retargeting idea could be built into the current runalltests.rb script.
What I didn't see was a way to easily mongle server retargeting into the current test framework.

You will experience errors.
Tests were not written with this kind of use in mind, so you will get funky race conditions and conflicting states. Also some of the tests are hardcoded to use localhost, so they'll have trouble.

If the various ID generators were slightly tweaked to generate more unique IDs, and the use of localhost removed, these tests would run against arbitrary hosts.

You could use this technique to crowdsource load against a common target server. You and your evil pals would fire up a flock of shells on your local machines and point the test suite at the target server.

Localhost tests:


OK time for me to cook a stack of gluten free pancakes for my crew!