Suggestion about L.Prentice post open question

[12u...@gmail.com]

Hi all,

 

Weird: I received Lloyd's e-mail but don't have a trace of it in the group :(

 

Sooo, as groups do not look they're also working as a ML (may be it is because my posting address isn't the same as the subscription one, duno), here's my answer:

 

Hi Lloyd,
 
> Jesse and I have  been kicking around the idea of a series of shorter
> project-oriented books that could possibly reach across the remaining
> items on my list above. But time and energy are serious constraints so
> we would much appreciate ideas and involvement from the Nitrogen
> community.  
 
THAT is a great idea!
 
> What well-documented amazingly cool demo projects would you
> like to build or see built, published, and promoted?  
 
I recently saw a Jesse's video about his basketball site ( " Realtime Content Sync with Nitrogen's sync_panel element" : https://www.youtube.com/watch?v=eECzZTrn8ms ), when and where to use a comet general pool to get pages auto-update with nice zones
updating numbers, text and turning background green when the match was over.

 

It is impressive, but having such an example with the code written would be so much better than watching a video that you must stop every 20 seconds to take notes and more to try to understand the code structure.

 

This is indeed the kind of case where you can easily scratch your skull and lose a good deal of time before figuring how to do things right.
(disclaimer: I'm not a real programmer, much more a sunday one ;-p).

 

So, such an example would be welcome as it seems to concentrate all the things

that are useful on a site.

 

Another suggestion would be to add (or delegate to) a real pubsub to Nitrogen to be able to cope with thousands of updates, such as in an auction site (IIUC, using i.e. the ZMQ chumak app on the server would only need the JS browser code to be added (?)).

 
> One comment with regard to templates: I spent time earlier this year
> playing with markdown and Pandoc as a route toward rapid development
> of templates and fast prototyping of Nitrogen sites. Jesse has created
> an element in Ver. 2.4.0 to interface with Pandoc which, I believe
> opens up wide areas of application related to item 2 above. Happy to
> discuss if anyone is interested.  
 
It looks very interesting and promising ; with that, Nitrogen could easily replace a wiki/blog like dokuwiki, especially with the possibility to convert from a wiki page to an .odt document (i.e.: for printing internal documentation) - not to mention rapid prototyping (and why not, definitive site:). Too bad it is written in Haskell and not Erlang.

 

As mamazone.fr now has the book, I'm gonna order it tonight or tomorrow (but it'll be a full week before delivery :~)

 

Jean-Yves

[Jesse Gumm]

Hey Folks!

 

Weird: I received Lloyd's e-mail but don't have a trace of it in the group :(

Very odd. It does appear to be in here: https://groups.google.com/g/nitrogenweb/c/7MFRPyBJJks/m/HyisTBqRBgAJ So I'm not sure what happened to it from you.

 

 I recently saw a Jesse's video about his basketball site ( " Realtime Content Sync with Nitrogen's sync_panel element" : https://www.youtube.com/watch?v=eECzZTrn8ms ), when and where to use a comet general pool to get pages auto-update with nice zones

updating numbers, text and turning background green when the match was over.

 

It is impressive, but having such an example with the code written would be so much better than watching a video that you must stop every 20 seconds to take notes and more to try to understand the code structure.

Ha!  I completely forgot I made that video all those years back.

 

Another suggestion would be to add (or delegate to) a real pubsub to Nitrogen to be able to cope with thousands of updates, such as in an auction site (IIUC, using i.e. the ZMQ chumak app on the server would only need the JS browser code to be added (?)).

Reworking comet to be or support a pubsub is on the roadmap for Nitrogen 3.

 

It looks very interesting and promising ; with that, Nitrogen could easily replace a wiki/blog like dokuwiki, especially with the possibility to convert from a wiki page to an .odt document (i.e.: for printing internal documentation) - not to mention rapid prototyping (and why not, definitive site:). Too bad it is written in Haskell and not Erlang.

Indeed! So far, working with the pandoc support in the #template element has proven a pretty efficient way to go about it, and documentation.  I'm thankful for all the prodding from Lloyd to get that done :)

 

 As mamazone.fr now has the book, I'm gonna order it tonight or tomorrow (but it'll be a full week before delivery :~)

Awesome!

--

Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

[Lloyd R. Prentice]

Hi Jean-Yves,

Much appreciate your thoughts.

> (disclaimer: I'm not a real programmer, much more a sunday one ;-p).

I don’t consider myself a professional programmer either. One reason I like Nitrogen — I’m too lazy to learn JavaScript

> So, such an example would be welcome as it seems to concentrate all the things
> that are useful on a site.

Exactly — when I think of how people use the web, I see a relatively small number of “formats” — store, blog, forum, dashboard, etc., some more elaborate than others. But each, at heart, has a unique set of implementation details that define the format.

> (Pandoc element) It looks very interesting and promising ; with that, Nitrogen could easily replace...

As a writer, this feature really gets my imagination spinning as well. I spent a bit of time a year or so ago trying to clarify and extend Joe Armstrong’s erlguten PDF application. Got pretty far along, but didn’t have time to figure out how to integrate wider selection of fonts beyond Adobe Type 1. Pandoc has a larger code footprint than I would like but certainly does most of what I can imagine wanting to do.

> I'm gonna order it tonight or tomorrow

Our profound thanks.

So, what would you like to build in Nitrogen?

All the best,

Lloyd

Sent from my iPad

> On Dec 8, 2020, at 9:07 AM, 12u...@gmail.com <12u...@gmail.com> wrote:
>
> Jean-sYves

[12u...@gmail.com]

Hi Lloyd,

 

> Exactly — when I think of how people use the web, I see a relatively small number of “formats”

> — store, blog, forum, dashboard, etc., some more elaborate than others.

> But each, at heart, has a unique set of implementation details that define the format.

 

Yep and if this kinda example isn't already online, it is obviously for one reason: Jesse doesn't work enough!!

(note that you could do something about this, like retaining his book's money, just giving him enough to

buy coffee and pizzas until all examples are ready (well, also add toilet paper, just in case ;-p)).

 

More seriously, it would be nice to have example(s) covering 80% of all people's needs with the little tricks

that make the difference explained.

 

> As a writer, this feature really gets my imagination spinning as well. I spent a bit of time a year or so ago

> trying to clarify and extend Joe Armstrong’s erlguten PDF application.

 

Hmm, I had a look at it to generate enterprise docs (proforma, invoices, reception/delivery slips, etc) but it wasn't

good enough, instead I rely on TCPDF (PHP), which is an excellent framework to generate almost everything

as a PDF (including QR codes) - so my contention would go more toward an Erlang adaptation of it.

 

For the little story, I spent 11 full days on Python Reportlab to be convinced that each and every bit of

usefulness was stripped from the open-source version ; needless to say I wasn't able to produce anything.

On the opposite side, TCPDF allowed me to get docs exactly the way I wanted them to be, such as always

having the totals, VAT, etc (last) block at the bottom of the last page in less than 3 days…

Of course, I can still mix languages as needed, but an Erlang version would be awfully nice (but I don't have

the skills to be able to translate it myself :/)

 

> Got pretty far along, but didn’t have time to figure out how to integrate wider selection of fonts beyond

> Adobe Type 1. Pandoc has a larger code footprint than I would like but certainly does most of what

> I can imagine wanting to do.

 

Well, I see that you also don't work enough!! ;-p)

 

Being quite large is not really a problem in regard of what it is capable to achieve, it is not as we would

have other choices that compete with it.

 

> So, what would you like to build in Nitrogen?

 

A restaurant software, from reservations, ordering (with bootstrap JS as Jesse recommended it), kitchen,

etc, to serving - may be with further evolution, such as kitchen stock decrementing, online reservation and

LED display on the serving hatch to identify which plate goes to which table (main source of fight between

waiters;).

This is why COMET immediate update is very important, cos' sometimes some restaurants only have a limited

number of fish or whatever food to serve, depending on the morning market.

 

But before that, I've to find a mouse solution that can keep up in a kitchen environment, which isn't an

easy thing ; waterproof keyboards exist but I did not found any waterproof mouse - so I might fold back

to the mouse cursor driven by the numpad keys. I also have to solve the display problem (air is charged

with grease) ; may be a plexiglass enclosure with filters.

 

With regards,

 

Jean-Yves

[Lloyd R. Prentice]

Hi Jean-Yves,

> Jesse doesn't work enough!!

It’s quite the opposite problem. Jesse has a demanding business to run, a family with two young kids, and Nitrogen support. I, for one, am awed by at his generous commitment of time and expertise in response to issues posted to this list and much grateful for the time he’s spent mentoring me. If anything, he needs more folks to step up and help advance and curate Nitrogen.

| I rely on TCPDF (PHP), which is an excellent framework to generate almost everything
| as a PDF (including QR codes) - so my contention would go more toward an Erlang
| adaptation of it.

Interesting. I’ll look into it.

Love your idea of a restaurant management system. Can you spell out the specific features that would call on Nitrogen’s strengths?

All the best,

Lloyd

Sent from my iPad

[Lloyd R. prentice]

Hello again,

I just took a look at TCPDF, Jean-Yves.

I've attached a progress report on the  work I did on erlpress core. If we could break through the font issue, I believe it could provide the basis for a full-featured  Erlang-based PDF library. I've run across recent clues toward font integration, but haven't had time to follow up. I'd welcome help from any quarter to help integrate open fonts in erlpress.

All the best,

Lloyd

--

You received this message because you are subscribed to the Google Groups "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nitrogenweb...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/2ce8573c-6edf-45be-9100-79b5d316e3aen%40googlegroups.com.

[12u...@gmail.com]

Hi again, Lloyd,

 

About Nitrogen features involved in my idea of a restaurant app, here's a small list:

* the easiness and speed of development,

* using bootstrap instead of jQuery, especially because it can have an icon and a counter in mobile bar menu,

* real time updating when some dishes are limited in number,

* ringing the waiter when he's plates are ready to leave the kitchen,

* can be very easily extended from premises to online (reservations: cut'n'paste the offline version and modify it slightly),

 

About Pandoc, the most important feature needed to produce enterprise docs is the possibility to have transactions that you can rollback as this is the way to push the last block to the end of the last page.

 

It should also be fast - for example and from what I recal, the generation of a document such as the one that is attached took something like at least 24 seconds, PDF re-compression included (pdf2ps + ps2pdf, more efficient than using ghostcript).

Note that PHP/TCPDF do not do any calculation, it is just supplying the layout - this example took the 2 physical cores and 2 HT cores of my laptop's i5-4210M CPU @ 2.60GHz at 100% (3.2 GHz in turbo mode IIRC) because of multiple transactions/rollback on the last page.

It is also using HTML tables that are branded as very slow by the developer.

 

The attached file is one of the last test I made 6 days after beginning with TCPDF.

 

Note that you can very easily round the corner of the top blocks, image included, electronically sign a document, add a password, have barcodes into the designation column when i.e. adding hard disks serial numbers, etc.

 

The only thing that is annoying is the need of a strong multi-core CPU when used _this way_ in production.

 

With regards,

 

Jean-Yves

Hi again, Lloyd,

 

About Nitrogen features involved in my idea of a restaurant app, here's a small list:

* the easiness and speed of development,

* using bootstrap instead of jQuery, especially because it can have an icon and a counter in mobile bar menu,

* real time updating when some dishes are limited in number,

* ringing the waiter when he's plates are ready to leave the kitchen,

* can be very easily extended from premises to online (reservations: cut'n'paste the offline version and modify it slightly),

 

About Pandoc, the most important feature needed to produce enterprise docs is the possibility to have transactions that you can rollback as this is the way to push the last block to the end of the last page.

 

It should also be fast - for example and from what I recal, the generation of a document such as the one that is attached took something like at least 24 seconds, PDF re-compression included (pdf2ps + ps2pdf, more efficient than using ghostcript).

Note that PHP/TCPDF do not do any calculation, it is just supplying the layout - this example took the 2 physical cores and 2 HT cores of my laptop's i5-4210M CPU @ 2.60GHz at 100% (3.2 GHz in turbo mode IIRC) because of multiple transactions/rollback on the last page.

It also uses HTML tables that are branded as very slow by the developer.

 

The attached file is one of the last test I made 6 days after beginning with TCPDF.

 

Note that you can very easily round the corner of the top blocks, image included, electronically sign a document, add a password, have barcodes into the designation column when i.e. adding hard disks serial numbers, etc.

 

The only thing that is annoying is the need of a strong multi-core CPU when used _this way_ in production.

 

With regards,

 

Jean-Yves

Raahhhh, when on the gogolgroups, it waits forever when trying to attach a file :((

The PDF I mentioned can be found here: http://www.mediafire.com/file/t98xvjqyp9oiawm/RMA-NAN-2012-01-18-0128.pdf

[Lloyd R. Prentice]

Hi Jean-Yves,

Can a restaurant app be fairly easily morphed from a more general on-line store app?

Best,

Lloyd

Sent from my iPad

On Dec 8, 2020, at 3:00 PM, 12u...@gmail.com <12u...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/77f345a7-0759-4836-923d-4d2512558abbn%40googlegroups.com.

[12u...@gmail.com]

Hi Lloyd,

 

> Can a restaurant app be fairly easily morphed from a more general on-line store app?

 

I don't think so, its "basket" only exist temporarily on the browser side and is limited to one article because dishes must be sent ASAP to the kitchen (cooking time planning is not something rare and could also lead to the kitchen asking the waiter remotely if it must launch such a dish, taking in account this time), the limited dish(es) counter(s) also has to be immediately decremented down to zero for other waiters to know if they can still propose it to patrons.On the other hand, you also have to count in negative for regular dishes and get their absolute value at the end of the service to add them to their counters and ventilate them by day, weeks, months, etc.

 

From my point of view, which still needs to be refined by more discussions with professionals, although being a waiter was my first job ever, it is also easier to start from scratch than to modify an external program that would come with some curve of knowledge acquisition before any work can take place.It is also easier to modify the code on the fly when you fully own (and wrote) it instead of trying to remember where it is located in another app.

 

It is funny that you mention an on-line store as it is the next project I'd like to develop with Nitrogen (this one requires a lot more thinking and preparation, though).

 

BTW, is there a way to have multiple Nitrogen servers to share a COMET pool or each one have it's own but with a communication between them? Because I'd like this project to be able to scale up to hundreds of thousands articles and simultaneous connections - I also have to understand how pictures/PDF/files are processed into Nitrogen to see if it is worth it to store them directly into the database (PostgreSQL) for a much easier backup procedure.

 

With regards,

 

Jean-Yves

[Lloyd R. prentice]

Hi Jean-Yves,

What's interesting about this is that it's estimated that up to 10,000 restaurants will be closing down in the U.S. in coming months due to covid.

This suggests that once the pandemic is behind us, many new restaurants will be opening up. The challenge of  a book is how to reach web developers interested in or working on restaurant apps. This suggests that it would have to be promoted widely to the restaurant industry.

If we did a book, the app would have to be very generic across restaurant formats. But I'm intrigued. Need to talk with Jesse.

Also, you're in France I take it. Would there be cultural differences that would have to be taken account across the U.S., Britain, and the EU?

Best,

Lloyd

To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/c6b6bec0-0797-4067-9770-7e27593c5d41n%40googlegroups.com.

[12u...@gmail.com]

On Tuesday, December 8, 2020 at 10:46:22 PM UTC+1 LRP wrote:

Hi Lloyd,

 

What's interesting about this is that it's estimated that up to 10,000 restaurants will be closing down in the U.S. in coming months due to covid.

 

Don't tell me about that, here in france, the lowest estimation is 15% and the highest is 75% (I mean definitely closed:(

 

This suggests that once the pandemic is behind us, many new restaurants will be opening up. The challenge of  a book is how to reach web developers interested in or working on restaurant apps. This suggests that it would have to be promoted widely to the restaurant industry.

If we did a book, the app would have to be very generic across restaurant formats. But I'm intrigued. Need to talk with Jesse.

Also, you're in France I take it. Would there be cultural differences that would have to be taken account across the U.S., Britain, and the EU?

 

Not from where I stand, the job's the same everywhere with very little variations from what I've seen in all countries I've visited.

 

The only differences that I still need to fiddle about the app structure is between regular diners and others (from gastronomic to specialized restaurants) as roles can be different, i.e.: in a small diner, the waiter's doing everything, on the other hand, in a gastro, reservations are taken by the restaurant headmaster, people are placed by a maître d'hôtel (that could eventually also take the order), served by a chef de rang, drinks are either server by a chef de rang (aperitives and liquors) but champagne & wines are the sommelier's domain, at the end, tables are usually cleared and re-dressed by a commis (who also needs a terminal, as clearing+re-dressing has to be timed for restaurants that have 2 services or more).

Oh, and the drag'n'drop feature of Nitrogen will also be very helpful to modify meal elements place (think about 2-3 people taking a menu and one taking just one dish, does he want it with the entrée of the others or with their dishes). There's also the carryout to take in account, the meat cooking level, etc. Actually, I'm pilling little papers in a filer with such things to avoid missing something, but with all details, it makes quite a long app to write, which Nitrogen makes easier as it's philosophy is to work page per page.

 

Some differences can happen, such as the traditional water jug with ice served first in the US, but it is trivial to have it in the list even if it is free.

 

In fact, those who support the most of the work in such an app are the kitchen guys, especially at the level where the morning market is directing the carte of the restaurant and/or side vegetables are or not available, they must update that at least every day and sometimes twice a day - the waiter's part is (and shall be) much more trivial.

 

With regards,

 

Jean-Yves

[braun...@gmail.com]

Do you have a design or draft of that pubsub feature?

I implemented a custom pubsub server to use with nitrogen and the thing is still arduous work, its crazy. A pro solution should consider network partitions, delayed delivery,  delivery guarantees, embedded metadata together with the payload and persistent storage with mnesia. This is the API Im doing wonders with now. The pusher:notify is what wf:send does. But pusher:publish on the other hand is on another level

http://linkode.org/#GRWxmjc99Bvt8a96PKqLD5

The current wf:send function doesnt cut it for real projects. I dont think that complexity should fall inside the comet implementation.

[12u...@gmail.com]

> Do you have a design or draft of that pubsub feature?

 

No need, as what I'm thinking about is a regular ZEROMQ pubsub, spitting to a multicast or an unicast address where all clients hooks.

This is the kind of thing that is often used for some (big) architectures that diffuse information (as micro-services or not).

 

As it is explained in ZMQ docs, you can't afford to wait for an answer, as this would drain too much on the server's power, lowering by a huge percentage the available number of simultaneous clients (not to mention the bandwidth and latency).

 

What is interesting is ZEROMQ exist in many languages, including Erlang (for a pure Erlang code, see: https://github.com/zeromq/chumak - ZMQ version 3.1) & JS , so it shouldn't be extremely difficult to integrate it in Nitrogen (well, this is a wild guess as I'm far from being an Erlang guru) - and it can cope with a lot of clients, much more than the existing COMET into Nitrogen AFAIK.

[Jesse Gumm]

I do not have a design draft of the pubsub.

In fact, my plan is not to actually build a pubsub myself, since there are countless implementations out there.  Instead, my plan would be to build it as a handler, so one could plug in their pubsub of choice, be it custom built, native erlang, or an adapter to something like redis.

But I haven't worked through any of it yet, it's a pretty abstract thought at this point.

-Jesse

--

You received this message because you are subscribed to the Google Groups "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nitrogenweb...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/82e970b6-2e19-4aef-bbbe-cb04b53d61c7n%40googlegroups.com.