mrmagooey

this is a repost of older stuff from wordpress

Before taking some time off to try my hand at web design and general Python based tomfoolery I was a management consultant, and a big part of being a junior member of a management consulting firm is Microsoft Excel.

The use of Excel is endemic throughout the business world, and although being an application that shouldn’t be used for much more than simple business accounting, I’ve seen it used to create 3D smoothed surface plots, interactive maps of the world, and excel formulas so long that 80% of the screen was covered by the formula bar (in fact this was mine). What’s worse is that every celebrated concept in modern programming is nigh impossible, from the separation of data and presentation (MVC), through to just the concept of variables (no, named ranges do not count).

To program in the same fashion that Excel is operated you would need to:

1. Reduce the visible lines in your editor to 1 (you only ever get to see the logic in the cell that you are looking at),
2. Rename all of your variables, and your data elements, to the A1-style,
3. Remove any looping control structures,
4. Remove most of your newlines, and;
5. Finally wrap everything in a broad try/catch statement so that all errors fail silently (there’s nothing like swapping to a sheet full of unexpected #REF!’s at midnight before something is due).

Then you have the Excel Experience™.

When suggesting that perhaps there was a better way to do things (i.e. using an actual programming language), I was essentially told that “We don’t do programming, we do strategy“, which they didn’t seem to realise was only partially true. To create a strategy you need data on which to base that strategy, and there’s few ways to understand data that don’t involve some degree of programming, even if the formulas and business logic are hidden away behind the reassuring exterior of Excel. In my opinion, business and management need programmers, it’s just that no one has told them yet.

The Django web framework’s versatility is sometimes used for evil, and this is sometimes grounds for, in the words of The Simpsons Jasper Beardly, “… a paddlin’”.

1. Using sqlite in production. That’s a paddlin’.

This is because it is a f*cking pain to do database migrations with, as South’s ability to recover from failed migrations is hamstrung by lack of DDL support. Use Postgresql or MySQL (maybe MariaDB?).

2. Ignoring STATIC_URL and using MEDIA_URL for everything. That’s a paddlin’.

Static media is for your css/js and site wide image files. They (hopefully) don’t change too often and for the most part they get cached downstream. User Media is what gets uploaded to the site in fulfilment of some function that your site provides. It might be user profile pictures, or pdf files, or whatever file your users may be providing. Mixing the two and only using MEDIA_URL for everything provides headaches because:

• You can’t use the collectstatic command to move your files into place when updating in production (this includes getting static files from your applications). You’ll have to make your own command, or do it manually.
• Separating user files and static files will make any downstream caching easier (e.g. telling Cloudflare to cache/not cache a particular url pattern). Otherwise your user media is going to be getting cached across the interwebs.
• If you ever put a delete_file() method in place somewhere and something goes wrong, say farewell to site.css.

And symlinking around Django’s inbuilt protection - oh you best believe that’s a paddlin’.

3. Using flatpages for everything

Using flatpages for everything means:

• Much more difficult to get context onto a page (hello custom template tags).
• You can’t version control page changes, as it’s all held in your database.
• All edits need to be made via django admin… in production (unless of course you want to make local edits and perform an export/import dance).
• The 404 fallback middleware seems like a longwinded method of producing a page

I would prefer that no one uses flatpages, but can see their use in giving clients a rich text editor in the admin that also updates a page.

4. Doing major point Django upgrades without reading the changelog.

No established projects should need to “upgrade” their version of Django, and for most projects you can’t just change the major point release of your Django installation by simply running “pip install -U django”. Without changes to align with the new Django api your project will break.

5. Not upgrading for minor point releases

Whilst major points upgrades should be considered carefully before being undertaken, minor point releases should be basically be done as a matter of policy. None of the Django API will change, and potentially site threatening bugs will be addressed. Not upgrading, especially for security releases, is bad for you and your customers.

6. Starting new projects using Apache and mod_wsgi.

No longer is Apache and mod_wsgi the recommended way of deploying your project. Projects like Gunicorn and uWSGI are simpler to integrate with virtual environments and are cheaper in both memory and cpu.

7. Not using virtualenv

Virtual environments are now considered to be such an integral part of Python that they are included in the standard library . They make dependency management and multiple site deployment much easier.

8. Not using version control and/or editing the site live in production

You will make a mistake one day, your site will break and you will be unable to pinpoint what caused it. Then you will call me, and I won’t be angry, just disappointed.

Without version control it will be very difficult to get back to a working version of your site, and if this happen in production then your failure (both initial damage, and inability to fix it) will be getting broadcast to the world.

9. Other web development paddlin’s

• Loading 5 versions of jquery (all overwriting each other). You only need one version, probably in the 1.9 series.
• Loading all of bootstraps css for the single form that you use bootstrap styling on. Download the less and only compile the modules that you need.
• Table based layouts. Seriously?
• Letting Django serve your static media
• Writing blog posts when you have real work to do.

And finally: all hail The Simpsons for this meme.

By pasting the following into the Add Custom CSS box in the Advanced tab of theme customisation, you get syntax highlighting (with the details below):

.pln{color:#000}
@mediascreen{
    .str{
        color:#080
    }
    .kwd{color:#008}
    .com{color:#800}
    .typ{color:#606}
    .lit{color:#066}
    .pun,.opn,.clo{color:#660}
    .tag{color:#008}
    .atn{color:#606}
    .atv{color:#080}
    .dec,.var{color:#606}
    .fun{color:red}
}
@media print,projection{
    .str{color:#060}
    .kwd{color:#006;font-weight:bold}
    .com{color:#600;font-style:italic}
    .typ{color:#404;font-weight:bold}
    .lit{color:#044}
    .pun,.opn,.clo{color:#440}
    .tag{color:#006;font-weight:bold}
    .atn{color:#404}.atv{color:#060}
}
pre.prettyprint{padding:2px;border:1px solid #888}
ol.linenums{margin-top:0;margin-bottom:0}
li.L0,li.L1,li.L2,li.L3,li.L5,li.L6,li.L7,li.L8{list-style-type:none}
li.L1,li.L3,li.L5,li.L7,li.L9{background:#eee}
code .tag {display:inline;} /* Addition to override tumblr tag class*/
</style>
<script type="text/javascript" src="//cdnjs.cloudflare.com/ajax/libs/prettify/r224/prettify.js"></script>
<script type="text/javascript" src="//cdnjs.cloudflare.com/ajax/libs/jquery/1.9.0/jquery.min.js"></script><script>
$(function(){
prettyPrint()
})
$(function(){
$("code").addClass('prettyprint');
$("pre").addClass('prettyprint');
})
</script>

<style type="text/css">

The css is just prettify.css from google prettify, and uses cloudflares cdn for prettify.js and jquery. Tumblr loads up jquery at some point regardless, but it’s lower down and wouldn’t be available in the page when I need it to add the prettyprint class that prettify.js is looking for.

The result looks like:

#Python
import sys
print sys.version
import this

// Javascript
var random_object = {some_attribute:1};
var array = [];
array[0] = 0;
array.push(1,2,3);
alert(random_object);

Prettify is meant to be able to identify the code snippets, but I found a little poke in the right direction with the correct class helps, e.g. for Python:

<pre class="prettyprint" >
<code class="prettyprint lang-py" >
... Code Here ...
</code >
</pre >

And all of the supported languages are outlined on the prettify Google Code site.

In emacs/24.2/lisp/shell.el.gz around line 542 add ((string-equal shell "zsh") "~/.zsh_history") so that that part of the function looks like:

...
(or (getenv "HISTFILE")
(cond ((string-equal shell "bash") "~/.bash_history")
((string-equal shell "ksh") "~/.sh_history")
((string-equal shell "zsh") "~/.zsh_history") ;; new
(t "~/.history"))))
....

M-x eval-last-sexp the entire expression for shell-mode, to make it apply for the current session, and then M-x byte-compile-file the file afterwards for emacs to pick it up on startup.

Then you can deal with the enormous .zsh_history file, emacs slow parsing of said file, and the emacs inability to deal with the numbered ids attached to every line in .zsh_history. But M-r will be looking through .zsh_history.