Cleaning unclean jQuery

jQuery enthusiasts love chaining. They think it's the bee's knees, the cookie's crumbles, the frosting on the cupcake. In the name of "performance" for "not having to do multiple lookups", they tend to write code with anonymous functions everywhere, full of deep levels of nesting, with relatively nasty control structure. After reading Clean Code, I see a better way. Compare these snippets.

Engineering Education and Cognitive Load Theory

Engineering topics have higher intrinsic load than other fields because, as Wouters et al (2008) put it: "The more complex a skill, the higher the intrinsic cognitive load because of the higher element interactivity."

Loading files in Grails without application context

Like all Grails n00bs, I got into a pattern of loading a bunch of data into the DB in Bootstrap.groovy, a la

def init = { servletContext ->
        println "starting"
        if(!Role.list())
        {
            setupRoles()
        }
        println "roles set up"
        if(!Person.list())
        {
            setupPersons()
        }
        println "people set up"
        if(!Organization.list())
        {
            setupWorkgroups()
        }
        println "orgs set up"
        if(!Customer.list())
        {
            setupCustomers()
        }
        println "customers set up"
        if(!Project.list())
        {
            setupProjects()
        }
        println "projects set up"
        if(!Milestone.list())
        {
            setupMilestones()
        }
        println "milestones set up"
        if(!UserDefaultMilestone.list())
        {
            setupDefaultMilestones()
        }
        println "default milestones set up"
        if(!OrgGoals.list())
        {
            setupOrgGoals()
        }
        println "goals set up"
        if(!IMBO.list())
        {
            setupIMBOs()
        }
        println "imbos set up"
    }

Eventually something inside said that 800 line Bootstraps were a bad idea (reading Robert Martin's Clean Code is having an effect.) I decided to abstract that away with the Strategy Pattern:

I've recently discovered Fixtures, so I may move away from this approach, but I like the ability to encapsulate my creation steps in my classes and do more processing, so we'll see.

public interface CreationAlgorithm {
    void loadData();
}

import edu.asu.engineeringed.Media
import org.codehaus.groovy.grails.commons.ApplicationHolder

class MediaCreation implements CreationAlgorithm {
    public static void loadData(){
        createMedia()
    }
    
    private static final void createMedia() {
        def media = 
        [
            "awesome" : [ 
                          name:"Awesome",
                          description: "This picture should make you smile",
                          fileName:"images/awesome.png" 
                        ]
        ]
        
        media.each { k, v ->
            def grailsApplication = ApplicationHolder.application
            def resource = grailsApplication.mainContext.getResourceByPath(v.fileName)
            def theFile = resource.file
            def newMedia = new Media(fileData:theFile.readBytes(),
                                  name:v.name, 
                                  description:v.description)
            newMedia.save()
        }
    }
}

import ProfessorCreation
import PresentationCreation
import UserCreation
import BasicCreation
import CourseCreation
import ResearchCreation

class BootStrap {
    def init = { servletContext ->
        BasicCreation.loadData()
        ProfessorCreation.loadData()
        PresentationCreation.loadData()
        CourseCreation.loadData()
        UserCreation.loadData()
        ResearchCreation.loadData()
        MediaCreation.loadData()
        AccomplishmentCreation.loadData()
    }
    def destroy = {
    }
}

The MediaCreation bit was an interesting case. I read this post, but didn't like the approach of putting my files in the grails-app/conf directory or that I had to do it in Bootstrap.

I didn't wanna pass the Grails servletContext to that one as it would break the consistency (eventually I'll refactor it down to using the Groovy Spaceship operator on a map of interface instances or do some metaprogramming magic), so I had to figure out how to get the grailsApplication in a Groovy src/ class file. This showed me the way, and since Spring WebApplicationContext offers an interface for Resources it made the code nice and clean.

Applying Test-Driven Development to Assessment in Software Engineering Education

Abstract: Test-Driven Development has become a predominant part of many Agile processes and an emphasis on testing has become a hallmark of modern software engineering discipline. Perhaps unsurprisingly, since Fred Brooks himself noted that software is made of "pure thought stuff", this innovation in software process has much wider applicability than merely the development of software components. In fact, one can argue that this very same approach should be taken to the task of teaching software engineering. In this paper, we review the educational literature on assessment in engineering education and argue that many of the principles behind TDD/BDD/ATDD should be applied by faculty for the administration and management of a software engineering course. We show how concepts such as "fail fast", "unit testing," and "iterations" can be used to manage course progress, and end with a framework that faculty can try in their own courses.

“Assessment as a long-term strategy is intended to enable high-performance student learning systems through the continuous measurement of processes and outcomes, and through the use of results to further refine performance.” (Spurlin, Rajala, Plavelle Designing Better Engineering Education Through Assessment 171)