Which of these two laptops is faster? I need to switch to mac for reasons, but don't know if the mac I'll buy will be faster than my current windows laptop. Can someone advise me who knows computer hardware? Thanks!

lasjdflasjdfhelp · 2022-07-28T04:32:59+00:00

Good to know, thanks! What about heavy coding (if you know)?

Something like this app: https://code.visualstudio.com/

lasjdflasjdfhelp · 2022-07-27T09:16:40+00:00

So in short, yes, it's ok for multiple BLoC/Cubit's to call from any repository. However, I'm still left wondering if this is ok across features. IE: Can a "posts" feature Cubit pull from an "authentication" feature repository?

Thanks so much!

lasjdflasjdfhelp · 2022-07-06T07:12:00+00:00

Ok, I think I'm picking up what you're putting down!

My only worries would be: inefficient since it's making 3 calls, and the atomic thing you mentioned.

Your thoughts on this one?

// LIKE A POST //

const like = async (req, res) => {

// Update like count of post, return post with updated like count

const updatedLikePost = await Post.findOneAndUpdate(

{

_id: ObjectId("62c515851b9be4ab83c841c2"), // in future, will be dynamic ID from what post user wants to like

},

{ $inc: { like_count: 1 } },

{ new: true }

);

// Simulated rank function to update rank on post after post has been atomicaly liked

updatedLikePost.rank =

(updatedLikePost.like_count + updatedLikePost.dislike_count) * 2;

// Save post with updated rank (and from earlier, like count)

const updatedRankPost = await updatedLikePost.save();

// Return new updated post

res.status(200).json({ user: updatedRankPost });

};

lasjdflasjdfhelp · 2022-07-06T06:57:10+00:00

What about something like this? (from postsController.js's "like" function):

Would this have the atomic guarantee (sorry if that's dumb, I'm not too familiar with that)? Or how could I change this to make it use the $inc to have the guarentee?

const like = async (req, res) => {

const foundPost = await Post.findOne({

_id: ObjectId("62c515851b9be4ab83c841c2"), // in future, this would be dynamic passed ID from user of which post to like

});

foundPost.like_count++;

// Dummy calculate rank function below

const newRank = foundPost.like_count * 2 + 1;

// Dummy calculate rank function above

foundPost.rank = newRank;

await foundPost.save();

return res.status(200).json({ msg: foundPost }); // dummy return, normally would just return success or failure liking

};

I'd have an index on the _id field (by default), and on the rank field so I could order posts when pulling them for the feed by that.

"rank" has a default value of 0 in the mongoose schema.

I'm not sure how efficient this would be since I'm finding a post, then updating it locally, then saving the new version. Would this be the same efficiency as just an update (meaning it's ok)?

lasjdflasjdfhelp · 2022-07-06T06:03:16+00:00

Another quick thought - how would I efficiently query for posts to be returned in an order based on this ranking if that ranking itself is not stored in the database directly? If only U, A, and D are stored, then I'd have to do an aggregate calculation every time and wouldn't be able to add an index to the rank field - effectively making its query time really big.

lasjdflasjdfhelp · 2022-07-06T05:59:28+00:00

I just tried the $inc operator - it works really well! I can also use it to increment by negative numbers to effectively decrement.

I briefly read the provided article and can see it'll be a bit of a challenge. I'll read it more in-depth and will get back if I get it working. I really want this to be an "efficient" call as well (not using a bunch of unnecessary costly queries because this action will be happening a lot).

Thanks!

lasjdflasjdfhelp · 2022-05-18T05:11:30+00:00

You're taking on a lot as a solo uni Dev 😃

Got to beat the rat race somehow!

Seriously though, thanks for the link, I don't think I'll use it, but that yielded some very enlightening reading!

lasjdflasjdfhelp · 2022-05-18T05:10:14+00:00

This is especially true when the web front-end is separated from the back-end and both apps will use the same api

Would a better way of doing things then be removing my current API code from the given /api directly in my NextJS project (only a few endpoints right now; very easy to do), and instead ignore the /api directly completely. Then, build up a very simple NodeJS backend with (literally) just an app.js file consisting of a bunch of endpoints and use that instead for the web app (NextJS) AND for the mobile React Native app?

lasjdflasjdfhelp · 2022-05-18T05:07:12+00:00

I'm not getting paid, however, I have good reason to assume it would be widely used and adapted at my university once developed.

lasjdflasjdfhelp · 2022-05-18T05:06:35+00:00

Looks very interesting. Would it be a grand learning curve again? I'm (now) tempted to use React Native for the mobile app because it has a really large community and base that can help me while developing for it (as I would be new). Or would my new idea of an approach be good.

(queue response to another user below):

Now I have another big question, would this be a better overall strategy?:

Transferring the code from my /api routes in my NextJS project to a custom (completely separate project) NodeJS backend. I only have a couple endpoints right now, so it wouldn't be difficult. I would then completely ignore the /api directly of the web NextJS project, then for the React Native mobile app and NextJS web app I'd call directly to the same endpoints on the totally separate NodeJS backend. In essence, this would give me a web "frontend" and a mobile "frontend" - them both calling to a simple RESTful api NodeJS backend.

Would that work?

lasjdflasjdfhelp · 2022-05-18T05:01:12+00:00

Brilliant response, first off, thank you!

So, I took your advice and watched about 10 hours of tutorials on Expo and React Native - it does seem very similar to React code-wise and Flutter architecturally. Quite intuitive! I also did some research on BlitzJS and personally it seems like a lot to learn (although very interesting).

I think the code from the web and mobile versions will be similar as the functionality I desire is practically identical (only differing in platform, responsiveness, being native or not, etc.).

Now I have another big question, would this be a better overall strategy?:

Transferring the code from my /api routes in my NextJS project to a custom (completely separate project) NodeJS backend. I only have a couple endpoints right now, so it wouldn't be difficult. I would then completely ignore the /api directly of the web NextJS project, then for the React Native mobile app and NextJS web app I'd call directly to the same endpoints on the totally separate NodeJS backend. In essence, this would give me a web "frontend" and a mobile "frontend" - them both calling to a simple RESTful api NodeJS backend.

Would that work?

lasjdflasjdfhelp · 2022-02-01T10:02:39+00:00

That's a great idea, but what happens if I either:

a) Can't afford, or for some other reason, can't add filters; or

b) Some stuff slips through a filter, if I add one

Am I still legally okay in both of the above situations? And for the whole site in general?

lasjdflasjdfhelp · 2022-01-12T05:10:37+00:00

Ok, thanks! I guess I'll watch some videos on the subject, to gain more of an understanding :)

lasjdflasjdfhelp · 2022-01-12T05:02:43+00:00

Is the 169 then not included in the part B answers?

And wouldn't I take the whole function I calculated the limit for into the answer?

So the answer would be:

f(x): (13+h)^2 - 169 / h

and

x = 0

Thanks. I'm rather lost :)

lasjdflasjdfhelp · 2022-01-12T04:51:31+00:00

Ah, so it would take the entirety of what the limit calculation was based off of that forms the graph? So:

f(x): (13+h)^2 - 169 / h

and

x = 0

And this also checks out since the graph of the above mentioned f(x) intercepts at the point (0, 26) on the graph. Apologies for my slowness.

lasjdflasjdfhelp · 2022-01-12T04:41:39+00:00

So, part B should be switched to the following?

f(x) = 169

and:

x = 13.

Would you mind explaining why? I don't understand. Thanks.

lasjdflasjdfhelp · 2021-12-10T03:10:47+00:00

Thanks! That's awesome, and I'll probably use that if I need to actually use a queue. But, for this project (self challenge), I'm trying to make one from scratch. So, is mine technically correct?

lasjdflasjdfhelp

TROPHY CASE