You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Modern JS: Tools of the Trade

Whether you like or dislike javascript, the good parts are quite good and javascript patterns can make it easier to write sophisticated apps that are also readable and maintainable. One of the more recent trends in JS is a movement toward micro libraries. A good resource for that is Alas, there’s no such thing as CPAN for browser-based javascript, but I think this is a good start at organizing the useful libraries that exist on github and elsewhere.

On one of my recent projects, I wanted to implement the pub/sub pattern on some objects, but instead of writing the code myself or reaching for a heavyweight library just for event functionality, I instead found microevent.js via microjs, a mixin that adds the ability to make any object an event emitter. In total, the library is just 20 lines of plain-old-javascript that anyone can understand.

These are some other tools and services that I’ve found very useful:

  • JSHint (successor to JSlint): lints code and also useful for enforcing a common style on a project with multiple developers.
  • RequireJS: a library that aims to make dependency management more sane in javascript. This is based on AMD.
  • Jasmine: a library for doing unit testing (BDD).
  • JSDoc: for documenting javascript, kind of like Javadoc. Docco is also gaining in popularity, although I haven’t used it myself.
  • Lodash/Underscore: Lodash is a fork of underscore.js that I’ve been using, although they both serve the same role: they facilitate a more functional-style and provide common utilities that every JS dev needs, whether they know it or not, although as Brain Lonsdorf points out, there’s more to functional programming.
  • JSPerf: this is a popular benchmarking service for JS and helps answer performance-related questions. Very useful.
  • JSfiddle: great service for testing out javascript and sharing it with others.

I’m sure there are some others that I’ve missed, and I’d like to hear about them!

Posted in ATG, Javascript. 1 Comment »

Git vs SVN again

My previous Git vs SVN made some errors based on old information. I’m hoping this will be a more accurate account.

Git Pros:

  • DVCS (Distributed Version Control System). What this means is it works off of the idea that every user copies the entire VCS and runs their own repository locally. This has several benefits.
    1. Speed. This makes development/working with the repository much faster as almost every operation does not require you to contact the “primary” repository.
    2. Tiny Commits. This allows / encourages tiny commits, so changes are tracked more closely and can be more easily separated out.
    3. Control over who merges. A merge can be attempted by any access layer, but this will generate a pull request which can then be reviewed and approved.
    4. No network access required.
  • Lightweight Branching. While feature branching in SVN is technically possible, it’s also a pain in the ass. Git made branching a first class feature. Easy branching means more people will probably make use of more advanced workflows.
  • Much smaller repositories. Due to better compression.
  • Repo file formats are simpler. So repair is easy and corruption is rare.
  • Clones act as full repository backups. That’s potentially useful I guess.
  • Creating a repository is trivial. So people who want to use repositories to track tiny personal projects, can just do so without any setup.

SVN Pros:

  • Narrow Clones. You can make a checkout of just one subdirectory deep in a hierarchy, download only the files related to that directory, and still be able to make commits. This seems useful in massively large repositories.
  • Authz files are easier (more standard) to write than Git commit hooks.
  • Comfort. People are already used to the linear structure and commands of SVN and that makes sense to them. Switching to DVCS is a cost. Most developers find the switch painful because it goes against what they’ve done for so long.
  • Deals with binary files better. If you’re tracking massive amounts of non-textual data, SVN handles it better as Git’s compression won’t work as well and it’ll be copying over everything.
  • Better classical / hierarchical model. (As opposed to patch/change based revisions.) It keeps in place a simplified model, good for keeping release history. Good for if you only make large commits and don’t want / need to record small dev changes. From a Git perspective, think of fast-forwarding every pull request.
  • SVN Lock. This provides more top down control over the repository.
  • Supports empty directories. This is probably important to someone.
  • Shorter and (mostly) predictable revision numbers.

SVN encourages large commits, Git encourages smaller commits. Simplicity or granularity. We all started out used to the former, but the latter is catching on quickly.

