Integrating Jasmine with Travis CI

One of the things I’ve been wanting to automate with our Harmony Lab project is the javascript test suite so that it runs via Travis CI. I tried once before, but hit a wall and abandoned the effort. I recently had the opportunity to work on this as part of a professional development day in ATG, which is an excellent practice that I think all departments should embrace, but that’s a topic for another day. If you’re not familiar with Travis, it’s a free continuous integration service that provides hooks for github so that whenever you push to a branch, it can run some tests and return pass/fail (among other things). Getting this to work with a suite of python unit tests is easy enough according to the docs, but incorporating javascript tests is less straightforward.

Harmony Lab JS tests use the Jasmine testing framework and all of the unit tests are created as RequireJS modules. This is nice because each unit test, which I’ll call a spec file, independently defines the dependencies it needs and then loads them asynchronously (if you’re not using RequireJS, I highly recommend it!). Running the Harmony Lab tests locally is a simple matter of pointing your browser to http://localhost:8000/jasmine. This makes a request to Django which traverses the spec directory on the file system and finds all spec files, and then returns a response that executes all of the specs and reports the results via jasmine’s HTMl reporter. But for headless testing, we don’t want to be running a django server unless it’s absolutely necessary. It would be nice if we could just execute some javascript in a static html page.

It turns out, we can! The result of integrating jasmine with phantomjs and travis CI is Harmony Lab Pull Request #39. You can check out the PR for all the nitty-gritty details. The main stumbling block was getting requirejs to play nicely with phantomjs and getting the specs to load properly. The phantomjs javascript code, that is, the javascript that controls the browser, was the simplest part since it only needed to listen for the final pass/fail message from jasmine via console.log and then propagate that to travis.

Basic LTI Tutorial Using PHP

Introduction

This tutorial will get you up and running with a development environment, complete with a virtual machine running an Apache 2 server with PHP, a basic LTI library written in PHP, and a simple basic LTI-compliant LMS. By the end of the tutorial, you will have written a simple “Hello, World!” LTI tool, and you will be ready to delve into the world of LTI coding. Please note that we assume you already have the following knowledge:

  • An understanding of directories and files, and how to navigate through them using a terminal window on your operating system;
  • How to install software packages on your operating system;
  • An understanding of fundamental web concepts, such as HTML, CSS, HTTP requests, POST requests, etc.
  • Some experience in setting up web servers;
  • Basic knowledge of PHP;
  • An understanding of basic LTI concepts and, in particular, the Basic LTI (v1.0) specifications.

Ready to begin? No? Then grab some coffee or another refreshing beverage. We’ll wait. . .

Ready now? We hope so! Because we’re getting started.

(more…)

Pages: 1 2 3 4

Posted in LTI. No Comments »

PeopleSoft and Star Trek

When I first encountered peoplesoft, I was woefully underwhelmed. Like something a newbie PHP person would have written 10 years prior. In fact, I’ve worked with dozens of similarly functioning sites over the years, so it honestly wasn’t a big deal.

I think I first noticed it was a big deal when I got an email about a year ago from HR, saying they’d give bonuses to people who referred Java and PeopleSoft professionals. That got me to thinking PeopleSoft and Java developers were roughly equivalent. I noticed the positions for them were being posted at roughly the same grade. I didn’t think much of it beyond that.

Recently I figured out what PeopleSoft development actually is. It’s not coding at all. It’s configuration management. Not too far removed from someone who can work in Drupal. I was floored. Not because there’s anything wrong with that, but because such a focus was being put on configuration over custom. I find this both refreshing and scary.

WilWheatonI woke up the other night and couldn’t get back to sleep thinking about this. Was this the future of web development? Configuration management? Was web development eventually going to become 90% “PeopleSoft”? I’ve even been thinking it made sense because Welsey Crusher — while gifted — was not the kind of person I saw coding the woman in red in C. That would require a team of developers. Sure, maybe there’s some awesome libs in the future, but more likely programming in the future will be tantamount to drag and drop. I mean, think about how they controlled the Holodeck, they were giving basic commands, parameters and values. Voice activated PeopleSoft.

Eventually hardware will get better and better, and the bloat of PeopleSoft and like platforms will be less of an inhibitor.

Eventually is a ways away though. Today, speed is paramount. Users demand immediate gratification, and that requires optimization. And PeopleSoft can’t meet user expectations in that way. So it just remains a corporate institution. Something people will put up with because that’s what’s been sold to them.

Gamifying Work

HabitRPG

My character, currently attired as a pirate, standing next to his pet, a flying pig.

I’ve always wondered how one might go about gamifying the workplace, and quite by accident, I discovered a way how. Although not specifically designed for work, HabitRPG is a “free habit building app that treats your life like a game,” and I and a colleague have started using it to gamify part of our work-life.

If you are like me, there’s plenty of things to do at work, so many things that it’s very easy to lose track of what one needs to do, so I take advantage of to-do lists. Every day, I create a to-do list of work that needs to be completed that day, even if it’s a simple thing, such as getting onto my Instant Messenger account or checking my calendar (seriously, as sad as it seems, if I didn’t remind myself to do these things, I wouldn’t do them). And if an item doesn’t get done, it gets pushed to the next day.

HabitRPG transforms to-do lists, as well as your overall habits, into a simple fantasy role-playing game (RPG). Like most of the RPGs in the fantasy genre, you undertake a persona called a “character” who starts out as a lowly adventurer. By completing quests, you gain experience, gold, and other treasures that help your character slowly build him/herself into a hero.

Quests in HabitRPG take on the form of individual habits (such as “isolating oneself for 1hr to get something done”) or individual items on to-do lists. When you complete a habit or an item on a to-do list, you are rewarded with experience, gold, and, if you’re lucky, you might find a piece of treasure you can use later in the game. The more you complete your tasks, the more powerful your character becomes.

And, as in any RPG, your character is in constant peril. Uncompleted tasks deal out damage, and if your character receives too much damage, your character will die. Never fear, your character will be resurrected, but there will be penalties, such as a loss of experience and treasure. This mechanic forces you to stay on top of your to-do lists, for if you let them go, you’ll pay the price.

I’ve started using HabitRPG for all of my to-do lists, including the one I use at work. I won’t claim an increase in productivity or anything like that, but the game does make keeping track of my worklife much more enjoyable than it used to be (and I get rewarded if I do something I normally procrastinate on, such as writing a blog post). Also, there are ways to team up with other players, such as your co-workers, which might make the workplace an even more congenial place, but we haven’t tried those aspects of the game yet.

The rules and mechanics to HabitRPG go much deeper than I have described–tasks can have different difficulty levels, you can collect and feed pets, you cast spells. . . just to name a few of the complexities of the game. But, overall, HabitRPG operates on a simple premise: For every task in life you complete, you and your character become hardier and stronger.

 

Scrum vs Kanban

I wanted to learn about Kanban — as I wanted to see what the “alternative” to scrum was. What I found pretty quickly was that they are not equivalent systems.

One big thing I found was that Kanban isn’t a replacement for scrum. It’s actually a very small change management procedure that is supposed to be introduced to an existing process as an added layer, which can be used to help make incremental improvements.

Kanban is super simple. All it is, at its core, is custom workflow steps with limits on how many items can be in each step. It’s a visual way to keep track of where your “stories” are in process and limits to keep too many things from being “in process” or “in testing” at one time. In that way, it’s supposed to help you keep on target, with minimal context switching.

Pro-Kanbaneers state the weaknesses of scrum are

  1. Unclear development steps
  2. Context switching
  3. Partially done work

I’m not convinced “unclear development steps” is a real thing, because they’re mostly saying scrum is confined to 3 or 4 workflow steps (“on deck”, “in process”, “testing”(sometimes), and “done”). I’m pretty sure in scrum you’re “allowed” to have custom workflows, where the development steps become more clear. But there is a real problem that comes up with being bottlenecked in the sprint and having to carry stories over to the next sprint. And context switching is always a problem, but not really avoidable…

There is a perception of scrum that it’s very rigid. I’ve never felt that way, but then, it’s not like a read any books on scrum. I’ve always through it was adaptive — because doesn’t it have to be?

We deal with partially done work by either breaking stories out into smaller stories or breaking out tasks and making sure the tasks that are done are complete and the hours recorded (so that our hour burndown is useful). But maybe my perception of scrum is wrong.

Though the more I read and listen to about agile, the more I feel people are missing the point. They say the word “agile”, but the word loses its meaning if you’re not agile… The whole reason agile exists is to make processes more adaptable, to make people more amenable to change. It’s all about constantly changing and adapting to what is needed.

References:
 http://scrumcrazy.wordpress.com/2013/02/…

 https://groups.yahoo.com/neo/groups/kanb…

Posted in Uncategorized. No Comments »

Accessibility and Mobility and Web Development

Mobility and Accessibility are not new technologies that have come up. They are not extras that some of us need to tack on to what web developers do.

They are an essential part of web development and should be considered as basic skills.

Accessibility is not hard. It used to be, it really used to be, but with HTML5, it’s actually quite simple. Simply a small part of the HTML5 spec, something web developers should know. Mobility was a hot new topic 6+ years ago. Now it’s expected that the applications you build are in some way available on a mobile platform.

It is an expectation.

Why is this not the reality? Why are web developers still making applications the same way they were 10 years ago? It partly has to do with web development being a “full stack” profession for so long. Traditionally, the front end has been small and the back end has been “the application”. The direction of the web is putting more of the application on the front end, so developers that are considered full stack have to now know more than basic HTML and the minimal JavaScript it takes to do some validation. JavaScript has become huge, for large applications, it requires its own framework.

I don’t think that’s been adequately realized by the web development community yet. The future of the web is a partnership, where the applications are separate. the back end an API, the front end the “actual application” that gets the data it needs from the API. As such, people are turning more to micro frameworks for the back end, and away from what had become the staple Rails clones — and much further away from the even larger, more complex frameworks.

SPA-Architecture I’m not sure if Single Page Applications are truly “the” future. But they are the now. It is important to stay on top of this, as this industry is constantly changing. But one thing is for sure, if you’re a business fully invested in back end developers, you’re hitting a problem where you feel like you need to hire “UI specialists” when you really need either 1) for back end developers to beef up their front end development skills or 2) to hire developers focused on front end “development” (as opposed to graphic designers).

Mobility Workshop

gold stick figures sitting together working on their gold laptopsA couple of months ago, we had a very successful presentation on vagrant/puppet. Given by a developer, it sparked motivation in some devops enthusiasts to give a workshop. It went really well. (Vagrant Tutorial)

They had a great format with their workshops that seemed effective. They were super enthusiastic, which translated to super prepared. They had created a wordpress post that was a very detailed, step by step instruction on getting started.

The interest and effectiveness of this sparked motivation to do “other topics”. So I put together this tutorial on mobile development, “featuring jQuery Mobile”.

I thought the idea of something where I had the material prepared beforehand and could just say “go” was a great place to start. This shouldn’t be a presentation, it should be an opportunity for people to get their hands dirty.

I was running through tutorials and found a lot of them had put their code on github. At some point I had the idea to use branches to “step” through the tutorial. The way I envisioned the workshop going was to start with nothing, and build out a mobile app through logical steps — as a lot of tutorials do. Do a header, do a menu, do a list, do a link, do a transition, do a search. Coming up with a list of “things to do” was easy.

Putting it together with github also meant I could just put the directions in the base readme and it would be a completely self-contained tutorial. (Not to mention, having it in git allowed me to force people who I know don’t want to make the switch out of SVN to use a VCS that is so much nicer.)

Anyway, the finished draft took a long time. It was a lot of easy stuff, but time consuming.

(Mobility Workshop)

The most important part came after the draft was finished. I gathered some team members and some cross-team members — basically whoever would come sit with me and had them run through it to see if it made sense. They were brutal. It was great. A lot of this work happened after hours, so the language was at times, very stream of consciousness. Having people with varied familiarity with the topics covered allowed for some invaluable revisions.

Overall, the workshop proved to be a wonderful exercise in collaboration and teamwork, and regardless of how the actual workshop goes, it has left me better than I started, so that’s good enough.

Accessibility, I’m Still Wrong!

