Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update digital.md #164

Merged
merged 2 commits into from
Jan 6, 2021
Merged

Update digital.md #164

merged 2 commits into from
Jan 6, 2021

Conversation

ps2270
Copy link
Contributor

@ps2270 ps2270 commented Dec 31, 2020

I've made some typo corrections and also some revisions. Pls let me know if you think any of the revisions don't convey correctly the intended meaning.
One question about my changes:
I changed
most of this data was worked on in the Project's Google Drive [which sounded awkward to me]
to
most of this data was processed in the Project's Google Drive [but processing sounds like a different operation than what we did]

We can change it back to worked on, or perhaps change it to "edited"

@ps2270 ps2270 requested a review from njr2128 December 31, 2020 16:40

For persistent access, each essay has been assigned a Digital Object Identifier (DOI) and will also be archived in Columbia University [Academic Commons](https://academiccommons.columbia.edu/) and downloadable as standalone publications.

Static Site Generation
------

Most websites are typically created using a content management system (CMS) in which the site's content is kept in a database and rendered into HTML when requested. This approach often requires the employment of proprietary software as well as a large number of resources, institutional support, or constant maintenance. Static site generation, unlike CMS or database-driven projects, allows websites to be created with significantly fewer dependencies, reduces maintenance overhead, and minimizes the risk of technological obsolescence. Content is already in its final form (as static pages are created beforehand) and can be sent as-is to the user.
Most websites are typically created using a content management system (CMS) in which the site's content is kept in a database and rendered into HTML when requested. This approach often requires the employment of proprietary software as well as a large number of resources, institutional support, or constant maintenance. Static site generation, unlike CMS or database-driven projects, allows websites to be created with significantly fewer dependencies, reducing maintenance overhead, and minimizing the risk of technological obsolescence. Content is already in its final form (as static pages are created beforehand) and can be sent as-is to the user.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we should keep the original because it is more technically precise. Static site generation does these three things (allows, reduces, minimizes) rather than the "fewer dependencies" causing the last two things

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to:

static site generation, unlike CMS or database-driven projects, allows websites to be created with significantly fewer dependencies, and reduces maintenance overhead, as well as minimizes the risk of technological obsolescence. Content is already in its final form (as static pages are created beforehand) and can be sent as-is to the user.


Static site generation thus offers a number of advantages. It allows individualized software decisions and better control and maintenance of the site. Furthermore, open-source web servers like Apache and Nginx can very efficiently serve large amounts of static data and respond with increased user traffic, leading to lower server costs. Because the technology is so fundemental to the web, techniques for serving static sites are likely to persist into the future as well as be universally understood by IT professionals tasked with keeping the assets online.
Static site generation thus offers a number of advantages. It allows individualized software decisions and better control and maintenance of the site. Furthermore, open-source web servers like Apache and Nginx can very efficiently serve large amounts of static data and respond to increased user traffic, leading to lower server costs. Because the technology is so fundamental to the web, techniques for serving static sites are likely to persist into the future as well as be universally understood by IT professionals tasked with keeping the assets online.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe there is a reason this is "respond with" - while grammatically in English this is usually "respond to," here it signifies that as traffic changes, the system is responsive

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DECISION: "respond to"

ALSO:

Because this is a well-established, fundamental web technology, techniques for serving static sites are likely to persist into the future as well as be universally understood by IT professionals tasked with keeping the assets online.


The content for _Secrets of Craft and Nature_ involved the scholarly work of a number of different editors, teams, and collaborators working over several years to explore the intricacies of a complex historical text, Ms. Fr. 640. To facilitate the collaborative methods, most of this data was worked on in the Project's Google Drive. As the Project evolved and came closer to digital publication, more and more data was moved to Github repositories. At the same time, content was still under developement, and there was a need to draw from both Github and Google Drive at build time.
The content for _Secrets of Craft and Nature_ involved the scholarly work of a number of different editors, teams, and collaborators working over several years to explore the intricacies of a complex historical text, Ms. Fr. 640. To facilitate the collaborative methods, most of this data was processed in the Project's Google Drive. As the Project evolved and came closer to digital publication, more and more data was moved to Github repositories. At the same time, content was still under development, and there was a need to draw from both Github and Google Drive at build time.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Terry and I struggled with the wording here. As you mentioned, "processed" has a different meaning and should not be used here. Perhaps "edited"? Or leave as "worked on"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DECISION:
"worked on"

Copy link
Member

@njr2128 njr2128 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tcatapano, can you take a look at this and review too?

@njr2128 njr2128 requested a review from tcatapano December 31, 2020 22:02
@ps2270
Copy link
Contributor Author

ps2270 commented Jan 1, 2021 via email

@ps2270
Copy link
Contributor Author

ps2270 commented Jan 1, 2021 via email

@njr2128 njr2128 self-requested a review January 6, 2021 21:30
@njr2128
Copy link
Member

njr2128 commented Jan 6, 2021

All commented changes have been updated

@njr2128 njr2128 merged commit 9bc4304 into master Jan 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants