خطا داریم؟ همینه که هست!

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

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

در یک برنامه معمولی جوابِ (احتمالا) درست به خیلی از این سوالا اینه که خب کارکرد برنامه رو متوقف کن و بگو نمیتونم. برنامه کار نکنه تا دوباره با برطرف شدن مشکلات یکی از اول اجراش کنه،
ولی اگر برنامه ما قراره توی یکسری از محیط‌ها اجرا بشه دیگه خبری از «من کار نمیکنم تا شرایط درست بشه» نیست. چه محیط‌هایی؟ محیط‌هایی که availability بالا مهمه مثلا سیستم های امبدد یا بک‌اند.
مثلا قراره ما مسیریابی یک هواپیما رو انجام بدیم و سیگنال GPS دریافت نمی‌کنیم، خب به هواپیما بگیم فعلا من کار نمیکنم؟! یعنی چی که کار نمیکنم، با سرعت زیاد داره میره :)))
یا مثلاً توی کلود اگر ارور بدیم و برنامه کرش کنه کنیم چی میشه؟ کوبرنتیز دوباره برنامه رو اجرا می‌کنه و دوباره با مشکل درگیریم!

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

مثلا چه مشکلاتی؟
مثلاً اگه قراره کانفیگ فایل رو از بیرون لود کنیم, آمادگی نبودنش رو هم داشته باشیم، مثلا یه کانفیگ پیشفرض داشته باشیم (البته کانفیگ چون موقع اولین اجرای برنامه خودش رو نشون میده شاید نیازی هم نباشه)
مثلا اگر داده gps به ما نرسید، با کمک داده های قبلی که ذخیره کردیم و یا ترکیبش با سرعت و شتاب و ... مشکل رو موقتا و حتی نادقیق حل کنیم
یا مثلاً اگر به سرور خارجی درخواست می‌زنیم و نیست، آمادگی نبودنش رو داشته باشیم، اینجا یکسری پترن که تو صنعت استفاده میشه داریم
مثلا چه پترنهایی؟
+ دوباره درخواست بده: retry pattern
+ به یکی دیگه درخواست بده: fallback
+ اگر خرابه تا یه مدت بهش درخواست نده تا ارور الکی نگیری: circuit breaker
+ اگه سرور خارجی کنده، خیلی صبر نکن تا response time خودت هم بالا نره
+ اگر سرور خارجی دیتا قراره بهت بده، دیتای قبلی رو کش کن.

اینها در سطح کد بودن، در سطح معماری هم میشه از قبل روش‌هایی رو تدارک دید مثلاً خود دیتابیس رو چطوری High available کنیم، یا روش‌هایی که بیشتر تو سیستم های امبدد استفاده میشه مثل اینکه یه برنامه رو با چند تا پیاده سازی همزمان اجرا کنیم تا اگر یکیش خراب شد اون یکی‌ها باشن!

منابع:
https://opensource.com/article/19/9/transient-faults-devops

https://www.jrebel.com/blog/microservices-resilience-patterns

https://learn.microsoft.com/en-us/azure/architecture/best-practices/transient-faults

https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/application-resiliency-patterns

@terminal_stuff

یه لینکی همینطوری پیدا کردم، یه بنده خدایی اومده سعی کرده SAT رو با پیاده‌سازی یه SAT solver ساده به زبان پایتون توضیح بده. من خودم پایتون هیچی بلد نیستم ولی متنش رو که می‌خوندم خیلی خوب و روون بود. خلاصه می‌ذاریم اینجا بمونه.

https://sahandsaba.com/understanding-sat-by-implementing-a-simple-sat-solver-in-python.html

تا حالا گول این کامند رو توی فروم ها خوردین؟

:(){ :|:& };:

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


https://www.wiregeek.ir/p/%D9%81%D9%88%D8%B1%DA%A9-%D8%A8%D9%85%D8%A8-%DA%86%DB%8C%D8%B3%D8%AA-%D9%88-%DA%86%D8%B7%D9%88%D8%B1-%DA%A9%D8%A7%D8%B1-%D9%85%DB%8C%DA%A9%D9%86%D8%AF/

"آن چاقوی سوئیسی دیگر نمی‌بُرَد"
با احترام، تقدیم به خدای باستانِ زبان‌های برنامه‌نویسی، مرحوم Niklaus Wirth
————————————————————

تنها سه روز از سال نوی میلادی جدید سپری شده و هنوز برای قضاوت خوش یا بد یُمن بودن آن زود است، اما یکم ژانویه‌ی ۲۰۲۴، یقینا یکی از سیاه‌ترین روزهای تاریخ جامعه‌ی آکادمیک مهندسی نرم‌افزار خواهد بود. امروز حدود ۳ ساعت پیش، آقای Bertrand Meyer در یک توئیت اعلام کردند که یکی از ستارگان زبان‌های برنامه‌نویسی، متدولوژی برنامه‌نویسی، مهندسی نرم‌افزار و طراحی سخت‌افزار افول کرد. آقای Niklaus Wirth، با کوهی از افتخارات، برنده‌ی جایزه‌ی تورینگ اوارد، در سن ۸۹ سالی به تاریخ یکم ژانویه‌ی ۲۰۲۴ چشم از جهان فرو بستند.

آقای Wirth در شهر Winterthur سوئیس بدنیا آمد و تحصیلات آکادمیک خود را در ETH زوریخ آغاز کرد. برای آغاز تحصیلات تکمیلی به دانشگاه Laval در کانادا رفت و بعد از آن رساله‌ی دکتری خود را در دانشگاه برکلی کالیفرنیا، به سرپرستی Harry Huskey، از پیشرویان پیدایش کامپیوتر، با عنوان A Generalization of ALGOL به سرانجام رساند. سپس به عضویت هیئت علمی دانشگاه استنفورد درآمد و بعد از آن به ETH بازگشت و در آنجا تا بازنشستگی خود به کارش ادامه داد.

از جمله دست‌آوردهای مهم ایشان طراحی زبان‌های برنامه‌نویسی Pascal و ALGOL بود. علاقه‌ی آقای Wirth به زبان ALGOL آنقدر زیاد بود که زبان‌های متعددی مانند Euler و Modula و Oberon را بر پایه‌ی آن طراحی کردند. ایشان در طراحی و پیاده‌سازی سیستم‌عامل‌های Medos-2 و Oberon System نقش کلیدی داشتند. در حوزه‌ی معماری کامپیوتر، یک زبان HDL به نام Lola را طراحی و پیاده‌سازی کردند. سال ۱۹۸۴ به پاس دست‌آوردهای کلیدی و مهم ایشان در حوزه‌ی زبان‌های برنامه‌نویسی، برنده‌ی جایزه Turing Award شدند.

علاوه بر پژوهش‌های پیشرو، دانشمندان به‌نامی مانند Martin Odersky، خالق زبان Scala و Generics در Java و Michael Franz، مبدع Just-in-time Compilation and Optimization را تربیت کردند. ایشان کتاب‌های مهم و تأثیرگذاری در طی فعالیت خود به چاپ رساندند که می‌توان از میان آن‌ها کتاب‌های مهمی چون Algorithms + Data Structures = Programs و Systematic Programming: An Introduction و Compiler construction را نام برد. کتاب اول را یکی از تأثیرگذارترین کتاب‌های نوشته شده در حوزه‌ی CS در طول تاریخ قلم‌داد می‌کنند. کتاب دوم مختص ریاضی‌دانانی نوشته شده بود که تمایل به درک ماهیت‌ برنامه‌نویسی و یادگیری نوشتن الگوریتم دارند. کتاب سوم با دید کاربردی نوشته شده که در آن زمان که تمام کتاب‌های حوزه‌ی کامپایلر با دید تئوری نوشته می‌شدند، کاری منحصر به فرد محسوب می‌شد.

در علم کامپیوتر یک ضرب‌المثلی وجود دارد که منسوب به آقای Wirth است و آن این است که :
"Software is getting slower more rapidly than hardware becomes faster"
از این روی به این عبارت Wirth's law گفته می‌شود.

گرچه ممکن است نام هیچ یک از کارهای آقای Wirth برای یک دانشجوی CS آشنا نباشد، اما گفتنی‌ست که امروزه اکثر زبان‌های برنامه‌نویسی، کامپایلرها، متدولوژی‌های تولید نرم‌افزار و حتی سیستم‌‌عامل‌ها، بیش از آنچه که فکر کنید وامدار پژوهش‌ها و دست‌آوردهای آقای Wirth می‌باشند.

یه سوال خیلی جالب بود برام توی یکی از مصاحبه ها ( تاحالا ازم نپرسیده بودن )

اگر به باگ بربخورید چطوری رفعش میکنید؟
این سوال رو بنظرم نیاز روزی هزار بار از خودمون بپرسیم
چون نه تنها تو زندگی مون توی همه جا بدردمون میخوره
زندگی تون بی باگ و اوقات تون زیبا

