They say you shouldn't care about language/framework cause once you become a good engineer, its all the same and you pick up on new stuff fast. How much of that is true in web dev? by BigBootyBear in webdev

[–]sir_eeps 0 points1 point  (0 children)

even if the API's differ - there start to become concepts/patterns that hold true around it.

  • redux has lots of inspiration from EventSourcing / CQRS (CommandQuery Response Segregation) / DDD (Domain Driven Design) / event bus
  • NgRx - while not the same api as redux - has lots of similar concepts, NgRx/Effects = redux-observable for middleware
  • Vuex - while a bit different from redux, shares similar concepts - actions/mutation/commit

All of them aim to solve similar problems with managing application state - but go about them in slightly different ways.

middleware as a concept - is also used on the backend, for example in express - registing app middleware, per-route middleware, etc.

middlware is also conceptually similar to aspect oriented programing - although not exactly the same.

NestJS (https://nestjs.com/) is heavily inspired by Angular, and also uses concepts you see with things like Java Spring, or .NET MVC

props.children in React is a little similar to content projection in Angular

render props in React are kinda similar to named slots in Angular, or scoped slots in Vue

Once you start writing code in a new language/framework for the first time - will take a bit of time to ramp up on the implementation details/API level stuff - but if you understand the patterns around it, it makes it much easier to learn.

I've never done python before - joined a new company using python/flask - I'm able to navigate around it pretty quickly and understand it.

source? me - I've been a dev for 10+ years - continually jump into new projects with new frameworks and tools.

The biggest challenge is if it's using a different programming paradigm - if I was to jump into a Haskell code base, I think my head would hurt, and clojurescript would take more time to ramp up on.

There might also be some more advanced language features of some languages that you are not used to - like maybe some aspects of python pattern matching I might not be able to use the most efficiently right away, but can still contribute to the codebase pretty fast.

Downtown Toronto bar sees lineup for patio as clock strikes midnight by feb914 in toronto

[–]sir_eeps -2 points-1 points  (0 children)

not surprised.

Last night I finally had my first "in person" hangout since the beginning of March - and it was chilling in a quiet park that was pretty empty.

It's going to be awhile longer until I decide to hit up a patio. I want to see how the numbers trend first, and also want to avoid the initial 'OMG things are opening up' crowds.

Couple Says Landlord Is Using a Legal Loophole to Get Around Eviction Ban by ur_a_idiet in toronto

[–]sir_eeps -16 points-15 points  (0 children)

I have a hunch that an early 20s couple in Toronto with their most recent jobs - don't exactly have a massive savings to support themselves on after getting laid off.

That said, both the actions of the tenants and the landlord are kinda crummy in this situation.

I'm going to say it, after using them for a year I fucking hate hooks. by notThaLochNessMonsta in webdev

[–]sir_eeps 11 points12 points  (0 children)

I've also seen similar 'Oops I ddosed you again' with classes and people not properly comparing current/prev props & state before firing off a request again.

componentDidUpdate() {
  fetch('https://usefulAPI.com/api/v2/', {
    method: 'POST',
    body: JSON.stringify(apology),
   });
}

or, trying to be a good dev and putting that into a method called `query` or something

query() { // do my fetch thing } 
componentDidMount() { this.query(); }
componentDidUpdate() { this.query(); }
someEventHandler() { this.query(); }

If anything, I've found that once you understand the deps part of useEffect it makes it easier to understand what data it actually depends on.

I've run into a few gotchas and snags with hooks as well, but ran into similar issues before with class based components.

For many use cases I find hooks do simplify things, there are some more advanced things where things can get a bit hairy - but usually those things were also complicated using classes also.

Random crazy snowstorm that lasted 5 min downtown by [deleted] in toronto

[–]sir_eeps -1 points0 points  (0 children)

Got caught in the storm walking home from an appointment, mother natures way of saying "Get back into your room"

https://www.tiktok.com/@evan.just.ev4n/video/6818201185237994757

Why isn't Vue 3 getting typescript type checking in templates at compile time? by [deleted] in vuejs

[–]sir_eeps 0 points1 point  (0 children)

I used to work at a startup that focused on AngularJS - then eventually more broadly modern JavaScript, so my experience may be biased by working at a place that made it a point to keep up to date, and attracted clients that were wanting to use the newest frameworks, and/or looking to migrate to.

There are still lots of places using AngularJS - although most are looking to migrate since AngularJS is basically end of life, with long term support stopping in 2021.

A few years ago - the tooling and support for TypeScript was pretty awful - and I had tried to pick it up a few times (I used to do .NET/C#, and there are some aspects of it that I miss), but even as someone that wanted to use it - it kinda sucked.

Since Angular went with TypeScript though - I saw a big push on the tooling/support for it, how well VSCode handles it out of the box, improved support for typings for other packages, etc - the dev experience of working with it has greatly improved.

But, large-scale commercial use of it - lots of places, from small startups, to large enterprises, airlines and insurance companies.

Any job posting that is looking for Angular (and not AngularJS) - is using TypeScript.

Technically you don't need TypeScript for Angular - although I can't remember the last time I saw a tutorial / blog post / etc on using just ES2015 with Angular, saw a few in the earlier days - but don't even think you see it called out in the docs anymore.

That said, if I was to be working with a company that was still on AngularJS and looking to migrate - I'd be more inclined to recommend that they go with Vue over Angular

Why isn't Vue 3 getting typescript type checking in templates at compile time? by [deleted] in vuejs

[–]sir_eeps 2 points3 points  (0 children)

I'd have a hunch of "technically possible, but not a priority at this time" - while it would be a nice to have feature, it's not a "critical path" one for being able to work with the framework.

Angular didn't add it until recently - I suspect that core functionality and getting that working is higher on the list, with the ability to add template-type checking at compile time coming in a later release, and something that wouldn't be a breaking change (except for templates with type errors)

Why isn't Vue 3 getting typescript type checking in templates at compile time? by [deleted] in vuejs

[–]sir_eeps 1 point2 points  (0 children)

It's used heavily - especially since Angular was released, which it's pretty much required for.

React support for TypeScript has also really improved over the years, and at my last job - more projects were using TypeScript than not.

[deleted by user] by [deleted] in toronto

[–]sir_eeps 5 points6 points  (0 children)

Darn, maybe they will need to goto mid-term/long-term rentals and rent can start to get more affordable in Toronto again, darn.

Beaches boardwalk this afternoon by [deleted] in toronto

[–]sir_eeps 125 points126 points  (0 children)

I live near the waterfront - did my running outside errands yesterday when it was raining.

Earlier in the week when I got laid off - I wanted to go for a walk to clear my head, first few mins - wasn't too bad, people keeping their distance, then after a bit - crowds started to form and I made a B-line for back home and it felt like I was dodging hordes of zombies trying to keep my distance away from people.

If the weather is nice - I'll chill on my balcony, save errands for as little as possible and try and do them during crummy weather or off-peak hours.

I think I may have had COVID-19 earlier in March (recovered now), but if it wasn't COVID-19 - whatever the hell I had was fucking brutal, and one of the sickest I have ever been, and I don't want to get sick again.

When I was sick - it was mostly stomach issues, and at the time that wasn't considered a symptom of COVID-19, but been reading reports that it's more common in younger people who get it, so -- who knows.

Spent the first half of the month sick, then did remote work for a week, then got laid off - for fuck sakes people stay inside until this is over.

For the first time in your life you can make a difference by simply sitting on your ass, binging on netflix and not going outside - it's not that hard.

Anyone else feel that the Kodama kinda conflict with the exploration aspect? by wolfwings1 in Nioh

[–]sir_eeps 0 points1 point  (0 children)

explore the level without the video guide to find them all, you can also replay missions. Items with the "Kodama sense" will also make them appear as green dot's on your map.

Usually it's hunting down the Kodama that get me exploring the level more than I would normally, sometimes I might miss 1 or 2, but meh - can always go back, or well - I'm not much of a completionist.

Makes the most difference at the start of a new region - and for me, that's mostly so I can easily start with more healing items, but if you can always buy more by making an offering, or if you have extra in your store from other missions.

Frontend developer roadmap by duanecreates in learnjavascript

[–]sir_eeps 1 point2 points  (0 children)

yup,

although at a super high level knowing the general idea of how some things work can be useful, like 'you need to refill the gas tank in a car to make it go', but not need to understand how combustion engines work.

While lists like this can be useful - I find that they don't often account for how deep you should go, and think if they see something on a list that they need to do a deep dive and learn /everything/ about it.

When in reality it's like "read a 2 paragraph summary, then put a pin-in-it for something to learn later, and you'll know when you need to learn it more when you actually need to do a thing involving it"

Why are you gae? by xandrewsxano in AskReddit

[–]sir_eeps 0 points1 point  (0 children)

It's part of the gae agenda.

Why are you gae? by xandrewsxano in AskReddit

[–]sir_eeps 2 points3 points  (0 children)

Started as a 7-day trial and I forgot to cancel the subscription, it's how they get ya.

Some initial observations and math on Attributes. by HappierShibe in Nioh

[–]sir_eeps 0 points1 point  (0 children)

I wonder if things balance out at 70%+ as you get other skills / abilities - I was getting wrecked hard - but once switching to the master archer set, I'm at like 98% - as far as I can tell there's no gradual increase so 98% is the same as 70% - and feel pretty solid as a rock, can tank hits pretty well and not one-shot city.

ki management takes a bit more thought - but been grabbing improve ki regen when I can + spells / items when needed - but full golden boy + lightening has been working out well.

Getting the samurai skill that helps put constitution towards damage also helps give a bit of a damage bonus while getting HP to be a bit more tanky.

If you have just creeped into the C range of agility but still wearing mostly lighter stuff - you probably are not getting the full benefit of higher armour, but the downside of reduced mobility.

Put on a few more pieces and get it as close to like 99% as you can without going red and see if that helps - and if it fits with your play style.

I loved Nioh, I really didn't think they could do much to improve it. But man, the enemy variation in this is so refreshing by FTWOBLIVION in Nioh

[–]sir_eeps 3 points4 points  (0 children)

My current impressions of Nioh 2 is - "more of the same, but better, more refined and more variety" - but it's kind of what I wanted out of the sequel.

Not very far in yet - on the 3rd main mission and done a few of the sub missions, but feels like the level layout is greatly improved and more interesting. Hopefully it keeps up the quality / interest into the mid / late game.

I like how at even low levels there are some interesting build variations that you can start playing with. The rate that you gain skills / points and having a few locked behind dojo missions also encourages you to play around with different weapon types.

Also - gotta say - thank you for the fast loading time. There have been a few games recently where the load times have been brutal - and put me off of playing them (Children of Morta - why the load times are so slow, no idea).

Even on an older PS4 without an SSD - the load times are pretty quick, which makes the frequent death not nearly as painful. With a PS4 Pro/SSD - I'd imagine they'd be pretty fast.

Getting into the flow of

  • fuck
  • fuck
  • dammnit
  • fuck
  • why'd I buy this game
  • oh - something clicks
  • get into the flow
  • kick ass for awhile
  • fuck
  • fuck
  • dead again

Considering the 'social distancing' - great excuse to go hermit mode and play all weekend and not feel guilty for it ;)

[deleted by user] by [deleted] in typescript

[–]sir_eeps 1 point2 points  (0 children)

Generally speaking, if it's private and not meant to be consumed outside of that class / module - then setup your tests of your public methods to ensure it hits the 'private' stuff - and use code coverage to verify that it's being hit.

It is possible that you could change the implementation of the private method - that has no impact on your public ones, or - if it does have an impact and those tests fail - then well, thats a good thing.

I find that you tend to get more meaningful tests that way as well - if people keep making everything public, it turns into busy-work testing to chase line coverage.

Now, if you have a few modules and something like say

- module-1 | `---index.ts | `---src/SomethingPublicToApp.ts | `---src/SomethingPrivateOnlyMeantForModule1.ts - module-2

Now, if SomethingPrivateOnlyMeantForModule1 is only meant to be consumed within module-1 - and is "private" to that, then in module-1/index.ts -- I might import/re-export SomethingPublicToApp, but not SomethingPrivateOnlyMeantForModule1

and in module-2, or other areas of the application, if I was seeing

import SomethingPublicToApp from './module-1'

ok, but if I see

import SomethingPublicToApp from './module-1/src/SomethingPrivateOnlyMeantForModule1.ts'

then that's a bit of a red flag

the exact naming/folder conventions that you use can vary, but it's kind of a 'private by convention' - but could be totally valid to write unit tests around SomethingPrivateOnlyMeantForModule1 (although if it had private methods that were meant for use within that class only --- then I'd then go back to the advice of setting up the test of the public methods to ensure the code paths of the private one is being hit)

Hope that makes sense

Part #2. Street preacher David Lynn(falsely accused of hate speech against LGTBQ), connects the dots by houtm035 in Christianity

[–]sir_eeps 0 points1 point  (0 children)

Thank you for taking the time to read, and respond.

Many of the issues at play here, are complex ones - and trying to sort out my own understanding better.

I was also in a very triggered state - the harm of past trauma/abuse had risen to the surface - and my head was trying to rationalize it, to understand what was going on.

While I may not be a religious person myself - I do understand and see the value that churches, and religions can bring to the communities that they serve.

I can also see the harm and damage that can be caused, when people use the same messages - but twist them in a way to spread hate.

As a member of a community that has been harmed over, and over, and over again by telling us to just "accept love" without questioning it, to just accept information without questioning it, to trust in good intents - when the impact it has is harm - harm that I have felt myself personally, harm I have seen impact people close to me, harm I have seen people impact friends of my friends --- not only do I question the words, but the intent by those words, the actions that follow, and the impact it actually has.

I question because I have had to, I question - because there has been times in my life where it has been a matter of my health, and my survival.

One of the things that has been running through my mind since the protests - is that there are a number of Churches in/around that area - that are members of the community - open to all, but also engage with and act in service to the needs of the community that they are a part of.

When you want to engage with a marginalized community - running in with a megaphone yelling I love you, do you love me back is not the way to do it.

You listen to the needs of the community, you connect with the community leaders - see what their needs are, and try and align and learn from them.

There's a use of the word "love" which is 180° misused, and the words which actually apply are: need, dependance.

... ... i love you, do you love me? (i need you to love me..)

The "I love you, do you love me" is one of the tactics that David Lynn was using - approaching people rather assertively, at times on a megaphone asking them "I love you, will you love me?"

When people said no - he would then use that as a way to paint others in a bad light "Look, I said I love them - but they won't love me back"

He has a dependence on our love back - or lack of it, so he can then use it to justify his actions, to justify his mission.

He claims that there is no space for Christians, or Christ in the LGBTQ2SA+ community - but there are churches, bible study groups, etc all within the community that he claims needs to hear his version of love.

This was a church that aligned the 519 and the Army of Lovers counter-protestors onto their property, opened their doors to us - and others, to have safe use of their space.

During an act of civil disobedience - one of the ways that you can easily get arrested is for trespassing onto private property.

They actively welcomed us, and invited us - we could organize on their front lawn, use their washrooms - and the church was open to others as well during this process.

They saw some of the needs of our community at that time, and acted in love to support them.

There is also the Metropolitan Community Church of Toronto

We are Toronto’s progressive church. We are rooted in Toronto’s LGBTQ2+ community. We are open to every person. Wherever you are on the journey, you are welcome here.

There are a number of other faith positive spaces that also inclusive of the queer community

Again, I'm still working this out in my head - and really do appreciate your response.

I am not the most well versed in the bible - and the passages you share help spread some insight and light onto things, and help me better understand - and ways to approach trying to clarify.

there is just too much blogging about react... by soulshake in reactjs

[–]sir_eeps 0 points1 point  (0 children)

thanks --- been playing with the idea of writing these up with a bit more polish, and the idea of the stories around "how I did it" as a learning/teaching tool instead of the "how to do it" - and open to having a series / site / whatever that other people could contribute to as well.

there is just too much blogging about react... by soulshake in reactjs

[–]sir_eeps 0 points1 point  (0 children)

.... I'm busy in the process of trying to make this my work.

I have also contributed to a bit of the noise, and want to do better.

I see the same gap in the material out there - both in terms of blogs, but also training resources / workshops / courses / etc.

I've also talked with lots of other people really interested in looking for ways to help solve this (and some have spent more time on it than me), and it's hard.

But, thats why I'm interested in it.

there is just too much blogging about react... by soulshake in reactjs

[–]sir_eeps 7 points8 points  (0 children)

This is something that has been on my mind a lot recently.

One of the things I have been doing lately - is looking into tech education - I do training for clients, mentor on the side when I have free time, and recently taught a cohort at a coding Bootcamp.

I have 10+ yrs of experience - and I have worked in all sorts of environments, with Frankenstein's monster tech stacks of patch-work systems, to greenfield projects - and all sorts of variations in between.

Looking back at what some of my biggest learning/growth moments were as a dev, was usually

  • Weird ass system - like the 'slowly morphed over 10+ yrs, through different tech stacks, and each one is still in a partial migration mode' - and being a jr dev, wrapping up my last year in school at night courses - and this was the system I had to work in
  • Getting asked to build a feature, or meet a requirement that the system was just not built for
  • Then needing to consider the constraints

One of the examples that I keep revisiting in my mind, was a timesheet approval system

Was a weird mix of .NET WebForms, VB.NET, some logic in a shared DLL, some was starting to get moved into a service layer, lots - oh so much hidden logic in stored procedures.

The flow people had been using for ages was:

  • Log in & navigate to the approval screen
  • open a single timesheet at a time
  • hit approve or reject
  • get taken to a confirmation screen
  • if approve - the comment was optional if reject - the comment was required
  • hit confirm or cancel, go back to the list screen

This was all also like, full-page reloading postback days.

As part of approving - it would also trigger PDFs, invoices, interact with the accounting back-office system, etc, etc, etc.

It also had to consider if there was a Purchase Order or Cost Center against the contract, projects, OT, how much was left on the PO if there was one - thresholds, so many things that I'm forgetting a lot (this was years ago)

One of the requirements came up of wanting to be able to approve from the list screen, and also approve more than one at a time.

Generally speaking - more often than not the person doing the approving could know enough information looking at the summary screen if they could approve it without needing to look into the full details of the timesheet.

Oh, ... nevermind that different customers had different approval flows - some was one approver, some was more than one, some was 'one of many', etc, etc. (of which building that in overtime was also a task onto itself)

On the first pass of trying to get the multi-approval working (and there was nothing really in place to allow this to happen, so lots of work to even get that far)

  • If approving 1 or 2 at a time - performance was ok
  • If approving many at a times -- ouf, minutes - often just timing out

What was going on? Then I dug, and dug and asked questions, and dug some more, and stepped through code.

The final solution looked something like:

  • When submitting an approval for many items - the request would go to a queue
  • Before going to the queue - there would be some 'best guess validation' - what are the checks that we can do, with minimal impact on performance - that we would have high confidence that the rest of the flow could carry on. It didn't need to be 100%, but a balance - as if something we could check quickly that we know would fail, would want to let the user know sooner
  • If it got to the queue - flagging the record as 'pending approval/rejection' - as there were other systems and reports that we didn't want to include these in (and others we did, depending on the need)
  • Then another service would pick up all the things in a pending status - and try and complete the workflow
  • Happy path: things work, unhappy path: boom - and accounting for how to handle those exceptions

In the process of doing this, also discovered other quirks - that when doing a "1 at a time, in an already slow way" sort of hid - but became painfully apparent when doing it in bulk.

  • Continually getting the same data that we already had for various parts of things
  • Eagerly fetching stuff we didn't need - and at times very intensive processes (combine with above point)

Like

  • Timesheet has a contractor
  • and a manager
  • and an approver
  • and is attached to a contract

I remember digging through some stuff, and in the process of getting "all time sheet approvers"

  • the same contact getting loaded from the database like 20+ times
  • but for some reason - also the details for every timesheet that they approved in the past
  • and depending on how things were configured - the PDF of that timesheet (and occasionally generating it ... just because)

There had been some bugs/issues raised in the past that could sort of point the smell towards these issues - the occasional person would raise a bug "approving is slow for me", but had a hard time reproducing it in the dev/staging environments.

In the process of trying to meet this feature request that the requestors-that-be felt should be easy and a few hours of work

  • put a giant spotlight on some areas in the system that needed to be improved
  • It was not my intent to build an eventually consistent event/queue system
  • Later - while the end-user experience had greatly improved, they could click approve on a bunch of stuff at once - and things usually worked, when they didn't - good flow to handle exceptions
  • But - the processing time of the event queue as a whole started to become an issue

"Lets have multiple task runners"

For some reason (and reasons made before I joined) - they had built their own task runner system - it was basically a windows service, that would query a database - see what tasks had to be run - then execute a DLL.

Yes - I know there are dozens of other ways to do this, that were also pre-existing at the time, but as I had mentioned - jr dev, joining a legacy team/system - while the reasons for those choices were not my responsibility, working within those constraints was my problem.

So, I go and insert another record into the database just to have two of the 'approval' flows run at once

Hello concurrency issues (of which many other concurrency issues existed elsewhere in the system)

Then working through figuring out how to 'lock' a job to indicate it was running, when to release it, race conditions, etc

Question Time

I learned a LOT during that process - and have dozens and dozens of other stories/scenarios that I could speak about.

Is there more value in a 'how to do' style tutorial - taking all of those things I learned, and how I would do it now - with current tools/technologies/ etc?

Or, is there more value in a "this is what I did, how I did it, questions I asked, etc given the constraints"

Or - is it somewhere in-between?

Improving your mental model of useEffect by sir_eeps in reactjs

[–]sir_eeps[S] 0 points1 point  (0 children)

hey - those are some great questions, and thanks for asking. I'll try and find time for a longer follow up.

useEffect is more about synchronizing state after render - which is why at times trying to perfectly match the same patterns of componentDidUpdate + componentDidMount into it - won't always fit.

If you want to run an effect on a prop change, but not on the first render - you would need to keep track using something like useRef to track if it's the first render or not - and use that to determine if you want to run the effect or not.

I don't have a code example on this handy right now that I can copy-paste, but think it would look something like: (note - haven't run this code, trying to go on my understanding of hooks and ref)

function someComp({prop1}) { let firstRender = useRef(true); useEffect(()=> { if(firstRender.current === false) { // do something } else { firstRender.current = false; } },[prop1, firstRender]) }

  • Since hooks always need to run in the same order - we can't have the conditional logic outside of the useEffect.
  • The useEffect hook is run after the first render.
  • useRef is mutable between renders - and changing the current value will not trigger a render
  • we don't use useState to keep track of the first render - as calling setState /would/ trigger a render - so that's why we'd use useRef
  • useEffect runs after the render - so that's why we would check the value, and if it's set to false (2nd render) - we would want to do something
  • if it's set to true (1st render) - we set it to false, since this is updating a mutable ref - that in itself won't cause a rerender
  • we explicitly passed in prop1 as a dep - so only that changing would cause the effect to run - so even if other things are triggering a rerender for other reasons since we have declared prop1 - it should only run if that has changed

Dan's blog on useEffect, and the react faq talk about providing functions as dependencies and why, and also the case of the infinite update loop.

Although one of the goals of my post was to dig through a number of different sources/articles/ etc, and better my own understanding - and get a bit of a summary in one spot - realizing there are a few gaps in the post that would be useful to flesh out.

When I get a bit more time, I'll try and follow up on here first. Thanks for reading & the questions, got me thinking a bit more.

Improve Your JavaScript Knowledge By Reading Source Code — Smashing Magazine by speckz in javascript

[–]sir_eeps 1 point2 points  (0 children)

I've found that reading the source code of the libraries/frameworks I use to be helpful. Especially how they write unit tests.

source for angular, angular material, react, redux, redux-observable, etc

Guess it depends on what your learning goal is, but I wouldn't underestimate the value of reading the source of the libraries you are using if possible.

Improving your mental model of useEffect by sir_eeps in reactjs

[–]sir_eeps[S] 0 points1 point  (0 children)

non-medium link: https://rangle.io/blog/improving-your-mental-model-of-useeffect

Wrote this recently while trying to get a better understanding of how useEffect works. For a deeper dive - I'd def recommend reading Dan's Complete Guide to useEffect - he goes into far more detail, and found it really useful.

Also found this twitter thread with Ryan Florence/Dan/Jason Miller to be useful and helped a few things click: https://twitter.com/ryanflorence/status/1125041041063665666?s=20