After a whirlwind week of HTML, CSS, and Flask, I know roughly how to make web pages talk to each other. Woohoo! Definitely still have a lot to learn, though. I also hit some areas of programming that I just don’t grok intuitively, and grappling with them has been…interesting.

I’m a logical person. I like simplifying logic equations with De Morgan’s theorem and then building little systems to represent them with logic gates. I used to do those gridded logic puzzles on paper for fun, and I’m one of those weirdos who gets excited about stepping through programs with debuggers.

But I’m also a creative person. I love writing, doodling, cross-stitching, watercolor painting, photography, and costuming. One of my favorite programming tools is Processing because I can use it to code art. I’ll take any excuse to combine crafting with LEDs, and I once made a color-changing scarf.

So, I thought I’d fall madly in love with front-end development for some reason. It’s artistic and logical, right?

Apparently I’m not as wired for design as I thought I might be, or maybe web design, in particular, isn’t the right kind of logical for me. While I can envision a pipeline of information going from one program to another to put words on a screen, I often cannot picture exactly how something I do in HTML or CSS will affect what those words look like. Sure, there’s a div that this text is theoretically going to sit in, but don’t ask me where that div sits on the page.

Maybe it’s a matter of practice? Once I get into a good workflow and get a skeletal page put together, making the page pretty gets easier, but it just doesn’t flow yet. I’ll have to keep trying. Perhaps I’ll fiddle with my Liquid templates.

Meanwhile, there are several areas of web development that I’m much more excited about.

Interfacing Components

Things got real at Hackbright when we started tinkering with a web framework called Flask. With Flask, you can use Python to make web pages talk to each other, and that feels amazing. For part of our homework this weekend, we built the bare beginnings of a simple web application, complete with form fields.

Here’s what a route to an HTML page on a website might look like in Flask:

@app.route("/")
def index_page():
    """Shows an index page."""

    return render_template("index.html")

The first line is called a decorator, which defines a route; in this case, / is the route being defined. The decorator syntax is a really cool part of Python; if I’ve understood correctly, a decorator is actually sort of wrapper that changes the behavior of another function without modifying the function itself, which allows you to generate new functions. (Yo dawg, I heard you like functions…) The function after the decorator defines what should happen when someone accesses that route, say by clicking a hyperlink or submitting a form. Anyone accessing / will be served the page written in index.html.

I find thinking about how best to link up pages on a website really fascinating, and debugging the connections can be a great puzzle to work through. (Debugging routes can also be frustrating–very frustrating. Working with Flask has reminded me of the value in just walking away for a little while.)

Templating All the Things

We’ve also been learning how to generate HTML pages with Jinja, a Python templating engine that you can interface with Flask. The idea is that you can create a base template (or multiple bases, if you like) with placeholders that Jinja understands, and other pages on your site can inherit the characteristics of the base template. Then, when you render pages in Flask, Jinja will fill in the blanks! Plus, if you link up your CSS stylesheet inside your base template, the styles will be automatically applied to all pages that inherit from the base. SO. COOL.

A simple base.html file might look like this:

(Liquid really wanted to read these Jinja blocks so I had to screenshot the code. If you like the colors I have going on here, check out the Fairyfloss Sublime Text theme by the amazing @sailorhg!)

The blocks do what they say on the tin. the body block is a placeholder for the <body> section of an HTML page, the title block is a placeholder for any <title> you might want to fill in, and so on. Jinja can also handle loops and if statements, and this code uses both to display any flash messages generated by the page previously visited.

With this base file, you could make an HTML file like this one that extends it:

Isn’t that lovely? It’s so much cleaner than cluttering your files with all the usual HTML tags, and it’s way more readable. Being able to supply content for those variables also lets you do really fun things, like templatizing (is that a word?) bulleted lists or tables as shown above. Just create a list of data in your Flask script, pass the list to Jinja when you render the template, and boom, you can throw down a ten-line table in half the HTML. Plus, you’ll never have to worry about adding extra lines manually.

Automation == <3

Testing, Debugging, and Documenting

I know, I know, I’ve said it before. I’m into documentation, and testing with docstrings is awesome. We also learned about unit, integration, and functional testing in Python this week, though, and I just have to say, I’m looking forward to writing tests for my big project once I get started. I’m still not sure how I feel about the idea of test-driven development (I’ll have to try it at some point), but I see merit and sense in knowing how to write good tests. I’ll have to start using unittest on my homework or maybe cook up a personal project to get some experience.

Debugging Jinja/Flask code is a new and interesting experience, too, because you’re dealing with sets of data in a different formats. You have to make sure you’re passing Jinja data in a form it can use, so print statements are often extra helpful in Flask code. Just print data as you process it, and you’ll be able to track the variables you’re trying to pass to Jinja much more easily.

Flask’s debug toolbar is also quite helpful, and the Inspect tool in browser developer toolkits is all kinds of awesome. Yay, tools!

Knowing How and Why Systems Work

Ultimately, what I realized while I was thinking about everything I enjoyed about this week is that my favorite part of computer engineering is still knowing the how and the why of a system I’m creating or maintaining. I need to know why a system should work the way it does to begin to understand it. I like to know how pages communicate, and there’s no better way to know that than by routing the connections yourself. It’s also very satisfying to look at a block of text on a page and know exactly how certain pieces of it got from the user’s input to being displayed in the browser. One of our assignments this week taught us roughly how a shopping cart might work, using sessions, and it totally blew my mind.

I don’t need to be the one making pages pretty, though. Give me your gorgeous pages, tell me what data you want to display on them, and I’ll be happy to (try to) make them into a running web application.

Quotes of the Post:

(On programming, generally): “When you want to write a program, the last thing you should do is touch your keyboard. Plan first.”

(On Flask/Jinja): “Try to think backward from what your template needs.”

–Ahmad