Re: [Pharo-users] Thinking aloud about project at hand

[Cameron Sanders via Pharo-users]

--- Begin Message ---

If you use Quuve, local data on Pharo is stored in Fuel files. There are
tools to export these to SIXX format in the web-app Admin tools - that's
how we migrated data back and forth between Gemstone and Pharo. The admin
tools allow exporting parts or full, DB, incremental import or replacement;
as well, one can keep around deleted records. Important thing to remember
is that Fuel stores the object graph, so be clear about cross-DB access by
reference.

Again, the warning: full app is a serious app with levels of abstraction.
-cam

On Wed, Apr 15, 2020 at 6:42 PM Cameron Sanders <camsand...@aol.com> wrote:

> Yes, See the overview video at youtube (
> https://www.youtube.com/watch?v=sraCv1VwJzQ&t=233s). It has a lot of
> support tools to grab time-series data from FRED or World Bank, even if you
> don't want to use the full web app. The framework for multi-user handles
> DB's and is lightweight in practice. If you think you will go web, to
> gemstone, or multi-users, there are advantages.
>
> To use full app, the warnings are:
>
>    1. uses HighCharts for display, which you would need a developer
>    license for - i guess, and I don't know configuration mess as Quuve last
>    ran on Pharo 6.x
>    2. there is a little directory structure with a few start-up files you
>    need to copy into place (under your root directory)
>    3. Many powerful financial rules were made easiest to use via this
>    full app, as there are "pattern methods" that expand (creating concrete
>    methods) to allow access to FRED and WorldBank as if each series were coded
>    as a method
>
>
> To simply use some of the toolkit from the "FA" package, which are general
> "functional analyst" tools, not involving GUI stuff, nor requiring much app
> framework, you can do the following to get CME crude prices front-month
> (CL1). Looks like they provide full FRED data access... but ... I know we
> provided tools to go directly to FRED and WorldBank too - i'd have to
> relearn how! (Been a few years.)
>
> |q |
> q := *FaQuandlDownloader* new  "#initialize method has an
> authorizationToken based on Debri's old account. When using the full
> application, the runtime uses specs for these to be created, and those
> specs are stored in DB's, at app-level, site-level, or user-level, allowing
> users to have extended subscriptions (from base app). We no longer have
> subscriptions, only a base account - and w*e get in trouble if you draw
> too much data like this*. *Please create your own account and change
> #initialize method.* "
> dataSourceSpec: 'SCF/';
> series: 'CL1' for: 'CME' withPeriodSuffix: 'FN';
> yourself.
> q fetch.
> q answerAsTable "returns FaTableAccess which allows string-indexed lookups
> or numbered index"
>
> ... my memory is you can extract that data as a FaDatedSeries too...
> mmm... i'd have to look.
>
> Good luck, let me know if you have questions.
> -cam
>
> --
> last loading I did went something like this...
> Metacello new
>     configuration: 'Seaside3';
>     repository: '
> http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
>  version: '3.2.4';
>  load: #('Core' 'Zinc-Seaside' 'Javascript' 'JQuery' 'JSON' 'Email');
>     lock.
>
>
> Gofer it
> url: 'http://smalltalkhub.com/mc/Debris/Quuve/main'
> username: monticelloUsername
> password: monticelloPassword;
>  package: 'ConfigurationOfQuuve';
> load.
>
>
> Metacello new
> configuration: 'Quuve';
> smalltalkhubUser: 'Debris' project: 'Quuve';
> version: '1.9';
> onLock: [ :ex | ex honor ];
> load: #('Core' 'DPOFX' 'DebrisREST').
> ---
>
>
> On Fri, Apr 10, 2020 at 4:57 AM Tim Mackinnon <tim@testit.works> wrote:
>
>> Wasn’t there a recent financial app in Pharo that was made open source...
>> there might be many ideas in it, and possibly a starting point.
>>
>> It’s in the success pages of pharo: Quuve, there are posts from Mariano
>> about what tech they used too
>>
>> Tim
>>
>> > On 10 Apr 2020, at 09:13, "teso...@gmail.com" <teso...@gmail.com>
>> wrote:
>> >
>> > Hi Tomaz,
>> >
>> > From the comments about the requirements you do I suggest:
>> >
>> > - For data storage, my recommendation goes depending on two factors:
>> > 1)Installation complexity, 2) volume of data. These are two variables
>> > that will be against one and the other. I will recommend to use
>> > MongoDB + Voyage, that goes very well. It grows excellent with the
>> > amount of data, it has really cool integration with Pharo and Voyage
>> > is an excellent mapping tool; also it is a mature solution and it has
>> > a lot of support for back-up schemes and solutions. Using MongoDB
>> > complicates the installation process, so if you have the idea of a
>> > easy installable application maybe SQLlite is a good alternative.
>> >
>> > - I think using Spec2 + GTK + Roassal3 + Polymath is a good idea.
>> > Check that Spec2 and Roassal3 are still under heavy development. They
>> > are getting much better, but of course, it will take some time to
>> > stabilize; but both of them are progressing very fast and they are
>> > already quite stable.
>> >
>> > - For developing DSL and interactive programming for non-programmers
>> > users, Pharo is ideal. It presents a lot of tools to easily develop
>> > DSL and the UI to make them work excellent. The idea of live
>> > manipulation of objects and inspection of all the instances can be
>> > easily added to a DSL.
>> >
>> > Thanks for your attention!
>> >
>> >> On Thu, Apr 9, 2020 at 9:13 PM Tomaž Turk <tomaz.t...@ef.uni-lj.si>
>> wrote:
>> >>
>> >> Dear all,
>> >>
>> >> I'm thinking about implementing a software solution in Pharo (as one
>> of the candidate environments), it's a project that I'm dealing with
>> professionally. The goal is to develop a financial planning/simulation
>> application on the country level, which is at present developed as a set of
>> interrelated Excel spreadsheets. The requirement is that the solution
>> should be more "manageable", resilient and straightforward than Excel
>> permits, that it should present a workflow to the user - i.e. , that the
>> tasks the user should do are suggested through the GUI.
>> >>
>> >> The majority of the data is in a form of a time series (for instance:
>> GDP for a series of years). There are many variables in the model which
>> shoud be calculated from other variables, year by year. There are also
>> lagged variables (the value for the current year depends from the value of
>> previous year), and running averages. There are also some variables which
>> are not time series (parameters). As a part of GUI, there is a need to
>> present the results as diagrams, too (scatterplots, line charts), otherwise
>> tables are the output.
>> >>
>> >> I found Pharo to be a very elegant language and environment, with
>> version 8.0 it became pretty stable, however I don't have any experiences
>> in building software solutions of this type in Smalltalk. In other words,
>> I'd like to be more confident in setting the architecture, both in the
>> sense of the model content (variables interrelation) and the architecture
>> of classes. Besides, for the calculated variables I'd like to have a
>> relatively simple syntax to define them (like 'GDPpC <- GDP / Population').
>> >>
>> >> My thoughts and questions:
>> >> - for easier maintenance I'd like to separate the data from the code -
>> so the question is what would be the best way to implement persistence
>> (another Pharo image  - with what?, some relational database, XML/JSON,
>> flat files ..)
>> >> - I wonder what would be the best "architecture" of classes - so, we
>> have a lot of aggregate variables like GDP and population, which can be
>> grouped at least according to the stage in the planning workflow. There are
>> also resulting (calculated) variables (e.g. GDP per capita). On the other
>> hand, since this is a planning software, it's a kind of simulation, where
>> we have a "data warehouse", experiments and results
>> >> - As a core packages I would use Spec2, Roassal, and PolyMath.
>> >>
>> >> I'm just thinking aloud, and would greatly appreciate any thoughts
>> from experienced Pharoers  :-)
>> >>
>> >> Best wishes,
>> >> Tomaz
>> >
>> >
>> >
>> > --
>> > Pablo Tesone.
>> > teso...@gmail.com
>> >
>>
>>
>>

--- End Message ---