On Mon, 17 Jan 2022 01:55:15 -0800 (PST), NArshad <narshad....@gmail.com>
declaimed the following:
>This is due to the time factor
And that opens another can of worms... Before this "assignment" was
given to you, surely someone made some sort of estimate of how long it
would take to produce, taking into account your (apparent) lack of
familiarity with any of the technology required.
Python, Flask, and web-hosting (on Heroku) all appear to be a result of
stumbling onto a "Hello World" tutorial that does no persist ant data
storage and relies upon a free/hobbyist level account on the hosting
provider -- an obvious flag that this is not a well thought out project for
some actual customer/employer (it might qualify as an internship assignment
at some school looking to automate the reservation/check-out of text
books). The lack of understanding in how Python dictionaries are
manipulated doesn't leave one impressed either...
In one respect, given the limited functionality stated, one gets the
impression of a class GROUP assignment, in which the individual functions
were divvied up to each group member to work, with pretty much no analysis
of suitable data storage, etc. (You only gave some sort of CONOPS for
"users" to "reserve" books; no CONOPS for unreserving books, an implication
that after reserving books the user will go to some desk [in library, in
store {unlikely if there is a return date for books}, some warehouse] and
receive a copy of the reserved book -- but no CONOPS for how this deck
validates that the user has reserved any particular book [no report printed
by user of reservations made during a session, no search function for desk
staff, etc.).
The Excel requirement comes across as "this is how we've been doing it,
and we have a lot of data in the file we don't want to lose". In other
words -- one should have defined a migration path to replace the Excel
spreadsheet with something suited to a multi-user and/or web-based
application. That, or someone in the group has squashed any discussion on
data storage to force their biased viewpoint. (I've been on the fringe of
one such: in a department with over 80 VAX FORTRAN-77 programmers [some of
us quite skilled in working the internals of the language] and some 20-30
PDP Macro-11 programmers, the Macro-11 group was tasked with porting their
application to VAX systems. One person held out for the port to be done in
VAX Pascal "because colleges were teaching Pascal" at the time [TurboPascal
in all likelihood] totally ignoring the massive F-77 expertise available;
he also is rumored to have threatened to leave if Pascal was not chosen and
management caved-in. Even though VAX Pascal was much different from
TurboPascal [no development environment, though it did support separate
compilation and linking], it did not have advanced math
operations/functions -- just the ones found in Jensen&Wirth, try doing
orbital computations with a subset of trig functions -- requiring
programmers to import the F-77 runtime library for the missing functions. A
few years later the manager confessed that submitting to Pascal was a
mistake -- it didn't take long for the VAX Pascal project to be ported to
HPUX workstations using C and X-window system).
I also note that during the course of this thread, the spreadsheet
appears to have gone from a somewhat logical "one-row per title"
TITLE | AUTHORs | INVENTORY | AVAILABLE
...
A Book Someguy 10 9
..
Book 2 Who Dat 100 100
...
Popular Madonna 30 1
...
to the illogical "one-column per title"
TITLE A Book Book 2 Popular
AUTHORs Someguy Who Dat Madonna
INVENTORY 10 100
30
AVAILABLE 9 100
1
...
Consider that Excel only supports some 16K columns, but 1M rows, and
expanding each column to show, say a 200 character title (there are some
long book titles in the world) results in only two or three books being
visible at a time... And there is no "side scroll" page key. In contrast
the first layout would only need one column to be expanded, the rest can be
narrower, and one can use page-up/page-down to scroll through a lot of
books at a time. Oh, and while a cell can hold some 4K text -- Excel itself
can only display the first 255 of those. That's going to put a limit on how
many names you can fit in the reserved-by column (about 10 25char names)
and easily find while scrolling. More than that and you have use "Find"
operations from the menu.
Heroku-Specific note: a recent web-page I encountered searching for
information for a different question indicates that Heroku does not support
SQLite3 and, by extension, ANY file-based dynamic data storage (so, no
Excel files either). An Heroku Python "dyno" [virtualized work container]
is initialized using a requirements file -- that file basically lists all
the 3rd party Python modules that need to be installed using "pip". If the
"dyno" is stopped (application shut down to upload modifications, or maybe
just to remove an application that has been idle for some hours) it, and
any data files, are just deleted -- when someone tries to connect to the
app again, a new "dyno" is spun up and loaded from scratch. One is supposed
to use one of the client server databases provided by Heroku for persist
ant storage (since those are not inside "dyno" container -- the app makes a
network connection to the database server.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
--
https://mail.python.org/mailman/listinfo/python-list
