The idea is that you can create Unit objects and associate them to any data, using a Quantity object. You can then perform any operation on the Quantity objects and the units are handled behind the scenes for you, with as few conversions as necessary (almost always zero).

Here’s an example to give you an idea of how it works.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

import numpy as np
from dimensionful import Unit, Quantity

# totally fake data
energy_data = np.random.random(4)
time_data = np.random.random(4)

# Create a Unit. Dimensionful knows the unit symbols "g", "cm", and
# "s", but you can provide any string or sympy expression.
energy_units = Unit("g * cm**2 * s**-2")

# Create a Quantity. First argument is the data, second is the units. The unit
# arg can be a Unit object or a string.
energies = Quantity(energy_data, energy_units)
time_intervals = Quantity(time_data, "s")

# Try Quantity operations
power = energies / time_intervals
print power

This outputs [ 0.84771033 1.01795928 0.34694982 0.26888805] cm**2*g/s**3. And a brief version of the same thing:

1
2
3

from dimensionful import Quantity, erg, s

print Quantity(np.random.random(4), erg) / Quantity(np.random.random(4), s)

This package is similar to magnitude and sympy.physics.units, but I think there are some key differences.

Symbolic Units

If I want to express some of my data in “M_solar / yr * s”, I do not want it automatically converted to “kg”. This is at least one unnecessary operation and is almost always not what I want.

Rather than carrying around powers of SI base units or automatically converting to SI, dimensionful understands that your units are mathematical symbols and should be treated as such. They are never reduced to other units until you ask for that.

Example using the Hubble rate:

1
2
3
4
5
6
7
8
9

>>> h = 0.71
>>> H_0 = Quantity(100 * h, "km / s / Mpc")
>>> print H_0
71.0 km/(Mpc*s)
>>> print H_0.get_in("s**-1")
2.30095149205362e-18 1/s
>>> time_interval = Quantity(100, "s")
>>> print H_0 * time_interval
7100.0 km/Mpc

Although km / Mpc is just a number, dimensionful does not convert it until you ask for the Hubble rate in inverse seconds.

Dimensionality-based

Each Unit object has an attribute called dimensions. This a symbolic expression of a Unit’s dimensionality, made up of “mass”, “length”, “time”, and “temperature” symbols.

1
2
3

>>> from dimensionful import erg
>>> erg.dimensions
(length)**2*(mass)/(time)**2

This is what allows dimensionful to understand the relationships between different units. If I have data with dimensions (length)**2*(mass)/(time)**2, I know that I can’t convert to units with dimensions (length)**2*(mass)/(time).

In this system, Units are combinations of dimensions and a reference value. I chose to use cgs for reference values, so each Unit object has the attributes dimensions and cgs_value:

1
2
3
4
5

>>> J = Unit("J")
>>> J.dimensions
(length)**2*(mass)/(time)**2
>>> J.cgs_value
10000000.0

Base units

Most unit libraries are SI based. In my opinion, cgs is a much better system for your base units. The typical reasons are that there are fewer base units and your E&M laws are simpler. See http://en.wikipedia.org/wiki/Gaussian_units for more info.

Check it out

The code is public at http://github.com/caseywstark/dimensionful. I decided license it under BSD to keep the legal stuff simple. There are a decent number of tests included (run them with nosetests), but it’s still fairly new. Let me know what you think if you tinker with it.

I decided to get rid of “thestarkeffect” and thestarkeffect.com. Even if you know the physics phenomenon, it’s a bit too dorky for me now. If you don’t know it, it sounds… bad.

I will leave thestarkeffect.com up for some time (serves the same directory), but you might want to update bookmarks and the feed to http://caseywstark.com/atom.xml if you use them.

I’ve been working with git in a more professional setting lately. We maintain our new cosmological code, Nyx, in git now and I can’t be as lazy as I have been with other git repos. We maintain 2 bare repos and about a dozen developers pull from us, so I like to be careful about what I push off.