What seems to be the bottom line for most people is that SVN is the old and Git is the new. This is the direction of things, and it’s a new way of thinking about workflows and how VC can actually be doing things OTHER than just storing data.

The only issue that really matters to us is the pain of the switch. The problem is if we don’t understand the benefits that we’re getting from the switch, there’s never going to be enough of an impetus to switch.

Posted in Git, SVN, Version Control. Tags: , , . Comments Off on Git vs SVN again »

The Newbie: Learning Tools Interoperability

We’re educational technologists, which generally means two things:

  1. We like to develop tools for teaching and learning;
  2. We have an on-campus Learning Management System (LMS) for which we have often developed;

The above has now been complicated by the inevitable: Our LMS will be changing in the future, and that LMS is, er, unknown at the moment. There are a wide variety of candidates, to be sure: Blackboard, Moodle, Sakai, and Canvas, to name a few. So which one to develop for? Or do we simply stop development, take some time off, and head out on vacation? The latter, alas, isn’t an alternative. And since we don’t know, exactly, what we are writing for, we’re implementing stand-alone web applications at the moment. It’s nice to be doing so, but it would also be nice to easily integrate these applications into whatever LMS the University ultimately decides upon.

Enter Learning Tools Interoperability (LTI), a specification by the IMS Global Learning Consortium. The specification attempts to establish a standard way for rich learning applications to be integrated with other platforms, such as, say, an LMS. In LTI lingo, the “rich learning applications” are called Tools (delivered by a Tool Provider) and the LMS is called the Tool Consumer. The goal is that users of the LMS can connect to your external, web-based application without disrupting their experience by having to travel outside the LMS. For developers, it means “write once, use anywhere.” That seems ideal. But we know how well “write once, use anywhere” often goes.

Nevertheless, we’re starting to explore LTI, and, fortunately, Instructure, the makers of Canvas, have an entire course for developers, and several of the assignments are devoted to learning LTI (just click on the “modules” link of their course site). Additionally, the MSDLT Blog has a good article on writing a basic LTI tool provider, which lists several links that all developers should be aware of, and shares their early thoughts on LTI. And we’ll (hopefully) continue to share our own thoughts on LTI as we delve into it.



Posted in Uncategorized. Comments Off on The Newbie: Learning Tools Interoperability »

SVN vs Git

SVN is a minor improvement on the CVS design. A linear, central repository. To their credit, the developers of SVN acknowledge this, from the Red Book:

Subversion was designed to be a successor to CVS, and its originators set out to win the hearts of CVS users in two ways—by creating an open source system with a design (and “look and feel”) similar to CVS, and by attempting to avoid most of CVS’s noticeable flaws. While the result wasn’t—and isn’t—the next great evolution in version control design, Subversion is very powerful, very usable, and very flexible.

Git is a Distributed Version Control System (DVCS). It’s important to distinguish it as “decentralized”. What that means is that each user creates a literal “fork” of the project.

What Git offers that’s important is lightweight branching and significantly better merging. These are what make advanced workflows (feature branches) possible. See Git Flow.

Branching by itself isn’t where the magic is. What makes Git bounds above SVN is actually the merging. What makes the merging so much better is actually how the history of commits is kept. Git is a Directed Acyclic Graph (DAG) and SVN is done linearly.

What this means is the SVN merge doesn’t take into account previous merges of the branch, it merges the files directly. They’re both doing 3-way merges, but the 3rd that is used (the common ancestor) isn’t the same because the linear history of SVN isn’t taking into account previous merges. So basically SVN goes back way further because it doesn’t know where the last merge between branches was. The result is a lot more conflicts that have to be manually resolved.

The above is outdated. As of SVN version 1.5, (2008), SVN includes meta data on merge histories, so it uses the 3-way merge to similar effect as Git now. I’m going to have to write a new one of these after more research.

Posted in Git, SVN, Uncategorized, Version Control. Tags: , , . Comments Off on SVN vs Git »

Version Control and Sensitive Data

Don’t put passwords in your repositories.

Posted in Uncategorized. Tags: , , . Comments Off on Version Control and Sensitive Data »