My website has recently come full circle back to Wordpress. It’s been a number of years since I’ve used Wordpress. The last time was probably in college on the cheapest shared host I could find. I avoided coming back to Wordpress because I didn’t want to maintain a server; I fiddle enough with them at work. Already being a Digital Ocean customer, the 1-Click setup/hardened server seemed like the best way to go. 

I quickly got it configured with all of the IndieWeb plugins to facilitate back-feeding content that I create on other platforms onto my website. The final step starting to use MarsEdit, my old favorite blog editor. Except it couldn’t connect to my website.

Turns out the reason is that the majority of Wordpress security issues stem from bots abusing the xmlrpc api and the digital ocean install blocks it at a low level by default. Disabling this block on the server allows programs to use the xmlrpc api and hence MarsEdit to work. Execute the following commands to disable the xmlrpc block.

sudo a2disconf block-xmlrpc
sudo systemctl reload apache2

Back when Macs came with modems built in, the one feature that I thought was super cool but never used was the Print to Remote Fax feature. It was one of those features like "Duh, of course. We can create PDFs. Naturally we can send them over the modem for printing."

The PDF file format is a ubiquitous file format and the only real way to guarantee document layout and display, no matter the device or operating system used to view it . Python, being a language that excels at data processing and manipulation, naturally has a lot of tools for working with PDF files to generate reports. This post is a brief introduction to the tools that are available and the tasks they work best for.

Wand

Its API is quite Pythonic and can help you split, convert, and even draw on PDF files. Wand is perfect for manipulating existing PDFs and doing light editing on them.

ReportLab

PikePDF

PikePDF also lets you explore the internal structure of a PDF document, which make it a perfect tool for debugging problem PDFs and extracting content/images.

The APIs are very Pythonic, and let you work with manipulate pages / page order like a regular list. PikePDF is also great for repairing and prepping PDF to be manipulated by Wand.

Pillow

While there's some overlap of functionality Wand in terms of image editing capabilities, it's more focused on editing images, rather than transforming and converting images. Pillow is an indispensable tool when working with any user-supplied images in your PDF workflow.

Conclusion

There is no single PDF tool in Python that fits all needs, all the time. These libraries can, and are, often used in conjunction with one another to quickly and easily generate PDFs on demand. However, depending on how you combine them, there can be some issues resulting in large file sizes and slow generation times. I'll cover these gotchas in future posts.

On a project at work I've been learning GraphQL. I'm in charge of both developing the backend ( using the wonderful graphene-django package) and the frontend ( using Typescript / Vue.js / axios ) for this specific feature.

After wrapping my head around GraphQL and getting a basic endpoint working I wanted to write some tests to ensure that filtering and other requirements are working as expected.

For a proper End-to-end test I'd usually setup a client and post a json dictionary or such. With End-to-end GraphQL tests you need to send actual GraphQL queries, which makes sense but it feels a bit like SQL Injection.

Below is how I've settled organizing and writing my GraphQL tests.

tests/
├── __init__.py
├── conftest.py
├── test_myapp/
│   └── test_schema.py

Because the graphql client will be reused across the django site, I added a global fixture that will automatically load mty project's schema.

# tests/conftest.py
@pytest.fixture
def graphql_client():
from myproject.schema import schema
from graphene.test import Client
return Client(schema)

In this example I'm testing that I'm filtering data as expected when passing a search parameter.

For setup, first I write a query as its own fixture so I can re-use it throughout the test and it's clear exactly what is going to be run. Second, I make sure the query uses variables instead of hard-coded values when querying so I can change the input depending on the test. Third, setup a model_bakery fixture for data that I expect to find.

import pytest
from model_bakery import baker

@pytest.mark.django_db
class TestMyModelData:
@pytest.fixture
def query(self):
return """
query testGetMyModel($searchParam: String!){
myModelData(searchParam: $searchParam) {
totalCount
}
}"""

@pytest.fixture
def my_model(self):
baker.make(
"myapp.MyModel",
total_count="20", # Decimal field
)

def test_none_response(self, graphql_client, query, my_model):
executed = graphql_client.execute(query, variables={"searchParam": "skittles"})
assert executed == {"data": {"myModelData": None}}

def test_filters_usage(self, graphql_client, query, my_model):
params = {"searchParam": "skittles"}
executed = graphql_client.execute(query, variables=params)
assert executed == {
"data": {
"myModelData": {
"totalCount": 20
}
}
}

Executing each test I simply pass my query and required variables for the test/query. In this I'm testing the same query twice: once with and one without a searchParameter. My expectation is that I get no results without a search term and data when to my graphql_client fixture.

As the return value from our client is a dictionary, I can simply assert my expecte results with the actual results. If something changes I'll know immediately.

Using the techniques above I can easily add new tests for my GraphQL endpoint as the available changes or bugs are found.

The Slow Web

• The slow web is formulating your thoughts and expressing them fully. 
• The slow web is about owning what you produce.
• The slow web is open.
• The slow web is yours.

The Slow Web in Practice

Sharing

• Writing unique content that matters to you and like-minded people will find it via search
• RSS Feeds (standard in most all blogging systems)
• POSSE (Publish (on your) Own Site, Syndicate Elsewhere

Ignore the Numbers

Privacy

Don't Over Engineer

Making the Jump

When testing in Django there's two basic ways to make an End-to-End test for your view: use the test client to send a request to the server or create a fake request object and manually call your view function.

One isn't "better" than the other, but I've come to prefer using the mock client over the fake request for the following reasons:

1. Client tests hit the entire stack of code before executing your view allowing you to catch any conflicts with a middleware or settings and your view.


2. Url Path tests come for free. When testing with fake request objects you can put any path you'd like in there and it will execute missing that bad merge where your url config change removing an endpoint.


3. It's (slightly) easier to reason about. If I'm writing a test to confirm X happens when Y is posted I make Y and post it rather than making an object that pretends Y was posted.


4. It removes the friction to refactor your views. As long as the url stays the same, you can rename and move your view however you'd like without changing any of the tests. This makes it easier to create a more consistent codebase e.g. some views use the verb "save" while others use "register".

def test_get_workflow(self):
    # Make sure that anonymous users are redirected to login
    # and that users are denied access to data that's not theirs
    self.redirect_for_anon_get()
    self.not_found_for_wrong_account() 
    # Check that our filter interface is filtering data properly so
    # calls to "mine" only show tasks assigned to me and so forth.
    self.filters_response(self.sub_task_data['title'], 'all', [])
    self.filters_response(self.my_task_data['title'], 'mine',
        [self.sub_task_data['title'],
        self.completed_task_data['title']]
    )
    self.filters_response(self.completed_task_data['title'],
        'complete',
        [self.sub_task_data['title'],
        self.my_task_data['title']]
    )

def test_post_workflow(self):
    # Make sure that all post requests are redirect
    # or return 405 and denied
    self.redirect_for_anon_post()
    self.post_not_allowed()

 Less code = Fewer places for bugs = Less maintenance