Category: Web Stuff

Thoughts and ideas as a developer.

Posted on

Learning Python the hard way, Day 1

A recent development at work has been a shift away from WordPress to build our websites. After giving Drupal a shot, we’re about to start a project using Django.

Since I had plans to learn Python regardless(see last year’s Cheffism Episode IV: A New Look), this was the perfect excuse to actually get started on that.

To start off, I finished Codecademy’s Python course. Which, while a decent course, only touches on the bare basics of Python programming and programming in general. A lot of time is spent teaching the “basics” like variable types, loops and functions from almost a beginner programmer standpoint.

Obviously, there’s nothing wrong with this, especially when you’ve picked Python as your first programming language. However, as someone that’s a little more experienced than that it was hardly challenging up to nearly at the end where it introduces Bitwise operators.

And so, to continue my adventures into Python, I have started what I had said I’d be doing: Learning Python the Hard Way. Which, as the introduction describes entails:

With the help of this book, you will do the incredibly simple things that all programmers do to learn a programming language:

Go through each exercise.
Type in each sample exactly.
Make it run.

One major point should be noted though, you’re not supposed to copy + paste code while doing this. And its main intent seems to be to teach by repeatedly doing. Additionally, you’re asked to write comments about each line(and thus, analyse and understand each line) and write down your mistakes as you fix them.

Now, you can call me naive, but how many mistakes can a person make while copying a block of code ad verbatim? Maybe I’m overestimating the average, or as the site puts it intended, reader, but my sheet of mistakes after today is still pretty empty.

Then again, I have only done the first 10 exercises(out of 52) and these seem to mostly cover printing strings and string manipulations through string formatters. And I’m cool with that, repetition is the best way to learn something.

Maybe, once I reach the halfway point it will all be different and I will actually start making mistakes. Maybe. We’ll see.

Posted on

Cheffism: Now with more sass

Recently I’ve been becoming more and more exposed to different development frameworks and techniques. One of them is the Sass CSS pre-processor, which has been nothing but lovely.

In an attempt to learn and use this practical tool, I’ve converted all of my theme’s CSS to work with Compass/Sass and configured Compass to minify the
CSS output. It’s also easier to change my own CSS code as well as updating the HTML5 Boilerplate code, because these are now more neatly separated in their own partials. Similarly, media queries for responsive design and print have been placed in their own partial as well.

This separation was the first step in my transition to Sass. I may have been too enthusiastic in the way I separated them, but we’ll see how it all pans out.

The next step was to try and use some of Sass’ biggest strengths: variables and mixins.

I personally feel I’ve not used variables to their maximum potential, simply because I don’t really have all that much that would be useful to turn into a variable. As such, there’s currently only four variables in my theme and they all involve colours:

$background-colour: #F7F7F7;
$base-link-colour: #333333; // Note: also used for text-selection
$base-font-colour: #444444;
$border-colour: #d2d2d2;

Perhaps I can make other colours variable based on these using the various functions available to me.

Mixins have probably had more use for me, specifically in adding the few CSS3 effects that I use, like gradients and box shadows. These mixins look like this:

// Prefixer mixin, adds browser vendor prefixes automatically
// Defaults to webkit, moz and spec
@mixin prefixer ($property, $value, $webkit: true, $moz: true, $ms: false, $o: false, $spec: true) {
    @if $webkit { -webkit-#{$property}: $value; }
    @if $moz    {    -moz-#{$property}: $value; }
    @if $ms     {     -ms-#{$property}: $value; }
    @if $o      {      -o-#{$property}: $value; }
    @if $spec   {         #{$property}: $value; }
}

// Adds CSS3 box shadow
@mixin shadow($h-shadow: 0px, $v-shadow: 0px, $blur: 15px, $colour: rgba(0,0,0,0.1)) {
    @include prefixer(box-shadow, $h-shadow $v-shadow $blur $colour);
}

// Simple linear gradient mixin with solid fallback
@mixin linear-gradient($angle: top, $from: #fff, $to: #000) {
    background: $from;
    background: linear-gradient($angle, $from, $to);
    background: -moz-linear-gradient($angle, $from, $to);
    background: -webkit-linear-gradient($angle, $from, $to);	
}

At first glance, mixins look very similar to functions in, for example, JavaScript. You can pass arguments to them(and assign default values to them) and even have access to simple so called control directives like @if, @for, @while and @each.

The first mixin is a generic “helper” that will help set browser vendor prefixes for certain CSS3 functions, so that I don’t have to myself. I had more use for this due to border-radius, but as it turns out vendor prefixes aren’t necessary for it anymore. Using a mixin for border-radius(@include border-radius(10px);) is just as much work as assigning it manually, if not more(border-radius: 10px;).

Unfortunately, this prefixer mixin won’t work for gradients, because the prefixes for that are set to the value of the background attribute. Which is unfortunate, but it will have to do.

As I get more comfortable using Sass and mixins, I’ll probably make more passes over my current CSS to see what else I can simplify. The first candidate will probably be the current selection code(::selection and ::-moz-selection both apply the same style…).

My Sass efforts can be found on Github. :)

So, Sass has been an awesome tool for me so far and I’ll no doubt keep using it. If you’re looking to get started with using Sass and don’t really know where to start, take a look at these two tutorials on TheSassWay.com and Sass-lang.com.

Posted on

Cheffism Episode IV: A new look

While having nothing to do seems nice, and it was the first month or two, watching TV all day gets boring very quickly. Especially with HBO showing The Green Lantern multiple times a day and week. So things had to be done, not only to entertain me but also to hone my skills further and keep them from rusting shut.

I’ve started reading more(Currently reading Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin, very insightful book!) and I’ve built my own WordPress theme(Which can be found on Github, feel free to “steal” or comment on it :)). I’ve opted for a minimalistic approach for this new theme, because it appeals to me most and is the easiest to read and get around.

As a starting point the theme uses the Handcrafted theme, which is a bare naked HTML5 theme. This theme uses HTML5 and the HTML5shiv to support older, less-capable browsers and seemed like a great place to start. In the process of building my theme I’ve learnt a lot more about how WordPress works(and doesn’t work, for that matter) and how to properly use some of the new tags in HTML5(Specifically article and section tags).

Features of the new look include:

A new homepage that will show my most recent post and the content of a page

The process of building the new homepage shows my limited experience with WordPress. It relies on having the static page setting enabled and having two pages(One for Home, one for the Blog). I wanted to do more with the homepage than simply showing page content, I made a page-template for it. I named this home.php. As it turns out, that was a bad idea. Little did I know, WordPress has a Template Hierarchy that basically works as follows:

If a visitor goes to your home page at http://example.com/blog/, the following happens:

WordPress first determines whether it has a static front page. If a static front page has been set, then WordPress loads that page according to the page template hierarchy.

If a static front page has not been set, then WordPress looks for a template file called home.php and uses it to generate the requested page.

If home.php is missing, WordPress looks for a file called index.php in the active theme’s directory, and uses that template to generate the page.

This basically meant that my front and blog pages were loading off the same template. Bit of a RTFM issue right there and I don’t mind admitting it.

The page template itself is pretty straightforward. It uses WP_Query('showposts=1') to retrieve the most recent post and a simple bit of code to retrieve the page content set as “front page”(Thanks to David of Limoen for showing me setup_postdata!).

$frontpage_id = get_option('page_on_front');
setup_postdata(get_page($frontpage_id)); 
the_content();

A separate blog page

The blog page is now listing all my blog posts until the beginning of time. I use a WordPress plugin called “Infinite Scroll” to automatically load the next page of posts until you reach the end. I’ve also gone ahead and used Chris Spooner’s tutorial to create CSS calendar icons for each blog post in the list. It uses CSS3 techniques like gradients, box shadows, and border radius. I’ve still got to do stuff about the comment form though, see if I can manage to make something spiffy out of those.

An archive page

As I had removed the sidebar altogether from this theme(I’ve never really had a use for it, even with the old theme), I had to make at least the option to search available. A very simple get_search_form(); and it’s done. I’ve also personalised the page somewhat and added some translations by checking the qTranslate language.

One thing I have noticed when working on this page is the inconsistency in the ways to show the post counts for each month and category. To show the post count when using wp_get_archives(); (for months), you need to set show_post_count to true. Like so: wp_get_archives( 'show_post_count=true' );

However, the same is not true when using wp_list_categories();, which uses show_count=1 to enable the post count. A minor inconvenience, but it makes me wonder why they’re different. There certainly is no reason for them to be, as far as I know anyway.

Better usable on mobile devices

This turned out to be a bit tricky. This is the first time I’ve used media queries and while the concept is simple, it ended up taking more time than anticipated. Mainly due to the fact that the browsers on my Android phone(Chrome, Firefox and Web) showed things differently from the User Agent/Device metrics overrides in the Chrome developer toolbar.

The toolbar suggests a screen resolution of 720 by 1280, and while there’s nothing wrong with that this is not the width an element(say, the body or html elements) will get when it’s set to 100%. Instead, the width will be set to 320. When overflow is not set to hidden, this will ensure that, when zoomed out, the elements that you’d like to span the full width only reach to about halfway. Not a pretty sight indeed.

I would never have figured this out were it not for the remote debugging that’s part of the Android SDK. That being said, I’ve no idea how this website runs on iPhones or tablets. I’d assume that it will work fine on iPhones at the very least, considering those set the viewport to 320 as well when using:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Tablets I’m not too sure about however…

So with that said and done, those are the highlights of my theme and some of the problems I’ve come across in developing it. Certainly a nice learning experience to keep me from getting bored. Should you spot any inconsistencies, bugs, weirdness anywhere on the site(or in the code on github) or feel I could’ve done things simpler(mostly the coding part) do let me know. :)

Next stop will likely either be learning Python using a combination of Learn Python the Hard Way, Python from Scratch, and The Django Book or dive deeper into PHP and spend some time with Zend. Because, stuff.