[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[jtuc...@objektfabrik.de]

Am 06.10.20 um 22:41 schrieb Tim Mackinnon:

Gosh - this is proving much more interesting than I had imagined, and I’m 
getting lots of useful input, so I double appreciate the time and thoughts from 
everyone.

I probably should have said that my "super awesome idea" is just a little 
flashcard spelling app for my daughter (and possibly a few friends in her class) - so 
probably SimplePersistance will do in this case,


yes, sounds like it. You mentioned it is not a super-complex 30-year 
project you are planning. It sounds like you can load all the data into 
memory in a few msec and just go form there, Saving the whole model as a 
file also sounds like perfectly doable in such a project. So, heck, you 
could probably simply just save the image and be good. A chunk of JSON, 
Fuel, whatever object serialization is probably second best.


The great thing about this: nothing external (to the image) to install 
or maintain. It is just you and the file system.




however the comments about making a persistence decision at the right moment 
are super interesting - and as always, its about spotting the right moment to 
do that…


Oh no, don't fear this too much. That's not what I wanted to point out. 
Most projects will do well on either NoSQL or using an ORM or an OODB. 
Almost anything is possible on all of them. We do boring business stuff 
(accounting) using Glorp as an ORM and DB2. Another well-known project 
in the Pharo world does something extremely similar (travel cost) with 
Voyage/Mongo. It is not so much a question of lost opportunities. The 
problem here is that you have to deal with the very same problems 
(concurrent access and isolation, fast lookups, caching, ghost objects) 
on each of these technologies, but differently. It is the different 
approaches to the same problems that make switching from one to the 
other that makes the decision so hard.


Example: we had a hard time finding out why some objects never went away 
although we had deleted them from the database. It took a while of 
logging all SQL statements until we found out first that they were 
really deleted in the Transaction when the user clicked OK. But they 
were inserted back in the next, possibly completely unrelated, 
transaction, because we had some dangling backpointers that tricked 
glorp into thinking "oops, there is this bunch of new objects I have to 
insert now". This is why I used object deletion as an example. Smalltalk 
has no concept of deleting an object. Databases do. So whatever approach 
you chose, deleting an object looks different. You either make the 
object completely (!) unreachable from the rest of the object model and 
thus just make it irrelevant, or you tell the databse to just throw it 
away. Sounds like no big deal. But it can be.





and ideally you have well factored code with ample tests that help you easily 
move from the idea, to something more scalable or robust…
The hard part here: the example with the reinserted objects is what is 
called an unknown unknown in the boringtech site ;-) You would need a 
test to check whether an object you deleted really isn't reoccuring 
after the next Transaction. You'd have to imagine that there might be a 
small chance that you delete an object successfully, but for some reason 
you distorted the ORMs internal bookkeeping and trocked it into 
inserting teh object back in some consecutive Transaction. A simple fact 
once you understood why it happened, but I am 99% sure almost nobody 
would come around the corner and say: well, we'll have to write a test 
for this scenario where an object still lingers somewhere and gets 
reinserted. The whole team would by this guy a beer and move to another 
table.

however, move too soon and you get bogged down with the details and you lose 
site of an MVP.


move and live with your decision. Or be prepared for a much more 
complicated transition than you thought.


The problem is that nobody (at least that I am aware of) has come up 
with an abstraction good enough to make the persistence implications 
irrelevant enough and provide good performance and feature richness at 
the same time. I know it's been tried.





It has been interesting hearing peoples thoughts on all of this… the turning 
tide on ORM’s, the potential sweet allure of a NoSql (but can you query it 
easily) - and then the overarching element of just setting this shit up (where 
hopefully Docker steps in to make that bit at least easy).
Not sure about the need for Docker. You just throw more tech at the 
problem. I mean, installing and setting up PostgreSQL or MySQL on a 
Linux distro these days is matter of a few commands. apt install, enter 
a db administrator password, answer a few questions and go. Same with 
Mongo or CouchDB.

I suppose this is where the Rails scaffolding was/is? such a jumpstart,


Don't get me started ;-)

Scaffolding is great if you need to sell a technology to management on a 
few slides. Slip in some comment like "works on 

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[Pierce Ng]

On Tue, Oct 06, 2020 at 09:41:21PM +0100, Tim Mackinnon wrote:
> Anyway, that login screen… oh crap I have to write one of those…

For Seaside, there is TF-Login. And oh, it rolled its own file-based
versioning object persistence.

Version that I ported to Pharo 7 and Seaside 3.3:

- https://github.com/PierceNg/TF-Login/tree/pharo7

Feature branch for better security:

- https://github.com/PierceNg/TF-Login/tree/password

Some of the classes are too tightly coupled IMO. Also I'm tending
towards an API-first approach, which needs OAuth2 and OpenID Connect,
meaning either more pieces to integrate or totally not using this.

Pierce

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[Offray Vladimir Luna Cárdenas]

Hi,

I have been using STON and Fossil for persistance and I'm pretty happy
with this combination as a future proof, simple and even reproducible
solution for my storage needs, including web hosting.

For example, for our last project about IndieWeb with pocket
infrastructures[1], a STON powered Grafoscopio[2] notebook[2a] describes
the computations in Brea[3] that create the web site at [1], everything
else are just plain markdown files with YAML metadata blocks[3a] and
mustache templates[4] that combined create the HTML files. Maybe this
combination is too "static web site" oriented, but now that you are
looking for a panoramic view on persistence, could be helpful to put
this in the radar.

[1] https://mutabit.com/repos.fossil/indieweb/
[2] https://mutabit.com/grafoscopio/en.html
[2a]
https://mutabit.com/repos.fossil/indieweb/file?name=indieweb.ston=trunk
[3a]
https://mutabit.com/repos.fossil/indieweb/tree?ci=trunk=tree=docs/es
[3] https://mutabit.com/repos.fossil/brea/
[4]
https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/pagina.mus.html

All my projects are run in a 5 USD Digital Ocean instance. I have not
need for anything else, as computing, when necessary, is distributed in
the desktops of the users that install and run Grafoscopio and Brea. The
server only synchronizes and stores files via Fossil repositories.

Cheers,

Offray

On 6/10/20 3:41 p. m., Tim Mackinnon wrote:
> Gosh - this is proving much more interesting than I had imagined, and I’m 
> getting lots of useful input, so I double appreciate the time and thoughts 
> from everyone.
>
> I probably should have said that my "super awesome idea" is just a little 
> flashcard spelling app for my daughter (and possibly a few friends in her 
> class) - so probably SimplePersistance will do in this case, however the 
> comments about making a persistence decision at the right moment are super 
> interesting - and as always, its about spotting the right moment to do that… 
> and ideally you have well factored code with ample tests that help you easily 
> move from the idea, to something more scalable or robust… however, move too 
> soon and you get bogged down with the details and you lose site of an MVP.
>
> It has been interesting hearing peoples thoughts on all of this… the turning 
> tide on ORM’s, the potential sweet allure of a NoSql (but can you query it 
> easily) - and then the overarching element of just setting this shit up 
> (where hopefully Docker steps in to make that bit at least easy). I suppose 
> this is where the Rails scaffolding was/is? such a jumpstart, you can get a 
> full thing going quite easily, and deploying seems relatively easy too… for 
> us in Smalltalk land, its still a bit too much work for my liking, compared 
> to the ease of getting an image and coding, and seeing it all work. It does 
> seem to be getting marginally better at least, but I do wish there was super 
> easy setup with all the pieces nicely in place so it was just your idea that 
> you could focus on…
>
> Anyway, that login screen… oh crap I have to write one of those…
>
> Tim
>
>> On 6 Oct 2020, at 20:56, jtuc...@objektfabrik.de wrote:
>>
>> Sean,
>>
>> thanks for your short overview of what SimplePersistence does. Sounds useful 
>> for quite a few scenarios and might even carry you well through production 
>> stages for some projects.
>> What I was talking about is also not meant to frustrate people. I've only 
>> played with Mongo/Voyage for a few hours and I must say I was blown away by 
>> the speed and ease of that stack. We got something running in a few hours 
>> and it was impressive. So Mongo/Voyage is a cool thing to use.
>>
>> I always wanted to use Magna on Pharo. I even started to implement my own 
>> little clone of Magna in VA Smalltalk. I got into troubles when I tried to 
>> nest transactions and get this concurrency stuff streamlined somehow. We all 
>> know that besides naming and one-off problems, caching and concurreny are 
>> the hardest problems in computing. I think there is something about this. 
>> And so I gave up on that project... ;-)
>>
>> In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a 
>> very solid state somewhere between complete despair and freaking out about 
>> how cool things are. I love and hate that stack from the bottom of my heart.
>>
>> The cool thing about an RDB is (and will sure be for quite a while) three 
>> letters. S, Q and L. There are lots of highly sophisticated GUI tools to 
>> query, manage, correct your data. And you can simply do everything form a 
>> command prompt, in an ssh session from your smartphone in a hotel toilet on 
>> the other side of the planet.
>>
>> Sure, using pure Smalltalk objects and not worry about n:m relationships, 
>> not having to write mappings and not having to end up with an object model 
>> that is driven mostly by what your O/R mapper can handle, sound great. And 
>> it is. Until you realize you also need to think about query 

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[Offray Vladimir Luna Cárdenas]

On 6/10/20 2:25 p. m., jtuc...@objektfabrik.de wrote:
>>> - Choose Boring Technology - http://boringtechnology.club/
>> This made my day. Thank you :-)
>
> Had never heard of this guy, but his site feels like home to me. Makes
> me a proud user of Smalltalk and DB2 after 25+ years ;-)
>
> He forgot to mention that boring technology can be quite interesting
> and cool, even if it is about to turn 50 years... And he's absolutely
> right about the fact that shipiing something useful for users makes
> you much more happy (and busy) than shipping something on top of an
> incredibly complicated and bloated technology stack...
>
Unfortunately software tech industry is co-opted by hype, trends and big
numbers. In that sense, Pharo or Fossil or technology that doesn't fit
that trio seems non boring for those used to evaluate safeness there. In
my hackerspace the ones used to more popular tech look at Pharo as too
strange (risky?), but those who don't have any preconception, mainly
non-programmers (by education or trade) have no problem accepting Pharo,
Fossil and more simple and agile technologies.

We deliver value swiftly from the margins, without being trapped by hype
o big numbers. I wonder how this organic, resilient and innovative
growth can be more visible, despite of being so far away of the usual
places where most tech related individuals, communities and investors
look for.

Offray

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[Tim Mackinnon]

Oh.. and blimey , look what I just found in my spam bucket “they are watching 
me… “ - >

 "We are excited to announce the General Availability of DigitalOcean App 
Platform , a 
reimagined platform as a service (PaaS) that makes it much simpler and faster 
to build, deploy, and scale apps. App Platform does the heavy lifting of 
managing infrastructure, app runtimes, and dependencies – so you can focus on 
what matters the most: building awesome apps.”

Possibly with its Docker support, perhaps Pharo might slot it, and they take 
care of everything for me… well here’s hoping right?

Tim

> On 6 Oct 2020, at 21:41, Tim Mackinnon  wrote:
> 
> Gosh - this is proving much more interesting than I had imagined, and I’m 
> getting lots of useful input, so I double appreciate the time and thoughts 
> from everyone.
> 
> I probably should have said that my "super awesome idea" is just a little 
> flashcard spelling app for my daughter (and possibly a few friends in her 
> class) - so probably SimplePersistance will do in this case, however the 
> comments about making a persistence decision at the right moment are super 
> interesting - and as always, its about spotting the right moment to do that… 
> and ideally you have well factored code with ample tests that help you easily 
> move from the idea, to something more scalable or robust… however, move too 
> soon and you get bogged down with the details and you lose site of an MVP.
> 
> It has been interesting hearing peoples thoughts on all of this… the turning 
> tide on ORM’s, the potential sweet allure of a NoSql (but can you query it 
> easily) - and then the overarching element of just setting this shit up 
> (where hopefully Docker steps in to make that bit at least easy). I suppose 
> this is where the Rails scaffolding was/is? such a jumpstart, you can get a 
> full thing going quite easily, and deploying seems relatively easy too… for 
> us in Smalltalk land, its still a bit too much work for my liking, compared 
> to the ease of getting an image and coding, and seeing it all work. It does 
> seem to be getting marginally better at least, but I do wish there was super 
> easy setup with all the pieces nicely in place so it was just your idea that 
> you could focus on…
> 
> Anyway, that login screen… oh crap I have to write one of those…
> 
> Tim
> 
>> On 6 Oct 2020, at 20:56, jtuc...@objektfabrik.de wrote:
>> 
>> Sean,
>> 
>> thanks for your short overview of what SimplePersistence does. Sounds useful 
>> for quite a few scenarios and might even carry you well through production 
>> stages for some projects.
>> What I was talking about is also not meant to frustrate people. I've only 
>> played with Mongo/Voyage for a few hours and I must say I was blown away by 
>> the speed and ease of that stack. We got something running in a few hours 
>> and it was impressive. So Mongo/Voyage is a cool thing to use.
>> 
>> I always wanted to use Magna on Pharo. I even started to implement my own 
>> little clone of Magna in VA Smalltalk. I got into troubles when I tried to 
>> nest transactions and get this concurrency stuff streamlined somehow. We all 
>> know that besides naming and one-off problems, caching and concurreny are 
>> the hardest problems in computing. I think there is something about this. 
>> And so I gave up on that project... ;-)
>> 
>> In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a 
>> very solid state somewhere between complete despair and freaking out about 
>> how cool things are. I love and hate that stack from the bottom of my heart.
>> 
>> The cool thing about an RDB is (and will sure be for quite a while) three 
>> letters. S, Q and L. There are lots of highly sophisticated GUI tools to 
>> query, manage, correct your data. And you can simply do everything form a 
>> command prompt, in an ssh session from your smartphone in a hotel toilet on 
>> the other side of the planet.
>> 
>> Sure, using pure Smalltalk objects and not worry about n:m relationships, 
>> not having to write mappings and not having to end up with an object model 
>> that is driven mostly by what your O/R mapper can handle, sound great. And 
>> it is. Until you realize you also need to think about query optimizations, 
>> reorganizations, indexes and whatnot in an object database. There are also 
>> compromises to make.
>> 
>> But, hey, I said all of that before.
>> 
>> So maybe approaches like fuel, SimplePersistence (or BOSS or Object Swapper) 
>> are the best thing to start with when you need to find out about your 
>> architectural and business ideas first (am I building the right thing, will 
>> this feel good to a user, etc.), but once you are beyond that state, you 
>> better dive into your options and decide soon. Maybe using image saving or 
>> SimplePersistence is even good for production in your case. It was good 
>> enough for dabbleDB for quite a while, iirc, so why 

[Pharo-users] [Ann] IndieWeb and pocket infrastructures: 5th biweekly workshop this Saturday (3:15 PM - 7:15 PM, GMT-5)

[Offray Vladimir Luna Cárdenas]

Hi all,

This is just a short reminder about our biweekly Grafoscopio community
workshops about IndieWeb and pocket infrastructures (in Spanish). You
can find more information about them on:

[1]
https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/index.html#talleres


It has been really nice to see how workshops, prose and code advance
intertwined and feedback each other in this community experience made on
a voluntary basis. In the "behind scenes" links below you can see how
the writing advances at a pretty good pace.

Also I would like to thank ESUG for their key support to this initiative.

Cheers,

Offray

Ps: here are the "behind scenes" links


[2] https://mutabit.com/repos.fossil/indieweb/timeline
[3]
https://mutabit.com/repos.fossil/indieweb/tree?ci=tip=docs/es=tree
[4] https://code.tupale.co/Offray/Brea
[5] https://mutabit.com/repos.fossil/brea/

[Pharo-users] Re: Standalone html builder (a la seaside without seaside?)

[Torsten Bergmann]

Yes, see https://github.com/pharo-contributions/XML-XMLWriter


 

Gesendet: Mittwoch, 30. September 2020 um 16:42 Uhr
Von: "monty" 
An: pharo-users@lists.pharo.org
Betreff: [Pharo-users] Re: Standalone html builder (a la seaside without seaside?)



Yes, XMLWriter can do this. Use can also use:

 

xmlWriter outputsSelfClosingTags: false

 

before writing to get more HTML-like output

___
montyos.wordpress.com

 
 

Sent: Tuesday, September 29, 2020 at 3:08 PM
From: "Santiago Bragagnolo" 
To: "Any question about pharo is welcome" 
Subject: [Pharo-users] Re: Standalone html builder (a la seaside without seaside?)



Hi Tim.

My two cents: I am using XML Writer (from the catalog) and i am really happy so far.

 


El lun., 28 sept. 2020 a las 19:28, Tim Mackinnon () escribió:

Hi - has anyone ever managed to extract the html builder out of seaside - or written something equivalent?

I often find I want to build some HTML, but don’t want the full seaside - and was wondering if anyone has managed to extract it, or have something similar?

This combined with Renoir from BA-ST would give a good little light weight web potential to run with Zinc.

Tim

[Pharo-users] [ANN] HighchartsSt v12.1.0 [v12.1.0] released!

[Buenos Aires Smalltalk]

HighchartsSt, a highcharts js api wrapper for pharo smalltalk reached it's v12.1.0 version.
Changelog

Updated Highcharts and Highstock to 8.2.0
Separated series into their own packages to reduce loading bloat when working with only a few of them

Regards,
The Buenos Aires Smalltalk team

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[Tim Mackinnon]

