Luxembourg, legitimacy, longevity#
Luxembourg City#
Over the past weekend, we all got to explore the wonderful city of Luxembourg! It started with a guided walking tour through the windy city streets and impressive ramparts. We learned that Luxembourg was once a powerful fortress, with only a fraction of its remains still conveying a strong presence. Since Luxembourg borders Belgium, France, and Germany, it was a powerful position to control. Inside the city, the food was amazing, and since Luxembourg is mostly green space, there were lots of grassy overlooks to enjoy in this city. This city taught me that you can have a balance between power and peace, fortresses and fields, as well as being committed to continuous improvement, the fortress was built upon and broken down at least seven times!
Legitimacy#
One talk that really stood out to me was our discussion with Pierre Dewitte, Researcher, KU Leuven Centre for IT and IP (CiTiP). Dr. Dewitte was incredibly engaging and concrete case studies to teach us about the intersection of law and data. Something I have always wondered is how do politicians pick the specific language they use in legislation, it feels incredibly ambiguious and incredibly specific at the same time. Dr. Dewitte had an insightful answer, explaining that all law is a compromise, and it takes lots of long hours and many tracked versions of legislation before lawmakers agree on a “solution.” And often to make sense of the meaning of final legislation, lawyers will have to parse through all the versions committed by different legislators. Versions, committed, politicians are basically legal coders! This idea shocked me deeply, I didn’t think politicians, such a legacy and non-technical community, could share processes with computer scientists. This insight helped me to better connect with lawmakers and approach the idea of finding common ground in a new light.
Longevity - The Project#
Over the course of this week we were tasked with translating our theoretical users, personas, wireframes, and schemas into real code and data. One thing that became quickly apparant is something will always go wrong from theory to practice. A struggle I faced in creating my first RESTful API routes actually came less from the flask and docker framework, that controls most of the complicated stuff, and actually from a silly error within streamlit. I spent hours and hours rewriting my code on the flask/docker side, checking routes, making sure data was clean, etc. etc. But in the end, you’re just not allowed to nest buttons in streamlit. These types of bugs happen a lot in coding, and being able to take a step back and compartmentalize a process is key in diagnosing and solving it (with the help of your much more knowledgable professor). In the future, I am excited to see the full project come together!