Another story from 2Denker is up: http://pharo.org/success/MultiCity Client seems to be done using Amber when I check the login page which was styled with Bootstrap. Server in Pharo with Nginx. I guess you use Mongo as DB (with Voyage or without). @Norbert/@Marcus: if possible can you share with us a few more technical details about the technologies/stack used. Also about size (LOC, users, nr of images) and pitfalls ... There is always something one can learn from the experience of others.
Hi Torsten,
Am 15.07.2015 um 22:51 schrieb Torsten Bergmann <astares@gmx.de>:
Another story from 2Denker is up: http://pharo.org/success/MultiCity
Client seems to be done using Amber when I check the login page which was styled with Bootstrap. Server in Pharo with Nginx. I guess you use Mongo as DB (with Voyage or without).
@Norbert/@Marcus: if possible can you share with us a few more technical details about the technologies/stack used. Also about size (LOC, users, nr of images) and pitfalls ...
There is always something one can learn from the experience of others.
sure I can give some insight in the project. For the admin client we use amber plus bootstrap. The backend for this is a pharo image with voyage. As you can see in the screenshot there is a geo location entered. That can be searched afterwards because mongo provides geo spatial indexes. The project is built upon a service we provide at 2denker. The service is a registry for app installations, users and message tokens. We provide libraries for ios, android and windows mobile that registers the app, assigns a user, requests a message token from the user and stores it. The service is used for notifying the user at return of the car. You then get a notification containing the time and price of your car rental. The architecture of our infrastructure is event based. Meaning that e.g. the installation registration service sends events to a central event bus like image. This stores the events in elasticsearch and provides the ability to register for events. What we had to do for this project? We've built an image that on the one hand serves the request of the client admin interface. On the other hand it registers at the event server for a certain kind of event. This event is triggered by the car return and piggybacks the geo location where the car has been left. When such an event travels through our system the event server sees a match and calls the image. The image extracts the geo information and searches the database for available advertisements. If one is found and conditions are met an additional message is sent. That's roughly it. In the whole process there are 8 pharo images involved but 2 are for redundancy so it is 6 different images. The rest is a mongo database and an elasticsearch database. If you want to know anything more don't hesitate to ask. Norbert
One question about Mongo. How do you handle HA (High Availability) in Pharo? The current driver (MongoTalk) connects to one single mongod. I haven't seen any support for replicasets and identifying who is the mongod to write to in MongoTalk (this support is built in any Python, Ruby, ... driver they do provide, including sharding support and GridFS). Also, I've been experiencing a couple of protocol errors when working with mongod under some scenarios (unrecognized command coming back in the wire protocol). Looks like MongoTalk and mongod were out of sync on the wire protocol. Thanks and kudos for one more nice application! Phil On Thu, Jul 16, 2015 at 12:36 PM, Norbert Hartl <norbert@hartl.name> wrote:
Hi Torsten,
Am 15.07.2015 um 22:51 schrieb Torsten Bergmann <astares@gmx.de>:
Another story from 2Denker is up: http://pharo.org/success/MultiCity
Client seems to be done using Amber when I check the login page which was styled with Bootstrap. Server in Pharo with Nginx. I guess you use Mongo as DB (with Voyage or without).
@Norbert/@Marcus: if possible can you share with us a few more technical details about the technologies/stack used. Also about size (LOC, users, nr of images) and pitfalls ...
There is always something one can learn from the experience of others.
sure I can give some insight in the project.
For the admin client we use amber plus bootstrap. The backend for this is a pharo image with voyage. As you can see in the screenshot there is a geo location entered. That can be searched afterwards because mongo provides geo spatial indexes.
The project is built upon a service we provide at 2denker. The service is a registry for app installations, users and message tokens. We provide libraries for ios, android and windows mobile that registers the app, assigns a user, requests a message token from the user and stores it. The service is used for notifying the user at return of the car. You then get a notification containing the time and price of your car rental.
The architecture of our infrastructure is event based. Meaning that e.g. the installation registration service sends events to a central event bus like image. This stores the events in elasticsearch and provides the ability to register for events.
What we had to do for this project? We've built an image that on the one hand serves the request of the client admin interface. On the other hand it registers at the event server for a certain kind of event. This event is triggered by the car return and piggybacks the geo location where the car has been left. When such an event travels through our system the event server sees a match and calls the image. The image extracts the geo information and searches the database for available advertisements. If one is found and conditions are met an additional message is sent.
That's roughly it. In the whole process there are 8 pharo images involved but 2 are for redundancy so it is 6 different images. The rest is a mongo database and an elasticsearch database. If you want to know anything more don't hesitate to ask.
Norbert
Am 16.07.2015 um 12:59 schrieb phil@highoctane.be:
One question about Mongo.
How do you handle HA (High Availability) in Pharo?
I don't.
The current driver (MongoTalk) connects to one single mongod.
I haven't seen any support for replicasets and identifying who is the mongod to write to in MongoTalk (this support is built in any Python, Ruby, ... driver they do provide, including sharding support and GridFS).
As far as I know there is no support for all of these. It would be really good to have them. But if nobody contributes it may be not needed after all.
Also, I've been experiencing a couple of protocol errors when working with mongod under some scenarios (unrecognized command coming back in the wire protocol). Looks like MongoTalk and mongod were out of sync on the wire protocol.
You need to be careful because the mongo connection is a single stream aligned request by request. If another thread writes on the stream at the same time you will experience what you call "out of sync". Norbert
Thanks and kudos for one more nice application!
Phil
On Thu, Jul 16, 2015 at 12:36 PM, Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote: Hi Torsten,
Am 15.07.2015 um 22:51 schrieb Torsten Bergmann <astares@gmx.de <mailto:astares@gmx.de>>:
Another story from 2Denker is up: http://pharo.org/success/MultiCity <http://pharo.org/success/MultiCity>
Client seems to be done using Amber when I check the login page which was styled with Bootstrap. Server in Pharo with Nginx. I guess you use Mongo as DB (with Voyage or without).
@Norbert/@Marcus: if possible can you share with us a few more technical details about the technologies/stack used. Also about size (LOC, users, nr of images) and pitfalls ...
There is always something one can learn from the experience of others.
sure I can give some insight in the project.
For the admin client we use amber plus bootstrap. The backend for this is a pharo image with voyage. As you can see in the screenshot there is a geo location entered. That can be searched afterwards because mongo provides geo spatial indexes.
The project is built upon a service we provide at 2denker. The service is a registry for app installations, users and message tokens. We provide libraries for ios, android and windows mobile that registers the app, assigns a user, requests a message token from the user and stores it. The service is used for notifying the user at return of the car. You then get a notification containing the time and price of your car rental.
The architecture of our infrastructure is event based. Meaning that e.g. the installation registration service sends events to a central event bus like image. This stores the events in elasticsearch and provides the ability to register for events.
What we had to do for this project? We've built an image that on the one hand serves the request of the client admin interface. On the other hand it registers at the event server for a certain kind of event. This event is triggered by the car return and piggybacks the geo location where the car has been left. When such an event travels through our system the event server sees a match and calls the image. The image extracts the geo information and searches the database for available advertisements. If one is found and conditions are met an additional message is sent.
That's roughly it. In the whole process there are 8 pharo images involved but 2 are for redundancy so it is 6 different images. The rest is a mongo database and an elasticsearch database. If you want to know anything more don't hesitate to ask.
Norbert
Le 16 juil. 2015 15:07, "Norbert Hartl" <norbert@hartl.name> a écrit :
Am 16.07.2015 um 12:59 schrieb phil@highoctane.be:
One question about Mongo.
How do you handle HA (High Availability) in Pharo?
I don't.
The current driver (MongoTalk) connects to one single mongod.
I haven't seen any support for replicasets and identifying who is the
mongod to write to in MongoTalk (this support is built in any Python, Ruby, ... driver they do provide, including sharding support and GridFS).
As far as I know there is no support for all of these. It would be really good to have them. But if nobody contributes it may be not needed after all.
Working - slowly - on it.
Also, I've been experiencing a couple of protocol errors when working
with mongod under some scenarios (unrecognized command coming back in the wire protocol). Looks like MongoTalk and mongod were out of sync on the wire protocol.
You need to be careful because the mongo connection is a single stream aligned request by request. If another thread writes on the stream at the same time you will experience what you call "out of sync".
Not such issue in the current code AFAIK but will look closer.
Norbert
Thanks and kudos for one more nice application!
Phil
On Thu, Jul 16, 2015 at 12:36 PM, Norbert Hartl <norbert@hartl.name>
wrote:
Hi Torsten,
Am 15.07.2015 um 22:51 schrieb Torsten Bergmann <astares@gmx.de>:
Another story from 2Denker is up: http://pharo.org/success/MultiCity
Client seems to be done using Amber when I check the login page which
was
styled with Bootstrap. Server in Pharo with Nginx. I guess you use Mongo as DB (with Voyage or without).
@Norbert/@Marcus: if possible can you share with us a few more technical details about the technologies/stack used. Also about size (LOC, users, nr of images) and pitfalls ...
There is always something one can learn from the experience of others.
sure I can give some insight in the project.
For the admin client we use amber plus bootstrap. The backend for this is a pharo image with voyage. As you can see in the screenshot there is a geo location entered. That can be searched afterwards because mongo provides geo spatial indexes.
The project is built upon a service we provide at 2denker. The service is a registry for app installations, users and message tokens. We provide libraries for ios, android and windows mobile that registers the app, assigns a user, requests a message token from the user and stores it. The service is used for notifying the user at return of the car. You then get a notification containing the time and price of your car rental.
The architecture of our infrastructure is event based. Meaning that e.g. the installation registration service sends events to a central event bus like image. This stores the events in elasticsearch and provides the ability to register for events.
What we had to do for this project? We've built an image that on the one hand serves the request of the client admin interface. On the other hand it registers at the event server for a certain kind of event. This event is triggered by the car return and piggybacks the geo location where the car has been left. When such an event travels through our system the event server sees a match and calls the image. The image extracts the geo information and searches the database for available advertisements. If one is found and conditions are met an additional message is sent.
That's roughly it. In the whole process there are 8 pharo images involved but 2 are for redundancy so it is 6 different images. The rest is a mongo database and an elasticsearch database. If you want to know anything more don't hesitate to ask.
Norbert
Am 16.07.2015 um 18:14 schrieb "phil@highoctane.be" <phil@highoctane.be>:
Le 16 juil. 2015 15:07, "Norbert Hartl" <norbert@hartl.name> a écrit :
Am 16.07.2015 um 12:59 schrieb phil@highoctane.be:
One question about Mongo.
How do you handle HA (High Availability) in Pharo?
I don't.
The current driver (MongoTalk) connects to one single mongod.
I haven't seen any support for replicasets and identifying who is the mongod to write to in MongoTalk (this support is built in any Python, Ruby, ... driver they do provide, including sharding support and GridFS).
As far as I know there is no support for all of these. It would be really good to have them. But if nobody contributes it may be not needed after all.
Working - slowly - on it.
Great! I'd like to see support for this. If you have anything commit it. Or ask. I'll be happy to assist. Norbert
Also, I've been experiencing a couple of protocol errors when working with mongod under some scenarios (unrecognized command coming back in the wire protocol). Looks like MongoTalk and mongod were out of sync on the wire protocol.
You need to be careful because the mongo connection is a single stream aligned request by request. If another thread writes on the stream at the same time you will experience what you call "out of sync".
Not such issue in the current code AFAIK but will look closer.
Norbert
Thanks and kudos for one more nice application!
Phil
On Thu, Jul 16, 2015 at 12:36 PM, Norbert Hartl <norbert@hartl.name> wrote:
Hi Torsten,
Am 15.07.2015 um 22:51 schrieb Torsten Bergmann <astares@gmx.de>:
Another story from 2Denker is up: http://pharo.org/success/MultiCity
Client seems to be done using Amber when I check the login page which was styled with Bootstrap. Server in Pharo with Nginx. I guess you use Mongo as DB (with Voyage or without).
@Norbert/@Marcus: if possible can you share with us a few more technical details about the technologies/stack used. Also about size (LOC, users, nr of images) and pitfalls ...
There is always something one can learn from the experience of others.
sure I can give some insight in the project.
For the admin client we use amber plus bootstrap. The backend for this is a pharo image with voyage. As you can see in the screenshot there is a geo location entered. That can be searched afterwards because mongo provides geo spatial indexes.
The project is built upon a service we provide at 2denker. The service is a registry for app installations, users and message tokens. We provide libraries for ios, android and windows mobile that registers the app, assigns a user, requests a message token from the user and stores it. The service is used for notifying the user at return of the car. You then get a notification containing the time and price of your car rental.
The architecture of our infrastructure is event based. Meaning that e.g. the installation registration service sends events to a central event bus like image. This stores the events in elasticsearch and provides the ability to register for events.
What we had to do for this project? We've built an image that on the one hand serves the request of the client admin interface. On the other hand it registers at the event server for a certain kind of event. This event is triggered by the car return and piggybacks the geo location where the car has been left. When such an event travels through our system the event server sees a match and calls the image. The image extracts the geo information and searches the database for available advertisements. If one is found and conditions are met an additional message is sent.
That's roughly it. In the whole process there are 8 pharo images involved but 2 are for redundancy so it is 6 different images. The rest is a mongo database and an elasticsearch database. If you want to know anything more don't hesitate to ask.
Norbert
Am 16.07.2015 um 12:36 schrieb Norbert Hartl <norbert@hartl.name>:
That's roughly it. In the whole process there are 8 pharo images involved but 2 are for redundancy so it is 6 different images.
To clarify on that. There are two images load balanced for the registry services. Two load balanced for the event stuff. Each one for sending apple push notifications, google cloud messages and windows messages. And there is a single image for this project. Norbert
Are you using SMS at all? NorbertHartl wrote
Am 16.07.2015 um 12:36 schrieb Norbert Hartl <
norbert@
>:
That's roughly it. In the whole process there are 8 pharo images involved but 2 are for redundancy so it is 6 different images.
To clarify on that. There are two images load balanced for the registry services. Two load balanced for the event stuff. Each one for sending apple push notifications, google cloud messages and windows messages. And there is a single image for this project.
Norbert
-- View this message in context: http://forum.world.st/Pharo-Success-story-MultiCity-tp4837716p4837880.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Am 16.07.2015 um 21:24 schrieb Paul DeBruicker <pdebruic@gmail.com>:
Are you using SMS at all?
Yes, we do use sms. One of our services is to reduce prices on messaging through message routing. As we know who can receive a push notification and who does not we can reach all users sending smses only for those who cannot. But in this particular project it is notification only. Norbert
NorbertHartl wrote
Am 16.07.2015 um 12:36 schrieb Norbert Hartl <
norbert@
>:
That's roughly it. In the whole process there are 8 pharo images involved but 2 are for redundancy so it is 6 different images.
To clarify on that. There are two images load balanced for the registry services. Two load balanced for the event stuff. Each one for sending apple push notifications, google cloud messages and windows messages. And there is a single image for this project.
Norbert
-- View this message in context: http://forum.world.st/Pharo-Success-story-MultiCity-tp4837716p4837880.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (4)
-
Norbert Hartl -
Paul DeBruicker -
phil＠highoctane.be -
Torsten Bergmann