شما نظرتون چیه؟ چطوری شروع میکنید فکر کردن و سر نخ پیدا کردن؟

https://jvns.ca/blog/2022/12/08/a-debugging-manifesto/

اینجا یه سری راهکار و راهنمایی برای دیباگ آورده شده،
مثل بقیه کامیک های این سایت، قشنگ و روون توضیح داده و حتما توصیه میشه.

امروز یاد گرفتم که استفاده از قابلیت‌های خفن‌تر تاچ‌پد توی لینوکس هم ممکنه. یعنی می‌تونید تنظیم کنید هر gestureی که با تاچ‌پد انجام می‌دید می‌تونه یه کامند اجرا بشه. جالا می‌تونه مستقیم کامند شل باشه می‌تونه هم با کمک ابزارهایی مثل xdotool وارد شدن کلید‌های دیگه رو شبیه‌سازی کنید.

با کمک ابزار fusuma با یه yaml ساده کانفیگ‌ها انجام می‌شه. این ویدیوی آموزشی رو توصیه میکنم:
https://www.youtube.com/watch?v=bn11Iwvf29I

و لینک ریپوزیتوریشون:
https://github.com/iberianpig/fusuma

سیستم لینوکسی چطوری بوت میشه؟
یه ویدیوی کوتاه با عمق خوب

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

💠دیواری از لامپ لاوا در کلادفلر💡

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

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

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

به این ترتیب کلادفلر به میزان انتروپی لازم برای تولید رمزگذاری و رندومنِس دست پیدا می‌کند.

ایده‌ی استفاده از لامپ لاوا برای رندومنِس اولین برای توسط Silicone Graphics در سال ۱۹۹۰ اجرا شد و امروزه کلادفلر از آن استفاده می‌کند.

الگوریتم LavaRand امروزه یکی از موثر ترین روش‌های تولید رندومنِس در کامپیوتر‌ها است.

مبحث رندومنِس در علوم کامپیوتر واقعا مبحث جذابیه

👉🔗 Link-1
👉🔗 Link-2
#نکته

مقدمه‌ای بر higher order functionها و تمرکز روی Decoratorها در پایتون

https://www.programiz.com/python-programming/decorator

اگه توی گولنگ مبتدی هستین یا زیاد به shuffle آهنگ‌ها دقت می‌کنید این مطلب که توش یه الگوریتم من‌در‌اوردی shuffle رو پیاده‌سازی کرده با گولنگ شاید جالب باشه.

https://cjohansen.no/a-better-playlist-shuffle-with-golang/

این موزیک پلیر هم با گو امکانات خوبی داره. البته در عمل استفاده نکنید شاید بهتر باشه تا وقتی vlc/mpv هست ولی خوندنش سورسش شاید جالب باشه.

https://github.com/mjibson/moggio

چرا تنها encoding خوب، utf-8 ئه؟
یه مطلب عمیق و طولانی در مورد مشکلات encodingهای دیگه در انواع سیستمها و پلتفرمها.

https://utf8everywhere.org/

#روزی_یک_نکته با دلاتو

دسته‌بندی: #آموزشی #کاربردی #latex #rubber

راجب rubber برای کامپایل latex:

مقدمه: اگه از latex/xelatex برای کامپایل استفاده کنید، نیاز به چند سری کامپایل برای گرفتن خروجی درست هست وگرنه داخل pdf تولید شده، فهرست یا... درست نمایش داده نمیشن.
سرچ زدم و ظاهرا یه راه حل ساده داره: rubber
داخل مخازن رسمی آرچ بیسا هستش، بقیه توزیع ها رو نمیدونم.

برای کامپایل هم خیلی ساده از دستور زیر استفاده میکنید:
rubber -m xelatex <file>

"اسم file رو باید بدون پسوند tex بنویسید"

بخش وسطش هم برای اینه که اگه متنتون فارسی باشه اصولا با xelatex برای کامپایل سر و کار دارید و این میگه که از xelatex استفاده بشه.
مثال:
rubber -m xelatex myfile

جهت اطلاعات بیشتر میتونید من پیجش رو بخونید.

منبعی که منو با rubber آشنا کرد این stackoverflow بود.

در انتها اگه این مطلب براتون مفید بود و دلتون خواست، لطفا برای شادی روح یحیی تجری فرزند حسین یه فاتحه بخونید.

🔅@LinFAQ
🔅@LinAcademy