Crashbin - Crash-Reporting-Tool(BA)

Automatisierte Crash-Reporting-Tools wie Sentry oder Airbrake werden von zehntausenden Software-Projekten und Firmen genutzt. Bestehende Produkte sind auf vollständige Automatisierung und oft Millionen von Crash-Events pro Monat ausgelegt. Keines der Produkte berücksichtigt die Notwendigkeit vereinfachter Kommunikation mit den Endbenutzern, die mit den Crashes konfrontiert wurden. Opensource-Projekte sowie Projekte von Start-ups sind oft vergleichsweise klein und ziehen wenig Nutzen aus den zahlreichen Automatisierungen, die diese mächtigen Tools anbieten. Jedoch ist für diese Art von Projekten die direkte Kommunikation mit Benutzern wichtig, insbesondere wenn Probleme auftreten. Ohne entsprechende Werkzeuge besteht die Gefahr, dass Entwickler nicht von Problemen erfahren und Nutzer zu einer Alternative wechseln. In einigen Opensource-Projekten kommunizieren Entwickler via Mail mit den von Software-Defekten betroffenen Benutzern, was schon bei mehreren Crash-Events pro Tag einen erheblichen Aufwand bedeutet. Oft werden auch Bug- und Ticket-Tracker für den Nutzer- und Kundensupport verwendet, diese sind jedoch nicht oder nur rudimentär mit den Crashreportern verknüpft. In dieser Arbeit werden die Bedürfnisse von solchen kleineren Projekten genauer analysiert und es wird ein neuartiges Werkzeug präsentiert: Eine Mischung aus den Konzepten bestehender Crash-Reporter sowie Ticket-Tracking-Software, um die Kommunikation mit Nutzern zu erleichtern. --- Automated crash reporting tools like Sentry or Airbrake are used by tens of thousands of software projects and companies. Existing products are designed for millions of crash reports per month and thus focused on a high level of automation. No existing solution allows for streamlined communication with the users affected by crashes. Open source projects as well as projects run by start-ups are often relatively small and therefore don't benefit from the automation features offered by those tools. However, for such projects, direct communication with users is very important, especially if issues occur. Without corresponding tools, there is a risk that developers do not know about software defects, with users switching to an alternative instead. In some open source projects, developers use emails to communicate with users after issues occur -- an approach which scales up poorly, even with only a handful of reports per day. Often, bug trackers or ticket tracking tools are used for user support, but these are not integrated well with crash reporters. In this thesis, the requirements of such smaller projects are analyzed in detail, and a new type of tool is presented: A mixture between concepts of existing crash reporters and ticket tracking software, to facilitate communication with users

Qutebrowser Made Extensible

The qutebrowser project is a web browser, comparable to Google Chrome or Mozilla Firefox, which is focused on keyboard usage and having a minimal user interface. It is aimed at power-users who value customizability and efficiency, but are willing to accept a rather steep learning curve compared to "traditional" web browsers. In contrast to Chrome and Firefox, qutebrowser did not support extending its functionality via extensions. Over its lifetime, various features have been added to its core by its maintainer and contributors. However, this caused the core to grow substantially, becoming increasingly complex over time. Many users of qutebrowser have specific feature requests and workflows. It should be possible for them to extend qutebrowser in an easy way in order to keep the core small and simple. The goal of this project was to make qutebrowser extensible by introducing a clearly defined API which can be used to develop extensions. Before attempting to expose such an API from qutebrowser, various problematic areas in its codebase had to be cleaned up due to "technical debt" accumulating in the past. Subsequently, functionality suitable for moving out of the core into extensions was identified. Based on the selected areas of code, a concept for an extension API was developed. After implementing said API, large parts of qutebrowser's functionality could be moved into extensions. The resulting changes increased code maintainability and simplicity. More information about qutebrowser can be found on its project website: https://www.qutebrowser.org

HypothesisWorks/hypothesis: Hypothesis for Python - version 4.5.9

You can read the changelog for this release here