Gosh - this is proving much more interesting than I had imagined, and I’m 
getting lots of useful input, so I double appreciate the time and thoughts from 
everyone.

I probably should have said that my "super awesome idea" is just a little 
flashcard spelling app for my daughter (and possibly a few friends in her 
class) - so probably SimplePersistance will do in this case, however the 
comments about making a persistence decision at the right moment are super 
interesting - and as always, its about spotting the right moment to do that… 
and ideally you have well factored code with ample tests that help you easily 
move from the idea, to something more scalable or robust… however, move too 
soon and you get bogged down with the details and you lose site of an MVP.

It has been interesting hearing peoples thoughts on all of this… the turning 
tide on ORM’s, the potential sweet allure of a NoSql (but can you query it 
easily) - and then the overarching element of just setting this shit up (where 
hopefully Docker steps in to make that bit at least easy). I suppose this is 
where the Rails scaffolding was/is? such a jumpstart, you can get a full thing 
going quite easily, and deploying seems relatively easy too… for us in 
Smalltalk land, its still a bit too much work for my liking, compared to the 
ease of getting an image and coding, and seeing it all work. It does seem to be 
getting marginally better at least, but I do wish there was super easy setup 
with all the pieces nicely in place so it was just your idea that you could 
focus on…

Anyway, that login screen… oh crap I have to write one of those…

Tim

> On 6 Oct 2020, at 20:56, jtuc...@objektfabrik.de wrote:
> 
> Sean,
> 
> thanks for your short overview of what SimplePersistence does. Sounds useful 
> for quite a few scenarios and might even carry you well through production 
> stages for some projects.
> What I was talking about is also not meant to frustrate people. I've only 
> played with Mongo/Voyage for a few hours and I must say I was blown away by 
> the speed and ease of that stack. We got something running in a few hours and 
> it was impressive. So Mongo/Voyage is a cool thing to use.
> 
> I always wanted to use Magna on Pharo. I even started to implement my own 
> little clone of Magna in VA Smalltalk. I got into troubles when I tried to 
> nest transactions and get this concurrency stuff streamlined somehow. We all 
> know that besides naming and one-off problems, caching and concurreny are the 
> hardest problems in computing. I think there is something about this. And so 
> I gave up on that project... ;-)
> 
> In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a very 
> solid state somewhere between complete despair and freaking out about how 
> cool things are. I love and hate that stack from the bottom of my heart.
> 
> The cool thing about an RDB is (and will sure be for quite a while) three 
> letters. S, Q and L. There are lots of highly sophisticated GUI tools to 
> query, manage, correct your data. And you can simply do everything form a 
> command prompt, in an ssh session from your smartphone in a hotel toilet on 
> the other side of the planet.
> 
> Sure, using pure Smalltalk objects and not worry about n:m relationships, not 
> having to write mappings and not having to end up with an object model that 
> is driven mostly by what your O/R mapper can handle, sound great. And it is. 
> Until you realize you also need to think about query optimizations, 
> reorganizations, indexes and whatnot in an object database. There are also 
> compromises to make.
> 
> But, hey, I said all of that before.
> 
> So maybe approaches like fuel, SimplePersistence (or BOSS or Object Swapper) 
> are the best thing to start with when you need to find out about your 
> architectural and business ideas first (am I building the right thing, will 
> this feel good to a user, etc.), but once you are beyond that state, you 
> better dive into your options and decide soon. Maybe using image saving or 
> SimplePersistence is even good for production in your case. It was good 
> enough for dabbleDB for quite a while, iirc, so why shouldn't it work for 
> others? And maybe that is even the best you can do to postpone the decision 
> for as long as possible at minimum opportunity cost.
> 
> I didn't dig deep enough into Voyage/Mongo to judge how expensive or risky 
> the changes to the design are. How hard is it to restructure the root trees - 
> say you need something that is now beneath some root to be a root of its own? 
> How would you do such changes?
> 
> I know I can do a lot of things of that kind with SQL. It is a second looking 
> glass and set of tools to view and manipulate the data. Sometimes things are 
> easier to do in Smalltalk, sometimes it is way too slow on top of an ORM and 
> a SQL query can do the same thing in a few milliseconds.
> 
> But maybe I am asking the wrong questions fo Tim's purposes. I think I 
> 

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[jtuc...@objektfabrik.de]

Sean,

thanks for your short overview of what SimplePersistence does. Sounds 
useful for quite a few scenarios and might even carry you well through 
production stages for some projects.
What I was talking about is also not meant to frustrate people. I've 
only played with Mongo/Voyage for a few hours and I must say I was blown 
away by the speed and ease of that stack. We got something running in a 
few hours and it was impressive. So Mongo/Voyage is a cool thing to use.


I always wanted to use Magna on Pharo. I even started to implement my 
own little clone of Magna in VA Smalltalk. I got into troubles when I 
tried to nest transactions and get this concurrency stuff streamlined 
somehow. We all know that besides naming and one-off problems, caching 
and concurreny are the hardest problems in computing. I think there is 
something about this. And so I gave up on that project... ;-)


In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a 
very solid state somewhere between complete despair and freaking out 
about how cool things are. I love and hate that stack from the bottom of 
my heart.


The cool thing about an RDB is (and will sure be for quite a while) 
three letters. S, Q and L. There are lots of highly sophisticated GUI 
tools to query, manage, correct your data. And you can simply do 
everything form a command prompt, in an ssh session from your smartphone 
in a hotel toilet on the other side of the planet.


Sure, using pure Smalltalk objects and not worry about n:m 
relationships, not having to write mappings and not having to end up 
with an object model that is driven mostly by what your O/R mapper can 
handle, sound great. And it is. Until you realize you also need to think 
about query optimizations, reorganizations, indexes and whatnot in an 
object database. There are also compromises to make.


But, hey, I said all of that before.

So maybe approaches like fuel, SimplePersistence (or BOSS or Object 
Swapper) are the best thing to start with when you need to find out 
about your architectural and business ideas first (am I building the 
right thing, will this feel good to a user, etc.), but once you are 
beyond that state, you better dive into your options and decide soon. 
Maybe using image saving or SimplePersistence is even good for 
production in your case. It was good enough for dabbleDB for quite a 
while, iirc, so why shouldn't it work for others? And maybe that is even 
the best you can do to postpone the decision for as long as possible at 
minimum opportunity cost.


I didn't dig deep enough into Voyage/Mongo to judge how expensive or 
risky the changes to the design are. How hard is it to restructure the 
root trees - say you need something that is now beneath some root to be 
a root of its own? How would you do such changes?


I know I can do a lot of things of that kind with SQL. It is a second 
looking glass and set of tools to view and manipulate the data. 
Sometimes things are easier to do in Smalltalk, sometimes it is way too 
slow on top of an ORM and a SQL query can do the same thing in a few 
milliseconds.


But maybe I am asking the wrong questions fo Tim's purposes. I think I 
understand what you (Tim) are looking for is not a big, complex project 
but more like an experiment? I don't want to invalidate any of the given 
suggestions, I know or at least believe that they each do a good job. 
All I really wanted to warn you is that you will not easily be able to 
go from one option to another, because each will have a deep impact on 
your object model and application architecture.


Joachim




Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users:

jtuchel wrote

Sigh. Forget about the idea that it will be easy to switch your
persistence laterI am not commenting on SimplePersistence here, I
don't even know what it
does or doesn't.

Joachim,
Thanks for this interesting perspective. I've never had the (mis?!)fortune
of a project growing enough to force me to make those tough choices! For
SimplePersistence I will say that I view it as a way to *delay* making *any*
choices until you are forced to. It's really just a layer of sugar on top of
Fuel (it used to use the old school Squeak equivalent serialization
mechanism - I forget the name and that might still work). You tell it what
classes to serialize. Implement two methods for each class that get and set
the data, and then it saves the whole thing as one object graph.

Tim,
If you use SimplePersistence, please keep me posted about your experience.
I'm happy to help.

NB I have maintained and extended the library, but it is the work of Ramon
Leon



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html



--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[jtuc...@objektfabrik.de]

- Choose Boring Technology - http://boringtechnology.club/

This made my day. Thank you :-)


Had never heard of this guy, but his site feels like home to me. Makes 
me a proud user of Smalltalk and DB2 after 25+ years ;-)


He forgot to mention that boring technology can be quite interesting and 
cool, even if it is about to turn 50 years... And he's absolutely right 
about the fact that shipiing something useful for users makes you much 
more happy (and busy) than shipping something on top of an incredibly 
complicated and bloated technology stack...



Joachim



--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[Gabriel Cotelli]

If you want to use docker there's https://github.com/ba-st/docker-pharo and
others that I don't remembar now that provides the basics.
You have some examples in
https://github.com/ba-st/docker-pharo/blob/master/docs/Examples.md .

We're deploying our apps as docker containers so ask any question if you
have doubts.

On Tue, Oct 6, 2020 at 9:48 AM Tim Mackinnon  wrote:

> Some great answers everyone - really appreciate it.
>
> I think that all things considered, SimplePersistence seems like a very
> easy place to start, and then I can "upgrade" when my super awesome idea
> (not), exceeds its bounds.
>
> I wonder if these answers should go somewhere in a tips section somewhere,
> and get updated yearly.
>
> @jonathan I had forgotten about those server tools - I think the last time
> I did something it predated some earlier tips the Sven had given, so will
> check it out. Back then, I did have a GitLab build pipeline autodeploying
> for me, so I'm hoping I can re-incarnate all of that so I can get my little
> app running with no fuss... lets see.
>
> While I have a love/hate with Docker - I did wonder if there was something
> for Pharo that just let me build my image into a container and then it
> would just work with little system knowledge needed (as I keep forgetting
> all the voodoo between times when I need it). Maybe there is, or maybe it
> might come one day soon...
>
> Tim
>
> On Tue, 6 Oct 2020, at 9:40 AM, Jonathan van Alteren wrote:
>
> Hi Tim,
>
> I've been running Seaside applications on Hetzner cloud servers for more
> than a year now, with great pleasure and success:
> https://www.hetzner.com/cloud
> I guess their servers are similar to Digital Ocean, although I haven't
> followed the development of their products and solutions for quite a while.
> Setting up a new server at Hetzner is a breeze, and you can start already
> for as low as €2,49 per month!
>
> We're using Voyage on MongoDB for persistence. After learning some hard
> lessons (and I'm sure there are more to come ;-)), I really enjoy the
> unobtrusiveness of it. Most of the time, it doesn't require much attention
> and allows me to add persistence to real OO designs quickly and easily. I
> find it a welcome change from the relational database work I used to (need
> to) do, back when I was still doing Java. The 'everything an object'
> principle of Pharo/Smalltalk really makes it shine.
>
> I can't help you with a list of tradeoffs though. If you come across a set
> of arguments, I'd be happy to give feedback.
>
> By the way, I forked Sven's pharo-server-tools project (here:
> https://github.com/objectguild/pharo-server-tools) and have a routine
> going that suits me well enough. Still lots of room for improvement, but
> it's OK for my current needs.
>
> Future plans are to use the Hetzner API to provision a new server and use
> something like Chef or Ansible to install/configure it automatically to be
> ready to deploy a Seaside application. I'd like to integrate this into a
> full service CI/CD pipeline in the future, to be able to do automated
> production deployments without service interruption if possible. For this
> scenario, I would really also like to switch to using GemStone for
> persistence.
>
> Hope this helps! Let me know what you decide and I might be able to help
> with some technical stuff.
>
> Kind regards,
>
> Jonathan van Alteren
>
> Founding Member | Object Guild B.V.
> *Sustainable Software for Purpose-Driven Organizations*
>
> jvalte...@objectguild.com
> On 6 Oct 2020, 00:23 +0200, Tim Mackinnon , wrote:
>
> Hi everyone - I’m wondering what is the recommended way to save some
> simple user data for a Pharo application I would like to run on the cloud
> (probably initially digital ocean, but could be AWS if it came to it).
>
> Initially I thought I might try and run my little app in Digital ocean (I
> followed someone’s steps a few years ago, and had a simple seaside app
> running quite well) - so I was thinking of starting there.
>
> I know there is Sven’s P3 - but I’m not sure I’m ready to run and maintain
> a SQL database for a simple application, but could be persuaded it its
> simple to setup with little maintenance. Would mongo be a suggestion - is
> that easy to setup and run? (And is that Voyage?).
>
> Possibly I could even use image persistence, and fuel out a Dictionary
> from time to time - but I think that might be a little bit too belt and
> braces for me.
>
> Is there something that gives a little table of tradeoffs with some simple
> ways to get started?
>
> Tim
>
>
>

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[Esteban A. Maringolo]

Hi Tim, 

I think that the persistence you choose will depend heavily on a few things:
- The complexity of the objects graphs in your domain models
- This architecture of your system
- How these objects/data is acceded (Atomically/In clusters)

In any case, for a lightweight solution you go the Fuel path, or something
using SQLite.

I have a GLORP based application (small, ~40 persisted classes), SQLite is
so lightweight that I run my SUnit tests creating the whole database _on
disk_ from scratch on setUp and destroying it on tearDown), and only run it
against the production backend (PostgreSQL) before deploying, but even this
is happening less frequently since I'm confident that things will work the
same on both.

OTOH I'm finding that ORMs are burden, and unless you need to work with an
existing schema or you really want to use an RDBMS, you might be better off
avoiding them. I've been using ORMs for almost two decades, so that's still
my default choice, but I feel winds of change here :-)

Regards!




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[Esteban Maringolo]

Hi Pierce,

On Mon, Oct 5, 2020 at 10:22 PM Pierce Ng  wrote:

> On Mon, Oct 05, 2020 at 11:23:25PM +0100, Tim Mackinnon wrote:
> Many options. Great time sinks. :-) Have fun.
>
> 

> - Choose Boring Technology - http://boringtechnology.club/

This made my day. Thank you :-)


Esteban A. Maringolo

[Pharo-users] [Offtopic] Documentary Project

[Eric Gade]

Fellow Squeakers and Pharo-ers,

Please forgive me if this message is inappropriate for the list. I am
hoping you all will be interested in the following project.

For the past year and a half I have been working on a team that is
developing a documentary

on the history of personal computing. Our goal is to interview the very
people who laid the foundations for personal computing while they are still
with us, learning about their original visions and getting their take on
the present. In this sense it is both an aspiring feature length
documentary project but also an endeavor in oral history and posterity.
Many of the themes we want to explore will be familiar to the members of
this community (as will the title).

Last fall we were able to shoot our first three interviews. We used these
to make a short teaser , with the idea it
could be used to raise funds for future rounds of interviews. That said, we
are currently in the middle of a Kickstarter campaign

to get the second round funded. If you are interested in learning more,
feel free to reach out to me directly and to visit the film's campaign site

and website . We need all the promotion
we can get!

Thanks!


-- 
Eric

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[Sean P. DeNigris via Pharo-users]

jtuchel wrote
> Sigh. Forget about the idea that it will be easy to switch your 
> persistence laterI am not commenting on SimplePersistence here, I
> don't even know what it 
> does or doesn't.

Joachim,
Thanks for this interesting perspective. I've never had the (mis?!)fortune
of a project growing enough to force me to make those tough choices! For
SimplePersistence I will say that I view it as a way to *delay* making *any*
choices until you are forced to. It's really just a layer of sugar on top of
Fuel (it used to use the old school Squeak equivalent serialization
mechanism - I forget the name and that might still work). You tell it what
classes to serialize. Implement two methods for each class that get and set
the data, and then it saves the whole thing as one object graph.

Tim,
If you use SimplePersistence, please keep me posted about your experience.
I'm happy to help.

NB I have maintained and extended the library, but it is the work of Ramon
Leon



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[jtuc...@objektfabrik.de]

Tim,

Am 06.10.20 um 14:47 schrieb Tim Mackinnon:

Some great answers everyone - really appreciate it.

I think that all things considered, SimplePersistence seems like a 
very easy place to start, and then I can "upgrade" when my super 
awesome idea (not), exceeds its bounds.


Sigh. Forget about the idea that it will be easy to switch your 
persistence later. There are lots of little (and not so little) things 
to consider for each approach, be it an ORM, an object database or just 
a bunch of serialized objects. It starts with the bookkeeping for 
references between objects. Is it enough to remove an object from a 
Collection or will it somehow survive in your db and come back as a 
surprise after you started a new transction? Will a deleted object be 
deleted or just unreachable? Do I have to care about all possible paths 
to this object if I really want it to be deleted? Will my ORB possible 
re-insert it in the next transaction because I don't understand how an 
ORM works?


Don't fool yourself into thinking there is something like a transparent 
persistence layer. If anybody ever says so, walk away, say thank you and 
forget about that person as fast as you can.


I am not commenting on SimplePersistence here, I don't even know what it 
does or doesn't. I am talking about experiences made with both OODBs and 
ORMs like Glorp.


I've been through tough times with an architecture that I thought to be 
a good idea: keep persistence in a separate layer that just spits out 
objects and swallows new or changed ones. Works well in a prototype. But 
on top of Glorp and with a few more than a hand full of objects, you end 
up wanting to write real database queries. So you need to get a hold of 
something that represents the database, say a Session object. You end up 
either trying to wrapper the query building in your clever layer and end 
up with friggin slow performance or give up on your nice layering to 
make your application at least bearable. Sometimes you even give up 
navigating between objects and replace a simple getter with a DB query 
to get good performance (ever waited for 600 proxies in a collection to 
each deserialize itself when accessing the #items of your Stock object? 
- you better write a sql query fetching them all at once...)


