در باب برنامه نویسی فانکشنال، یه مقاله خیلی خوب و البته پایه ای هست که توضیح میده چطوری میشه محاسبات رو در قالب توابع بازگشتی بیان کرد. (در واقع اثبات انجام میده)
اگه به functional programming علاقه دارید ازش میشه چیزای خوبی یاد گرفت.

https://www-formal.stanford.edu/jmc/recursive.pdf

#ارسالی از دوست خوبم دانیال

و یادآوری اینکه مقاله سنگینیه، شاید با کمک سرچ و یوتوب منابعی پیدا کنید که بیشتر توضیح دادن.

چی میشه اگه یه مهندس نرم‌افزار (آشنا به گیت و گیتهاب) یه شرکت و متودولوژی توسعه نرم‌افزار طراحی کنه؟
احتمالا برای همه چی از گیت و گیتهاب استفاده می‌کنه. توی plaintext و markdown می‌نویسه و ...

به نظرم ویدیویی جالبی بود.
https://youtu.be/WgV6M1LyfNY?si=Hr9hsBTfmEME7s9A

The devil is in the details
شیطان در جزئیات خفته

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

اما از دید من، هیچ تغییری بی اهمیت نیست،
یه اسپیس اضافه توی فایل یمل میتونه کلا کانفیگ رو خراب کنه و پاد کلا بالا نیاد.

و کاش ته فاجعه بالا نیومدن یه پاد باشه!
یه سری اشتباهات در همین اندازه کوچیک،
موشک ها منفجر کردن و بیزنس ها به خاک نشوندن!

|-×-×-×-|

نیاز به حساسیت رو یه سری موارد در ظاهر کم ارزش اما باطنا تاثیر گذار، باعث شد که با خیال راحت تری برای ریویو کردن کد ها حساسیت به خرج بدم.

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

ولی خودمونیما، چه دلیلی وجود داره که کد فرمت نشه؟
اونم با وجود کلی ابزار برای اتومات شدن این فرآیند؟
چیزی جز مایندست "بزن بره"؟
و چه تضمینی هست کسی که رو فرمت کردن کدش تنبلی کرده، بقیه جاها مثل ساعت کوارتز، دقیق باشه؟

|-×-×-×-|

برای من کد مثل یه اثر هنری میمونه، که هر چی بیشتر به ظرافت هاش توجه بشه زیباتر میشه.
و تو مهندسی، علاوه بر زیبایی، پارامتر هایی مثل کارایی، بهینگی، قابل اتکایی و... هم تاثیر پذیر از توجه به ظرافت ها و جزئیات هستن.

بنابراین به جزئیات دقت کنید،
تمام کامیت های شما میشن اعتبار آینده شغلی شما،
اعتبار شما پیش کسایی که فعلا شمارو نمیشناسن،
اما اسم و کیفیت کارتون رو خواهد شناخت.

دیر رسیدن، بهتر از رو پروداکشن ترکیدن!

|-×-×-×-|

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

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

|-×-×-×-|

از این موارد و عدم توجه به جزئیاتی که باعث فاجعه شدن زیاد توی تاریخ دنیای نرم افزار وجود داره،
ولی مایندست "بزن بره" هم همچنان به قوت خودش باقیه 🔥😂

واقعیت اینکه گاهی وقتا یه چیزایی برامون شفاف نشده،
و همین باعث میشه ندونیم چه وقت حساس باشیم و چقدر حساس باشیم.

میخوایم جلوی premature optimisation رو بگیریم،
اشتباها کد باگی میفرستیم رو پروداکشن.
چون مرز بهینگی رو مشخص نکردیم،
چون تعریف باگ رو (برا خودمون) مشخص نکردیم،
چون هیچ فریمورکی برای کد ریویو نداریم و کاملا سلیقه ای انجام میشه.
و...

|-×-×-×-|

نظر شما چیه؟ چه مثال ها و نکاتی رو دوست دارید در مورد مطالب گفته شده مطرح کنید؟

اگر دوست داشتید Reverse Shell رو پیگیری کنید. هکر کاری می‌کنه که سیستم قربانی خودش به سمت هکر وصل بشه و می‌تونه کنترل سیستم رو از راه دور به دست بگیره. اینطوری فایروال ها خیلی کمتر جلوش رو میگیرن.

https://www.acunetix.com/blog/web-security-zone/what-is-reverse-shell/

این هم سایت باحالی بود در این زمینه
https://revshells.com

با تشکر از دوست قديميم امیر میرزایی عزیز #ارسالی

چیزهای عجیبی که موقع استفاده از json در گولنگ باید حواسمون باشه
https://www.alexedwards.net/blog/json-surprises-and-gotchas

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

🆔 @lifeAsAService

تاریخچه ای از چند باگ خیلی مهم در نرم‌افزار های مختلف که باعث ضرر یا از دست دادن جون آدما شد.

https://youtu.be/Iq_r7IcNmUk?si=7VZNVjvvjUB-SxC2

Happy 53rd birthday, Unix! 🥳

در مورد پاک کردن فایل‌ها در لینوکس با دستور rm و تفاوتش با دستور unlink
https://www.networkworld.com/article/2517515/how-to-get-rid-of-unneeded-files-on-linux.html

وقتی برنامه‌ها تموم می‌شن یه کدی دارن به اسم exit code
تو این مطلب باهاشون بیشتر آشنا می‌شیم و در مورد اینکه هر کد چه معنی‌ای می‌تونه داشته باشه صحبت می‌کنیم.
https://www.networkworld.com/article/3546937/understanding-exit-codes-on-linux-2.html

در مورد کامند xargs و اینکه چطوری می‌تونه باعث افزایش سرعت کارمون بشه اینجا بخونید:

https://www.networkworld.com/article/3560213/lesser-known-xargs-command-is-a-versatile-time-saver.html

مطالب روزهای گذشته از یک بلاگ بود به اسم یونیکس به عنوان زبان دوم (unix as a second language)
به نظرم آموزش‌های لینوکسی سطح متوسط و کاربردی‌ای داره. از سایت‌های عام که آموزش‌های مقدماتی رو مدام تکرار می‌کنن فاصله گرفته ولی همچنان قابل فهم و زیبا می‌نویسه و موضوعات خوبی هم انتخاب می کنه.

https://www.networkworld.com/blogs/unix-as-a-second-language/

گیت اخیرا به اسیب پذیری داشت که یه ریپوزیتوری فقط با کلون شدن، میتونست رو سیستم سما دستورات مخرب اجرا کنه.
توضیحات خوب و توضیح کد رو اینجا ببینیم:
https://amalmurali.me/posts/git-rce/

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

اما اگه ویم دوست ندارید یا میخواید مشخص تر باشه روند کاری که پیش می‌رید، امکان گرفتن diff (یا با کامند دیف یا با کمک git diff) و بعد اعمال کردنش با دستور patch می‌تونه کمک کننده باشه.


در مورد دستور patch:
https://www.youtube.com/watch?v=r9N-BOWWr-k
اموزش متنی هم قطعا ازش هست ولی ممکنه نامانوس باشه قضیه برای همین این اموزش ویدیویی برای خودم جالب تر بود.

اگه میخواین با کمک گیت فایل های patch رو بسازید یا اصلا اعمال کنید این اموزش خیلی خوبیه که با کمک ابزار git diff آموزش میده که فایل دیف بسازیم و بعد روی فایل‌ها اعمالش کنیم.

https://www.specbee.com/blogs/how-create-and-apply-patch-git-diff-and-git-apply-commands-your-drupal-website


حالا چرا وقتی دستور patch هست از گیت برای اعمال پچ ها استفاده کنیم؟ چون خیلی قابلیت‌های بیشتر بهمون میده مثل چک کردن پیشفرض سینتکس صحیح پچ و چک کردن اینکه قابل مورد تغییر کامیت شده باشه و یا حتی حل کردن کانفلیکت‌هایی که پچمون اعمال می‌کنه.
https://www.reddit.com/r/suckless/comments/pb828q/whats_the_point_of_using_git_to_apply_patches/

از صفحاتی جالبی که امروز به چشمم خورد Write your Own Virtual Machine بود.

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

@aminrbg

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

https://github.com/jesusprubio/up

اگه دوست دارید از زیر و بم گولنگ سر در بیارید این ریپو منابع خیلی خوبی معرفی کرده.
البته که هر کدوم سنگین هستن و نمیشه انتظار داشت یهو بشینیم همشو (یا حتی یکیشو) بخونیم.

https://github.com/emluque/golang-internals-resources