CodeCrafters

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

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

قوه مجریه (دولت) دستور اتصال اینترنت رو میده قوه قضاییه دستور لغو، دستور قوه مجریه رو میده یعنی جوری شده کسی که نماینده و منتخب ملت هستش، توسط کسی که منتخب یک سازمان هستش داره کنترل میشه 😐😐😐 از فردا رییس جمهور مملکت بابت خوردن آب هم باید اجازه بگیره از یکعده خاص؟؟؟ میزان رای ملت امام بزرگوار هم دیگه نامیزان شده، توسط کی؟؟؟ توسط فیلترشکن فروش‌ها چند میلیون نفر بیکار شدیم بخاطر حضور مافیای اینترنت در قوه قضاییه رای من کو؟؟؟

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

آخرین مجله اکونومیست رو خوندم، که با سرتیتر بزرگ نوشته بود (آخرالزمان شغل‌ها) خب ماجرا از چه قراره؟؟؟ مجله راجب هوش مصنوعی و شغل‌ها صحبت کرده بود، موارد زیادی از بدبینی و خوش بینی و پیشنهاد راهکار برای دولت‌ها و ... مطرح کرده بود ولی هیچ چیزی واقعیت رو که با آمار و ارقام نشون میده رو، نمیتونه نشون بده طبق این نمودار از زمان ظهور chat bot ها میزان اشتغال دائم مهندسین علوم داده، مهندسین نرم افزار، مهندسین علوم کامپیوتر از ۷۷ درصد به نزدیک ۵۰ درصد رسیده و این فقط برای سه سال هستش که از نسخه ضعیفش تا الان که قویترین نسخه اون شبکه شبیه به نصف شبکه عصبی انسان رو داره رخ داده اینکه چه برداشت یا تفسیری از اون داشته باشید برعهده خودتون هستش و این آمار برای کشورهایی هستش که تو تکنولوژی بشدت سرمایه گذاری کردن و شاه رگ بزرگ اقتصادهای بزرگ جهان هستند اینکه مجله یه جاهایی اومده یسری حرفا از یکسری ها گفته یا راهکار داده و .... به معنای واقعیت یا پیروی سیاست مدارها از اون نیستش اعداد و ارقام واقعیت‌ها رو میگن @codecrafters

هر اتفاقی افتاد یادتون نره ما یک ملتیم که جز دل‌های همدیگه جایی نداریم

تهران رو زدن

یکی از بچه‌های گروه اکانت gpt پذمیوم رو با قیمت خوبی روی ایمیلتون فعال میکنه براتون اگه نیتز داشتین بهش پیام بدین

دانشگاه تهران قیام شد

از گروه مستقل تست (ITG) تا مهندس نرم‌افزار در تست (SDET) 1️⃣ تفکیک «صحت» و «تصدیق» در مهندسی نرم‌افزار کیفیت نرم‌افزار یکی از چالش‌برانگیزترین موضوعات در صنعت نرم‌افزار است. در صنایع فیزیکی، کیفیت با متریک‌های عینی مانند وزن، ضخامت، مقاومت یا ابعاد قابل اندازه‌گیری است؛ اما در نرم‌افزار، کیفیت مفهومی چندبعدی و تا حدی انتزاعی است. در مهندسی نرم‌افزار، کیفیت معمولاً از طریق دو مفهوم بنیادین بررسی می‌شود: ✅ صحت (Verification) «آیا سیستم را درست ساخته‌ایم؟» تمرکز بر درستی پیاده‌سازی، منطق کد و انطباق با طراحی. بررسی صحت الگوریتم‌ها پوشش تست عدم وجود باگ منطقی رعایت استانداردهای کدنویسی این موضوع بیشتر به درون سازمان و تیم توسعه مربوط است. ✅ تصدیق (Validation) «آیا سیستم درست را ساخته‌ایم؟» تمرکز بر برآورده شدن نیازهای واقعی مشتری. انطباق با نیازمندی‌ها تجربه کاربری مناسب حل مسئله واقعی کاربر این موضوع به بیرون سازمان و رضایت مشتری مرتبط است. 2️⃣ کیفیت، مسئولیت جمعی است کیفیت نرم‌افزار: فقط مسئولیت تیم توسعه نیست فقط با تست انتهایی حاصل نمی‌شود فقط با سخت‌گیری افراطی ایجاد نمی‌شود فقط با تأیید یک گروه خاص تضمین نمی‌شود در رویکردهای مدرن، گروه مستقل تست (ITG) از ابتدای پروژه در کنار تیم توسعه قرار می‌گیرد، نه فقط در فاز پایانی. در چارچوب‌های چابک، تستر یکی از نقش‌های کلیدی تیم است و از مرحله تحلیل نیازمندی‌ها تا تحویل محصول حضور دارد. این حضور باعث می‌شود: بدهی فنی کاهش یابد تصمیمات فنی پخته‌تر شوند ریسک معماری کاهش پیدا کند بلوغ فنی تیم افزایش یابد و این دقیقاً همان نقطه‌ای است که نقش کلاسیک Tester به سمت SDET (Software Development Engineer in Test) تکامل پیدا می‌کند. 3️⃣ کیفیت از دید استاندارد در استاندارد قدیمی کیفیت نرم‌افزار یعنی: ISO/IEC 9126 این استاندارد کیفیت را در چند بعد تعریف می‌کند: قابلیت نگهداری (Maintainability) قابلیت استفاده مجدد (Reusability) در دسترس بودن (Availability) اطمینان‌پذیری (Reliability) جامعیت (Integrity) انعطاف‌پذیری (Flexibility) قابلیت حمل (Portability) درستی (Correctness) این نگاه نشان می‌دهد کیفیت صرفاً «کم بودن باگ» نیست. 4️⃣ متریک کلیدی: پیچیدگی سیکلی (Cyclomatic Complexity) یکی از مهم‌ترین متریک‌های ساختاری کیفیت کد است Cyclomatic Complexity (CC) این متریک نشان می‌دهد:

چند مسیر تصمیم‌گیری مستقل در یک ماژول یا تابع وجود دارد.

هرچه این عدد بالاتر باشد: احتمال خطا بیشتر تست‌نویسی سخت‌تر نگهداری دشوارتر طبقه‌بندی پیشنهادی: مقدار cc < 5 وضعیت عالی مقدار cc < 10 وضعیت مطلوب مقدار cc < 15 در معرض ریسک (نیاز به تست بیشتر) مقدار cc > 20 وضعیت بحرانی (نیاز به بازنگری معماری) این متریک می‌تواند برای هر: ماژول کلاس تابع متد محاسبه شود. 5️⃣ ابزار محاسبه CC در پایتون در زبان پایتون می‌توان با کتابخانه زیر این مقدار را محاسبه کرد: Radon نمونه استفاده: radon cc your_file.py -a این ابزار می‌تواند در: CI/CD Code Review Quality Gate سیاست‌نامه کیفیت سازمان استفاده شود. 6️⃣ گذار از ITG به SDET در مدل سنتی: گروه تست مستقل (ITG) تست در انتهای پروژه تمرکز بر کشف باگ در مدل مدرن SDET: مهندس تست بخشی از تیم توسعه است تست خودکار می‌نویسد در طراحی معماری اثر می‌گذارد متریک‌های کیفیت را تحلیل می‌کند در تصمیمات فنی مشارکت دارد در واقع SDET فقط «کشف‌کننده خطا» نیست؛ او «معمار کیفیت» است. جمع‌بندی کیفیت نرم‌افزار حاصل: صحت (Verification) تصدیق (Validation) معماری سالم پیچیدگی کنترل‌شده حضور تست از ابتدا بلوغ مهندسی تیم و در نهایت، کیفیت یک فعالیت انتهایی نیست؛ بلکه یک فرهنگ سازمانی است. با تشکر از هوش مصنوعی برای تمیز کردن متن #test @code_crafters

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

تست بعنوان یک تفکر سیستمی در سیستم‌های مبتنی بر نرم افزار ما دو موضوع کلی داریم یک فرایند نرم افزار: تعیین چهارچوب دو مهندس نرم افزار: تعیین تکنولوژی در طی تولید یک نرم افزار نقش مهندس نرم افزار بشدت کلیدی هستش که در همه جای یک سیستم بارها و کرات دیده میشه چرا انقدر این نقش کلیدی هستش؟؟؟ در طی این پروسه ما با حالت‌های مختلف زیاد ناشناخته روبرو هستیم که نیاز داریم همیشه از یک نگاه سیستماتیکی بهش پرداخته بشه و این اصلی ترین وظیفه مهندس نرم افزار هستش یک سیستم در طی روند زیر تولید میشه: تحلیل -» طراحی -» توسعه -» آزمایش -» استقرار بحث ما بر سر موضوع آزمایش هستش کلیت تست‌ها به دو دسته کلی تقسیم میشن: تست جعبه سفید: آزمایش منطق داخلی کدهای نوشته شده تست جعبه سیاه: آزمایش رفتار سیستم اینکار عمدتا توسط تسترها (QA) صورت میگیره و مهندس نرم افزار با ارائه اسناد و دیاگرام‌های پروژه در روند تست و پلن تست حضور خواهد داشت اما چرا ما نیاز به انواع مختلفی از تست داریم، جواب خیلی ساده هستش بعلت وجود پیچیدگی‌های مختلف و سیستم‌های گوناگون نیاز به تست در شکل‌های مختلف در چرخه حیات نرم افزار شکل گرفت بیایید یک مثال ساده بزنیم کدهای تولید شده توسط تیم توسعه ممکنه ساختار متفاوتی داشته باشه که با رویکردهای مختلفی نوشته شده و پیاده سازی گشته هر نوع ساختار نیاز به یک شیوه خاص جهت تست  هستش،جایی که تیم توسعه خوب عملکرده باشه تست جعبه سفید همیشه کار میکنه و این عالیه، اما اگه بد عمل کرده باشه تست جعبه سفید هزینه بردار، سخت، زمانبر، شکننده و گاها غیر ممکن میشه اما توسعه متوقف میشه؟؟؟ نه ما جایی که به هر عنوانی نتونیم تست منطقی انجام بدیم، تست رفتاری (جعبه سیاه) انجام میدیم یعنی یک فرآیند رو در نظر میگیریم و پیش میبریم، این منجر میشه که توسعه با تعطیلی روبرو نشه نمونه بارز تست جعبه سفید، تست واحد هستش و نمونه بارز تست جعبه سیاه e2e هستش دقت داشته باشید که بر اساس نوع سیستم شما ممکنه تست متفاوت باشد، یعنی ما یجا تست‌هایی داریم بر اساس task, user story, future use-case اما در سبستمی متفاوت تر ما تست‌هایی از قبیل TCCN, Z-object, RTRSM داریم و یکجایی هم BDD داریم مهمترین موارد در تست سیستم چی هستش؟؟؟ تست ماژول‌های حیاتی تست ماژول‌های پر خطا ساختار داده ورودی و خروجی انتظار رفتار مورد قبول از سیستم بررسی نوع ارتباط داخلی و بیرونی و ... آیا همه تست‌ها با کد زده میشن؟؟؟ خیر برخی از تست‌ها دستی و انسانی هستند. و برخی تست ها در محیط آزمایشگاهی که بهشون میگیم HIL test و SIL test آیا همیشه مقادیر درست تست میشن؟؟؟ خیر گاهی بر حسب نیاز مقادیر غلط تست میشن تا چک کنیم رفتار سیستم رو و بتونیم مانع جلوگیری فروپاشی سیستم در اون نقطه بشیم در نهایت آیا همه چیز تست میشه؟؟؟ خیر اما تست بصورت پوشش کامل باید باشد در نهایت فراموش نکنیم که تست از نگاه بالغ یعنی بررسی اینکه سیستم در موقعیت اشتباه و خطا، چه رفتاری از خودش نشون میده #test @code_craftets

