New Pharo based solution in the wild
Hi all, After one year of negotiations (demos, quotes, etc.) and a couple of months of development, by the end of December we released a pilot version of our pharo based solution. The solution consists of a native mobile app (Android), with Pharo 2.0 servers, using Seaside for the web UI, Seaside-REST for the mobile app API and Zinc Websockets to certain "live" features of the web. The persistence is GLORP using the native PostgreSQL driver. I can't disclose much more about the customer or the solution yet, it is a private solution for a multinational consumer goods company operating in Argentina. But I can comment on the numbers: * The pilot will end in ~40 days * It involves 50 mobile users of the Android app using it daily. * An nginx frontend for static files and http proxying to the pharo app servers * Two pharo images as servers, one for the web interface, and one for the REST API. The image is the same, they work as two separate app servers to make use of each server and for improved reliability (I don't want the seaside failures, which has been none yet, to affect the REST API). * Everything running in DigitalOcean droplets based in NYC (they add ~180ms of latency from here but their price/value equations is unmatched). Some performance numbers: * The Pharo server uptime has been no less than perfect, the first 10 days with uninterrupted uptime. Only shutdown to upgrade the image (yesterday night). * The load is minor, with peaks of ~30 concurrent mobile users during a few "business" moments of the day, the server never passed 15% of CPU use. The disk I/O is also small, but the database is small too (growing daily). If the pilot succeeds the plan is to extend the user base to ~1000 mobile users. But some water must pass under the bridge before thinking of that. And if it ever happens, it is going to be gradual. Some anecdotal info I quit my Smalltalk full time job at InfOil (after 9 years of employment) to dedicate 100% to my new company. So I'm betting big on this. By now I'm the sole Smalltalk developer (devops?) of the company. Time has never been more scarce than nowadays. Why Pharo? * Because it is the best open source Smalltalk ("inspired") out there. * Because I have 10+ years of experience with Smalltalk I can't throw away in the context of rapid prototyping and business domain modelling (emphasis on this). * It was a key advantage during the negotiations, we could show a wireframed live app even before our competition prepared a PowerPoint presentation. The development process with Pharo has been rudimentary, only Monticello packages and a couple of workspace scripts to provision new images. I still can't get my head around Metacello. But honestly I haven't dedicated as much time as it needs to be learnt. Having used VAST ENVY's ConfigurationMaps successfully in the past is a proof I can learn Metacello. During the last years at InfOil we were using git with Dolphin Smalltalk, with CI after every git push to the main repo. This was also linked with our issue tracking system, in order to know in which build a certain issue was fixed. We used Dolphin's PAX's files (CVS friendly), Gitlab, JetBrain's TeamCity and YouTrack I'd like to do the same using Monticello's FileTree, BitBucket and JIRA (CI server to be defined). Hopefully with some time, I'll be able to dive deeper into this. My learning of Pharo tooling hasn't been straightforward, but maybe because I'm old and spoiled with other Smalltalk dialects (VSE, VAST, Dolphin). I was managing the Android code (java) with git branching and merging way before I learnt how to use Monticello. Managing the code (files) was the only advantage of working with Eclipse/Java. Everything else was a burden compared with Pharo. I wanted to share my experiences through a blog, but haven't had time to set it up as I'd like, and by now this email is going to be all I can share. After the pilot, we can talk about reporting a success story for Pharo. I felt like this during the last week: http://devopsreactions.tumblr.com/post/68251866244/successful-deployment-at-... Best regards, Esteban A. Maringolo CTO (aka DevOps), http://trentosur.com
Esteban A. Maringolo wrote
After one year of negotiations (demos, quotes, etc.) and a couple of months of development, by the end of December we released a pilot version of our pharo based solution.
Thanks for sharing all that! Very exciting. Good luck and keep us posted... ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Pharo-based-solution-in-the-wild-tp4734212p4734216... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Thanks you, Esteban. This is a wonderful story. Could this be posted on the Pharo blog? I love this quote: "It was a key advantage during the negotiations, we could show a wireframed live app even before our competition prepared a PowerPoint presentation." :) Keep it up, and let us know if we can help. We need success stories like this one. Cheers, Doru On Sat, Jan 4, 2014 at 8:16 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
Hi all,
After one year of negotiations (demos, quotes, etc.) and a couple of months of development, by the end of December we released a pilot version of our pharo based solution. The solution consists of a native mobile app (Android), with Pharo 2.0 servers, using Seaside for the web UI, Seaside-REST for the mobile app API and Zinc Websockets to certain "live" features of the web. The persistence is GLORP using the native PostgreSQL driver.
I can't disclose much more about the customer or the solution yet, it is a private solution for a multinational consumer goods company operating in Argentina.
But I can comment on the numbers: * The pilot will end in ~40 days * It involves 50 mobile users of the Android app using it daily. * An nginx frontend for static files and http proxying to the pharo app servers * Two pharo images as servers, one for the web interface, and one for the REST API. The image is the same, they work as two separate app servers to make use of each server and for improved reliability (I don't want the seaside failures, which has been none yet, to affect the REST API). * Everything running in DigitalOcean droplets based in NYC (they add ~180ms of latency from here but their price/value equations is unmatched).
Some performance numbers: * The Pharo server uptime has been no less than perfect, the first 10 days with uninterrupted uptime. Only shutdown to upgrade the image (yesterday night). * The load is minor, with peaks of ~30 concurrent mobile users during a few "business" moments of the day, the server never passed 15% of CPU use. The disk I/O is also small, but the database is small too (growing daily).
If the pilot succeeds the plan is to extend the user base to ~1000 mobile users. But some water must pass under the bridge before thinking of that. And if it ever happens, it is going to be gradual.
Some anecdotal info I quit my Smalltalk full time job at InfOil (after 9 years of employment) to dedicate 100% to my new company. So I'm betting big on this. By now I'm the sole Smalltalk developer (devops?) of the company. Time has never been more scarce than nowadays.
Why Pharo? * Because it is the best open source Smalltalk ("inspired") out there. * Because I have 10+ years of experience with Smalltalk I can't throw away in the context of rapid prototyping and business domain modelling (emphasis on this). * It was a key advantage during the negotiations, we could show a wireframed live app even before our competition prepared a PowerPoint presentation.
The development process with Pharo has been rudimentary, only Monticello packages and a couple of workspace scripts to provision new images. I still can't get my head around Metacello. But honestly I haven't dedicated as much time as it needs to be learnt. Having used VAST ENVY's ConfigurationMaps successfully in the past is a proof I can learn Metacello.
During the last years at InfOil we were using git with Dolphin Smalltalk, with CI after every git push to the main repo. This was also linked with our issue tracking system, in order to know in which build a certain issue was fixed. We used Dolphin's PAX's files (CVS friendly), Gitlab, JetBrain's TeamCity and YouTrack I'd like to do the same using Monticello's FileTree, BitBucket and JIRA (CI server to be defined).
Hopefully with some time, I'll be able to dive deeper into this. My learning of Pharo tooling hasn't been straightforward, but maybe because I'm old and spoiled with other Smalltalk dialects (VSE, VAST, Dolphin). I was managing the Android code (java) with git branching and merging way before I learnt how to use Monticello. Managing the code (files) was the only advantage of working with Eclipse/Java. Everything else was a burden compared with Pharo.
I wanted to share my experiences through a blog, but haven't had time to set it up as I'd like, and by now this email is going to be all I can share. After the pilot, we can talk about reporting a success story for Pharo. I felt like this during the last week:
http://devopsreactions.tumblr.com/post/68251866244/successful-deployment-at-...
Best regards,
Esteban A. Maringolo CTO (aka DevOps), http://trentosur.com
-- www.tudorgirba.com "Every thing has its own flow"
thanks for sharing that with us. We are happy. I want to share this story with you. I hope one day it will be public for real. I will tell you what a guy in bank in a east european country told me: For his first Smalltalk application he used Pharo 1.4 + magritte + seaside + fuel It took him 3 months of work and only three forms where coded by hand :) The business unit asked before the IT groups there and the estimate were 1.5 year in C# and 2 years in Java. It passed all the security tests of the bank. Now another bank is interested :) Stef On 04 Jan 2014, at 20:16, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi all,
After one year of negotiations (demos, quotes, etc.) and a couple of months of development, by the end of December we released a pilot version of our pharo based solution. The solution consists of a native mobile app (Android), with Pharo 2.0 servers, using Seaside for the web UI, Seaside-REST for the mobile app API and Zinc Websockets to certain "live" features of the web. The persistence is GLORP using the native PostgreSQL driver.
I can't disclose much more about the customer or the solution yet, it is a private solution for a multinational consumer goods company operating in Argentina.
But I can comment on the numbers: * The pilot will end in ~40 days * It involves 50 mobile users of the Android app using it daily. * An nginx frontend for static files and http proxying to the pharo app servers * Two pharo images as servers, one for the web interface, and one for the REST API. The image is the same, they work as two separate app servers to make use of each server and for improved reliability (I don't want the seaside failures, which has been none yet, to affect the REST API). * Everything running in DigitalOcean droplets based in NYC (they add ~180ms of latency from here but their price/value equations is unmatched).
Some performance numbers: * The Pharo server uptime has been no less than perfect, the first 10 days with uninterrupted uptime. Only shutdown to upgrade the image (yesterday night). * The load is minor, with peaks of ~30 concurrent mobile users during a few "business" moments of the day, the server never passed 15% of CPU use. The disk I/O is also small, but the database is small too (growing daily).
If the pilot succeeds the plan is to extend the user base to ~1000 mobile users. But some water must pass under the bridge before thinking of that. And if it ever happens, it is going to be gradual.
Some anecdotal info I quit my Smalltalk full time job at InfOil (after 9 years of employment) to dedicate 100% to my new company. So I'm betting big on this. By now I'm the sole Smalltalk developer (devops?) of the company. Time has never been more scarce than nowadays.
Why Pharo? * Because it is the best open source Smalltalk ("inspired") out there. * Because I have 10+ years of experience with Smalltalk I can't throw away in the context of rapid prototyping and business domain modelling (emphasis on this). * It was a key advantage during the negotiations, we could show a wireframed live app even before our competition prepared a PowerPoint presentation.
The development process with Pharo has been rudimentary, only Monticello packages and a couple of workspace scripts to provision new images. I still can't get my head around Metacello. But honestly I haven't dedicated as much time as it needs to be learnt. Having used VAST ENVY's ConfigurationMaps successfully in the past is a proof I can learn Metacello.
During the last years at InfOil we were using git with Dolphin Smalltalk, with CI after every git push to the main repo. This was also linked with our issue tracking system, in order to know in which build a certain issue was fixed. We used Dolphin's PAX's files (CVS friendly), Gitlab, JetBrain's TeamCity and YouTrack I'd like to do the same using Monticello's FileTree, BitBucket and JIRA (CI server to be defined).
Hopefully with some time, I'll be able to dive deeper into this. My learning of Pharo tooling hasn't been straightforward, but maybe because I'm old and spoiled with other Smalltalk dialects (VSE, VAST, Dolphin). I was managing the Android code (java) with git branching and merging way before I learnt how to use Monticello. Managing the code (files) was the only advantage of working with Eclipse/Java. Everything else was a burden compared with Pharo.
I wanted to share my experiences through a blog, but haven't had time to set it up as I'd like, and by now this email is going to be all I can share. After the pilot, we can talk about reporting a success story for Pharo. I felt like this during the last week: http://devopsreactions.tumblr.com/post/68251866244/successful-deployment-at-...
Best regards,
Esteban A. Maringolo CTO (aka DevOps), http://trentosur.com
Great, impressive work, Esteban, thanks for sharing. I wish you luck in completing your pilot. Let us known if you need help in critical areas. Sven On 04 Jan 2014, at 20:16, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi all,
After one year of negotiations (demos, quotes, etc.) and a couple of months of development, by the end of December we released a pilot version of our pharo based solution. The solution consists of a native mobile app (Android), with Pharo 2.0 servers, using Seaside for the web UI, Seaside-REST for the mobile app API and Zinc Websockets to certain "live" features of the web. The persistence is GLORP using the native PostgreSQL driver.
I can't disclose much more about the customer or the solution yet, it is a private solution for a multinational consumer goods company operating in Argentina.
But I can comment on the numbers: * The pilot will end in ~40 days * It involves 50 mobile users of the Android app using it daily. * An nginx frontend for static files and http proxying to the pharo app servers * Two pharo images as servers, one for the web interface, and one for the REST API. The image is the same, they work as two separate app servers to make use of each server and for improved reliability (I don't want the seaside failures, which has been none yet, to affect the REST API). * Everything running in DigitalOcean droplets based in NYC (they add ~180ms of latency from here but their price/value equations is unmatched).
Some performance numbers: * The Pharo server uptime has been no less than perfect, the first 10 days with uninterrupted uptime. Only shutdown to upgrade the image (yesterday night). * The load is minor, with peaks of ~30 concurrent mobile users during a few "business" moments of the day, the server never passed 15% of CPU use. The disk I/O is also small, but the database is small too (growing daily).
If the pilot succeeds the plan is to extend the user base to ~1000 mobile users. But some water must pass under the bridge before thinking of that. And if it ever happens, it is going to be gradual.
Some anecdotal info I quit my Smalltalk full time job at InfOil (after 9 years of employment) to dedicate 100% to my new company. So I'm betting big on this. By now I'm the sole Smalltalk developer (devops?) of the company. Time has never been more scarce than nowadays.
Why Pharo? * Because it is the best open source Smalltalk ("inspired") out there. * Because I have 10+ years of experience with Smalltalk I can't throw away in the context of rapid prototyping and business domain modelling (emphasis on this). * It was a key advantage during the negotiations, we could show a wireframed live app even before our competition prepared a PowerPoint presentation.
The development process with Pharo has been rudimentary, only Monticello packages and a couple of workspace scripts to provision new images. I still can't get my head around Metacello. But honestly I haven't dedicated as much time as it needs to be learnt. Having used VAST ENVY's ConfigurationMaps successfully in the past is a proof I can learn Metacello.
During the last years at InfOil we were using git with Dolphin Smalltalk, with CI after every git push to the main repo. This was also linked with our issue tracking system, in order to know in which build a certain issue was fixed. We used Dolphin's PAX's files (CVS friendly), Gitlab, JetBrain's TeamCity and YouTrack I'd like to do the same using Monticello's FileTree, BitBucket and JIRA (CI server to be defined).
Hopefully with some time, I'll be able to dive deeper into this. My learning of Pharo tooling hasn't been straightforward, but maybe because I'm old and spoiled with other Smalltalk dialects (VSE, VAST, Dolphin). I was managing the Android code (java) with git branching and merging way before I learnt how to use Monticello. Managing the code (files) was the only advantage of working with Eclipse/Java. Everything else was a burden compared with Pharo.
I wanted to share my experiences through a blog, but haven't had time to set it up as I'd like, and by now this email is going to be all I can share. After the pilot, we can talk about reporting a success story for Pharo. I felt like this during the last week: http://devopsreactions.tumblr.com/post/68251866244/successful-deployment-at-...
Best regards,
Esteban A. Maringolo CTO (aka DevOps), http://trentosur.com
Hi all, I'm bumping this thread with sad news. Unfortunately this solution was decommissioned more than two months ago, after more than one and a half year of perfect uptime and no technical nor user-requested features shortcomings. The reasons given weren't technical, it had more to do with a change of our customer's top manager, who also was it's internal sponsor. The new management "inherited" this ongoing project which wasn't fully deployed at that moment, and their stance regarding it wasn't as proactive as with the previous one. That plus the local economic woes during the last years created the ideal scenario for a budget cut that let us hanging. Had the project been fully deployed earlier, I guess the story would have been different. Also we heard that the new manager tried to replace our solution with one that "he brought" without success until now. I'm sharing this with you in order to update the Success section of Pharo's website. We still have the other small project, but it's future doesn't look promising either, the current context for it is similar with the added decline of sales (it's a mobile sales app). Regards, Esteban A. Maringolo ps: On the personal level these bad news were overly compensated with the birth of my first daughter two months ago. :) 2014-01-04 18:33 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
Great, impressive work, Esteban, thanks for sharing.
I wish you luck in completing your pilot.
Let us known if you need help in critical areas.
Sven
On 04 Jan 2014, at 20:16, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi all,
After one year of negotiations (demos, quotes, etc.) and a couple of months of development, by the end of December we released a pilot version of our pharo based solution. The solution consists of a native mobile app (Android), with Pharo 2.0 servers, using Seaside for the web UI, Seaside-REST for the mobile app API and Zinc Websockets to certain "live" features of the web. The persistence is GLORP using the native PostgreSQL driver.
I can't disclose much more about the customer or the solution yet, it is a private solution for a multinational consumer goods company operating in Argentina.
But I can comment on the numbers: * The pilot will end in ~40 days * It involves 50 mobile users of the Android app using it daily. * An nginx frontend for static files and http proxying to the pharo app servers * Two pharo images as servers, one for the web interface, and one for the REST API. The image is the same, they work as two separate app servers to make use of each server and for improved reliability (I don't want the seaside failures, which has been none yet, to affect the REST API). * Everything running in DigitalOcean droplets based in NYC (they add ~180ms of latency from here but their price/value equations is unmatched).
Some performance numbers: * The Pharo server uptime has been no less than perfect, the first 10 days with uninterrupted uptime. Only shutdown to upgrade the image (yesterday night). * The load is minor, with peaks of ~30 concurrent mobile users during a few "business" moments of the day, the server never passed 15% of CPU use. The disk I/O is also small, but the database is small too (growing daily).
If the pilot succeeds the plan is to extend the user base to ~1000 mobile users. But some water must pass under the bridge before thinking of that. And if it ever happens, it is going to be gradual.
Some anecdotal info I quit my Smalltalk full time job at InfOil (after 9 years of employment) to dedicate 100% to my new company. So I'm betting big on this. By now I'm the sole Smalltalk developer (devops?) of the company. Time has never been more scarce than nowadays.
Why Pharo? * Because it is the best open source Smalltalk ("inspired") out there. * Because I have 10+ years of experience with Smalltalk I can't throw away in the context of rapid prototyping and business domain modelling (emphasis on this). * It was a key advantage during the negotiations, we could show a wireframed live app even before our competition prepared a PowerPoint presentation.
The development process with Pharo has been rudimentary, only Monticello packages and a couple of workspace scripts to provision new images. I still can't get my head around Metacello. But honestly I haven't dedicated as much time as it needs to be learnt. Having used VAST ENVY's ConfigurationMaps successfully in the past is a proof I can learn Metacello.
During the last years at InfOil we were using git with Dolphin Smalltalk, with CI after every git push to the main repo. This was also linked with our issue tracking system, in order to know in which build a certain issue was fixed. We used Dolphin's PAX's files (CVS friendly), Gitlab, JetBrain's TeamCity and YouTrack I'd like to do the same using Monticello's FileTree, BitBucket and JIRA (CI server to be defined).
Hopefully with some time, I'll be able to dive deeper into this. My learning of Pharo tooling hasn't been straightforward, but maybe because I'm old and spoiled with other Smalltalk dialects (VSE, VAST, Dolphin). I was managing the Android code (java) with git branching and merging way before I learnt how to use Monticello. Managing the code (files) was the only advantage of working with Eclipse/Java. Everything else was a burden compared with Pharo.
I wanted to share my experiences through a blog, but haven't had time to set it up as I'd like, and by now this email is going to be all I can share. After the pilot, we can talk about reporting a success story for Pharo. I felt like this during the last week:
http://devopsreactions.tumblr.com/post/68251866244/successful-deployment-at-...
Best regards,
Esteban A. Maringolo CTO (aka DevOps), http://trentosur.com
Hi Esteban, Sad news about the app indeed. It is true that time to market is key to adoption. Nevertheless, I wish you well for the future. Keep in touch via other channels. Phil On Tue, Sep 8, 2015 at 5:16 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi all,
I'm bumping this thread with sad news.
Unfortunately this solution was decommissioned more than two months ago, after more than one and a half year of perfect uptime and no technical nor user-requested features shortcomings.
The reasons given weren't technical, it had more to do with a change of our customer's top manager, who also was it's internal sponsor. The new management "inherited" this ongoing project which wasn't fully deployed at that moment, and their stance regarding it wasn't as proactive as with the previous one. That plus the local economic woes during the last years created the ideal scenario for a budget cut that let us hanging.
Had the project been fully deployed earlier, I guess the story would have been different. Also we heard that the new manager tried to replace our solution with one that "he brought" without success until now.
I'm sharing this with you in order to update the Success section of Pharo's website. We still have the other small project, but it's future doesn't look promising either, the current context for it is similar with the added decline of sales (it's a mobile sales app).
Regards,
Esteban A. Maringolo
ps: On the personal level these bad news were overly compensated with the birth of my first daughter two months ago. :)
2014-01-04 18:33 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
Great, impressive work, Esteban, thanks for sharing.
I wish you luck in completing your pilot.
Let us known if you need help in critical areas.
Sven
On 04 Jan 2014, at 20:16, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi all,
After one year of negotiations (demos, quotes, etc.) and a couple of months of development, by the end of December we released a pilot version of our pharo based solution. The solution consists of a native mobile app (Android), with Pharo 2.0 servers, using Seaside for the web UI, Seaside-REST for the mobile app API and Zinc Websockets to certain "live" features of the web. The persistence is GLORP using the native PostgreSQL driver.
I can't disclose much more about the customer or the solution yet, it is a private solution for a multinational consumer goods company operating in Argentina.
But I can comment on the numbers: * The pilot will end in ~40 days * It involves 50 mobile users of the Android app using it daily. * An nginx frontend for static files and http proxying to the pharo app servers * Two pharo images as servers, one for the web interface, and one for the REST API. The image is the same, they work as two separate app servers to make use of each server and for improved reliability (I don't want the seaside failures, which has been none yet, to affect the REST API). * Everything running in DigitalOcean droplets based in NYC (they add ~180ms of latency from here but their price/value equations is unmatched).
Some performance numbers: * The Pharo server uptime has been no less than perfect, the first 10 days with uninterrupted uptime. Only shutdown to upgrade the image (yesterday night). * The load is minor, with peaks of ~30 concurrent mobile users during a few "business" moments of the day, the server never passed 15% of CPU use. The disk I/O is also small, but the database is small too (growing daily).
If the pilot succeeds the plan is to extend the user base to ~1000 mobile users. But some water must pass under the bridge before thinking of that. And if it ever happens, it is going to be gradual.
Some anecdotal info I quit my Smalltalk full time job at InfOil (after 9 years of employment) to dedicate 100% to my new company. So I'm betting big on this. By now I'm the sole Smalltalk developer (devops?) of the company. Time has never been more scarce than nowadays.
Why Pharo? * Because it is the best open source Smalltalk ("inspired") out there. * Because I have 10+ years of experience with Smalltalk I can't throw away in the context of rapid prototyping and business domain modelling (emphasis on this). * It was a key advantage during the negotiations, we could show a wireframed live app even before our competition prepared a PowerPoint presentation.
The development process with Pharo has been rudimentary, only Monticello packages and a couple of workspace scripts to provision new images. I still can't get my head around Metacello. But honestly I haven't dedicated as much time as it needs to be learnt. Having used VAST ENVY's ConfigurationMaps successfully in the past is a proof I can learn Metacello.
During the last years at InfOil we were using git with Dolphin Smalltalk, with CI after every git push to the main repo. This was also linked with our issue tracking system, in order to know in which build a certain issue was fixed. We used Dolphin's PAX's files (CVS friendly), Gitlab, JetBrain's TeamCity and YouTrack I'd like to do the same using Monticello's FileTree, BitBucket and JIRA (CI server to be defined).
Hopefully with some time, I'll be able to dive deeper into this. My learning of Pharo tooling hasn't been straightforward, but maybe because I'm old and spoiled with other Smalltalk dialects (VSE, VAST, Dolphin). I was managing the Android code (java) with git branching and merging way before I learnt how to use Monticello. Managing the code (files) was the only advantage of working with Eclipse/Java. Everything else was a burden compared with Pharo.
I wanted to share my experiences through a blog, but haven't had time to set it up as I'd like, and by now this email is going to be all I can share. After the pilot, we can talk about reporting a success story for Pharo. I felt like this during the last week:
http://devopsreactions.tumblr.com/post/68251866244/successful-deployment-at-...
Best regards,
Esteban A. Maringolo CTO (aka DevOps), http://trentosur.com
Le 08/09/2015 17:16, Esteban A. Maringolo a écrit :
ps: On the personal level these bad news were overly compensated with the birth of my first daughter two months ago. :)
Congratualtion! Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu
On 08 Sep 2015, at 19:51, Hilaire <hilaire@drgeo.eu> wrote:
Le 08/09/2015 17:16, Esteban A. Maringolo a écrit :
ps: On the personal level these bad news were overly compensated with the birth of my first daughter two months ago. :)
Congratualtion!
Yeah !
Hilaire
-- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu
Hi Esteban Two points: - I'm sad for you. - You still have a success story. This is not because one guy got fired and another came into the place and administratively killed your project that this is a failure from Pharo perspective. We are really happy that our techno helped you. Stef Le 8/9/15 17:16, Esteban A. Maringolo a écrit :
Hi all,
I'm bumping this thread with sad news.
Unfortunately this solution was decommissioned more than two months ago, after more than one and a half year of perfect uptime and no technical nor user-requested features shortcomings.
The reasons given weren't technical, it had more to do with a change of our customer's top manager, who also was it's internal sponsor. The new management "inherited" this ongoing project which wasn't fully deployed at that moment, and their stance regarding it wasn't as proactive as with the previous one. That plus the local economic woes during the last years created the ideal scenario for a budget cut that let us hanging.
Had the project been fully deployed earlier, I guess the story would have been different. Also we heard that the new manager tried to replace our solution with one that "he brought" without success until now.
I'm sharing this with you in order to update the Success section of Pharo's website. We still have the other small project, but it's future doesn't look promising either, the current context for it is similar with the added decline of sales (it's a mobile sales app).
Regards,
Esteban A. Maringolo
ps: On the personal level these bad news were overly compensated with the birth of my first daughter two months ago. :)
2014-01-04 18:33 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>>:
Great, impressive work, Esteban, thanks for sharing.
I wish you luck in completing your pilot.
Let us known if you need help in critical areas.
Sven
On 04 Jan 2014, at 20:16, Esteban A. Maringolo <emaringolo@gmail.com <mailto:emaringolo@gmail.com>> wrote:
> Hi all, > > After one year of negotiations (demos, quotes, etc.) and a couple of > months of development, by the end of December we released a pilot > version of our pharo based solution. > The solution consists of a native mobile app (Android), with Pharo 2.0 > servers, using Seaside for the web UI, Seaside-REST for the mobile app > API and Zinc Websockets to certain "live" features of the web. The > persistence is GLORP using the native PostgreSQL driver. > > I can't disclose much more about the customer or the solution yet, it > is a private solution for a multinational consumer goods company > operating in Argentina. > > But I can comment on the numbers: > * The pilot will end in ~40 days > * It involves 50 mobile users of the Android app using it daily. > * An nginx frontend for static files and http proxying to the pharo app servers > * Two pharo images as servers, one for the web interface, and one for > the REST API. The image is the same, they work as two separate app > servers to make use of each server and for improved reliability (I > don't want the seaside failures, which has been none yet, to affect > the REST API). > * Everything running in DigitalOcean droplets based in NYC (they add > ~180ms of latency from here but their price/value equations is > unmatched). > > Some performance numbers: > * The Pharo server uptime has been no less than perfect, the first 10 > days with uninterrupted uptime. Only shutdown to upgrade the image > (yesterday night). > * The load is minor, with peaks of ~30 concurrent mobile users during > a few "business" moments of the day, the server never passed 15% of > CPU use. The disk I/O is also small, but the database is small too > (growing daily). > > If the pilot succeeds the plan is to extend the user base to ~1000 > mobile users. But some water must pass under the bridge before > thinking of that. And if it ever happens, it is going to be gradual. > > Some anecdotal info > I quit my Smalltalk full time job at InfOil (after 9 years of > employment) to dedicate 100% to my new company. So I'm betting big on > this. By now I'm the sole Smalltalk developer (devops?) of the > company. Time has never been more scarce than nowadays. > > Why Pharo? > * Because it is the best open source Smalltalk ("inspired") out there. > * Because I have 10+ years of experience with Smalltalk I can't throw > away in the context of rapid prototyping and business domain modelling > (emphasis on this). > * It was a key advantage during the negotiations, we could show a > wireframed live app even before our competition prepared a PowerPoint > presentation. > > The development process with Pharo has been rudimentary, only > Monticello packages and a couple of workspace scripts to provision new > images. > I still can't get my head around Metacello. But honestly I haven't > dedicated as much time as it needs to be learnt. Having used VAST > ENVY's ConfigurationMaps successfully in the past is a proof I can > learn Metacello. > > During the last years at InfOil we were using git with Dolphin > Smalltalk, with CI after every git push to the main repo. This was > also linked with our issue tracking system, in order to know in which > build a certain issue was fixed. We used Dolphin's PAX's files (CVS > friendly), Gitlab, JetBrain's TeamCity and YouTrack > I'd like to do the same using Monticello's FileTree, BitBucket and > JIRA (CI server to be defined). > > Hopefully with some time, I'll be able to dive deeper into this. > My learning of Pharo tooling hasn't been straightforward, but maybe > because I'm old and spoiled with other Smalltalk dialects (VSE, VAST, > Dolphin). > I was managing the Android code (java) with git branching and merging > way before I learnt how to use Monticello. Managing the code (files) > was the only advantage of working with Eclipse/Java. Everything else > was a burden compared with Pharo. > > I wanted to share my experiences through a blog, but haven't had time > to set it up as I'd like, and by now this email is going to be all I > can share. After the pilot, we can talk about reporting a success > story for Pharo. I felt like this during the last week: > http://devopsreactions.tumblr.com/post/68251866244/successful-deployment-at-... > > > Best regards, > > Esteban A. Maringolo > CTO (aka DevOps), http://trentosur.com >
participants (8)
-
Esteban A. Maringolo -
Hilaire -
phil＠highoctane.be -
Sean P. DeNigris -
stepharo -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba