Hi, Given that the mailing lists are often used to ask questions when we get in trouble, report bugs and other issues, conduct public discussion between strong headed individuals, we quickly forget what a fantastic platform Pharo is. Last month I implemented a rough MVP-style ticket sales platform that was successfully used to sell and validate at the entrance, about 1000 digital, online tickets for a relatively large 3000+ attendance event (a party). It took only a couple of days to build and deploy, and it was a lot of fun - it was even done in 'unstable' Pharo 7. Early on I decided to identify each individual ticket by a unique URL. For easier presentation and scanning purposes, I encoded that URL in a QR code. Although I am grateful for the whole Pharo ecosystem (including Seaside), we all build on top of other people's work, I was especially happy with Jochen Rick's QRCode package (http://smalltalkhub.com/#!/~JochenRick/QRCode/). This is such a great piece of work ! It worked right out of the box in Pharo 7 (even though it is from 2013/2014), was well designed, easy to figure out, was well documented, had unit tests. I can't say anything bad about it, it is as close to perfect as I have ever seen. So: thanks Jochen, you made my day ! Here is how a ticket generates its own QR code: T123Ticket>>#asQRCode ^ self url asString asQRCode formWithQuietZone magnifyBy: 5 Just beautiful. It is also easy (for a non-graphics, non-UI person like me) to combine the QR code with some text: T123Ticket >>#asQRCodeWithText | form font | form := Form extent: 535 @ 185 depth: 1. font := LogicalFont familyName: 'Bitmap DejaVu Sans' pointSize: 14. self asQRCode displayOn: form at: 0 @ 0. form getCanvas drawString: self url asString at: 180 @ 20 font: font color: Color black; drawString: self id36, ' - ', ticketId asString at: 180 @ 45 font: font color: Color black; drawString: (name ifNil: [ 'N.N' ]) at: 180 @ 90 font: font color: Color black; drawString: (email ifNil: [ '@' ]) at: 180 @ 115 font: font color: Color black; drawString: (phone ifNil: [ '+' ]) at: 180 @ 140 font: font color: Color black. ^ form Next we combine this with a nice template designed by a graphics artist: T123Ticket >>#asQRCodeWithTextInTemplate | templateFile form | templateFile := 'tickets123-template-{1}.jpg' format: { self event id }. form := PluginBasedJPEGReadWriter formFromFileNamed: templateFile. self asQRCodeWithText displayOn: form at: 20@540. ^ form And finally, the ticket form is encoded as a JPEG (to be mailed and so on): T123Ticket >>#asJPEGBytes ^ ByteArray streamContents: [ :out | PluginBasedJPEGReadWriter putForm: self asQRCodeWithTextInTemplate onStream: out ] I also found GT Inspector very handy (again) in doing back end work (managing payments and other administration), especially the ability to use Spotter on a collection open in an inspector. Anyway, I know many of you have similar happy experiences, I just wanted to share (one of) mine. Thanks Jochen, thanks everyone. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Thanks Sven Yes QRCode is nice. Once I wanted to see if I could produce a pdf version for artefact and when I read the spec I stopped. And yes sometimes the atmosphere of this mailing-list is telling me to stay away from it. So thanks for your nice mail and energy. And thanks for your super cool libraries. Today we had a good laugh with Santiago because we will build a smart contracts corpus and use STON to save them (too easy ;P) Stef On Fri, Apr 13, 2018 at 8:47 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
Given that the mailing lists are often used to ask questions when we get in trouble, report bugs and other issues, conduct public discussion between strong headed individuals, we quickly forget what a fantastic platform Pharo is.
Last month I implemented a rough MVP-style ticket sales platform that was successfully used to sell and validate at the entrance, about 1000 digital, online tickets for a relatively large 3000+ attendance event (a party). It took only a couple of days to build and deploy, and it was a lot of fun - it was even done in 'unstable' Pharo 7.
Early on I decided to identify each individual ticket by a unique URL. For easier presentation and scanning purposes, I encoded that URL in a QR code.
Although I am grateful for the whole Pharo ecosystem (including Seaside), we all build on top of other people's work, I was especially happy with Jochen Rick's QRCode package (http://smalltalkhub.com/#!/~ JochenRick/QRCode/). This is such a great piece of work !
It worked right out of the box in Pharo 7 (even though it is from 2013/2014), was well designed, easy to figure out, was well documented, had unit tests. I can't say anything bad about it, it is as close to perfect as I have ever seen. So: thanks Jochen, you made my day !
Here is how a ticket generates its own QR code:
T123Ticket>>#asQRCode ^ self url asString asQRCode formWithQuietZone magnifyBy: 5
Just beautiful.
It is also easy (for a non-graphics, non-UI person like me) to combine the QR code with some text:
T123Ticket >>#asQRCodeWithText | form font | form := Form extent: 535 @ 185 depth: 1. font := LogicalFont familyName: 'Bitmap DejaVu Sans' pointSize: 14. self asQRCode displayOn: form at: 0 @ 0. form getCanvas drawString: self url asString at: 180 @ 20 font: font color: Color black; drawString: self id36, ' - ', ticketId asString at: 180 @ 45 font: font color: Color black; drawString: (name ifNil: [ 'N.N' ]) at: 180 @ 90 font: font color: Color black; drawString: (email ifNil: [ '@' ]) at: 180 @ 115 font: font color: Color black; drawString: (phone ifNil: [ '+' ]) at: 180 @ 140 font: font color: Color black. ^ form
Next we combine this with a nice template designed by a graphics artist:
T123Ticket >>#asQRCodeWithTextInTemplate | templateFile form | templateFile := 'tickets123-template-{1}.jpg' format: { self event id }. form := PluginBasedJPEGReadWriter formFromFileNamed: templateFile. self asQRCodeWithText displayOn: form at: 20@540. ^ form
And finally, the ticket form is encoded as a JPEG (to be mailed and so on):
T123Ticket >>#asJPEGBytes ^ ByteArray streamContents: [ :out | PluginBasedJPEGReadWriter putForm: self asQRCodeWithTextInTemplate onStream: out ]
I also found GT Inspector very handy (again) in doing back end work (managing payments and other administration), especially the ability to use Spotter on a collection open in an inspector.
Anyway, I know many of you have similar happy experiences, I just wanted to share (one of) mine.
Thanks Jochen, thanks everyone.
Sven
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Sven Van Caekenberghe-2 wrote
Thanks Jochen, thanks everyone.
Great report! Thanks, Sven :) I was thinking in the same direction - that my posts always seem to focus on our work moving forward, and I rarely take the time to do a nice writeup of successful applications like these, of which I've had many. I was also thinking that many of the recent animated discussions are signs of health in our community because: a) They seem to often involve people that are not regular posters to the list, signaling a potential widening of buy-in b) While our community values constructive feedback (even if it's very direct), it also fiercely protects people who have given us a lot (as evidenced by the overwhelming response to a recent trolling on another ML) c) Maybe most important: they are often about code and infrastructure that didn't even *exist* a few years ago. For example, now we complain about breaking builds; I'm sure we all remember not long ago when there was *no* CI at all to complain about! It seems amazing that the system is as stable as it is considering everything we overhauled/invented, including: streams, http, file system, browser (2x), git support, FFI, changes, catalog, the compiler, GT⦠For myself, I am clear that any instability is a small price to pay for the power and hope that Pharo offers. Every time I drop out of our live, direct, turetles-all-the-way down into a Ruby script, command line, or configuration file, this is proven again. All we have to do is hang on! It is a well known principle that it often seem most difficult just before success and the difference is who quits and who doesn't :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On 14 April 2018 at 22:15, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
Thanks Jochen, thanks everyone.
Great report! Thanks, Sven :) I was thinking in the same direction - that my posts always seem to focus on our work moving forward, and I rarely take the time to do a nice writeup of successful applications like these, of which I've had many.
I was also thinking that many of the recent animated discussions are signs of health in our community
I recently came across an interesting hypothesis... "There are two types of programming languages. Those that people complain about, and those that people don't use." Is it masochistic to hope we are moving towards the former?
because:
a) They seem to often involve people that are not regular posters to the
list, signaling a potential widening of buy-in
While there is likely a growing need to guard against trolls, consider that newcomers may commit limited time to posting, be hurting and lash out, and with fresh eyes, may be poking us where it hurts. For us, don't take it personally. If we focus our response on the technical aspects, we lead the discussion where we want it to go. The easiest thing for a Pharo newcomer to do when experiencing problems is to just drop it and move on to something else. That they put in the effort to articulate their issues is a good thing, and are the seeds of a contributor concerned with making Pharo better. For newcomers, remember that many people have invested a lot of volunteer effort into Pharo and is something dear to our hearts. We love specific *constructive* feedback that helps us make Pharo better, but broad complaints only detract with little benefit. cheers -ben P.S. Years ago, this article was influential to me... http://www.catb.org/esr/faqs/smart-questions.html
b) While our community values constructive feedback (even if it's very direct), it also fiercely protects people who have given us a lot (as evidenced by the overwhelming response to a recent trolling on another ML) c) Maybe most important: they are often about code and infrastructure that didn't even *exist* a few years ago. For example, now we complain about breaking builds; I'm sure we all remember not long ago when there was *no* CI at all to complain about! It seems amazing that the system is as stable as it is considering everything we overhauled/invented, including: streams, http, file system, browser (2x), git support, FFI, changes, catalog, the compiler, GTâ¦
For myself, I am clear that any instability is a small price to pay for the power and hope that Pharo offers. Every time I drop out of our live, direct, turetles-all-the-way down into a Ruby script, command line, or configuration file, this is proven again.
All we have to do is hang on! It is a well known principle that it often seem most difficult just before success and the difference is who quits and who doesn't :)
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Sven, Thanks a lot for the positive message! Indeed, it is a much needed perspective, and I am sure there are many other similar examples. Btw, nice work, too :). Cheers, Doru
On Apr 13, 2018, at 8:47 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
Given that the mailing lists are often used to ask questions when we get in trouble, report bugs and other issues, conduct public discussion between strong headed individuals, we quickly forget what a fantastic platform Pharo is.
Last month I implemented a rough MVP-style ticket sales platform that was successfully used to sell and validate at the entrance, about 1000 digital, online tickets for a relatively large 3000+ attendance event (a party). It took only a couple of days to build and deploy, and it was a lot of fun - it was even done in 'unstable' Pharo 7.
Early on I decided to identify each individual ticket by a unique URL. For easier presentation and scanning purposes, I encoded that URL in a QR code.
Although I am grateful for the whole Pharo ecosystem (including Seaside), we all build on top of other people's work, I was especially happy with Jochen Rick's QRCode package (http://smalltalkhub.com/#!/~JochenRick/QRCode/). This is such a great piece of work !
It worked right out of the box in Pharo 7 (even though it is from 2013/2014), was well designed, easy to figure out, was well documented, had unit tests. I can't say anything bad about it, it is as close to perfect as I have ever seen. So: thanks Jochen, you made my day !
Here is how a ticket generates its own QR code:
T123Ticket>>#asQRCode ^ self url asString asQRCode formWithQuietZone magnifyBy: 5
Just beautiful.
It is also easy (for a non-graphics, non-UI person like me) to combine the QR code with some text:
T123Ticket >>#asQRCodeWithText | form font | form := Form extent: 535 @ 185 depth: 1. font := LogicalFont familyName: 'Bitmap DejaVu Sans' pointSize: 14. self asQRCode displayOn: form at: 0 @ 0. form getCanvas drawString: self url asString at: 180 @ 20 font: font color: Color black; drawString: self id36, ' - ', ticketId asString at: 180 @ 45 font: font color: Color black; drawString: (name ifNil: [ 'N.N' ]) at: 180 @ 90 font: font color: Color black; drawString: (email ifNil: [ '@' ]) at: 180 @ 115 font: font color: Color black; drawString: (phone ifNil: [ '+' ]) at: 180 @ 140 font: font color: Color black. ^ form
Next we combine this with a nice template designed by a graphics artist:
T123Ticket >>#asQRCodeWithTextInTemplate | templateFile form | templateFile := 'tickets123-template-{1}.jpg' format: { self event id }. form := PluginBasedJPEGReadWriter formFromFileNamed: templateFile. self asQRCodeWithText displayOn: form at: 20@540. ^ form
And finally, the ticket form is encoded as a JPEG (to be mailed and so on):
T123Ticket >>#asJPEGBytes ^ ByteArray streamContents: [ :out | PluginBasedJPEGReadWriter putForm: self asQRCodeWithTextInTemplate onStream: out ]
<Screen Shot 2018-04-13 at 20.40.54.png>
I also found GT Inspector very handy (again) in doing back end work (managing payments and other administration), especially the ability to use Spotter on a collection open in an inspector.
Anyway, I know many of you have similar happy experiences, I just wanted to share (one of) mine.
Thanks Jochen, thanks everyone.
Sven
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
-- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."
participants (5)
-
Ben Coman -
Sean P. DeNigris -
Stephane Ducasse -
Sven Van Caekenberghe -
Tudor Girba