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:

 

 

 

 

 

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…

Working on a simple application to let a group have a set of forms in which they collect data. Something like a simplistic form of WuFoo which lets the group update their forms and save the data to a backing data store.

First level idea: use Google Forms. Forms are very readily editable, even by non-technical folk, data’s saved to a backing spreadsheet, and you can use Google’s tools for analysis.

Implemented a first pass solution:

Advantages:
– data validation, either through their selections, through regular expressions, or (not yet tested) scripts
– really easy to share the form’s editing and responses with a set of collaborators
– very easy to add new elements
– the control set (textboxes, checkboxes, etc) are non-sophisticated but OK for my needs

Disadvantages:
– No great way to handle theming. You can pick from a set of stock themes, and there’s one sitethat seems to have found a way to handle it, but definitely not something that seems like it’s embedded in the core capability. Since I expect the group to need to adjust this ongoing, this is probably a non-starter
– No great way to link records.. e.g., if I have the same user fill out multiple things, no good way to connect them through.

OK… committed to taking a look at a first-level solution, and this doesn’t seem to be the right one. Next I’ll look at a hosted open-source solution.

Today I’ve:
– presented half-working stuff at a retrospective and then spent the rest of the day moving it forward
– figured out that one reason my widget wasn’t working was because it was being served as http, rather than https, which caused mixed-content headaches
– configured Apache to deal with https. Worked much more nicely on Linux than it did on Windows. Meaning, I was completely hosed on Windows.
– got PHP working with PDO and MySQL. No, PHP 5.3 does NOT automatically work with PDO. Though yum install nicely gets things working, once you figure out the right set
– compiled node and npm on our Linux instance, as it sure seemed nicer to pull what we need from Git directly to the box with a known build environment, rather than build it and push it up via ftp. Note: compiling node requires things like gcc and make – haven’t seen those since C++ in college. Glad everything just worked, once the right path revealed.
– reviewed a briefing deck for a meeting tomorrow… unclear what these guys are asking for, but they’ve definitely got a pitch in mind
– signed timesheets, updated mine
– talked through demo possibilities with another team

More stuff, too, including futzing with git feature branches, investigating how to create separate user accounts on the ec2 instance so that a git clone wouldn’t expose my password in history, and a few other things I’m sure I’ve forgotten…

And I thought I’d only spend 10 hours “managing” this project.. Uh, maybe that’s right. Except that most everything above is _doing_ rather than managing. That said, a healthy mix keeps me happy. Better bounds on the work day would make me even happier. Too bad I don’t give up until a problem’s solved.

Success: getting an Amazon EC2 instance up with your software running on it. Able to take a screen capture to show work actually complete before shutting down the instance to avoid running up unnecessary charge.

Despair: testing stop / restart and then realizing that your public DNS has changed, which means your site can’t be bookmarked, its certs no longer work, and you have to update a properties file with a new host name.

Hope: the box itself still has your stuff on it, you can log in with the same keys, and there’s this thing called an Elastic IP available for a charge from Amazon.

Elation: stop / restart works! New user ids granted through IAM, console renamed to give something useful, PEM sent out for access, and JIRA ticket marked as resolved.

Contentment: Now time for bed, in time to wake up and think of the other three things you wanted to accomplish in the evening with Fringe playing in the background courtesy of NetFlix.

About to have a discussion about potentially putting some effort into a project within our company to clean it up and possibly make it available open-source (geek indicator 1). Had a discussion about open-source with the corporate CTO and Chief Engineer, as well as others, earlier this spring (geek indicator 2). Trying to find my notes from that meeting, I end up discovering new flags for Windows 7’s search capability (geek indicator 3: the regular search was taking too long – needed more flags to make it precise), as well as a whole host of new command-line capabilities in Windows 7 that I wasn’t aware of (thinks that’s cool: geek indicator 4). Hunting through notes on my iPad, on my laptop, etc. Finally found my notes written on paper in my organizer, based on a search of Outlook’s calendar to find the date of the original meeting. Geek fail, though personal success.

Other geeky goodness: in the past few days, I’ve stood up an LDAP server on an Ubuntu image on EC2. I’ve configured CAS to interact with that LDAP server. And I’m now rebranding CAS to handle the look and feel I want for our corporate demo site, using Jetstrap to give me a Bootstrap skeleton. I’m explicitly not linking through to all that stuff because the folks who know what it is already know what those things refer to, and the folks who don’t really aren’t going to want to wade through it all. Count it as a mercy non-linking.

My kids gets this amazing summertime experience: long days, little to no schedule, and family members around to be able to do things. They have the benefit of a stay-at-home-parent, so we don’t need to send them somewhere to fit into someone else’s schedule. The rub: they’ve got no driver to do anything in particular. So, every summer I ask each kid to think about what they’d like to learn or try over the summer. Callie and I in particular have had a great time building these lists. Last year’s list had everything from ‘go to a tea party’ to ‘rollerskate’ to ‘learn to unicycle’ to ‘go camping’. We didn’t accomplish all of them, but it was a lot of fun to both think up the list, and then also to get to cross things off. I also think it’s important to point my kids to thing towards bigger ideas and goals, to not just live in an hour by hour what keeps me from being bored kind of mental model.

I have an informal summer list this year… things on it include ‘learn to juggle 4 balls’ (I can do 3, but have never solved 4), ‘unicycle’ (we didn’t solve it last year, but now have two unicycles to work with), and ‘write a mobile app’. That last one’s for a contest with a deadline. Deadlines are good things. I’ve had that same unicycle goal on a list of 100 goals since 2007… Some of the other 100 goals I’ve met: I’ve driven a motorcycle, gotten another tattoo, taken my family to Disney, and read the Bible through completely, as well as a few other goals. Of the original 100, I’ve accomplished 12 1/3 so far. The 1/3 comes from a goal that says I’ll crochet an afghan for each of my kids. 1’s done, 1’s in progress (been in progress for a while) and the last hasn’t started.

Looking over the list, none are ones that I want to strike, though a few have gotten more complicated. It was simpler to visit my grandmother once a month when she lived in Silver Spring rather than out near Cumberland: think that one will be amending to ‘visit or call’. I could see adding new goals prioritized over the original batch of 100. For example, I want to earn a most-valuable-player ring from my rugby team, as well as want to win a championship with our team. Those goals might come ahead of ‘spend at least a week touring in Australia’…

Revisiting the list helps kick me out of my own personal rut of whatever I’m dealing with day-to-day to remind me of big dreams and the idea that some things are worth planning out small steps to get to bigger dreams. That’s one of the things I want to teach my kids, as well as remind myself. Going to go sketch in some ideas for my mobile app…

After a pretty lousy day at work, had great fun geeking out a little this evening.
* Lego WeDo – spinning ducks! (first efforts at activities for a corporate Women In Computing Day this Sunday… LOVE that the women in our company are now pulling this together for the 3rd year! Uh, linked video is not me or my child commenting…)
* Used a random number generator online to pick the winner of a 50/50 raffle to benefit some rugby players fundraising to go to Russia for the World University games. These ladies are all Naval Academy midshipmen, so have some significant restrictions on how they can fundraise. Help them out via their fundraising site
* ThinkGeek has a Mother’s Day section! Uh, not so keen on the whole idea of cosmetics on ThinkGeek. That said, superhero socks (somehow listed in the cosmetics section?) would be pretty fun to have peeking out under slacks at work on tough days…