Drag Dropping a Helper (or something else) with jQuery UI

I was having issues using jquery UI’s draggable and dropping something other than what I was dragging into a sortable. So this example, but dropping something else.

Originally I was trying to do it with Helpers. Helpers are nice, but limited in functionality and you cannot get the draggable helper element from the sortable. The right way seems to be to append / create the element within the dom once it’s been dropped. So create an element template and drop it in on the sortable’s update event.

Here is a jsfiddle with my solution.

Highlight:

var textItem = 'Text that is droppped';
var imgItem = 'Image that is dropped';

$(document).ready(function(){
	$('#sortable').sortable({
		revert: true,
		update: function(event, ui){
			if($(ui.item).hasClass('mysortable')){
			    // we don't add one if we're sorting a pre-existing item	
			} else {
				$(ui.item).removeClass('ui-state-highlight');
				$(ui.item).addClass('mysortable');
				
				if($(ui.item).hasClass('textDrag')){
					$(ui.item).html(textItem);					
				}
				if($(ui.item).hasClass('imgDrag')){
					$(ui.item).html(imgItem);					
				}
			}
		}
	});
	$('.draggable').draggable({
        connectToSortable: "#sortable",
        helper: "clone",
        revert: "invalid"
	});
	
});

Feature Branches with Code Reviews

We have been trying to find a process for doing code reviews for a little while. Because most of our current projects are in github, it made sense to try and use some of the github features to help in this process.

I have been using issues for stories and milestones for sprints for a while. And it works out nicely because I get a pretty neat gamificationy results.

So I started using a feature branch in order to have the ability to make pull requests on my own project and get a discussion thread before code is merged into the trunk (production).
 https://github.com/Harvard-ATG/Quizmo/pu…

This discussion is a great way to get a reasonable code review before merging code. Right now we’ve decided to only do this for non-trivial changes, but with a very high bar on “trivial”.

Forcing Client Involvement Through Production Releases

What I take away from agile is the idea of putting something in front of a client as quickly and as often as possible. Of course things are going to have flaws, and things may be unfinished, but having the client see what you’re doing gets a sort of course correction done that doesn’t happen in a vaccuum. People tend to understand this, but they don’t often abide by it.

The problems I’ve seen lately have been in the instance when there is no client directly involved in the process. In that case, a product manager is assigned to take on the role of client, someone who mostly understands what the client wants and basically be their advocate. But the product manager, being an employee and not a client, doesn’t want to risk releasing an incomplete project for fear of how that will look or how the client will react to that. Therefore purposely not involving the client in the only part of the process where the client could give direct feedback — in production.

As long as it’s explained to the client that they are dealing with an alpha, and we welcome feedback on things they feel are necessary, it seems they could be used at that part of the cycle to offer feedback and keep features that will never be used from being added to the project and keep the project from straying too far from something they don’t want.

Agile Context Switching

I had the pleasure of trying to work on 3 separate agile projects last sprint. I typically get 40-50 story points done in a sprint. I like to take on more than I think I can do to keep myself from letting work expand to fill time. I also had the issue of having to take on another developer’s work. Total, we promised ~80 story points.

Now, when my kid was new and I wasn’t allowed to sleep nights, I was able to cram 70-80 sps into a sprint. But sleep has made that level of productivity very hard.

I was also tasked with working offsite, organizing a community of practice, and trying to learn a very large project through “osmosis”. Which is to say, learn as much as you can without reporting time spent on it.

I have to admit, all of the work is interesting and the clients are all people I personally don’t want to let down. So it’s hard to say “forget project X”. (Which is hard to say generally when there actually is a project X.)

So with many things pulling me in many directions, my completed story points for the sprint was 33. A significant decrease in general productivity.

Context switching needs to be allocated for in sprint planning. Duh?

The trick is how much? Some people say it takes 15-30 min to effectively context switch. That’s part of it. I think the larger part is when you’re focused on one-two items, you can finish things effectively. The more items, the more you end up with partial work. Partial work is the worst time killer. You get 50% into a feature and if you have to stop and start again it magically turns into 30-40% done.

Solution? Don’t switch contexts.

Har har. Work on something to completion before switching contexts. Be strict about it.

Flashcard Gamification

With our Flashcard application, I am trying to make gamification a focal point. I want the games to be modular so anyone can create new games and I want games that are multiplayer. Friendly competition within the class would be ideal.

Competition among a scoring system is too antisocial. The score scroll at the end of a game of donkey kong doesn’t make for a lot of interest in this day and age.

I have a couple of ideas.

A “card” game. Each student is dealt the same 5 cards from a “deck”. They see only one side of the 5 cards. The reverse of one of those cards is displayed and the first student to select the correct card gets a point. That card is then replaced with a new one. Having them both have the same cards takes any chance out of the game. It is time based, which means it is reliant on students being on at the same time.

So a variation of the previous could be one student plays and waits for the other student to play and they don’t lose a point unless they get it wrong. Players could be matched based on how much they’ve studied.

But is that fun? I think after a while, most people would just get bored of it.

Word games on phones are quite popular, but they’re all just variations of word scrambles, word finds, or crosswords. These are simple and not very applicable to a flashcard framework.

