Building software for devices that cannot locally support development tools can be challenging. These devices have either limited computing power to run an IDE (e.g., smart-phones), lack appropriate input/output interfaces (display, keyboard, mouse) for programming (e.g., mobile robots) or are simply unreachable for local development (e.g., cloud-servers). In these situations developers need appropriate infrastructure to remotely develop and debug applications. Yet remote debugging solutions can prove awkward to use due to their distributed nature. Empirical studies show us that on average 10.5 minutes per coding hour (over five 40-hour work weeks per year) are spend for re-deploying applications while fixing bugs or improving functionality [ZeroTurnAround 2011]. Moreover current solutions lack facilities that would otherwise be available in a local setting because its difficult to reproduce them remotely (e.g., object-centric debugging [Ressia 2012b]). This fact can impact the amount of experimentation during a remote debugging session - compared to a local setting. In this dissertation in order to overcome these issues we first identify four desirable properties that an ideal solution for remote debugging should exhibit, namely: interactiveness, instrumentation, distribution and security. Interactiveness is the ability of a remote debugging solution to incrementally update all parts of a remote application without losing the running context (i.e., without stopping the application). Instrumentation is the ability of a debugging solution to alter the semantics of a running process in order to assist debugging. Distribution is the ability of a debugging solution to adapt its framework while debugging a remote target. Finally security refers to the availability of prerequisites for authentication and access restriction. Given these properties we propose Mercury, a remote debugging model and architecture for reflective OO languages. Mercury supports interactiveness through a mirror-based remote meta-level that is causally connected to its target, instrumentation through reflective intercession by reifying the underlying execution environment, distribution through an adaptable middleware and security by decomposing and authenticating access to reflective facilities. We validate our proposal through a prototype implementation in the Pharo programming language using a diverse experimental setting of multiple constraint devices. We exemplify remote debugging techniques supported by Mercury's properties, such as remote agile debugging and remote object instrumentation and show how these can solve in practice the problems we have identified.