Problem is, I don’t normally work that way. I like to code things quickly and try them, keeping track of changes as I go. Think “cowboy” development with very frequent commits. So, I could end up with a very messy commit history. Luckily, git rebase comes to the rescue.

So at the end of a bout of local coding, the commit history looks something like this.

… many commits down to …

For many reasons, I cannot rebase commits already pushed to a remote, so I need to update the remote tracking branch at this point. A simple git fetch origin master does the job. Now I can rebase off this commit and rewrite my messy history.

I find the tip of origin/master, copy the sha, and run git rebase -i [origin sha]. I think there is simpler way to do this, like git rebase -i origin/master, but I haven’t tried it. I like to be sure I’m rebasing off the right commit for now.

Now, my editor opens up and shows a list of the commits since then. For each commit, I have several choices. Here’s what git displays during a rebase:

# Rebase 3272740..9ef6432 onto 3272740
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

And here’s a snapshot of what I ended up with this time.

So I will squash 5 commits, reword 3 of the commit messages, and leave everything else as is.

After saving and closing the editor, git opens each commit I want to reword or squash while rebasing. I make the changes I want, and git finishes with “Successfully rebased and updated refs/heads/master”.

Now my commits show up as a single line of development off of the latest commit on origin/master.

Let’s just hope the non-sequential commit datetimes don’t confuse anyone.

Don’t forget to git push origin master after all that.

Last week, my undergraduate research advisor, Vitaly Kresin, emailed me a “nice paper”, saying “I think you might enjoy it.” He was spot on. I could barely read the abstract before I started jumping around and squealing like a little girl.

During my senior year at USC, Vitaly and I published theoretical results of modeling alkali metal clusters inside helium nanodroplets. We called it “Critical sizes for the submersion of alkali clusters into liquid helium” and published in Physical Review B.

The awesome thing is that our intuition for the problem was right. We expected that small alkali clusters end up sitting in dimples on the surface of helium droplets (this was experimentally confirmed for sodium dimers and probably trimers at the time), and large clusters must sink into the center of the droplet.

The new paper is “The submersion of sodium clusters in helium nanodroplets: Identification of the surface → interior transition” by An der Lan et al., in The Jounal of Chemical Physics. Here is the abstract:

The submersion of sodium clusters beyond a critical size in helium nanodroplets, which has recently been predicted on theoretical grounds, is demonstrated for the first time. Confirmation of a clear transition from a surface location, which occurs for alkali atoms and small clusters, to full immersion for larger clusters, is provided by identifying the threshold electron energy required to initiate Nan cluster ionization. On the basis of these measurements, a lower limit for the cluster size required for submersion, n ≥ 21, has been determined. This finding is consistent with the recent theoretical prediction.

Referenced in the abstract? I couldn’t believe it! They go on to reference me and Prof. Kresin and our results for the critical submersion size of sodium clusters. The experiment demonstrates “excellent agreement” with our prediction for sodium.

In the grand scheme of science, this is not exactly earth-shattering – this is like a tiny screw in the giant tower of human knowledge. I doubt anyone besides Vitaly and I will sleep more soundly knowing this. But it’s my tiny screw and I’m proud of it. And I’m so glad that I had the opportunity to do some good theory work with a brilliant advisor.

If you care to read on, here are some other goodies from An der Lan et al.:

“Thus, at some critical size the cluster may become submerged in the helium rather than adopt a surface location. Recently, Stark and Kresin have described and employed a theoretical model which anticipates such a critical cluster size for alkali submersion^9. For example, Na_n clusters are predicted to preferentially enter ^4 He nanodroplets once n ≥ 21, whereas K_n clusters require approximately 78 atoms to become fully solvated.”

“The ion yield curves for Na^19+ and smaller clusters are consistent with a surface location for the corresponding neutral clusters, whereas those for Na^21+ and larger clusters are consistent with an interior location for the corresponding neutral clusters. These findings provide strong evidence for a switch from a surface location to an interior location at a certain sodium cluster size. For completeness, we show aggregated data for the much weaker even cluster ions in Figure 5, where the signal from all Na^n+ ions with n > 20 have been summed together and similarly all of those with n ≤ 20. Again this is consistent with a change in cluster location at around the n = 20 or 21 size.”

"Thus, because of the potential for ion fragmentation, we can only firmly establish a lower limit of n ≥ 21 for sodium cluster submersion in ^4 He droplets. The lower limit is in excellent agreement with a recent theoretical prediction made by Stark and Kresin, whose model suggested that the minimum Nan cluster size for submersion in ^4 He droplets occurred at n = 21^9.

1

$ grep --color -irn "some text" .

Just to be clear, --color highlights the search string in the output, -i makes the search case-insensitive, -r makes the search recursive, -n outputs the line number of the hit, and the . at the end says to search the current directory. Lazy as I am, I realized I could just add this to ~/.bash_profile:

1

alias ggrep="grep --color -irn"

Now, I can save some time and thought with ggrep "thing" . It’s the little things…

EDIT: As Matt Turk suggests in the comments, the best alternative (especially for the Pythonists) is grin. Much simpler and clearer display of results.

It’s been a great couple of days, meeting lots of fellow cosmologists, having very casual talks and schedule, and nerding out. I have been taking lots of notes, but I decided that I should keep them private, at least for now. I know that’s not being my usually open self, but it would take too much time to clean them up for all eyes. If you would like to know anything about what’s going on, feel free to contact me though.

Just another note: there is very little AT&T reception in Sante Fe and even less at the College, so please email me if you need to get in touch.

$ lsss /etc/default
total 49
-r-xr-xr-x   1 root           12     gemini Jun  4  2002 cron
-r--r--r--   1 root          204     gemini Jun  4  2002 devfsadm
-r--r--r--   1 root         3388     gemini Jun  4  2002 dhcpagent
-r--r--r--   1 root           10     gemini Jun  4  2002 fs
-r--r--r--   1 root          719   aquarius Jan 23  2004 inetd
-r--r--r--   1 root          379     gemini Jun  4  2002 inetinit
-r-xr-xr-x   1 root          638     gemini Jun  4  2002 init
-r--r--r--   1 root         1182      virgo Sep 15  2002 kbd
[...]

Twinkle twinkle little star
How I wonder what you are
When my civilization advances
And we can fly to your galaxy
We’ll exploit your natural resources

This is a bug that has to do with the Mac framework architecture. Basically, you need to install matplotlib to /Library/Frameworks/Python.framework/ or matplotlib will not be able to interact with the Mac OS X Windows Manager properly. I don’t know the first thing about window managers, but I can tell you that this is really important when you want to save your figures.

I tried many things, including installing numpy, scipy, and matplotlib in a virtualenv. I thought it would be much cleaner to “activate” my scientific environment, keeping the Apple Python build as my system default. I got this all setup and when I tried to use matplotlib, I could not type in the textfield in the matplotlib save figure window. That is, I would plot something, click save, and then I could not enter a filename in the dialogue box. Infuriating.

So I gave up and installed the EPD 32-bit academic version. Not ideal, but it works really well and it just means my environment variables are a tiny bit mangled. No bigs.

I am making a web editor for scientists, called Paper Hustler. I just put up the pre-beta site at http://paperhustler.com. You can also follow @paperhustler.

I put up the site yesterday, just before giving my talk at the Grad Student Postdoc Seminar (aka Wine And Cheese Talks). You can check out the slides to see a quick pitch (my thoughts that inspired the project) and new forms of scientific dissemination.

I am looking for lots of feedback on this, so please let me know what you think, good or bad.

In the future, I hope to post details on the tech behind the project. I have really enjoyed obsessing over developing this one.