I stopped writing this and don’t have the motivation to continue, so I’m just going to post what I have.

Avoiding Page Reloads

My applications are part of a framework (LMS) that load a billion extra items on each page load.

To get around it I wanted to do that silly “twitter thing”. They’re the ones who get credited with it because for years normals were baffled by their url changing.
 http://www.adequatelygood.com/2011/2/Tho…

Additionally, if you’re interested in why the bang(!) is necessary, it’s not. It’s just to tell google to index the page. Otherwise they assume it’s just an anchor link.
 https://developers.google.com/webmasters…

So I spent the last few hours changing all links in one of my current applications to do a “hashbang” sort of call instead of loading new pages. This significantly increased speed when using our clunky LMS.

This was especially annoying because our LMS forces changes with <a> tags.

What made this especially easy to implement was that I had already made all links go through a smarty plugin so altering all links in the application was just in one file and I could make those links specific to whatever authentication scheme / LMS the application is living in. So I just had to alter that plugin and the LMS specific layout and bam. The only thing that’s not covering is form submissions. But there are only a couple of those, so I’m not going to stress about that.

In continuing research obviously I had to investigate why twitter moved away from hashbangs.
 http://engineering.twitter.com/2012/05/i…

The highlight of that being that with hashbangs, you have to go to the client and then back out, which reduces speed on the initial pageload. So twitter went a little fancier 6 months ago and used the history api’s PushState.

Implementing the hashbang urls was a very small amount of code, so I’m going to move forward with that for now, maybe next time I get a chance to do some research I’ll focus on converting that to PushStates.

Harmony Lab

One of the nice things about my job is being able to take credit for interesting student projects. We’ve got an awesome pool of kids that are always doing stuff. They have cool ideas, write up a sloppy implementation and don’t want to maintain it. So it comes to us and we have the opportunity to polish it and expand it for use to a broader audience.

The most recent of these projects to come along is the newly named “Harmony Lab”. (Formerly GoFigure / Piano Lab) This is a nice application that allows you to hook up a midi keyboard to your computer and get information about music theory stuffs (and by “music theory stuffs” I mean I haven’t yet wrapped my head around everything the application does).

Currently it is an application that uses an applet to get the midi data from the keyboard and a ton of javascript for visualizing the key/chord. And a ton of javascript is never a pretty thing.

We are giving it a backend for some authentication, cleaning up the javascript where we can, and adding some extra functionality — hopefully not too much extra. This is a cool project, but it’s usefulness is limited to one or two classes.

What’s cool about this is it’s a (potentially) simple application so it lets us play with (learn) something new (to us). So we went for python Django.

It’s available on github from the start.

Gamification in Software Development


Gamification has been on my mind a lot lately.

I was just doing some of my sprint planning and found myself filling out borderline excessive github issues for my project. I put all of the issues for the current sprint into aptly named milestones. So as I finish the issues in the milestone, the milestone progress bar gets filled up. I recently realized I enjoy doing this because it’s very game-like.

I’ve turned work into a game and I think it has increased productivity and general happiness with employment. Maybe that sounds lame, but it seems true in my case, I would recommend it for most people who are finding their current work stale and are looking for some self motivation.

Agile Documentation and Research Stories

A few months into our switch to a more agile process, it became apparent that we still weren’t able to find a place for documentation in our sprints.

At first we had the idea that we would add a task to each story that would cover documentation. We found that we would end up writing docblocks and general code documentation but actual user documentation never got written. But we did that before so we really weren’t getting done what we were trying to get done.

Our next attempt was to set aside a day at the end of the sprint where we would write documentation or finish up stories that were not done yet. But I’m not sure how other people are doing point allocation in sprint planning but I think the ideal is to try to go just a little over the to of what you’re capable of. That keeps you working hard. At least for me, if I know I can do 50 points in a sprint and I schedule 40, I will get 40 done. Work expands to fill time. My point is there is always work to get done on the last day of a sprint. Scheduling documentation within the sprint separate from story points just doesn’t work.

That brings us to documentation stories.
As a developer
I need to document this functionality
So I can easily refer back when there is a problem in the future

This would be great, if during sprint planning, these stories actually got priority. The client wants a cool app, they don’t care about user documentation when you could instead be giving them a bell or a whistle.

What we have had are research stories. These are stories where we investigate options. i.e.
As a developer
I want to figure out if X is doable
So I know if this technology is the right way to go

These stories come up often in our process. We typically have been simply making some notes and reporting back at the retrospective / next planning. This was fine for our purposes but then we realized we could be creating a slightly more professional looking set of notes and pass them off as user documentation.

This doesn’t cover every aspect of user documentation, but it can get a lot of useful documentation done. How did we do our ldap data? We have documentation of our options and our final choice and why.

Currently we have been writing all of these in google docs so they can be easily collaborated on. We then paste them into the project wiki. It appears to be working.

Rendering templates obsolete?

There’s an interesting discussion on github today (courtesy of javascript weekly) about whether rendering templates and template engines in general are obsolete in today’s javascript-heavy applications. This topic seems to come up periodically, although the idea hasn’t really taken off. I think the first time I came across it was in the seaside framework, which is great by the way. I don’t have a strong opinion one way or the other, so I’ll be interested to see how the discussion develops.