|
a hot gujju bhabhi posted:Why are there no logs? How do you look at historical events? if this is still that stock ticker project, if there's a problem, he'll see it on TV.
|
#
?
Jun 14, 2018 11:53
|
|
|
|
| # ? May 18, 2024 13:51 |
|
|
a hot gujju bhabhi posted:Why are there no logs? How do you look at historical events? Usually via Chinese whispers. It's character building or something like that. In reality there are only a finite number of events and usually you will see the same problem happen again on another day that you can run in parallel with a system that has logging or a debugger attached. This isn't a NYSE project although they have asked about using similar TVs before, these are incredibly underpowered devices: Samsung posted:Expected performance The NYSE devices run 1080p at 60fps, with 12 monitors hanging off a single PC. I have a dev server running in parallel so I can sometimes track issues live, but yes live streaming on TV helps.
|
|
#
?
Jun 14, 2018 14:41
|
|
|
MrMoo posted:Making a webapp with no logs, no log server, and no window scrolling or pretty much any useful input device, what to do with fatal errors? “1 seconds” oof.
|
|
#
?
Jun 15, 2018 16:06
|
|
|
💩 I'll credit you in the commit log.
|
|
#
?
Jun 15, 2018 16:39
|
|
|
Webpack problem: For some strange reason, Webpack isn't outputting any files for me. All file paths are correct as far as I can tell, MyStyles.less is listed as a dependency in main.ts, and it only began having these issues when I tried adding the LESS handling. How should I proceed from here, what should I look for to debug this? E: Dammit, I forgot at the time, and don't entirely remember now. IIRC, the issue was that the output path defaulted to "/dist"; files were being output, but not in the right place. I added "path: __dirname" to output and everything worked after that. webpack.config.js - code:code:darthbob88 fucked around with this message at 02:39 on Sep 2, 2018 |
|
#
?
Jun 16, 2018 00:18
|
|
|
I usually try not to use packages for anything unless i’m absolutely desperate, but I’m realized today that I really really really hate sorting things. It makes my brain hurt and it’s the one instance where I have no shame letting a package work it’s magic
|
|
#
?
Jun 18, 2018 21:43
|
|
|
Sometimes it really is best to just admit that you stand in the shoulders of giants, and that they know better.
|
|
#
?
Jun 18, 2018 21:53
|
|
|
Dates suck enough that I feel zero guilt at adding a library for dealing with them.
|
|
#
?
Jun 18, 2018 21:58
|
|
|
Dates and encryption are the two things you really shouldn't do yourself. Both are going to bite you in the rear end down the road, and quite spectacularly annoyingly so.
|
|
#
?
Jun 18, 2018 22:35
|
|
|
Just use packages for most stuff. Someone has probably already solved whatever problem way better than you could have.
|
|
#
?
Jun 18, 2018 22:40
|
|
|
JazzmasterCurious posted:Dates and encryption are the two things you really shouldn't do yourself. Both are going to bite you in the rear end down the road, and quite spectacularly annoyingly so. I can confirm that bit about encryption. There's some support nowadays but I regret thinking I could use it, all browsers do it differently with different support for different algorithms. It's a mess.
|
|
#
?
Jun 18, 2018 22:40
|
|
|
prom candy posted:Just use packages for most stuff. Someone has probably already solved whatever problem way better than you could have. Yup. It's one thing to write it to get the practice, but there's (almost) always something done already that 20-1000 people have contributed input and fixes to already.
|
|
#
?
Jun 18, 2018 22:44
|
|
|
JazzmasterCurious posted:Dates and encryption are the two things you really shouldn't do yourself. Both are going to bite you in the rear end down the road, and quite spectacularly annoyingly so. T I M E Z O N E S well I guess that's a date/datetime object in many languages
|
|
#
?
Jun 18, 2018 22:50
|
|
|
TheFluff posted:T I M E Z O N E S Yeah timezones and leap anything was my thought. Say what you will about Tom Scott but his rant about timezones is pretty great in projecting the horror of it all.
|
|
#
?
Jun 18, 2018 22:54
|
|
|
I use to be anti-packages, but after many mistakes I have learn many things are better handled with packages. Dates are already mentioned. Escaping anything or satinifying anything. If you are going to receive random html from a unknown source, and satinify it. You better use the best tools available and not try to satinify it yourself.
|
|
#
?
Jun 19, 2018 12:45
|
|
|
JazzmasterCurious posted:Yup. It's one thing to write it to get the practice, but there's (almost) always something done already that 20-1000 people have contributed input and fixes to already. it's thinking like that which ended up making me a contributor to the SJCL when I was doing my master's project.
|
|
#
?
Jun 19, 2018 13:54
|
|
|
Tei posted:I use to be anti-packages, but after many mistakes I have learn many things are better handled with packages. Dates are already mentioned. Escaping anything or satinifying anything. What do you mean by satinify, and what package would do that? There are literally 0 relevant Google hits. From context it sounds like a way to make html safe to include in other html. Edit: did you mean sanitize?
|
|
#
?
Jun 19, 2018 15:01
|
|
|
Code modularity and the idea of libraries that code modularity enabled, is among the greatest ideas to ever arise in computer languages. Use libraries.
|
|
#
?
Jun 19, 2018 15:56
|
|
|
Another pro for packages: How else are you going to be a github celebrity if you don't contribute bug fixes to all the broken packages you use?
|
|
#
?
Jun 19, 2018 16:15
|
|
|
Thermopyle posted:Code modularity and the idea of libraries that code modularity enabled, is among the greatest ideas to ever arise in computer languages. actually javascript is unique in how terrible libraries can be, and web developers are particularly terrible at assessing whether or not they are any good because they are (mostly) all fresh out of college, so just because you hear a library name at some meet-up or something, you really can't assume the library is any good at all. i'm not saying that you shouldn't use libraries, you just need to be smart about isolating them from your project. i've spend literally months debugging poo poo in the jquery library for instance - that's months i could've spent on solving problems with business value. Bruegels Fuckbooks fucked around with this message at 16:49 on Jun 19, 2018 |
|
#
?
Jun 19, 2018 16:46
|
|
|
Bruegels Fuckbooks posted:actually javascript is unique in how terrible libraries can be, and web developers are particularly terrible at assessing whether or not they are any good because they are (mostly) all fresh out of college, so just because you hear a library name at some meet-up or something, you really can't assume the library is any good at all. i'm not saying that you shouldn't use libraries, you just need to be smart about isolating them from your project. i've spend literally months debugging poo poo in the jquery library for instance - that's months i could've spent on solving problems with business value. Yeah, so instead of finding a good library, we should let all these terrible web develoeprs develop the functionality from scratch.
|
|
#
?
Jun 19, 2018 17:37
|
|
|
Thermopyle posted:Yeah, so instead of finding a good library, we should let all these terrible web develoeprs develop the functionality from scratch. it depends on the problem you're trying to solve. like, would i roll my own js crypto library or date library? gently caress no. but it can actually take longer and be a bigger cost to use a library than to just solve the problem yourself. it's not like you're standing on the shoulders of giants with this web development stuff, there's an incredible amount of bs.
|
|
#
?
Jun 19, 2018 19:17
|
|
|
Also know when to roll your own rather than hacking around a library that isn't doing what you want. I'm in the process of ditching gl-matrix in my own app because of how... *checks paper* not good it is.
|
|
#
?
Jun 19, 2018 19:42
|
|
|
Bruegels Fuckbooks posted:it depends on the problem you're trying to solve. like, would i roll my own js crypto library or date library? gently caress no. but it can actually take longer and be a bigger cost to use a library than to just solve the problem yourself. it's not like you're standing on the shoulders of giants with this web development stuff, there's an incredible amount of bs. Yeah, I don't think anyone would say its a good idea to just blindly mash in whatever library to solve whatever problem and drat the consequences. I'm pushing back against the idea raised earlier in the thread (and which I see with developers in all languages): "I try to avoid libraries".
|
|
#
?
Jun 19, 2018 19:45
|
|
|
Bruegels Fuckbooks posted:actually javascript is unique in how terrible libraries can be, and web developers are particularly terrible at assessing whether or not they are any good because they are (mostly) all fresh out of college, so just because you hear a library name at some meet-up or something, you really can't assume the library is any good at all. i'm not saying that you shouldn't use libraries, you just need to be smart about isolating them from your project. i've spend literally months debugging poo poo in the jquery library for instance - that's months i could've spent on solving problems with business value. What went wrong in jQuery?
|
|
#
?
Jun 19, 2018 21:47
|
|
|
Interested here too, jQuery's main problem is that HTML5 provides the same features although slightly prosaic in form, the libraries end up gigantic for all the crud they grew.
|
|
#
?
Jun 20, 2018 01:03
|
|
|
Doom Mathematic posted:What went wrong in jQuery? Let me talk about jquery event handling. So like, around the IE6/IE7 days, different browsers had different, incompatible properties in their event handlers. JQuery's approach to fixing this was to 'fix' the event using JQuery.event.fix(), which basically would try to make it so you could use event handlers in a cross-browser way without doing a bunch of bullshit. Unfortunately: a) JQuery.event.fix() is loving slow. It uses properties that can trigger browser reflows, and I've seen fix take upwards of 30~40% of cpu time in mousemove handlers just to normalize properties. b) JQuery.event.fix() is almost completely unnecessary if you don't care about IE8 and before. c) Rather than just be like 'gently caress this, screw JQuery.event.fix()', the JQuery took the approach of having 'an event handler cache.' What this means is that when you create an event handler in JQuery, it will create the function in the JQuery namespace itself, and have another function point at that function in the JQuery namespace. The consequences of this are: a) If you call removeElement on an element that has an event handler in vanilla js, the event handler goes away. If you call removeElement on an element in JQuery, the original function and whatever is bound to it lives in the JQuery event handler cache forever - if you bound this to the function scope, well, your stuff is never going to garbage collect. b) Moreover, JQuery fucks up all the memory profiling tools because this event handler cache bullshit makes it so instead of the leaked memory being in the namespace of the code that leaked, everything is leaked in the JQuery namespace instead. God help you if you use $.proxy, say goodbye to anything in that function ever releasing the memory again. c) The JQuery pros will recommend that you use features like 'event delegation' and bullshit to speed up your JQuery, not realizing that vanilla js event handlers are fast, idiot proof, and don't leak - you don't have to use event delegation in vanilla js because just attaching the event handler to every element that would trigger the event would perform better! Like, in 2006-2008 timeframe, I remember that people still used IE6 and IE7, so all this bullshit made sense. In 2018, all JQuery event handling does is make the setting 'break on every exception' super annoying because it throws exceptions in expected program flow. Similarly, sizzle (the jquery selector engine) is worse than just doing querySelectorAll in anything later than IE9. God I remember spending like three weeks balls deep in that library because of some bullshit involving iframe and unload event handlers. (I am actually a contributor to this library, but in my defense I was new when I had these problems.)
|
|
#
?
Jun 20, 2018 05:03
|
|
|
 oh man it must have been nice not having to care about IE<9 after 2008.Yeah, making a SPA with just jQ would be pretty tedious, but that's not really its wheelhouse. It's great at progressive enhancement, though of course that's out of vogue.
|
|
#
?
Jun 20, 2018 14:01
|
|
|
I just want to say I'm loving GraphQL and Apollo and you should check it out if you haven't. I've gotten rid of so much redux data fetching and normalization code. I might even get rid of redux completely in this project because I'm down to like one or two reducers and maybe 4 actions total. I say this as someone that worships at the altar of Abramov.
|
|
#
?
Jun 20, 2018 14:51
|
|
|
prom candy posted:I just want to say I'm loving GraphQL and Apollo and you should check it out if you haven't. I've gotten rid of so much redux data fetching and normalization code. I might even get rid of redux completely in this project because I'm down to like one or two reducers and maybe 4 actions total. I say this as someone that worships at the altar of Abramov. Abramov's First Commandment: "You might not need Redux"
|
|
#
?
Jun 20, 2018 15:54
|
|
|
Well I looked through the router code sample from angular.io and it seems like every component has its own routing module? I feel like my next step is stopping work on the project and quitting the company because clearly I'm a loving moron. I'm just trying to get a JSON object from a third party given a request with some optional parameters. These optional parameters are in the URL (e.g. ?q=what&n=60&p=2) The result would feed into a number of components. I first thought I would have each component do the request, but that resulted in multiple requests. So then I decided to have a parent component do the request and just pass the result to the child via @Input() The children, via user interaction (click) can add/edit the optional parameters. This action updates the URL, but the parameters in the URL are unfortunately not a 1:1 match to the parameters in the request. I did have it sort of working, but the initial load didn't read the URL parameters correctly ({{value | async}}, how helpful, can I have just the value without the async so I can transform it into a value to pass to the third party????). Also the back button didn't work, well it changed the URL, but not the content, probably because I wasn't using [routerLink] and/or [queryParams] on the aforementioned click actions. I hate how this thread is a constant reminder to me that I'll never be good enough, and the moment I get somewhat of a grasp on anything, it's immediately deprecated and all the knowledge gained is useless. Case in point, all the research showing params and queryParams which have been deprecated in favor of paramMap and queryParamMap respectively.
|
|
#
?
Jun 21, 2018 16:57
|
|
|
The Merkinman posted:Well I looked through the router code sample from angular.io and it seems like every component has its own routing module? It doesn’t sound like you are far off. Some questions: Do the child components each have their own params for making the call? Or if one changes, they all change? Why do you think multiple requests is bad? How large is the data being returned? How often is it being called? Think about something like a typeahead textbox tied to the backend. That’s going to be make multiple requests per second as a user types, depending on what the debounce time is set too. But the data set is small so it doesn’t matter. Basically, if your 3 child components are getting different data, put the call in a common service they can all inject and let each one call it as params change. If the returned data is large (and “large” here is dependent on your environment and your application), then rethink the problem a bit. Can you return the data in chunks instead of all at once? Can it be paged, etc. If they are all getting the same data then injecting the service into the parent and passing it down via @Input is probably the way to go, but that also assumes if on child updates, they all do. In that case, have the parent listen for an Event which the children Emit to update the data. As for you last paragraph- don’t get discouraged. Everyone here, no matter how many years of experience they have STILL has moments of “what the hell I can’t make anything work”. It comes with the job. There’s no ONE solution to any given problem. Just remember it’s code- it can always be refactored later if need be.
|
|
#
?
Jun 21, 2018 18:29
|
|
|
HaB posted:It doesn’t sound like you are far off. Some questions: HaB posted:Why do you think multiple requests is bad? How large is the data being returned? How often is it being called? HaB posted:If the returned data is large (and “large” here is dependent on your environment and your application), then rethink the problem a bit. Can you return the data in chunks instead of all at once? Can it be paged, etc. HaB posted:If they are all getting the same data then injecting the service into the parent and passing it down via @Input is probably the way to go, but that also assumes if on child updates, they all do. In that case, have the parent listen for an Event which the children Emit to update the data. parent.component.html code:code:code:HaB posted:As for you last paragraph- don’t get discouraged. Everyone here, no matter how many years of experience they have STILL has moments of “what the hell I can’t make anything work”. It comes with the job. There’s no ONE solution to any given problem. Just remember it’s code- it can always be refactored later if need be.
|
|
#
?
Jun 21, 2018 19:28
|
|
|
prom candy posted:I just want to say I'm loving GraphQL and Apollo and you should check it out if you haven't. I've gotten rid of so much redux data fetching and normalization code. I might even get rid of redux completely in this project because I'm down to like one or two reducers and maybe 4 actions total. I say this as someone that worships at the altar of Abramov. Big Same ™. We still see redux at work, but all my personal projects are in Apollo graphql. The one and only downside to apollo+graphql is that both are still in their infancy. I've had to fix two bugs in Apollo client so far, while I don't think I ever had to fix one in redux. Both of those bugs were not just fixed in later versions, but massively improved, so both really were examples of just immature code.
|
|
#
?
Jun 22, 2018 01:31
|
|
|
One reason redux is pretty bug free is its very simple. The innovation of redux is 85% a way of thinking and structuring your project and 15% the actual library.
|
|
#
?
Jun 22, 2018 03:18
|
|
|
Thermopyle posted:The innovation of redux is 85% a way of thinking and structuring your project and 15% the actual library.
|
|
#
?
Jun 22, 2018 03:37
|
|
|
Vincent Valentine posted:Big Same ™. We still see redux at work, but all my personal projects are in Apollo graphql. Agreed yeah, one of the biggest open and unsolved issues right now is basically "what's the best way to handle mutations that delete something?" What were the bugs that you fixed?
|
|
#
?
Jun 22, 2018 04:53
|
|
|
prom candy posted:Agreed yeah, one of the biggest open and unsolved issues right now is basically "what's the best way to handle mutations that delete something?" What were the bugs that you fixed? At one point earlier in its existence(much before apollo2.0), you could set how it would retrieve data. For example you could set it to "cache-only" to only fetch from the cache and ignore the network. Similarly, you could do "network-only" to always get the most fresh data, which had the side effect of not having optimistic updating. I was trying to come up with a system for using client-side state by seeding the cache with some default values, then only call the cache and ignore the network(since there'd be nothing in the network). Instead, it just didn't work at all. I spent awhile toying with things, trying to come up with a solution and then finally decided to dig through the framework code and see what was up. Basically what was there was just early-draft test code that I honestly think was never intended to get released, but iirc it was never actually fixed until 2.0. Hilariously one of the code blocks was, almost verbatim: code:The second bug wasn't really a bug so much as a design flaw, if you cache got to be enormous(we're talking 3000+ entries), it would get extremely slow. The fetching algorithm was just too inefficient for caches of that size, and I had a cache that was around 6,000 entries. I cleaned it up a bit and it was faster, but tbqh it still wasn't good enough. Like I said before though, both of these were not just resolved later in its existence, they were massively improved. They added an entire system to support client side state which is thoroughly great, and giant caches are significantly better handled. I haven't had any issues since 2.0, but every once in awhile I wonder if a problem I'm having is actually my fault.
|
|
#
?
Jun 22, 2018 23:55
|
|
|
I'm trying to do proper TDD for this new Typescript/React project of mine, using Enzyme/Jest, and I'm having issues setting up the first tests. Specifically I'm getting a lot of "Module raf/polyfill in the setupFiles option was not found" errors. If I just remove the "setupFiles" option from the config, it fails on "Module enzyme-to-json in the snapshotSerializers option was not found". I've confirmed that those modules exist in node_modules, and I'm beginning to think it's just a problem with Jest failing to resolve anything, but I'm not sure how to fix it.
|
|
#
?
Jun 24, 2018 00:26
|
|
|
|
| # ? May 18, 2024 13:51 |
|
|
I've been fiddling with MEAN, I do Angular 2 professionally but I wanted to extend that into the MEAN stack, and over the last couple of weeks I've really hammered down the creation of a pretty rudimentary MEAN application using Express & CosmosDB, Microsoft's forked MongoDB. So far it's pretty cool tbh. I'd also like to say that VSTS/Azure deployment is really loving nice and having it connect with Github to just do a build every time you do a commit it really nice. Also, using MongoDB requires this youtube to be posted: https://www.youtube.com/watch?v=b2F-DItXtZs
|
|
#
?
Jun 25, 2018 20:22
|
|
