امروز وقتی وارد لینکدین شدم کلی پست راجب پیشنهاد خوندن کتاب fluent python دیدم.

خیلی خوشحالم که این کتاب داره دیده می‌شه؛ یک زمانی بود آدما زبان برنامه‌نویسی رو درست نمی‌شناختند ولی بخاطر جوی که راه افتاده بود
Clean coder, clean code , ....

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

https://t.iss.one/pyHints/s/3

#موقت

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

ابزار KRunner فقط برای جستجو و اجرای برنامه ها نیست ماشین حسابم هست حتی تبدیل واحد هم می‌کنه خیلی بدرد بخوره مخصوصا برای تبدیل سریع بیت به واحد های خوانا

توی دسکتاپ KDE با Alt + Space ران می‌شه

@Linuxor

چون زیاد سوال شد :

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

استفاده کنید هم باحاله هم کاربردی
داستانش چیه :

KIMI
یه مدل زبانی جدید چینیه که می‌تونه همزمان تا 50 فایل رو بررسی کنه و متن تا 200,000 توکن رو پردازش کنه. حتی ظاهرشم هم خیلی شبیه دیپ‌سیک هستش

لینک:
https://kimi.ai

@DevTwitter | <Mr.programmer/>

Skill issue

#fun
@CleverDevs - @CleverDevsGp

۲۶ اسفند۱۳۷۶ اتوبوس حامل نخبگان ریاضی شرکت‌کننده در مسابقات ریاضی در راه بازگشت به تهران در جاده انديمشک-پل‌دختر به دره سقوط ‌كرد.

در این سانحه ۲ راننده و ۷ نفر از دانشجویان نخبه رياضی دانشگاه‌های شريف و تهران كشته شدند.

مریم میرزاخانی یکی از بازماندگان این فاجعه بود.

روحشان شاد🙏

🔵 عنوان مقاله
Keep Postgres Maintenance from Slowing Down Your Go App

🟢 خلاصه مقاله:
جای خود را برای یادگیری روش‌های پیشگیرانه نگهداری تضمین کنید که خطرات پنهان کارایی پایگاه داده،

مانند

پرس و جوهای کند (slow queries)،

رفتار نقطه بازرسی (checkpoint behavior)،

و مسائل اتصال (connection issues)،

را پیش از آنکه تشدید شوند، آشکار می‌سازند.

🟣لینک مقاله:
https://golangweekly.com/link/166476/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

خب حالا که خیلی زیاد حرف از بیکار شدن برنامه نویس ها توسط AI هست پینک اورکا ی عزیز زحمت کشیدن یک ویدیوی کوتاه آموزشی تهیه کرده در این باره، امیدوارم که به دردتون بخوره

#fun

@PhiloLearn

تبیین عمیق تر #معماری و #معمار - تو مو بینی و مجنون پیچش مو ( شعری از وحشی بافقی » فرهاد و شیرین)

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

قطعا الگوی Retry را تابحال شنیده اید، الگویی که در ذات بدلیل فهم ناقض و بدتر از آن بدلیل فقدان #تفکر_سیستمی به شدت می تواند #تجربه_کاربر را دچار خدشه کند. به طور مثال اگر و صرفا اگر قرار به پیاده سازی این الگو باشد، عموما این الگو توسط فرآیندهای سیلو شده در تیم های بک اند انجام میپذیرد! دلیل این انتخاب هم عموما وقتی نیازمندی مطرح می شود، به دلیل عدم نگاه سیستمی و وجود مرزهای بوجود آمده (فرانت/بک) فرآیند به شکل صحیح قابلیت ترسیم حتی برای خود توسعه دهندگان ندارد. به دلیل همین فقدان ها یعنی نبود دانش موثر در تصمیم گیری ها، حتی شاید از پیاده سازی این الگو بدلیل پیچیدگی ها زیاد آن صرفنظر می شود و براحتی فراخوانی مجدد فرآیند را به شکل ناشیانه ای به کاربر منتقل می کنند. کاربر کلافه از فرآیندهای ناقض و خسته کننده، اگر با بازار رقابتی روبرو باشد قطعا به عنوان یک کاربر ناراضی سازمان را رها می کند و در اکثر اوقات حتی بدون داده مناسب برای سازمان و حتی خود فرد در خصوص چرایی این اتفاق، سازمان صرفا تماشاگر از دست دادن سهم بازار خواهد بود. هر چند متاسفانه در سازمان های وابسته به حکومت کشورها، این موضوع مهم بدلیل ذات انحصارگرایانه ارائه خدمت عملا منجر به ترک سازمان نمی شود ولی منجر به مشکلات اجتماعی مثل بالا رفتن سطح خشونت در جامعه خواهد شد. اتفاقی که متاسفانه در خیلی از اوقات صرفا با سرکوب معلول (خشم، ...)، بدون حل علت، به دنبال پنهان کردن آنها هستند. وقتی حرف از حل ریشه ای مشکلات می کنیم، نگاه خطی به هیچ عنوان موثر نمی باشد و قطعا نیاز به #تفکر_سیستمی خواهیم داشت.