A while ago, I talked about the legal requirements for academia web development. I pointed to Section 508 because it was “just another section” of the Rehabilitation Act of 1973, and Section 504 was DEFINITELY required.

I was wrong.

Upon further inspection, we are ONLY under Section 504 because Section 504 is a matter of civil rights, while 508 is “just a guideline”. Section 504 (or title III of the ADA (American’s with disabilities Act of 1990)) is what people reference when filing suit. 508 is not directly enforceable outside of government agencies. Even then it can be trumped by 504.

So when doing things in academia, using 508 is useful in that it will get you 90% of the way there, but that 10% can still get you under 504. The trick is it’s not clearly defined. It’s left very ambiguous. This is probably a good thing from an accessibility standpoint because it can remain technology agnostic.

So stick to WCAG 2.0 AA.

Using jQuery in Node with jsdom

After having watched a ton of Node.js tutorials (and TAing for a JS class), I decided a while ago “for my next script, I’m totally going to use Node.”

So I finally got the opportunity this last week to write a script. Tasked with a menial job, making a script to accomplish it brightened my day.

The first script was dealing with an xml api feed. So I immediately found xml2js, a nice converter and set about looping through some api urls, collecting the data I needed and totaling it up. It was a mess, and looked like this:

var https = require("https");
var parseString = require('xml2js').parseString;

https.get("https://someplace/someapi", function(response){
 
	var body = '';
	response.on("data", function(chunk) {
		body += chunk;
	});
	
	response.on("end", function(){
		//console.log(body);
		parseString(body, function (err, result) {
			totalEntries += result.feed.entry.length;
			for(var i=0; i < result.feed.entry.length; i++){
				something += parseInt(result.feed.entry[i]['something'][0]['somethingelse'][0].$.thingiwant);
			}
			console.log("Total stuff: " + something);									
		});	
	});
}

This one was easy to get what I needed, but clearly not the right way to do it. Because the functions happen asynchronously, blah blah blah, that’s not what I’m writing about.

The next one was very similar, but I had to scrape a webpage, not just xml data. So I found a nice lib called jsdom, which created a dom for me to use jquery on.

var jsdom = require("jsdom");
 
jsdom.env(url, function(errors, window){
	var $ = require("jquery")(window);
	var total = 0;
	
	$(".some_class").each(function(key, value){
		// just use a regex to get it
		// it's buried in the onclick, so I'll have to use a regex regardless...
		var result = value.innerHTML.match(/newWindow\('([^']*)'/)[1]; // get first grouping
		jsdom.env(host + result, function(errors, window){
			var $ = require("jquery")(window);
			// use regex to get the xxxxxxx because I'm lazy
			var result = $('head').html().match(/someRegex/g);
			if(result !== null){
				for(var i = 0; i < result.length; i++){
					var thing = result[i].match(/"([^"]*)"/)[1]; // get first grouping
					total += thing;
				}
			}			
		});
	});
});

This was super easy / super powerful to use something I’m already so familiar with to accomplish a task that is well suited to that. The scripts themselves took minutes to write — if you don’t take into account the time I spent finding where to get what I needed.

Shame on Me: the missing code review (or is it unit testing?)

So a bug was reported not long ago. Let’s say “sensitive data” was available where it shouldn’t have been. I had an API view, a view that was returning json only, or should have been. Apparently early on in the project, I had added a comment to that view, to make sure it was returning the appropriate data. So I had added an html comment to a view that was supposed to be returning json. And I had it outputting everything under the sun it could output.

<!--
"secure data" => "stuff I don't want the user to see",
... 30-40 lines of this ...
-->
{"success": true}

So there’s 2 problems with that. The most important of which is that with DOM inspection tools, like chrome developer tools or firebug, you can inspect the return value of that request and see the data I don’t really want you to see. The other problem is that I’ve created invalid json, and whatever is checking that success is clearly not using that value.

Why did I do this?

This was early on in development and I was debugging the easiest way I could.

What could have prevented this?

A code review of any kind. One look at that file would have been a red flag to anyone. But a view file that was only outputting true or false never seemed like something I ever needed to look at once I got it working.