Laser cut from cardboard, then glued to paper and cut out, then hot glued into a box and fitted with an IKEA Hemma cord set.
Author Archives: tsaylor
Bikeshedding is the Mind Killer
I must not bikeshed.
Bikeshedding is the mind-killer.
Bikeshedding is the little-death that brings total dysfunction.
I will take action.
I will permit it to make progress through me.
And when I finish my work I will turn the inner eye to see the gains I have made.
Where the bikeshedding has gone there will be nothing.
Only action will remain.
Knife Making
Now that I’m no longer the president of Pumping Station: One I can legitimately shirk responsibility and do fun projects at the space. This weekend, knife making!
The top one was ground from a blank of O1 tool steel and heat treated. It’s sitting on a blank of oak that’s going to become its handle. I meant to bend it to make a spoon carving knife but I forgot to do that before heat treating, so instead of fixing this one I’ll just make another and fix a few more mistakes along the way.
The bottom one was forged from a railroad spike, formed on a grinding wheel and finished / sharpened at the belt sander. It’s not good knife metal, it’s just a project to get started at blacksmithing. And it looks purdy.
Getting Data From a Bound but Unvalidated Form
I have a form with dynamic fields, meaning the answers available for field B depend on the answer for field A. Therefore, when the form is submitted I get the value from field B, but when it’s redisplayed I have to read the value from field A and populate the choices for field B or else field B is blanked out in the browser.
I looked for a convenient way to read the bound data from a specified form field and was surprised that I couldn’t find one. I could just read the POST, but this form is in a formset with a prefix, so I’d have to assemble a complicated key name like “foo_bar_form-1-fieldname”. The closest I saw to an interface to get the data was the _raw_value(fieldname) method which I couldn’t get to work and is suboptimal since it’s an internal call and could change in the future.
I ended up having to go to the POST data anyway, but I saw a helper function in _raw_value(fieldname) that made it easier. What I ended up doing was this:
field_value = self.request.POST[form.add_prefix('fieldname')]
add_prefix(fieldname) is a public method to take care of the prefix hassle for me, so reading the post value is doable. The only thing to watch out for is that you have to handle potential invalid values when redisplaying a form with errors.
Vim Is Wrong
I just saw this post on Stack Overflow about some clever vim commands and as a vim user I was glad to learn some new tricks I can use. Then I read the reddit comments about the story and found this (screencapped in case that link changes):
When writing software the code is written once but probably read dozens of times. Therefore, readable code is very important. This is one of the central tenets of Python. These commenters are debating whether readability is equally as important with Vim commands as it is in programming languages.
Previously I would have sided with the advocates of Vim’s terse command syntax without much thought. Short commands are easier to type and can be more effective. However, this thread made me reconsider. Because of Vim’s terse commands, they are harder to learn and to remember. And once a command is learned, it may be learned as a magical incantation and not a sequence of instructions, so the components won’t be learned and reused for other needs. So unless a Vim user spends a considerable amount of time learning commands, they’ll be using the editor inefficiently and getting less done than they could because of Vim’s terse commands and steep learning curve. I’m no longer sure that the efficiency gained by having short, easy to type commands is worth the efficiency lost by having a large set of hard to remember commands in your brain, and an equally large set that you aren’t using because you don’t know them.
Python has a relatively small syntax. Most things are explicit so there aren’t a bunch of implicit things you have to remember to know what your code is doing. The advantage that gives a developer is that they can write code more quickly without having to look up syntax rules or function calls all the time. Also, a new developer can come to the code and will understand the program more quickly with fewer things to learn. As I thought about Vim’s command complexity, it occurred to me that we already have a command set that’s easy to write, read, and remember, and it’s quick and easy to write a short script like the one in that Stack Overflow comment: Python! Why can’t Vim use Python to edit the working document? The Python scripting support is a good start for complex add-ons, but why not make it even more integrated with things like :find(‘query’) instead of /query? I’m very curious if a readily accessible, full blown python interpreter would make my vim use more effective.
P.S. Emacs? </blasphemy>
Get The Display Name Of A ModelChoiceField’s Selected Value in Django
I just had a formset where each form had a pre-loaded ModelChoiceField, and I needed to display the name of the selected choice in the template. On a model you would just use the get_FOO_display() method, but a form has no such convenience. I found a number of almost solutions on Stack Overflow, and after poring over them I concluded the best solution for my problem was to add the following method to the form:
class QuestionLanguageForm(forms.Form):
''' basic QuestionLanguage form '''
language = forms.ModelChoiceField(queryset=Language.objects.all())
short = forms.CharField()
place_holder = forms.CharField()
long = forms.CharField(widget=forms.Textarea(attrs={'rows':None, 'cols':None}))
def get_language_name(self):
''' returns the name of the selected language '''
try:
return Language.objects.get(id=self.initial['language']).name
except:
return None
This way I can use
{{ form.get_language_name }}
in my template and it prints the human readable name of the language set in my initial data. This code is not robust; I catch all exceptions and ignore them because I’m only using it in a circumstance where this code won’t raise an exception (and in case it does, at least it won’t fail catastrophically). However proper error handling could be added pretty simply. #ExerciseForTheReader
P.S. The title says “selected” value but I’m actually using a pre-loaded value, not anything user selected. If you need to get a user selected value you could use self.data or self.cleaned_data instead of self.initial.
Convert Django Model Instances To Dictionaries
I just searched for a method to convert a model instance to a dictionary in Django and the top few results were a bunch of custom methods in Django Snippets and Stack Overflow. I was about to use one of those when I clicked on one last link that showed me a better solution. There is a method already built into Django that does exactly what I want: django.forms.models.model_to_dict.
As I pointed that out to a coworker, he showed me that that’s basically the same output as the .values() method in the queryset api. If you don’t specify a value to retrieve, it will retrieve the whole model instance as a dictionary.
Here’s the output of these two pieces of code:
>>> Q.objects.filter(id=6).values()
[{'short': u'oui', 'deleted': False, 'language_id': 3L, 'long': u'oui', 'place_holder': u'oui', 'id': 6L, 'question_id': 8L}]
>>> model_to_dict(Q.objects.filter(id=6)[0])
{'short': u'oui', 'language': 3L, 'deleted': False, 'question': 8L, 'long': u'oui', 'place_holder': u'oui'}
There are two differences here, and one of them is pretty important. First, .values() turns a queryset into an iterable that yields dictionaries, and model_to_dict turns a model instance into a single dictionary. As long as you know about it this is pretty trivial to overcome. Second, .values() converts foreign keys to {‘<field_name>_id’: #} and model_to_dict converts them to {‘<field_name>’: #}. Since my purpose in using this was to populate a form I had to convert the id’s into model instances and update the dictionary. Not a big problem, but a bigger annoyance to solve than the first difference.
IOError: request data read error
I couldn’t find a good simple explanation of what this error means on the web, so to future googlers, you’re welcome.
This most likely means that the user made a web reqeuest, probably through ajax, on your site and then cut off the connection before the ajax request completed. The connection can be cut off by clicking on another link, closing the browser, or things in the middle like firewalls and whatnot.
There isn’t a good solution to this issue that I could find, the error is just something that happens from time to time. If it happens regularly and you don’t think it’s an accidental connection cut off, do some more exploring (particularly with firewalls and other potential connection problems), otherwise it can be ignored.
Commerce Update
I’ve done some exciting things in the world of commerce since my last post. After Pumping Station: One got a laser cutter I started cutting stuff from Thingiverse and thinking of products I could make with it. I fixed the Thingiverse files for Tetris blocks and made some of those. Then I thought of making glasses out of the Look of Disapproval from reddit. Then Gretchen wanted me to make her something on the laser, so I made her a pendant with the kiss emoticon. After a while I put all these things on my etsy store, Optical Awesome. The Look of Disapproval Glasses started really taking off, and I’ve now sold over 150 of them! Exciting stuff. I’ve decided to move all my e-commerce to etsy since they make it so easy and deliver me traffic through their search.
I also sold things at Maker Faire NY, which was great. My necklaces and t-shirts were big hits and I just about made enough money to cover the expenses of the trip. (Lesson #1, don’t dig so big a hole that you have to have a ton of success to get back out of it.) I kept track of a few things I started out doing wrong and did my best to fix on the spot, so hopefully those mistakes won’t happen again:
- Post a price or people don’t know it’s for sale. With all the makers just exhibiting things, it’s easy to get confused.
- If you put t-shirts out on a table people will look through them for their size. Either have sizes out there or hang them up behind you.
- Don’t underestimate the number of girls there. I didn’t think necklaces would sell well, but a ton of girls came by and loved them.
- People loved trying on the look of disapproval glasses and sending pics to their friends. If I had a kiosk to do that it would be nice for collecting emails.
BARcamp Chicago is July 9th & 10th!
I’ve been hard at work for the last couple months helping to get BARcamp Chicago put together this year. We’re hosting it at Pumping Station: One on the weekend of July 9th and 10th, and as always the event is free and there will be food and drinks provided (and not just pizza, we’ll be grilling hamburgers and hot dogs on site).
If you’ve never been to BARcamp or to any unconference before, you should definitely come check it out. The weekend will be filled with a wide variety of technology and entrepreneurship talks given by attendees. If you have some knowledge you’d like to share, you can give a talk too!
We’re also repeating the BARcompany contest. Last year we had three companies present business plans and prototypes, and the winner, Sacha DeAngeli of RuggedScents, has now launched his third manly scented cologne and has revenue coming in. This year we have three experienced judges and a cash prize for the winner, so start thinking about something you’d like to make.
I know I’m excited for BARcamp this year, and I hope you are too! For more info, check out our website at http://www.barcampchicago.org/ or follow us on twitter.
