Does your data science platform check the following boxes?
This bite-sized post is the first in a series that digs into using Git effectively from within Gigantum. We start with the the most basic thing, which is importing an external Git repository (or "repo") with some data. Gigantum does a lot of Git automation under the hood. While that automation provides nice features like version control by default and the Activity Feed, naive inclusion of a Git repos in your project can lead to some hiccups! So how can we use a dataset that's published on GitHub?
This recaps our first webinar of June 23, 2020. It was fun and we wanted to give access to the video.
The webinar demoed creating portable and reproducible work in Jupyter and RStudio, as well as an easy system for transferring work between CPU and GPU resources. It further explained why decentralization, not centralization, is best for collaboration and productivity in data science. The current remote work situation makes this decentralized approach even more critical.
In the webinar Dean (CTO) and Tyler (CEO):
- Outlined the technical problems of collaboration and managing data science work;
- Related this problem to cost and productivity concerns;
- Explained "centralized vs decentralized" and why decentralization is better;
- Explained how local automation can make decentralization robust & scalable;
- Demonstrated Gigantum's Client + Hub model for scaling collaboration and productivity.
Decentralization means letting data scientists work across resources in a self-service fashion. For us, it also means container native, not just cloud native. It is that simple.
The key to decentralization is automation and a UI at the local level, not as a monolithic, managed cloud service. We call this "Self Service SaaS", which is sort of a silly phrase but captures what we mean.
Self Service SaaS takes the good parts of the SaaS experience, i.e. nice UIs and automation around difficult tasks, and eliminates the bad parts, i.e. zero control over deployment and everything that entails.
Check out the video and let us know what you think. We love to talk about this stuff and we want to hear your story and your problems. You can watch by filling out the form below.
Gigantum automates the tracking of your code and data in Git / Git-LFS and reproducing your environment on different machines using Docker. Gigantum runs in Docker, and thus you can use it on pretty much any machine, including Windows. However, Docker has some performance penalties on pre-WSL2 Windows, and Gigantum inherited them. (While you'll rarely see it written out, WSL2 stands for Windows Subsystem for Linux 2.)
Most importantly, in comparison to running on Mac or Ubuntu, Gigantum on Windows had a performance penalty for file access. With WSL2, that is no longer true!
In this post, we explore some of the cutting edge tools coming out of the RAPIDS group at Nvidia. This highlights yet another use-case for the portability provided by the Gigantum Client - we're going to make it easy to try out an evolving code base that includes some fussy dependencies. This post revisits some skills we picked up in our previous post on Dask dashboards, so be sure to check that post if you're interested in parallel computing!
This post is an overview for reviewers that are using Gigantum to inspect code for a manuscript.
Gigantum is a browser base application that integrates with Jupyter & RStudio to streamline the creation and sharing of reproducible work in Python & R.
Working exclusively in a single cloud isn't possible for most people, and that is not just because it is expensive. Real work requires significantly flexibility around deployment.
For example, sensitive data typically can't go in the cloud. Or maybe each of your three clients uses a different cloud, or maybe you spend significant time on a laptop.
It would be nice if things would "just work" wherever you want them to, but the barriers are many and large. Git & Docker skills are table stakes. Typos & hard coded variables rule the day. No matter how careful you are, stuff goes wrong. Maybe your collaborators don't have the same level of care and technical skill you do.
Who knows? The possibilities are endless.
Well, it used to be hard. There is a new container native system that moves reproducible work between machines (virtual or bare metal) with a few clicks.
No need to know Docker or Git. No need to be obsessive about best practices. No need to worry who is on what machine.
We will demo it here using Dask and DigitalOcean for context. In the demo we:
- Create a 32-core Droplet (i.e. instance) on Digital Ocean
- Install the open source Gigantum Client on the Droplet
- Import a Dask Project from Gigantum Hub and run it
- Sync your work to Gigantum Hub to save it for later.
Computational reproducibility should be trivial but it is not. Though code and data are increasingly shared, the community has realised that many other factors affect reproducibility, a typical example of which is the difficulty in reconstructing a work’s original library dependencies and software versions. The required level of detail documenting such aspects scales with the complexity of the problem, making the creation of user-friendly solutions very challenging.