These are chat archives for exceptionless/Discuss

7th
Jan 2016
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:20
hey :-)
Blake Niemyjski
@niemyjski
Jan 07 2016 20:20
hey
Eric J. Smith
@ejsmith
Jan 07 2016 20:21
so we are talking about recording page views...
we are thinking that we would just record it as a feature event type
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:21
right, and I mentioned that sessions are a really helpful first step
Blake Niemyjski
@niemyjski
Jan 07 2016 20:21
and we could use a feature type event and the value could be the total time it took to render the page and we could have extended data for other perf metrics.. Butt hte question I havei s
Eric J. Smith
@ejsmith
Jan 07 2016 20:21
yeah, what Blake is working on will be nice.
I guess just counting event occurrences can be number of page views.
Blake Niemyjski
@niemyjski
Jan 07 2016 20:22
what if you are on a page, and you send a feature usage with the message / source as the page url and then you have a feature usage event for some button click.. how could you narrow it down to this page view the user did xyz
Eric J. Smith
@ejsmith
Jan 07 2016 20:22
value could be the page load time… that seems fine.
we wouldn’t be able to do that right now.
Blake Niemyjski
@niemyjski
Jan 07 2016 20:23
thing about having a special event type for pageviews. is you could potentially use heart beats + page views to keep track of how long a user was on the page.
server side
Eric J. Smith
@ejsmith
Jan 07 2016 20:23
we would need to take the session link thing and make it generic where we have entity links
and you can search those.
I don’t want to get into that right now.
Sander Rijken
@srijken
Jan 07 2016 20:24
also considering SPAs when thinking about pageviews.. what a pageview is isn’t that clear these days :)
Eric J. Smith
@ejsmith
Jan 07 2016 20:24
that is a whole new pandoras box.
yeah, we can wire into the router in angular and aurelia
Blake Niemyjski
@niemyjski
Jan 07 2016 20:24
yeah and your not going to have page load for a spa app
Eric J. Smith
@ejsmith
Jan 07 2016 20:24
to record page views in those
Blake Niemyjski
@niemyjski
Jan 07 2016 20:24
page load time*
Eric J. Smith
@ejsmith
Jan 07 2016 20:24
you still have load
the router will potentially load resources
but we might not have all the metrics that a normal browser page load has.
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:28
okay, i don’t know if this topic somehow touches what I have in mind
but finally, everything that we are trying to capture is „things that happen“ (events, log messages, mouse clicks) and put them in context (page view, session)
this would actually make up a hierarchical structure, as in „tree"
Eric J. Smith
@ejsmith
Jan 07 2016 20:31
yeah, we just gotta be careful to not let the scope get out of control.
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:31
yes
another thing is „chain of events"
that’s one thing we’re trying to figure right now at work. we have an application that uses a message bus
every time something bad happens, we have a single exception with its stack trace
Eric J. Smith
@ejsmith
Jan 07 2016 20:32
so we have the concept of stack now, which is basically a parent… and now session is basically a parent as well… and now we are wanting page view to be another parent...
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:32
somewhere on the bottom of the stack, there is „Handle<BlahMessage>()"
but BlahMessage has been sent over the bus, and queued….
by another handler. and this has been handling another message, that has been queued by another handler.
Eric J. Smith
@ejsmith
Jan 07 2016 20:33
yeah, and totally decoupled
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:33
yes. so, how do i get context?
Eric J. Smith
@ejsmith
Jan 07 2016 20:33
that is a good question...
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:33
i would need to create some kind of correlation context.
Eric J. Smith
@ejsmith
Jan 07 2016 20:34
I guess one thing that we do is keep track of the message id
then add that to the events...
but it seems like we need to pull this whole concept up to be more of a 1st class thing.
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:34
:-)
session is somewhat coupled to the duration of the user using the thing
i would rather want to create a context on my own, and assign events to it
and contexts could be linked together
Eric J. Smith
@ejsmith
Jan 07 2016 20:35
I think what we need is the concept of event references.
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:36
have you been looking into this? https://github.com/narratr/story
Eric J. Smith
@ejsmith
Jan 07 2016 20:36
where a custom data property can be a link to another event with that id on it
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:36
don’t know if i mentioned it here already
i don’t like the notation, but i like the concept itself
Eric J. Smith
@ejsmith
Jan 07 2016 20:38
yeah, that is interesting.
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:38
it’s about logging things but having context attached
you could use that for all kinds of things. sessions, requests, message handlers, whatnot
Eric J. Smith
@ejsmith
Jan 07 2016 20:38
yeah, I think if you just had the concept of event references then you could pretty much link anything together.
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:39
:)
Eric J. Smith
@ejsmith
Jan 07 2016 20:39
we are talking about adding more metrics things soon and letting people build dashboards...
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:40
i read the discussion on github
Eric J. Smith
@ejsmith
Jan 07 2016 20:40
I want to try and keep the scope of the session stuff limited to not much more than it is right now so that we can get onto that because I think it will be a really big business value
but I think we could do the event reference thing and then that would be really useful for the reports too.
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:41
i think that is a API thing.
Eric J. Smith
@ejsmith
Jan 07 2016 20:41
because you could say show me a graph of everything that myentityref = blah
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:41
maybe simple references is enough from a model point of view
but fluent interfaces and assistance for automatically creating such references in the clients would make the difference
creating one event per HttpRequest for example and linking all events created during this request to it for example
the UI could then not only allow navigation to the reference, but also show lists of all referencing events
Blake Niemyjski
@niemyjski
Jan 07 2016 20:48
yeah
like a mini stack per page view
aka reference event
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:51
in .UI, I have 8 tests that succeed every single time
on my Macbook
so the problem only happens in integration builds?
Blake Niemyjski
@niemyjski
Jan 07 2016 20:52
yeah
fails with that timeout at random, seems to happen everytime if I reduce the karma logging
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:52
d'oh
Blake Niemyjski
@niemyjski
Jan 07 2016 20:55
that story lib is really cool
Frank Ebersoll
@frankebersoll
Jan 07 2016 20:55
as i said, i don’t like the „static“ nature of the API
but using „using“ for creating context is a technique that i’ve already used myself
and connecting events that belong together with some kind of correlation seems just logical
Blake Niemyjski
@niemyjski
Jan 07 2016 21:00
yeah
thing is, if we can’t make it easy / seamless on the developers view point
is it even worth doing
I love those drop it in and you get instant wins
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:02
yes. it needs to be seamless and intuitive
Blake Niemyjski
@niemyjski
Jan 07 2016 21:02
I think on javascript it’s really easy to do
but in a winforms / asp.net app
not really
owin yes, if you register middlware
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:10
no idea regarding this karma / phantom problem
sorry. we can’t even switch to mochajs like we did on .javascript, because those test require the DOM
Blake Niemyjski
@niemyjski
Jan 07 2016 21:12
these tests add little to no value
...
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:13
(i didn’t want to write that)
Blake Niemyjski
@niemyjski
Jan 07 2016 21:13
there not e2e
LOL
@ejsmith tempted to just force run the tests they run or they don't
they did when we were building the site cause I was a huge angular nub
lol
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:15
the last thing i was looking into before christmas was bundling and build process
the only thing I remember is that it was a mess.
Blake Niemyjski
@niemyjski
Jan 07 2016 21:19
lol
yeah you made some sweet improvements to that
Eric J. Smith
@ejsmith
Jan 07 2016 21:19
sorry, people drive by...
Blake Niemyjski
@niemyjski
Jan 07 2016 21:19
did we merge it
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:20
the improvements, yes. but there were little
Blake Niemyjski
@niemyjski
Jan 07 2016 21:24
sigh so much to do
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:24
i wish i had documented my findings, so we could easily discuss them
Eric J. Smith
@ejsmith
Jan 07 2016 21:25
yes, endless amount of things to do. :-)
Blake Niemyjski
@niemyjski
Jan 07 2016 21:26
feel like it was so long ago
I forgot about it myself
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:33
maybe we can summarize what we have now.
  • lots of typescript => tsproject => one single flat .js file (let’s call it out.js)
  • out.js => UMD => umd.js
  • umd.js => uglifyer => result.js
is this true?
Blake Niemyjski
@niemyjski
Jan 07 2016 21:34
yup
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:36
our requirements:
  • fast build during development (enables fast test execution)
  • tiny js file for the browser
  • umd for supporting different loading strategies
  • modularization?
Blake Niemyjski
@niemyjski
Jan 07 2016 21:37
last one isn’t a hard requirement
thats why we have two different byuilds
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:37
i mean the „lazy load what we need into the browser“ kind of modularization
Blake Niemyjski
@niemyjski
Jan 07 2016 21:39
yeah that would be super nice but a ton of work
and breaking api changes?
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:40
having everything in one file somehow contradicts the „tiny js file“ requirement
breaking api changes?
Blake Niemyjski
@niemyjski
Jan 07 2016 21:42
yeah it does, I’m talking about having async loading and have a really small surface for logging / etc
I ndon’t think its worth it
I can’t type
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:42
i was asking: shouldn’t users bundle the thing themselves?
Blake Niemyjski
@niemyjski
Jan 07 2016 21:42
we’d like it if they didn't
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:43
after all, we’re just another library.
Blake Niemyjski
@niemyjski
Jan 07 2016 21:43
because we could put it on a cdn and update it
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:43
yes, that’s the next requirement.
Blake Niemyjski
@niemyjski
Jan 07 2016 21:43
e.g add session support without them having to update and deploy
Eric J. Smith
@ejsmith
Jan 07 2016 21:44
yeah, I think that is what we need to try and work towards.
so we don’t have to rely on people updating their js clients all the time.
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:45
okay. but then, we would still have to decide on having one „big" file vs. some more „smaller“ files that are loaded on demand
Eric J. Smith
@ejsmith
Jan 07 2016 21:46
I think it should be a single file.
I certainly hope that we are able to keep the js client small.
but we would need different files for things like angular support
so you would load our main client and the angular plugin.
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:48
we have some parts that could be partitioned. one thing being tracekit, that makes up almost a third of the file
yes, I think we should have a core library and then load plugins or integrations as needed
Eric J. Smith
@ejsmith
Jan 07 2016 21:49
do you think we would want to not include tracekit in some situations?
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:50
we would always include it, but we wouldn’t update it as often
i don’t know, it’s one additional request vs. a bigger file that has to be loaded every update of our lib
Eric J. Smith
@ejsmith
Jan 07 2016 21:50
yeah, but we probably should optimize for as few requests as possible.
hopefully we aren’t updating the client all that often.
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:51
hopefully we are :-)
Eric J. Smith
@ejsmith
Jan 07 2016 21:51
so it will get cached and not be a big deal to have a little exta kb
Blake Niemyjski
@niemyjski
Jan 07 2016 21:51
yeah
almost every error service bundles it
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:53
ok, so we should probably put everything into a single file, as it is now
Eric J. Smith
@ejsmith
Jan 07 2016 21:54
yeah, I think so.
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:54
reason is, we wouldn’t want to write the module loading code ourselves. even if we do, it will take up some space. and every existing solution that i tried, combined with several kinds of uglifiers, resulted in bigger files than what we have now
Eric J. Smith
@ejsmith
Jan 07 2016 21:55
we may even want to offer different versions where one is the full client + angular plugin bundled in.
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:55
yes, and different versions for „logging API“ vs „full extensibility API“
i mean, our public API is not that big
Eric J. Smith
@ejsmith
Jan 07 2016 21:55
so when I have looked at other clients like raygun, I don’t even think they have any module loading
what they do is setup an object that they queue operations to and then async load their code in.
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:56
but offering every single plugin and provider that we have for extensibility uses lots of space, because those names won’t be minified
yes, we talked about that
we could try something like that
Eric J. Smith
@ejsmith
Jan 07 2016 21:57
same thing that google analytics does
but that is probably a decent sized change to the client.
Frank Ebersoll
@frankebersoll
Jan 07 2016 21:58
the main problem is that I don’t fully understand how bundling and minfication works as it is right now
Eric J. Smith
@ejsmith
Jan 07 2016 21:59
hrmm… haven’t looked too much… is it bad?
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:01
well, i haven’t looked into how uglify works, but it seems that there is lots of potential
Blake wrote something like „I don’t like how this typescript is compiled, because it puts it into the prototype“
i think what he means is something like that: e.prototype.onProcessQueue=function(){….
Eric J. Smith
@ejsmith
Jan 07 2016 22:02
it’s compiling down to ES5, it has to do prototypes
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:02
then, i don’t understand why it doesn’t cache e.prototype and use this
Eric J. Smith
@ejsmith
Jan 07 2016 22:03
would have to see the code it’s translating from.
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:03
like: `ep=e.prototype;ep.onProcessQueue=…;ep.onBlah=….;ep.
Eric J. Smith
@ejsmith
Jan 07 2016 22:04
yeah, not sure why it would be doing that… but I would trust that TS is doing the right thing. :-)
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:04
„prototype“ is all over the place. it could easily cut some letters there
Eric J. Smith
@ejsmith
Jan 07 2016 22:04
ahh
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:04
i’m talking about the uglifier.
Blake Niemyjski
@niemyjski
Jan 07 2016 22:04
Uplift does a horrible job at translating somethings
Eric J. Smith
@ejsmith
Jan 07 2016 22:04
yeah, I see what you mean.
Blake Niemyjski
@niemyjski
Jan 07 2016 22:04
Uglify
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:04
then, another thing: say, we only use „onProcessQueue“ in our own code
it could be obfuscated to „a"
Eric J. Smith
@ejsmith
Jan 07 2016 22:05
yeah
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:05
but it doesn’t, because it doesn’t know what is public and what isn’t
Eric J. Smith
@ejsmith
Jan 07 2016 22:05
so the problem is that it thinks everything we have is a public API
because we are exporting it all
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:06
and that’s because tsproject puts everything on the top level
Eric J. Smith
@ejsmith
Jan 07 2016 22:06
so it can’t mangle the names
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:06
other bundling technologies let you define the „entry point“ of the application
Eric J. Smith
@ejsmith
Jan 07 2016 22:06
think we have to decide if we want people using the API directly or not.
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:06
then, everything that entry point uses is minified, but not put into your public API
yes, and we could even make two versions - one with „extensibility“ and one without
that’s what I meant before.
Eric J. Smith
@ejsmith
Jan 07 2016 22:07
I don’t think we even need to do that.
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:07
it would make a big difference, because there are so many unmangled names in the lib
Eric J. Smith
@ejsmith
Jan 07 2016 22:08
if we move to a top level dispatch type of system where commands are being put into a queue using strings as the names of the commands then we could easily have a command to add a plugin and it would just be a function
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:09
yes, i like that idea
Eric J. Smith
@ejsmith
Jan 07 2016 22:09
then you could minify everything.
everything would be internal
everything is public and exported
so it probably causes it to think everything is exported as it walks down the tree
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:13
tsproject is the cause
that’s not the cause
Eric J. Smith
@ejsmith
Jan 07 2016 22:14
tsproject is some dudes project system and what we are using to bundle?
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:14
yes. and it flattens everything
Eric J. Smith
@ejsmith
Jan 07 2016 22:14
and it is bundling in a way that makes everything public?
look at 2132
there we have SubmissionResponse, which probably isn’t used by anything outside our lib
but everything is exported by name, so nothing can be minified. neither the type’s names, nor the members
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:25
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:30
but very few things apply to us, as we want to put everything into one file
so it boils down to a) optimizing what tsproject does or b) adding another step behind tsproject to help uglify or c) optimize what uglify does or a combination of those
Eric J. Smith
@ejsmith
Jan 07 2016 22:32
I see there is a new version of tsproject
what version are we using?
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:33
1.0.5 i think
Eric J. Smith
@ejsmith
Jan 07 2016 22:33

TsProject 1.2.0 provides bundle minification by shortening identifiers and whitespace removal.

TsProject 1.1.0 provides project watch support for cache optimized, incremental builds.

TsProject 1.1.0 supports Typescript 1.7!

Frank Ebersoll
@frankebersoll
Jan 07 2016 22:33
oh :-)
Eric J. Smith
@ejsmith
Jan 07 2016 22:34
sounds relevany
relevant
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:34
sounds like at least some things to try
Eric J. Smith
@ejsmith
Jan 07 2016 22:34
yeah
Frank Ebersoll
@frankebersoll
Jan 07 2016 22:36
i had some fear of delving into this. because, after all, i wrote my last compiler in college
but i have some ideas of how i’d like this output file to be. so, fuck it.
i’m looking into this now :-)
"Merge pull request #67 from ToddThomson/minification …
ToddThomson committed 4 hours ago"
as we speak… :-D
Eric J. Smith
@ejsmith
Jan 07 2016 22:41
haha
maybe post an issue in there and ask him.