Forwarded from Agora (Alireza Azadi)
پیچیدگی و نشانههای آن
___________
کتاب A Philosophy of Software Design نوشتهی John Ousterhout، میاد و سه نشانه (manifestation) از پیچیدگی در سیستم مطرح میکنه و اینجا میخوام این سه مورد رو باهم مرور کنیم:
- Change Amplification
یک تغییر ساده [در یک عملکرد کلی]، نیازمند تغییر در قسمتهای مختلفه. دم دستی ترین مثال ممکن که احتمالا در ذهنتون بیدرنگ نشست، استفاده از یک ثابته (مثل کد رنگ) که در تمام تابعها داره بهکار برده میشه و هر جا هم یک اسمی داره و ما قراره اون رو عوض کنیم. حالا یک تغییر سادهی ما amplify شد و از یکی شد ۱۰۰ تا (مشابه write amplification در دیتابیسها که گاهی یک رایت ساده، منجر به چسبیدن IO به سقف میشه).
- Cognitive Load
چقدر یک توسعهدهنده نیازه که [راجعبه سیستم] بدونه برای این که یک تسک رو به سرانجام برسونه. هرچقدر این «دونستن» بیشتر لازم باشه، به طبع نیازمنده تا زمان بیشتری رو صرف یادگیری کنه تا تسک مذکور رو انجام بده و این تعدد نیاز به دانستنها، ریسک به وجود اومدن باگ رو بیشترو بیشتر میکنه.
در این مورد، گریزی هم به ماجرای تعداد خطها میشه زد. بعضی طراحان سیستم فکر میکنند که تعداد خط کمتر منجر به کاهش پیچیدگی سیستم میشه.
شاید اینطور باشه که خوندن یک کلاس عریض و طویل بسیار وحشتناکه، اما به تجربه، هیچچیز ترسناک تر از خوندن کدهای کوتاهی نیست که سراسر پر شدند از trick و magicهایی که بدون دانش قبلی هیچ ایدهای نخواهیم داشت راجعبه این که این چند خط چطور کار میکنند.
کاهش تعداد خط با خیال کاهش پیچیدگی در نهایت میتونه به افزایش cognitive load منجر بشه و مارو از اون رویای شیرین، به وسط کابوس کدبیس پیچیده پرتاب کنه.
- Unknown unknowns
بدترین بین این سه اما، ناشناختههای ناشناختهست. به این معنی که ما ندونیم کدوم قسمت از کد باید تغییر کنه تا تسک ما انجام بشه.
در این حالت، برای ما روشن نخواهد بود که چه کار باید بکنیم، یا اونچه که قصد انجامشو داریم اصلا کاراست یا نه.
در نهایت سیستمی که پیادهسازی و طراحی مبرهنی داره، برای توسعه دهنده این امکان رو به وجود میاره که به سادگی بفهمه که کد فعلی چطور کار میکنه و بتونه به سرعت حدس بزنه چطور باید تغییرات مورد نظرش رو اعمال کنه و خیالش آسوده باشه از این که حدسی که زده صحیحه و قرار نیست تغییرات جدید در جایی که فکرش رو هم نمیکرد مشکلات جدیدی رو به وجود بیاره.
پینوشت:
- از عباس عزیز واقعا ممنونم بابت معرفی کتاب.
- کتاب رو دو روزه که شروع کردم و دلم میخواد تیکههاییش که برام جالبه یا ممکنه برای شما جالب باشه رو چه با نقل و قول مستقیم، چه غیرمستقیم اینجا هم بنویسم.
- بجز تعریف سیستم پیچیده که به شکل تعریف نشانههاش بالاتر ازش حرف زدیم و مختص به سیستمهای نرمافزاری بود، بد نیست یک گریزی بزنیم به کتاب Melanie Mitchell
با عنوان «سیری در نظریه پیچیدگی» (عنوان اصلی کتاب، Complexity: A Guided Tour) که اون هم کتابیه خوندنی و توصیهش میکنیم. در انتهای فصل اول کتاب، سیستم پیچیده رو به دو شکل تعریف میکنه:
و تعریف دوم:
که فکر میکنم تعریف دوم، بیشتر با شرح نشانههایی که از یک سیستم نرمافزاری دیدیم همسو باشه.
___________
کتاب A Philosophy of Software Design نوشتهی John Ousterhout، میاد و سه نشانه (manifestation) از پیچیدگی در سیستم مطرح میکنه و اینجا میخوام این سه مورد رو باهم مرور کنیم:
- Change Amplification
یک تغییر ساده [در یک عملکرد کلی]، نیازمند تغییر در قسمتهای مختلفه. دم دستی ترین مثال ممکن که احتمالا در ذهنتون بیدرنگ نشست، استفاده از یک ثابته (مثل کد رنگ) که در تمام تابعها داره بهکار برده میشه و هر جا هم یک اسمی داره و ما قراره اون رو عوض کنیم. حالا یک تغییر سادهی ما amplify شد و از یکی شد ۱۰۰ تا (مشابه write amplification در دیتابیسها که گاهی یک رایت ساده، منجر به چسبیدن IO به سقف میشه).
- Cognitive Load
چقدر یک توسعهدهنده نیازه که [راجعبه سیستم] بدونه برای این که یک تسک رو به سرانجام برسونه. هرچقدر این «دونستن» بیشتر لازم باشه، به طبع نیازمنده تا زمان بیشتری رو صرف یادگیری کنه تا تسک مذکور رو انجام بده و این تعدد نیاز به دانستنها، ریسک به وجود اومدن باگ رو بیشترو بیشتر میکنه.
در این مورد، گریزی هم به ماجرای تعداد خطها میشه زد. بعضی طراحان سیستم فکر میکنند که تعداد خط کمتر منجر به کاهش پیچیدگی سیستم میشه.
شاید اینطور باشه که خوندن یک کلاس عریض و طویل بسیار وحشتناکه، اما به تجربه، هیچچیز ترسناک تر از خوندن کدهای کوتاهی نیست که سراسر پر شدند از trick و magicهایی که بدون دانش قبلی هیچ ایدهای نخواهیم داشت راجعبه این که این چند خط چطور کار میکنند.
کاهش تعداد خط با خیال کاهش پیچیدگی در نهایت میتونه به افزایش cognitive load منجر بشه و مارو از اون رویای شیرین، به وسط کابوس کدبیس پیچیده پرتاب کنه.
- Unknown unknowns
بدترین بین این سه اما، ناشناختههای ناشناختهست. به این معنی که ما ندونیم کدوم قسمت از کد باید تغییر کنه تا تسک ما انجام بشه.
unknown unknown means that there is something you need to know, but there is no way for you to find out what it is, or even whether there is an issue.
در این حالت، برای ما روشن نخواهد بود که چه کار باید بکنیم، یا اونچه که قصد انجامشو داریم اصلا کاراست یا نه.
در نهایت سیستمی که پیادهسازی و طراحی مبرهنی داره، برای توسعه دهنده این امکان رو به وجود میاره که به سادگی بفهمه که کد فعلی چطور کار میکنه و بتونه به سرعت حدس بزنه چطور باید تغییرات مورد نظرش رو اعمال کنه و خیالش آسوده باشه از این که حدسی که زده صحیحه و قرار نیست تغییرات جدید در جایی که فکرش رو هم نمیکرد مشکلات جدیدی رو به وجود بیاره.
پینوشت:
- از عباس عزیز واقعا ممنونم بابت معرفی کتاب.
- کتاب رو دو روزه که شروع کردم و دلم میخواد تیکههاییش که برام جالبه یا ممکنه برای شما جالب باشه رو چه با نقل و قول مستقیم، چه غیرمستقیم اینجا هم بنویسم.
- بجز تعریف سیستم پیچیده که به شکل تعریف نشانههاش بالاتر ازش حرف زدیم و مختص به سیستمهای نرمافزاری بود، بد نیست یک گریزی بزنیم به کتاب Melanie Mitchell
با عنوان «سیری در نظریه پیچیدگی» (عنوان اصلی کتاب، Complexity: A Guided Tour) که اون هم کتابیه خوندنی و توصیهش میکنیم. در انتهای فصل اول کتاب، سیستم پیچیده رو به دو شکل تعریف میکنه:
سیستمی که شبکهٔ بزرگ اجزای آن که فاقد کنترل مرکزی هستند و مطابق با قواعد سادهای عمل میکنند، موجب پدیداد شدن رفتار پیچیدهٔ جمعی، پردازش اطلاعات پیشرفته، و انطباق از راه یادگیری یا تکامل میشود.
و تعریف دوم:
سیستمی که رفتارهای نابدیهی (nontrival) و نوظهور و خود-سازمان را بهنمایش میگذارد.
که فکر میکنم تعریف دوم، بیشتر با شرح نشانههایی که از یک سیستم نرمافزاری دیدیم همسو باشه.
Forwarded from Agora (Alireza Azadi)
یک حدس بیخودی بزنم در بارهی این که چرا اینطوره.
ماجرا اینه که در صفحهی دیجیتال، عادت کردیم به محتوای کوتاه و مختصر و این در رابطه با کاغذ فیزیکی صادق نیست. همین عادت باعث میشه زودتر حواسمون پرت بشه و درنتیجه، یادگیری هم کاهش پیدا کنه.
این که گفتم بیخوده چون حدسه و صرفاً بدرد فرضیهپردازی میخوره. اما چیزی که بیخود نیست اینه که تجربهی شخصی من هم همیشه همین بود. وسواسی دارم که هرکتاب یا محتوای خوبی رو که بخوام بخونم و واقعا بخوام که تو ذهنم بمونه دوست دارم نسخهی فیزیکش رو تهیه کنم. اما خب، از بد حادثه، اینجا برای یک کتاب زپرتی صد و چند صفحهای، باید حداقل ۳۰-۴۰ یورویی خرج کنم چه برسه به کتابهای گردن کلفتتر و این باعث میشه که بوسهای به کلهی کچل آقای ادام گرنت بزنم وحرفش رو بریزم دور و دست libgen و رفقا رو به گرمی بفشارم و epub ها رو دونه دونه دانلود کنم.
ماجرا اینه که در صفحهی دیجیتال، عادت کردیم به محتوای کوتاه و مختصر و این در رابطه با کاغذ فیزیکی صادق نیست. همین عادت باعث میشه زودتر حواسمون پرت بشه و درنتیجه، یادگیری هم کاهش پیدا کنه.
این که گفتم بیخوده چون حدسه و صرفاً بدرد فرضیهپردازی میخوره. اما چیزی که بیخود نیست اینه که تجربهی شخصی من هم همیشه همین بود. وسواسی دارم که هرکتاب یا محتوای خوبی رو که بخوام بخونم و واقعا بخوام که تو ذهنم بمونه دوست دارم نسخهی فیزیکش رو تهیه کنم. اما خب، از بد حادثه، اینجا برای یک کتاب زپرتی صد و چند صفحهای، باید حداقل ۳۰-۴۰ یورویی خرج کنم چه برسه به کتابهای گردن کلفتتر و این باعث میشه که بوسهای به کلهی کچل آقای ادام گرنت بزنم وحرفش رو بریزم دور و دست libgen و رفقا رو به گرمی بفشارم و epub ها رو دونه دونه دانلود کنم.
Forwarded from DevTwitter | توییت برنامه نویسی
نسخهٔ ۳ دیپسیک که اخیراً منتشر شده، claude 3.5 sonnet رو پشت سر گذاشته. اینجا میتونید رایگان ازش استفاده کنید. امکانِ جستجو در اینترنت هم جدیداً اضافه کرده. دیگه وقتشه جدی ازش استفاده کنیم.
chat.deepseek.com
@DevTwitter | <Ayub Kokabi/>
chat.deepseek.com
@DevTwitter | <Ayub Kokabi/>
Forwarded from LearnPOV | لرن پی او وی
برای اینکه بفهمید چند خط کد توی ریپازیتوری گیت شما زده شده میتونید از دستور زیر استفاده کنید، نتیجش میتونه واقعا جالب باشه 🔥
دستور زیر هم لیست تمامی فایلهای ریپو رو به همراه تعداد خط کد هر کدوم لیست میکنه و در نهایت هم جمع کلشون رو نشون میده.
اگر زدید به همراه زبان/فریمورک پروژتون بفرستید ببینیم پروژه کی کداش بیشتره 📟
🚀 @coolycode
git ls-files | xargs wc -l | tail -n 1
دستور زیر هم لیست تمامی فایلهای ریپو رو به همراه تعداد خط کد هر کدوم لیست میکنه و در نهایت هم جمع کلشون رو نشون میده.
bash git ls-files | xargs wc -l
اگر زدید به همراه زبان/فریمورک پروژتون بفرستید ببینیم پروژه کی کداش بیشتره 📟
#git | #tricks
Forwarded from CleverDevs (Mammad)
Forwarded from Linuxor ?
اگه یه ماژول فقط مسئول محاسبه تخفیفها باشه (مثلا کلاس DiscountCalculator)، این ماژول یه ماژول High Cohesion هستش و خیلی خوبه باعث فهم بهتر کد و قابلیت نگهداری بالاتریه.
اگه یه ماژول وظایف مختلفی مثل محاسبه تخفیف، چاپ فاکتور و مدیریت مشتری رو انجام بده، انسجامش پایینه و میتونه باعث پیچیدگی و مشکلات در نگهداری شه.
@Linuxor
اگه یه ماژول وظایف مختلفی مثل محاسبه تخفیف، چاپ فاکتور و مدیریت مشتری رو انجام بده، انسجامش پایینه و میتونه باعث پیچیدگی و مشکلات در نگهداری شه.
@Linuxor
Forwarded from LearnPOV | لرن پی او وی
برای اینکه بفهمید چند خط کد توی ریپازیتوری گیت شما زده شده میتونید از دستور زیر استفاده کنید، نتیجش میتونه واقعا جالب باشه 🔥
دستور زیر هم لیست تمامی فایلهای ریپو رو به همراه تعداد خط کد هر کدوم لیست میکنه و در نهایت هم جمع کلشون رو نشون میده.
🚀 @coolycode
git ls-files | xargs wc -l | tail -n 1
دستور زیر هم لیست تمامی فایلهای ریپو رو به همراه تعداد خط کد هر کدوم لیست میکنه و در نهایت هم جمع کلشون رو نشون میده.
bash git ls-files | xargs wc -l
#git | #tricks
Forwarded from Go Casts 🚀
دو برنامه نویس کهنه کار و خفن ۲۵ سال پیش یه کتاب جمع و جور و خوب نوشتن که کلی نکته کوچیک و مفید در مورد practiceهای برنامه نویسی داره.
مثلا در فصل اول برای style همین یک پاراگراف کلی نکته داره
اولا اینکه style یه common sense هست، پس براش دنبال استاندارد و قانون نگردید.
کد باید واضح و ساده باشه و نباید clever tricks داشته باشه
خیلی Consistency مهمه که یک style در کل کد رعایت بشه
The principles of programming style are based on common sense guided by expe- rience, not on arbitrary rules and prescriptions. Code should be clear and simple- straightforward logic, natural expression, conventional language use, meaningful names, neat formatting, helpful comments- and it should avoid clever tricks and unusual constructions. Consistency is important because others will find it easier to read your code, and you theirs, if you all stick to the same style.
من چند تا از نکات فصل اول رو مینویسم اینجا
Use descriptive names for globals, short names for locals.
Programmers are often encouraged to use long variable names regardless of context. That is a mistake: clarity is often achieved through brevity.
نوشته شده که global variables باید اسم های طولانی و توصیف کننده داشته باشن و local variables ها باید short name داشته باشن.
نکته جالبی که میگه اینه که برنامه نویس ها علاقه دارن اسم های طولانی انتخاب بکنن بدون در نظر گرفتن context، در حالیکه clarity خیلی وقت ها با استفاده از اختصار بدست میاد.
Be consistent
در انتخاب اسم ها باید سیاست consistent داشته باشیم، اگه یه جا برای نامگذاری یه متغیر مرتبط با صف از Queue استفاده کردیم، برای یه متغیر دیگه از Q استفاده نکنیم…
Consistency and Idioms: Use a consistent indentation and brace style
این چیزیه که در گولنگ خیلی دغدغه ش رو نداریم، چون rob pike یکی از نویسندگان این کتاب خودش گولنگ رو نوشته 🙂
Give names to magic numbers
بهتره اگه تو کد مقادیر ثابت استفاده میکنید براشون constant تعریف کنید، مثلا اگه در گولنگ از لینتر استفاده کنید میتونید این لینتر رو نصب کنید go-mnd که بهتون بگه کجاها رعایت نکردید
خلاصه این کتاب کلی نکته مفید و کوچیک و خفن داره که هنوز هم خیلی هاش کاربردیه
The Practice of Programming (Addison-Wesley Professional Computing Series) 1st Edition
https://www.amazon.com/Practice-Programming-Addison-Wesley-Professional-Computing/dp/020161586X
by Brian Kernighan (Author), Rob Pike (Author)
@gocasts
مثلا در فصل اول برای style همین یک پاراگراف کلی نکته داره
اولا اینکه style یه common sense هست، پس براش دنبال استاندارد و قانون نگردید.
کد باید واضح و ساده باشه و نباید clever tricks داشته باشه
خیلی Consistency مهمه که یک style در کل کد رعایت بشه
The principles of programming style are based on common sense guided by expe- rience, not on arbitrary rules and prescriptions. Code should be clear and simple- straightforward logic, natural expression, conventional language use, meaningful names, neat formatting, helpful comments- and it should avoid clever tricks and unusual constructions. Consistency is important because others will find it easier to read your code, and you theirs, if you all stick to the same style.
من چند تا از نکات فصل اول رو مینویسم اینجا
Use descriptive names for globals, short names for locals.
Programmers are often encouraged to use long variable names regardless of context. That is a mistake: clarity is often achieved through brevity.
نوشته شده که global variables باید اسم های طولانی و توصیف کننده داشته باشن و local variables ها باید short name داشته باشن.
نکته جالبی که میگه اینه که برنامه نویس ها علاقه دارن اسم های طولانی انتخاب بکنن بدون در نظر گرفتن context، در حالیکه clarity خیلی وقت ها با استفاده از اختصار بدست میاد.
Be consistent
در انتخاب اسم ها باید سیاست consistent داشته باشیم، اگه یه جا برای نامگذاری یه متغیر مرتبط با صف از Queue استفاده کردیم، برای یه متغیر دیگه از Q استفاده نکنیم…
Consistency and Idioms: Use a consistent indentation and brace style
این چیزیه که در گولنگ خیلی دغدغه ش رو نداریم، چون rob pike یکی از نویسندگان این کتاب خودش گولنگ رو نوشته 🙂
Give names to magic numbers
بهتره اگه تو کد مقادیر ثابت استفاده میکنید براشون constant تعریف کنید، مثلا اگه در گولنگ از لینتر استفاده کنید میتونید این لینتر رو نصب کنید go-mnd که بهتون بگه کجاها رعایت نکردید
خلاصه این کتاب کلی نکته مفید و کوچیک و خفن داره که هنوز هم خیلی هاش کاربردیه
The Practice of Programming (Addison-Wesley Professional Computing Series) 1st Edition
https://www.amazon.com/Practice-Programming-Addison-Wesley-Professional-Computing/dp/020161586X
by Brian Kernighan (Author), Rob Pike (Author)
@gocasts
Forwarded from linuxtnt(linux tips and tricks) (hosein seilany https://seilany.ir/)
🔰 گوگل قصد دارد ChromeOS را "متوقف کند" و اندروید را به دسکتاپ بیاورد
🔹گوگل قصد دارد ChromeOS را "متوقف کند" تا با آی پد اپل رقابت کند. جایی که توضیح داده میشود گوگل در حال کار بر روی یک لپتاپ high-end با نام رمز Snowy است.
🔹گزارش شده که گوگل تنها یک سیستم عامل خواهد داشت: اندروید
🔹رمز Snowy یک لپتاپ high-end خواهد بود که به سری مکبوک شباهت دارد، اما به جای استفاده از ChromeOS، از اندروید استفاده خواهد کرد. آنها اصرار دارند که هدف رقابت با آی پد است.
🔹 گوگل سابقه چندان درخشانی در مدیریت سیستمعاملها و محصولات خود ندارد. وبسایت "گورستان گوگل" نزدیک به ۳۰۰ نمونه از محصولات و خدمات متوقفشده گوگل را فهرست کرده است.گوگل ممکن است با اندروید موفق بوده باشد، اما سیستمعاملهای دیگر را بهدرستی مدیریت نکرده یا رها کرده است.گوگل در سال ۲۰۱۸ اقدام به بازسازی و بهبود این سیستمعامل کرد و نام آن را به Wear OS تغییر داد. سیستمعامل ظاهر جدیدی به خود گرفت و کمی سریعتر شد، اما بسیاری از مشکلات آن باقی ماندند و تعداد تولیدکنندگانی که از این پلتفرم استفاده میکردند کاهش یافت
🔹در ژانویه ۲۰۲۳، گوگل ۱۶٪ از کارکنان مشغول به کار روی Google Fuchsia را اخراج کرد. از آن زمان چیز زیادی درباره آن نشنیدهایم. این سیستمعامل به عنوان نسل بعدی اندروید و ChromeOS معرفی شد،
🔹نکته این است که آنها میخواهند ChromeOS به اندروید تبدیل شود، یا بهتر بگوییم ادغامی از هر دو سیستم عامل.
همچنین بر اساس این منبع داخلی ادعا شده، همه اینها به این دلیل است که آی پد پادشاه تبلتها است و هیچ کاری که گوگل تا به حال انجام داده نتوانسته این وضعیت را تغییر دهد. در ایالات متحده، به جایی رسیده که بسیاری از مردم به هر تبلتی "آی پد" میگویند.
📌نویسنده: حسین سیلانی
📌منبع : آکادمی کندوی دانش
https://learninghive.ir
🔹گوگل قصد دارد ChromeOS را "متوقف کند" تا با آی پد اپل رقابت کند. جایی که توضیح داده میشود گوگل در حال کار بر روی یک لپتاپ high-end با نام رمز Snowy است.
🔹گزارش شده که گوگل تنها یک سیستم عامل خواهد داشت: اندروید
🔹رمز Snowy یک لپتاپ high-end خواهد بود که به سری مکبوک شباهت دارد، اما به جای استفاده از ChromeOS، از اندروید استفاده خواهد کرد. آنها اصرار دارند که هدف رقابت با آی پد است.
🔹 گوگل سابقه چندان درخشانی در مدیریت سیستمعاملها و محصولات خود ندارد. وبسایت "گورستان گوگل" نزدیک به ۳۰۰ نمونه از محصولات و خدمات متوقفشده گوگل را فهرست کرده است.گوگل ممکن است با اندروید موفق بوده باشد، اما سیستمعاملهای دیگر را بهدرستی مدیریت نکرده یا رها کرده است.گوگل در سال ۲۰۱۸ اقدام به بازسازی و بهبود این سیستمعامل کرد و نام آن را به Wear OS تغییر داد. سیستمعامل ظاهر جدیدی به خود گرفت و کمی سریعتر شد، اما بسیاری از مشکلات آن باقی ماندند و تعداد تولیدکنندگانی که از این پلتفرم استفاده میکردند کاهش یافت
🔹در ژانویه ۲۰۲۳، گوگل ۱۶٪ از کارکنان مشغول به کار روی Google Fuchsia را اخراج کرد. از آن زمان چیز زیادی درباره آن نشنیدهایم. این سیستمعامل به عنوان نسل بعدی اندروید و ChromeOS معرفی شد،
🔹نکته این است که آنها میخواهند ChromeOS به اندروید تبدیل شود، یا بهتر بگوییم ادغامی از هر دو سیستم عامل.
همچنین بر اساس این منبع داخلی ادعا شده، همه اینها به این دلیل است که آی پد پادشاه تبلتها است و هیچ کاری که گوگل تا به حال انجام داده نتوانسته این وضعیت را تغییر دهد. در ایالات متحده، به جایی رسیده که بسیاری از مردم به هر تبلتی "آی پد" میگویند.
📌نویسنده: حسین سیلانی
📌منبع : آکادمی کندوی دانش
https://learninghive.ir
Forwarded from کانال اطلاعرسانی توزیع پارچ
ویژگیهای جدید، ظاهر جدید
کالامارس پارچ رو با ظاهری جدید و رنگبندی توکیو نایت بازطراحی کردیم، صدالبته این نتیجه نهایی نیست و تا روز عرضه نسخه جدید دستخوش تغییرات زیادی خواهد شد.
@ParchLinux
کالامارس پارچ رو با ظاهری جدید و رنگبندی توکیو نایت بازطراحی کردیم، صدالبته این نتیجه نهایی نیست و تا روز عرضه نسخه جدید دستخوش تغییرات زیادی خواهد شد.
@ParchLinux
Forwarded from ASafaeirad
Node.JS Typescript support (kinda) is now enabled by default.
https://github.com/nodejs/node/pull/56350
#nodejs #news
https://github.com/nodejs/node/pull/56350
#nodejs #news
GitHub
module: unflag --experimental-strip-types by marco-ippolito · Pull Request #56350 · nodejs/node
It's time to enable it by default to catch some more bugs, currently there are no open issues.
I think it's a semver minor change.
Fixes: nodejs/typescript#17
@nodejs/tsc for visibi...
I think it's a semver minor change.
Fixes: nodejs/typescript#17
@nodejs/tsc for visibi...
Forwarded from ASafaeirad
Forwarded from Laravel News
A Laravel Package for the Quickpay API https://laravel-news.com/quickpay-laravel
Laravel News
A Laravel Package for the Quickpay API - Laravel News
The Quickpay package for Laravel helps you quickly utilize the Quickpay API client using a fluent object and service Facade. Quickpay allows you to accept payments securely and reliably.
Forwarded from CleverDevs (Mammad)
خیلی اوقات برامون پیش میاد بخوایم یه فایلی رو بین لپ تاپ یا گوشی یا حتی بین دوتا گوشی به اشتراک بزاریم
یکی از بچه های کانال اومده یه برنامه باحال برای اینکار توسعه داده به اسم میزبان که میاد یه سرور کوچیک روی شبکه LAN میسازه و دستگاه هایی که به یه شبکه متصل باشن راحت میتونن فایل هاشون رو به اشتراک بزارن
میزبان از سیستم عامل های گنو/لینوکس و ویندوز پشتیبانی میکنه و استفاده ازش هم سادس که میتونید توی گیت هابش ببینید
https://github.com/aminupy/mizban/
اگه پیشنهادی داشتید میتونید توی کامنتا بفرستید یا خودتون توی برنامه مشارکت کنید و اگه خوشتون اومد استار بدید ⭐️
#openSource
@CleverDevs - @CleverDevsGp
یکی از بچه های کانال اومده یه برنامه باحال برای اینکار توسعه داده به اسم میزبان که میاد یه سرور کوچیک روی شبکه LAN میسازه و دستگاه هایی که به یه شبکه متصل باشن راحت میتونن فایل هاشون رو به اشتراک بزارن
میزبان از سیستم عامل های گنو/لینوکس و ویندوز پشتیبانی میکنه و استفاده ازش هم سادس که میتونید توی گیت هابش ببینید
https://github.com/aminupy/mizban/
اگه پیشنهادی داشتید میتونید توی کامنتا بفرستید یا خودتون توی برنامه مشارکت کنید و اگه خوشتون اومد استار بدید ⭐️
#openSource
@CleverDevs - @CleverDevsGp
Forwarded from Laravel News
Deep Array Manipulation with Laravel's replaceRecursive Method https://laravel-news.com/replacerecursive
Laravel News
Deep Array Manipulation with Laravel's replaceRecursive Method - Laravel News
Master Laravel's replaceRecursive method for elegant nested array updates. Learn to merge complex configurations and user preferences while preserving default values in your data structures.