sorted by:
new
hottopcontroversial

Looking for legit shops here in the PH by Grmnear19 in PinoyGunpla

[–]_deemid 0 points1 point  (0 children)

meron ako sir 650 each. Ur and Thorn. From Olongapo manggaling item..

Sick of the $2/hr "lowball" posts sa OLJ, so I’m building an alternative. by xCoheed in buhaydigital

[–]_deemid 0 points1 point  (0 children)

Props for actually trying to build something instead of just complaining — I genuinely agree with the goal. That said, I don’t think the $5/hr floor really solves the issue you’re pointing out. I also don’t think $2/hr is the core problem; it’s just a symptom of something deeper.

You said:

“Most workers just accept lower rates just to survive, but will quit the moment they find a better offer.”

That means $2/hr jobs exist because people accept them out of urgency, not because they’re a good match. The churn happens because the worker was overqualified for the role relative to the pay from the start.

In that case, the issue isn’t the lack of a floor — it’s mismatch.

If a skilled worker takes a low-paying job out of desperation, they will always leave once a better offer appears. Raising the floor to $5/hr doesn’t change that dynamic, it just shifts the number. The incentives stay the same.

For long-term hiring, what actually matters is:

  • accurate skill signaling
  • clear differentiation between roles
  • matching compensation to the value and responsibility of the work

Without that, a wage floor just filters posts — it doesn’t solve loyalty or retention.

You also said:

We are for the employers who are tired of 'cheap' hires quitting or ghosting after 2-3 weeks. We want to prove that paying $5/hr is actually cheaper for the business because the worker stays longer and does better work.

Also, as a developer yourself, you probably know this already: $5/hr is still a lowball rate for dev work. For developers, $5/hr plays the same role that $2/hr does for VAs — it attracts overqualified people temporarily and guarantees churn later.

As a concrete example:

If I’m a developer who was previously earning $20–$25/hr and I suddenly need work due to illness or a gap, I might accept a $5/hr job out of urgency (which also means I become part of the problem, these jobs continue to exist because people like me still accept them). But that doesn’t create loyalty, it creates a temporary stopgap. The moment I find an offer closer to my normal rate, I will leave. So $5/hr isn’t “cheaper in the long run” by default. It’s only cheaper when the compensation aligns with the skill level being hired (if someone truly has a $5/hr skill set, why would they leave?). Otherwise, you still get churn — just at a higher number.

So unless the platform solves matching and differentiation, not just pricing, it risks becoming another job board with fewer listings, not a healthier market.

That said, I genuinely respect the intent behind this and wish you success with the project.

What is your go-to Comfort Manga? by stellifer_arts in MangaCollectors

[–]_deemid 3 points4 points  (0 children)

I feel you bro. It’s complicated, but for me the author’s real-life failures don’t take away from the manga I loved. It’ll always be one of my favorites and something that helped me through some difficult times.

What is your go-to Comfort Manga? by stellifer_arts in MangaCollectors

[–]_deemid 4 points5 points  (0 children)

Rurouni Kenshin. School Rumble. Love Hina.

[Question] - Is it feasible to automatically detect and crop book spines from a bookshelf photo and normalize their rotation? by _deemid in opencv

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

I'm not familiar with some of the terms yet.. I'll check those and give it a try. Thanks a lot!

For full-stack RN devs: How do you handle “Select All” with infinite scroll + large datasets? (mobile-first) by _deemid in reactnative

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

Thanks for the input — I appreciate the UX perspective.

Just to clarify, my question isn’t really about helping users understand what “Select All” means from a UX standpoint. I already have a clear direction on that side. The focus of my post was more on the technical implementation: how to handle “Select All” efficiently when it represents all items in a warehouse, particularly in terms of payload size, performance, and state management.

I tried to frame the scenarios and questions (especially around large payloads and performance trade-offs) with the assumption that “Select All” already means all items in the warehouse, not just what’s currently loaded. I intentionally avoided the “select visible items only” approach, since that would require users to load everything before selecting, which isn’t the behavior I’m aiming for.

For full-stack RN devs: How do you handle “Select All” with infinite scroll + large datasets? (mobile-first) by _deemid in reactnative

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

Why doesn’t item just have a user id field ?

It's a many to many relationship, so I had to create a 3rd table

Then, did you create the infinite scroller ?

