jdwije / lewt Goto Github PK

Documentation is falling behind features pretty hard at the moment. Some time should be spend creating though rough writ ups of how things work. A few wiki pages for things such as building extensions would be nice as well.

The unit test system took a bit of a battering when lib mode was introduced. Now it doesn't properly distinguish between lib & cl mode, however it still works. A solution should be created that works for both.

Furthermore some classes (especially extensions) should really have some more meaningful test going on..

Calendar Extract stopped working due to the google Calendar API upgrade to v3.

See here: https://developers.google.com/google-apps/calendar/

Integrate rake into the project to streamline builds

The GEM spec file is currently not including all the required core extensions for LEWT. This is because there individual .rb file are not listed in the gemspec!

Turns out you can recursively include directories with it... I'm not going to maintain a list of files in the package - either this needs to be automated or a alternative solution needs to be figured out.

A handler should be built so events data can be extracted directly from Goggle Calender

rounding and numbers should be restricted to currency values (i.e. 2 decimal places) across the whole program. Initialising values as doubles in the ledger will probz handle this downstream.

Currently invoices are outputted to the terminal. a -w should be enabled so that they can optionally be written as yaml files to a specified location.

Currently these are one and the same! That means my config will be in there (oops), guess that means I have to change some passwords before release.

The command line mode of lewt is more developed than the library mode. By this I mean I have spent more time thinking and optimising command line usage than software usage of LEWT! The API is messy, for example the main function of the LEWT class is run_logic_loop - this function does not run a loop, it fires the extract, process, render events! There are a lot of confusing naming conventions like this, some effort should be spent cleaning these up.

Extensions take more steps than required to init. Streamline this:

class Reports < LewtExtension

  def initialize
    super
    @command_name = "report"
    register_extension
  end

end

The extensions that ship with LEWT should be able to be developed separately from the CORE system.

A compile script should be created that fetches these extensions from there respective repositories and includes the in the main LEWT project. Perhaps it should be able to target specific builds as well in case the master branch is broken or whatever.

In general I would like for some motivated community members to replace these core extensions if LEWT catches on. If things are structured as above, the core extensions tha ship with LEWT can always be changed at a later date.

this extension currently uses some random ruby class to do the stats. it should be improved so that a real analysis can be done.

The Lewt Extensions store which is used for persisting data is a bit sucky. The extract method isn't even implemented!

This is a pretty important extension so it will pay to take the time to do things right.

Tax calculation is currently adhoc and implemented in the extensions themselves. This should be pulled into the LEWT core and a structured method for performing it provided to extensions.

This should basically be a layer on top of Ruby GEMS which searches for GEMS by the keyword lewt_extension. It could be made something like this:

lewt extension-list

> MadBilling: A better billing tool than the default one
> ProductBandit: Import and process product sales through LEWT
> ...

then

lewt extension-install MadBilling

> installing MadBilling extension...

This would setup the extension by doing a regular gem install.

modify ruby's option parser to display extension context info on --help as currently it does not say which extension option flags belong too currently! this would be a good usability improvement (for me as well!).

The extension API could be streamlined and thought out more. It doesn't have to be perfect but this might be a good opportunity to try out the DSL features of ruby.

Whilst I'm not in favour of the instance_eval() which yields a block like API akin to:

Class::new do |c|
  c.title = "xxx"
  c.desciption = File.open("xx.txt")
end

I do like the idea of modifying the core ruby syntax to be a bit more Lewt Extension tailored within the context of a LEWT Extension. For example the options & the command could be set like this:

MyExt < LewtExtension
  options ++ :param { 
                :default => false, 
                :definitions => "what this option is about",
                :type => String
                }
  command :my_command
end

Need a way to generate reports from all calender data.

This issue is kind of related to #23

All the config files i.e. settings.yml, clients.yml, enteprise.yml should be consolidated into a lewt file or something like that.

The file should be a ruby DSL and settings should be specified by setting properties on an object. This way everything can be maintained in one file, and things will look cleaner as settings markup is getting increasingly complicated as with the GEM extension loading conventions...

Using LEWT as a library looks very ugly at the moment in practice. Library mode should be shown some TLC and made more enjoyable to use.

currently OSX is preferences but this needn't be the case.

