[comixed-dev] Re: New library code for fetching

  • From: "Darryl L. Pierce" <mcpierce@xxxxxxxxx>
  • To: comixed-dev@xxxxxxxxxxxxx
  • Date: Wed, 27 Nov 2019 09:19:18 -0500

The SonarCloud plugin has failed for me five different times, including the
following error message:

2019-11-27T14:03:32.1536110Z [ERROR] Failed to execute goal
org.sonarsource.scanner.maven:sonar-maven-plugin:3.7.0.1746:sonar
(default-cli) on project comixed: Project was never analyzed. A regular
analysis is required before a branch analysis. -> [Help 1]

I'm going to have to give this up for a while, but I did push the branch
[1] if someone else would like to poke at it and get it working. I added a
comment to an existing bug [2] to see if someone can give us an idea of how
we do a "regular analysis".

[1] https://github.com/comixed/comixed/tree/enable-sonarcloud-java
[2] https://github.com/gabrie-allaigre/sonar-gitlab-plugin/issues/225

On Wed, Nov 27, 2019 at 8:24 AM Darryl L. Pierce <mcpierce@xxxxxxxxx> wrote:

I took a shot at it over coffee this morning. I created the secret, added
the Maven plugin, created the workflow and it's running its analysis now.

Once we get a good foundation of what sorts of Github actions help us out,
we should discuss what sort of flows we put together.

For example, my main push right now was just to get an action in place
that would build a new zip file each time we push/merge to develop. But we
still have the development workflow there that does the same but on someone
pushing a tag to the repo. And now we've got the SonarCloud analysis.

What'd I'd like is for us to decide on a strategy of what actions to have
and when in the process.

On Tue, Nov 26, 2019 at 7:18 PM João Miguel Côrte-Real França Pereira <
jmcrfp@xxxxxxxxx> wrote:

I had to look around because I'm used to the sonar server we have
installed in my company and I'm not familiar with the cloud version.
But the sonarcloud automatic analysis only works for script languages,
for compiling languages we need to setup it in the build.
https://github.com/SonarSource/sonarcloud-github-action this is the link
to setup with actions. I didn't put it because I don't have the sonar token

On Tue, Nov 26, 2019 at 8:21 PM Darryl L. Pierce <mcpierce@xxxxxxxxx>
wrote:

I wonder if it doesn't realize it's also a Java project?
[image: Screen Shot 2019-11-26 at 3.20.45 PM.png]

On Tue, Nov 26, 2019 at 3:20 PM Darryl L. Pierce <mcpierce@xxxxxxxxx>
wrote:

Hrm, no idea. I see where it's only going down to the resource files
only. Not sure what's up with that. It sure is having a fit over the CSS
files: it doesn't like :host or ::ng-deep tags. :D

On Tue, Nov 26, 2019 at 1:42 PM João Miguel Côrte-Real França Pereira <
jmcrfp@xxxxxxxxx> wrote:

For some reason none of the java classes are in sonarcloud. any
reason why?

On Tue, Nov 26, 2019 at 5:07 PM Darryl L. Pierce <mcpierce@xxxxxxxxx>
wrote:

I'll check it out as I use IntelliJ for work and this project.

On Tue, Nov 26, 2019 at 12:02 PM João Miguel Côrte-Real França
Pereira <jmcrfp@xxxxxxxxx> wrote:

Cool, I usually have the sonarlint plugin enabled on my Intellij so
that I don't make big silly mistakes. :P

On Tue, Nov 26, 2019 at 4:57 PM Darryl L. Pierce <mcpierce@xxxxxxxxx>
wrote:

For this one action, I ended up having to have it create a tag
since we can't push a release without one. And it's only goal is for 
doing
pushes to develop, so people can grab a prerelease easily to play with.

I just checked out SonarCloud, looks nice. I've enabled it for the
project and am checking it out now. It's running its analysis, so I'll
follow up on it after lunch. But just poking around it's giving me a 
LOT of
insight into things on the comixed-frontend project! Very nice. :D

On Tue, Nov 26, 2019 at 10:10 AM João Miguel Côrte-Real França
Pereira <jmcrfp@xxxxxxxxx> wrote:

Nice, I forgot the V. I also think we don't need tags, maybe only
for releases.
It's also missing the action for the PRs, right? (and did you
considered adding sonarcloud to them?)

On Tue, Nov 26, 2019 at 3:06 PM Darryl L. Pierce <
mcpierce@xxxxxxxxx> wrote:

Great minds! That's what I ended up doing (but with 'v*').

I think we've got a decent workflow step setup now to handle
things on develop. Right now it's pushing a development build and 
then
using my new action to do the tag (though I'm now thinking that we 
don't
need tagging).

On Tue, Nov 26, 2019 at 8:22 AM João Miguel Côrte-Real França
Pereira <jmcrfp@xxxxxxxxx> wrote:

It should be possible with something like:

on:
  created:
    tag:
      - *-*



On Tue, Nov 26, 2019 at 1:17 PM Darryl L. Pierce <
mcpierce@xxxxxxxxx> wrote:

I'm hoping we'll have the automated builds up and running again
now that we're moving the repo away from Travis CI and to using 
Github
Actions. I wrote one last night to do the tagging when things are 
checked
into develop. Now we only need an action that reacts to a tag 
being created
(not pushed) and does a build and we'll be good to go.

On Mon, Nov 25, 2019 at 4:54 PM bareheiny <
dmarc-noreply@xxxxxxxxxxxxx> wrote:

Cheers – that pretty much confirms what I thought was
happening.



I’ve just had a quick look at the log data, and there seem to
be a couple of things going on.



The time between get 100 requests ranges from 1.4 seconds to 6
minutes, averaging 46 seconds.  The time for a get 100 to 
complete ranges
from 0 seconds to 5 minutes, averaging 48 seconds.



This leads to two questions – what’s causing the variability
in the time for a get to complete, and the next to begin, and 
what’s
causing the variability in the time for a get to return a result.



At first blush, I would think that the time for a  get to
complete would depend on the size of the comics in the get 
request – I’m
assuming the each file needs to be loaded for the cover to be 
extracted –
which could take some time for the larger files.  The time 
between a get
completing and the next starting...maybe processing the metadata 
for
loading into the drop down lists etc.?



I do have a copy of my comics with the comic info files
removed – I’m interested in knowing how loading a library with no 
metadata
changes the load times – that’s my next job, but will take a 
number of days
to load everything in 😊





Meanwhile, I’ll wait for you change to make it to a release,
and have another look...but I’m expecting that I may see delays 
of up to 6
minutes for 100 comics to be displayed (based on the above).





*From: *Darryl L. Pierce <mcpierce@xxxxxxxxx>
*Sent: *Tuesday, 26 November 2019 9:21 AM
*To: *comixed-dev@xxxxxxxxxxxxx
*Subject: *[comixed-dev] Re: New library code for fetching



Not a problem. :D



When you log into the app, it will (very soon) stop trying to
download the entire library in chunks of 100 comics/request).



Instead, when you go to the library page (/comics), the
browser will send a request to the backend and ask for comics to 
display on
the current page.That's determined by three things:

1. the current page of comics you're on,

2. how many comics you are showing on a page, and

3. the sort order for the comics.



The display widget (called DataView) knows how many total
comics there are, and how many you want to show per page, and 
divides that
into the number of pages. So if you're viewing comics 25 at a 
time then the
first page is comics 1-25, the second is 26-50, etc. So as you 
navigate
through the pages of comics, the browser sends a request for the 
comics to
show just for that page.



The long and short of it is, if you're only viewing 25 comics
per page, then the browser will only have those 25 in memory. 
When you go
to the next or previous page of comics the browser will go and 
get them
from the backend and then those are the ones it has in memory.



Is that a better description?



On Mon, Nov 25, 2019 at 2:34 PM bareheiny Alexander <
dmarc-noreply@xxxxxxxxxxxxx> wrote:

Mmmm....this is sounding familiar, I’ll need to revisit the
open tickets to refresh my memory.



Can you outline what happens when the library is being loaded
(in laymen’s terms)?



