[2884 total ]
Luke Plant: Is static type checking a redundant testing mechanism?

Based on my recent Haskell experience, I highlight some cases where I think static type checks provide a better testing mechanism than unit tests or other automated tests.

Hugo: for post in leo.blog():: Django-Jython 1.0.0 released!

for post in leo.blog():: Django-Jython 1.0.0 released! - für ein Projekt auf der Arbeit nicht unwichtig: Django-Jython hat fertig. Und mit dabei der Oracle-Client, den wir in dem Projekt auch dringend brauchen würden. Nett.

Jakub Uniejewski: Develop in Django+Python, deploy in Java.

Develop in Django+Python, deploy in Java. : django-jython includes a “war” management command so you can […] get a single mysite.war file which you can deploy in your preferred application server. This file doesn’t require anything special ... [More] installed on the target server. No Django, no Jython, no nothing.
Do I get it right? I develop using whole smoothness of Python and Pony powers of Django. And then, thanks to Jython and django-jython, I can magically generate a native Java web application for deployment on enterprise web servers? Wooow, I’m impressed. This way both developers and administrators are happy :)

More about django-jython. Currently already works with Django 1.0.x and several database backends. And more updates coming soon. Cool! [Less]

Daniel Greenfeld: Code I'll reuse

When I'm evaluating a package to use in my work or play I tend to look at five things. I think many of my on-line colleagues look at a similar list. If its missing too many of these things then odds are I'll go somewhere else for my needs or roll my ... [More] own.

Documentation
Did the author bother with a README file? How about some sphinx documentation? How complete it it? Does it get me started and give a few basic examples?

I'm okay with typos and mistakes. These happen. But I want to see

Licensing
Everyone has their own idea of what they like for licenses. I like the MIT/BSD thing. I can understand the attraction to LGPL and GPL although they aren't for me. What I can't stand and won't use are monstrosities like GPL/Commercial used by such libraries as ExtJs.

Want to make money off your software? Easy... let anyone use it and charge for support. Worked damn well for communities and companies like Python, Django, Plone, various Linux distributions (Redhat anyone?), etc...

Eggification
Is your software constructed so that it can be installed via easy_install or pip? And yes, this is a bit of mild embarrassment for me, so I'm happy enough to eggify other people's work.

Tests
Do you have tests? Even a nearly empty tests file or folder? How about a test application? If you have no tests then your package is suspect. How do I know it will work independently of your personal computer?

Code Quality
Does the code smell bad? Can it be easily extended? If its innovative but the code needs work is it on a DVCS so more people can easily contribute? [Less]

Trey Piepmeier: How to Log Something

With The Django Debug Toolbar

Somewhere in your Python code (not a template):

import logging
logging.debug(something_you_want_to_log)

With Firebug

Somewhere in your JavaScript or the Firebug ... [More] Console:

console.log(something_you_want_to_log);

That was easy.

Sources

Alex
Firebug Console API [Less]

Eric Holscher: Correct way to handle mobile browsers

At work, a lot of our sites have sweet mobile versions of our sites. The problem is how to educate people of their existence. Currently we just have little ads that show up on the site that promote the mobile site, which seems a subpar solution. So I ... [More] was tasked with doing this, and luckily, as a lot of the time with Django, most of my work was done for me.

Minidetector is a Django reusable app that allows you to know if a request is being viewed on a mobile device. It provides a middleware and a view decorator that sets a request.mobile variable to True if the request is coming from a mobile device. It's method of figuring out if a device is mobile is simple; It first checks for a special Opera Mini header, then for WAP support, then finally checks the User Agent against a list of known mobile strings.

So at work I have implemented a simple way to promote the mobile sites through redirecting, allowing for a couple of different use cases. This has lead to a problem that a lot of internet sites face, and I haven't found a good solution to the problem: how do I redirect users to a mobile site?

Obviously, you should keep the request path, so that when you go to SITE/blog/2009, you get redirected to m.SITE/blog/2009. A lot of sites actually chop off the request path, bringing you to the mobile home page!

The use case
The use case I am thinking about is a user that is using twitter, and they click on a lot of links to a site, through a mobile browser. They should be gentley introduced to the existance of the mobile site, and have the ability to always have mobile links go to the mobile site. However, they should also have the ability to say 'never show me the mobile site' as well.

Three approaches

No Redirects
I see two basic approaches to the problem. The first is that we don't automatically redirect anyone to our mobile sites. We are able to detect if they are identifying as a mobile browser, so we can show them a message about our mobile site, and let them choose.

An option could be made to allow a user to say "Always redirect me" if they enjoy usage of the mobile site. This seems to allow the user to get expected behavior, but allow them to choose to use the mobile site on their mobile device if they want. However, you run into the problem of users ignoring the message about the mobile site, or just not caring enough to click it.

Redirect once (opt in)Redirect once is the plan where you redirect the user once, and then set a cookie to never redirect them again. This allows the mobile user to get a glimpse of your mobile site the first time they visit, and can then choose to visit in the future.

You can also allow them to set a cookie to automatically redirect all of their mobile requests in the future. This allows the user to get a glimpse of the mobile site, and see if they want to use it. Then based on this experience, they can choose to visit it by default if they want.

Always redirect (opt out)The third option is to always redirect mobile browsers to the mobile site, with the ability to go back to the main site. You would have a setting that the user could set to never be redirected. This is more of a 'all mobile users will use our mobile site, unless they choose not to'. I don't know if the mobile web is quite there yet (for example, we don't have a mobile version for every page), and it might lead to user confusion.

What do you think?
I think that redirecting the user on their first visit on a mobile browser is a good idea. This introduces them to the mobile site, and by setting a cookie on that redirect, you can be sure that they won't be redirected again. Then you can have an opt in cookie, that basically says redirect me every time. This makes it do what people expect most of the time, while still allowing the choice to always be redirected.

Have you implemented mobile redirecting before on a site? How have you solves this problem? Am I missing some obvious solution that handles all these cases gracefully? [Less]

Simon Willison: Correct way to handle mobile browsers

Correct way to handle mobile browsers. If your site has an equivalent “mobile” version running on a different subdomain, how and when should you redirect mobile users to it and how should you let them opt in or opt out?

Daniel Greenfeld: Eating your own dogfood

Since way back in 2007 when I blogged about JSON and Python I've used blogspot as my blog engine. I've never been completely happy with it because it didn't easily support code coloration. Still, it worked, had great up time, and I got used to ... [More] it.

Recently though on twitter I've been getting a few dings about using python to host my blog. And since I've now captured pydanny.com and pydanny.net it makes even more sense. I toyed a few times with writing my own blog engine but while I've done it for my job, I never wanted to do it for myself.

So I've been shopping around for what I consider the best blog engine for me. I had a lot of great options thanks to a blog engine query asked in April. In the end we just extended the Pinax blog engine with a few widgets and that was good enough. Anyway, recently I started to look at those again as viable options.

However, one more option presented itself. Kevin Fricovsky's Mingus. It has everything I want in a blog, and also seems to closely follow what I would like to think I would have done in my blog. That is, to say, he fetched bits and pieces from all over the Django ecosphere and assembled them into one universal whole. Yup, I like it a lot.

So my plan is over the next week or so is to set it up on a Webfaction account and start blogging from there.

24 more posts to go! (I'm behind on days but plan to make it up with posts) [Less]

Dan Fairs: Python, Unicode and UnicodeDecodeError

In the years I've been developing in Python, Unicode seems to be the topic which causes the greatest amount of confusion amongst developers. Hopefully much of this confusion should go away in Python 3, for reasons I'll come to at the end; but until then, the UnicodeDecodeError is the bane of many developers' lives.

Low Kian Seong: When you play outside of django's ORM ... you get pain!

For one of my projects, I forgot to implement the relationship of one my models. I thought I could get away with it by writing a tag that made a query to the db upon being fed a string in the report. To my horror, this caused the report to take about ... [More] 50seconds to generate for a paltry 3000 record db! Upon tailing the logs of query.log, I found that the multitude of query to the db was causing the problem. It was basically hitting the db about 3000+ times for a single page report. That is when I found out the good thing about Django's select_related(). The problem now is, I do not have that relationship and need to build that relationship into the db. Not exactly fun with a db that is already populated with data. Led me to thinking, while Django's ORM might be great for stuff like calling data from another table, but would it also incur a performance hit everytime data is being queried. I have heard Django being used for high traffic sites but then are these high traffic sites?

I tried looking around but I could not find a satisfactory answer to this: "What if you wanted to model data for an existing MyISAM table which does not have the relationship?" It would be nice if Django provided a mechanism to recreate the relationship between MyISAM tables that is implemented at the MiddleWare. Say if I were to go the Django way now, would I have to dump out the data, re-implement the tables in a 'Django-ic' model then reimport back my data?

Currently I am feeling that in order to play in Django ORM's park. I am being forced to play by it's rules. If I opt to write my sqls raw then the ORM takes back it's ball and refuses to let me even venture into it's side of the park and I am left to recreate back a lot of the convenient functionality that was provided by the ORM layer. There doesn't seem to be a nice middle ground and that just sucks. [Less]