Forced browsing is the class of serious web application vulnerability I see the most often. Contrary to conventional wisdom, you can build effective automated tests for it in your application, tests that don’t use hard-coding or fuzzing.
In November 2014 we announced the availability of rwslib, a python library which provides helpers to access Rave Web Service (RWS) APIs. That release included Builders for creating CDISC ODM messages for clinical data exchange (e.g. uploading a blood pressure reading or demographic information to Rave EDC). The latest version of rwslib improves on these builders and provides support for our own MAuth authentication scheme via a separate requests-mauth library which we are also releasing as Open Source under a MIT license.
Wherein we learn how to run commands that require SSH keys or other secrets from within a Dockerfile, without leaving said secrets in the resulting Docker image.
We have opensourced a library for webcrawling called Grell. The main properties of Grell over other tools are: - It is written in Ruby so it is very easy to use it by a Rails application or a gem. - It uses Phantomjs under the hood. Which allow us to execute the Javascript of the pages we are crawling. This allow us to, for instance, follow links added by Ajax requests or elements which are not links but become clickable with Javascript.
Testing with microservices is tricky. The behavior you need to support is spread across many different codebases, with their own testing frameworks, deployment processes, and developers. With a platform as widely used as the Medidata Clinical Cloud, it gets even trickier: if there’s any aspect of a service contract you haven’t carefully defined and tested, you’re going to end up breaking some integration.
Over the past few years, Medidata has worked hard to meet the demanding requirements of producing high quality software applications. Building enterprise class solutions like a Big Data Analytics Platform involves testing huge amounts of clinical trial data from various studies, subjects, and embedded devices. Processing and storing terabytes or petabytes of data may take days or weeks to complete. Using a large data set during software development and testing delays the continuous integration and delivery efforts. We have taken an innovate approach on testing big data applications such as Extract, Transform and Load (“ETL”) process by using input space partition testing to create a smaller representative sample.
Almost one year ago, I sat down with David Kronfeld (Director, Corporate Development) for the first time. David was looking to strengthen the bridge between his team and the Product team by collaborating on interdepartmental projects. As part of our collaboration, we took control of Medidata’s Developer Central program.
If writing working code is a challenge then writing working deployable code is a really big challenge. If you’ve been in the software business for more than a few months, you’ve heard statements like “it works fine on my machine” or “it worked in {Environment A} so I don’t know why it doesn’t work in {Environment B}”? As responsible engineers and developers, it’s our duty to deliver working, deployable code.
In our last post we introduced rwslib, a Python client library for Rave Web Services (RWS). In this post we look a little closer at one of the components of RWS: the Clinical Audit Records web service and at a rwslib helper that makes it easy to capture key events from the Rave EDC System.
Medidata’s business is enabling pharmaceutical and biotech companies to plan and execute their clinical trials with greater speed and efficiency, getting medicines approved and to patients faster. Part of that process involves collecting data from physicians but also increasingly from devices, from the patients themselves and from labs. The primary repository for this data is Rave, our Electronic Data Capture (EDC) system.
In Dragonlance, Kenders are fast and clever. They are impossible to contain and unrelenting in the pursuit of their goal - exactly the kind of traits you want in a continuous integration (CI) environment.
You cannot start a project without DiceBag the same way you can not setup your character without rolling dice.
As we build more services in the Clinical Cloud, there’s an increasing need for a robust tool to move large amounts of data between these services. Take Plinth, for example. Plinth is our core clinical objects service, serving resources like studies and sites. As more Medidata codebases adopt Plinth for master data management, they’ll need to migrate their own persisted core clinical objects over to Plinth.
The following is adapted from an internal whitepaper I wrote last year, pitching a platform-wide security enhancement that we’re now implementing. Medidata has complex and evolving access control requirements. To manage them, we’re drawing on a new, open standard–the Policy Machine–from the Computer Security Division at NIST.
The no single point of failure design principle asserts simply that no single part of a system can stop the entire from working. For example, in our Electronic Data Capture product, Rave, the database server is a single point of failure. If it crashes we cannot continue to serve clients in any fashion. But, if we kept all of Rave in cache, we could continue to operate in read-only mode. Has the system stopped working? Some functionality has definitely failed, but some business process could still progress.
Medidata was founded on a simple (but at the time revolutionary) innovation: Using the web to collect, check and provide remote access to Clinical Trial data. But as a company grows it’s easy to focus on the official roadmap and miss out on unexpected opportunities that crop up along the way.
Mobile applications and bring-your-own-device initiatives are playing an increasingly important role in Life Sciences. At Medidata, we’re extremely excited because mobile apps are a natural extension of our cloud platform, enhancing the patient experience and greatly improving the quantity and quality of health data available.
At Medidata we provide a number of SaaS solutions for organizations conducting clinical trials. We believe that if you’re going to ask your customers to invest in a SaaS solution, you need to be willing to do so yourself. To that end we use many SaaS tools in the line of developing our software: GitHub, HipChat, Jira and so on. Having accounts spread across a number of tools in this way causes an administrative headache for managers like me.
In November 2013, Amazon released CloudTrail, a web service that logs Amazon Web Services (AWS) requests to store in an S3 bucket. Here’s how we made it work with Logstash – originally with version 1.2.3 and later with the no-longer current development branch, Logstash 1.4.0.
‘DevOps’: such a simple word to convey so much meaning. What is DevOps? Ask 5 people and you’ll probably get 5 different answers. It is a mysterious and ephemeral ideology - many people will tell you it’s a great idea, but relatively few will really understand it. Like so many powerful ideas, at its heart DevOps is a very simple concept; but there is enormous complexity in its application, because it must be applied by organizations, not individuals, and not even just teams. The application of these concepts is often beleaguered by resistance to change, for many reasons - rational, emotional and inertial.
It’s hard to imagine building software nowadays without leveraging some form of open source software. From operating systems to databases to web servers, open source software forms the backbone for the overwhelming majority of the systems that power the internet and the cloud. One of the things that makes the Open Source Software movement so unique is its altruistic nature. There are tens of thousands of active open source projects that are solving real problems and are allowing businesses to innovate and grow and in Medidata’s case to save lives and improve quality of life.