I have a rough idea, but want to double check before I say
something stupid.







On 26/11/2019, at 05:06, Darryl L. Pierce <mcpierce@xxxxxxxxx>
wrote:



With the code that I checked in yesterday, it should be a lot
faster to load since it's no longer going to try and load 
everything once
you log in. It's going to now start pulling strategic chunks of 
data as
needed, only as much as need be shown on the current page. The 
old code is
still there as the collections views still depend on it. But for 
the main
library viewing it only loads what it needs.



Regarding caching things, we had/have a ticket for caching the
cover image so they can be more quickly retrieved. I'm not sure 
if pulling
them from a database is going to be any faster than extracting 
them out of
the comic file, but my thought was to have CX maintain a 
thumbnails/caching
directory where it would story covers hierarchically by hash 
value (break
up the hash into 4-char pieces and each represents a 
subdirectory). Since
file access is fastest, it can get the hash, look for the file 
and, if it's
not there, grab it from the archive, cache it and return it. But 
I'm open
to other ideas for how to make it faster.



On Mon, Nov 25, 2019 at 5:32 AM bareheiny Alexander <
dmarc-noreply@xxxxxxxxxxxxx> wrote:

Over the years, I’ve been explored YAC, Ubooquity and
ComicRack (something’s happening here...the website is showing a 
new
landing page).

As far as I can tell, all of the applications extract and
store comic covers – making the thumbnail generation a lot 
quicker.  Is
that something you’ve considered for CR?



My (non-developer) thoughts are that cover display would be
pulled from pre-extracted images...statistics and filter fields 
(publisher,
characters etc.) would be pulled from the database via SQL (I’m a 
BI
developer, so I see SQL everywhere – if all you have is a hammer, 
all you
see are nails as they say) as the user navigates to the relevant 
pages –
rather than having to wait for the entire library to load and get
everything populated.



As it stands, with CX trying to load the entire library and
all metadata....it takes far too long to load a large library (as 
I’ve
mentioned on GitHub, my session times out before the library 
fully loads).
If there is no metadata, the library loads quick smart (to be 
fully
confirmed).



Not being an application developer, I’m likely missing vital
information / experience...I’m more than happy to be enlightened. 
 Also
happy to be told that this isn’t the appropriate list for my 
input :)





*From: *Darryl L. Pierce <mcpierce@xxxxxxxxx>
*Sent: *Monday, 25 November 2019 2:43 PM
*To: *comixed-dev@xxxxxxxxxxxxx
*Subject: *[comixed-dev] New library code for fetching



I spent time yesterday and today writing a new set of actions
for the library to move away from loading the whole library into 
the
browser. What it does now is, when you go to the library view, it 
fetches
just the comics for the current page. And as you move about, 
changing
sorting, switching pages, changing the number of comics to show, 
etc, it
makes a REST call to fetch the comics to display and refreshes 
the view.



It's going to be a process to refactor other pages, but what
I'm thinking is this:



1. Have the main page load specific statistics (rather than
extracting it from the comics as they're loaded) with a single 
REST API.

2. Have each of the collections page use a similar request (or
enhancements to the new request) to get comics in pages.

3. Change the current continuous update to do some other,
simpler actions to get statistics on the library rather than 
loading
everything. Or just dump that continuous update entirely.



And these are all things I think we can get done by the end of
the year when I want to put the 0.5 release out for RC.



I merged this one, but would like to start putting things up
for PRs to get feedback if you guys are comfortable with getting 
more
hands-on now. :D


--

Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap
together." - Gord Downie





--

Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap
together." - Gord Downie



--

Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap
together." - Gord Downie





--
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap
together." - Gord Downie



--
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap
together." - Gord Downie



--
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap together."
- Gord Downie



--
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap together." -
Gord Downie



--
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap together." -
Gord Downie



--
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap together." -
Gord Downie



--
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap together." - Gord
Downie



-- 
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap together." - Gord
Downie

PNG image

Other related posts:

  1. Home
  2. comixed-dev
  3. Archive
  4. 11-2019