You need query by example? Good luck in an Object DB. You either use DB 
specific queries and hand-tuned indices, or you navigate your object net 
and have the user wait a little. Or you design your object model around 
the search paths (which is hard once your model has evolved a while).


In Mongo/Voyage, you need to make a decision of what objects will always 
be tied closely together (referenced by a root) and can be retrieved on 
their own. You think in object trees rather than objects. We've thrown 
CouchDB out of our project. Not because it is a bad NoSQL database, but 
because we couldn't make it work well in our overall architecture in 
which the primary store is a relational Database.


So please be aware that once your app gets a little more than just a 
prototype, you need to make a decision: relational, dictinaries, tree-like



I guess this is not really helpful advice. I can't really tell you what 
is right. I am cursing at Glorp every few days, but I also love it for 
many great things it does for us. And I've had a few very "interesting" 
lessons along the way, and am still in the process of learning about its 
limits.



Joachim







I wonder if these answers should go somewhere in a tips section 
somewhere, and get updated yearly.


@jonathan I had forgotten about those server tools - I think the last 
time I did something it predated some earlier tips the Sven had given, 
so will check it out. Back then, I did have a GitLab build pipeline 
autodeploying for me, so I'm hoping I can re-incarnate all of that so 
I can get my little app running with no fuss... lets see.


While I have a love/hate with Docker - I did wonder if there was 
something for Pharo that just let me build my image into a container 
and then it would just work with little system knowledge needed (as I 
keep forgetting all the voodoo between times when I need it). Maybe 
there is, or maybe it might come one day soon...


Tim

On Tue, 6 Oct 2020, at 9:40 AM, Jonathan van Alteren wrote:

Hi Tim,

I've been running Seaside applications on Hetzner cloud servers for 
more than a year now, with great pleasure and success: 
https://www.hetzner.com/cloud
I guess their servers are similar to Digital Ocean, although I 
haven't followed the development of their products and solutions for 
quite a while. Setting up a new server at Hetzner is a breeze, and 
you can start already for as low as €2,49 per month!


