به تغییرات آخر رسیدیم :

1- کامندارو آوردم وسط صفحه.

2- فایلای بزرگ رو سپردم به بیگ‌فایل که بخش بخش نمایش بده روی صفحه تا زمان لود کردنشون کند نباشه.

3- ی پلاگین مثل cursor ai اضافه شد ولی بصورت دیفالت غیرفعال هست.

4- داشبورد اضافه شده که توی تصویر هست.

5- برای پایتون format, lint فقط و فقط ruff رو داریم و اونم موقع ذخیره کارش رو می‌کنه

6-پلاگین which-key اضافه شد؛ خیلی‌ها گفتن که فراموش می‌کنند کلیدهارو

7-دیباگر پایتون رو حذف کردم؛ زمان لود رو میبرد بالا

8-کی‌مپ برای حیسون اضافه کردم که پرتی‌پرینتش کنه (پلاگین نیست و از پایتون روی سیستم استفاده می‌کنه)

9-پلاگین برای مشاهده csv, tsv اضافه شد؛ بصورت جدول نشون میده و تمیز.

10-یک venv selector هم داریم؛ البته من برای pyright, ... قبلا کد زدم که .venv رو بخونه اگر نبود از بیس بگیره و ... ولی خب اینم اضافه شد.


احتمال زیاد برای Rust دیباگر رو فعال می‌کنم (چون نیازه ولی برای پایتون نداشته باشیم؛ نمیدونم)

چیز دیگه به ذهنم نمیرسه و ۹۰٪ چیزایی که پیشنهاد دادید روی این نسخه و نسخه قبلی بود.

هر جیزی هم که توی این توسعه دادن ۱ هفته‌ای که اومدم روی neovim بهش برخورد می‌کنم رو اضافه می‌کنم.

شاید براتون جالب باشه

ربات های گوگل اتک میزنن به سایتتون و فشار سی پی یوتون بالا میبرن و سایتتون رو کند میکنن بعد میگن سرعت سایتتون کمه

و این قضیه رو هر سئو کاری بگه غیر ممکنه ما ثابت میکنیم

در عکس بالا ربات های گوگل میان فیلتر های سایت رو باز میکنن و میرن توی فروشگاه رندوم تمام فیلتر ه امدام سلکت میکنن و مدام با سرعت زیاد باز میکنن

و این قضیه باعث فشار روی سی پی یو و دیتابیس میشه

و اگر بگید توی فایل ربات ببندید درست میشه نه همه این کارا شده

بعضی وقتا خوده ربات های گوگل اتک میزنن و شما اگر ببندیدنشون سئوتون خراب میشه

باز بزارید سی پی یوتون میچسبه بالا و سایت کنده

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

@poinair پوینا

خیلی از سایتای خارجی و ایرانی توی قالب و افزونه هاشون فایل و بکدوره

یکی از سایتایی که 99 درصد فایل های افزونه و قالبش کرکیه و ما تا الان توش ویروس و بکدور و بک لینک ندیدیم

این سایته

wplocker.com

تا الان گزارش ویروسی از سمت این سایت نداشتیم

توی گرونی دلار بدردتون میخوره

حالا اگر کسی توش ویروس دید بگه ما حتما میگیم

@poinair پوینا

فکر کردین System Programmer ها نیازی به دونستن ریاضی ندارن؟

توسعه دهنده های کرنل لینوکس با تناقض بهتون ثابت می کنن که اشتباه می کنین. کامنت های این تابع با استفاده از روابط ریاضی، اثبات میکنه که اگه وزن تغییر کنه و زمان اجرای مجازی ثابت بمونه، تناقضی توی محاسبات ایجاد می‌شه.


@Linuxor ~ abhi9u

20 سال با اوبونتو

پیچیدگی و نشانه‌های آن
___________

کتاب 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) و نوظهور و خود-سازمان را به‌نمایش میگذارد.

که فکر میکنم تعریف دوم، بیشتر با شرح نشانه‌هایی که از یک سیستم نرم‌افزاری دیدیم هم‌سو باشه.

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

این که گفتم بیخوده چون حدسه و صرفاً بدرد فرضیه‌پردازی میخوره. اما چیزی که بیخود نیست اینه که تجربه‌ی شخصی من هم همیشه همین بود. وسواسی دارم که هرکتاب یا محتوای خوبی رو که بخوام بخونم و واقعا بخوام که تو ذهنم بمونه دوست دارم نسخه‌ی فیزیکش رو تهیه کنم. اما خب، از بد حادثه، اینجا برای یک کتاب زپرتی صد و چند صفحه‌ای، باید حداقل ۳۰-۴۰ یورویی خرج کنم چه برسه به کتاب‌های گردن کلفت‌تر و این باعث میشه که بوسه‌ای به کله‌ی کچل آقای ادام گرنت بزنم وحر‌ف‌ش رو بریزم دور و دست libgen و رفقا رو به گرمی بفشارم و epub ها رو دونه دونه دانلود کنم.

نسخهٔ ۳ دیپ‌سیک که اخیراً منتشر شده، claude 3.5 sonnet رو پشت سر گذاشته. اینجا می‌تونید رایگان ازش استفاده کنید. امکانِ جستجو در اینترنت هم جدیداً اضافه کرده. دیگه وقتشه جدی ازش استفاده کنیم.
chat.deepseek.com‎

@DevTwitter | <Ayub Kokabi/>

یکی از بهترین میم هایی که میشد با داون شدن gpt درست کرد :

#fun
@CleverDevs - @CleverDevsGp

اگه یه ماژول فقط مسئول محاسبه تخفیف‌ها باشه (مثلا کلاس DiscountCalculator)، این ماژول یه ماژول High Cohesion هستش و خیلی خوبه باعث فهم بهتر کد و قابلیت نگهداری بالاتریه.

اگه یه ماژول وظایف مختلفی مثل محاسبه تخفیف، چاپ فاکتور و مدیریت مشتری رو انجام بده، انسجامش پایینه و می‌تونه باعث پیچیدگی و مشکلات در نگهداری شه.


@Linuxor

2024 • @telemetr_io_bot

دو برنامه نویس کهنه کار و خفن ۲۵ سال پیش یه کتاب جمع و جور و خوب نوشتن که کلی نکته کوچیک و مفید در مورد 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