یک سایت خیلی جذاب و کاربردی پیدا کردم
این سایت کلی DESIGN.md آماده داره که کلی تمپلیت، سیستم طراحی، رنگ، تایپوگرافی و استایل آماده جمع کرده. میتونید از بینشون بگردید، ایده بگیرید و برای پروژههای خودتون استفاده کنید.
آدرس سایت :
https://aura.build/design-systems
@DevTwitter | <Alireza/>
این سایت کلی DESIGN.md آماده داره که کلی تمپلیت، سیستم طراحی، رنگ، تایپوگرافی و استایل آماده جمع کرده. میتونید از بینشون بگردید، ایده بگیرید و برای پروژههای خودتون استفاده کنید.
آدرس سایت :
https://aura.build/design-systems
@DevTwitter | <Alireza/>
❤21👍5👎2
یکی از مفاهیم جالب Kubernetes که معمولا درکش هم برای بار اول خیلی یجوریه و اذیت کنندس و باید چنتا سایت و داکیومنت رو خوند تا قشنگ فهمید موضوع Headless Service هستش و این که Service همیشه قرار نیست ترافیک رو بین Podها پخش کنه.
مثلا اگه سه تا Pod داشته باشیم که پشت یک Service قرار گرفته باشن، وقتی Application به اون Service وصل میشه، معمولا Service درخواست رو به یکی از Podها میرسونه.
ولی حالا ممکنه شرایطی پیش بیاد که Application بخواد IP تک تک Podها رو بدونه و مستقیم با هرکدوم یه ارتباطی برقرار کنه، مثلا توی بعضی سیستم ها مثل کافکا یا clickhouse لازمه خب که اعضای خودشون رو بشناسن و با هر Node بهصورت جداگانه ارتباط داشته باشن و ... که اینجا Service معمولی خیلی مناسب نیست.
یکی از راهاش اینه که بریم سراغ Kubernetes API و از اونجا لیست Podها و IPهاشون رو بگیریم بعد دونه دونه هرکار میخوایم بکنیم، ولی خب این یعنی Application ما باید Kubernetes رو بشناسه و مستقیم با API Server کار کنه.
راه تمیزترش میشه همون Headless Service .
توی حالت نرمال، DNS مربوط به یک Service، آدرس ClusterIP رو برمیگردونه، ولی وقتی Service رو Headless میکنیم، با نوشتن:
clusterIP: None
دیگه Kubernetes برای اون Service یک ClusterIP نمیذاره، بجاش وقتی Application از طریق DNS اون Service رو Lookup میکنه، DNS میتونه IP خود Podهای پشت Service رو برگردونه، حالا Application خودش تصمیم میگیره با کدوم Pod ارتباط برقرار کنه با یکی، چندتا یا همشون.
پس تفاوت مهمی که اینجا هست اینه که:
کوبر برای Service معمولی یه آیپی ثابت میده، خودشم یکی از Podها رو انتخاب میکنه و ...
ولی برای Headless Service دیگه Load Balancing انجام نمیده، آیپی Podهای پشت این Service رو بهمون میده، دیگه بقیش با خودمونه که چکار کنیم باهاش.
@DevTwitter | <S.M.Sadegh Raeeskarami/>
مثلا اگه سه تا Pod داشته باشیم که پشت یک Service قرار گرفته باشن، وقتی Application به اون Service وصل میشه، معمولا Service درخواست رو به یکی از Podها میرسونه.
ولی حالا ممکنه شرایطی پیش بیاد که Application بخواد IP تک تک Podها رو بدونه و مستقیم با هرکدوم یه ارتباطی برقرار کنه، مثلا توی بعضی سیستم ها مثل کافکا یا clickhouse لازمه خب که اعضای خودشون رو بشناسن و با هر Node بهصورت جداگانه ارتباط داشته باشن و ... که اینجا Service معمولی خیلی مناسب نیست.
یکی از راهاش اینه که بریم سراغ Kubernetes API و از اونجا لیست Podها و IPهاشون رو بگیریم بعد دونه دونه هرکار میخوایم بکنیم، ولی خب این یعنی Application ما باید Kubernetes رو بشناسه و مستقیم با API Server کار کنه.
راه تمیزترش میشه همون Headless Service .
توی حالت نرمال، DNS مربوط به یک Service، آدرس ClusterIP رو برمیگردونه، ولی وقتی Service رو Headless میکنیم، با نوشتن:
clusterIP: None
دیگه Kubernetes برای اون Service یک ClusterIP نمیذاره، بجاش وقتی Application از طریق DNS اون Service رو Lookup میکنه، DNS میتونه IP خود Podهای پشت Service رو برگردونه، حالا Application خودش تصمیم میگیره با کدوم Pod ارتباط برقرار کنه با یکی، چندتا یا همشون.
پس تفاوت مهمی که اینجا هست اینه که:
کوبر برای Service معمولی یه آیپی ثابت میده، خودشم یکی از Podها رو انتخاب میکنه و ...
ولی برای Headless Service دیگه Load Balancing انجام نمیده، آیپی Podهای پشت این Service رو بهمون میده، دیگه بقیش با خودمونه که چکار کنیم باهاش.
@DevTwitter | <S.M.Sadegh Raeeskarami/>
❤21👍7👎1
در PHP؛ وقتی انعطافپذیری زبان میتونه دردسرساز بشه!
یکی از ویژگیهای جالب PHP، Type Juggling هست؛ یعنی PHP در بعضی شرایط خودش سعی میکنه type دادهها رو تبدیل کنه تا عملیات موردنظر انجام بشه.
در نگاه اول این رفتار خیلی راحت و کاربردیه، اما وقتی وارد پروژههای بزرگتر مثل Laravel میشیم، همین انعطافپذیری میتونه گاهی باعث رفتارهای غیرمنتظره بشه.
اینجاست که چیزهایی مثل استفادهی درست از type declaration، validation و مقایسهی strict (===) اهمیت پیدا میکنن.
البته strict_types قرار نیست تمام مشکلات Type Juggling رو در PHP حل کنه؛ اما باعث میشه در بخشهایی از کد، رفتار typeها قابلپیشبینیتر باشه.
به نظرم یکی از نکات مهم در کار با PHP اینه که:
هرچقدر پروژه بزرگتر میشه، شناختن رفتارهای خود زبان اهمیت بیشتری پیدا میکنه؛ چون خیلی از باگهای سخت، نه از منطق پیچیدهی business، بلکه از یک assumption اشتباه دربارهی typeها
به وجود میان.
زبان PHP ساده به نظر میرسه، ولی هرچقدر عمیقتر بشناسیمش، متوجه جزئیات بیشتری میشیم که روی کیفیت کدمون تأثیر میذاره.
@DevTwitter | <Amir Mohammad M./>
یکی از ویژگیهای جالب PHP، Type Juggling هست؛ یعنی PHP در بعضی شرایط خودش سعی میکنه type دادهها رو تبدیل کنه تا عملیات موردنظر انجام بشه.
در نگاه اول این رفتار خیلی راحت و کاربردیه، اما وقتی وارد پروژههای بزرگتر مثل Laravel میشیم، همین انعطافپذیری میتونه گاهی باعث رفتارهای غیرمنتظره بشه.
اینجاست که چیزهایی مثل استفادهی درست از type declaration، validation و مقایسهی strict (===) اهمیت پیدا میکنن.
البته strict_types قرار نیست تمام مشکلات Type Juggling رو در PHP حل کنه؛ اما باعث میشه در بخشهایی از کد، رفتار typeها قابلپیشبینیتر باشه.
به نظرم یکی از نکات مهم در کار با PHP اینه که:
هرچقدر پروژه بزرگتر میشه، شناختن رفتارهای خود زبان اهمیت بیشتری پیدا میکنه؛ چون خیلی از باگهای سخت، نه از منطق پیچیدهی business، بلکه از یک assumption اشتباه دربارهی typeها
به وجود میان.
زبان PHP ساده به نظر میرسه، ولی هرچقدر عمیقتر بشناسیمش، متوجه جزئیات بیشتری میشیم که روی کیفیت کدمون تأثیر میذاره.
@DevTwitter | <Amir Mohammad M./>
👍28🍌10❤7
تجربه ۲ روز کدنویسی فشرده با مدل Qwen 3.8-27B روی RTX 3090 (24GB)
کانفیگ و ستاپ تست:
پنجره کانتکست: 128K
سطح استدلال (Reasoning Effort): xHigh
ایجنت / پلتفرم: Kilo Code
دقت مدل در اجرای درست تسکها با همان پرامپت اول فوقالعاده بالا رفته است. چرخههای فرسایشی دیباگ و اصلاحیههای پیاپی به حداقل رسیده و بیشتر کدها از همان ابتدا تمیز و آماده اجرا تحویل داده میشوند.
زنجیره تفکر و خروجیهای مدل بسیار متمرکزتر شده و تولید توکنهای زائد به حداقل رسیده است. این ساختار تمیز باعث میشود پنجره کانتکست ۱۲۸ هزارتایی دیرتر اشباع شود و نشستهای طولانی پایداری بیشتری داشته باشند.
میانگین سرعت خروجی (Decode Throughput) روی تسکهای سنگین کدنویسی حدود 45 t/s ثبت شد. افت سرعت نسبت به نسلهای قبل کاملاً محسوس است (که حاصل سربار تفکر عمیقتر و پارامترهای فعال است)، اما کیفیت بالای خروجی این افت سرعت را جبران میکند.
یکپارچگی مدل با ابزارهای خارجی عالی است؛ اتصال بدون نقص به Playwright برای بررسی خروجی دام، گرفتن اسکرینشات از UI، ارزیابی رندرینگ لایو و دیباگ خودکار بر اساس خطاهای رانتایم.
در سطح استدلال xHigh، مدل گاهی دچار Over-thinking میشود و زمان زیادی را صرف زنجیره تفکر (CoT) میکند، اما نکته مثبت این است که وارد لوپ بینهایت نمیشود و همیشه به یک خروجی نهایی و قابلاتکا میرسد.
معماری کامپوننتها، مدیریت استیت و خروجی UI بهطرز چشمگیری ارتقا پیدا کرده و در ساختارهای پیچیده فرانت، سطحی از پختگی مشابه مدلهای سری Claude Sonnet را نشان میدهد.
در پروژههای ماژولار بزرگ، پایداری مدل حتی در سشنهای پیوسته با حجم تجمعی چند میلیون توکن حفظ شد. زمان پاسخدهی از ۱ تا ۲ دقیقه برای باگفیکسهای سریع تا حدود ۴۰ دقیقه برای پیادهسازی کامل یک فیچر فولاستک (UI + منطق بکاند) متغیر بود.
کاری که پیش از این با مدلهای لوکال قدیمیتر نزدیک به ۲ هفته زمان میبرد، به لطف دقت One-Shot این مدل در ۲ روز جمع شد. برای یک ستاپ لوکال روی تککارت ۲۴ گیگابایتی، جهش عملکردی کمنظیری است.
@DevTwitter | <کدنویس اسطورهای/>
کانفیگ و ستاپ تست:
پنجره کانتکست: 128K
سطح استدلال (Reasoning Effort): xHigh
ایجنت / پلتفرم: Kilo Code
دقت مدل در اجرای درست تسکها با همان پرامپت اول فوقالعاده بالا رفته است. چرخههای فرسایشی دیباگ و اصلاحیههای پیاپی به حداقل رسیده و بیشتر کدها از همان ابتدا تمیز و آماده اجرا تحویل داده میشوند.
زنجیره تفکر و خروجیهای مدل بسیار متمرکزتر شده و تولید توکنهای زائد به حداقل رسیده است. این ساختار تمیز باعث میشود پنجره کانتکست ۱۲۸ هزارتایی دیرتر اشباع شود و نشستهای طولانی پایداری بیشتری داشته باشند.
میانگین سرعت خروجی (Decode Throughput) روی تسکهای سنگین کدنویسی حدود 45 t/s ثبت شد. افت سرعت نسبت به نسلهای قبل کاملاً محسوس است (که حاصل سربار تفکر عمیقتر و پارامترهای فعال است)، اما کیفیت بالای خروجی این افت سرعت را جبران میکند.
یکپارچگی مدل با ابزارهای خارجی عالی است؛ اتصال بدون نقص به Playwright برای بررسی خروجی دام، گرفتن اسکرینشات از UI، ارزیابی رندرینگ لایو و دیباگ خودکار بر اساس خطاهای رانتایم.
در سطح استدلال xHigh، مدل گاهی دچار Over-thinking میشود و زمان زیادی را صرف زنجیره تفکر (CoT) میکند، اما نکته مثبت این است که وارد لوپ بینهایت نمیشود و همیشه به یک خروجی نهایی و قابلاتکا میرسد.
معماری کامپوننتها، مدیریت استیت و خروجی UI بهطرز چشمگیری ارتقا پیدا کرده و در ساختارهای پیچیده فرانت، سطحی از پختگی مشابه مدلهای سری Claude Sonnet را نشان میدهد.
در پروژههای ماژولار بزرگ، پایداری مدل حتی در سشنهای پیوسته با حجم تجمعی چند میلیون توکن حفظ شد. زمان پاسخدهی از ۱ تا ۲ دقیقه برای باگفیکسهای سریع تا حدود ۴۰ دقیقه برای پیادهسازی کامل یک فیچر فولاستک (UI + منطق بکاند) متغیر بود.
کاری که پیش از این با مدلهای لوکال قدیمیتر نزدیک به ۲ هفته زمان میبرد، به لطف دقت One-Shot این مدل در ۲ روز جمع شد. برای یک ستاپ لوکال روی تککارت ۲۴ گیگابایتی، جهش عملکردی کمنظیری است.
@DevTwitter | <کدنویس اسطورهای/>
❤55🍌12💔1
ایکس اومده الگوریتم بخش for you رو متنباز کرده، یه Agent انداختم تو کل سورس که فایلبهفایل بگرده و بفهمه که چطوری کار میکنه.
نتیجهاش خیلی جالب بود؛ مخصوصاً وزن Reply، Share، Follow، Report و اینکه اصلاً یک پست چطور وارد For You میشه.
چیزهایی که پیدا کردم رو توی ویرگول نوشتم
https://virgool.io/@mrbug_ir/x-algorithm-open-source-lrmu9j4z7fz2
@DevTwitter | <Alireza Rezaie/>
نتیجهاش خیلی جالب بود؛ مخصوصاً وزن Reply، Share، Follow، Report و اینکه اصلاً یک پست چطور وارد For You میشه.
چیزهایی که پیدا کردم رو توی ویرگول نوشتم
https://virgool.io/@mrbug_ir/x-algorithm-open-source-lrmu9j4z7fz2
@DevTwitter | <Alireza Rezaie/>
🔥47👍9👎6
تولدت مبارک پیرمرد قابل اعتماد دنیای لینوکس!
از مرداد ۱۳۷۲ تا امروز Stable مثل همیشه
@DevTwitter | <MehrdadLinux/>
از مرداد ۱۳۷۲ تا امروز Stable مثل همیشه
@DevTwitter | <MehrdadLinux/>
❤106🔥12👍1
یک دورهی کامل Git از صفر تا حرفهای، شامل ۳۰ بخش:
از مفاهیم پایه (staging area، commit، branch) شروع میشه، به merge/rebase/conflict میرسه، ابزارهائی مثل stash، cherry-pick، reflog، bisect، submodules و hooks رو پوشش میده، بعد وارد بخش حرفهای میشه و..
https://github.com/AsaEdgerunner/git-course-fa
@DevTwitter | <Asa/>
از مفاهیم پایه (staging area، commit، branch) شروع میشه، به merge/rebase/conflict میرسه، ابزارهائی مثل stash، cherry-pick، reflog، bisect، submodules و hooks رو پوشش میده، بعد وارد بخش حرفهای میشه و..
https://github.com/AsaEdgerunner/git-course-fa
@DevTwitter | <Asa/>
🍌28❤20👍2
یه ابزار ساختم که خیلی وقت بود اذیتم میکرد نبودنش :))
ابزار Schemat میذاریش رو ریپوت، دیاگرام ERت رو زنده نشونت میده.
دیتای Prisma، SQL، Drizzle، TypeORM و چندتای دیگه رو میخونه.
همهچی لوکال، بدون اکانت، بدون کلاود.
اوپنسورسه:
https://github.com/alirezahamid/schemat
@DevTwitter | <Alireza.js/>
ابزار Schemat میذاریش رو ریپوت، دیاگرام ERت رو زنده نشونت میده.
دیتای Prisma، SQL، Drizzle، TypeORM و چندتای دیگه رو میخونه.
همهچی لوکال، بدون اکانت، بدون کلاود.
اوپنسورسه:
https://github.com/alirezahamid/schemat
@DevTwitter | <Alireza.js/>
🍌18❤13👍2
امروز Filament File Explorer v0.5.1 رو روی Packagist منتشر کردم.
یک مدیر فایل برای پنلهای Filament — پوشه، آپلود، چند وضعیت برای نمایش، و Form Picker — ساختهشده روی Spatie Media Library، Livewire و Tailwindcss.
میخواستم همون حس کار با finder و file explorer دسکتاپ رو داخل ادمین Filament داشته باشم.
چی توی v0.5.1 هست؟
- رابط Finer — درخت سایدبار، breadcrumbs، عقب / جلو، تولبار ریسپانسیو
- نماها — Grid، List، Table، Details + پنجره Get Info
- عملیات — آپلود Drag-and-drop، Cut / Copy / Paste، انتخاب چندتایی، دانلود Zip
- امکانات Filament — traitی HasFileExplorer، صفحه جدول فایلها، Form Picker، generator stub
- چندزبانه — ۱۵ زبان
- سازگار با Filament v4 و v5 · Laravel 11 / 12 / 13 · PHP 8.2+
نصب
composer require ardavan/filament-file-explorer:"^0.5" -W
Docs
https://ardavanshamroshan.github.io/filament-file-explorer/
Packagist
https://packagist.org/packages/ardavan/filament-file-explorer
GitHub
https://github.com/ardavanshamroshan/filament-file-explorer
پروژه هنوز اول راهشه — و مطمئنم با کمک جامعهی Filament و Laravel میتونه خیلی بهتر بشه.
@DevTwitter | <Ardavan ShamRoshan/>
یک مدیر فایل برای پنلهای Filament — پوشه، آپلود، چند وضعیت برای نمایش، و Form Picker — ساختهشده روی Spatie Media Library، Livewire و Tailwindcss.
میخواستم همون حس کار با finder و file explorer دسکتاپ رو داخل ادمین Filament داشته باشم.
چی توی v0.5.1 هست؟
- رابط Finer — درخت سایدبار، breadcrumbs، عقب / جلو، تولبار ریسپانسیو
- نماها — Grid، List، Table، Details + پنجره Get Info
- عملیات — آپلود Drag-and-drop، Cut / Copy / Paste، انتخاب چندتایی، دانلود Zip
- امکانات Filament — traitی HasFileExplorer، صفحه جدول فایلها، Form Picker، generator stub
- چندزبانه — ۱۵ زبان
- سازگار با Filament v4 و v5 · Laravel 11 / 12 / 13 · PHP 8.2+
نصب
composer require ardavan/filament-file-explorer:"^0.5" -W
Docs
https://ardavanshamroshan.github.io/filament-file-explorer/
Packagist
https://packagist.org/packages/ardavan/filament-file-explorer
GitHub
https://github.com/ardavanshamroshan/filament-file-explorer
پروژه هنوز اول راهشه — و مطمئنم با کمک جامعهی Filament و Laravel میتونه خیلی بهتر بشه.
@DevTwitter | <Ardavan ShamRoshan/>
🔥9👍2🍌2
Forwarded from DevTwitter Ads.
وقت نداری برای هر موضوع امنیتی ۲۰ صفحه گزارش بخونی؟ حق داری!
«نوشدارو» اصل ماجرا رو میگه: چه اتفاقی افتاده، چرا مهمه و چه چیزی باید ازش یاد بگیریم؛ بدون پیچیده کردن چیزی که میشه ساده گفت.
برای دولوپرهایی که میخوان توی «حریم شخصی»، «امنیت» و «آشنایی با آخرین خطرات» یک قدم جلوتر باشن.
همین الان دنبال کنید:
@NooshDaroo_web
@NooshDaroo_web
«نوشدارو» اصل ماجرا رو میگه: چه اتفاقی افتاده، چرا مهمه و چه چیزی باید ازش یاد بگیریم؛ بدون پیچیده کردن چیزی که میشه ساده گفت.
برای دولوپرهایی که میخوان توی «حریم شخصی»، «امنیت» و «آشنایی با آخرین خطرات» یک قدم جلوتر باشن.
همین الان دنبال کنید:
@NooshDaroo_web
@NooshDaroo_web
🍌15❤6👍2
#Dart
یه سؤال ساده شروعش کرد: چرا هر درگاه پرداخت ایرانی باید یه SDK کاملاً جدا داشته باشه؟
زرینپال یه شکل جواب میده، زیبال یه شکل دیگه، پیپینگ اسم فیلدهاش فرق داره، وندار احراز هویتش با بقیه یکی نیست... نتیجه؟ هر بار که بخوای درگاه عوض کنی یا دومی رو اضافه کنی، عملاً داری از صفر مینویسی.
برای همین pardakht رو ساختم — یه پکیج Dart که ۷ درگاه پرداخت ایرانی رو پشت یه interface واحد میبره:
زرینپال، زیبال، آیدیپی، پیپینگ، پی.آیآر، وندار، ایراندرگاه
چیزی که برام مهم بود، نه فقط «کار کنه» بلکه «قابل اعتماد باشه»:
نوع داده Money که واحد پول (ریال/تومان) رو صریح نگه میداره — دقیقاً همون جایی که خطای «ده برابر شدن قیمت» از اونجا شروع میشه.
وریفای تکراری = موفقیت، نه شکست. خیلی از مرچنتها پرداخت واقعی رو استرداد میزنن چون verify دوم رو اشتباه fail میخونن. اینجا این حالت یه state جدا و صریحه.
بدون وابستگی به Flutter — یعنی همون کد روی بکاند هم اجرا میشه، جایی که verify واقعاً باید انجام بشه (نه سمت کلاینت، که هرکسی میتونه callback رو جعل کنه).
هر درگاه یه سند مشخصات جداگانه داره: هر claim با URL منبع و تاریخ تأیید. هیچ فیلدی حدسی نیست.
۷۹۸ تست، ۱۰۰٪ پوشش خط، صفر warning.
کد، مستندات و همهچیز باز و در دسترس:
https://pub.dev/packages/pardakht
https://github.com/naeimlotfali/pardakht
@DevTwitter | <Naeim Lotfali/>
یه سؤال ساده شروعش کرد: چرا هر درگاه پرداخت ایرانی باید یه SDK کاملاً جدا داشته باشه؟
زرینپال یه شکل جواب میده، زیبال یه شکل دیگه، پیپینگ اسم فیلدهاش فرق داره، وندار احراز هویتش با بقیه یکی نیست... نتیجه؟ هر بار که بخوای درگاه عوض کنی یا دومی رو اضافه کنی، عملاً داری از صفر مینویسی.
برای همین pardakht رو ساختم — یه پکیج Dart که ۷ درگاه پرداخت ایرانی رو پشت یه interface واحد میبره:
زرینپال، زیبال، آیدیپی، پیپینگ، پی.آیآر، وندار، ایراندرگاه
چیزی که برام مهم بود، نه فقط «کار کنه» بلکه «قابل اعتماد باشه»:
نوع داده Money که واحد پول (ریال/تومان) رو صریح نگه میداره — دقیقاً همون جایی که خطای «ده برابر شدن قیمت» از اونجا شروع میشه.
وریفای تکراری = موفقیت، نه شکست. خیلی از مرچنتها پرداخت واقعی رو استرداد میزنن چون verify دوم رو اشتباه fail میخونن. اینجا این حالت یه state جدا و صریحه.
بدون وابستگی به Flutter — یعنی همون کد روی بکاند هم اجرا میشه، جایی که verify واقعاً باید انجام بشه (نه سمت کلاینت، که هرکسی میتونه callback رو جعل کنه).
هر درگاه یه سند مشخصات جداگانه داره: هر claim با URL منبع و تاریخ تأیید. هیچ فیلدی حدسی نیست.
۷۹۸ تست، ۱۰۰٪ پوشش خط، صفر warning.
کد، مستندات و همهچیز باز و در دسترس:
https://pub.dev/packages/pardakht
https://github.com/naeimlotfali/pardakht
@DevTwitter | <Naeim Lotfali/>
👍52🍌9🔥8
مخزن عمومی دادههای گنجور:
https://github.com/ganjoor/ganjoor-data
توضیحات بیشتر:
https://blog.ganjoor.net/1405/05/25/ganjoor-public-data/
* گنجور بزرگترین سایت شعر ایرانه که دیتاش به صورت پابلیک در دسترسه
@DevTwitter
https://github.com/ganjoor/ganjoor-data
توضیحات بیشتر:
https://blog.ganjoor.net/1405/05/25/ganjoor-public-data/
* گنجور بزرگترین سایت شعر ایرانه که دیتاش به صورت پابلیک در دسترسه
@DevTwitter
🔥56❤11🍌3
سلام
بعد از سال ها کار کردن روی پروژه های فلاتر یک معماری برای ساختن اپلیکیشن های مایکرو سرویسی فلاتر ایجاد کردم . این معماری حاصل تلاش چند ساله منه امیدوارم خوشتون بیاد و اینکه اگه سوالی داشتین یا مشکلی دیدن تو گیت هاب برای من issue بزنید
https://github.com/Mahfa/CrusaderArch/tree/master
@DevTwitter | <Mohsen Fallahi/>
بعد از سال ها کار کردن روی پروژه های فلاتر یک معماری برای ساختن اپلیکیشن های مایکرو سرویسی فلاتر ایجاد کردم . این معماری حاصل تلاش چند ساله منه امیدوارم خوشتون بیاد و اینکه اگه سوالی داشتین یا مشکلی دیدن تو گیت هاب برای من issue بزنید
https://github.com/Mahfa/CrusaderArch/tree/master
@DevTwitter | <Mohsen Fallahi/>
👍24❤7💔2
Forwarded from DevTwitter Ads.
محبوبترین تکنولوژی، همیشه بهترین انتخاب نیست!
انتخاب اشتباه تکنولوژی یا معماری میتونه هزینه توسعه رو بالا ببره و مسیر پروژه رو پیچیدهتر کنه.
در وبینار «از مسئله تا انتخاب تکنولوژی در توسعه نرمافزار»، سامان هاشمی و هژار آزیز از تیم فنی همکاران سیستم، با تجربه واقعی توسعه «راهکاران آیند» نشون میدن چطور از یک نیاز کسبوکار به تصمیم فنی، انتخاب تکنولوژی و معماری مناسب میرسن.
📅 ۲۹ مرداد و ۵ شهریور، ساعت ۱۱
🎟 شرکت در رویداد رایگانه
💼 امکان ارسال رزومه برای فرصتهای شغلی همکاران سیستم
اطلاعات بیشتر و ثبتنام:
🔗 quera.org/r/eah3n
انتخاب اشتباه تکنولوژی یا معماری میتونه هزینه توسعه رو بالا ببره و مسیر پروژه رو پیچیدهتر کنه.
در وبینار «از مسئله تا انتخاب تکنولوژی در توسعه نرمافزار»، سامان هاشمی و هژار آزیز از تیم فنی همکاران سیستم، با تجربه واقعی توسعه «راهکاران آیند» نشون میدن چطور از یک نیاز کسبوکار به تصمیم فنی، انتخاب تکنولوژی و معماری مناسب میرسن.
📅 ۲۹ مرداد و ۵ شهریور، ساعت ۱۱
🎟 شرکت در رویداد رایگانه
💼 امکان ارسال رزومه برای فرصتهای شغلی همکاران سیستم
اطلاعات بیشتر و ثبتنام:
🔗 quera.org/r/eah3n
👍8👎3❤1
یه بار سر پروژهای که ساختار دیتابیسش پیچیده شده بود، مجبور شدم برم تو دیبی کلاینت و دستی جدولها و فارینکیها رو دنبال کنم تا بفهمم کدوم جدول به کدوم وصله. کار خستهکنندهای بود، مخصوصاً وقتی چند نفر روی پروژه کار میکنن و شِمای دیتابیس هی تغییر میکنه.
ابزار Laravel Truss دقیقا همین مشکل رو حل میکنه. یه پکیج لاراولیه که شِمای دیتابیس شما رو اسکن میکنه و بهصورت یه دیاگرام ER قابل اسکرول و زوم، مستقیم داخل اپلیکیشن نمایش میده؛ دیگه لازم نیست بری سراغ ابزار جداگونه.
نکتهی مهمش امنیته: فقط ساختار (جدولها، ستونها، کلیدها، ایندکسها) رو میخونه و هیچوقت به دادههای واقعی جدولها دسترسی نداره یا نمایششون نمیده.
قابلیتهای جالبش:
- حالت Focus mode برای دیدن یه جدول و همسایههای فارینکیاش
- فیلتر بر اساس اسم جدول و سوییچ بین تایپ نیتیو و لیبلهای لاراولی
- کار آفلاین و بدون نیاز به CDN
برای هر Laravel developer که با دیتابیسهای نسبتاً پیچیده کار میکنه یا تازه وارد یه پروژهی قدیمی شده و میخواد سریع ساختارش رو بفهمه، مفیده.
https://github.com/albertoarena/laravel-truss
@DevTwitter | <Ladoya/>
ابزار Laravel Truss دقیقا همین مشکل رو حل میکنه. یه پکیج لاراولیه که شِمای دیتابیس شما رو اسکن میکنه و بهصورت یه دیاگرام ER قابل اسکرول و زوم، مستقیم داخل اپلیکیشن نمایش میده؛ دیگه لازم نیست بری سراغ ابزار جداگونه.
نکتهی مهمش امنیته: فقط ساختار (جدولها، ستونها، کلیدها، ایندکسها) رو میخونه و هیچوقت به دادههای واقعی جدولها دسترسی نداره یا نمایششون نمیده.
قابلیتهای جالبش:
- حالت Focus mode برای دیدن یه جدول و همسایههای فارینکیاش
- فیلتر بر اساس اسم جدول و سوییچ بین تایپ نیتیو و لیبلهای لاراولی
- کار آفلاین و بدون نیاز به CDN
برای هر Laravel developer که با دیتابیسهای نسبتاً پیچیده کار میکنه یا تازه وارد یه پروژهی قدیمی شده و میخواد سریع ساختارش رو بفهمه، مفیده.
https://github.com/albertoarena/laravel-truss
@DevTwitter | <Ladoya/>
❤20👎5👍3