In the past few years, Open Science has become quite the buzz word, but most people aren’t sure exactly what it means. Since DJ and I will be discussing it a lot in the upcoming weeks, I would like to nail down a definition.

When people think open science, they think open access. That is, publishing your papers to a journal without a paywall. That’s a good start, but we would like to think it encompasses more than that. A lot more.

What Open Means For Science

First off, when we think open publishing, we mean open publishing of everything. That means more than the paper -– it means the raw data, the analyzed data, and any code involved along with the final paper. Sure, there are a lot of technicalities with publishing data (so many we can’t discuss it here), but you should at least publish the data included in the paper to make your colleagues’ lives easier.

Second, truly open science means also doing science openly. That’s right, I’m talking full on scientific transparency. When it comes down to it, we need to improve how science is done, not just the way it is distributed. When I say open science, this is mostly what I’m referring to –- the practice of putting all works in progress on the web.

So let’s talk about what this new openness buys us and why it should become the new norm.

How Open Benefits Science

The most common argument for open access is to give the taxpayer what they paid for. It’s not easy to motivate scientists with this one, but there are many good reasons for it, which you should read about here. But open science also means doing science in public channels, which has plenty of its own benefits.

Timestamped records

For starters, we get a public record of everything we do. Every single one of our contributions is timestamped and publicly accessible. Skeptics of doing science in the open usually argue that making our works in progress public will open them up to getting scooped, but to us, it seems much more likely that this will prevent it. If you have an accredited, timestamped record of your idea, how are you going to get scooped? If someone stumbles upon your idea and wants to work on it, they are more likely to contact and bam, you have another collaborator.

Disrupting the scientific group

One of the biggest changes open science could have in store is shaking up the model of the scientific group. Instead of working in a fixed group of people, open science would allow us to focus on the the problems themselves, with individual scientists contributing solutions as they please. Not saying that the scientific group will be destroyed or should go away, but groups would certainly be more flexible this way.

Currently, secrecy is the glue holding the scientific group together. But if we share our day-to-day research beyond the same fixed group of collaborators, the sacred bond will be broken and scientists will be able to mix it up with other collaborators more often. At the very least scientists can collaborate more frequently based on expertise and background instead of whoever is down the hall.

Publicizing works that were previously lost to the void

As I said last week, transparency in science will help eliminate duplicate efforts. This includes things like research mistakes that led to dead ends and half-finished projects. If we make works in progress public, others can learn from our mistakes and help pick up the projects we never had time for.

Awesome metrics of impact

Currently, measuring scientific impact is very difficult and our methods for trying to figure it out (basically just bibliometrics) are horribly crude. Being scientists, you would think we would be a little more interested in this, but maybe we haven’t done anything about it because our current scientific model gives us practically no data. With truly open science, we could have so much data that we wouldn’t know what to do with it. At the very least, open science on the web would unlock the potential for all sorts of scientific metrics.

Exposure of the scientific method

No, I’m not talking about the thing you learned in second grade. This new practice would provide excellent exposure of the scientific method –- the way it really works -– raw, uncut, and in the wild.

I’ve been studying physics for four years now and I think I still don’t have a clear idea of how the field actually evolves. Having a working record of scientific projects would provide anyone interested (scientists in other fields, students, and enthusiasts) with a level of intimacy with research projects that was previously impossible. It’s no replacement for real research experience, but full transparency would definitely provide a better idea of the scientific method than we can get now.

How Open Can Science Be?

Many scientists will think that open science is too risky for some time, but we can all tell it’s heading there and as we’ve said, someone needs to start it. As more and more scientists pick up their web developer hats and web science becomes more respected, I believe we will see a reinventing of how we establish scientific credit and this will really determine exactly how far (and how fast) this open model can go.

The dream is for scientists not to worry about their own research and funding so much and to remember that it’s all about the science.

In the past decade or so, establishing a personal webpage has just about become a requirement in science. Try to Google the name of the nice waiter or waitress you met at dinner today and you’re likely to come up empty-handed. But the new colleague you met at a conference this morning? You’d probably be shocked if a Google search didn’t turn up a homepage or at the very least a university or research institution profile listing research interests and other personal information. Scientists have realized long before the majority of human beings the great social benefits of establishing an online persona to manage their public image and encourage new collaborations.

Smart move.

Scientists now have the opportunity to lead the pack on another intriguing technology on the horizon relating to managing one’s own public image –- the CV as a live digital stream of professional contributions.

The CV as a Live Feed

First of all, what do I mean by “live digital stream of professional contributions”?

Up until now, the CV has been a collection of lightly edited PDFs buried in a folder somewhere on your desktop. You probably scramble to update it only when you’re applying for a new position or grant, wasting hours wracking your brain to recall every publication, peer review, or other contribution you’ve made recently and yet still forgetting several important pieces of data.

Yet plenty of that information you cram into your CV is either already available online or soon will be as science becomes more open. Why painstakingly curate it yourself? Imagine a service that aggregates your most recent publications, counts the number of papers you peer review, keeps track of the conferences you attend, and presents your collective scientific contribution in a live stream, just like an RSS feed.

The future of the scientific CV is a live digital stream of your scientific contributions.

Now why should you be excited?

Save Time

I’ve never met a scientist who would rather be updating their CV than thinking about interesting problems. Any change that allows scientists to focus more on thinking, experimenting, and collaborating and less time on administrative tasks should be an easy sell.

Never Forget to Include Your Latest Updates

Trying to remember accepted and pending submissions for half a dozen journals, the number of times you stayed up half the night peer reviewing a paper, or the collection of awards you picked up for your latest hit paper isn’t easy. And if you forget to list something, don’t expect a committee to go digging up all your missing data. Unlisted by you = unappreciated by them. Aggregation is what machines are good at it. Leave it to them.

Easy Customization -– For Both Scientists and Their Employers

Rather than painstakingly reviewing and revising every item on your CV each time you want to share it with someone, simply check a few boxes, applying custom filters that determine exactly which information they’ll gain access to. And don’t feel pressured to whittle your CV down to as few pages as possible. If application committees have their own set of filters, they can easily hone in on what they’re interested in. Giving both parties filtering capabilities, only information of mutual interest gets reviewed.

Accreditation

Now imagine you’re on an application committee. In principle, you could always exhaustively verify the claims made on each CV you review, but let’s be realistic. It’s unlikely you’ll even read all the CVs you receive, let alone verify them. Instead, you simply take on blind faith the lengthly list of publications offered to you.

But what if journals published accredited feeds, detailing every author’s contribution in a way that was easily integrated into a digital CV? Better yet, what if they also published the number of papers that an author peer reviewed, conference organizers published easily aggregated lists of attendees and speakers, and universities provided verified lists of courses taught, seminars given, and other academic contributions? A CV would no longer be a holy document accepted on blind faith; it would be an aggregation of information verified by the greater scientific community.

A Richer Measure of Scientific Impact

The most interesting benefits of the CV as a live feed, however, come as scientific communication migrates online and becomes more public. Instead of “peer viewed papers for journal X”, CVs could include the number of papers peer-reviewed and the quality of feedback as measured by the votes of authors or, in the case of open peer review, the votes of the community as well. Instead of “published paper in journal Y”, CVs could include the quality of the publication as measured by votes from the community, instead of something as crude as a citation index.

Black-box descriptions of scientific contributions could become much richer measures of how the greater community values a researcher’s work.

Data on scientific communication could also help the community to distinguish hermits from those who actively contribute to other’s work, even if it doesn’t mean a co-authorship. While many valuable contributions to science are made in solitude, useful feedback is also key to the scientific process and is surprisingly absent from present measures of scientific output. The idea isn’t to penalize hermits but simply to reward those who do make an effort to contribute to the greater scientific effort.

