Forwarded from هزارتو
در این دوره، میکوشیم سری به سرآغازهای داستان بزنیم، و با نگاهی به بعضی آثار ماندگار تاریخ ادبیات داستانی، به پیدایش رمان در جهان جدید برسیم. هرچند تلاش میکنیم در طی دوره، از آراء و نظرات متفکران و نویسندگان مهم و مؤثر بهره ببریم، اما مسیر حرکتمان را محدود به نظریهی ادبی نخواهیم کرد، و میکوشیم از لابهلای خطوط خود قصهها، به رازورمز و تحولشان بپردازیم. درانتها، با نگاهی به تحولات تاریخی و اجتماعی، خواهیم دید چگونه سروکلّهی رمان پیدا میشود، و نظریهی رمان مقصد نهایی ما خواهد بود.
در صورت تمایل برای شرکت در این دوره، به شناسهی زیر پیام دهید 👇🏻
@Neemalavi
@hezaartoomag
در صورت تمایل برای شرکت در این دوره، به شناسهی زیر پیام دهید 👇🏻
@Neemalavi
@hezaartoomag
Forwarded from نوشتههای ترمینالی
یه استفاده که من اخیرا از git hook کردم ابن بود که مطمین بشم کامیت مسیج های یه سری پروژه خاص، یه فرمت خاصی رو رعایت میکنن. برای این کار از هوک commit-msg استفاده کردم. این هوک هم میاد قبل از این که واقعا کامیت صورت بگیره اجرا میشه و کامیت مسیج رو دریافت میکنه. در نهایت با کمک exit code میتونید مشخص کنید که کامیت مورد تایید هست یا باید ریجکت بشه.
کدی که من نوشتم:
#!/bin/bash
commit_regex='some regex'
error_msg="Aborting commit."
if ! grep -E "$commit_regex" "$1"; then echo "$error_msg" >&2
exit 1
fi
این فایل باید به این اسم سیو بشه: commit-msg توی پوشه hooks اون ریپوزیتوری.
اما حالا برای این که این اسکریپت رو همه جا تکرار نکنم چیکار کردم؟ اومدم از core hooks استفاده کردم. به این شکل میتونم بگم پوشه هوک دیفالت برای همه پرورهها یکی باشه و نیاز نیست برم داخل هر پروژه تک تک چک کنم.
کامندی که استفاده کردم اینه:
git config core.hooksPath
و نهایتا کانفیگ گیت اینطوری میشه:
[core]
hooksPath = /path/to/hooks/dir
اما اینجا هنوز یه تیکه گمشده دیگه هست. با این تغییراتی که من دادم این فرمت برای همهی پروژه ها روی سیستمم اعمال شد ولی من اینو نمیخوام، بلکه میخوام فقط توی پروژه خاصی خاصی اعمال بشه. کاری که میکنم استفاده از conditional config توی گیته. قضیه اینطوریه که یه فایل کانفیگ ثانویه میسازم که این کانفیگ توش نوشته شده و توی کانفیگ اصلی میگم includeif: یعنی فقط وقتی این کانفیگ رو اعمال کن که پوشه گیت من داخل یکی از این پوشه ها بود یا داخل مسیری بود که این پترن رو داشت.
منابع:
https://git-scm.com/docs/githooks
و
https://dev.to/chaz8080/git-smart-streamlining-your-workflow-with-the-prepare-commit-msg-hook-432p
و
https://medium.com/@mrjink/using-includeif-to-manage-your-git-identities-bcc99447b04b
و اگه خواستید دقیقش رو توی dotfile م ببینید:
https://github.com/rsharifnasab/dotfiles/blob/2b3ba235c300e8a5dbec53a7a84dde350ca372af/configs/.config/git/config#L51
و
https://github.com/rsharifnasab/dotfiles/blob/37f0812046ef9eceb7c3e18ff0e9fb6b30843828/configs/.config/git/snapp#L9
کدی که من نوشتم:
#!/bin/bash
commit_regex='some regex'
error_msg="Aborting commit."
if ! grep -E "$commit_regex" "$1"; then echo "$error_msg" >&2
exit 1
fi
این فایل باید به این اسم سیو بشه: commit-msg توی پوشه hooks اون ریپوزیتوری.
اما حالا برای این که این اسکریپت رو همه جا تکرار نکنم چیکار کردم؟ اومدم از core hooks استفاده کردم. به این شکل میتونم بگم پوشه هوک دیفالت برای همه پرورهها یکی باشه و نیاز نیست برم داخل هر پروژه تک تک چک کنم.
کامندی که استفاده کردم اینه:
git config core.hooksPath
و نهایتا کانفیگ گیت اینطوری میشه:
[core]
hooksPath = /path/to/hooks/dir
اما اینجا هنوز یه تیکه گمشده دیگه هست. با این تغییراتی که من دادم این فرمت برای همهی پروژه ها روی سیستمم اعمال شد ولی من اینو نمیخوام، بلکه میخوام فقط توی پروژه خاصی خاصی اعمال بشه. کاری که میکنم استفاده از conditional config توی گیته. قضیه اینطوریه که یه فایل کانفیگ ثانویه میسازم که این کانفیگ توش نوشته شده و توی کانفیگ اصلی میگم includeif: یعنی فقط وقتی این کانفیگ رو اعمال کن که پوشه گیت من داخل یکی از این پوشه ها بود یا داخل مسیری بود که این پترن رو داشت.
منابع:
https://git-scm.com/docs/githooks
و
https://dev.to/chaz8080/git-smart-streamlining-your-workflow-with-the-prepare-commit-msg-hook-432p
و
https://medium.com/@mrjink/using-includeif-to-manage-your-git-identities-bcc99447b04b
و اگه خواستید دقیقش رو توی dotfile م ببینید:
https://github.com/rsharifnasab/dotfiles/blob/2b3ba235c300e8a5dbec53a7a84dde350ca372af/configs/.config/git/config#L51
و
https://github.com/rsharifnasab/dotfiles/blob/37f0812046ef9eceb7c3e18ff0e9fb6b30843828/configs/.config/git/snapp#L9
DEV Community
Git Smart: Streamlining Your Workflow with the prepare-commit-msg Hook
Overview If you want to learn how to improve and automate your commit messages, you're in...
Forwarded from نوشتههای ترمینالی
تایپهای شایسته و ناشایسته
https://the-dr-lazy.github.io/incompetent-types
https://the-dr-lazy.github.io/incompetent-types
the-dr-lazy.github.io
تایپهای ناشایسته
این پست اولین بخش از سری پستهای «طریقت یک
FP…
FP…
Forwarded from جادی | Jadi
Maktabkhoone GIT tutorial progress
███████████░░░░░░░░░ [55%]
███████████░░░░░░░░░ [55%]
Forwarded from جادی | Jadi
Maktabkhoone GIT tutorial progress
███████████░░░░░░░░░ [55%]
███████████░░░░░░░░░ [55%]
Forwarded from Linuxor ?
پیش به سوی بدبختی
شرکت Bitnami که ابزار و کانتینر برای وب مثلا وردپرس، PHP و Node.js دیتابیسای معروف مثل Postgress و Mysql میسازه کفگیرش به ته دیگ خورده و محصولات و کانتینر هاشو داره پولی میکنه.
البته با تگ latest میتونید نسخه توسعه رو pull کنید ولی برای پروداکشن مناسب نیست.
@Linuxor
شرکت Bitnami که ابزار و کانتینر برای وب مثلا وردپرس، PHP و Node.js دیتابیسای معروف مثل Postgress و Mysql میسازه کفگیرش به ته دیگ خورده و محصولات و کانتینر هاشو داره پولی میکنه.
البته با تگ latest میتونید نسخه توسعه رو pull کنید ولی برای پروداکشن مناسب نیست.
@Linuxor
Forwarded from DevTwitter | توییت برنامه نویسی
به تازگی یه پروژه ای رو دیدم به اسم node-hooker که سازندش اومده از هوک های wordpress الهام گرفته و یه چیزی شبیه به اونارو برای ران تایم node نوشته
استفاده ازش میتونه وابستگی بخش های مختلف رو کمتر کنه و این امکان رو بده که باهاش یه معماری پلاگین محور بتونیم پیاده کنیم
اگه علاقه مند بودین یه سری به این پروژه بزنین.
https://mamedul.github.io/node-hooker/
@DevTwitter | <Ali Nazari/>
استفاده ازش میتونه وابستگی بخش های مختلف رو کمتر کنه و این امکان رو بده که باهاش یه معماری پلاگین محور بتونیم پیاده کنیم
اگه علاقه مند بودین یه سری به این پروژه بزنین.
https://mamedul.github.io/node-hooker/
@DevTwitter | <Ali Nazari/>
Forwarded from Reza Jafari
نکاتی که اگر حواسمون نباشه، پروژه Machine Learning رو زمین میزنن
پروژههای machine learning خیلی جذابن، ولی واقعیت اینه که پر از چالش و اشتباههای ریز و درشت هستن که اگر حواسمون نباشه، بیصدا پروژه رو خراب میکنن. یکی از مهمترین مشکلات وقتی پیش میاد که هدف پروژه شفاف نباشه. اگه دقیق ندانیم دنبال چی هستیم یا قراره موفقیت رو با چه معیاری بسنجیم، احتمال زیادی وجود داره که کلی وقت و منابع صرف کنیم ولی در نهایت راهحلی بسازیم که مشکل اصلی رو حل نمیکنه.
بعدش میرسیم به دادهها. دادههای واقعی معمولاً تمیز و کامل نیستن؛ پر از مقادیر گمشده، نویز و ناسازگاری هستن. اگر بدون رسیدگی از این دادهها استفاده کنیم، نتیجه مدل هم قابل اعتماد نخواهد بود. مرحله پیشپردازش داده هم اهمیت زیادی داره، چون اگر درست انجام نشه، مشکلاتی مثل data leakage رخ میده که معمولاً دیر متوجهش میشیم و تأثیرش مخربه.
انتخاب مدل هم خودش یه نکته حیاتیست. اگه مدل خیلی ساده باشه، نمیتونه الگوها رو یاد بگیره (underfitting) و اگه خیلی پیچیده باشه، روی دادههای آموزشی گیر میکنه و در دنیای واقعی کار نمیکنه (overfitting). تنظیم درست hyperparameterها هم ضروریه، چون حتی بهترین الگوریتم بدون تنظیم مناسب، خروجی خوبی نمیده.
وقتی مدل آماده شد، ارزیابی دقیق لازمه. بسنده کردن به یه متریک یا یه تقسیم داده، خیلی وقتها حس کاذب موفقیت ایجاد میکنه. روشهایی مثل cross-validation کمک میکنن تا مطمئن بشیم مدل واقعاً قابل اعتماد و پایدار هست. شفافیت مدل هم مهمه؛ مخصوصاً در حوزههای حساس مثل سلامت یا مالی، کاربرا و ذینفعان باید بتونن بفهمن مدل چرا یه تصمیم خاص گرفته.
استقرار مدل هم چالشهای خودش رو داره. مدل باید با سیستمهای موجود هماهنگ باشه، سرعت پیشبینی مناسب باشه و مسیر بازآموزی (retraining) داشته باشه. اگر این موارد رعایت نشه، حتی بهترین مدل هم در محیط واقعی بلااستفاده میشه. تعامل با کاربرها هم مهمه؛ اگه پیشبینیها برای کاربر قابل فهم یا عملی نباشه، خیلی راحت کنار گذاشته میشه.
و در نهایت، نگهداری و مانیتورینگ مدل ضروریه. مدلهای ML مثل یه باغچهن؛ اگه بعد از کاشت رهاشون کنیم، عملکردشون به مرور افت میکنه. دادهها تغییر میکنن و این باعث data drift میشه. اگه سیستم نظارت و بازآموزی نداشته باشیم، ممکنه مدتها مدل خروجی غلط بده و متوجه نشیم.
در مجموع، پروژههای machine learning فقط به ساختن یک مدل خلاصه نمیشن. از تعیین هدف و آمادهسازی دادهها تا ارزیابی، استقرار و نگهداری، دهها دام وجود داره که اگر شناسایی و مدیریت نشن، پروژه رو به شکست میکشونن. اما با شناخت این اشتباهها و برنامهریزی درست، احتمال موفقیت خیلی بیشتر میشه.
🔤 🔤 🔤 🔤 🔤 🔤 🔤
🥇 اهورا اولین اپراتور هوش مصنوعی راهبردی ایران در حوزه ارائه خدمات و سرویسهای زیرساخت هوش مصنوعی
🌐 لینک ارتباط با اهورا
@reza_jafari_ai
پروژههای machine learning خیلی جذابن، ولی واقعیت اینه که پر از چالش و اشتباههای ریز و درشت هستن که اگر حواسمون نباشه، بیصدا پروژه رو خراب میکنن. یکی از مهمترین مشکلات وقتی پیش میاد که هدف پروژه شفاف نباشه. اگه دقیق ندانیم دنبال چی هستیم یا قراره موفقیت رو با چه معیاری بسنجیم، احتمال زیادی وجود داره که کلی وقت و منابع صرف کنیم ولی در نهایت راهحلی بسازیم که مشکل اصلی رو حل نمیکنه.
بعدش میرسیم به دادهها. دادههای واقعی معمولاً تمیز و کامل نیستن؛ پر از مقادیر گمشده، نویز و ناسازگاری هستن. اگر بدون رسیدگی از این دادهها استفاده کنیم، نتیجه مدل هم قابل اعتماد نخواهد بود. مرحله پیشپردازش داده هم اهمیت زیادی داره، چون اگر درست انجام نشه، مشکلاتی مثل data leakage رخ میده که معمولاً دیر متوجهش میشیم و تأثیرش مخربه.
انتخاب مدل هم خودش یه نکته حیاتیست. اگه مدل خیلی ساده باشه، نمیتونه الگوها رو یاد بگیره (underfitting) و اگه خیلی پیچیده باشه، روی دادههای آموزشی گیر میکنه و در دنیای واقعی کار نمیکنه (overfitting). تنظیم درست hyperparameterها هم ضروریه، چون حتی بهترین الگوریتم بدون تنظیم مناسب، خروجی خوبی نمیده.
وقتی مدل آماده شد، ارزیابی دقیق لازمه. بسنده کردن به یه متریک یا یه تقسیم داده، خیلی وقتها حس کاذب موفقیت ایجاد میکنه. روشهایی مثل cross-validation کمک میکنن تا مطمئن بشیم مدل واقعاً قابل اعتماد و پایدار هست. شفافیت مدل هم مهمه؛ مخصوصاً در حوزههای حساس مثل سلامت یا مالی، کاربرا و ذینفعان باید بتونن بفهمن مدل چرا یه تصمیم خاص گرفته.
استقرار مدل هم چالشهای خودش رو داره. مدل باید با سیستمهای موجود هماهنگ باشه، سرعت پیشبینی مناسب باشه و مسیر بازآموزی (retraining) داشته باشه. اگر این موارد رعایت نشه، حتی بهترین مدل هم در محیط واقعی بلااستفاده میشه. تعامل با کاربرها هم مهمه؛ اگه پیشبینیها برای کاربر قابل فهم یا عملی نباشه، خیلی راحت کنار گذاشته میشه.
و در نهایت، نگهداری و مانیتورینگ مدل ضروریه. مدلهای ML مثل یه باغچهن؛ اگه بعد از کاشت رهاشون کنیم، عملکردشون به مرور افت میکنه. دادهها تغییر میکنن و این باعث data drift میشه. اگه سیستم نظارت و بازآموزی نداشته باشیم، ممکنه مدتها مدل خروجی غلط بده و متوجه نشیم.
در مجموع، پروژههای machine learning فقط به ساختن یک مدل خلاصه نمیشن. از تعیین هدف و آمادهسازی دادهها تا ارزیابی، استقرار و نگهداری، دهها دام وجود داره که اگر شناسایی و مدیریت نشن، پروژه رو به شکست میکشونن. اما با شناخت این اشتباهها و برنامهریزی درست، احتمال موفقیت خیلی بیشتر میشه.
@reza_jafari_ai
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Gopher Academy
🔵 عنوان مقاله
3 Critical TTL Patterns for In-Memory Caching
🟢 خلاصه مقاله:
این مقاله سه الگوی کلیدی TTL برای کش درونحافظهای را توضیح میدهد و نشان میدهد چگونه انتخاب درست میان تازگی داده، کارایی و پایداری را ممکن میکند. الگوی اول، TTL ثابت است: هر مقدار پس از مدت مشخص منقضی میشود؛ ساده و قابلپیشبینی است، اما نزدیک انقضا میتواند داده قدیمی ارائه کند و پس از انقضا به «thundering herd» منجر شود مگر اینکه با jitter و همگرایی درخواستها مدیریت شود. الگوی دوم، TTL لغزشی است: هر دسترسی عمر آیتم را تمدید میکند، برای کلیدهای پرترافیک عالی است اما بدون «حداکثر عمر» ممکن است بعضی مقادیر عملاً هرگز تازهسازی نشوند. الگوی سوم، stale-while-revalidate (و refresh-ahead) است: مقدار کمی کهنه فوراً سرو میشود و تازهسازی در پسزمینه انجام میگیرد؛ با single-flight از هجوم درخواستهای همسان جلوگیری میکند و در صورت خطا میتوان با stale-if-error موقتاً از آخرین مقدار سالم استفاده کرد. در عمل ترکیب این الگوها—بههمراه TTLهای متفاوت برای هر کلید، jitter، backoff و رصد دقیق نرخ hit/miss—به تعادل بهینه میانجامد. نویسنده برای نمایش پیادهسازیهای عملی از کتابخانه Hot در اکوسیستم Go بهره میگیرد تا استفاده از این الگوها ساده و کارا شود.
#Caching #TTL #InMemoryCache #Go #Golang #StaleWhileRevalidate #Performance #CacheStampede
🟣لینک مقاله:
https://golangweekly.com/link/175058/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
3 Critical TTL Patterns for In-Memory Caching
🟢 خلاصه مقاله:
این مقاله سه الگوی کلیدی TTL برای کش درونحافظهای را توضیح میدهد و نشان میدهد چگونه انتخاب درست میان تازگی داده، کارایی و پایداری را ممکن میکند. الگوی اول، TTL ثابت است: هر مقدار پس از مدت مشخص منقضی میشود؛ ساده و قابلپیشبینی است، اما نزدیک انقضا میتواند داده قدیمی ارائه کند و پس از انقضا به «thundering herd» منجر شود مگر اینکه با jitter و همگرایی درخواستها مدیریت شود. الگوی دوم، TTL لغزشی است: هر دسترسی عمر آیتم را تمدید میکند، برای کلیدهای پرترافیک عالی است اما بدون «حداکثر عمر» ممکن است بعضی مقادیر عملاً هرگز تازهسازی نشوند. الگوی سوم، stale-while-revalidate (و refresh-ahead) است: مقدار کمی کهنه فوراً سرو میشود و تازهسازی در پسزمینه انجام میگیرد؛ با single-flight از هجوم درخواستهای همسان جلوگیری میکند و در صورت خطا میتوان با stale-if-error موقتاً از آخرین مقدار سالم استفاده کرد. در عمل ترکیب این الگوها—بههمراه TTLهای متفاوت برای هر کلید، jitter، backoff و رصد دقیق نرخ hit/miss—به تعادل بهینه میانجامد. نویسنده برای نمایش پیادهسازیهای عملی از کتابخانه Hot در اکوسیستم Go بهره میگیرد تا استفاده از این الگوها ساده و کارا شود.
#Caching #TTL #InMemoryCache #Go #Golang #StaleWhileRevalidate #Performance #CacheStampede
🟣لینک مقاله:
https://golangweekly.com/link/175058/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Substack
3 Critical TTL Patterns for In-Memory Caching
Most caching libraries get TTL expiration wrong. They focus on per-key complexity while missing the patterns that actually prevent production outages.
Forwarded from TheAliBigdeli Channel
مدیریت خطا و پیامها
تو هر پروژهای خطا اجتنابناپذیره، مهم اینه چطور باهاش برخورد کنیم. اگه پیامها درست مدیریت نشن، هم کاربر گیج میشه، هم فرانت سختتر میتونه هندل کنه.
چند تا نکته به عنوان best practice:
- برای خطاها یه ساختار مشخص داشته باش تا فرانت بتونه راحت تشخیص بده با چه شرایطی طرفه.
- پیام برای کاربر باید ساده و قابل فهم باشه، نه پر از اصطلاحات فنی.
- جزئیات فنی و لاگها رو نگه دار برای بکاند و تیم فنی، نه برای کاربر.
- همیشه از پیامهای عمومی برای خطاهای پیشبینینشده استفاده کن (مثل "مشکلی پیش اومده، دوباره امتحان کن").
- خطاها رو دستهبندی کن (مثلاً خطای کاربر، خطای سرور، خطای دسترسی) تا بتونی راحتتر مدیریت کنی.
از مهمترین شرایطی که باید یک توسعه دهنده بک اند در API لحاظ کنه Custom Exception Handler هستش تا بتونه خطا ها رو با یک فرمت مناسب و یک دست پاسخ بده و این موضوع بر اساس کمپانی های مختلف متفاوت هستش ولی می تونین الگوی مناسبی رو از درونشون پیدا کنین.
مثلا داشتن کلید error در پیام و همچنین در ادامه status کد خطای اتفاق افتاده و همچنین جدا سازی detail و message که در یکی خطای توسعه و دیگری پیام قابل نمایش به کاربر قرار میگیره. در بعضی شرایط ممکنه حتی timestamp و اطلاعات بیشتری هم درج بشه مثلا code یا type که ممکنه شماره خطای خاص و یا کلید واژه مربوطه برای ردگیری خطای سریعتر باشه.
دیده میشه گاهی وقتا آدرس و یا حتی ورودی ها رو هم در بعضی سرویس ها نشون میدن که به نظرم جاش توی ریسپانس نیست و باید توی لاگ ها باشه و با این حال بعضی سرویس ها ارائه میدن.
نمونه Response مناسب برای خطا ها
رفرنس ها:
- https://zuplo.com/learning-center/best-practices-for-api-error-handling
- https://api7.ai/learning-center/api-101/error-handling-apis
- https://nordicapis.com/5-real-world-examples-of-great-api-error-messages/
- https://www.baeldung.com/rest-api-error-handling-best-practices
📢 @thealibigdeli_channel
#api_design
#api
تو هر پروژهای خطا اجتنابناپذیره، مهم اینه چطور باهاش برخورد کنیم. اگه پیامها درست مدیریت نشن، هم کاربر گیج میشه، هم فرانت سختتر میتونه هندل کنه.
چند تا نکته به عنوان best practice:
- برای خطاها یه ساختار مشخص داشته باش تا فرانت بتونه راحت تشخیص بده با چه شرایطی طرفه.
- پیام برای کاربر باید ساده و قابل فهم باشه، نه پر از اصطلاحات فنی.
- جزئیات فنی و لاگها رو نگه دار برای بکاند و تیم فنی، نه برای کاربر.
- همیشه از پیامهای عمومی برای خطاهای پیشبینینشده استفاده کن (مثل "مشکلی پیش اومده، دوباره امتحان کن").
- خطاها رو دستهبندی کن (مثلاً خطای کاربر، خطای سرور، خطای دسترسی) تا بتونی راحتتر مدیریت کنی.
از مهمترین شرایطی که باید یک توسعه دهنده بک اند در API لحاظ کنه Custom Exception Handler هستش تا بتونه خطا ها رو با یک فرمت مناسب و یک دست پاسخ بده و این موضوع بر اساس کمپانی های مختلف متفاوت هستش ولی می تونین الگوی مناسبی رو از درونشون پیدا کنین.
مثلا داشتن کلید error در پیام و همچنین در ادامه status کد خطای اتفاق افتاده و همچنین جدا سازی detail و message که در یکی خطای توسعه و دیگری پیام قابل نمایش به کاربر قرار میگیره. در بعضی شرایط ممکنه حتی timestamp و اطلاعات بیشتری هم درج بشه مثلا code یا type که ممکنه شماره خطای خاص و یا کلید واژه مربوطه برای ردگیری خطای سریعتر باشه.
دیده میشه گاهی وقتا آدرس و یا حتی ورودی ها رو هم در بعضی سرویس ها نشون میدن که به نظرم جاش توی ریسپانس نیست و باید توی لاگ ها باشه و با این حال بعضی سرویس ها ارائه میدن.
نمونه Response مناسب برای خطا ها
{
"error": {
"status": 404,
"code": "OBJECT_NOT_FOUND",
"message": "آبجکت مورد نظر یافت نشد",
"detail": "Object matching query does not exist.",
"timestamp": "2025-10-03T12:30:45Z"
}
}رفرنس ها:
- https://zuplo.com/learning-center/best-practices-for-api-error-handling
- https://api7.ai/learning-center/api-101/error-handling-apis
- https://nordicapis.com/5-real-world-examples-of-great-api-error-messages/
- https://www.baeldung.com/rest-api-error-handling-best-practices
📢 @thealibigdeli_channel
#api_design
#api
Forwarded from DevTwitter | توییت برنامه نویسی
This media is not supported in your browser
VIEW IN TELEGRAM
کمپانی IBM امروز یک سری مدل جدید Granite 4.0 رو منتشر کرده، جدیدترین سری مدلهای LLM کوچیکش!
این مدلها توی کارای agentic (مثل فراخوانی ابزار)، تحلیل اسناد، RAG و کلی چیز دیگه واقعاً خیلی خوبند. مدل Micro (3.4B) (یک مدل با ۳.۴ میلیارد پارامتر!) حتی میتونه ۱۰۰٪ به صورت لوکال توی مرورگرتون روی WebGPU اجرا بشه، با کمک Transformers.js!
https://huggingface.co/spaces/ibm-granite/Granite-4.0-WebGPU
@DevTwitter | <Mehdi Allahyari/>
این مدلها توی کارای agentic (مثل فراخوانی ابزار)، تحلیل اسناد، RAG و کلی چیز دیگه واقعاً خیلی خوبند. مدل Micro (3.4B) (یک مدل با ۳.۴ میلیارد پارامتر!) حتی میتونه ۱۰۰٪ به صورت لوکال توی مرورگرتون روی WebGPU اجرا بشه، با کمک Transformers.js!
https://huggingface.co/spaces/ibm-granite/Granite-4.0-WebGPU
@DevTwitter | <Mehdi Allahyari/>
Forwarded from Python BackendHub (Mani)
و به این شکل یوزر هر زبونی که هست براش ترجمه میکنید.
چرا بهتره ترجمه رو سمت کلاینت نگه داریم؟
۱. از رو مرورگر میتونید متوجه بشید زبون کاربر چیه. ولی بخواین اینو رو سرور متوجه شید باید فرانت اول یک کدی بفرسته که اینو براتون تو سرور بفرسته.
۲. اینکه کاربر چه زبونی داره در درجه اول state frontend هست. نه بک اند.
۳. اگه یوزر زبونش رو تغییر داد, اگه فرانت state management رو درست انجام داده باشه بدون اینکه درخواست http ای بزنه کل محتوا صفحه رو میتونه آپدیت کنه. و این تجربه کاربری رو بهتر میکنه.
۴. اکوسیستم مدیریت زبان در فرانت بسیار قوی تره.
ولی خب در نهایت یک جاهایی مجبور میشیم ترجمه سمت سرورم داشته باشیم. مثلا ارسال نوتفیکیشن.
@PyBackendHub
چرا بهتره ترجمه رو سمت کلاینت نگه داریم؟
۱. از رو مرورگر میتونید متوجه بشید زبون کاربر چیه. ولی بخواین اینو رو سرور متوجه شید باید فرانت اول یک کدی بفرسته که اینو براتون تو سرور بفرسته.
۲. اینکه کاربر چه زبونی داره در درجه اول state frontend هست. نه بک اند.
۳. اگه یوزر زبونش رو تغییر داد, اگه فرانت state management رو درست انجام داده باشه بدون اینکه درخواست http ای بزنه کل محتوا صفحه رو میتونه آپدیت کنه. و این تجربه کاربری رو بهتر میکنه.
۴. اکوسیستم مدیریت زبان در فرانت بسیار قوی تره.
ولی خب در نهایت یک جاهایی مجبور میشیم ترجمه سمت سرورم داشته باشیم. مثلا ارسال نوتفیکیشن.
@PyBackendHub
Forwarded from Python BackendHub (Mani)
این پستو دیدم تقریبا هر Rest standard ای بود توش رعایت نشده :))
در خصوص ارور و integration داشتن خوب با فرانت اند؛
۱. همیشه سعی کنید از HTTP STATUS استفاده کنید. اگه ۲۰۰ میدین یعنی ریسپانس موفقیت آمیز بوده، حالا هرچی که اسمشو موفقیت آمیز میذارید. چون تقریبا تمام ابزار های telemetry (چه بک اند چه فرانت) بر مبنا همین کار میکنه. اینکه شما http status code رو بذارید تو بادی کار بسیار اشتباه و غلطی هست. استاندارد های http رو دور زدید.
۲. فرانتی که نمیدونه کی به سرور درخواست داده، دولوپر نیست. صرفا یک LLM ای هست با دسترسی به git. یک تایمی ارسال میشه از سمت سرور به کلاینت. حالا اگه این تایم استمپ زمان اتمام درخواسته بازم برای کلاینت مهم نیست که شما بخوای رو سرور بذاری. برای کلاینت مهم اینه که درخواست رو کی دریافت کرده که میدونه.
۳. اینکه شما پیام ترجمه شده رو سمت سرور نگه دارید یک اشتباه دیگست. code کافیه. داکیومنت شما باید تو OpenAPI برای ارور ها باید schema داشته باشه که فرانت بدونه چه ارور هایی ممکنه بیاد. اینطوری اگه فرانت از ابزار های code auto generate استفاده کنه (که مثلا schema openapi رو میگیرن و کلاینت میسازن خودشون) اون ارور هارو هم میبینه و تو تایپ سیستمش میاد. میتونه اونا رو حالا به هر زبونی که کاربر هست بهش نشون بده. میتونه هرجوری بخواد ترجمه کنه. OBJECT_NOT_FOUND هم به شدت کلید اشتباهیه. چون معلوم نیست کدوم آبجکت not found عه. درستش اینه مثلا BookNotFound.که فرانت بتونه ترجمه کنه.
اگه خیلی فرانت بخوای قشنگ کارو در بیاره (تو سورس کد خودم اینکارو کردم) یک هوک نوشتم
پس هم میتونی بنویسی
و هم
@PyBackendHub
در خصوص ارور و integration داشتن خوب با فرانت اند؛
۱. همیشه سعی کنید از HTTP STATUS استفاده کنید. اگه ۲۰۰ میدین یعنی ریسپانس موفقیت آمیز بوده، حالا هرچی که اسمشو موفقیت آمیز میذارید. چون تقریبا تمام ابزار های telemetry (چه بک اند چه فرانت) بر مبنا همین کار میکنه. اینکه شما http status code رو بذارید تو بادی کار بسیار اشتباه و غلطی هست. استاندارد های http رو دور زدید.
۲. فرانتی که نمیدونه کی به سرور درخواست داده، دولوپر نیست. صرفا یک LLM ای هست با دسترسی به git. یک تایمی ارسال میشه از سمت سرور به کلاینت. حالا اگه این تایم استمپ زمان اتمام درخواسته بازم برای کلاینت مهم نیست که شما بخوای رو سرور بذاری. برای کلاینت مهم اینه که درخواست رو کی دریافت کرده که میدونه.
۳. اینکه شما پیام ترجمه شده رو سمت سرور نگه دارید یک اشتباه دیگست. code کافیه. داکیومنت شما باید تو OpenAPI برای ارور ها باید schema داشته باشه که فرانت بدونه چه ارور هایی ممکنه بیاد. اینطوری اگه فرانت از ابزار های code auto generate استفاده کنه (که مثلا schema openapi رو میگیرن و کلاینت میسازن خودشون) اون ارور هارو هم میبینه و تو تایپ سیستمش میاد. میتونه اونا رو حالا به هر زبونی که کاربر هست بهش نشون بده. میتونه هرجوری بخواد ترجمه کنه. OBJECT_NOT_FOUND هم به شدت کلید اشتباهیه. چون معلوم نیست کدوم آبجکت not found عه. درستش اینه مثلا BookNotFound.که فرانت بتونه ترجمه کنه.
اگه خیلی فرانت بخوای قشنگ کارو در بیاره (تو سورس کد خودم اینکارو کردم) یک هوک نوشتم
useError. این هوک اگه ریسپانس ۲۰۰نباشه ریسپانس رو میگیره. و کدش رو مپ میکنه به زبون یوزر و ترجمه میکنه و بهش نمایش میده. اگه کدی هم وجود نداشت (مثلا اروری که واقعا catch نشده بود) اون موقع فال بک میشه به اینکه خطایی در سرور رخ داده و نمیدونم این خطا چیه :). این هوک من, به شما هم ErrorMessage رو میده. هم یک کال بکی میده که از react-toastify استفاده کرده و ارور رو toast میکنه برای شما. پس هم میتونی بنویسی
const { errorMessage } = useError()
errorMessage(response)
و هم
const { toastError} = useError()
toastError(response)
@PyBackendHub
Forwarded from DevTwitter | توییت برنامه نویسی
کتابخونهٔ «hazm» آپدیت نمیشه و با نسخههای جدید پایتون و کتابخانههایی مثل pandas و langchain سازگار نیست.
اما کتابخونهٔ جدیدتری توسعه داده شده به نام «شِکَر». کتابخانهای مدرن، بهروز و هماهنگ با آخرین نسخههای پایتون برای پردازش متن فارسی.
https://github.com/amirivojdan/shekar
@DevTwitter | <Ali Moameri/>
اما کتابخونهٔ جدیدتری توسعه داده شده به نام «شِکَر». کتابخانهای مدرن، بهروز و هماهنگ با آخرین نسخههای پایتون برای پردازش متن فارسی.
https://github.com/amirivojdan/shekar
@DevTwitter | <Ali Moameri/>
Forwarded from DevTwitter | توییت برنامه نویسی
Forwarded from Mr Python | مستر پایتون (حسین)
🟣 اسمبلی x86 - قسمت 6 : چرخه اجرای 8086
از این قسمت وارد بخشی از دوره خواهیم شد که اختصاصا به ریزپردازنده 8086 که پایه ی خانواده x86 حساب میشه میپردازیم . در این قسمت به معرفی نمای کلی داخلی 8086 که شامل بخش های EU و BIU هست میپردازیم ، چرخه اجرای (Execution Cycle) این ریزپردازنده را بررسی کرده و در مورد قابلیت خط لوله (Pipeline) که موجب تسریع و بهینه سازی اجرای دستورالعمل ها خواهد شد صحبت میکنیم .
02:08 معرفی و یادآوری ریزپردازنده 8086
08:17 چرخه اجرا (Execution Cycle)
12:40 نمای کلی داخلی 8086 شامل بخش های BIU و EU
22:07 قابلیت خط لوله (Pipeline) در 8086
Aparat : https://www.aparat.com/v/bpww31t
Youtube : https://youtu.be/xgZ2AmyrDKI
🆔 : @MrPythonBlog | BOOST
از این قسمت وارد بخشی از دوره خواهیم شد که اختصاصا به ریزپردازنده 8086 که پایه ی خانواده x86 حساب میشه میپردازیم . در این قسمت به معرفی نمای کلی داخلی 8086 که شامل بخش های EU و BIU هست میپردازیم ، چرخه اجرای (Execution Cycle) این ریزپردازنده را بررسی کرده و در مورد قابلیت خط لوله (Pipeline) که موجب تسریع و بهینه سازی اجرای دستورالعمل ها خواهد شد صحبت میکنیم .
02:08 معرفی و یادآوری ریزپردازنده 8086
08:17 چرخه اجرا (Execution Cycle)
12:40 نمای کلی داخلی 8086 شامل بخش های BIU و EU
22:07 قابلیت خط لوله (Pipeline) در 8086
Aparat : https://www.aparat.com/v/bpww31t
Youtube : https://youtu.be/xgZ2AmyrDKI
🆔 : @MrPythonBlog | BOOST
Forwarded from linuxtnt(linux tips and tricks) (hosein seilany https://seilany.ir/)
⭐️ ۷ اپلیکیشن رایگان و کاربردی Odoo برای کاربران لینوکس در سال ۲۰۲۵
🔹پست آموزشی کامل در آکادمی کندوی دانش. مرجع آموزشهای متن باز و لینوکس به فارسی
https://learninghive.ir/odoo/
نویسنده: حسین سیلانی
🔹پست آموزشی کامل در آکادمی کندوی دانش. مرجع آموزشهای متن باز و لینوکس به فارسی
https://learninghive.ir/odoo/
نویسنده: حسین سیلانی
Forwarded from Gopher Academy
🔵 عنوان مقاله
celebrates its tenth anniversary with a look
🟢 خلاصه مقاله:
این مقاله دهمین سالگرد یک ابزار زیرساختی متنباز مبتنی بر Go را جشن میگیرد و نشان میدهد چگونه از یک ابزار کوچک به مولفهای بالغ و شناختهشده در تیمهای DevOps و SRE تبدیل شده است؛ با بهبودهای کارایی و پایداری، معماری افزونهپذیر، API/CLI پایدار و تمرکز جدی بر امنیت و زنجیره تأمین. اکوسیستم آن با جامعهای پویا، مستندات بهتر، نسخهبندی معنادار، سازگاری عقبرو و یکپارچگی گسترده با فضای ابری، CI/CD و ابزارهای مشاهدهپذیری رشد کرده است. در ادامه، نقشهراه بر بهبود تجربه کاربری، غنیتر شدن API/SDK، تقویت policy-as-code، مدیریت بهتر وضعیت و دریفت، و اتوماسیون ایمنتر در مقیاس تأکید میکند.
#Go #Infrastructure #DevOps #OpenSource #Cloud #Automation #Security #Observability
🟣لینک مقاله:
https://golangweekly.com/link/175053/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
celebrates its tenth anniversary with a look
🟢 خلاصه مقاله:
این مقاله دهمین سالگرد یک ابزار زیرساختی متنباز مبتنی بر Go را جشن میگیرد و نشان میدهد چگونه از یک ابزار کوچک به مولفهای بالغ و شناختهشده در تیمهای DevOps و SRE تبدیل شده است؛ با بهبودهای کارایی و پایداری، معماری افزونهپذیر، API/CLI پایدار و تمرکز جدی بر امنیت و زنجیره تأمین. اکوسیستم آن با جامعهای پویا، مستندات بهتر، نسخهبندی معنادار، سازگاری عقبرو و یکپارچگی گسترده با فضای ابری، CI/CD و ابزارهای مشاهدهپذیری رشد کرده است. در ادامه، نقشهراه بر بهبود تجربه کاربری، غنیتر شدن API/SDK، تقویت policy-as-code، مدیریت بهتر وضعیت و دریفت، و اتوماسیون ایمنتر در مقیاس تأکید میکند.
#Go #Infrastructure #DevOps #OpenSource #Cloud #Automation #Security #Observability
🟣لینک مقاله:
https://golangweekly.com/link/175053/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Traefik Labs
Traefik's 10-Year Anniversary: A Community's Journey
10 years ago, I made a small reverse proxy project public. Fast forward to today and Traefik has 3.4B downloads and 56k GitHub stars. See how it unfolded.