Drawing Board 1 - Do I build a file system?

-

This is a quick review and series of revisions after doing the first sprint on Your Data Place, and playing around with integrations and SDKs. So... what is YDP (Your Data Place)?

YDP at the core started as a way to store your old datasets for quick reuse and agile data discovery and analysis. You could (ideally) take your datasets, drop them into YDP, then write lambda-like functions which would execute them seamlessly and provide results and cultivate an environment of experimentation.

From there, more ideas jumped out of the page: iterative datasets for managing big data easily, blending data, expanding columns on data using logic (like converting addresses to latitude longitudes), easy integrations with Google APIs which I use so often (Sheets/etc), transforms vs dataset creators, uploading dependencies through requirements.txt or conda.deps, timer logic for expressing complicated timers in code, and the before-mentioned "code being the best form of expression for data", and so much more.

This is all great, and I still find the ideas extremely valuable and implementable, but I'm suffering from the thought that it needs more. Sure, it solves my problems, but I have this itch that there's a meta-problem to be solved which sits outside of the problems I solve existingly, of which will solve and streamline my workflow to generate more value in my professional career.

One big decision I've been trying to decide on is as-to whether the client UI will emulate a full file-system (FS), which is both a huge positive but also seems like a massive negative in-that the app will become more of a cloud IDE than a data platform (in my head). One implementation of this which seems to sit outside of the IDE side is indeed allowing a FS to exist and allow one to build code that executes in this FS context, but build meta-scripts which are the current "dataset creator" scripts which utilize this file-system.

Another illustration would be that users can create SDKs or commonly recycleable "scripts", which when they attempt an import, are brought into the project and referenceable. This would streamline jobs down into 3-10 line scripts (transformations, jobs, or dataset makers), of which all the hard logic is developed in a real IDE then provided.

There feels like no need to reinvent the wheel, and I definitely have no passion for IDE engineering. Data, on the other hand...

Comments

Post a Comment

What did you think about this post? Do you have any ideas you think would be helpful?

Popular posts from this blog

Shareable data and code in YDP Projects

-
Image
Datasets, everywhere... One major ability I want in YDP is the ability to create datasets that can be interpreted as global, reproducable datasets which were created as part of a dataset generator. Although I presume datasets will primarily be used inside their own projects, I think there's great value in the ability to make these datasets global, and accessible by any other project. The Problem At the moment, the problem is in the implementation. This was no issue when YDP was a sandbox test project in my local filesystem, where I could easily WRITE a file here, then READ a file here under the same name. But, in a real production architecture, we're using Docker as of this moment to manage our independent filesystems. When it comes to being able to have a dataset be generated in Project 1's file system (FS) then wants to be used in Project 2's FS, what has to occur is something along the lines of the following: Flag a Python script as a generator for a dataset. Execute
Read more

Siesta of YDP

-
Unfortunately, I've had to take a siesta in Your Data Place. I'm still extremely passionate, but most of my spare time has been consumed by a half-work half-play project which is niche in my industry which will allow me some more future freedom if it ends up working correctly. I'm using some of the innovations I've outlined here in that project, to make it something completely unique and separate to the current competitors. It's in the pharmaceutical space, and I may start to think through concepts in this blog, as some of the ideas are quite abstract but need to be represented simply and easily to the users. In the time since I've last written, I have not learnt Rust to a proficcient level. I've learnt Firebase and become better at frontend web design as well as better at software application building using Python. I will return to Rust, and YDP, as these are my raw passions. I believe my experience in this next project will greatly inspire more ideas in YD
Read more

The start: a week of Rust

-
Image
I've taken a small break to focus on my primary work obligations, and in that time I've had lots of time to ponder. During this time, I flew to Tasmania (737-800) and read through a few preliminary chapters of Manning Publications'  "Math for Programmers"  (Paul Orland). This book is a real workhorse for programmers who want and know  they wish to be able to implement more mathematics into their code, but find the conventional teaching methods difficult to fast-track. Home now, I plan to spend a week giving Rust a real go from the other Manning Publications book, "Rust in Action"  (Tim McNamara). In this time, I'll learn everything with a noble aspiration: "How could this benefit the users of YDP?" (as well as my primary work, and other interests of mine like genetics). Rust is fast, but from what I've experienced, it's cracked and goated with the sauce. What I find interesting about Rust, is the author's intent is as clear as d
Read more