پوریا یکی از خفن ترین دوستهای منه...دوره های خیلی خفنی میسازه و اینکه رایگان هم هست برای همیشه 😊چی بهتر از این ....
https://codehalic.ir/courses/nestjs-intermediate

من و دوستم یه کلون تلگرام با Next.js ساختیم!

گیت هاب: https://github.com/hamedakbarii/telegram-clone

اگه خوشتون اومد، حتما یه استار بدید.

@DevTwitter | <Unknown Talent | بچه برنامه نویس/>

🔶 ناسا به ‌طور رسمی اعلام کرد که از ۵ سپتامبر، شهروندان چینی حتی با ویزای معتبر ایالات متحده نیز از دسترسی به تأسیسات، شبکه ‌ها و برنامه ‌های این سازمان منع شده‌اند. این تصمیم به‌دلیل نگرانی‌های امنیتی و تشدید رقابت ‌های فضایی با چین اتخاذ شده است.

#خبر

@TheRaymondDev

برای کسایی که بیشتر از 8 ساعت پشت سیستم کد میزنن یه تجربه ای از اشک مصنوعی بگم؛

توی ایران چندین نوع اشک مصنوعی داریم چیز هایی که من توی بازار زیاد دیدم اشک های تک دوز آرتلاک و ارتیپیک و سینالونه، و یا ژل لیپوزیک و هیچ کدوم نسخه پزشک لازم ندارن.

از همشون استفاده کردم، آرتلاک مال شرکت بوش اند لمبه و خیلی خیلی معتبره، وقتی توی چشم ریخته می‌شه چشم راحتی بیشتری نسبت به آرتپیک و سینالون که ایرانیه داره ولی نتیجه زیاد تفاوتی نداره. هر ویالشون تا 24 ساعت قابل استفاده مجدده و هر 2 ساعت می‌تونید بریزید چشمتون.

اما لیپیوزیک که ژل هست ماندگاری بیشتری داره و حداکثر روزی 3 بار استفاده می‌شه و بیشتر برای خشکی شدید استفاده می‌شه اما اون تک ویال ها بیشتر برای خشکی خفیف تا متوسط استفاده می‌شه.


قیمت هاشون هم امروز چند تا گرفتم به این صورت بود :
آرتلاک دونه ای 7 تومن؛ آرتلاک ادونس دونه ای 30 تومن؛ آرتپیک 6 تومن؛ ژل لیپوزیک 330 تومن که برای 28 روز یا کمتر استفاده میشه. همچنین نسخه ادونس آرتلاک حتی میتونه خشکی های شدید هم جوابگو باشه و مواد نگهدارنده نداره و بی ضرر، اگه خشکی معمولی دارید بقیشون هم جوابه.


@Linuxor

🔶 در حال کار برای افزودن زبان فارسی و انگلیسی به پروژه تسک پایر هستم.

@TheRaymondDev

کلا توی نرم افزار ما چیزی به اسم حذف نداریم، توی دیتابیس یه is_deleted می‌زاریم و دیگه به کاربر نشونش نمی‌دیم؛ ولی این چک کردن هی is_deleted توی کد های مختلف سخت می‌شه یه راه حل دیگه ساخت جدول trash هست که یه ستون رشته ای به اسم table_name داره و یه ستون دیتایی به اسم table_data داره درسرش کمتره؛ می‌تونید تستش کنید.


@Linuxor

مولانا | دیوان شمس | رباعیات | رباعی شمارهٔ ۷۷۶

قومی به خرابات تو اندر بندند
رندی چند و کس نداند چندند
هشیاری و آگهی ز کس نپسندند
بر نیک و بد خلق جهان میخندند

#مولانا | گنجور
📍@iipoem

اینجارو ببینید پر سیستم دیزاینه، هم ‌می‌تونید توش کامپوننت های آماده پیدا کنید هم می‌تونید Voice & Tone پیدا کنید مثلا پیام خطا یا دستورالعملی می‌نویسی، چه لحن و ادبیاتی داشته باش و فایل های آماده فیگما و فتوشاپ و کلی سورس کد دیگه

https://github.com/alexpate/awesome-design-systems

@DevTwitter | <Nimo/>

توی هفته گذشته این گروه جلسه‌ی اول خودش رو برگزار کرد. تجربه‌ی خیلی خوبی بود. بعد از مدت‌ها دوباره فرصتی پیش اومد تا در کنار دوستان عزیز و علاقه‌مند باشم و ازشون یاد بگیرم. خواستم بهتون بگم که قرار شد آخر هفته، مجدد جلسه‌ی اول رو تکرار کنیم تا دوستانی که به هر دلیلی نتونسته بودند خودشون رو برسونن، یک فرصت دیگه‌ای باشه تا بتونن به جمع ما بپیوندند. در ادامه جا داره به چند نکته‌ اشاره کنم.

