Weather API

Creating a Weather API was a project assigned by Enegia Consulting Oy, a subsidiary of Enegia Group Oy. Enegia Group’s business idea is to offer services to customers helping them to reduce energy related costs. The objective of the project by the Enegia Consulting Oy was to plan and implement Weather API for other Enegia services to consumers. The Weather API would serve weather information to a given postal code, time frame and resolution to all authorized requests to the API. The weather information was gathered from the open data service of the Finnish Meteorological Institute, and stored to the database using Weather API endpoint. The information was gathered daily using Azure WebJob. The Weather API was written with C# using .NET Core 1.0 development platform. The application used time series database InfluxDB to store the weather information. Other data such as the postal code to geolocation mapping was stored to Azure SQL database in Microsoft Azure. The solution ran in Microsoft Azure App services. The Weather API was released to production in May 2017 and since then it has been running continuously without interruption. Further development has been planned, however, the implementation has not yet been started.Säätieto-ohjelmointirajapinta-projekti toteutettiin Enegia Group Oy:n tytäryhtiön Enegia Consulting Oy:n toimeksiannosta. Enegia Groupin liiketoiminta-ajatuksena on tarjota asiakkailleen palveluita, jotka auttavat vähentämään energiakustannuksia. Säätieto-ohjelmointirajapinta-projektin (lyhyemmin Weather API) tavoitteena oli suunnitella ja toteuttaa säätietorajapinta, jota muut Enegian palvelut voisivat käyttää. Weather API palvelisi säätietoja tietylle postinumerolle, aikavälille ja resoluutiolle kaikille valtuutetuille pyynnöille. Säätiedot kerättiin Ilmatieteen laitoksen avoimesta tietopalvelusta ja tallennettiin tietokantaan Weather API:n rajapinnan avulla. Tiedot kerättiin päivittäin Azure WebJobin avulla. Weather API kirjoitettiin C # -ohjelmalla käyttäen .NET Core 1.0 -kehitysalustaa. Sovellus käytti aikasarjatietokanta InfluxDB:tä säätietojen tallentamiseen. Muut tiedot, kuten postinumeron paikoitustieto, tallennettiin Azure SQL -tietokantaan Microsoft Azure -palvelussa. Ratkaisu toteutettiin Microsoft Azure App -palveluissa. Weather API julkaistiin tuotantoon toukokuussa 2017, ja sen jälkeen se on ollut käynnissä keskeytyksettä. Jatkokehittämistä on suunniteltu, mutta toteutusta ei ole vielä aloitettu

The Role of a Microservice Architecture on cybersecurity and operational resilience in critical systems

Critical systems are characterized by their high degree of intolerance to threats, in other words, their high level of resilience, because depending on the context in which the system is inserted, the slightest failure could imply significant damage, whether in economic terms, or loss of reputation, of information, of infrastructure, of the environment, or human life. The security of such systems is traditionally associated with legacy infrastructures and data centers that are monolithic, which translates into increasingly high evolution and protection challenges. In the current context of rapid transformation where the variety of threats to systems has been consistently increasing, this dissertation aims to carry out a compatibility study of the microservice architecture, which is denoted by its characteristics such as resilience, scalability, modifiability and technological heterogeneity, being flexible in structural adaptations, and in rapidly evolving and highly complex settings, making it suited for agile environments. It also explores what response artificial intelligence, more specifically machine learning, can provide in a context of security and monitorability when combined with a simple banking system that adopts the microservice architecture.Os sistemas críticos são caracterizados pelo seu elevado grau de intolerância às ameaças, por outras palavras, o seu alto nível de resiliência, pois dependendo do contexto onde se insere o sistema, a mínima falha poderá implicar danos significativos, seja em termos económicos, de perda de reputação, de informação, de infraestrutura, de ambiente, ou de vida humana. A segurança informática de tais sistemas está tradicionalmente associada a infraestruturas e data centers legacy, ou seja, de natureza monolítica, o que se traduz em desafios de evolução e proteção cada vez mais elevados. No contexto atual de rápida transformação, onde as variedades de ameaças aos sistemas têm vindo consistentemente a aumentar, esta dissertação visa realizar um estudo de compatibilidade da arquitetura de microserviços, que se denota pelas suas caraterísticas tais como a resiliência, escalabilidade, modificabilidade e heterogeneidade tecnológica, sendo flexível em adaptações estruturais, e em cenários de rápida evolução e elevada complexidade, tornando-a adequada a ambientes ágeis. Explora também a resposta que a inteligência artificial, mais concretamente, machine learning, pode dar num contexto de segurança e monitorabilidade quando combinado com um simples sistema bancário que adota uma arquitetura de microserviços

