As part of some code for a not-yet-publicly-visible project, I needed to extend an existing Javascript API.  Because I know my code generally needs all the help it can get, and because our team does unit-testing, I’m building it out via TDD: write a test that fails, write the code to make it run, rinse, repeat.

Challenge: our team is using PhantomJS to run Jasmine tests via karma.  All of the rest of our infrastructure, both test and development, makes use of RequireJS to handle dependencies.   I’m not well-versed in RequireJS, but it hasn’t been an issue so far, as I’d been extending stuff already built out.  Today, I needed to test code that was in a new set of files I’d created.   Wasn’t working.

Collecting notes here in terms of what I needed, which also provides clues to the discerning reader of what bit me….   My hope is to revisit this post sometime in the future and amend it as I’m a bit more expert in all of these areas…

– my code needed to be set up as a Require module with a define() block at the top, even though the thing I’m extending isn’t in a require module.  (We cheat and stub out our other invocations of the underlying API, so this was a new thought to me, that I needed to set this up as a Require module itself…)

– that module’s function needed to return something.  Just having things happen in the function within the define block really doesn’t do it.

– the new module needed to be made visible as a name in my test-main.js

– the new file needed to be made visible to the configuration to Phantom

Beyond the TDD, to then have my new module work within my webapp, I no longer need to link explicitly to the Javascript file, but instead just let our RequireJS stuff do its magic.   That required both adding it as a referenced package within our dojoConfig and then also adding it in as a dependency to the primary app module itself.  Not sure I’ve got in the spot I finally want it, in terms of usage within the app, but I can at least see my code come in/through now.

Takeaway: Lots of places to put things to make things “just work”.

 

 

 

After too many bits of time spent wondering, “how’d I make that work, again?”, I’m finally getting around to figuring out how to automate a development environment.  Starting out by doing some playing with Vagrant. The idea is that with each project I build, I’ll set up a script to build out a virtual machine with its dev environment. I also want a set of scripts to build out a deployment environment. E.g., bundle together OWF, a security plugin, the plugin’s configuration, and maybe a custom theme for the OWF instance.  Preferably by doing so in some sort of pluggable way.  E.g., I could mix/match what I want by pulling in bits and pieces from various places.  And then readily have a build/deployment script path for pushing to our EC2 demo instance.

Not sure yet whether the right toolkit is Chef, Puppet, Ansible, …  just have gotten to the ‘gotta have a solution’ level.  Since one of the guys in our office made available some Ansible scripts related to OWF which I’d offered to test/share out with the OWF community, starting there.  Since Ansible doesn’t run on Windows, that backs me up to trying out Vagrant to set up a Linux machine off of my Windows box.  I’m taking Vagrant’s tutorial path of using VirtualBox.  (I’ve had VirtualPC on my box for a bit, but that’s been purely to let me do IE7 testing on a machine running IE9.)

Progress today: got his Ansible scripts running, after some hiccups getting the right version of Ansible to hit my virtual machine.  Oh, and I committed my first potential pull request possibilities to his devops repository.  Like the Vagrantfile that sets up the right version of Ansible…

 

 

 

 

Hashtag trending on Twitter: #FiveWordTechHorrors

My favorites seen this evening:

 

 

 

 

 

The Post has an article about Target hiring a former CIA agent to give parents guidance on how to get your kids’ Christmas list, hide the presents, etc.  Parents need guidance for this?  Half the fun of being a parent is thinking through these things.  Tucking the gifts away in the back corner of the “scariest” room in the house.  Scary here can mean it’s dark, or that the kids know that entering that room is likely to give them the chore of cleaning it up.  Handling the Santa presents versus the mom and dad ones by changing your handwriting on the gift tag by using your opposite hand and wrapping the gifts in different wrapping paper.  Having the kids do the Santa letter at Grandma’s house so that she can pilfer the letter from the mailbox as soon as the kids have gone home.  (You do have to make certain not to get caught with that letter in hand: I found Cameron’s on the kitchen table this morning after some late night shopping… would have been a bad scene had he come out for breakfast when called.)

I was the kid who would find the presents in our house.  I remember how much fun it was to go sneaking around.  So now when I catch Callie doing the same thing, I leave one present in a place she’ll find.  But I make it the most educational/boring/oh my goodness how could my parents get me that present, just to see if she’ll confess her knowledge and thus display her means and methods.  Oooh, so much fun.

I did pick up a new trick from the article – hadn’t tried having the kids write their letters in invisible ink.  That’s a good one.

 

 

Continuing on with my geek volunteer efforts, after some conversations with the ‘client’, we discovered that not only do we want to collect some information via forms, but the folks who fill out these forms will want to register for classes and be paired with a mentor.   Aha!  That starts to sound like a customer relationship management (CRM) system or one of the learning management systems that lots of colleges are using lately.  I knew of a few open-source solutions, and figured this was a good reason to do some exploring.  Idea on my part is that a custom app ought to be the last resort, unless the custom app provides a real advantage to the group.  Otherwise, someone’s gotta be willing to take on maintenance and hosting of that app if I’m hit by a bus / win the lottery.  This application isn’t, at least at this point, something that this organization wants/needs to invest in.

Open-source CRM – after surveying a bit, narrowed in on SugarCRM, specifically its community edition.  Its AGPL license is a challenge in terms of integrating other capabilities were I need to extend Sugar, but since I’m trying to go with vanilla and just use its customizations, believe it’s readily workable.

Open-source LMS – the clear community leader at the moment is Moodle.  As its GPL, rather than AGPL, the license headaches are mitigated a bit, as long as the group doesn’t attempt to share out its source.  (Note: not a open-source license expert: statement is my understanding – confirm before assuming it’s right..)

But licensing will only matter if the solutions are the right fit…

Shortening the story a bit…  I went ahead and stood up a Moodle instance on an EC2 instance.  I found a plugin to collect survey information related to student classes.  Since Moodle had that idea of surveys + people, adding SugarCRM to the mix definitely seemed the wrong way to go.  Moodle installed nicely, as did the plugin, but in the end, it just felt like the wrong use case fit – too much complexity, and then not enough control over the user experience.  Note: were I to customize the Moodle code or write a new theme, I assume I’d have had full control.  But it was a higher hurdle than I wanted to leave for those who came behind.

The same underlying technology stack that Moodle uses is also used by a composable system called Drupal.  Headed that way for part 2 of this app…