[Pharo-users] Lawsuit Tracker app

Esteban Lorenzano estebanlm at gmail.com
Sun Jan 3 06:41:39 EST 2016

well, correct link is: http://smallworks.eu/web/projects/lawsuitTracker <http://smallworks.eu/web/projects/lawsuitTracker>

I made that app in one month work (just before coming to work in pharo). 

in one month I managed to: 

- create Voyage (there was nothing before, and MongoTalk driver was just an experiment not really finished… so I needed to finish also the driver… for putting an example reading was so slow that after a couple of tweaks a managed to transform a 1s query into a 10ms query… just to give you a hint)
- tweak glamour to provide better user interactions (often mixing glamour+magritte+glamour inside magritte+more magritte… :)
- wrap a PDF library (bah, finish a wrapper that already existed, in fact), and a generic “report tool” who of course use magritte
- create a custom query language “lawyer apt” (they don’t know about sql or databases :P) using petit parser 
- and learn how to close the image, so an user can have a desktop app without seeing a debugger or a class browser if something happened (errors where directly reported by me using fuel, in the first iteration mariano made, when he was still doing his phd and fuel was still an experimental tool)

the application is still in use (by 20+ lawyers in two offices of the same law firm) and they just call me one time in 5 years, and that was because they screw the mongodb installation, not a problem of the application.

Can I say I’m pretty proud of that thingy? :)

The main point is that using anything else (I worked in “java world” for 12 years before jumping to Pharo, so I know very well what I’m talking about) I would take no less than 4 months on doing the same… using Pharo and their libraries I managed to do it in one month AND to create something valuable for the community. 

I would say both glamour and magritte are still fundamental if you want to provide a desktop application… even if you have to spend time learning them.

Now, about performance, that’s something always annoys me: people believing this will have a problem before actually having it… people believing they will need numbers they do not need. 
A language like squeak was very capable of having croquet, and a company like this one http://www.3dicc.com <http://www.3dicc.com/> use them to build virtual words and they are very successful. True, they are not second life, and they have some escalation issues, but they manage it pretty well… 
Even high availability games like eveonline are made using python (and not the scripting parts, the full game) and they are capable to handle battles of 3k users in a single instance… 

You think you need better performance than them? Most probably not… but even if you need it, I think you are missing the path: you use Pharo and if it happens performance is not enough, then you profile and optimise, probably using some external library: we have FFI and if that is not enough you can always do your own plugins… at the end, that’s what those guys do :)

I think is a lot more efficient (and agile) way to create an application… in the worst case, you can spend the time you save using Pharo on optimising your solution interfacing with C or whatever. At the end, you will have an application that is a lot more maintainable than using C or C++ as main language. 


> On 02 Jan 2016, at 22:51, Saša Janiška <gour at atmarama.com> wrote:
> Hello,
> I'm looking how to build GUI app with Pharo and today found out
> screenshot of Lawsuit Tracker (http://smallworks.eu/web/projects/lawsuit
> Tracker) which very much resembles 'typical' desktop/business
> application. The web site says: "It is made using Pharo, Glamour,
> Magritte and MongoDB." and in my case I'd replace MongoDB with Sqlite3,
> have need for more grpahical output - something like:
> http://saravali.de/screenshots.html
> but wonder about other components and whether they (Glamour/Magritte)
> are still relevant *today* ?
> Otoh, today I was re-reading some stuff about Julia language which looks
> as fine langauge, but it does not fit on one psotcard, although it
> provides more "classical" way of developing: editor+REPL along with
> Gtk(.jl) bindings.
> The language does perform very well, iow. it's quite fast which is good
> for my project, but it's a bit cumbersome since there is no support to
> compile end application, while it looks that Pharo has advantage here
> providing smoother way of deployment (multi-platform wise).
> Any hint?
> -- 
> Even if you are considered to be the most sinful of all sinners, 
> when you are situated in the boat of transcendental knowledge 
> you will be able to cross over the ocean of miseries.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160103/f18ba5c9/attachment.html>

More information about the Pharo-users mailing list