Finishing up on our previous episode on search engine optimization, this time we discuss specific things that you can do as a developer building a website to improve your rankings and discoverability.
Continue readingMost developers are aware of the term “Search Engine Optimization”, and like me, have a vague understanding of what it actually means. For a long time I thought that this was more about the content of a website than how that site was created or built. In other words, I saw it as an issue for the folks over in the marketing or sales organizations, certainly not for us engineers to worry about.
It turns out that the design and architecture of the technologies implementing a website have a large impact in it’s discoverability. I didn’t understand this until about a year or two ago when I needed to perform some optimizations for tryexceptpass.
I met up with Michael Kennedy from the Talk Python To Me podcast, and together we recorded our musings about SEO and present them to you in this two-part series.
Continue readingI spend most of my day, every day, knee deep in code. Optimizing, building, fixing and thinking through workflows can be taxing. This means that the last thing I want to do when I come home is deal with more programming. But I also like learning new things and communicating my experiences so they can help others. I do that through the posts in this website.
Maintaining a web presence without dealing with code means you get to use as many off-the-shelf components as possible. You consider things like WordPress or static site generators that let you concentrate on content, while handling the user interface for you. Write in markdown, build the website, rinse repeat with updates. It’s all very easy, until you need a little more interactivity, like a comments section, or a newsletter signup.
Continue readingIf you aren’t aware of my earlier posts, check out Part 1 and Part 2 of this series so that you get some context for this ongoing exercise.
Since I started thinking about and working on these posts, I’ve also been developing the ideas on GitHub as a side project I called sofi.
Sofi is a Python 3 package that serves as the starter implementation of the design discussed in Part 2: a system that will generate the necessary HTML and JavaScript code typically needed to produce a single-page application and serve it up through WebSockets (not an HTTP server).
Continue readingIn the first part of this series, we discussed a few existing modules that give us tools for building interfaces. I promised to come back with some ideas on how I would attempt to solve the situation, and this post is intended to cover aspects of my initial design.
However, first I need to discuss one more point on existing modules. In case you’re not aware, PyCon 2016 happened a few wks ago in Portland, and amongst the many wonderful talks, keynotes and open spaces, there was one in particular that is relevant to the topic of our discussion here: Russell Keith Magee’s talk on BeeWare and the work he’s done to solve the same problem. I highly recommend you take a look and help out with his projects if you can. It’s definitely a bold and brave solution that’s highly complex, but he already has it at a usable state and deserves massive props for going down that path. The Podcast.__init__ guys also have a great interview with him going over the details.
Continue readingStaring at my coworkers, already knowing the inevitability of the situation, my eyes roll as the argument starts anew:
“I told you I can write that code twice as fast, in half as many lines and they’ll be cleaner and more readable than yours will ever be! Python is awesome!” — said the one guy.
“Whatever you say, you’ll never be able to make a UI that’s half as good as this. It won’t look pretty and no one will want to use it!” — replied the other — “Probably can’t even make it run on Windows” — he mumbled to himself while walking away.
Some years ago this was a regular exchange between coworkers, and while they were mostly messing around, there was still an element of truth to it. Regardless of its capabilities, Python was mostly known as a “scripting” language — not really for graphical interfaces — and the world was still looking for a native OS feel in their GUI applications, which was not really accessible from Python without a lot of work.
Continue reading
