May 07, 2023

LunaGen Intro: Part 1 - Requirements

The first of three parts of an introduction to my "LunaGen" software.

I may add slides to this later, but currently it's just me talking.

This video is also used in my unit-testing.

Transcript:

What is LunaGen?

When I was setting up my new site for Lunatics Project,

I was disatisfied with the options I could find

for setting up a static landing page which could

provide access to released video episodes and

associated viewer content

(as opposed to developer or production team content).

So I created my own "Lunatics Site Generator",

which I contracted to "LunaGen".

This is a presentation of my design concept,

in three parts:

requirements,

implementation, and

use.

PT 1: REQUIREMENTS

I wanted a page that would be served statically

Many popular web applications, including Wordpress,

which we had been using for our project website,

work dynamically.

Each time you visit one of those sites,

a program runs on the server

to combine your 'request'

with the data it has stored in a database

or on the file system,

to construct the HTML page that it sends you.

After that, your own computer might do some more work,

interpreting a Javascript program that the web page

has sent you, which then draws

the page in your browser.

That's a lot of complexity, and the important thing is:

It happens EACH TIME someone visits the page.

That's fine, if you only get a 100 hits a day. It might

even be more efficient, if the pages that are served up

have a strong chance of being different from each other,

due to being rapidly changing or personalized for each

user.

But if you get a MILLION hits a day, and the webpages are

all pretty much the same anyway, then it is very wasteful,

and requires much more of the server --

which, can mean your server crashes

or you have to spend more money on more resources

to keep it from crashing.

By contrast, for a static website, all the generation

of the HTML has been done in advance, and the resulting

HTML is simply stored on the server.

When a user asks for the page,

it uses the URL to fetch the page off disk

and sends it to them.

A well-configured web server might even cache that data

in active memory,

so that it doesn't even have to access the disk.

A static page doesn't have to be unchanging.

It actually might be updated frequently.

For example, it might include a clock,

with the time updated every minute

or even every second.

But it is NOT updated each time you ask for it.

If it is updated too frequently,

and the web traffic is slow,

it might wind up putting more stress on the server

than a dynamic page.

But the point is that not much of the load

depends on the traffic.

So it is more predictable, and less vulnerable to

a sudden surge in traffic.

It also has a significant advantage

for security and privacy.

The server doesn't need to know anything about

who you are.

And it doesn't take any input from you.

That, by itself,

eliminates most concerns about privacy.

And it defeats most kinds of attacks.

I also wanted the page to be simple and lightweight.

Besides being statically served,

if a web page avoids using a lot of Javascript,

and in particular,

not using Javascript libraries,

then it won't have to send you

large program files.

That means less load on the server,

simply because less data is transferred.

Also less time to download the page,

which matters for people on slow connections.

And,

although it doesn't affect the server,

it means less time for the user to wait

while their browser renders the page.

This makes the page seem a lot faster.

These factors were all important to me

for Lunatics Project,

because we don't have a lot of money

for renting expensive,

high-availability,

servers.

And also, because we don't really have

an IT staff ready to deal

with a traffic crisis.

And because, as we are a creative project

with a plan to have a release schedule,

a sudden surge in traffic

is a realistic possibility.

I mean,

we may not be popular enough

to worry about that.

But I like to plan

for the possibility of a big success.

I also wanted my page to be easy to update,

and to respect the internal structure of my media.

We are basically producing video and audio series.

Our release page should make it easy

to watch our series in order,

optionally with extra featurette videos.

This is the kind of structure you see

on a DVD or Blu-Ray disk.

Which are obviously static menus.

A lot of web applications,

like blogs, on the other hand,

emphasize the serial nature of posting

over the internal structure of the media.

That is, it is more important to them

to record the order of last update

than the logical story order.

That turns up all the time,

when a series is posted on video platforms,

like YouTube or Vimeo.

The site mechanisms aren't really set up

to preserve the serial order of the media.

What's more,

posting on such platforms,

involves a lot of drudgery,

trying to maintain a systematic structure

to each post.

If I were to release my series

as a 'blog' --

perhaps using one of the pre-existing

static web log softwares,

like Jekyll, Hugo, or Pelican,

I would have to do a lot of fiddling with Markdown

for EACH POST, having to check prior posts to see,

if I were being consistent.

That seemed like a lot of hassle.

So I decided against using

one of those pre-existing static blog packages.

What I wanted was to be able to simply update a

collection of facts about each series

and each episode,

and then generate the web site based on that.

That suggested that

instead of a mark-up language

I wanted something more like a

structured data language.

This would then be combined

with templates to generate chunks of HTML

which would then be assembled into pages.

It's fundamentally like a data-driven page,

but the amount of data is not large,

while the multimedia content elements

hold most of the information.

Finally, I wanted a site that would allow for

a friendly and flexible sort of monetization.

I don't wish to become a "platform" site.

Nor do I want to be too attached

to any one platform.

I don't want to be a "YouTuber",

nor a "Patreon Blogger".

We do need financial support to keep going,

and our contributors...

(me included)

...deserve to get paid for their work.

Somehow.

So I wanted to be able to embed "calls to action"

directly on the video publishing page.

Not hidden away somewhere,

where only the most dogged fans might find it.

So much stuff is published "for free",

with the monetization mechanism,

be it advertising

or data mining,

being hidden.

It would be easy for fans to imagine

that this is all "paid for"

and they have no reason to pay us.

I want to make sure the donation hat is clearly visible!

Or the merch store.

Or whatever mechanism is working for us.

On the other hand, I don't want gross pop-up ads

or other things that ruin the viewers' experience.

So my design needs to naturally allow

for this secondary stream of content.

After determining that none of the available

off-the-shelf solutions seemed to suit me,

I decided I would write my own site generator.

I'd try to keep the scope small,

by sticking to my original use-case,

and not adding

a lot of bells and whistles.

This remains a design goal.

...more

View all episodes

May 07, 2023

LunaGen Intro: Part 1 - Requirements

The first of three parts of an introduction to my "LunaGen" software.

I may add slides to this later, but currently it's just me talking.

This video is also used in my unit-testing.

Transcript:

What is LunaGen?

When I was setting up my new site for Lunatics Project,

I was disatisfied with the options I could find

for setting up a static landing page which could

provide access to released video episodes and

associated viewer content

(as opposed to developer or production team content).

So I created my own "Lunatics Site Generator",

which I contracted to "LunaGen".

This is a presentation of my design concept,

in three parts:

requirements,

implementation, and

use.

PT 1: REQUIREMENTS

I wanted a page that would be served statically

Many popular web applications, including Wordpress,

which we had been using for our project website,

work dynamically.

Each time you visit one of those sites,

a program runs on the server

to combine your 'request'

with the data it has stored in a database

or on the file system,

to construct the HTML page that it sends you.

After that, your own computer might do some more work,

interpreting a Javascript program that the web page

has sent you, which then draws

the page in your browser.

That's a lot of complexity, and the important thing is:

It happens EACH TIME someone visits the page.

That's fine, if you only get a 100 hits a day. It might

even be more efficient, if the pages that are served up

have a strong chance of being different from each other,

due to being rapidly changing or personalized for each

user.

But if you get a MILLION hits a day, and the webpages are

all pretty much the same anyway, then it is very wasteful,

and requires much more of the server --

which, can mean your server crashes

or you have to spend more money on more resources

to keep it from crashing.

By contrast, for a static website, all the generation

of the HTML has been done in advance, and the resulting

HTML is simply stored on the server.

When a user asks for the page,

it uses the URL to fetch the page off disk

and sends it to them.

A well-configured web server might even cache that data

in active memory,

so that it doesn't even have to access the disk.

A static page doesn't have to be unchanging.

It actually might be updated frequently.

For example, it might include a clock,

with the time updated every minute

or even every second.

But it is NOT updated each time you ask for it.

If it is updated too frequently,

and the web traffic is slow,

it might wind up putting more stress on the server

than a dynamic page.

But the point is that not much of the load

depends on the traffic.

So it is more predictable, and less vulnerable to

a sudden surge in traffic.

It also has a significant advantage

for security and privacy.

The server doesn't need to know anything about

who you are.

And it doesn't take any input from you.

That, by itself,

eliminates most concerns about privacy.

And it defeats most kinds of attacks.

I also wanted the page to be simple and lightweight.

Besides being statically served,

if a web page avoids using a lot of Javascript,

and in particular,

not using Javascript libraries,

then it won't have to send you

large program files.

That means less load on the server,

simply because less data is transferred.

Also less time to download the page,

which matters for people on slow connections.

And,

although it doesn't affect the server,

it means less time for the user to wait

while their browser renders the page.

This makes the page seem a lot faster.

These factors were all important to me

for Lunatics Project,

because we don't have a lot of money

for renting expensive,

high-availability,

servers.

And also, because we don't really have

an IT staff ready to deal

with a traffic crisis.

And because, as we are a creative project

with a plan to have a release schedule,

a sudden surge in traffic

is a realistic possibility.

I mean,

we may not be popular enough

to worry about that.

But I like to plan

for the possibility of a big success.

I also wanted my page to be easy to update,

and to respect the internal structure of my media.

We are basically producing video and audio series.

Our release page should make it easy

to watch our series in order,

optionally with extra featurette videos.

This is the kind of structure you see

on a DVD or Blu-Ray disk.

Which are obviously static menus.

A lot of web applications,

like blogs, on the other hand,

emphasize the serial nature of posting

over the internal structure of the media.

That is, it is more important to them

to record the order of last update

than the logical story order.

That turns up all the time,

when a series is posted on video platforms,

like YouTube or Vimeo.

The site mechanisms aren't really set up

to preserve the serial order of the media.

What's more,

posting on such platforms,

involves a lot of drudgery,

trying to maintain a systematic structure

to each post.

If I were to release my series

as a 'blog' --

perhaps using one of the pre-existing

static web log softwares,

like Jekyll, Hugo, or Pelican,

I would have to do a lot of fiddling with Markdown

for EACH POST, having to check prior posts to see,

if I were being consistent.

That seemed like a lot of hassle.

So I decided against using

one of those pre-existing static blog packages.

What I wanted was to be able to simply update a

collection of facts about each series

and each episode,

and then generate the web site based on that.

That suggested that

instead of a mark-up language

I wanted something more like a

structured data language.

This would then be combined

with templates to generate chunks of HTML

which would then be assembled into pages.

It's fundamentally like a data-driven page,

but the amount of data is not large,

while the multimedia content elements

hold most of the information.

Finally, I wanted a site that would allow for

a friendly and flexible sort of monetization.

I don't wish to become a "platform" site.

Nor do I want to be too attached

to any one platform.

I don't want to be a "YouTuber",

nor a "Patreon Blogger".

We do need financial support to keep going,

and our contributors...

(me included)

...deserve to get paid for their work.

Somehow.

So I wanted to be able to embed "calls to action"

directly on the video publishing page.

Not hidden away somewhere,

where only the most dogged fans might find it.

So much stuff is published "for free",

with the monetization mechanism,

be it advertising

or data mining,

being hidden.

It would be easy for fans to imagine

that this is all "paid for"

and they have no reason to pay us.

I want to make sure the donation hat is clearly visible!

Or the merch store.

Or whatever mechanism is working for us.

On the other hand, I don't want gross pop-up ads

or other things that ruin the viewers' experience.

So my design needs to naturally allow

for this secondary stream of content.

After determining that none of the available

off-the-shelf solutions seemed to suit me,

I decided I would write my own site generator.

I'd try to keep the scope small,

by sticking to my original use-case,

and not adding

a lot of bells and whistles.

This remains a design goal.

...more

Share LunaGen Intro: Part 1 - Requirements

Sign up to save your podcasts

LunaGen Intro: Part 1 - Requirements

LunaGen Intro: Part 1 - Requirements