A blog and website by Peter Bengtsson
31 January 2019 0 comments Python
Prior to version 0.14.5 hashin would write write down the hashes of PyPI packages in the order they appear in PyPI's JSON response. That means there's a slight chance that two distinct clients/computers/humans might actually get different output when then run
hashin Django==2.1.5.
The pull request has a pretty hefty explanation as it demonstrates the fix.
Do note that if the existing order of hashes in a requirements file is not in the "right" order, hashin won't correct it unless any of the hashes are different.
Thanks @SomberNight for patiently pushing for this.
29 January 2019 0 comments Linux, MacOSX
Suppose you have a cleartext file that you want to encrypt with a password, here's how you do that with ccrypt on macOS. First:
Now, you have the ccrypt program. Let's test it:
▶ cat secrets.txt
Garage pin: 123456
Favorite kid: bart
Wedding ring order no: 98c4de910X
▶ ccrypt secrets.txt
Enter encryption key: ▉▉▉▉▉▉▉▉▉▉▉
Enter encryption key: (repeat) ▉▉▉▉▉▉▉▉▉▉▉
# Note that the original 'secrets.txt' is replaced
# with the '.cpt' version.
▶ ls | grep secrets
secrets.txt.cpt
▶ less secrets.txt.cpt
"secrets.txt.cpt" may be a binary file. See it anyway?
There. Now you can back up that file on Dropbox or whatever and not have to worry about anybody being able to open it without your password. To read it again:
▶ ccrypt --decrypt --cat secrets.txt.cpt
Enter decryption key: ▉▉▉▉▉▉▉▉▉▉▉
Garage pin: 123456
Favorite kid: bart
Wedding ring order no: 98c4de910X
▶ ls | grep secrets
secrets.txt.cpt
Or, to edit it you can do these steps:
▶ ccrypt --decrypt secrets.txt.cpt
Enter decryption key: ▉▉▉▉▉▉▉▉▉▉▉
▶ vi secrets.txt
▶ ccrypt secrets.txt
Enter encryption key:
Enter encryption key: (repeat)
Clunky that you have you extract the file and remember to encrypt it back again. That's where you can use emacs. Assuming you have emacs already installed and you have a ~/.emacs file. Add these lines to your ~/.emacs:
(setq auto-mode-alist
(append '(("\\.cpt$" . sensitive-mode))
auto-mode-alist))
(add-hook 'sensitive-mode (lambda () (auto-save-mode nil)))
(setq load-path (cons "/usr/local/share/emacs/site-lisp/ccrypt" load-path))
(require 'ps-ccrypt "ps-ccrypt.el")
By the way, how did I know that the load path should be /usr/local/share/emacs/site-lisp/ccrypt? I looked at the output from brew:
▶ brew info ccrypt
ccrypt: stable 1.11 (bottled)
Encrypt and decrypt files and streams
...
==> Caveats
Emacs Lisp files have been installed to:
/usr/local/share/emacs/site-lisp/ccrypt
...
Anyway, now I can use emacs to open the secrets.txt.cpt file and it will automatically handle the password stuff:
About to open
Opening with password
Opened
This is really convenient. Now you can open an encrypted file, type in your password, and it will take care of encrypting it for you when you're done (saving the file).
Be warned! I'm not an expert at either emacs or encryption so just be careful and if you get nervous take precaution and set aside more time to study this deeper.
22 January 2019 0 comments Python, Django
tl;dr; If you use the django.views.decorators.cache.cache_control decorator, consider this one instead to change the max_age depending on the request.
I had/have a Django view function that looks something like this:
@cache_control(public=True, max_age=60 * 60)
def home(request, oc=None, page=1):
...
But, that number 60 * 60 I really needed it to be different depending on the request parameters. For example, that oc=None, if that's not None I know the page's Cache-Control header can and should be different.
So I wrote this decorator:
from django.utils.cache import patch_cache_control
def variable_cache_control(**kwargs):
"""Same as django.views.decorators.cache.cache_control except this one will
allow the `max_age` parameter be a callable.
"""
def _cache_controller(viewfunc):
@functools.wraps(viewfunc)
def _cache_controlled(request, *args, **kw):
response = viewfunc(request, *args, **kw)
copied = kwargs
if kwargs.get("max_age") and callable(kwargs["max_age"]):
max_age = kwargs["max_age"](request, *args, **kw)
# Can't re-use, have to create a shallow clone.
copied = dict(kwargs, max_age=max_age)
patch_cache_control(response, **copied)
return response
return _cache_controlled
return _cache_controller
Now, I can do this instead:
def _best_max_age(req, oc=None, **kwargs):
max_age = 60 * 60
if oc:
max_age *= 10
return max_age
@variable_cache_control(public=True, max_age=_best_max_age)
def home(request, oc=None, page=1):
...
I hope it inspires.
18 January 2019 0 comments Javascript, ReactJS
When Immer first came out I was confused. I kinda understood what I was reading but I couldn't really see what was so great about it. As always, nothing beats actual code you type yourself to experience how something works.
Here is, I believe, a great example: https://codesandbox.io/s/y2m399pw31
If you're reading this on your mobile it might be hard to see what it does. Basically, it's a very simple React app that displays a "todo list like" thing. The state (aka. this.state.tasks) is a pure JavaScript array. The React components that display the data (e.g. <List tasks={this.state.tasks}/> and <ShowItem item={item} />) are pure (i.e. extends React.PureComponent) meaning React natively protects from re-rendering a component when the props haven't changed. So no wasted render-cycles.
What Immer does is that it helps mutate an object in a smart way. I'm sure you've heard that you're never supposed to mutate state objects (arrays are a form of mutable objects too!) and instead do things like const stuff = Object.assign({}, this.state.stuff); or
const things = this.state.things.slice(0);. However, those things are shallow copies meaning any mutable objects within (i.e. nested objects) don't get the clone treatment and can thus cause problems with not re-rendering when they should.
Here's the core gist:
import React from "react";
import produce from "immer";
class App extends React.Component {
state = {
tasks: [[false, { text: "Do something", date: new Date() }]]
};
onToggleDone = (i, done) => {
// Immer
// This is what the blog post is all about...
const tasks = produce(this.state.tasks, draft => {
draft[i][0] = done;
draft[i][1].date = new Date();
});
// Pure JS
// Don't do this!
// const tasks = this.state.tasks.slice(0);
// tasks[i][0] = done;
// tasks[i][1].date = new Date();
this.setState({ tasks });
};
render() {
// appreviated, but...
return <List tasks={this.state.tasks}/>
}
}
class List extends React.PureComponent {
...
It just works. Neat!
By the way, here's a code sandbox that accomplishes the same thing but with ImmutableJS which I think is uglier. I think it's uglier because now the rendering components need to be aware that it's rendering immutable.Map objects instead.
Caveats
The cost of doing what immer.produce isn't free. It's some smart work that needs to be done. But the alternative is to deep clone the object which is going to be much slower. Immer isn't the fastest kid on the block but unlike MobX and ImmutableJS once you've done this smart stuff you're back to plain JavaScript objects.
Careful with doing something like console.log(draft) since it will raise a
TypeError in your web console. Just be aware of that or use console.log(JSON.stringify(draft)) instead.
If you know with confidence that your mutable object does not, and will not, have nested mutable objects you can use object spread, Object.assign(), or .slice(0) and save yourself the trouble of another dependency.
08 January 2019 0 comments Python
I only just learned about this today after all these years and thought you might like it too.
The trick is to conveniently turn an argparse.Namespace into keyword arguments that you can send to a function. This is the old/wrong way I've been doing it for years:
# THE OLD WAY
def main(things, option_a, option_n):
print(locals()) # Debugging
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("things", help="Bla bla", nargs="*")
parser.add_argument("-o", "--option-a", help="Bla bla", default="Op A")
parser.add_argument("-n", "--option-n", help="Ble ble", default="Op N")
args = parser.parse_args()
main(
things=args.things,
option_a=args.option_a,
option_n=args.option_n
)
That works but the tedious thing is to have to have spell out every single argument, twice!, when sending the argparse Namespace into the function. Here's the much moar betterest way:
# THE NEW WAY
def main(things, option_a, option_n):
print(locals()) # Debugging
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("things", help="Bla bla", nargs="*")
parser.add_argument("-o", "--option-a", help="Bla bla", default="Op A")
parser.add_argument("-n", "--option-n", help="Ble ble", default="Op N")
args = parser.parse_args()
# The only difference and the magic sauce...
main(**vars(args))
What's neat about this is that you don't have to type up every argument defined in the parser to the get it as arguments into a function. And as a bonus, Python will name match keyword arguments to arguments so the order doesn't matter.
Caveat! This "trick" assumes that the arguments in the parser match the arguments in the function. So if the main() function takes an argument called foo_bar you have to have an argument in the parser called --foo-bar.
04 January 2019 0 comments Javascript
tl;dr; Use Number.prototype.toString()
to display percentages that might be floating point numbers.
I started writing a complicated solution but as I discovered corner cases and surprised I was brutally forced to do some research and actually read some documentation. Turns out Number.prototype.toString(), with the precision argument omitted, is the ideal solution.
The application I was working on has an input field to type in a percentage. I.e. a number between 0 and 100. But whatever the user types in, we store the number in decimal. So, if the user typed in "10" into the input widget, we actually store it as 0.1
in the database. Most people will type in a whole number (aka. an integer) like "12" or "5" but some people actually need more precision so they might type in "0.2%" which means 0.002 stored in the backend database.
But the widget is a React controlled component meaning it's value prop needs to be potentially formatted to what gives the best user experience. If the user types in whole numbers set the value prop to a whole number. If the user types in floating point numbers set the value prop type a floating point number with the "matching formatting".
I started writing an overly complicated function that tries to figure out how many decimal-points the user typed in. For example 0.123 is 3 because parseInt(0.123 * 10 ** 3, 10) === 0.123 * 10 ** 3. But, that approach doesn't work because of floating point arithmetic and the rounding problem. For example 103441 !== 10.3441 * (10 ** 4) === 103440.99999999999. So, don't look for a number to pass into .toFixed().
Turns out Number.prototype.toString() is all you need. If you omit the precision argument, it figures out how many significant digits to use based on the input. It's best explained with some examples:
> (33).toString()
"33"
> (33.3).toString()
"33.3"
> (33.10000).toString()
"33.1"
> (10.3441).toString()
"10.3441"
Perfect!
Next level stuff
So actually, it's a bit more complicated than that. You see, the number stored in the backend database might be 0.007 which you and I know as "0.7%" but be warned:
> 0.008 * 100
0.8
> 0.007 * 100
0.7000000000000001
You know, because of floating-point arithmetic, which every high-level software engineer remembers understanding one time years ago but now know just to watch out for.
So if you use the toString() on that you'd get...
> var backendPercentage = 0.007
> (100 * backendPercentage).toString() + '%'
"0.700000000000001%"
Ouch! So how to solve that? Use Math.round(number * 100) / 100 to get rid of those rounding errors. Apparently, it's very fast too. So, now combine this with the toString():
> var backendPercentage = 0.007
> (Math.round(100 * backendPercentage * 100) / 100).toString() + '%'
"0.7%"
Perfect!
