Düben, Christian writes
I am still working on the database performance. Insertion times dropped but did not reach a satisfactory level yet. However, as the application is done except for the database issue, I decided to seek feedback from your side already. You can access it at "http://95.216.35.87:8080"
For that I already have test.collec.repec.org
with the user name "Test_User"
Why do I need to sign in? It's too slow after sign in. In general, darni is dreadfully slow today. I think the i/o is the bottleneck. I have been deleting files as we reached %94 full. Few Otto Normaleconomists will understand the weighted networks. Data entry should not ask to fill a name or fill a handle, but detect whether the entry is a name or a handle. Ideally, one should enter family names as well as they are more famliar to users who search. I think you need to start with a simple note, where the screen is cached.
The video embedded in the "Introduction" tab is a placeholder and will be replaced with the actual tutorial upon the new CollEc's public release. The output generated in the "Distances", "Closeness" and "Betweenness" tabs is temporarily not available as I am currently working on the underlying MariaDB tables. I changed the documentation a few times and am curious to hear your comments on it.
I think it's better to give people a list of top nodes at the start, or just start with a screen very similar to the to one of the existing CollEc. It may not be a the best, but some folks got used to it. A video link should go to the docmentation page. -- Cheers, Thomas Krichel http://openlib.org/home/krichel skype:thomaskrichel
As for the text, I think it can be shortened CollEc is a RePEc service that evaluates the economic literature's co-authorship network. It allows you to assess bilateral distances and centrality measures like closeness and betweenness for more than 47,000 authors. As in GraphEc , you interact with the results through graphical representations. CollEc was founded by Thomas Krichel in <YEAR> and is currently maintained by Christian Düben . The underlying co-authorship data is derived from the RePEc Author Service , a RePEc service maintained by Christian Zimmermann . Further details are available in the documentation . Feel free to watch the following tutorial for a brief introduction to CollEc's functionalities. Note that this is a Youtube video. Clicking the play button places Youtube's cookies in your browser which are subject to that platform's cookie policy. CollEc evaluates RePEc's co-authorship network. You can access bilateral distances and closeness and betweenness centrality data for more than 47,000 authors. As in GraphEc, you interact with the results through graphical representations. Have a look at the documentation. Our data comes from the RePEc Author Service. CollEc was founded by Thomas Krichel in <YEAR> and is currently maintained by Christian Düben . The underlying co-authorship data is derived from the RePEc Author Service , a RePEc service maintained by Christian Zimmermann . Further details are available in the documentation . Feel free to watch the following tutorial for a brief introduction to CollEc's functionalities. Note that this is a Youtube video. Clicking the play button places Youtube's cookies in your browser which are subject to that platform's cookie policy. I think we should host the video on the server directly. And the paragraph above can be deleted. The footer should be placed in normal flow, rather than absolutely as you have done, as this looks funky if somebody has a small screen. Finally the footer should have you first, then say "it was created by Thomas Krichel in 2013. Server sponsored ... as before. Or maybe I should not be in the footer. -- Cheers, Thomas Krichel http://openlib.org/home/krichel skype:thomaskrichel
Thanks for the messages. Can you point test.collec.repec.org to http://95.216.35.87:8080? I set up the user authentication to restrict access until the app is publicly released. Start up speed varies greatly between sessions. Sometimes the app starts almost immediately and sometimes it takes quite a while or even fails. ShinyProxy handles this stage and I am not sure why it is so volatile. I am currently running four parallel threads inserting data into the containerized MariaDB. This might at least partly explain the server's performance issues today. And it may adversely affect the app's loading times. The app containers are also attached to the same bridge network over which the data is inserted into the MariaDB - another potential reason for extended loading times. The author search field is a selectize.js functionality. You can start typing at any position within an author's name. E.g. in my case you can start with "Christian", with "Düben" or even with "übe". You simply type something until the desired name shows up in the list of suggestions underneath. And those suggestions motivate the two reasons for which the app requires users to choose between names and handles before selecting an author. First, all available choices need to be loaded into memory and filtered while the user is typing. More choices make the functionality slightly slower. Second, a vector of names and handles combined also generates a list of suggestions containing both names and handles. And that might confuse users. I am not sure what to write on where the screen is cached. By "give people a list of top nodes at the start" you mean that the top default names on the list should be prominent, i.e. central, economists, right? I thought about it. And I think you have a point. I am going to change the default suggestions. Many economists are not familiar with graph theory. And that is why the documentation explains the basics in a simply way. Edge weights are a key component of graphs and in my opinion one of the easiest parts to understand. Users do not have to be familiar with the slightly more complex shortest cost path algorithms or centrality measures to understand how edge weights work. If required, I can add another paragraph and a plot on edge weights to the documentation. Cutting the introduction shorter is possible. Thanks for the suggestion. I will look into a few options. Hosting the video on the server would indeed make the cookie notification obsolete. The motivation to embed a video hosted on Youtube comes from Youtube's video player. It automatically adjusts the resolution to the user's bandwidth, provides a rather stable performance, works well in different browsers and allows users to modify the speed. Other video players used online tend to be more annoying to use. They get stuck, complain about missing browser plugins, do sometimes not adjust dynamically to bandwidth limitations and come with fewer customizable settings. I can add the video via the HTML video tag. And then we check how it performs in the web application called by different browsers. If that does not work as intended we can still try other players or host it on Youtube. I embedded the video in the introduction rather than the documentation because of feedback I received on GraphEc. The feedback was that users should understand right at the start how the app works - without having to click through the other tabs. The video is like a paper's abstract. It is a brief, convenient, initial overview presented to the user without him or her going through the details, i.e. the documentation. And besides that everyone likes to watch videos. Some users might not find it as enjoyable as funny cat videos, but it still makes the app appear more active and engaging from the start. You mention the year 2013 in your e-mail. Should I use that as the year you introduced CollEc? I guess I somehow incorrectly understood CollEc to be a service from the early RePEc days. The decision on whether your name shows up in the footer is up to you. It is your name. In the meantime I am going to check the footer's position. Thanks for offering me to use the database on the host. However, I still prefer a containerized MariaDB. With a container I do not have to manually intervene when the database crashes. Docker simply spins up a new container with an uncorrupted MariaDB image without any loss of data. A similar story holds for Java. I tried running ShinyProxy directly on the host. The required Java version was not compatible with the Debian installation. Therefore, ShinyProxy and the respective Java version are now deployed through Docker. Shinyproxy runs in a container but exposes the app directly on the host's ports. So, would it be possible to set the A record to that port? Or to use a Nginx reverse proxy to link the port the URL is pointing to to the port ShinyProxy exposes the app on? No worries about any delayed responses. That e-mail was meant as an update not invoking any feedback. And especially when you are sick you should focus on your health. Besides that, I am also busy with other matters, including teaching and ongoing research projects. Let me make a few adjustments to the documentation based on your comments. Then I will send you the source code. Have a nice day. Christian Düben Research Associate Chair of Macroeconomics Hamburg University Von-Melle-Park 5, Room 3102 20146 Hamburg Germany +49 40 42838 1898 christian.dueben@uni-hamburg.de http://www.christian-dueben.com -----Original Message----- From: Thomas Krichel <krichel@openlib.org> Sent: Freitag, 3. Juli 2020 15:41 To: Düben, Christian <Christian.Dueben@uni-hamburg.de> Cc: CollEc Run <collec-run@lists.openlib.org> Subject: Re: CollEc 2.0 Access Düben, Christian writes
I am still working on the database performance. Insertion times dropped but did not reach a satisfactory level yet. However, as the application is done except for the database issue, I decided to seek feedback from your side already. You can access it at "http://95.216.35.87:8080"
For that I already have test.collec.repec.org
with the user name "Test_User"
Why do I need to sign in? It's too slow after sign in. In general, darni is dreadfully slow today. I think the i/o is the bottleneck. I have been deleting files as we reached %94 full. Few Otto Normaleconomists will understand the weighted networks. Data entry should not ask to fill a name or fill a handle, but detect whether the entry is a name or a handle. Ideally, one should enter family names as well as they are more famliar to users who search. I think you need to start with a simple note, where the screen is cached.
The video embedded in the "Introduction" tab is a placeholder and will be replaced with the actual tutorial upon the new CollEc's public release. The output generated in the "Distances", "Closeness" and "Betweenness" tabs is temporarily not available as I am currently working on the underlying MariaDB tables. I changed the documentation a few times and am curious to hear your comments on it.
I think it's better to give people a list of top nodes at the start, or just start with a screen very similar to the to one of the existing CollEc. It may not be a the best, but some folks got used to it. A video link should go to the docmentation page. -- Cheers, Thomas Krichel http://openlib.org/home/krichel skype:thomaskrichel
Düben, Christian writes
Can you point test.collec.repec.org to http://95.216.35.87:8080?
I think tihs is done.
I set up the user authentication to restrict access until the app is publicly released.
I don't see much of a sense in doing that, but you are the boss here.
Start up speed varies greatly between sessions. Sometimes the app starts almost immediately and sometimes it takes quite a while or even fails. ShinyProxy handles this stage and I am not sure why it is so volatile.
I think over the post week I found that the machine was running very slow on certain time. I found disk space rising to 94%, causing me great concern. I don't know how to count what is in your part. I killed all backups that the machine had. As of lately disk space dropped considerably.
Many economists are not familiar with graph theory. And that is why the documentation explains the basics in a simply way. Edge weights are a key component of graphs and in my opinion one of the easiest parts to understand. Users do not have to be familiar with the slightly more complex shortest cost path algorithms or centrality measures to understand how edge weights work. If required, I can add another paragraph and a plot on edge weights to the documentation.
I think seeing a list of top-rated folk right at the start will prolly motivate users.
Hosting the video on the server would indeed make the cookie notification obsolete. The motivation to embed a video hosted on Youtube comes from Youtube's video player. It automatically adjusts the resolution to the user's bandwidth, provides a rather stable performance, works well in different browsers and allows users to modify the speed.
But then show you ads, right?
Other video players used online tend to be more annoying to use. They get stuck, complain about missing browser plugins, do sometimes not adjust dynamically to bandwidth limitations and come with fewer customizable settings. I can add the video via the HTML video tag. And then we check how it performs in the web application called by different browsers. If that does not work as intended we can still try other players or host it on Youtube.
I
I embedded the video in the introduction rather than the documentation because of feedback I received on GraphEc. The feedback was that users should understand right at the start how the app works - without having to click through the other tabs. The video is like a paper's abstract. It is a brief, convenient, initial overview presented to the user without him or her going through the details, i.e. the documentation. And besides that everyone likes to watch videos. Some users might not find it as enjoyable as funny cat videos, but it still makes the app appear more active and engaging from the start.
I hardly represent the averae user, so I can't comment on this.
You mention the year 2013 in your e-mail. Should I use that as the year you introduced CollEc?
I'm sorry. No. I'm really bad at this. I think the first mention as a runnig service on RePEc-run is on 25 January 2011.
I guess I somehow incorrectly understood CollEc to be a service from the early RePEc days.
Can't be since RAS is only from 99. Early days would be 1993 to 1997.
Thanks for offering me to use the database on the host. However, I still prefer a containerized MariaDB. With a container I do not have to manually intervene when the database crashes. Docker simply spins up a new container with an uncorrupted MariaDB image without any loss of data.
A similar story holds for Java. I tried running ShinyProxy directly on the host. The required Java version was not compatible with the Debian installation.
Not a problem at all since JAVA is not used for anything else.
Shinyproxy runs in a container but exposes the app directly on the host's ports. So, would it be possible to set the A record to that port? Or to use a Nginx reverse proxy to link the port the URL is pointing to to the port ShinyProxy exposes the app on?
That is done I think. If you mean a DNS record, it can't be tied to a part.
Besides that, I am also busy with other matters, including teaching and ongoing research projects.
I have no one to blame but me but it looks I now have about 100000 sick ArchEc files. -- Cheers, Thomas Krichel http://openlib.org/home/krichel skype:thomaskrichel
Sorry for the late reply. The embedded Youtube video would display ads. That might be a problem. So I will look into options of hosting it directly on the server. The connection to the app collapses after opening it at test.collec.repec.org. It works fine when I directly access it via the IP. But somehow the communication does not work when accessing it via test.collec.repec.org. I added a functionality to the app. User can now access fragments of the graph through interactive D3 networks in the Co-Authors tab. What is left is the video. I am going to record it later this week, after recovering from a cold. Christian Düben Research Associate Chair of Macroeconomics Hamburg University Von-Melle-Park 5, Room 3102 20146 Hamburg Germany +49 40 42838 1898 christian.dueben@uni-hamburg.de http://www.christian-dueben.com -----Original Message----- From: Thomas Krichel <krichel@openlib.org> Sent: Donnerstag, 9. Juli 2020 15:32 To: Düben, Christian <Christian.Dueben@uni-hamburg.de> Cc: CollEc Run <collec-run@lists.openlib.org> Subject: Re: CollEc 2.0 Access Düben, Christian writes
Can you point test.collec.repec.org to http://95.216.35.87:8080?
I think tihs is done.
I set up the user authentication to restrict access until the app is publicly released.
I don't see much of a sense in doing that, but you are the boss here.
Start up speed varies greatly between sessions. Sometimes the app starts almost immediately and sometimes it takes quite a while or even fails. ShinyProxy handles this stage and I am not sure why it is so volatile.
I think over the post week I found that the machine was running very slow on certain time. I found disk space rising to 94%, causing me great concern. I don't know how to count what is in your part. I killed all backups that the machine had. As of lately disk space dropped considerably.
Many economists are not familiar with graph theory. And that is why the documentation explains the basics in a simply way. Edge weights are a key component of graphs and in my opinion one of the easiest parts to understand. Users do not have to be familiar with the slightly more complex shortest cost path algorithms or centrality measures to understand how edge weights work. If required, I can add another paragraph and a plot on edge weights to the documentation.
I think seeing a list of top-rated folk right at the start will prolly motivate users.
Hosting the video on the server would indeed make the cookie notification obsolete. The motivation to embed a video hosted on Youtube comes from Youtube's video player. It automatically adjusts the resolution to the user's bandwidth, provides a rather stable performance, works well in different browsers and allows users to modify the speed.
But then show you ads, right?
Other video players used online tend to be more annoying to use. They get stuck, complain about missing browser plugins, do sometimes not adjust dynamically to bandwidth limitations and come with fewer customizable settings. I can add the video via the HTML video tag. And then we check how it performs in the web application called by different browsers. If that does not work as intended we can still try other players or host it on Youtube.
I
I embedded the video in the introduction rather than the documentation because of feedback I received on GraphEc. The feedback was that users should understand right at the start how the app works - without having to click through the other tabs. The video is like a paper's abstract. It is a brief, convenient, initial overview presented to the user without him or her going through the details, i.e. the documentation. And besides that everyone likes to watch videos. Some users might not find it as enjoyable as funny cat videos, but it still makes the app appear more active and engaging from the start.
I hardly represent the averae user, so I can't comment on this.
You mention the year 2013 in your e-mail. Should I use that as the year you introduced CollEc?
I'm sorry. No. I'm really bad at this. I think the first mention as a runnig service on RePEc-run is on 25 January 2011.
I guess I somehow incorrectly understood CollEc to be a service from the early RePEc days.
Can't be since RAS is only from 99. Early days would be 1993 to 1997.
Thanks for offering me to use the database on the host. However, I still prefer a containerized MariaDB. With a container I do not have to manually intervene when the database crashes. Docker simply spins up a new container with an uncorrupted MariaDB image without any loss of data.
A similar story holds for Java. I tried running ShinyProxy directly on the host. The required Java version was not compatible with the Debian installation.
Not a problem at all since JAVA is not used for anything else.
Shinyproxy runs in a container but exposes the app directly on the host's ports. So, would it be possible to set the A record to that port? Or to use a Nginx reverse proxy to link the port the URL is pointing to to the port ShinyProxy exposes the app on?
That is done I think. If you mean a DNS record, it can't be tied to a part.
Besides that, I am also busy with other matters, including teaching and ongoing research projects.
I have no one to blame but me but it looks I now have about 100000 sick ArchEc files. -- Cheers, Thomas Krichel http://openlib.org/home/krichel skype:thomaskrichel
Hi Christian, you can either self-host the video, or use Vimeo, which doesn't display ads (the free tier should be fine for this) -- Lars Vilhuber, Economist Cornell University, Executive Director, Labor Dynamics Institute and ILR School - Department of Economics American Economic Association - Data Editor Journal of Privacy and Confidentiality - Managing Editor e: lars.vilhuber@cornell.edu p: +1.607-330-5743 v: https://cornell.zoom.us/my/larsvilhuber w: http://lars.vilhuber.com/ <http://lars.vilhuber.com/> Assistant: ldi@cornell.edu | +1.607-255-2744 ________________________________ From: CollEc-run <collec-run-bounces@lists.openlib.org> on behalf of Düben, Christian <Christian.Dueben@uni-hamburg.de> Sent: Wednesday, July 15, 2020 08:28 To: Thomas Krichel <krichel@openlib.org> Cc: CollEc Run <collec-run@lists.openlib.org> Subject: Re: [CollEc] CollEc 2.0 Access Sorry for the late reply. The embedded Youtube video would display ads. That might be a problem. So I will look into options of hosting it directly on the server. The connection to the app collapses after opening it at test.collec.repec.org. It works fine when I directly access it via the IP. But somehow the communication does not work when accessing it via test.collec.repec.org. I added a functionality to the app. User can now access fragments of the graph through interactive D3 networks in the Co-Authors tab. What is left is the video. I am going to record it later this week, after recovering from a cold. Christian Düben Research Associate Chair of Macroeconomics Hamburg University Von-Melle-Park 5, Room 3102 20146 Hamburg Germany +49 40 42838 1898 christian.dueben@uni-hamburg.de http://www.christian-dueben.com -----Original Message----- From: Thomas Krichel <krichel@openlib.org> Sent: Donnerstag, 9. Juli 2020 15:32 To: Düben, Christian <Christian.Dueben@uni-hamburg.de> Cc: CollEc Run <collec-run@lists.openlib.org> Subject: Re: CollEc 2.0 Access Düben, Christian writes
Can you point test.collec.repec.org to http://95.216.35.87:8080?
I think tihs is done.
I set up the user authentication to restrict access until the app is publicly released.
I don't see much of a sense in doing that, but you are the boss here.
Start up speed varies greatly between sessions. Sometimes the app starts almost immediately and sometimes it takes quite a while or even fails. ShinyProxy handles this stage and I am not sure why it is so volatile.
I think over the post week I found that the machine was running very slow on certain time. I found disk space rising to 94%, causing me great concern. I don't know how to count what is in your part. I killed all backups that the machine had. As of lately disk space dropped considerably.
Many economists are not familiar with graph theory. And that is why the documentation explains the basics in a simply way. Edge weights are a key component of graphs and in my opinion one of the easiest parts to understand. Users do not have to be familiar with the slightly more complex shortest cost path algorithms or centrality measures to understand how edge weights work. If required, I can add another paragraph and a plot on edge weights to the documentation.
I think seeing a list of top-rated folk right at the start will prolly motivate users.
Hosting the video on the server would indeed make the cookie notification obsolete. The motivation to embed a video hosted on Youtube comes from Youtube's video player. It automatically adjusts the resolution to the user's bandwidth, provides a rather stable performance, works well in different browsers and allows users to modify the speed.
But then show you ads, right?
Other video players used online tend to be more annoying to use. They get stuck, complain about missing browser plugins, do sometimes not adjust dynamically to bandwidth limitations and come with fewer customizable settings. I can add the video via the HTML video tag. And then we check how it performs in the web application called by different browsers. If that does not work as intended we can still try other players or host it on Youtube.
I
I embedded the video in the introduction rather than the documentation because of feedback I received on GraphEc. The feedback was that users should understand right at the start how the app works - without having to click through the other tabs. The video is like a paper's abstract. It is a brief, convenient, initial overview presented to the user without him or her going through the details, i.e. the documentation. And besides that everyone likes to watch videos. Some users might not find it as enjoyable as funny cat videos, but it still makes the app appear more active and engaging from the start.
I hardly represent the averae user, so I can't comment on this.
You mention the year 2013 in your e-mail. Should I use that as the year you introduced CollEc?
I'm sorry. No. I'm really bad at this. I think the first mention as a runnig service on RePEc-run is on 25 January 2011.
I guess I somehow incorrectly understood CollEc to be a service from the early RePEc days.
Can't be since RAS is only from 99. Early days would be 1993 to 1997.
Thanks for offering me to use the database on the host. However, I still prefer a containerized MariaDB. With a container I do not have to manually intervene when the database crashes. Docker simply spins up a new container with an uncorrupted MariaDB image without any loss of data.
A similar story holds for Java. I tried running ShinyProxy directly on the host. The required Java version was not compatible with the Debian installation.
Not a problem at all since JAVA is not used for anything else.
Shinyproxy runs in a container but exposes the app directly on the host's ports. So, would it be possible to set the A record to that port? Or to use a Nginx reverse proxy to link the port the URL is pointing to to the port ShinyProxy exposes the app on?
That is done I think. If you mean a DNS record, it can't be tied to a part.
Besides that, I am also busy with other matters, including teaching and ongoing research projects.
I have no one to blame but me but it looks I now have about 100000 sick ArchEc files. -- Cheers, Thomas Krichel http://openlib.org/home/krichel skype:thomaskrichel _______________________________________________ CollEc-run mailing list CollEc-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/collec-run
Hi Lars, Thanks for the advice. I am going to check it out. Christian Düben Research Associate Chair of Macroeconomics Hamburg University Von-Melle-Park 5, Room 3102 20146 Hamburg Germany +49 40 42838 1898 christian.dueben@uni-hamburg.de<mailto:christian.dueben@uni-hamburg.de> http://www.christian-dueben.com From: Lars Vilhuber <lars.vilhuber@cornell.edu> Sent: Mittwoch, 15. Juli 2020 14:48 To: Düben, Christian <Christian.Dueben@uni-hamburg.de>; Thomas Krichel <krichel@openlib.org> Cc: CollEc Run <collec-run@lists.openlib.org> Subject: Re: CollEc 2.0 Access Hi Christian, you can either self-host the video, or use Vimeo, which doesn't display ads (the free tier should be fine for this) -- Lars Vilhuber, Economist Cornell University, Executive Director, Labor Dynamics Institute and ILR School - Department of Economics American Economic Association - Data Editor Journal of Privacy and Confidentiality - Managing Editor e: lars.vilhuber@cornell.edu<mailto:lars.vilhuber@cornell.edu> p: +1.607-330-5743 v: https://cornell.zoom.us/my/larsvilhuber w: http://lars.vilhuber.com/ Assistant: ldi@cornell.edu<mailto:ldi@cornell.edu> | +1.607-255-2744 ________________________________ From: CollEc-run <collec-run-bounces@lists.openlib.org<mailto:collec-run-bounces@lists.openlib.org>> on behalf of Düben, Christian <Christian.Dueben@uni-hamburg.de<mailto:Christian.Dueben@uni-hamburg.de>> Sent: Wednesday, July 15, 2020 08:28 To: Thomas Krichel <krichel@openlib.org<mailto:krichel@openlib.org>> Cc: CollEc Run <collec-run@lists.openlib.org<mailto:collec-run@lists.openlib.org>> Subject: Re: [CollEc] CollEc 2.0 Access Sorry for the late reply. The embedded Youtube video would display ads. That might be a problem. So I will look into options of hosting it directly on the server. The connection to the app collapses after opening it at test.collec.repec.org. It works fine when I directly access it via the IP. But somehow the communication does not work when accessing it via test.collec.repec.org. I added a functionality to the app. User can now access fragments of the graph through interactive D3 networks in the Co-Authors tab. What is left is the video. I am going to record it later this week, after recovering from a cold. Christian Düben Research Associate Chair of Macroeconomics Hamburg University Von-Melle-Park 5, Room 3102 20146 Hamburg Germany +49 40 42838 1898 christian.dueben@uni-hamburg.de<mailto:christian.dueben@uni-hamburg.de> http://www.christian-dueben.com -----Original Message----- From: Thomas Krichel <krichel@openlib.org<mailto:krichel@openlib.org>> Sent: Donnerstag, 9. Juli 2020 15:32 To: Düben, Christian <Christian.Dueben@uni-hamburg.de<mailto:Christian.Dueben@uni-hamburg.de>> Cc: CollEc Run <collec-run@lists.openlib.org<mailto:collec-run@lists.openlib.org>> Subject: Re: CollEc 2.0 Access Düben, Christian writes
Can you point test.collec.repec.org to http://95.216.35.87:8080?
I think tihs is done.
I set up the user authentication to restrict access until the app is publicly released.
I don't see much of a sense in doing that, but you are the boss here.
Start up speed varies greatly between sessions. Sometimes the app starts almost immediately and sometimes it takes quite a while or even fails. ShinyProxy handles this stage and I am not sure why it is so volatile.
I think over the post week I found that the machine was running very slow on certain time. I found disk space rising to 94%, causing me great concern. I don't know how to count what is in your part. I killed all backups that the machine had. As of lately disk space dropped considerably.
Many economists are not familiar with graph theory. And that is why the documentation explains the basics in a simply way. Edge weights are a key component of graphs and in my opinion one of the easiest parts to understand. Users do not have to be familiar with the slightly more complex shortest cost path algorithms or centrality measures to understand how edge weights work. If required, I can add another paragraph and a plot on edge weights to the documentation.
I think seeing a list of top-rated folk right at the start will prolly motivate users.
Hosting the video on the server would indeed make the cookie notification obsolete. The motivation to embed a video hosted on Youtube comes from Youtube's video player. It automatically adjusts the resolution to the user's bandwidth, provides a rather stable performance, works well in different browsers and allows users to modify the speed.
But then show you ads, right?
Other video players used online tend to be more annoying to use. They get stuck, complain about missing browser plugins, do sometimes not adjust dynamically to bandwidth limitations and come with fewer customizable settings. I can add the video via the HTML video tag. And then we check how it performs in the web application called by different browsers. If that does not work as intended we can still try other players or host it on Youtube.
I
I embedded the video in the introduction rather than the documentation because of feedback I received on GraphEc. The feedback was that users should understand right at the start how the app works - without having to click through the other tabs. The video is like a paper's abstract. It is a brief, convenient, initial overview presented to the user without him or her going through the details, i.e. the documentation. And besides that everyone likes to watch videos. Some users might not find it as enjoyable as funny cat videos, but it still makes the app appear more active and engaging from the start.
I hardly represent the averae user, so I can't comment on this.
You mention the year 2013 in your e-mail. Should I use that as the year you introduced CollEc?
I'm sorry. No. I'm really bad at this. I think the first mention as a runnig service on RePEc-run is on 25 January 2011.
I guess I somehow incorrectly understood CollEc to be a service from the early RePEc days.
Can't be since RAS is only from 99. Early days would be 1993 to 1997.
Thanks for offering me to use the database on the host. However, I still prefer a containerized MariaDB. With a container I do not have to manually intervene when the database crashes. Docker simply spins up a new container with an uncorrupted MariaDB image without any loss of data.
A similar story holds for Java. I tried running ShinyProxy directly on the host. The required Java version was not compatible with the Debian installation.
Not a problem at all since JAVA is not used for anything else.
Shinyproxy runs in a container but exposes the app directly on the host's ports. So, would it be possible to set the A record to that port? Or to use a Nginx reverse proxy to link the port the URL is pointing to to the port ShinyProxy exposes the app on?
That is done I think. If you mean a DNS record, it can't be tied to a part.
Besides that, I am also busy with other matters, including teaching and ongoing research projects.
I have no one to blame but me but it looks I now have about 100000 sick ArchEc files. -- Cheers, Thomas Krichel http://openlib.org/home/krichel skype:thomaskrichel _______________________________________________ CollEc-run mailing list CollEc-run@lists.openlib.org<mailto:CollEc-run@lists.openlib.org> http://lists.openlib.org/cgi-bin/mailman/listinfo/collec-run
Düben, Christian writes
Thanks for the advice. I am going to check it out.
I don't see a problem with self-hosting. This is not porn. I doubt we will hit our network limits with that. -- Cheers, Thomas Krichel http://openlib.org/home/krichel skype:thomaskrichel
participants (3)
-
Düben, Christian -
Lars Vilhuber -
Thomas Krichel