اخیرا مقامات کشور زیادی پیامک نمیدن؟؟؟ یعنی فهمیدن هیچکس رسانه‌هاشون رو باور و پیگیری نمیکنن میخوان با پیامک حرف بزنن گویا نمیدونن اسپم میشه😁😁😁😁

کار ریموت خوبه؟؟؟ اگه عادت کنی که روزای تعطیل هم کار کنی آره اونم تا قبل خواب😐😐😐😐

بچه‌ها خودتون یا اطرافیاتون اگه قبلا با پلتفرم مودل (moodle) کار کردن ممنون میشم بهم معرفی کنین

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

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

چند نکته جالب بهتون بگم یکی استفاده از پکیج tox هستش، که جهت تست کردن پروژه در محیط‌های مختلف پایتونی هستش، یکی از مسائلی که توسعه دهندگان یک سازمان از نسخه‌های مختلف پایتون استفاده میکنن و نیاز هست چک شود آیا در بازه مشخصی از ورژن‌ها کار میکنه یا نه، یکی از راحت ترین ابزارهای در این حیطه tox هستش که کافیه شما فایلش رو کانفیگ کنید، یعنی بهش بگین با چه نسخه‌هایی کار کنه براتون، چه دپندنسی‌هایی رو نصب کنه و با چه دستوری اجرا و تست بگیره

#File tox.ini

[tox]
envlist = py39, py310

[testenv]
deps = -rrequirements.txt

commands = pytest

علاوه بر این شما میتونید داخل تست‌هاتون از دیباگر داخل پایتون (pdb) استفاده کنید، در نقاط مدنظرتون مقدار breakpoint() رو قرار بدید و بعد از اجرا با pytest دیباگرتون رو با دستورات c ادامه برنامه n رفتن به خط بعد l نمایش خطوط اطراف q بستن دیباگر مدیریت کنید در نهایت یکی از موضوعات جالب pytest داشتن پلاگین‌های بی شمار آن است pytest-cov pytest-django pytest-timeout pytest-async pytest-repeat و کلی پلاگین دیگه که داخل داکیومنت رسمی pytest Refrence guides -> pytest plugin list مشاهده کنید و یک کتاب خوب هم جهت خوندن بهتون معرفی کنم python testing with pytest هستش #test @code_crafters

