« first day (3042 days earlier)      last day (138 days later) » 

00:05
REFRESH!
[Minesweeper] 117 Games Played. 94 Bombs Used. 15060 Moves Performed. 13 New Users
01:03
@Vogel612 @MathieuGuindon getting reference assemblies from nuget seems to fix at least that initial problem. Another thing is the abject lack of nuget packages and some more config shenanigans. I'll keep it on my backburner.
Sleep now
Got a meeting around my Master's Thesis tomorrow ... (or more correctly in 11 hours)
 
3 hours later…
03:50
 
3 hours later…
06:39
@MathieuGuindon Now I know again what the issue was. You should generally reject all JWTs specifying alg = none.
More generally, you should reject all JWTs with unexpeted parameters.
 
5 hours later…
12:09
@Duga gonna need to start tracking RD3 stars, too. Granted, oletools has a bit of a headstart...
 
4 hours later…
16:33
> Introduce a simplified version of the PublicApiClient used by the website, and modify the VersionCheck feature to use it to query the API back-end endpoint (and then receive a rich Json response) instead of querying a website URL (and then only receive a string with a version number).
ugh wtf is this diff
branch probably not up-to-date
ah, it didn't like the squash-merge
16:49
@Duga 1/4
(already in Rubberduck3)
hm, that worked locally
wait no, it built locally... forgot to actually run the tests
 
2 hours later…
18:53
@MathieuGuindon I would rather depend on github infra than on godaddy infra
just saying
definitely!
not sure what you're referring to though?
oh for the version check against the API instead of the website?
hm
@MathieuGuindon any particular reason you chose to use packages.config over using PackageReference elements inside the csproj?
if not I am going to migrate to PackageReference, because that works out of the box by just calling dotnet build instead of requiring a nuget restore beforehand
19:47
nope, no reason in particular
that said I can't seem to get the tests to run :(
well some of them do, but a good chunk don't
> System.TypeInitializationException : The type initializer for 'Moq.DefaultValueProvider' threw an exception.
----> System.IO.FileLoadException : Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
@Duga looks like Max made his Hacktoberfest picks! :D
I recall Moq needed some special assembly access permissions
sigh....
> // Allow Moq mocks to inherit from stub classes and thus enable partial mocks
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
hmm ... seems like that is set up correctly then ..
I'll look at that a bit later, workday isn't quite finished yet :)
what, you actually work during the workday?
19:55
lol
currently sitting in a (useless) meeting of 12 people
@BigBen spent 2 hours working, then an hour "commute" to a meeting for uni, then enjoyed the autumn sun for a few hours before coming back home
the workday is not a semantically applicable concept to me
at least now 4/5 days my commute consists in taking my coffee downstairs :D
eesh that's a rough commute for a uni meeting
My commute is three times a week descending into our cellar and two times a week riding my bike for about 15 minutes.
20:09
@BigBen it did include a 15 minute buffer (because showing up late to a first in person meeting is not cool), which grew by another 15 minutes because I caught a better connection in public transit
so it theoretically could've been 30 minutes, but that would've been cutting it too close for comfort.
Well yeah, I definitely agree on the buffer
21:05
@Vogel612 so for the PR (assuming I eventually get the tests to run 😅), it would be better to replace the API client with a service that pulls the tags directly from GitHub... and would be feature creep to eventually pull things like inspection examples from the API? I'll rework the service in that direction if that's the case.
@MathieuGuindon I'm not sold either way, TBF, but infrastructure is something you need to keep in the back of your head when doing something like that
I can see why a rich JSON response would be more useful, but I don't think we want it for the version check alone
but we want any integrated help to use the api (heavily cached, maybe)
In any case the website will have to keep supporting the legacy routing that returns a plain version string, so the check doesn't break in any older RD builds out in the wild
that also runs against the website?
welp
yeah... welp indeed!
^^ the current urls
Ugh link doesn't work because the file was renamed
oh wow and it's http urls
Anyway that's why I was confused with your infrastructure comment, because the dependency is kind of already there
Still I'll make it a service that hits GitHub directly instead
@MathieuGuindon only one instance of "rubberduckvba" on that page
21:17
And then RD3 may or may not need an API client
"need" is probably a strong word there ...
yeah
TBH grabbing the API client from the website project was just lazy =)
I mean ... that's usually a good instinct :D
 
1 hour later…
22:39
> As per discussions, I'll push an update to replace the API client with a service that hits GitHub directly instead.
 
1 hour later…
23:50
[rubberduck-vba/Rubberduck] 1652 stars vs. [decalage2/oletools] 2223 stars

« first day (3042 days earlier)      last day (138 days later) »