Bioinformatic Investigations Into the Genetic Architecture of Renal Disorders

Modern genomic analysis has a significant bioinformatic component due to the high volume of complex data that is involved. During investigations into the genetic components of two renal diseases, we developed two software tools. // Genome-Wide Association Studies (GWAS) datasets may be genotyped on different microarrays and subject to different annotation, leading to a mosaic case-control cohort that has inherent errors, primarily due to strand mismatching. Our software REMEDY seeks to detect and correct strand designation of input datasets, as well as filtering for common sources of noise such as structural and multi-allelic variants. We performed a GWAS on a large cohort of Steroid-sensitive nephrotic syndrome samples; the mosaic input datasets were pre-processed with REMEDY prior to merging and analysis. Our results show that REMEDY significantly reduced noise in GWAS output results. REMEDY outperforms existing software as it has significantly more features available such as auto-strand designation detection, comprehensive variant filtering and high-speed variant matching to dbSNP. // The second tool supported the analysis of a newly characterised rare renal disorder: Polycystic kidney disease with hyperinsulinemic hypoglycemia (HIPKD). Identification of the underlying genetic cause led to the hypothesis that a change in chromatin looping at a specific locus affected the aetiology of the disease. We developed LOOPER, a software suite capable of predicting chromatin loops from ChIP-Seq data to explore the possible conformations of chromatin architecture in the HIPKD genomic region. LOOPER predicted several interesting functional and structural loops that supported our hypothesis. We then extended LOOPER to visualise ChIA-PET and ChIP-Seq data as a force-directed graph to show experimental structural and functional chromatin interactions. Next, we re-analysed the HIPKD region with LOOPER to show experimentally validated chromatin interactions. We first confirmed our original predicted loops and subsequently discovered that the local genomic region has many more chromatin features than first thought

On the real world practice of Behaviour Driven Development

Surveys of industry practice over the last decade suggest that Behaviour Driven Development is a popular Agile practice. For example, 19% of respondents to the 14th State of Agile annual survey reported using BDD, placing it in the top 13 practices reported. As well as potential benefits, the adoption of BDD necessarily involves an additional cost of writing and maintaining Gherkin features and scenarios, and (if used for acceptance testing,) the associated step functions. Yet there is a lack of published literature exploring how BDD is used in practice and the challenges experienced by real world software development efforts. This gap is significant because without understanding current real world practice, it is hard to identify opportunities to address and mitigate challenges. In order to address this research gap concerning the challenges of using BDD, this thesis reports on a research project which explored: (a) the challenges of applying agile and undertaking requirements engineering in a real world context; (b) the challenges of applying BDD specifically and (c) the application of BDD in open-source projects to understand challenges in this different context. For this purpose, we progressively conducted two case studies, two series of interviews, four iterations of action research, and an empirical study. The first case study was conducted in an avionics company to discover the challenges of using an agile process in a large scale safety critical project environment. Since requirements management was found to be one of the biggest challenges during the case study, we decided to investigate BDD because of its reputation for requirements management. The second case study was conducted in the company with an aim to discover the challenges of using BDD in real life. The case study was complemented with an empirical study of the practice of BDD in open source projects, taking a study sample from the GitHub open source collaboration site. As a result of this Ph.D research, we were able to discover: (i) challenges of using an agile process in a large scale safety-critical organisation, (ii) current state of BDD in practice, (iii) technical limitations of Gherkin (i.e., the language for writing requirements in BDD), (iv) challenges of using BDD in a real project, (v) bad smells in the Gherkin specifications of open source projects on GitHub. We also presented a brief comparison between the theoretical description of BDD and BDD in practice. This research, therefore, presents the results of lessons learned from BDD in practice, and serves as a guide for software practitioners planning on using BDD in their projects