After some brief investigation it would seem the GPL (v2 specifically) would support this project better than the MIT License.

The MIT License does not require one to release the source code of any modifications made to my version of LEWT. However GPL v2 does!

What is not clear to me is how the GPL would restrict me in terms of how other libraries/software I link to at runtime would impact my project licensing.

This deserves further investigation however I think in general the switch should be made.

Essentially all transaction data is processed from a kind of General Ledger. Store should be upgraded to maintain a copy of this ledger - this ledger will have some extra fields so payment completion etc can be marked.

Currently it is possible to maintain a central ledger but it requires too much CLI interaction to do so.

Pretty self explanatory. The templates should work fully with all of the core extensions, they should use a pretty but minimal default style so they can be easily enhanced.

namespaces are still pretty unorganised especially when viewing via some ruby docgen. Some time should be spent reorganising this

Currently extensions mus be placed in the extensions/ directory to be picked up by LEWT. A method should be added to include extensions packaged as GEMS.

Calling invoice command seems to iterate all clients instead of the one specified.

Lewt Reports doesn't work so well. Some effort should be spent making it better!

There is little to no error handling or type checking in LEWT. This should be worked upon!

Upon nearing the completion of the initial alpha version of LEWT it has become apparent to me that writing the code to do invoicing in order to achieve MY ENDS was not that hard. It CLOC's in at 321 lines of code all in all plus the several modules it uses.

It is now clear that the tool needs to be re-architected with a focus on extensibility and composability.

The UNIX experience is core to the usefulness of the tool to me. I like being able to pipe LEWT's output into ALPINE however some people might want to automate this process. In general LEWT's usefulness lies in being a tool to expose business data. It should be easy to create extensions and hook them into the system.

The system should be designed as an means extracting, processing, and rendering business data into textual data such as reports, invoices, etc. As much of the system should be made to be an extension as possible. These will ship as core extensions however they will be extensions none the less. Thus the system is a minimal runtime for defining the extraction, processing, and rendering of business data and making it generally useful and accessible whilst interacting with other such definitions through design implementation of the UNIX composability principle.

The project (and therefore the code architecture) needs to be setup in a way to support user contribution. LEWT should be able to search/install LEWT extensions via some sort of structured means like a package manager. It should have a command to create a skeleton template for a user extension (much like rails does for controllers).

The LEWT project should ship with some essential core extensions. These may include

• iCal Extractor: for working with apple calendars
• Google Calender Extractor: for working with Goggle Calendars in the cloud
• Expenses Plugin: add support for arbitrary expenses in a bill
• PDF Formatting Plugin: format invoice output as PDF

Apple calender uses iCal however it has a strange dir structure. There seems to be some classes to work with this and they should be used.

glcal api seems to require paging as only a limited subset of the specified date range is every returned [apx. 1month].

• Calender Event Data Extractor - should work with Google Calender, Apple iCalender, and Outlook if possible.
• Invoices - a simple invoicing tool that works with expenses and calender data
• Store - a system for backing up data to file systems in a raw format. Store will also allow users to extract data from previously stored operations.
• Simple Expenses - an expense management tool that works with CSV & Excel files. Very simple, allows billing to clients and plays well with the other core plugins.
• Reports - A reporting tool that works with extracted calender data and defines some standardised reports.
• Meta Log - Allows for the passing of meta data from calender extractions for use with reports.
• Simple Milestones - manage millstone style invoicing.

Some of my clients are complaining about the invoice ID hashes. They are pretty messy admittedly, spend some time thinking of a more useful format.

There needs to be some sort of class hierarchy going on!

Stuff like:

• file inclusion paths
• loaded settings files

Are all universal throughout the system and don't need to be figured out every time.

Furthermore the extensions system is ripe for optimisation through some sort of class system/API. Things could be streamlined A LOT here - this ultimately supports one of LEWT's core goals very strongly:

Make your business data easily scriptable

Name spacing is enough of a problem internally with LEWT as is so some care should be taken to make things sane.

Some test cases need to be written if I want others developers to contribute to this properly. Probably will need to sort out some dummy data for this.

lewt help
this command should display all available extractors, processors and renderes along with some basic information about them

lewt help command
this command should display detailed information about a specific command