راستش خیلی مهمه که موقع شرکت در جلسات مقالات رو تا یک حدی بررسی کرده باشید. حقیقتا زمان جلسه محدوده و اگر قرار باشه گرداننده‌ی جلسه مقالات رو درس بده وقت بسیار کم میاریم.

نکته‌ی دیگه این هستش که تصمیم گرفتیم یک git repo درست کنیم جهت قرار دادن منابع و مطالبی که توی reading group بهشون بر میخوریم. از بین دوستان، یاسمین داوطلب شد که مدیریت ریپو رو دست بگیره. توی این repo علاوه‌ بر مقالات اصلی، مقالات و کتب جانی هم قرار میدیم. یک روحیه‌ی خیلی قشنگی که بچه‌ها دارن، این هستش که بسیار مشتاقن تا کارهای عملی و پیاده‌سازی هم انجام بدیم. از این رو برای هر مبحثی که می‌خونیم، هر کسی توی این ریپو پروژه‌های عملی مربوط به اون حوزه‌ی خاص که state of the art هستند رو قرار میده. علاوه بر اون تصمیم گرفتیم که پروژه‌های کوچکی هم تعریف کنیم که خودمون هم دست بکار بشیم.

برای مثال مطالب هفته‌ی اول دوره مربوط بود به Hoare Logic و زبان GCL بود. اگر به ریپو مراجعه کنید، علاوه بر مقالات و کتب جانبی، لیستی از پروژه ها مثل Dafny, Boogie, Why3 و KeY رو مشاهده میکنید که همگی زبان‌های برنامه‌نویسی و verification هستند که Hoare Logic رو ساپورت میکنن و همه‌شون Deductive Verifier دارند برای اثبات درستی برنامه‌ها.

علاوه‌بر اینا ۳ تا پروژه هم تعریف شده که به زودی یکی از این‌ها رو استارت میزنیم و ببینیم تا کجا می‌تونیم پیش ببریمش.

نکته آخر هم اینکه تصمیم گرفتیم موقعی که این مقالات رو می‌خونیم، هر چیزی که ازش فهمیدیم رو در قالب یک نوت به شکل خلاصه بنویسیم و توی ریپو push کنیم. به همین منظور توصیه کردیم که دوستان نوت‌هاشون رو با latex بنویسن و سورسش رو push کنن. بنده هم سعی می‌کنم نوت‌های دوستان رو بخونم و ادیت کنم و در نهایت یک نوت ادغام شده از هر مطلب داشته باشیم.

خلاصه که آقا همش Fun و عشق و صفاست.

توی معماری سیستم یک اصطلاحی داریم به اسم؛
distributed monolithic
که خب یک anti-pattern هست برای معماری micro-service اول هفته با یک شرکتی برای مشاوره صحبت کردیم (کارشون رو قبول نکردم ولی یک قرارداد کوچک بستم برای اینکه بگم مشکل فعلی سیستم کجاس)

معماری سیستم مثلاً قرار بوده micro-service باشه؛ در نگاه اول هم هست و حتی از تمام ابزارهای لازم هم داره استفاده می‌شه اما به اشتباه.

کل سیستم رو امروز کنار هم چیدم و روی یک سرور بالا آوردم (بجای چندتا سرور) و تبدیلش کردم به multi app monolithic اولش خیلی ناراحت و نگران بودند که پرفورمنس خراب میشه و ازین حرفا ولی بعد توی تست‌ها دیدند که حداقل ۲ برابر سرعت پاسخ و تعداد درخواست‌هایی که هندل میشه بیشتره.

البته من مطمئن بودم که اینطوری می‌شه به سه دلیل :
۱- به وضوح anti pattern رو می‌دیدم
۲- تعداد درخواست‌های بین سرویس‌ها زیاد بود
۳- خیلی از زمان پروفایلنگ، برای درخواست بین سرویس‌ها هدر می‌رفت روی نتورک. (که خب حتی async هم نبود که حداقل cpu هدر نره)

این موضوع دلیلی شد؛ بیام چندتا تعریف اشتباه که دائم می‌شنوم رو انتقال بدم:

۱- توی ماکروسرویس هر سرویس باید دیتابیس جدا داشته باشه.

این تعریف درسته، اما تفسیر غلط ازش زیاده؛ مثلاً ۹۹٪ فکر می‌کنند این یعنی برای هر سرویس باید یک سرور Postgres جدا داشته باشند، نه لزوماً مفهوم این تعریف اینه که:
مثلاً سرویس auth شما نره دیتای سرویس payment رو بخونه حتی اگر جفتشون روی یک دیتابیس هستند (فقط دوتا تیبل جداشده) و برای گرفتن دیتای مورد نیازش به سرویس payment درخواست بده

۲- هر تابع، متد یا ... باید single responsibility داشته باشه.

بله درسته، این یکی از موارد مهم هست اما تفسیر اشتباه ازش زیاده، مثلاً:
فرض کنید سرویس payment بالا، بعد از اینکه پرداخت انجام شد باید به بخش انبارداری تیکت بزنیم که پرداخت موفق بوده موجودی رو کم کن، به بخش حسابداری بزنیم که فاکتور صادر شده پرداخت شد و مثلاً به بخش ارسال کالا هم بگیم چیو بسته‌بندی و ارسال کنه به چه آدرسی ...

اینو دیدم که میگم، به طرف میگم، خب عالی توابع اینکارها رو بذار یک‌جا داخل یک تابع و درخواست بده اگر مشکلی توی پرداخت پیش اومد همه باهم باید rollback بخوره (توجه به بحث قبل شما حق نداری، تیبل سرویس‌های دیگه رو دستکاری کنی)؛ برگشته می‌گه پس Single Responsiblity چی می‌شه ؟

یک ساعت داشتم براش توضیح میدم؛ که این تابع SRP رو رعایت می‌کنه چون تو فقط داری میگی من پول رو پرداخت کردم موفق بود یا نه.


۳- ماکروسرویس بهتره ...

نه چون یک چیزی سخت‌تر هست پیاده‌سازیش لزوماً بهتر نیست، بسیار بسیار پروژه دیدم که گفتم خب همه‌ی چیزایی که اینا لازم دارن اگر monolithic بود، هم سریعتر بود هم سرعت توسعه‌اش بیشتر بود هم نیاز به این همه دولوپر نداشت.


چندتا برداشت اشتباه دیگه هم بود که متأسفانه یادم نیست دیگه،‌ ولی تبدیل سیستم به یک monolithic واقعی توی این پروژه نتایج خیلی بهتری داشت.
حتی برای مرحله بعدی هم پیشنهاد کردم اول سراغ
Load balance
و بالا آوردن چندتا instance از همین monolithic برند، بعد برای تبدیل به micro-sercive از یکی که معماری رو واقعاً بلد هست کمک بگیرند نه کسی که پوشه پوشه کردن فایلای پایتونش رو فقط یاد گرفته.


نهایتاً؛ البته من می‌دونم خیلی از این برداشت‌های اشتباه از کجا میاد.
منابع ترجمه شده به فارسی.

ترجمه اشتباه لغوی یک کلمه، باعث میشه معنی یک جمله بطور کامل عوض بشه.

https://www.youtube.com/watch?v=DbhYpx70zTY

ویدیو جالبی بود در مورد سطح های متفاوت کاربرد LLM برای برنامه نویس های جونیور تا سنیور

آیا هوش مصنوعی جایگزین ما میشود؟ فعلا فقط جونیور ها

فاتحه رو باید خوند 😂

اخیراً برای ساخت پنل کاربری در یکی از پروژه‌هام از Filament استفاده کردم و تجربه متفاوتی بود.
برخلاف AdminLTE که نیاز به شخصی‌سازی سنگین دارن، Filament روی لاراول با چند خط کد یه پنل کامل بهم داد؛
مثلا با دستور make:filament-resource نه‌تنها CRUD مدل ساخته می‌شه، بلکه فرم‌ها، جدول‌ها، فیلترها و حتی bulk action ها رو به‌صورت پیش‌فرض برات می‌سازه.
چیزی که برای من جذاب بود، هماهنگی مستقیم Filament با Policies لاراول و همینطور پشتیبانی از Spatie Permission برای role/permission بود؛ یعنی می‌تونید به‌جای workaround، امنیت و سطح دسترسی رو طبق best practice خود لاراول پیاده کنید.
برای دولوپرهای جوونیور و میدلول، کار با Filament بهترین فرصت برای لمس معماری تمیز، درک بهتر authorization و ساخت سریع feature های واقعی توی پروژه‌های production هست.

@DevTwitter | <ehsan azizi/>

زک یادگاری، مدیرعامل ۱۸ ساله‌ای که ماهانه ۱٫۵ میلیون دلار درآمد دارد - زومیت
https://www.zoomit.ir/business/447742-cal-ai-app-featured/

نام‌بان جدید رو شاهد هستید.



@SohrabContents