We're using Voyage on MongoDB for persistence. After learning some 
hard lessons (and I'm sure there are more to come ;-)), I really 
enjoy the unobtrusiveness of it. Most of the time, it doesn't require 
much attention and allows me to add persistence to real OO designs 

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[Tim Mackinnon]

Some great answers everyone - really appreciate it.

I think that all things considered, SimplePersistence seems like a very easy 
place to start, and then I can "upgrade" when my super awesome idea (not), 
exceeds its bounds.

I wonder if these answers should go somewhere in a tips section somewhere, and 
get updated yearly.

@jonathan I had forgotten about those server tools - I think the last time I 
did something it predated some earlier tips the Sven had given, so will check 
it out. Back then, I did have a GitLab build pipeline autodeploying for me, so 
I'm hoping I can re-incarnate all of that so I can get my little app running 
with no fuss... lets see.

While I have a love/hate with Docker - I did wonder if there was something for 
Pharo that just let me build my image into a container and then it would just 
work with little system knowledge needed (as I keep forgetting all the voodoo 
between times when I need it). Maybe there is, or maybe it might come one day 
soon...

Tim

On Tue, 6 Oct 2020, at 9:40 AM, Jonathan van Alteren wrote:
> Hi Tim,
> 
> I've been running Seaside applications on Hetzner cloud servers for more than 
> a year now, with great pleasure and success: https://www.hetzner.com/cloud
> I guess their servers are similar to Digital Ocean, although I haven't 
> followed the development of their products and solutions for quite a while. 
> Setting up a new server at Hetzner is a breeze, and you can start already for 
> as low as €2,49 per month!
> 
> We're using Voyage on MongoDB for persistence. After learning some hard 
> lessons (and I'm sure there are more to come ;-)), I really enjoy the 
> unobtrusiveness of it. Most of the time, it doesn't require much attention 
> and allows me to add persistence to real OO designs quickly and easily. I 
> find it a welcome change from the relational database work I used to (need 
> to) do, back when I was still doing Java. The 'everything an object' 
> principle of Pharo/Smalltalk really makes it shine.
> 
> I can't help you with a list of tradeoffs though. If you come across a set of 
> arguments, I'd be happy to give feedback.
> 
> By the way, I forked Sven's pharo-server-tools project (here: 
> https://github.com/objectguild/pharo-server-tools) and have a routine going 
> that suits me well enough. Still lots of room for improvement, but it's OK 
> for my current needs.
> 
> Future plans are to use the Hetzner API to provision a new server and use 
> something like Chef or Ansible to install/configure it automatically to be 
> ready to deploy a Seaside application. I'd like to integrate this into a full 
> service CI/CD pipeline in the future, to be able to do automated production 
> deployments without service interruption if possible. For this scenario, I 
> would really also like to switch to using GemStone for persistence.
> 
> Hope this helps! Let me know what you decide and I might be able to help with 
> some technical stuff.
> 
> Kind regards,
> 
> Jonathan van Alteren
> 
> Founding Member | Object Guild B.V.
> *Sustainable Software for Purpose-Driven Organizations*
> 
> jvalte...@objectguild.com
> On 6 Oct 2020, 00:23 +0200, Tim Mackinnon , wrote:
> 
>> Hi everyone - I’m wondering what is the recommended way to save some simple 
>> user data for a Pharo application I would like to run on the cloud (probably 
>> initially digital ocean, but could be AWS if it came to it).
>> 
>> Initially I thought I might try and run my little app in Digital ocean (I 
>> followed someone’s steps a few years ago, and had a simple seaside app 
>> running quite well) - so I was thinking of starting there.
>> 
>> I know there is Sven’s P3 - but I’m not sure I’m ready to run and maintain a 
>> SQL database for a simple application, but could be persuaded it its simple 
>> to setup with little maintenance. Would mongo be a suggestion - is that easy 
>> to setup and run? (And is that Voyage?).
>> 
>> Possibly I could even use image persistence, and fuel out a Dictionary from 
>> time to time - but I think that might be a little bit too belt and braces 
>> for me.
>> 
>> Is there something that gives a little table of tradeoffs with some simple 
>> ways to get started?
>> 
>> Tim

[Pharo-users] Re: Energy efficiency of Pharo/Smalltalk

[Jonathan van Alteren]

Hi Mariano,

Thanks for your response! I will take a look at the presentation.

I was hoping for some more concrete experience with the Green Software Lab 
benchmark. It's not a priority at the moment, but hopefully I'll get back to 
this in the near future. I'll report back with any findings.

Kind regards,

Jonathan van Alteren

Founding Member | Object Guild B.V.
Sustainable Software for Purpose-Driven Organizations

jvalte...@objectguild.com
On 1 Oct 2020, 22:34 +0200, Mariano Martinez Peck , 
wrote:
>
> Hi there,
>
> We did a related experiment with VA Smalltalk and other languages like 
> Python, Java, etc... the context was how a JIT compiler can also help you 
> reduce energy consumption...which could be very important for IoT. We did 
> experiments on a Raspberry Pi, run some benchmarks and with some hardware 
> tool we were measuring the wattage.
>
> You can see the whole presentation here: https://youtu.be/2xO0ohUNnug
>
> Hopefully this can get you started with Pharo experiments.
>
> Cheers,
>
> > On Thu, Oct 1, 2020 at 8:47 AM Jonathan van Alteren 
> >  wrote:
> > > Hi all,
> > >
> > > I am interested in energy efficiency metrics for Pharo (version >=8). 
> > > Just now, I came across this research and related GitHub project:
> > >
> > > • https://sites.google.com/view/energy-efficiency-languages
> > > • https://github.com/greensoftwarelab/Energy-Languages
> > >
> > >
> > > Unfortunately, the paper mentions that Smalltalk was excluded from the 
> > > results because the (VW) compiler was proprietary :-S However, the GitHub 
> > > repository does contain Smalltalk code and results, but I haven't been 
> > > able to evaluate those.
> > >
> > > [1] Does anyone here have more information on this topic?
> > >
> > >
> > > The benchmarks seem to be low-level algorithms. Although that is useful, 
> > > I think that a better argument for Pharo/Smalltalk efficiency is that a 
> > > good OO design (e.g. created using responsibility-driven design with 
> > > behaviorally complete objects) will be a better fit, can be much simpler 
> > > and will thus be more efficient during development, as well as easier to 
> > > maintain and evolve.
> > >
> > > [2] Has anyone done any research in this area that can quantify this 
> > > aspect?
> > >
> > > Kind regards,
> > >
> > > Jonathan van Alteren
> > >
> > > Founding Member | Object Guild B.V.
> > > Sustainable Software for Purpose-Driven Organizations
> > >
> > > jvalte...@objectguild.com
>
>
> --
> Mariano Martinez Peck
> Email: marianop...@gmail.com
> Twitter: @MartinezPeck
> LinkedIn: www.linkedin.com/in/mariano-martinez-peck
> Blog: https://marianopeck.wordpress.com/

[Pharo-users] Re: Easiest light weight cloud/web persistence for Pharo?

[Jonathan van Alteren]

Hi Tim,

I've been running Seaside applications on Hetzner cloud servers for more than a 
year now, with great pleasure and success: https://www.hetzner.com/cloud
I guess their servers are similar to Digital Ocean, although I haven't followed 
the development of their products and solutions for quite a while. Setting up a 
new server at Hetzner is a breeze, and you can start already for as low as 
€2,49 per month!

We're using Voyage on MongoDB for persistence. After learning some hard lessons 
(and I'm sure there are more to come ;-)), I really enjoy the unobtrusiveness 
of it. Most of the time, it doesn't require much attention and allows me to add 
persistence to real OO designs quickly and easily. I find it a welcome change 
from the relational database work I used to (need to) do, back when I was still 
doing Java. The 'everything an object' principle of Pharo/Smalltalk really 
makes it shine.

I can't help you with a list of tradeoffs though. If you come across a set of 
arguments, I'd be happy to give feedback.

By the way, I forked Sven's pharo-server-tools project (here: 
https://github.com/objectguild/pharo-server-tools) and have a routine going 
that suits me well enough. Still lots of room for improvement, but it's OK for 
my current needs.

Future plans are to use the Hetzner API to provision a new server and use 
something like Chef or Ansible to install/configure it automatically to be 
ready to deploy a Seaside application. I'd like to integrate this into a full 
service CI/CD pipeline in the future, to be able to do automated production 
deployments without service interruption if possible. For this scenario, I 
would really also like to switch to using GemStone for persistence.

Hope this helps! Let me know what you decide and I might be able to help with 
some technical stuff.

Kind regards,

Jonathan van Alteren

Founding Member | Object Guild B.V.
Sustainable Software for Purpose-Driven Organizations

jvalte...@objectguild.com
On 6 Oct 2020, 00:23 +0200, Tim Mackinnon , wrote:
> Hi everyone - I’m wondering what is the recommended way to save some simple 
> user data for a Pharo application I would like to run on the cloud (probably 
> initially digital ocean, but could be AWS if it came to it).
>
> Initially I thought I might try and run my little app in Digital ocean (I 
> followed someone’s steps a few years ago, and had a simple seaside app 
> running quite well) - so I was thinking of starting there.
>
> I know there is Sven’s P3 - but I’m not sure I’m ready to run and maintain a 
> SQL database for a simple application, but could be persuaded it its simple 
> to setup with little maintenance. Would mongo be a suggestion - is that easy 
> to setup and run? (And is that Voyage?).
>
> Possibly I could even use image persistence, and fuel out a Dictionary from 
> time to time - but I think that might be a little bit too belt and braces for 
> me.
>
> Is there something that gives a little table of tradeoffs with some simple 
> ways to get started?
>
> Tim