Page 45
I've finally had time to sort out the django-mongokit code so it's now fully compatible with Django 1.4.
Because I don't personally use the project I've sort of got myself lost in various patches from some awesome contributors who keep it in check.
Also, thanks to Marc Abramowitz who added a tox.ini which I've now updated to also test python 2.7 and Django 1.4
Go forth and build awesome Django apps with MongoKit which is still think is the best wrapper available on PyMongo out there.
Last month I built a very basic mobile app using jQuery Mobile. It's still available here.
One flaw I found with jQuery Mobile is that it's a bit slow. Scrolling up and down feels sluggish. It looks pretty though.
This time around I opted instead to use Twitter Bootstrap instead. (inspired by some other blog post with a similar experience)
Also, with this version I've set up a domain name: uslicensespotter.com
The source code is available here and there are some interesting pieces of this that I'd like to delve into deeper.
Optimization
This new app feels faster and scrolling is smoother. There is still some parts where it doesn't feel snappy. The primary part is when you click one of the buttons. It works something like this:
// binding (simplified)
$('form a.btn').click(function(event) {
var $el = $(this);
var id = $el.attr('id');
if ($el.hasClass('btn-success')) {
switch_off($el);
State.remove(id);
} else {
switch_on($el, new Date());
State.add(id);
}
return false;
});
// the switch_on function
function switch_on($el, timestamp) {
$el.addClass('btn-success');
$('i', $el).addClass('icon-white').removeClass('icon-remove').addClass('icon-check');
$('span', $el).text(timeSince(timestamp));
}
There are two potentials for making this faster.
element.click(...) I can use touch events which supposedly fire better thus starting the actual animation earlier. My next task is to apply both of these ideas and try to somehow keep and eye on which makes the biggest impact.
Deployment
One neat new feature with this new code is the deployment script, build.py. The actual code might be a bit of a mess but the way it works for me is great.
What I do is that I work on the app by editing dev.html and when I deploy I run python build.py and it opens dev.html and concatenates and minifies all CSS and Javascript ready for ideal caching. This reduces the static assets down to just three files weighing only 78Kb altogether.
(Note: even more can be done such as switching to ZeptoJS and removing bootstrap stuff I don't need with a custom download)
What the script does is that it parses the dev.html template with lxml and applies whatever transformations it needs to do such as generating the Apple touch images eg. this one
I think a lot of mobile web developers can benefit from this script. Maybe you don't want to copy it verbatim but you might want to copy it and do the transformations you want to do.
My good friend @jonanmary brought this very amusing tweet to my attention:
I know you've all seen this, but it's awesome anyway: Photographing other sports like beach volleyball metro.us/newyork/sports... #olympics
That's brilliant! The thing is, if you didn't already know it, beach volleyball gals are mandated to wear those speedos looking things they wear. What's even more funny is something another good friend, @trollkip on twitter point:
@jonanmary @peterbe out of interest, earlier, I looked up who makes these rules. Governing body: fivb.org/EN/FIVB/Board_ Yeah.
UPDATE
Apparently, the rule about what beach volleyball players have to wear changed recently
I love me some tanned sexy lady-skin but don't be an asshole about it. Let her choose.
About 5 years ago I switched from Apache to Nginx. And with that switch I could practically stop stabbing my feet with HTTP accelerators like Squid and Varnish because Nginx serves files from the filesystem both faster and more efficient than the accelerators. And, it's one less moving part that can go wrong.
Then in late 2010 Amazon introduced Custom Origins on their Amazon CloudFront CDN service. Compared to other competing CDNs I guess CloudFront loses some benchmarks and win some others. Nevertheless, network latency is the speed-freaks biggest enemy and CDNs are awesome.
With Custom Origin all you do is tell CloudFront to act as a "proxy". It takes and URL and replaces the domain name to go and fetch the original from your own server. For example...
http://mydomain.com/static/foo.css http://efac1bef32rf3c.cloudfront.net/static/foo.css http://mydomain.com/static/foo.css and saves a copy So, if I make my Nginx server serve /static/foo.css with:
Expires: Thu, 31 Dec 2037 23:55:55 GMT Cache-Control: max-age=315360000 Cache-Control: public
Then CloudFront will do the same and it means it will never come back to your Nginx again. In other words, your Nginx server serves the cacheable static assets once and all other requests are just the usual HTML and JSON and whatever your backend web server spits out.
So, what does this mean? It means that we can significantly re-think they way we write code that prepares and builds static assets. Instead of a complex build or a run-time process that ultimately writes files to the filesystem we can basically do it all in run-time and not worry about speed. E.g. something like this::
# urls.py
url(r'/static/(.*\.css)', views.serve_css)
# views.py
def serve_css(request, filename):
response = http.HttpResponse(mimetype="text/css")
response.setHeader('Cache-Control': 'public, max-age:315360000')
content = open(filename).read()
content = cssmin.cssmin(content)
content = '/* copyright: you */\n%s' % content
response.write(content)
return response
That's untested code that can be vastly improved but I hope you get the idea. Obviously there are lots more things you can and should do such concatenating files.
So, what does this also mean? You don't need Nginx. At least not for serving static files faster. I've shown before that something like Nginx + uWSGI is "better" (faster and less memory) than something like Apache + mod_wsgi but oftentimes the difference is negligable.
I for one am not going to re-write all my various code I have to prepare for optimal static assets hosting but I'll definietly keep this stuff in mind. After all, there are other nifty things Nginx can do too.
By the way, here's a really good diagram that explains CloudFront
UPDATE
Want to read this in Serbian? Thank you Anja Skrba for the translation!
(This post is a response to Richard Patchet's request for tips on how to actually use premailer)
First of all, premailer is a Python library that converts a document of HTML and tranforms its <style> tags into inline style attributes on the HTML itself. This comes very handy when you need to take a nicely formatted HTML newletter template and prepare it before sending because when you send HTML emails you can't reference an external .css file.
So, here's how to turn it into a command line script.
First, install, then write the script:
$ pip install premailer $ touch ~/bin/run-premailer.py $ chmod +x ~/bin/run-premailer.py
Now, you might want to do this differently but this should get you places:
#!/usr/bin/env python
from premailer import transform
def run(files):
try:
base_url = [x for x in files if x.count('://')][0]
files.remove(base_url)
except IndexError:
base_url = None
for file_ in files:
html = open(file_).read()
print transform(html, base_url=base_url)
if __name__ == '__main__':
import sys
run(sys.argv[1:])
To test it, I've made a sample HTML page that looks like this:
<html>
<head>
<title>Test</title>
<style>
h1, h2 { color:red; }
strong {
text-decoration:none
}
p { font-size:2px }
p.footer { font-size: 1px}
p a:link { color: blue; }
</style>
</head>
<body>
<h1>Hi!</h1>
<p><strong>Yes!</strong></p>
<p class="footer" style="color:red">Feetnuts</p>
<p><a href="page2/">Go to page 2</a></p>
</body>
</html>
Cool. So let's run it: $ run-premailer.py test.html
<html>
<head>
<title>Test</title>
</head>
<body>
<h1 style="color:red">Hi!</h1>
<p style="font-size:2px"><strong style="text-decoration:none">Yes!</strong></p>
<p style="{color:red; font-size:1px} :link{color:red}">Feetnuts</p>
<p style="font-size:2px"><a href="page2/" style=":link{color:blue}">Go to page 2</a></p>
</body>
</html>
Note that premailer supports converting relative URLs, so let's actually using that:
$ run-premailer.py test.html https://www.peterbe.com
<html>
<head>
<title>Test</title>
</head>
<body>
<h1 style="color:red">Hi!</h1>
<p style="font-size:2px"><strong style="text-decoration:none">Yes!</strong></p>
<p style="{color:red; font-size:1px} :link{color:red}">Feetnuts</p>
<p style="font-size:2px"><a href="https://www.peterbe.com/page2/"
style=":link{color:blue}">Go to page 2</a></p>
</body>
</html>
I'm sure you can think of many many ways to improve that. Mayhaps use argparse or something fancy to allow for more options. Mayhaps make it so that you can supply named .css files on the command line that get automagically inserted on the fly.
This is part 1 in, hopefully, a series of blog articles about developing mobile apps with Javascript.
My app that I'm going to build is called "US License Plate Spotter". A dead-simple app where you tick off each US state once you see it.
In case you didn't know, in the USA, you mostly see "local" license plates because if you for example buy a car in Micigan but move to California, after about 3 months you have to re-license it with plates from the state you're living in. So here where I live, in California, you mostly see "California plates" but every now and then you see other plates such as Nevada, Washington or Floria. The further away, the less likely to be spotted.
Anyway, the first version is available right here: https://www.peterbe.com/uslicenseplates/index.html Code is on Github
It works best in smartphones like an Android or iOS app since it's built with jQuery Mobile
This is about 2 hours of work which is pretty quick but it was easy because I've used jQuery Mobile a lot in the past and this was more or less just getting familiar with the recent changes.
The app works fine and I even used it this last weekend to keep track of new license plates since Friday.
Next steps:
localStorage) using the Facebook API UPDATE
Here's part 2 in the series.
The @staticmethod decorator is nothing new. In fact, it was added in version 2.2. However, it's not till now in 2012 that I have genuinely fallen in love with it.
First a quick recap to remind you how @staticmethod works.
class Printer(object):
def __init__(self, text):
self.text = text
@staticmethod
def newlines(s):
return s.replace('\n','\r')
def printer(self):
return self.newlines(self.text)
p = Printer('\n\r')
assert p.printer() == '\r\r'
So, it's a function that has nothing to do with the instance but still belongs to the class. It belongs to the class from an structural point of view of the observer. Like, clearly the newlines function is related to the Printer class. The alternative is:
def newlines(s):
return s.replace('\n','\r')
class Printer(object):
def __init__(self, text):
self.text = text
def printer(self):
return newlines(self.text)
p = Printer('\n\r')
assert p.printer() == '\r\r'
It's the exact same thing and one could argue that the function has nothing to do with the Printer class. But ask yourself (by looking at your code); how many times do you have classes with methods on them that take self as a parameter but never actually use it?
So, now for the trump card that makes it worth the effort of making it a staticmethod: object orientation. How would you do this neatly without OO?
class UNIXPrinter(Printer):
@staticmethod
def newlines(s):
return s.replace('\n\r', '\n')
p = UNIXPrinter('\n\r')
assert p.printer() == '\n'
Can you see it? It's ideal for little functions that should be domesticated by the class but have nothing to do with the instance (e.g. self). I used to think it looked like it's making a pure looking thing like something more complex that it needs to be. But now, I think it looks great!
I learned something today thanks to my colleague Axel Hecht; the difference between $element.data('foo') and $element.attr('data-foo').
Basically, the .data() getter/setter is more powerful since it can do more things. For example:
<img id="image" data-number="42">
// numbers are turned to integers
assert($('#image').data('number') + 1 == 43);
// the more rudimentary way
assert($('#image').attr('data-number') + 1 == '421');
Integers is just one thing the .data() getter is able to parse. It can do other cool things too like booleans and JSON. Check out its docs
So, why would you NOT use .data()?
One reason is that with .data(name, value) the original DOM element is not actually modified. This can cause trouble if other pieces of Javascript depend on the value of a data- attribute further along in the page rendering process.
To see it in action check out: test.html
In conclusion: just be aware of it. Feel free to use the .data() getter/setter because it's way better but be aware of the potential risks.
First of all, this technique is only really applicable to apps where there's only one big HTML template which is then shuffles, part hidden and part visible thanks to lots of Javascript. Those familiar with jQuery Mobile will have seen this.
On Around The World there are a lot of images. Majority of them you don't need to see immediately because only one screen is loaded at the time. The page structure looks like this:
<div class="section" id="page1">
<h2>Page 1</h2>
<img src="section-icon1.png">
</div>
<div class="section" id="page2" style="display:none">
<h2>Page 2</h2>
<img src="section-icon2.png">
</div>
<div class="section" id="page3" style="display:none">
<h2>Page 3</h2>
<img src="section-icon3.png">
</div>
So, if you load that you'll notice that your browser will download "section-icon1.png", "section-icon2.png" and "section-icon3.png" even though two of the images are not going to be displayed. Good for pre-loading the images when they're later needed but bad for the user experience since the browser will be busy downloading images rather than displaying the first visible section.
This is how I solve this; first I change the HTML to be this:
<div class="section" id="page1">
<h2>Page 1</h2>
<img src="." data-src="section-icon1.png" class="deferred">
</div>
<div class="section" id="page2" style="display:none">
<h2>Page 2</h2>
<img src="." data-src="section-icon2.png" class="deferred">
</div>
<div class="section" id="page3" style="display:none">
<h2>Page 3</h2>
<img src="." data-src="section-icon3.png" class="deferred">
</div>
And now for the magic that turns these img tags into real normal img tags. The truth is that the Javascript about loading individual sections is a bit more complicated but in its inner core it looks something like this:
// variable 'hash' is something like 'page2'
if ($(hash + '.section').size()) {
$('.section:visible').hide();
$(hash + '.section').show();
$('img.deferred', hash).each(function() {
var el = $(this);
el.attr('src', el.data('src'));
el.removeClass('deferred');
});
...
It makes the HTML slightly more complicated but the end result is great. It's not just useful for the first-time load but also applicable every time someone reloads the page.
Just in case this hits you too when you use CITEXT fields that were originally defined in a Postgres before version 9.1.
ProgrammingError: could not determine which collation to use for string comparison HINT: Use the COLLATE clause to set the collation explicitly.
This can happen if you use something like:
WHERE name='peter'
when field name is a case insensitive text field.
After some googling around and shooting in the dark I found the the only way to crack this is to run this command:
CREATE EXTENSION citext FROM unpackaged;
Hope that helps some poor schmuck with the same problem.
UPDATE
If you have problems applying this to new tables in Postgres 9.1 you might need to run this instead:
CREATE EXTENSION citext WITH SCHEMA public ;