April 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Fwd: Debris' Quuve - Technologies used
by stepharo April 17, 2015

April 17, 2015

If one day you think that this part can be shared it would be great because it could bring business around your techno Le 16/4/15 08:10, Cameron Sanders via Pharo-users a Ã©crit : > We have a full-featured CRUD system based on Magritte. Actually, we > have extended Magritte so much that all our descriptions and > components are actually subclasses of the original Magritte classes. > We have our own descriptions, components, report column classes, > mementos, table layouts, etc. All our framework is Twitter Bootstrap > integrated, fully AJAX and with lots of rich features. We can make a > full CRUD report/form out of Magritte descriptions in no time.

2 1

JavaLoader
by Julien Delplanque April 17, 2015

April 17, 2015

Hi, I saw this repository on smalltalkhub: http://smalltalkhub.com/#!/~blabux/JavaLoader/ and I wonder if someone could give me some examples of use. For example, is it possible to use JavaLoader with Roassal to display class hierarchy of a java project or something like that? I browsed google and the mailing list's archives but didn't found any doc/examples... Maybe I'm not searching in the right place? :) Thanks in advance, Julien

3 10

time library?
by Tudor Girba April 16, 2015

April 16, 2015

Hi, I am looking for a library that deals with time. Specifically, I am looking for things like: - The concept of Period (not duration) that models an absolute time period - Scripting possibilities like: 16 April, 2015 @ (3 pm + 15 minutes) Do you know any effort in this direction? Doru -- www.tudorgirba.com "Every thing has its own flow"

3 5

Class comments rendered in Nautilus (through Pillar)
by Damien Cassou April 16, 2015

April 16, 2015

Hi, Kasper Ãsterbye has just finished a proof-of-concept that renders Pillar text inside a class comment pane. >From the view, the developer can press $ (dollar) to edit the document in Pillar. Best regards, -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

2 1

[FUN] [OUT OF TOPIC] Lighthouse in their way ;-)
by Luc Fabresse April 16, 2015

April 16, 2015

https://www.youtube.com/watch?v=_VHXRYXzEVU Enjoy, #Luc

1 0

Re: [Pharo-users] Fwd: Fwd: Debris' Quuve - Technologies used
by Yanni Chiu April 16, 2015

April 16, 2015

On Apr 15, 2015, at 8:01 PM, Cameron Sanders via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Sure, I am happy to share. We are to the point that we need to get people interested in this platform; one thing we offer is a source license and therefore we need to document things that we have not yet documented. > > So please, fire away any questions. Are there any instances of Magritte framework that are not an instances of a custom subclass? (Did you have to subclass everything?) What pushed you toward custom subclasses? Was the properties dictionary not sufficient for extending the object state variables, or was it a speed/performance issue? Would refactoring the Magritte classes to have various hook methods allowed you to avoid making custom subclasses? (I found that it was Twitter Bootstrap which drove the need for subclassing the framework, whereas native HTML would have been adaptable to Magritteâs needs). Did you use the OneToOne and OneToMany relationship descriptions by subclassing, or did you create entirely new ones? What are some statistics on your model - e.g. number to classes? average (mean/median/mode) number of attributes/methods per class? average depth of the class hierarchy? Do you translate/map the âSmalltalkâ query blocks for GemStone to get better speed, or is this unnecessary? Do you use Magritte descriptions to tag things for indexing on GemStone? Or, do you just manually create indexes on GemStone as necessary (e.g. via install code that encapsulates knowledge of where to index, or does the system automatically raise flags when indexing is needed). >From various postings, I gather you have a lot of data to process. Do you have any numbers like: - total number of objects in the system - biggest collection, typical collection size Thanks for sharing your experience.

1 0

Fwd: [Pharo-users] Fwd: Debris' Quuve - Technologies used
by Cameron Sanders April 16, 2015

April 16, 2015

Sure, I am happy to share. We are to the point that we need to get people interested in this platform; one thing we offer is a source license and therefore we need to document things that we have not yet documented. So please, fire away any questions. -Cam On Wed, Apr 15, 2015 at 5:59 PM, Brad <bsselfridge(a)gmail.com> wrote: > I'd love to know more about your architecture. It seems like you've built > an architecture very similar to what I've dreamed of building. Is there any > possibility of asking questions or of you providing examples of some of the > features from time to time? > > Brad Selfridge > 913-269-2385 > > > On Apr 15, 2015, at 4:30 PM, Cameron Sanders via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > > > > <mime-attachment> >

1 0

Re: [Pharo-users] Fwd: Debris' Quuve - Technologies used
by Brad April 15, 2015

April 15, 2015

I'd love to know more about your architecture. It seems like you've built an architecture very similar to what I've dreamed of building. Is there any possibility of asking questions or of you providing examples of some of the features from time to time? Brad Selfridge 913-269-2385 > On Apr 15, 2015, at 4:30 PM, Cameron Sanders via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > <mime-attachment>

1 0

Re: [Pharo-users] Fwd: Debris' Quuve - Technologies used
by Luc Fabresse April 15, 2015

April 15, 2015

Hi, Thanks for this email. It is really nice to read that all these frameworks are used in yet another successful commercial app such as Quuve. Best, #Luc 2015-04-15 23:30 GMT+02:00 Cameron Sanders via Pharo-users < pharo-users(a)lists.pharo.org>: > > > ---------- Message transfÃ©rÃ© ---------- > From: Cameron Sanders <camsanders(a)aol.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Date: Wed, 15 Apr 2015 17:30:24 -0400 > Subject: Fwd: Debris' Quuve - Technologies used > Several people inquired as to how Quuve was built. Mariano wrote up a nice > description of the various tools that were used to build Quuve -- see > below. Note also that DebrisPublishing.com website is now up; we are still > working on videos, but the site is very lean at present. > > -Cam > > Quuve Technologies Used > > Quuve has been and still is developed with Pharo. We try to use the most > up to date stable version of Pharo. Quuve is deployed in GemStone. > > Package dependencies are managed via Metacello. Not only do we have many > dependencies but also multiple Smalltalk environments: Pharo and GemStone. > We also use Metacello to correctly load the needed packages and versions > for each of the platforms. > > We use Seaside as our web framework and Twitter Bootstrap for Seaside for > the layout and design of the app. While some parts are still using the > full-request approach, most of the app is done with AJAX and only > refreshing the needed part of the screen. > > We use JQuery a lot and some external JS libraries such a DataTables (for > our table/reports), floatThead, HighCharts (for making charts), TinyMCE (to > edit notes and a few other things), etc. > > We have a full-featured CRUD system based on Magritte. Actually, we have > extended Magritte so much that all our descriptions and components are > actually subclasses of the original Magritte classes. We have our own > descriptions, components, report column classes, mementos, table layouts, > etc. All our framework is Twitter Bootstrap integrated, fully AJAX and with > lots of rich features. We can make a full CRUD report/form out of Magritte > descriptions in no time. > > For persistency we have a library/layer which gives a unified way of > saving and querying objects using a Glorp-like interface; it differs in > that the where clauses are straight Smalltalk blocks. So far, when we work > on Pharo we use Fuel as the "database", while for production we use > GemStone. We have developed some compatibility packages so that same code > would work in both Smalltalks in the way we expect. Quuve briefly used > Oracleâs relational DB for persistence of its securities DB, connecting to > it via the Glorp toolkit; because many mature financial DBâs are delivered > in relational form, we may need to do so more extensively in the future. > Although the need for this may subside as more data becomes available over > REST-server interfaces. > > We use NeoCSV for parsing CSV, XMLParser, Zinc-REST and STON for providing > REST web services, and SIXX for moving data between Pharo and GemStone. > > As to the web server, in Pharo we use Zinc, and in GemStone we use nginx + > FastCGI. Quuve clients could be for example, an individual or a large > advisory firm. In each case, Quuve is deployed as a "site/instance" for > each customer. Each site is a fully isolated and secured instance of Quuve. > > Quuve is hosted in a cloud virtual hosting which allows us to scale as > much as we need and we can have as many nodes as required. The operating > system is CentOS Linux. We correctly perform backups, cleanings and > maintenance of our sites. We have scripts to automatically create new sites > very easily. > > >

1 0

Fwd: Debris' Quuve - Technologies used
by Cameron Sanders April 15, 2015

April 15, 2015

Several people inquired as to how Quuve was built. Mariano wrote up a nice description of the various tools that were used to build Quuve -- see below. Note also that DebrisPublishing.com website is now up; we are still working on videos, but the site is very lean at present. -Cam Quuve Technologies Used Quuve has been and still is developed with Pharo. We try to use the most up to date stable version of Pharo. Quuve is deployed in GemStone. Package dependencies are managed via Metacello. Not only do we have many dependencies but also multiple Smalltalk environments: Pharo and GemStone. We also use Metacello to correctly load the needed packages and versions for each of the platforms. We use Seaside as our web framework and Twitter Bootstrap for Seaside for the layout and design of the app. While some parts are still using the full-request approach, most of the app is done with AJAX and only refreshing the needed part of the screen. We use JQuery a lot and some external JS libraries such a DataTables (for our table/reports), floatThead, HighCharts (for making charts), TinyMCE (to edit notes and a few other things), etc. We have a full-featured CRUD system based on Magritte. Actually, we have extended Magritte so much that all our descriptions and components are actually subclasses of the original Magritte classes. We have our own descriptions, components, report column classes, mementos, table layouts, etc. All our framework is Twitter Bootstrap integrated, fully AJAX and with lots of rich features. We can make a full CRUD report/form out of Magritte descriptions in no time. For persistency we have a library/layer which gives a unified way of saving and querying objects using a Glorp-like interface; it differs in that the where clauses are straight Smalltalk blocks. So far, when we work on Pharo we use Fuel as the "database", while for production we use GemStone. We have developed some compatibility packages so that same code would work in both Smalltalks in the way we expect. Quuve briefly used Oracleâs relational DB for persistence of its securities DB, connecting to it via the Glorp toolkit; because many mature financial DBâs are delivered in relational form, we may need to do so more extensively in the future. Although the need for this may subside as more data becomes available over REST-server interfaces. We use NeoCSV for parsing CSV, XMLParser, Zinc-REST and STON for providing REST web services, and SIXX for moving data between Pharo and GemStone. As to the web server, in Pharo we use Zinc, and in GemStone we use nginx + FastCGI. Quuve clients could be for example, an individual or a large advisory firm. In each case, Quuve is deployed as a "site/instance" for each customer. Each site is a fully isolated and secured instance of Quuve. Quuve is hosted in a cloud virtual hosting which allows us to scale as much as we need and we can have as many nodes as required. The operating system is CentOS Linux. We correctly perform backups, cleanings and maintenance of our sites. We have scripts to automatically create new sites very easily.

1 0