- One final note is I tried to do with julz what ember-cli <https://ember-cli.com/> did for Ember.js <http://emberjs.com/> - I really think the addition of ember-cli into the ecosystem changed the community in a way they never thought possible
On Thursday, October 6, 2016 at 10:12:21 AM UTC-4, Dan Segal wrote: > > *Code* > > - github repo: https://github.com/djsegal/julz > - (see readme.rst as well as included dummy Julia project) > > *Summary* > > Julz is a command line utility for creating ambitious Julia applications. > Its goal is to remove many of the petty decisions involved in starting a > project and establish a standard that can be adopted by the entire Julia > ecosystem. In this way it channels Ruby on Rails’ mantra of “convention > over configuration”: tell people where files should go, but allow them to > tweak it if they so desire. > > *Description* > > The problem Julz attempts to resolve is architecting a Julia project that > is resilient to both the frequent on-boarding/turnover of engineers as well > as the mass accumulation of files. In this way, a person reading a codebase > for the first time does not get bogged down by the sheer number of files > that have accumulated over time inside a shallow depth src directory. > > The way to alleviate this problem is to treat the src folder and the test > folder as boxes that hold smaller boxes of like content. In a Julia > context, this means that the src and test folder each have corresponding > subdirectories for: methods, types, functions, macros, etc. Each > subdirectory then has an associated generator command that can be used to > make files of that format. For example, generating a Rational type with two > integer fields from the command line would use boiler-plate templates to > compile: > > - a working rational.jl file in the ‘src/types’ directory > - an associated rational_test.jl in the ‘test/types’ directory > > This may not seem like a big idea at first, but getting every project to > adopt this level-deeper folder structure is the cornerstone to a successful > framework. With it, packages can be created that expand on the native > collection of data structures, i.e. to produce singletons, compilers, etc. > Here, the addition of generators just make everything less user-error prone > and promotes adequate test coverage of code. > >
