Fwd: Debris' Quuve - Technologies used
Locked
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. |
Re: Fwd: Debris' Quuve - Technologies used
|
|
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 <[hidden email]>:
|
Re: Fwd: Debris' Quuve - Technologies used
|
|
In reply to this post by Pharo Smalltalk Users mailing list
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 <[hidden email]> wrote: > > <mime-attachment>
Brad Selfridge
|
Fwd: Fwd: Debris' Quuve - Technologies used
|
|
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 <[hidden email]> 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? |
Re: Fwd: Fwd: Debris' Quuve - Technologies used
|
|
On Apr 15, 2015, at 8:01 PM, Cameron Sanders via Pharo-users <[hidden email]> 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. |
|
|
In reply to this post by Pharo Smalltalk Users mailing list
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. |
Re: Fwd: Fwd: Debris' Quuve - Technologies used
|
|
In reply to this post by Yanni Chiu
Yanni, please find my answers below.
On Thu, Apr 16, 2015 at 10:57 AM, Mariano Martinez Peck <[hidden email]> wrote:
|
Re: [Bulk] Fwd: Fwd: Debris' Quuve - Technologies used
|
|
On Apr 16, 2015, at 10:33 AM, Mariano Martinez Peck <[hidden email]> wrote:
> Yanni, please find my answers below. Mariano, thanks for your detailed answers. Your experience building a CRUD framework using Magritte and Bootstrap was very similar to mine. My stuff is on a back burner for now, but I hope to get back to it sometime soon. I hope Quuve is successful for you guys. |
|
|
In reply to this post by stepharo
+ 10
|
Re: Fwd: Fwd: Debris' Quuve - Technologies used
|
|
In reply to this post by Mariano Martinez Peck
On 16/04/15 16:33, Mariano Martinez Peck wrote:
> 1) We want everything to be ajaxfied (so every single component > needed to be rewritten for AJAX) > 2) We want all our components to use Bootstrap layout In QCMagritte we managed to keep most, using an Ajax-Memento and the chained visitors. > 3) We want components/descriptions/renderes/etc that better fit our > own needs > 4) We needed more hooks Definitely. > We think Magritte was easy enough > to extend as is. Another thing we found is that sometimes is a bit > hard to agree on what is needed for all magritte users. So fully > refactoring Magritte may affect other developers or other use-cases > of Magritte. Yep, fully agree. Stephan |
|
|
Just a remark
I found strange that not a single little improvements of Magritte was necessary for the Qude project. Now if heavy users of open-source libraries do not enhance these open-source libraries and keep their extensions under close source then the open-source libraries will never make progress and I will immensely sad. You know that I like business and that people can make money but the fight is against other community and competetitor and not within Pharo. Stef Le 17/4/15 19:43, Stephan Eggermont a écrit : > On 16/04/15 16:33, Mariano Martinez Peck wrote: >> 1) We want everything to be ajaxfied (so every single component >> needed to be rewritten for AJAX) > > 2) We want all our components to use Bootstrap layout > > In QCMagritte we managed to keep most, using an Ajax-Memento and > the chained visitors. > >> 3) We want components/descriptions/renderes/etc that better fit our >> own needs >> 4) We needed more hooks > > Definitely. > >> We think Magritte was easy enough >> to extend as is. Another thing we found is that sometimes is a bit >> hard to agree on what is needed for all magritte users. So fully >> refactoring Magritte may affect other developers or other use-cases >> of Magritte. > > Yep, fully agree. > > Stephan > > > |
Re: [Bulk] Re: Fwd: Fwd: Debris' Quuve - Technologies used
|
|
On Apr 18, 2015, at 2:18 AM, stepharo <[hidden email]> wrote: > I found strange that not a single little improvements of Magritte was necessary for the Qude project. It’s not strange to me, because when working with Magritte 2, it seemed that almost everything I wanted to do had a hook method to override, or an obvious place to subclass or extend. So much so, that when I could not find the extension point, I thought it was my fault. What was missing was instance-based descriptions, which was added by the community in Magritte 3. Given how well-factored Magritte 2 was, my deduction was that a lot of effort had already been done to extract out an open-source artefact, from whatever system drove it’s development. So, no surprise that few improvements to the core Magritte were needed. > Now if heavy users of open-source libraries do not enhance these open-source libraries and keep their extensions > under close source then the open-source libraries will never make progress and I will immensely sad. Given that Magritte is already well-factored for extensions, what tends to be written is exactly the custom code which you would not be releasing to open-source. However, there might be a case for add-ons, such as Twitter Bootstrap support. As mentioned in another post, changing the Magritte API/interfaces at this point is tricky, because it would affect current users - that’s the conundrum: success and wider adoption will constrain the evolution. The addition of instance-based descriptions was worth the (minor) pain of the transition, but what level of pain would be tolerable to add Bootstrap support, especially if you’re not using Bootstrap. |
|
|
Le 18/4/15 20:04, Yanni Chiu a écrit : > On Apr 18, 2015, at 2:18 AM, stepharo <[hidden email]> wrote: > >> I found strange that not a single little improvements of Magritte was necessary for the Qude project. > It’s not strange to me, because when working with Magritte 2, it seemed that almost everything I wanted to do had a hook method to override, or an obvious place to subclass or extend. So much so, that when I could not find the extension point, I thought it was my fault. What was missing was instance-based descriptions, which was added by the community in Magritte 3. :) > > Given how well-factored Magritte 2 was, my deduction was that a lot of effort had already been done to extract out an open-source artefact, from whatever system drove it’s development. So, no surprise that few improvements to the core Magritte were needed. Ok so we have perfect software. Good to know. >> Now if heavy users of open-source libraries do not enhance these open-source libraries and keep their extensions >> under close source then the open-source libraries will never make progress and I will immensely sad. > Given that Magritte is already well-factored for extensions, what tends to be written is exactly the custom code which you would not be releasing to open-source. but you see I did not use magritte since long time. It would be great to have example of custom-code. For example are relationships any useful. > > However, there might be a case for add-ons, such as Twitter Bootstrap support. As mentioned in another post, changing the Magritte API/interfaces at this point is tricky, because it would affect current users - that’s the conundrum: success and wider adoption will constrain the evolution. We have versions to help there. > The addition of instance-based descriptions was worth the (minor) pain of the transition, but what level of pain would be tolerable to add Bootstrap support, especially if you’re not using Bootstrap. But we are talking about SeasideMagritte here? I do not know because I do not have experience. I was talking about magritte. |
|
|
And BTW I would really like to see how we can do crude with
magritte-described objects. Le 18/4/15 21:37, stepharo a écrit : > > > Le 18/4/15 20:04, Yanni Chiu a écrit : >> On Apr 18, 2015, at 2:18 AM, stepharo <[hidden email]> wrote: >> >>> I found strange that not a single little improvements of Magritte >>> was necessary for the Qude project. >> It’s not strange to me, because when working with Magritte 2, it >> seemed that almost everything I wanted to do had a hook method to >> override, or an obvious place to subclass or extend. So much so, that >> when I could not find the extension point, I thought it was my fault. >> What was missing was instance-based descriptions, which was added by >> the community in Magritte 3. > > :) > >> >> Given how well-factored Magritte 2 was, my deduction was that a lot >> of effort had already been done to extract out an open-source >> artefact, from whatever system drove it’s development. So, no >> surprise that few improvements to the core Magritte were needed. > > Ok so we have perfect software. Good to know. >>> Now if heavy users of open-source libraries do not enhance these >>> open-source libraries and keep their extensions >>> under close source then the open-source libraries will never make >>> progress and I will immensely sad. >> Given that Magritte is already well-factored for extensions, what >> tends to be written is exactly the custom code which you would not be >> releasing to open-source. > > but you see I did not use magritte since long time. It would be great > to have example of custom-code. > For example are relationships any useful. >> >> However, there might be a case for add-ons, such as Twitter Bootstrap >> support. As mentioned in another post, changing the Magritte >> API/interfaces at this point is tricky, because it would affect >> current users - that’s the conundrum: success and wider adoption will >> constrain the evolution. > We have versions to help there. > >> The addition of instance-based descriptions was worth the (minor) >> pain of the transition, but what level of pain would be tolerable to >> add Bootstrap support, especially if you’re not using Bootstrap. > But we are talking about SeasideMagritte here? > I do not know because I do not have experience. > I was talking about magritte. > > > > |
Re: [Bulk] Re: Fwd: Fwd: Debris' Quuve - Technologies used
|
|
Hi Stef, Similar to what Yanni said, 99% of our extensions are to Magritte-Seaside, not to magritte core itself. I honestly see Magritte as a very small and super extensible framework from which you can build your own on top of it. Like QCMagritte. Or likely what Yanni did, or likely what we did. That is...a set of subclasses/extensions to Magritte Seaside. This doesn't mean we shouldn't make this open-source, but I am just saying all our extensions should not be Magritte core code but kind of a framework build on top of Magritte core. Just to give you an idea of the extensibility of Magritte... is that with all our framework build on top of Magritte, we had NO OVERRIDE and our classes/extensions load cleanly after loading Magritte. Cheers, On Sat, Apr 18, 2015 at 4:55 PM, stepharo <[hidden email]> wrote: And BTW I would really like to see how we can do crude with magritte-described objects. |
|
|
Le 21/4/15 18:26, Mariano Martinez Peck
a écrit :
Ok I trust you. So this is good. Now I do not know how to do crud applications with magritte.
|
Re: [Bulk] Re: Fwd: Fwd: Debris' Quuve - Technologies used
|
|
Magritte could be improved to allow a context of usage to be specified e.g. #tableReport, or #editor, and then allow class designers to specify the pairs of keys for CSS style to be written for the context. We'll follow up on this point soon.
Seaside could accept more renderingBlocks to be more customizable. And/or Magritte descriptions should allow these to be passed down. But where does one draw the line? Like the above paragraph on CSS, different contexts demand different rendering blocks. So in fact, we pull together our Magritte descriptions in non-standard ways for our most important view: the portfolio browser. Many are created dynamically from accounting terms in a DB, because there are thousands of possible rules/equations, and they cannot all be hand-coded for this one class. - In our application, Magritte provides a mechanism to describe the attributes (or computed terms) in order to paint an editor, a read-only view, and/or table presentation/edit dialogs. For complex specification and controller classes, we often still need to write dedicated Components. We do not use Magritte for persistence, instead we use a variant of DebrisDB that works on Gemstone & Pharo. So our CRUD solution involves our own tables (seaside subclasses) that allow us to install blocks to implement various behaviors such as "update table from DB". We also allow application-level "plugin" rules to be presented as buttons and controls, but these are very specific to our whole framework. The launching of these tables is handled through various of our own constructs, specifically our ApplicationContext, which knows where to put new panes/components, for example. Much of the speed with which we can define a new class, have it persistent (no time using DebrisDB), and have editors/presenters (perhaps 1 to 15 minutes per instVar for simple classes), is due to the culmination of various tools in our environment and our experience with such. -Cam On Tue, Apr 21, 2015 at 2:55 PM, stepharo <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |