Bereits im November 2020 berichtete u.a. die Westfalenpost über unseren Absolventen David Kliment, der große Sportdatensätze mit Hilfe von Machine Learning Algorithmen in seiner Bachelorarbeit untersuchte. Auch eine Form von Business Intelligence, jedenfalls wenn man der FC Barcelona oder ein anderer Verein mit Bedarf an Entscheidungsunterstützung ist :-).
Die Westfalen Post berichtet in der Ausgabe vom 03.11.2020 über unseren Absolventen David Kliment.
Hr. Kliment hat in seiner Bachelorarbeit Spieldaten des FC Barcelona mit Hilfe von Verfahren des Maschinellen Lernens untersucht. Die Ergebnisse haben teilweise auch ihn überrascht: Verteidiger Dani Alves weist ein ebenso außergewöhnliches Spielverhalten auf wie z. B. Messi oder Neymar.
Foto-Shooting bei TBW: Dicht getaktet wurde am Montag das Fotomaterial für die neuen Webseiten der FH aufgenommen. Innerhalb weniger Tage wurden alle Standorte und Fachbereiche durchlaufen, um Räumlichkeiten, Labore und Ausstattung ins richtige Licht zu rücken.
Wer sich den Webauftritt der FH heute anschaut, merkt schnell, dass die darunter liegende Technik in die Jahre gekommen ist. Insbesondere die Nutzung mit Smartphone oder Tablet funktioniert nur begrenzt gut. Mittlerweile kommt aber mehr als 50% aller Aufrufe über Mobilgeräte und nicht mehr über Desktop-PCs. Die „User Experience“ (das Benutzungserlebnis) und auch die „Usability“ (die Gebrauchtauglichkeit) könnten besser sein. Zeit etwas zu tun.
Wer mehr über User Experience und Usability erfahren möchte, ist im kommenden Wintersemester in meinem Modul „Mensch-Computer-Interaktion“ genau richtig :-).
In einer aktuellen Pressemitteilung berichtet unser Turbostudent Philipp Dirks, wie er seinen Bachelor in Wirtschaftsinformatik in nur sechs Semestern absolviert hat. Dabei war er noch ein Semester im Ausland und Spaß hat’s auch noch gemacht.
Herzlichen Glückwunsch zum Abschluss „mit Auszeichnung“!
Die Entwicklung von Apps für die HoloLens erfordert ein umfangreiches Toolset, angefangen bei der Spieleentwicklungsumgebung Unity über Microsofts Visual Studio bis hin zu verschiedenen Add-Ons. Aber es geht auch einfacher: Mit der Cloud-Entwicklungsplattform Buildwagon können Holo-Apps ohne jede zusätzliche Software im Browser mit JavaScript entwickelt werden. In einem aktuellen Artikel in der Zeitschrift iX berichten wir über unsere Erfahrungen mit Buildwagon (siehe Publikationen).
Aktuelle iX mit Beitrag von J. Strunk und Prof. Leubner zum Entwickeln von Holo-Apps
Für unsere Studierenden bieten wir im Rahmen des Moduls „Sondergebiete Informatik“ einen Programmierkurs für Holo-Apps mit Buildwagon an (z. B. im Sommersemester 2021).
Auch in Corona-Zeiten bleiben wir am Ball: der Fachbereich TBW freut sich über eine neue Microsoft HoloLens 2 als Ergänzung zur aktuellen Laborausstattung. Nach mehrmonatigen Lieferzeiten ist sie endlich eingetroffen. Hier ein paar Fotos vom Unboxing.
Die Hochschule berichtet in einer aktuellen Pressemitteilung über das erfolgreich angelaufene Projekt zur Programmierung einer Drohne für die Instandhaltung.
Django and Python can cause quite a headache in Windows environments. However, sometimes you have no choice and Windows is the OS that has to be used. It took me several hours, spent at googling, reading and testing until I got a configuration that worked in my setup. So, for anyone else in a similar situation I’d like to summarize my experiences.
The built-in web server in Django is really nice for developing and testing. However, it shouldn’t be used for a production setup. While there are a lot of tools for this purpose (e. g. uWSGI, Gunicorn), many of them are not available for Windows. The most appealing solution is most probably the usage of Docker which also works on Windows Server 2019. However, Docker requires Hyper-V for virtualization and since my Windows system is a VM itself, it depends on the configuration of the VM host whether Hyper-V is made available to the guest VMs or not.
An alternative that is most likely to work is Apache. All you have to do is to integrate your Apache installation with the Python/Django application. For all of the above mentioned solutions (and also for Apache) Django comes with a WSGI interface that bridges the web server to a Python application. On the Apache side you need a specific module, the „mod_wsgi“ module, that accomplishes the task. Unfortunately, this module is not shipped with a standard Apache distribution.
Basic setup
My setup is:
Windows Server 2019 Desktop (VM)
Python 3.8.1 64 bit
Apache 2.4.41 64 bit
PyCharm 2019.3.3
First of all, it seems to be important to have anything either 64 bits or 32 bits. Never mix it up!
I took the standard Python distribution which can be downloaded here. I installed Python as Administrator, added to PATH and installed it for „all users“. Use the „custom install“ and verify that the respective checkboxes are marked.
The Apache distribution may cause problems in combination with the other tools involved, so I downloaded it from Apachelounge. Extract it to „c:\apache24“, which seems to be the standard path that works out of the box for the other tools. I installed (that means copying from the archive) with my normal user account.
My pain points
First of all, I created a new Django project with PyCharm with its nice wizard. PyCharm supports three virtual environment managers, namely „virtualenv“, „pipenv“ and „conda“. For Django projects the Conda package manager is not recommended (don’t remember where I read it), „pipenv“ seems to cause trouble in combination for building the „mod_wsgi“ described later. So, there is only „virtualenv“ left. Something I learned at this point is that the current „virtualenv“ that is part of Python is actually „venv“. The real „virtualenv“ is a third-party package manager that has to be installed additionally. Moreover, for building „mod_wsgi“ it is recommended to use the third-party „virtualenv“ and not the built-in „venv“. However, when using PyCharm you have no choice, but to stick to the built-in „venv“.
PyCharm terminal issue
Setting up a new virtual environment with an empty Django project in PyCharm is a quick win. I had some issues when using the „terminal“ tab at the bottom of PyCharm because the virtualenv package information was different than the one I saw in project settings. There are some threads on the Jetbrains issue tracker concerning this problem. For the next steps it is safer to open a new command line shell, activate the virtualenv in this shell and to do the next steps in there. Double-check the actual virtual environment you are in.
Having read lots of hints it seems to be important to have the latest versions of (currently):
pip 20.0.2
setuptools 45.2.0
Moreover, virtualenv (the third-party one) is recommended, but I also succeeded with the build-in venv.
Building mod_wsgi
As mentioned above you need the „mod_wsgi“ for Apache in order to bridge the Apache web server with your Django application. Since this approach is several years old, you have to pay attention on the publishing date of articles and posts when googling this topic. For example, you could download the module pre-built for your platform, but lots of things may go wrong this way, leaving you with a non-working solution. Moreover, a lot of scenarios I found on the web concerning „mod_wsgi“, which promise to be very simple, are not applicable for Windows. So, my summary is that the best way is to build „mod_wsgi“ yourself, which is also recommended on the official webpage.
Fortunately, the build process is not difficult at all. You simply use „pip“ in your virtual environment:
pip install mod_wsgi
https://pypi.org/project/mod-wsgi/
Out of the box this approach won’t work because you need the respective toolset from Microsoft for the build process which can be found here. You actually only need the „build tools“, not Visual Studio. Scrolling down the page, you’ll find them in the „Tools for Visual Studio“ section. Maybe this direct download link works for you. Installing the „build tools“ you only need (presumably)
MSVC v142 – VS2019 C++ x64/x86-Buildtools
Windows 10 SDK
Having the build tools installed, you should give the „pip install mod_wsgi“ in your virtual environment a try. For me, it did not work :
Obviously, the build process does not find the Python libraries which are not part of the virtual environment where they seem to be expected. The issue seems to be quite new and could be solved for a while by using the third-party virtualenv. In this post the solution is to use the following pip-command instead:
That worked for me and I finally got „mod_wsgi“ built and ready to use. I suppose that this issue may be fixed in future releases. You can check the result out with the command:
mod_wsgi-express module-config
You’ll get an output like this:
You will need this output later on. There’s a lot more you could do with „mod_wsgi-express“. However, nothing else seems to work on Windows. On Unix systems for example you could use „mod_wsgi-express“ to spin up an own web server.
Apache trouble
Next step is to put the newly created „mod_wsgi“ module in your Apache installation. As mentioned before, you should only use the Apachelounge distribution and install/copy the files in „c:\apache24“. I also added the Apache-bin directory to the system path „c:\apache24\bin“, but I’m not sure whether that is of any use. I installed Apache as a Windows service with
httpd.exe -k install
In my setup I maintained the Apache settings in the „httpd.conf“ (in the „apache24\conf“ directory) and in the „httpd-vhosts.conf“ (in the „apache24\conf\extra“ directory). My vhosts contains the following:
Based on the guidelines you should copy the output you receive from the „mod_wsgi-express module-config“ (see above) into the „httpd.conf“ file. Having googled lots of web pages I often found a „LoadFile“ directive, which is missing in my output (does not seem to matter).
I inserted the output in my „httpd.conf“ and tried to restart the Apache service using the „Services“ dialog (start as Administrator), but failed. The Apache service could not be started and threw an error message. I tried lots of things and finally ended up with this working solution:
Deactivate (delete/comment) the „WSGIPythonHome“ in „httpd.conf“. I succeeded with just the „LoadModule wsgi_module“ directive (copy/paste from mod_wsgi-express)
Remove any „WSGIPythonPath“ directives
Added a PYTHONPATH to the system-wide environment variables for the virtual environment site-package path, the Django project directory and the Django app directory (where the „wsgi.py“ is located):
For me it’s still a mystery why the „WSGIPythonHome“ and the „WSGIPythonPath“ directives haven’t worked or which values would have been correct to fill in. Obviously they made Apache crash on startup.
I’d like to emphasize that I didn’t change the standard „wsgi.py“ generated by Django. I’ve seen quite a lot of solutions modifying this file with the goal to activate the virtual environment from within the „wsgi.py“. That does not work in the built-in virtualenv because the „activate_this.py“ script is not available. Moreover, it is not necessary in this configuration because the „mod_wsgi“ already belongs to the virtual environment.
Finally with Apache and the PYTHONPATH defined, my Django installation is accessible via Apache:
