Code Thinking

Sometimes it's hard to tell someone's knowledge level just from a GitHub account—especially if the code is on private client accounts.

So I wrote a list of my experiences, opinions, and insights about front end, wordpress, python, django, and general development that will give you a better idea of my abilities.

Front End Stuff

Responsive Design

Media queries are wonderful—and a mega pain if you don't control them. Most sites will have a giant chunk of CSS for the "desktop", then another giant chunk of media queries. I don't roll that way. I add media query CSS per section or item. Media queries for site navigation immediately follows the main navigation styles. Each media query is rarely longer than 20 lines.

.navigation {
    …
}
@media screen and (max-width: 749px){
    .navigation {
        …
    }
}

.some_other_stuff {
    …
}
                        

CSS Preprocessors: Maintenace

CSS preprocessors can create challenges for long-term site maintenance in teams. Compiling works great when there's a local copy, but is more of a pain on a development server (needing SSH and some sort of compiler available). Setting up a local clone of a site is a pain too. Sure, this is all avoidable with good team communication, good dev server setup, etc. But smaller projects or client hosted projects can suffer.

CSS Preprocessors: Responsive

Although I love preprocessors, writing media queries can be a pain. Nesting makes perfect sense when writing out the main style – that's what processors are for. But recalling the levels of nesting for the media queries can be a pain. Imagine we just want to change the h3 subtitle. Then we have to include the entire parent structure. Certainly fewer levels of nesting and writing clean CSS help, but that's just not always possible depending on the design.

.post {
    …
    .title {
        …
        h2 {…}
        h3 {…}
    }
}
@media screen and (max-width: 800px){
    .post {
        .title {
            h3 {…}
        }
    }
}
                        

Wordpress

Real CMS management tools?

On the list of things that most frustrate me about Wordpress is that there aren't any native admin tools for creating/maintaining custom post types and custom fields (okay custom fields technically, but nothing clean like Advanced Custom Fields).

Advanced Custom Fields Pro plugin has really nailed the custom fields thing about as well as possible within Wordpress. But it's a 3rd party plugin. I've heard people say that not everyone needs custom fields, and that's true, but I be more people need custom fields than need a multi-site installation.

Categories are not Content Types

May Wordpress developers use post categories to separate out posts in different part of the site. Imagine a site has the pages News, Jobs, and Team Members. News will show posts in the "news" category, Jobs will show posts in the "jobs" category, and Team Members will show posts from the "team" category.

But that places the content management burden on the user to remember to pick the right category.

Instead, I create custom post types for Jobs and Team Members. Each will have it's own admin section. Choosing "Add New" from the Team Members menu makes sense to clients. Remembering to check "Team Members" in the lower right corner does not.

Python

List Comprehensions

Love list comprehensions in Python! So powerful, so concise, so pythonic. They're like poetry. My favorite is when I get to use an if/else AND a conditional. Imagine a contrived example where we need a list of rock album titles before 1980, and a value of False for other genres.

albums = [
    {'title': 'Chic', 'year': 1977, 'genre': 'disco'},
    {'title': 'Cheap Trick', 'year': 1977, 'genre': 'rock'},
    {'title': 'The Wall', 'year': 1979, 'genre': 'rock'},
    {'title': 'Confrontation', 'year': 1983, 'genre': 'reggae'},
    {'title': 'Pyromania', 'year': 1983, 'genre': 'rock'},
]
titles = [a['title'] if a['genre'] == 'rock' else False for a in albums if a['year'] < 1980]
print(titles)

>>> [False, 'Cheap Trick', 'The Wall']

                        

Pandas

Is a dataframe an Excel sheet? Is it a database? Is it both? Either way, pandas is just beautiful.

Fabric

Once you get used to having Fabric in your tool set, it's mega frustrating to go with out it. I use fabric to work with git, deploy local to dev environments, and deploy staging to live environments. One of the best implementations I've done is to programatically convert a custom MySQL-based CSM database to Wordpress using Fabric and Wordpress Command Line Interface. I also have my own WPCLI fabfile.py that will launch a clean local Wordpress development environment in about 1min.

Django

Function-based Views vs. Class-based Views

I prefer function-based views. Both have their strengths and weaknesses. I really love CBV in theory, but I've found in practice that I always seem to need to override enough view methods that the FBV approach would have been cleaner. I've also found it easyier for new team members to get up to speed on FBV, probably because of their procedural nature.

That said, FBV have plenty of their own issues. They're hard to keep D.R.Y. and need more boilerplate to work with. Also can be hard to reuse outside of keeping a snippet library (which I do).

In general, however, I mitigate any issues with FBV by pushing more logic and burden onto models and managers (fat models for the win!) . It reduces code repetition, simplifies views, makes them easier to follow for other team members, and models are easier to test.

General

D.R.Y.

Any time in need to resuse something, it either becomes a function or separate template file. Editing the same thing in multiple places is a major pain, and you'll always miss one of those extra places.

This is one of my biggest frustrations with Worpdress templates, which by their nature seem to require vast amounts of repeating/copying.