با تشکر از دوست عزیزمون بابت شروع این مبحث در کانال ،که قرار هست هفته‌ای با یک الی دو پست در این مورد تا حدود مبتدی و اشنایی با کوبر پیش ببره


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



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


https://www.aparat.com/v/rNdW3


@code_crafters

با تشکر از تمامی دوستانی که در متینگ امشب مارو همراهی کردن ،متینگ امشب چیزی در حدود چهار ساعت طول کشید

طبق وعده‌ی هفته قبل پیش رفتیم:
۱-نیم ساعت در خصوص امنیت صحبت کردیم
Speak about SSTI Attack

۲-مهمانان ما تشریف اوردن راجب استارتاپشون حرف زدن از خودشون گفتن و حوزه کاریشون و چالش‌هایی که داشتن

۳-در خصوص ساختار یک پروژه بزرگ حرف زدیم و بخشی از کدهارو دیدیم


در متینگ امشب در خصوص مسائل زیر بصورت جسته گریخته صحبت شد:
۱-نقش مدیر cto
۲-توزیع تسک
۳-بیگ دیتا و پلتفرم و ابزارهای مناسب
۴-معماری مونولوتیک
۴-معماری چند لایه
۵-معماری میکروسرویس و توضیح اجمالی آن
۶-استفاده از دپندنسی‌ها ،کتابخونه‌ها و کاستومایز کردن و توسعه شخصی آن مناسب برنامه و چالش‌های موجود در هنگام ارتقا ورژن
۷-توزیع درخواست‌ها در وب سرور
۸-پیگیری و تحلیل رفتار کاربران بصورت دستی و ماشینی
۹-تفکر و تفاوت عملکرد sql ,nosql
۱۰-هیبرید کش
۱۱-مدیریت صحیح داده‌های ورودی، ذخیره،حذف و چند رویکرد متفاوت در این حیطه
۱۲-انتقال داده‌های دیتابیس بین dbms های مختلف


در متینگ هفته بعد قرار بر این شد که موارد زیر رو بررسی کنیم:
۱-یک موضوع امنیتی دیگر در حدود نیم ساعت
۲-بررسی یکی از پروژه‌های ناموفق و دلایل ان و بررسی محتوای کد آن
۳-صحبت بیشتر در خصوص بیگ دیتا و ابزارهای مختلف
۴-بررسی اجمالی سه متینگ قبلی و ادامه موضوع اصلی که بررسی ساختار پروژه‌های بزرگ سازمانی می باشد


#meeting

@code_crafters

https://www.researchgate.net


گاهی اوقات حس ناکافی بودن میاد سراغمون و دلمون میخواد راجب اون موضوع مدنظرمون بیشتر و عمیقتر بخونیم و یاد بگیریم

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


لینک بالا رو داشته باشید که حس ناکافی بودنتون رو حداقل سرکوب کنه


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


@code_crafters

https://haseebkamal.com/the-dependency-inversion-principle-explained-in-python/


توضیح پنج اصل SOLID برای پایتون کاران با مثال و کد


#principles

@code_crafters

«تفکر مراقبتی»


همان طور که
یک قطعه موسیقی، انعکاس تفکر در اصوات است،

یک داستان انعکاس تفکر در زبان است

و یک نقاشی انعکاس تفکر در نقش هاست و هیچ نقاشی نمی تواند در نقاشی اش تفکر را منعکس سازد مگر این که قادر به تحسین رنگ ها باشد و برای آن ها ارج قائل باشد…

«تفکر مراقبتی» نیز انعکاس در ارزش ها می باشد.

بنابراین برای اندیشیدن در باب ارزش ها، فرد
می بایست قادر به شناخت و تحسین آن چه که ارزش محسوب
می گردد، باشد!


چه قدر تفکر مراقبتی داریم؟


@code_crafters
#free

افزایش کارایی دیتابیس در پردازش کوئری های ما بسیار حائز اهمیت هست


در لینک زیر مواردی ازش رو‌میتونید بخونید


@code_crafters


https://artarad.ir/%D8%B1%D8%A7%D9%87%DA%A9%D8%A7%D8%B1%D9%87%D8%A7-%D9%88-%D8%AA%DA%A9%D9%86%DB%8C%DA%A9%D9%87%D8%A7%DB%8C-performance-tuning//

🔆 آمدن Api های اکسل برای پایتون!

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

🔺بزودی این فیچر بصورت رسمی اضافه میشود.

🌐 Github Link

@ZenMaxe

Fat Models or business logic

مدل های جنگو دیتابیس هستند، که اونهارو تبدیل به انتخاب بدی برای اراعه رابط لایه سرویس به لایه ذخیره سازی (persistence layer) میکنه. مدل های جنگو ذاتا در پنهان کردن، کپسوله کردن و محافظت کردن از جزییات پیاده سازی در برابر مصرف کننده که اهمیت نمیده یا اجازه دسترسی بهش رو نداره، ناتوان هست.

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

بیزینس لاجیک شما به لایه سرویس یا لایه عملیاتی تعلق داره. لایه سرویس یک رابط ثابت رو به تمام بخش های اپلیکیشن اراعه میده. لایه سرویس شما متد های معقول و قابل درکی رو برای انسان داره مثل " “register user یا “associate device with user”. این متد ها دربردارنده بیزینس لاجیک شما هستند که معمولا نیاز هست تا قبل به وجود امدن مدل دیتابیس اعمال بشوند یا تعدادی بیزینس لاجیک رو پس از بازیابی مدل های موجود اعمال بکنند. لایه سرویس شما اون جزییات زیاد و درهم‌برهم و غیر ضروری وضعیت دیتابیس رو پنهان میکنه. مصرف کننده ها نباید به جزییات اهمیت بدهند، نباید به انها وابسته باشند( تا بتونیم اونهارو تغییر بدیم بدون اینکه رابط به مشکل بخوره) و همچنین احتمالا نباید به انها دسترسی مستقیم برای ویرایش هر چه میخواهند بدهیم.

.اگر این کار رو انجام ندید و بجاش از مدل های چاق استفاده کنید اتفاقات زیر خواهد افتاد :

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

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

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

@code_crafters

رویکرد ترجیحی :

1- هر دامنه دارای یک لایه سرویس است که شامل بیزینس لاجیک و همچنین یک رابط قابل اعتماد و خوب برای هرچیزی که ممکن است با ان دامنه کار داشته باشد اراعه میدهد. این رابط شامل دادن خطاهای بیزینس لاجیک که معنای مرتبطی با با بیزینس لاجیک ما دارند هست. مثلا خطای "Django.models.DoesNotExist" را نمایش نمیدهد و اروری برمیگرداند که به مصرف کننده بگوید چه اشتباهی رخ داده.

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

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

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

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

@code_crafters

بخش کوچکی از روزمرگی‌های سازمانی

بدخطم منتها پست آموزشی نیست😅😅😅
اون لایه که با رنگ آبی فلش کشیدم لایه جدیدمون هست که میخوام اجرایی بشه در سیستم

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

#daily

@code_crafters

اسکوپ کریپ چیست؟؟؟

این پست مناسب دوستانی هست که پروژه‌های فریلنسری میگیرن


در طول این سالها با دوستانی که برخورد کردم یک موضوع مشترک وجود داشت

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



https://productive.io/blog/scope-creep-prevent/


https://mag.hostiran.net/scope-creep-web-design/


@code_crafters

به قول حضرت عشق جان من است او. 3>
مگه بهتر از کامپیوترها هم هست؟ :)
اولین خاطره کامپیوتریت چی بود؟
#Nostalgic
🧑‍💻👩‍💻 @code_crafters

اجایل مجموعه ای از اصول و ارزش ها هست که معمولا در توسعه نرم افزار استفاده میشود و باعث افزایش بهره وری تیم میشود.

Agile (چابک)
اجایل یک رویکرد تکراری و افزایشی است که بر انعطاف پذیری، همکاری، و اراعه ارزش ها به مشتریان تاکید دارد.

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

12 اصل اجایل پیشنهاد داده است که به شما برای حفظ این ارزش ها کمک کند :

1- رضایت مشتری در اولویت قرار داشته باشد. یک تیم توسعه نرم افزار باید پیوسته و به طور مداوم محصول خود را اراعه دهد.

2- از هر گونه تغییرات استقبال بشود، حتی اگر پروژه در مراحل پایانی قرار دارد.

3- تحویل زود به زود نرم افزار قابل استفاده به مارکت. طبق اصل 1و2 شما باید سریع نرم افزار رو اراعه بدید و تغییرات رو اعمال بکنید. اجایل به شما یک فاصله زمانی 2-3 هفته تا 2-3 ماهه پیشنهاد میدهد تا نرم افزار خود را در مارکت پابلیش کنید. ترجیح به فاصله زمانی کمتر است.

4- ذی‌نفعان کسب و کار و دولوپر ها باید به صورت روزانه با هم مشارکت داشته باشند.

5- مسئولیت پروژه را برعهده افراد با انگیزه بگذارید. به انها ازادی عمل دهید و ان‌ها به دلیل با انگیزه بودنشان بسیار جدی پیگیر پروژه خواهند بود.

6- تیم نرم‌افزار به صورت رو در رو اطلاعات را به همدیگر انتقال دهند زیرا بیشترین تاثیر را دارد.

7- معیار سنجش تیم، خروجی کار باشد.

8- توسعه پایدار به صورت ثابت و مداوم حامیان مالی و توسعه دهندگان.

9- توجه مداوم به برتری فنی و طراحی خوب چابکی رو افزایش میدهد.

10- سادگی – هنر افزایش کار های انجام نشده. از افزودن فیچر های غیر ضروری اجتناب کنید.

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

12- در فواصل منظم اعضای تیم بر چگونگی موثر تر شدن همفکری میکنند و سپس تیم خود را بر اساس بازتاب این تفکر باید اصلاح کنند.

اجایل بر کوچک کردن بخش های پروژه و تسک های قابل مدیریت تمرکز میکند که بهشون استوری های یوزر میگویند.
اجایل از تیم های کراس-فانکشنال ( تیم هایی که اعضایی با مهارت های مختلف دارند)، همکاری اعضای تیم و مشارکت مکرر مشتری در طول فرایند توسعه نرم افزار حمایت میکند.
فریمورک هایی که بر اساس اصول اجایل ساخته شدند مانند اسکرام، کانبان، Extreme Programming (XP) و ... به طور گسترده ای در شیوه های توسعه استفاده میشوند.
اگر شما به اصول و ارزش های اجایل پایبند باشید، تیم شما بدون در نظر گرفتن فریمورک اجایل محسوب میشود و استفاده کردن از یک فریمورک خاص ضروری نیست.
#agile
#project_managment_system


@code_crafters

در پست قبلی با عنوان اجایل موضوعی مطرح گردید و این سوال در ذهن شکل گرفت که آیا امروزه اجایل به ابزاری جهت مانیتورینگ و بهره وری کارمندان تبدیل شده؟؟؟


یکم شرح مسئله کنم

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


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


بهتره با موضوع okr هم آشنا بشیم تا بتونیم در خصوص موضوعات بالا تصمیم گیری به عمل آوریم

لذا در چند پست بعدی در خصوص okr مطالبی رو با شما به اشتراک خواهیم گذاشت


در خصوص پیگیری این دست پست‌ها در کانال هشتگ زیر رو جستجو کنید


#project_managment_system

@code_crafters