Web.py and PyInstaller: issues with HTTPS on 32-bit Windows machines

I recently had a project where I had to bundle a Windows app, written in Python 2.7. I chose to use PyInstaller 3.2, since it was being used for other parts of our project as well.

The app had to be light-weight and compatible with older, 32-bit Windows machines, since it was going to be deployed on 10+ year old hardware in rural areas (running 32-bit Windows XP). The app basically provided a local, RESTful assessment engine, allowing students to interactively answer various types of questions (Multiple Choice, Fill-in-the-Blank, etc.) using the open source Open Embedded Assessments tool. To make it as light-weight as possible, I had decided to use the Web.py server.

While the app bundled fine on a 64-bit Windows 10 VM, I kept running into an error on a 32-bit Windows 10 VM:

    You must install pyOpenSSL to use HTTPS.

The app ran fine from the command prompt, and using a Python shell, I could import OpenSSL manually, so I was stumped. I finally dug into the PyInstaller warnings file and realized that Web.py was masking a common issue with _cffi_backend not being declared as a hidden import. Adding that to my spec file solved it, and I could cleanly build my app in 32-bit Windows.

I’m not entirely sure why the same spec file (without the _cffi_backend hidden import) worked fine in 64-bits, but that’s another mystery for another day.

React Native Flexbox confusion with custom components

For our Fly-by-Wire project, I’ve been learning and using React Native to build mobile applications. When trying to do a sidebar layout for a tablet view using nested custom components, I got stuck with Flexbox — no matter what I did, the flex option didn’t seem to have any effect in making my sidebar only take up a portion of the screen. You can see an example here.

I thought that ReactNative wrapped each component in an extra View or something (like how React wraps everything in a div). So I thought the components would render something like:


   
    
  
  
    
  

As you can probably guess, that is not how it works. The styles on the custom components’ (Sidebar and MainContent) View elements overrode anything I set on the custom components themselves (the sidebar and content classes). I was not expecting that, and I couldn’t find it clearly explained in the documentation. What I really wanted was something like this. Which would render (per my example above) as:


  
  

My lesson learned — with React Native, styles go on the “lowest” component in the tree, something to watch out for with nested custom components.

 

The Value of Models

It’s amazing how simple architectural decisions at the start of a software project can kill its long-term potential. One example we run into all the time is with learning outcomes and tagging content — simple enough, right?

Most learning platforms treat learning outcomes as simple text tags — let your instructors tag content with learning outcomes, so students know what they are expected to learn. Good pedagogy. And it’s a simple enough feature to implement, so it’s considered low-hanging fruit.

However, when you want to experiment with things like pathways and relationships between the outcomes, or adaptive assessments based on your knowledge, you run into trouble. Big trouble. You can’t easily link text tags once they are in your system…you could probably come up with complex database queries to get the results you want, but that early decision to model the outcomes as text tags now forces you to jump through hoops to do anything more complex and interesting.

Ideally, from the start you treat learning outcomes as their own entities, with their own relationships to each other and to content. So the initial complexity and planning pays off in the long-term, with less refactoring and more powerful models.

And yes, I am partially tooting my own horn. My group has been working on these types of models for the education domain, though way before my time. As outcomes-based learning becomes more prevalent, it’s amazing to see how the early work on OSIDs (from ~15 years ago) seems almost prescient. Check out EDUCAUSE’s vision for next generation learning platforms, and you can see the parallels.