Re: Conclusion about Studio-PM's “Tech.Reports”
Studio - PM
studio-pm at hotmail.com
Mon May 18 03:27:17 BST 2020
Dearest Tiger,
direct to the Point(s):
P1) From a life-long experience as an experimental Physicist and as a s/w developer (CERN-GE, Univ.-TS, ...) I've got to appreciate good tech.doc.s sparing me unnecessary difficulties in making good use of high tech. devices in general, and computer systems and s/w tools in particular.
P2) From that experience I reached a “revolutionary” conclusion, that is that good/effective documentation should be written from the end-user point of view (and purpose, and needs), not from the involved high tech. device designer, producer or seller, as it usually happens.
P3) With such basic and revolutionary conviction in mind I decided to demonstrate the usefulness, the validity of my “vision” in a real case; that is with Eric, a fairly complex s/w tool so far virtually undocumented.
P3.1) A “basic and revolutionary conviction” which, by the way, implies that for writing valid and sensible documentation about a given tool, especially a high tech s/w tool, first of all (among other things, but this first of all) obviously you must know what that tool is intended for, you must be a fair expert of the intended art, so to test and know what you are talking about. Obviously.
P4) My intended reward for that commitment of mine was to get in touch with and obtain the operative adhesion of a bunch of, say, half a dozen users, so to get valid and sensible feed-back and professional support from qualified and collaborative fellow users. It would be sort of methodological revolution about how Tech.Doc. should be intended, and done.
P5) All what here said is openly and clearly announced in the Foreword of my work, and then stated with each and all pages that follow.
P6) In conclusion, after about half a dozen Tech.Reports aimed at the stated revolutionary goal, being, as it happens, my effort not appreciated nor encouraged by the Eric users' community, of course there is no reason to keep inflicting it upon them. Of course.
P7) All your question & remarks are anyhow welcome.
So long. Yours,
- P.M.
- -
Sent from Outlook<http://aka.ms/weboutlook>
________________________________
From: some.user at posteo.net <some.user at posteo.net>
Sent: Sunday, May 17, 2020 12:27 PM
To: Studio-PM at hotmail.com <Studio-PM at hotmail.com>
Subject: Conclusion about Studio-PM's “Tech.Reports”
Hi P.M.
just got on the Eric mailing list and saw your post. I do not know anything about the history of that document, but I would like to offer you the feedback from my first steps with Eric from 3 days ago.
I think Eric could be what I had been looking for for some time. My normal C++ IDE (CodeBlocks) unfortunately does not support Python and I just can not get used to those code monsters of VSCode or rather counter-intuitive, undocumented IDEs as KDevelop (which I got to run but really did not warm up to it). Major frustration was maybe it was missing someone like you, who wrote up something about the program to get started and around most pecularities.
So I really apprecitate your work on Eric and thank you very much for your effirts I think most people have no idea how time consuming a full documentation of such a complex program is.
I have to admit that I had wasted a lot of time searching for some documentation for Eric. I was led off by the title "Technical Report" and the look of first few pages and dismissed it as too detailed developer stuff rather than Getting Started Stuff. I think this is mainly due to the way the document is presented on the Eric website.
The Document proved most valuable in clearing up the strange concept of API. At least I have understood what it is not. I have not really understood what exactily it is and what is does from the explanation, but that is because usually I only understand things after seeing a concrete example, because I typially interpret whats written in a different way very often. However, I see how difficult it would be to make a concrete example of this.
I ran into a big problem setting up Eric in Linux using pyenv. I got a workaround going now, but there is a severe thing going wrong. I noted that your version is too old to cover the new tow VirtualEnv dialogs in Extras. I must admit that I did not really undertand what they do, because in my installation they fail to do what I would naturally expect them to do. With the Configure dialog I accidentially deleted all my VEs in pyenv, so I got a bit careful about playing around.
As I am new to python I am sure that most people starting with Eric would be highly appreciative of your document, would they get it presented as such: "Description of Eric IDE, its main Concepts and Installation in Windows". (not very up to date). AFAIK there is not other written documentation around at all.
You mentioned in your text you would have some additional information. I would be pleased to learn more about it or receive the files if you would be prepared to send them.
Best regards
Tiger
PS: I would have answered you on the mailing list, but I'm afraid I do not know how to answer to a specific post there. I just pressed the "Reply via email to" button on the page. Please feel free to at this onto the mailing list if you think that is useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/eric/attachments/20200518/c45d7b81/attachment.htm>
More information about the Eric
mailing list