kmarekspartz

A map by Mary

---

After living for 3 years on the University of Minnesota campus, I decided I couldn't stand it any longer: I needed a car. Getting groceries was tough.

Mary Pattison, my fiancée, is currently taking an urban planning course for her master's degree in GIS. For her final project, she collected a list of grocery stores in Minneapolis and used a Euclidean distance analysis to calculate minimum walking distance of any point in Minneapolis to a grocery store.

A lost keys startup

---

Four months later, my blog post is a startup. No relation.

Don't worry about what isn't due today

---

Don't worry about what isn't due today.[^1]

[^1]: If your tasks are estimated to take more than a day's worth of time, this won't work. Break up your tasks until they are in day chunks of time.

How to gather requirements

---

Requirements are a funny thing. They can be over- or underspecified, and it is often hard to know which is which.

Vagueness in the requirements can be bad or good. When requirements are vague, it is difficult to know what direction to go in, or whether the end result will be what the client is looking for. On the other hand, when the client can afford to experiment, vague requirements sometimes provide for novel solutions which the implementers would not have discovered had the requirements been more specific.

Programming in the requirements can also be bad or good. When non-programmers attempt pseudocode, it can lead to logically inconsistent requirements. Instead, when the client cannot afford to learn programming, the requirements should solely detail the needs of the client rather than the specific logic that needs implementing. On the other hand, providing pseudocode in the requirements makes implementation more straightforward, at least initially.

---

John D. Cook blogged about patches and specs today. I've not yet had time to view the video he linked to, but here's the quote he selected:

Every time code is patched, it becomes a little uglier, harder to understand, harder to maintain, bugs get introduced.

If you don’t start with a spec, every piece of code you write is a patch.

Which means the program starts out from Day One being ugly, hard to understand, and hard to maintain.

– Leslie Lamport

Marketing your linguistics degree

---

Today I'll be participating in a forum at the Minnesota Undergraduate Linguistics Symposium entitled “Marketing Your Linguistics Degree”. Here are some of my preparation notes:

When I came to college, I wasn't sure exactly what I wanted to do. I was interested in cognitive science, but it isn't offered as an undergraduate major, so I took the introductory psychology course. It wasn't what I was looking for, so I then took the introductory linguistics course, with a plan to go on to neuroscience if it didn't work out. It worked out! Since then, I developed my computer skills and got a research job doing software development with a linguistic focus.

I have not had specific goals for my career path; I just try apply to everything that sounds interesting and don't get down when I get rejected. Don't doubt your qualifications.

The skill that linguistics gave me that I use the most is problem solving. I use the approaches I learned in historical linguistics and linguistic analysis every day for debugging, both for the software at my job, but also for debugging the world around me.

Another important skill is writing. Due to your writing skills, you shouldn't be afraid to apply for a job where you wouldn't be a subject-matter expert. You can work as a catalyst, documenting and pushing everyone else along.

During college, it is hard to justify writing outside of class because of time spent on in-class writing, but after college, make sure you keep writing. In addition to maintaining the technical skill of writing, writing regularly helps people organize their thoughts and allows them to become more effective at what they do.

If you have or are getting a linguistics major and are looking for some direction, feel free to send me an email.

Setting WTForms selection fields dynamically

---

WTForms is a very useful tool for constructing web forms and operating on their data.

Setting selection fields dynamically from database content is not directly apparent, but they do provide one recipe to accomplish such functionality. I don't mind this approach, but there are a few other options.

One approach that I've used is to provide a set_choices method:

class MyForm(Form):
    selection_field = SelectField()

    def set_choices(self):
        from models import Model
        self.selection_field.choices = query(Model).all()

You'd have to call the set_choices method after instantiating your form. This gives you some flexibility, but some redundant code.

Another option is to do this work in the __init__:

class MyForm(Form):
    ...
    def __init__(self):
        super(MyForm, self).__init__()

        from models import Model
        self.selection_field.choices = query(Model).all()

This allows you to use the filtered form without changing your external code.

Another approach would be to pass in the choices as a parameter to __init__:

class MyForm(Form):
    ...
    def __init__(self, selection_choices):
        super(MyForm, self).__init__()
        self.selection_field.choices = selection_choices

Thoughts on Beeminder

---

I've been using Beeminder for two months. I'm currently tracking 14 different goals. Two issues that I had with some of my early goals were not measuring the right metric and using 'Do Less' goals.

For an example of an incorrect metric, I started tracking how many days I follow pescatarian, vegetarian, and vegan diets. I didn't know what my rate was, so I set a low initial rate and began to measure. After a few days I realized that I should be tracking meals, as many days I eat two vegan meals but then ate some meat with one meal, so I wasn't capturing that information. I changed my metric to number of meals, and have been tracking that since. After a few weeks of tracking meals, I adjusted my rate to be closer to the historical data.

With the 'Do Less' goals, there is not enough of an incentive to report information, so they lend themselves to cheating. I don't recall actually cheating, but toward the end of me trying them out, I decided I didn't want it to be that easy. So, I reframed my goals to be 'Do More' goals. For example, instead of 'Do less sleeping in', I am now tracking number of days I get up at dawn.

I've not paid them any money yet! When I tell people about Beeminder they say that they're willing to take my money, too. They don't quite get it.

If and when I pay in, I'll be paying to do the things that I want to be but wouldn't otherwise be doing. That's priceless.

(By the way, I wrote this blog post because I was going to fall off my blogging goal tomorrow if I didn't!)

Why I don't have a LinkedIn account

---

I used to have a LinkedIn account. After their password leak in 2012, I got rid of my account. At the time, I did not have a serious web presence, but I've unbundled my use of their services into this site. My about page accounts for most of what LinkedIn provided me at the time.

Some may argue that what I have isn't social, though I do 'link in' to my collaborators web presences when I can. This linking not only helps our collective PageRank, but provides a connection to a distributed social web.

Since 2012, when I've seen other people use LinkedIn, I've been consistently surprised by the feature creep. LinkedIn has been attempting to gain features of blogging and mailing lists, while also providing feature-parity with Facebook, but focused on business instead of personal interactions. I'm not sold on the idea.

Edit (June 2017): I caved and recently created a LinkedIn profile.

The need for a non-technical co-founder, found in a technical co-founder

[W]e informed Richard [Feynman] that his assignment would be to advise on the application of parallel processing to scientific problems. “That sounds like a bunch of baloney,” he said. “Give me something real to do.” So we sent him out to buy some office supplies.

Danny Hillis, from Richard Feynman and The Connection Machine

On choosing the best tool for the job

Last week, I gave a talk entitled “Why Not Django”. This is an essay version.

Multitools are great. They can do many things, though not always well.

Occasionally, I find things I can't do with my multitool, but I do them anyway. If I need a prybar, I'll use the flat-head screwdriver from my multitool. If I need a saw, I'll use the tiny one on my multitool.

If all you have is a hammer, everything looks like a nail.

– Law of the instrument

Using tools for different or bigger jobs than they are meant for can lead to damage. My flat-head screwdriver isn't so flat anymore. At what point is a damaged multitool no longer considered useful? I'd argue that point happens sooner than if they were individual tools, as carrying around a multitool with only a few working tools isn't worth the extra effort.

Multitools are useful, but they have their place. Everyone should have one in their toolbox, but you should always prefer single-use tools.

[Use tools] that do one thing, and do it well.

– Doug McIlroy, UNIX philosopher.

By using single-use tools, we decompose the multitool into a bigger toolbox, with tools more apt for their respective jobs. This decomposition leads to a separation of concerns, so the bottle opener doesn't need to be hanging off the side of your screwdriver. When your requirements change (and they always do), you don't need to worry about the interdependencies of your tools.

Some may argue that multitools give you greater flexibility than other tools. However, there is more than one way to define flexibility in this context. In addition to having flexible tools which can be used for different use cases, we also need the flexibility to choose the best tool for the job.

See also: On Choosing the Best Tool for the Job.