This isn't exactly the best stack overflow question because it's opinion-based, but I'm going to try to ask it in a way that will lend itself relatively to an answer with some degree of factuality (as opposed to opinion).
I know you can switch projects (https://docassemble.org/docs/playground.html#projects), which is of course very useful. What I'm thinking about in particular is that I have seen some tutorials that abstract code out of interviews in .py files -- this seems reasonably useful to me, not the least of all because of linting (tangent: is there a docassemble linter?).
Because of the way docassemble does inheritance, I think I would rather have my entire playground be one big directory with subdirectories for projects (rather than starting from scratch with new projects ... some of the .yml file, .py files, static files, etc. are probably able to be written in a way that they can be re-used across interviews and I'd love to do that in a way that's less clunky than re-importing them into a new project when I need them.
Can we organize the playground in docassemble, or are we stuck with a one-level directory?
If the playground can be organized (eg. into directories, subdirectories, etc.), are there any community-accepted or JHPyle-reccomended best-practices around that? (i.e. although I assume less formal, I'm thinking something like PEP) I know it's probably easy-enough to come up with a file naming convention with similar effect, but that's a bit hacky.
Is in possible, as an alternative, to simply directly edit the packages?
The main thing I'd like to accomplish, and the main impetus for this question, is keeping my code DRY by using helper functions / helper .yml files.
The Playground is a simplified interface for people who are new to programming. It supports "projects" but does not support subdirectories. Advanced programmers can write their code in Python packages using a text editor and can use subdirectories under the data directory if they want to.
Related
It is 2017, and as far as I know, the way programmers organize their codes have not changed. We distribute our codes into files and organize them with a tree structure (nested directories and files). When codebase is huge, and the relations between classes/components are complex, this organization approach gives me the inefficient impression. With more files, either one directory has more files in it or the depth of directories increases. And since we handle the directories directly, navigation costs me time and effort without tools like search.
Figure: A complex UML from https://github.com/CMPUT301W15T09/Team9Project/wiki/UML
We can use CAD to design/draw complex things; mind map can be created in a similar manner. For these, we do not need to deal with file systems. Can't we have something similar and hide file system in a black box? Why the fundamental organization methods have not evolved for so long a time.
So I wonder, what's the advantages that keeps us from getting a new way? What's the inherit advantages of using file system to organize our codes.
Different on-disk representations of source-code have been tried (e.g. how Flash stores ActionScript inside binary .fla files) and they're generally unpopular. No-one likes proprietary file formats. It also means you can't use text-based source control systems like Git, which means you can't do a text-merge to resolve change conflicts.
We store source code in files in a tree structure (e.g. one OOP class or procedural module per file), with nested namespaces represented by nested directories because it's intuitive (and again, for better cohesion with source-control systems).
Some languages enforce this, like Java, for example, that requires the source file be named the same as the class it contains and be in the same directory name as its containing package. For other languages like C# and C++ it just makes sense - because otherwise it's confusing to someone who might be new to your codebase when they see class TurboEncabulator inside a file named PrefabulatedAmulite.cs.
I'm working on a website with Visual Studio Code.
Is there a way to save only the files being used by a project into a separate folder?
Basically what I'm looking for is a tool which would scan all the local resources linked by all html files (meaning linked images, videos, files), and then it would save them all in a separate folder.
The reason why I'm asking this is because at the moment I'm testing things out, meaning I'm using image A, then image B, C and so on so forth. These images live in subfolders, so now I ended up with some images which I'm actually using in the html pages and some which I'm not. The thing is, is not simple to check which images I'm using.
You'll find the same principle in 3d applications, such as 3ds Max for instance, where, once you're done with the project, you can use a Resource Collector tool to strip out all the unused assets and save only the ones used by the project.
I've looked for an extension or a solution to this without any luck, so I guess an extension does not exist yet, but I think it would be a nice tool.
I don't understand why someone downvoted my post.
Either what I'm asking is already possible, although like I said I searched and I didn't find anything, or who downvoted consider my request stupid.
Whatever the reason, I believe it would be more mature to give a proper answer, even if whoever downvoted did it for either one of the two possible reason above.
In fact:
The solution already exists: like I said, I didn't find it, so if someone knows the solution why not simply posting it here?
The solution doesn't not exist but someone thinks it's a stupid idea. Well, it is not and it would be polite and civilized to discuss it.
In the current era it became so easy to express opinions without actually doing anything, by simply pressing a button to say nothing valuable, as a "I like".
I never stop feeling amazed where the social media behavior it's taking us.
Is there is a standard fashion for organizing a Rust project? I have been working with C-family programming languages for over nine years, but Rust seems different in some aspects.
Is one supposed to organize their projects in a similar manner to C-family languages, especially object-oriented such?
project
|->src
|->main.rs
|->structs.rs
Or perhaps in this way?
project
|->src
|->main.rs
|->struct0.rs
|->struct1.rs
|->struct2.rs
|->struct3.rs
That is, one file per struct?
Or does one create new binary projects every time they make a new part of their program? I am currently using Cargo to generate my projects, but to be fair do not know too much about it. Eventually, there will come a point when I read through the entire Cargo documentation, although I would like to get a little more acquainted with Rust prior to that.
Kindly explain in both trees and text, as well as possibly some pieces of code.
Try to plan how your program will be organized in terms of logic rather than objects. Split your logic into separate modules.
If a you have a small module make it a single file modname.rs or if it is a bigger module (consisting of submodules) create a folder with at least a mod.rs file in it: modname/mod.rs.
If your project gets really huge you could also split it into several crates (libraries) which you then depend on in your main project.
You can read more about Rusts crates and module system in the official rust book: https://doc.rust-lang.org/book/crates-and-modules.html
I have two questions regarding coding Haskell in Emacs/VIM in Linux :
If one wanted to organise a haskell code base into multiple projects (where files of a given project are stored in a particular folder) then can emacs and vim handle this? The reason is that I have used IDE's before where all the projects are loaded at once into the session, but am not sure how this would work for Emacs/VIM.
Another nice thing about IDEs is that I can go the definition of a function from a given project, even if that function definition is in a separate project (i.e. stored in a separate folder). Can Emacs/VIM handle this?
There was some discussion here : Haskell IDE for Windows?
VIM/Emacs don't care how you organize your files. They're primarily editors, so you can use them to edit files no matter how you lay out your directory structure. Other than that, it's good to follow some standard conventions, or adapt the structure for tools you are going to use. You can have a look at Structure of a Haskell project. It is also convenient to use Cabal to build your project and to manage its dependencies.
VIM/Emacs can use Ctags index files for navigating in your project. See Tags for available options how to create these index files. The indexing tools don't expect any specific project structure, so if you need to navigate in multiple projects, you can just index a directory with multiple projects into one index file.
There's an Emacs mode called Projectile that allows some "project-like" functionality, which might be what you're looking for. I haven't really used it myself (I tend to stick to the old *nix way of just editing files), so I can't give you details, but it can't hurt to check it out.
Not sure if I understood the gist of question correctly. The following is my suggestion concerning the question of management of multiple projects in Vim, without regard to the language employed.
You could take advantage of vim sessions. With a few custom functions/keymappings in your .vimrc you'll be able to keep a separate session file for each project, either in the project directory or the one you'd dedicate for session files.
This is the general how-to: http://vim.runpaint.org/editing/managing-sessions/
And there you'll find a number of scripts that specifically address the issue of handling multiple project-specific sessions: How to auto save vim session on quit and auto reload on start including split window state?
I have loads of notepad , js , .cs in a folder that I use to refer back to when I'm developing. They are just in a folder on my laptop. Is anyone aware of a better way of storing all this guff in a more stuctured way? Thinking some kind of cloud website or something?
You can use a wiki for this kind of thing. There are wikis that are local, such as TiddlyWiki.
One way or another, to keep things safe, you should use source control, and/or backup to the cloud.
I keep my code samples that aren't project-specific in a revision-controlled directory tree, based on the language they're in; actual projects are also kept in revision control, but are kept separately. I have tons of them now.
For smaller idioms and snippets that are useful or that I forget as I switch between languages for a period of time, I pop them into a wiki, with different pages also based on which language they're in. I don't put whole files in there; I just extract the pieces that I tend to forget and pop them in there.
They do tend to build up as time goes on, so just putting the smaller pieces in is much more efficient for fast lookup.