معماری به مثابه معنا، نه جداسازی سطحی (در سیستم‌های بزرگ و چند لایه) داخل مهندسی نرم افزار (بخش مفاهیم و طراحی) ما با موضوع ساختار برنامه روبرو هستیم، در مهندسی نرم افزار ساختار سیستم باید گرافی باشه، از ساختار پنکیکی جلوگیری که این ساختار به معنای ورشکستی سیستم تلقی میشه، منظور چیه ؟؟؟ یک مثال ساده بگم، شما چهارتا سرویس دارید این چهار سرویس رو در یک نقطه دسترسی قرار ندید یعنی نگید از پورت هشتاد ورودی برو به همه سرویس‌ها بیاید مثال عملی تر بزنیم ما مقادیر: static media UI application(front) api application(backends) رو داریم همه اینها رو در ورودی بعد از web server نزارید، باید ساختار گرافی بسازید، به چه شکل؟؟؟ Nginx => static, media, ui, gateway gateway=> BFF, identity service, cms service BFF => (first level backends) جالب شد BFF چیه؟؟؟ اینجا دقیقا جایی هستش که اوج معماری مدرن شروع میشه تفکیک بین microservice بر پایه DDD یا فقط modularity monoloth (که کابوس شکست سازمان‌هایی هستش که مهندس نرم افزار ندارن) یعنی چی؟؟؟ تفکیک پذیری بر اساس معنا، نه بر اساس جدا سازی خود BFF مخفف backend for front هستش خب بیایید این رو یکم براتون بازش کنم سه مفهوم رو در DDD براتون بگم تا یکم مسئله رو باز کنم Ubiquitous language SAGA Aggregation چطور سرویس‌هامون رو از هم جدا کنیم (سرویس، نه دامنه) در زبان مشترک اگه برای یک مفهوم چند معنا داشتیم اونجا مرزهای سرویس‌هاتون قرار گرفته برای مثال (کاربر: از نگاه پشتیبان یعنی پاسخ گیرنده، از نگاه کسب و کار یعنی مشتری، از نگاه برنامه نویس یعنی یوزر) جنگ بر سر هویت و موجودیت هستش: هویت: هر چیزی که به تنهایی بتونه مستقل معنا بده موجودیت: هر چیزی که جهت معنا نیاز به اتصال داشته باشه واسه مثال: کاربر هویت هستش (دارای شناسه یکتا در سیستم)، مشتری و پاسخ گیرنده موجودیت وابسته به کاربر هستند که شماره تماس، آدرس و ... دارند موضوع بعدی SAGA: انجام یکسری عملیات های رکوردی در یک درخواست، یعنی شما یک درخواست میگیرید و چندین جدول مختلف رو باهاش تاچ و کامیت میکنید (یک الگوی سخت) مورد بعدی aggregation: دریافت یک درخواست و جمع آوری اطلاعات در یک نقطه خاص این سه مورد موضوعاتی هستند که داخل BFF حضور دارن یعنی دامنه اصلی و شاید پشتیبان در رویکرد DDD و اینجا جایی هستش که بهش میگیم شروع business logic و فاز توسعه میکروسرویس شروع میشه و امسدوارم فاز پایه خوبی رو اجرا کرده باشین وگرنه شروع نشده با شکست روبرو هستید خب بیایم راجب bff بیشتر بگیم در این معماری دیگه فرانت برای گرفتن اطلاعات یک صفحه مجبور نیست چندتا درخواست ارسال کنه، یک درخواست میاد سمت شما و پاسخ رو یکجا دریافت میکنه، داخل این لایه شما فقط داده‌های لازم رو برای فرانت صدا میزنید و براش ارسال میکنید به چه شکل؟؟؟ نوع داده و درخواست: اگه درخواست از نوع sync باشه از gRPC استفاده میکنید اگه نوع درخواست async/event driven باشه از rabbitmq در یک زبان ساده بگم بهتون، grpc میاد وسط سرویس‌هاتون قرار میگیره و rabbitmq میاد در کنار سرویس‌هاتون قرار میگیره و در صورت نیاز در جاهای خاصی میاد بین سرویس‌ها نقش ایفا میکنه (جایی که هزاران درخواست میان جهت کامیت در دیتابیس) در نهایت چه اتفاقی افتاد؟؟؟ فرانت هیچگونه اطلاعی از سرویس‌های بکند نداره، coupling ضعیف شکل میگیره و معماری با قدرت به سمت خوبی پیش میره مرزبندی سرویس‌ها رو جدی بگیرید، این یک روند بر اساس تجربه و دانش هستش، و با DTO مرز بین سرویس‌هاتون رو داخل کدهاتون مشخص کنید درخواست در مرحله اول میرسه به view و داخل اون ابتدا serializable اجرا میشه (درستی نوع تایپ مدنظر)، در مرحله بعد وارد سرویس میشه و داخل سرویس ابتدا value object (یک مفهوم دیگه از DDD) صدا زده میشه جهت ولیدیشن و اعتبار سنجی و بعد منطق تجاری روش اجرا میشه و در نهایت به DTO تبدیل میشه و ویو جهت ریسپانس برگردونده میشه request => view - response view => serialization (type data) - service - return DTO service => value objects (validation) - logic (data layer and ...) - DTO @code_crafters