Blog posts, popular science articles, publicly posted lectures, and other forms of public outreach could also be easily included.

Some of the tools to do this are already available, but many are not. Scientists should be first in line in both demanding and developing them.

Making Open Science the standard is a much greater task than just building the best tools for it. Most of the battle in fact, is just motivating scientists to work and think in a new way.

As DJ says, figuring out the best way to do open science may take some wasted effort, but once we have that settled, we could get even more time back by saving scientists from duplicating other scientists’ work.

If you’re confused about what I mean, here are a few examples:

Duplicate Code

Albert wrote a simple stellar simulation program for his latest paper. Barbara is another astrophysicist who wants to use this program with slightly different parameters. Unfortunately, Albert only wrote about the code in his paper and never released it. When Barbara tries to contact Albert, he never responds.

It’s a common situation. Many scientists write code that never gets seen by the rest of the world. Maybe someone in their group looks over it, but usually, that’s the furthest it goes.

Whatever the reason, many scientists end up having to rewrite code that’s already out there. This is a problem for many reasons, but one of the biggest issues is that no one gets to save time by reusing their code. Every time someone has a need for similar computations, they have to spend a significant amount of time writing and testing (and hopefully documenting) their own version.

Sure, there are many reasons to create your own version of someone else’s code -– you might want to get more familiar with the calculations (or double check them), rewrite it in a more familiar language, or clean it up to make future improvements easier to implement. However, all of this becomes much, much easier when you have a working copy in front of you.

So let’s make code open. There are many other scientific reasons for releasing code, but at the very least, we should do it to make it easier on our fellow scientists.

Duplicate Searching/Aggregating

A lot of scientific work involves figuring out what people have already figured out. Searching for papers, reading them, and repeating takes a lot of time. More importantly, everyone in the same field does the same (or very similar) searching, reading, and organizing. If we could record and share our work in this arena, we would save a lot of time and needless effort.

If Carol spends all day searching around for seminal quantum computation papers and organizing them, why should Daniel spend all of tomorrow doing the same thing? Sure, he still has to read the papers, but he could save a good chunk of his day by having these papers already organized, rated, and reviewed for him.

Luckily, this one is already being tackled by the folks over at Mendeley. Hands down, Mendeley is the best way to organize papers and share them. The Mendeley research network also allows you to use other users’ tags and reading stats to find papers in your field more efficiently.

Duplicate Mistakes

Scientists make only a tiny percentage of their work public because we only publish the most polished version of the final results. We have very few records of all of the mistakes we make along the way, which are bound to be forgotten soon after.

Remember that brilliant idea you wanted to try after reading that paper the other day? That idea you thought was brand new because you couldn’t find anything after a quick literature search? Perhaps several people did try the same thing, only to get stuck and realize it was a doomed approach. If these blunders, dead ends, and half-way solutions were made public, we could learn from them instead of repeating the same mistakes.

Duplicate Projects

Of course, the worst kind of duplicate work is repeating entire projects.

One of the biggest advantages to open science is that you can always see what your fellow researchers are up to. The current model of the scientific groups makes the bulk of their ongoing work invisible. Instead of constantly competing with similar groups or worrying about getting scooped out of nowhere, we could finally combine efforts and focus on the questions themselves, not whose side we’re on.

Get Started Sharing

So say you want to start participating in open science today. Here are some great starting points:

• myExperiment for sharing experimental workflows and data.
• GitHub for hosting code and collaborating with other coders.
• Delicious for sharing and organizing anything on the web (bookmarking).
• Mendeley for finding, organzing, and recommending papers.
• Twitter for getting and receiving quick updates about projects.
• CoLab for organizing collaborations around a single question.

