Awesome tool. I love its simplicity, and also the vim-like command mode.
Right off the bat, here are a few improvements I would suggest for the command mode:
- (i or Enter): Go back to edit mode
- (dd): Delete the task
- (u/r): Undo/Redo
Another suggestion would be to spin up some sort of issue-tracker (github, discourse, canny...) where feedback can be given in an organized way.
SDV (The Synthetic Data Vault) is an ecosystem of Open Source Python libraries and tools for Synthetic Data Generation that works with single-table, multi-table and time-series data. One of the use cases of Synthetic Data is data augmentation for machine learning models, as shown in the example posted, but it also enables a multitude of other use cases such as privacy preserving methods for sharing data or the generation of data for software testing. More resources, tutorials and documentation can be also found here: https://sdv.dev
I'm Carles Sala, the lead developer of the SDV, The Synthetic Data Vault. Please feel free to ask any questions that you may have about it. Any feedback will be more than welcome!
> I've honestly tried to give Vim a go, there just seemed like to much setup and configuration so I went back to an IDE.
I'd like to point out something to avoid scaring away potential Vim newcomers here.
While it's true that Vim can get as complex as you want via plugins and configuration, I think that one of beauties of developing with Vim is not doing this, spending a lot of effort configuring it to behave like a complex IDE, but rather changing a bit your working paradigm to rely only on just the basics and, at most, a few tweaks on a custom .vimrc which you can quickly scp over (or wget) to the host where you are working on.
Here I will totally agree that at the beginning it may require some time to get used to it. But once you get there, the level of freedom that it gives you is totally worth it. And not only because then any shell feels like home, but also because not having all the IDE helpers available also ends up forcing you to have some additional awareness about what you are doing on the code. You need to remember what the function signatures are, where the different pieces of code are, take care of the coding style while typing, etc. And, while it's truly a much more spartan experience, at the end your efficiency stops depending on your working environment to become just a part of you.
It is becoming clearer every day how Synthetic Data Generation will be a must-have skill and technology in the upcoming years!
I'm the lead developer of an Open Source project called SDV (The Synthetic Data Vault)[0] which offers an ecosystem of Python libraries and resources for Synthetic Data Generation of different data modalities. It allows learning and sampling synthetic clones of Single Table, Relational and Time Series datasets, and offers tools to evaluate the quality of the generated data and benchmark different models.
I am honestly surprised at the amount of people here trying to say that open sourcing your work and making money out of it is incompatible. While the OP may have plenty of reasons and be totally entitled to make this decision, I do not thing their case can be directly compared to all the different open source projects out there.
Being myself a full-time open source developer, I have seen several cases in which businesses are built around free software, either because multi-billion companies hire third party teams to build software for them under the conditions (imposed by the hired team) of open sourcing what is built, or by developing free software while offering high-end paid support for it, or even by wrapping the open source software in commercial enterprise-level, services-oriented applications.
So no, I do not think that it is reasonable to paint open sourcing is an equivalent to being stolen by big tech companies. It is just a particular way of doing things, originally based on certain principles and which sometimes succeeds as a business strategy and some other times does not, just like any other business strategy out there!
Having said that, I wish the best of luck to Marak and I hope they figure out the way to remake their life after what happened and continue to push on their awesome work on open source software while managing to make a living out it!
Simply saying prefer "this" over "that" without adding any context to the equation is the best recipe to end up doing the wrong thing in the wrong place. Or maybe you mean that you can make the same decisions when testing a Web based app UI than when testing a cryptographic function in the Linux kernel?
IMO, both mocks, fakes and "reals" (to put it in the same language) need to be first class citizens of software testing, each one of them used in the right circumstances.
Just like resorting to unit testing only is as much a bad practice as it is to use acceptance testing only.
A good testing strategy should be adapted to each software and context, and potentially include all types of tests: unit, end-to-end, integration, numerical, acceptance, etc. and all sorts of resources: mocks, dummy data, substitutes, testing engineers, test databases, real databases, real users, etc.
Another suggestion would be to spin up some sort of issue-tracker (github, discourse, canny...) where feedback can be given in an organized way.