π₯11β€4
Forwarded from EKD Designs
Introducing Lockd-in
Lockd In is a minimalist productivity web application built to help users manage their time and maintain deep focus.
Built Lockd-in when I was stressing for exit exam & design work overloads back in uni.
After weeks of beta testing, Lockd-in is officially liveπ π π
Thanks to everyone that gave me feedbacks, almost all feedbacks have been reviewed & edited into this versionπ
Features:
π₯ Streaks
πΈ Focus Cards
β³ Pop Out (PiP) Timer
βοΈ Session logs & Productivity Chart
If you've been meaning to build something but keep burning out halfway through, this is definitely for you.
π https://lockd-in.pages.dev/ (PC RECOMMENDED for now)
I'm not a developer, so there may be imperfections. If you find a bug, want a feature added, or wish to express your feelings, my comments and DMs are open.
Lock in. Outwork. Outlast.
@ekddesign
Lockd In is a minimalist productivity web application built to help users manage their time and maintain deep focus.
Built Lockd-in when I was stressing for exit exam & design work overloads back in uni.
After weeks of beta testing, Lockd-in is officially live
Thanks to everyone that gave me feedbacks, almost all feedbacks have been reviewed & edited into this version
Features:
All local, no login or sign up needed
If you've been meaning to build something but keep burning out halfway through, this is definitely for you.
I'm not a developer, so there may be imperfections. If you find a bug, want a feature added, or wish to express your feelings, my comments and DMs are open.
Lock in. Outwork. Outlast.
@ekddesign
Please open Telegram to view this post
VIEW IN TELEGRAM
lockd-in.pages.dev
Lockd In β Focus Workspace
Minimalist productivity for builders. Lock in. Outwork. Outlast.
β€4
Article of the day
Advanced git
Before pushing to
Before every push, review your changes with
If you've rebased your branch, avoid using
read more advanced git concepts π [ LINK ]
@devwitheyob
#TechVibe #git #ArticleOfTheDay
Advanced git
Before pushing to
main, make it a habit to sync your branch with the latest changes by rebasing on top of main. This helps you resolve conflicts early and keeps your commit history clean. If your branch has a lot of small "fix" or "oops" commits, use an interactive rebase to squash them into a few meaningful commits. A clean history makes reviewing code and debugging much easier later.Before every push, review your changes with
git diff and scan for anything that shouldn't be in the repository, such as API keys, tokens, passwords, or temporary debugging code. Then run your tests locally to make sure nothing is broken. Catching an issue before it reaches the remote repository is always easier than fixing it after deployment.If you've rebased your branch, avoid using
git push --force. Instead, use git push --force-with-lease, which checks whether someone else has updated the remote branch before overwriting it. Finally, tag important releases with versions like v1.0.0 or v2.1.0. Release tags make it easy to identify deployments, track changes between versions, and roll back quickly if something goes wrong in production.read more advanced git concepts π [ LINK ]
@devwitheyob
#TechVibe #git #ArticleOfTheDay
π₯5
Git in CI
CI runners clone your repo on every job. For a 200 MB monorepo with 50k commits and 10k refs, a naive
Shallow clone is the lazy fix. It downloads only the most recent commits, skipping history.
read more advanced git concepts π [ LINK ]
@devwitheyob
#TechVibe
CI runners clone your repo on every job. For a 200 MB monorepo with 50k commits and 10k refs, a naive
git clone burns 30-60 seconds per job before any test runs. Across a 40-job pipeline that is 30 minutes of pure clone wait per pull request. The fix is not "throw a faster runner at it", it is matching the clone strategy to what each job actually needs.Shallow clone is the lazy fix. It downloads only the most recent commits, skipping history.
git clone --depth=1 https://github.com/org/repo.gitread more advanced git concepts π [ LINK ]
@devwitheyob
#TechVibe
Git in CI
While shallow clones (
A better option is a partial clone, which downloads the commit history but only fetches file contents when they're actually needed. This keeps history available while making clones much faster and smaller.
For medium and large repos, especially monorepos, partial clones can significantly reduce clone time and disk usage without losing access to Git history.
read more advanced git concepts π [ LINK ]
@devwitheyob
#TechVibe #git #GitInCI
While shallow clones (
depth=1) are fast, they break commands that rely on Git history like git log, git blame, git merge-base, changelog generators, and release tools.A better option is a partial clone, which downloads the commit history but only fetches file contents when they're actually needed. This keeps history available while making clones much faster and smaller.
# Download history, fetch file contents on demand
git clone --filter=blob:none https://github.com/org/repo.git
# Skip blobs larger than 1 MB
git clone --filter=blob:limit=1m https://github.com/org/repo.git
For medium and large repos, especially monorepos, partial clones can significantly reduce clone time and disk usage without losing access to Git history.
read more advanced git concepts π [ LINK ]
@devwitheyob
#TechVibe #git #GitInCI
β€1π1
π10
Article of the day
LLM Integrations
Everyone gets excited when their AI feature finally works, but making one successful API call is the easiest part. What actually matters is everything around it before it reaches production. If you don't plan for failures, retries, rate limits, token budgets, or cost tracking, your application will eventually fail when real users start using it.
A production-ready LLM integration should be built with resilience in mind from day one. Abstract your provider so switching models is painless, retry only transient failures with exponential backoff, stream responses instead of making users wait, validate every tool call, and count tokens before every request to avoid expensive errors. None of these features make your demo look cooler, but they'll save you countless hours in production.
The biggest lesson is that reliability is a feature. Add observability, track your LLM costs, enforce sensible timeouts, and always have a fallback model ready. Production isn't about proving your AI worksβit's about making sure it keeps working when everything around it doesn't.
Read full article π [LINK]
@devwitheyob
#TechVibe #ArticleOfTheDay #AIEngineering #LLM
LLM Integrations
Everyone gets excited when their AI feature finally works, but making one successful API call is the easiest part. What actually matters is everything around it before it reaches production. If you don't plan for failures, retries, rate limits, token budgets, or cost tracking, your application will eventually fail when real users start using it.
A production-ready LLM integration should be built with resilience in mind from day one. Abstract your provider so switching models is painless, retry only transient failures with exponential backoff, stream responses instead of making users wait, validate every tool call, and count tokens before every request to avoid expensive errors. None of these features make your demo look cooler, but they'll save you countless hours in production.
The biggest lesson is that reliability is a feature. Add observability, track your LLM costs, enforce sensible timeouts, and always have a fallback model ready. Production isn't about proving your AI worksβit's about making sure it keeps working when everything around it doesn't.
Read full article π [LINK]
@devwitheyob
#TechVibe #ArticleOfTheDay #AIEngineering #LLM
π₯4π2β€1
Here's a simple fallback implementation in Go. Instead of failing the request when one provider is down or rate-limited, it just tries the next provider in the chain until one succeeds. It's a small pattern, but it makes a huge difference in production where outages and rate limits are normal. Graceful degradation is almost always better than showing your users an error.
@devwitheyob
#TechVibe #go #LLMIntegration
@devwitheyob
#TechVibe #go #LLMIntegration
β€4
Btw guys, today I sat at my desk at 2 PM, and it's almost 2 AM now. I literally worked for almost 12 hours straight.
I think this is the longest work session I've had this break. The good part is I finally finished the project.
The bad part... I'm not feeling my back π.
never had this kind of back pain before thoπ
@devwitheyob
#TechVibe #project #WorkSession
I think this is the longest work session I've had this break. The good part is I finally finished the project.
The bad part... I'm not feeling my back π.
never had this kind of back pain before thoπ
@devwitheyob
#TechVibe #project #WorkSession
π₯7
I realized something about myself over the past few months: when I truly believe something is necessary, I'll do whatever it takes to make it happen. I'll sacrifice my sleep, my comfort, my time, and even my money. Doing that has shown me how much I'm actually capable of in such a short amount of time, and it's boosted my confidence more than anything else.
Anyways, GN guys. βοΈ
@devwitheyob
#TechVibe #random
Anyways, GN guys. βοΈ
@devwitheyob
#TechVibe #random
β€6π3π₯3β‘1π€1