No more hoarding code, mistakes, ideas, and published data. Saving your colleagues hours of toil and frustration is just a few clicks away -– all it means is sharing your work.

There will be no perfect tool for open science.

Blogs like that of Michael Nielsen and Cameron Neylon, the Twitterverse and the Science 2.0 group over at FriendFeed are full of comments from people eager to participate in open science. Many dream of a wonderful future in which papers are full of links and dynamic data and tailored to the readers’ needs, publishing is fast, open, and free, and experimental data is uploaded directly and automatically from the lab bench to the web. Yet many giddy comments end with a whimpering “Let me know when something like this is available.” Plenty of people are interested in doing open science, but everyone is waiting for the perfect tool.

Well folks, its not coming anytime soon. It’s not for lack of demand or interest. It’s that we still don’t know what the perfect tools for open science look like.

The problem is that very few people are actually experimenting with open science. There are great discussions going on (especially at the sites I mentioned above), proposing lots of interesting ideas about how to do open science, but discussion alone is not going to separate the good ideas from the bad. We’re currently theorizing blindly. Just as theorists are lost without experimentalists, so too are brainstorms without trial and error.

We need to be willing to waste our time with imperfect tools.

Wordpress blogs, wikis, and Twitter were neither designed for scientists nor are they great tools for doing open science. MyExperiment, Naboj, and CoLab were actually designed for doing open science, but they certainly aren’t perfect. However, all of these tools do provide sandboxes where those of us interested in doing open science can start to get our hands dirty. By experimenting with imperfect tools (and being willing to “waste” a little time), we can better understand exactly what features killer open science apps must have. And along the way, we will have actually done some open science.

Consider the PolyMath Projects. Certainly blog comments are not the perfect place to do collaborative mathematics. Yet lack of equation support, poor filtering, and the inability to branch conversations didn’t stop 30+ mathematicians from doing genuinely new and important mathematics on the web.

So start a blog about your ongoing research projects. Tweet questions for colleagues or links to interesting new papers. Post data and code to your homepage. Do something, even if it’s not the perfect thing you envisioned open science to be.

This post is not proposing any ground-breaking ideas. It is only meant to stress the importance of experimentation in a field that should know better.

The problem I always have with JavaScript is debugging. I don’t have a whole lot of experience with JavaScript, so that might be a big part of the problem, but the errors usually aren’t very helpful, and plain impossible if the culprit code is minified. I’m just lucky that the Chrome developer panel is there.

I was trying to compile a JavaScript template using Underscore’s template function, but I kept getting an unexpected identifier error that pointed to the line calling _.template($("#template_id").html()) somewhere in Chrome’s traceback.

I was afraid this was a compatibility issue between the versions of Underscore.js and jQuery. Wrong. After juggling versions for a while, I looked at my template again:

<span class="authors-count"><% authors %></span> authors.

So kids, always remember to start your template tags with <%**=**.

Dajax has an excellent example of this. See their flickr-style editor demo, especially if you aren’t sure what I mean by inline editing.

I wanted to do something very similar on the frontend, but I think that in most cases, Dajax’s philosophy just gets in the way. It’s a nice way to keep as much of the code as possible in Django, but as a web developer, you should be completely comfortable with JavaScript anyway. In the end, Dajax is a middleman and I don’t like those.

So I went out and looked for a sweet jquery plugin and found jeditable. The short review – it’s great.

Assuming you setup your fields something like…

1
2
3
4
5
6
7

$('.editable').editable('{% url update_url_name %}', {
    type: 'text',
    id: 'field',
    name: 'value',
    submit: 'save',
    cancel: 'cancel'
});

Just write a django view to save the field updates and you’re good to go.

1
2
3
4
5
6

... get the thing containing the field to update ...
field = request.POST.get("field", field)
value = request.POST.get("value", value)
... validate the update value and check permissions ...
setattr(thing_object, field, value)
paper.save()

BAM. More details to come.

Merry Christmas everyone!