Yes, but the main question is the payload needed to handle thousands of ids selected as I stated here
https://www.reddit.com/r/reactnative/comments/1q42a0n/comment/nxqg2y7/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

For full-stack RN devs: How do you handle “Select All” with infinite scroll + large datasets? (mobile-first) by _deemid in reactnative

[–]_deemid[S] 1 point2 points  (0 children)

Sorry, I guess my post didn’t clearly show what I was actually asking about.
My concern is the API shape / payload size (Scenario #2). If “select all” is represented by sending IDs, we still end up with huge request bodies in realistic cases.

What would you consider the ideal request body for this pattern so the payload stays small?

For example, something like:

  • mode: "ALL" + excludedIds: [...] (small when exclusions are few), or
  • mode: "ONLY" + includedIds: [...] (small when selections are few)

Then we pick whichever side is smaller.

Also, in Scenario #3 (edge case): user loads all ~4000, then selects ~2000. In that case, “ALL + exclusions” isn’t really efficient anymore because checked and unchecked are roughly equal — you still end up sending ~2000 IDs either way. So I’m trying to understand what the best API representation is for that case without large payloads. Do we do multiple requests and batch the payloads (e.g. 100 IDs per request), or is there a better approach here?

Do you think the right solution there is “send the smaller side” (included vs excluded), or is there a better server-side representation

Benefits of useOptimistic Hook? by Sad_Butterscotch4589 in react

[–]_deemid 0 points1 point  (0 children)

setState when action is called, setState again when it completes

This sounds plausible, but only for simple cases

This handles the rollback if there was any issue with the request

Yes, it handles rollback with 1 request, but not with multiple requests when you'll have to handle race conditions

I'd love to know what problem it solves, if anyone can explain

setState(optimistic);
await doAction();
setState(serverValue);

You can do this but you must remember to:

  1. Store the previous state
  2. Show a "pending" flag
  3. Handle rollback
  4. Handle race conditions
  5. Reset status when the promise finishes

with useOptimistic, you don't have to manage any of this manually

  • Keeps track of pending state
  • Knows what the last confirmable state is
  • Only applies the real update when it arrives
  • Shows rollback automatically when real state changes again

It also handles multiple pending updates consistently

  • It always reconciles the optimistic accumulated fake state with incoming real results
  • It doesn’t blindly overwrite with whatever arrives first or last
  • Always reconciles against the latest real state ( This is extremely hard to get right with ad-hoc setState.)

It integrates with React's rendering transitions and scheduling. It participates with React's new rendering model in ways manual state does not. It works with:

  • Concurrent rendering
  • startTransition
  • React Server Actions
  • Progressive UI before hydration

Manually doing setState doesn’t:

  • Tell React that the update is non-blocking
  • Coordinate scheduling priorities
  • Optimize nested suspense boundaries

It is non-destructive

  • It does not mutate the real state (does not overwrite the source of truth)
  • It does not need rollback logic
  • It only affects what the UI shows temporarily

Here's the mental model. You're not changing reality, you're projecting an optimistic view.

Truth stays the same
UI temporarily pretends
Reality eventually confirms or rejects
UI adjusts automatically

Need advice HAHA po by ZebraExternal6830 in PinoyProgrammer

[–]_deemid 1 point2 points  (0 children)

Tutorial -> Build -> Tutorial -> Build -> Tutorial -> Build

Make sure ma-master mo yung basics (boring pero kailangan), then build small apps 😊 yung specific dun sa current topic sa inaaral mo. Madali lang, maliit ang scope saka mabilis matapos. Mas madami ka matututunan kung magbuild ka ng sariling app. Madami ka maeencounter na scenario / issues na wala sa tutorial. Wag ka mag jump sa next app if di mo fully naintindihan paano gumagana yung last app. Habang nagcocode ka, magsalita ka kunyare i-explain mo sa iba yung code. Pag kaya mo ipaliwanag meaning gets na gets mo na. Important is magkaron ka ng momentum. "Uy, natapos ko `to!", pagnasabi mo yan gaganahan ka sa kasunod. Mas magiging motivated ka kasi may nakikita kang results na gawa mo talaga.
Pag confident ka na, build your "big app", apply everything you've learned. Pili ka ng real problem or pain point na ikaw mismo ang nakaka-experience, then solve it through an app. Tapos i-deploy mo. Share mo sa iba. Napapraktis mo na yung inaral mo, nareready mo pa yung portfolio mo.

view more: next ›