بگذارید یک مثال واقعی هم که قبلا بهش برخورد کردم را اینجا مطرح کنیم. در نرم افزار ازکی (azki.com) وقتی قصد ثبت یک پلاک جدید دارید و سرویس مورد نظر به هر دلیلی در دسترس نباشد، به شکل عجیبی اول درخواست با استفاده از پروتکل HTTP با کد وضعیت 200 پاسخ داده می شود ولی در عملا در بدنه خطایی ارسال می شود با مضمون به زبان فارسی "در حال حاضر امکان ثبت پلاک وجود ندارد."! متاسفانه بدلیل error handleing ضعیف این نرم افزار، اولا کاربر اصلا متوجه نمی شود که خطایی رخ داده، چون خطایی نمایش داده نمی شود! مشخصا سرویس در سمت سرور قصد برقراری ارتباطی با سرورهای بیمه مرکزی یا پلیس راهور را دارد و بدلیل عدم پاسخگویی آنها، امکان ثبت مهیا نمی باشد. هر چند مشخص نیست. بدلیل ذات طولانی بودن مدت درخواست (16 ثانیه) می شود حدس زد که در سمت سرور حداقل چندبار تلاش (الگوی نام برده شده) اتفاق افتاده است! ولی آیا کاربر عادی 16 ثانیه صبر میدهد بدون اینکه بداند فرآیند در بدون چه وضعیتی می باشد؟ قطعا اگر داده مناسب جمع آوری شود براحتی می توان ادعا کرد بالای 50% از کاربرها به عنوان وجود مشکل به مرورگر دستور بارگزاری مجدد صفحه را می دهند!
قصد نیست در چند خط کوتاه پاسخ قطعی به موضوع بدهیم، ولی از دید شما بهتر نیست فرآیند به شکل عمومی تر دیده بشه و در سمت نرم افزار کاربر، در هر حال فرآیند اخذ اطلاعات و نمایش به عنوان پلاک جدید با یک وضعیت مثلا در حال بررسی نمایش داده شود و در فرآیندهای مستقل تر موضوع تایید پلاک انجام پذیرد؟ و موضوع الگوی تکرار بدون نیاز به دخالت کاربر در زمان مناسب تر انجام پذیرد؟ عموما وقتی در حال ایجاد یک خطا هستید به این فکر کنید که مخاطب خطا کیست؟ آیا اصولا نیاز به وجود این خطا می باشد یا نیاز به اصلاح یا ایجاد فرآیند درست دیگر در جهت حل مشکل در فرآیند. در کامنت های همین پست عکس های مرتبط با ازکی را قرار میدهم که ملموس تر باشد موضوع.

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

تبیین عمیق تر #معماری و #معمار

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

احتمالا با الگوی Retry آشنا هستید، الگویی که در ذات بدلیل فهم ناقض و فقدان #تفکر_سیستمی می تواند #تجربه_کاربر را دچار خدشه کند. به طور مثال حتی اگر قرار به پیاده سازی این الگو باشد، عموما این الگو توسط فرآیندهای سیلو شده در تیم های بک اند انجام میپذیرد! بدلیل عدم نگاه سیستمی و وجود مرزهای بوجود آمده (فرانت/بک) فرآیند به شکل صحیح قابلیت ترسیم حتی برای خود توسعه دهندگان نیز ندارد. به دلیل همین فقدان ها یعنی نبود دانش موثر در تصمیم گیری ها، حتی شاید از پیاده سازی این الگو بدلیل پیچیدگی ها زیاد آن صرفنظر می شود و براحتی فراخوانی مجدد فرآیند را به شکل ناشیانه ای به کاربر منتقل می کنند. کاربر کلافه از فرآیندهای ناقض و خسته کننده، اگر با بازار رقابتی روبرو باشد قطعا به عنوان یک کاربر ناراضی سازمان را رها می کند و در اکثر اوقات حتی بدون داده مناسب برای سازمان و حتی خود فرد در خصوص چرایی این اتفاق، سازمان صرفا تماشاگر از دست دادن سهم بازار خواهد بود. هر چند متاسفانه در سازمان های وابسته به حکومت کشورها، این موضوع مهم بدلیل ذات انحصارگرایانه ارائه خدمت عملا منجر به ترک سازمان نمی شود ولی منجر به مشکلات اجتماعی مثل بالا رفتن سطح خشونت در جامعه خواهد شد. اتفاقی که متاسفانه در خیلی از اوقات صرفا با سرکوب معلول (خشم، ...)، بدون حل علت، به دنبال پنهان کردن آنها هستند. وقتی حرف از حل ریشه ای مشکلات می کنیم، نگاه خطی به هیچ عنوان موثر نمی باشد و قطعا نیاز به #تفکر_سیستمی خواهیم داشت.

بگذارید یک مثال واقعی هم که قبلا بهش برخورد کردم را اینجا مطرح کنیم. در نرم افزار ازکی (azki.com) وقتی قصد ثبت یک پلاک جدید دارید و سرویس مورد نظر به هر دلیلی در دسترس نباشد، به شکل عجیبی اول درخواست با استفاده از پروتکل HTTP با کد وضعیت 200 پاسخ داده می شود ولی در عملا در بدنه خطایی ارسال می شود با مضمون به زبان فارسی "در حال حاضر امکان ثبت پلاک وجود ندارد."! متاسفانه بدلیل error handleing ضعیف این نرم افزار، اولا کاربر اصلا متوجه نمی شود که خطایی رخ داده، چون خطایی نمایش داده نمی شود! مشخصا سرویس در سمت سرور قصد برقراری ارتباطی با سرورهای بیمه مرکزی یا پلیس راهور را دارد و بدلیل عدم پاسخگویی آنها، امکان ثبت مهیا نمی باشد. هر چند مشخص نیست. بدلیل ذات طولانی بودن مدت درخواست (16 ثانیه) می شود حدس زد که در سمت سرور حداقل چندبار تلاش (الگوی نام برده شده) اتفاق افتاده است! ولی آیا کاربر عادی 16 ثانیه صبر میدهد بدون اینکه بداند فرآیند در بدون چه وضعیتی می باشد؟ قطعا اگر داده مناسب جمع آوری شود براحتی می توان ادعا کرد بالای 50% از کاربرها به عنوان وجود مشکل به مرورگر دستور بارگزاری مجدد صفحه را می دهند!
قصد نیست در چند خط کوتاه پاسخ قطعی به موضوع بدهیم، ولی از دید شما بهتر نیست فرآیند به شکل عمومی تر دیده بشه و در سمت نرم افزار کاربر، در هر حال فرآیند اخذ اطلاعات و نمایش به عنوان پلاک جدید با یک وضعیت مثلا در حال بررسی نمایش داده شود و در فرآیندهای مستقل تر موضوع تایید پلاک انجام پذیرد؟ و موضوع الگوی تکرار بدون نیاز به دخالت کاربر در زمان مناسب تر انجام پذیرد؟ عموما وقتی در حال ایجاد یک خطا هستید به این فکر کنید که مخاطب خطا کیست؟ آیا اصولا نیاز به وجود این خطا می باشد یا نیاز به اصلاح یا ایجاد فرآیند درست دیگر در جهت حل مشکل در فرآیند. در کامنت های همین پست عکس های مرتبط با ازکی را قرار میدهم که ملموس تر باشد موضوع.

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

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

او همچنین اولین کسی است که ایده یک دانشنامه تمام آزاد مثل ویکی‌پدیا را داد.



@SohrabContents