یکی دیگر از موارد مهم در طراحی UI‌ برنامه‌های موبایل توجه به Landscape و یا Portrait بودن است. که هر کدام از این حالت‌ها ویژگی‌های خاص خود را دارند که طراح میتواند به خوبی از این ویژگی‌ها استفاده کند.
مثلا برنامه‌ای را در نظر بگیرد که برای بورس نوشته شده است. در حالت Portrait یک گرید نمایش داده میشود که شاخص بورس در هفته جاری را نشان میدهد. یک UI معمولی همین گرید را در حالت Landscape نمایش میدهد ولی یک UI خوب یک نمودار میله‌ای را نمایش میدهد.

در پست زیر Patternهای مختلفی را که برنامه‌های مختلف در نمایش Landscape استفاده کرده‌اند را بررسی کرده است.

https://www.smashingmagazine.com/2012/08/designing-device-orientation-portrait-landscape/

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

کانال تلگرام:
@SoftwarePhilisophy



___

مفهوم Coupling:

یکی از اتفاقات بد که کم و بیش در هر پروژه ای به مرور پیش می آید، Coupling می باشد. جلوگیری از وقوع Coupling انرژی زیادی را از تیم توسعه خواهد گرفت و کار دشواری است. تیم ها و نفرات تازه کار از Coupling رنج می برند بدون آنکه از آن اطلاعی داشته باشند.
مفهوم Coupling به این معنا است که کلاس های مختلف، متد های مختلف، ماژول های مختلف تا چه میزان در هم تنیده و به هم وابسته اند. تنیدگی کد ها موجب می شود، تا هر تغییری در هر قسمتی، باعث بروز رفتارهای ناصحیح، از کار افتادگی و عدم کامپایل بخش هایی از برنامه شود که فکرش را هم نمی کنید.
وجود Coupling در نرم افزار ها موجب می شود تا هنگام تغییری در متد مربوط به کاربران، قسمتی از کد مربوط به انبارداری کامپایل نشود و یا قسمتی در سیستم سفارشات دچار خطای Run Time شود. 
به تعبیری وجود Coupling موجب می شود هر تغییری در سیستم موجب اثری به نام Ripple Effect و یا تغییرات موجی در نرم افزار شما شود. در نتیجه تغییر در سیستم های Coupled پر هزینه بوده و با عواقب غیرقابل پیشبینی رو به رو خواهد شد. همچنین گسترش این سیستم ها با دشواری مواجه خواهد بود.

* اگر کد شما دارای Coupling و وابستگی کمی باشد، به کد شما
Loosely Coupled گفته می شود، که نشان دهنده هنر مهندسی شما است.
* اگر کد شما دارای Coupling و وابستگی بالایی باشد، به کد شما Tightly Coupled گفته می شود.

یکی از مباحثی که همیشه در تشکیل تیم‌های نرم‌افزاری مطرح است، انتخاب زبان برنامه‌نویسی و یا تکنولوژی‌های مورد استفاده است. مقایسه محصولات موفق و نا موفق نشان می‌دهد هیچکدام از آنها صرفا با یک تکنولوژی و یا یک زبان خاص نوشته نشده‌اند. برای مثال سیستم‌های موفق زیادی وجود دارند که با Java و یا C# نوشته شده‌اند. همچنین سیستم‌های بی کیفیت زیادی نیز وجود دارد که با Java و یا C# نوشته شده‌اند. این حقیقت نشان می‌دهد دلیل موفقیت یا شکست سیستم‌ها نمی‌تواند زبان برنامه‌نویسی باشد. مقاله زیر توضیح می‌دهد که چطور طرز فکر برنامه‌نویس‌ها موفقیت و یا شکست یک سیستم را رقم می‌زند.

https://mehrandvd.me/2015/10/15/software-quality-comes-from-people-not-languages/

#مهران_داودی
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy

___

اگر در دنیای کامپیوتر و نرم‌افزار زندگی می‌کنید، حتما لینک‌ها و صفحه‌های زیادی در طول روز می‌بینید که دوست دارید بخوانید ولی فرصت مطالعه آن‌ها را ندارید. در پست زیر Scott Hanselman توضیح داده است که چگونه «بعدا بخوانید!» یا «Read it Later!». در این پست ابزارهایی معرفی شده‌است که بتوانید با آنها مطالب نخوانده خود را بهتر مدیریت کنید و بتوانید آن‌ها را به زمانی موکول کنید که فرصت دارید.

https://www.hanselman.com/blog/TwoMustHaveToolsForAMoreReadableWeb.aspx

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilisophy



___

مفهوم Polymorphism:

این مفهوم یکی از سه ویژگی اساسی برنامه نوسی شی گرا می باشد. کسی که برنامه نویسی شی گرا می داند با این مفاهیم اجین شده است و لاغیر!
1. فرض کنیم، کلاسی پایه به نام Shape داریم. این کلاس، متدی به نام Draw دارد که وظیفه کشیدن شکل بر روی صفحه را به عهده دارد.
2. کلاس های دلخواهی را از کلاس Shape به ارث می بریم. مثلا کلاس Circle (دایره)، کلاس Rectangle (مستطیل) و کلاس Square (مربع). طبیعتا هر کدام از این ها باید به نحو خاصی بر روی صفحه کشیده شوند و با هم متفاوتند. پس هر کدام از این ها، متد Draw را که از کلاس Shape به ارث برده اند، override می کنند و در این متد، کد مربوط به نحوه کشیدن شان را قرار می دهیم.
3. فرض کنیم کلاسی به نام Monitor داریم. این کلاس وظیفه دارد تا اشکال مختلف را بگیرد و بر روی صفحه نمایش دهد. 
آیا باید به ازای هر شکلی که داریم متد های جداگانه ای در کلاس Monitor تعریف کنیم؟ مثل متد های DrawCircle، DrawRectangle و DrawSquare؟ اگر تعداد اشکال به مرور زیاد شد باید هر بار کلاس Monitor هم تغییر بدهیم و کدهای مربوط به شکل جدید را اضافه کنیم؟ در این صورت اشکال و کلاس Monitor دچار Coupling شده اند!!!

4. راه حل: می توانیم در کلاس مانیتور فقط یک متد تعریف کنیم. نام این متد را Draw می گذاریم. ورودی این متد از جنس کلاس پایه Shape می باشد. در Draw فقط متد Shape.Draw را صدا خواهیم زد و اینجاست که Polymorphism وارد عمل می شود.

- شما یک مستطیل و یا دایره را به متد Monitor.Draw پاس می دهید. چون هر دو از جنس Shape هستن، مشکلی ایجاد نخواهد شد.
- هنگامی که در متد Monitor.Draw، متد Shape.Draw را صدا می زنیم، Polymorphism موجب می شود تا به طور خودکار CLR -مسئول اجرای کد- بداند که شی Shape در واقع از نوع دایره یا مستطیل می باشد و هوشمندانه متد مربوط و خاص به همان کلاس را اجرا می کند و نه کد مربوط به کلاس Shape را!

مفهوم Polymorphism موجب می شود که در هنگام اجرای کد (Run Time)، رفتار های متفاوتی از متد مربوط به کلاس Shape سربزند. این متد گاهی مربع می کشد و گاهی دایره. استفاده از این روش، یکی از راه های کاهش Coupling می باشد.

https://msdn.microsoft.com/en-us/library/ms173152.aspx

در مورد WebApi مطالب زیادی وجود دارد. ولی پست زیر با جزئیات خیلی زیادی کل چرخه پیغام‌های HTTP را در WebApi Pipeline به طور کاملا عملی بررسی کرده‌است. خواندن این مقاله می‌تواند خیلی به درک مفهوم Pipeline در این معماری‌ها کمک کند. نکته خوب این مقاله این است که در آن OWIN که یک معماری بسیار عالی برای استفاده و پیاده سازی WebApi است توضیح داده شده‌است. معماری OWIN کمک می‌کند بتوانید WebApi را مستقل از جایی که قرار است در آن Host شود طراحی کنید و برای مثال بتوانید آن را حتی در یک برنامه Console Application استفاده کنید.

https://www.c-sharpcorner.com/article/webapi-pipeline-revealed-a-true-practical-approach/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilisophy



___

مهندسی معکوس و یا Decompile کردن کدهای دات نت:
در پلتفرم دات نت، فارغ از زبانی (سی شارپ، F# و ویژوال بیسیک و ....) که برای برنامه نویسی استفاده می کنیم، کد های ما پس از کامپایل شدن تبدیل به یک زبان میانی به نام IL و یا Intermediate Language می شوند. به علت اینکه تمامی کد ها در نهایت به یک "زبان واحدِ میانی" تبدیل می شوند، می توانیم در هر زبانی که هستیم که از کتابخانه هایی که توسط زبان های دیگر توسعه پیدا کرده اند استفاده کنیم.
در هنگام اجرا، زبان IL به زبان ماشین کامپایل می شود و همین جا یکی از دلایل کندی نرم افزار های توسعه داده شده با دات نت در قیاس با زبان های C و یا C++ می باشد. چرا که باید زمانی را صرف کامپایل کد ها به زبان ماشین نماییم.
زبان IL، اگر چه شبیه به زبان Assembly است ولی به پیچیدگی و گنگی آن نیست. در کد های IL اطلاعات بسیار زیادی در مورد کد اصلی ما نگهداشته می شود. به همین خاطر روند مهندسی معکوس کد ها از زبان IL به زبان اصلی بسیار ساده صورت خواهد پذیرفت. یعنی می توانیم با داشتن یک dll یا فایل exe کد های اصلی را بدست بیاوریم. ابزارهای بسیار متنوعی برای این منظور وجود دارند.

برگرداندن کد ها به جز استفاده های غیر قانونی، برای یادگیری و فهمیدن رفتار کتابخانه های دیگران بسیار مفید می باشند. 
ابزار های:
1. https://ilspy.net
2. https://www.jetbrains.com/decompiler

ویژگی float در CSS یکی از ویژگی‌هایی است که نکات ریز خیلی زیادی دارد. به همین دلیل استفاده از آن معمولا در ابتدا خیلی ساده به نظر می‌رسد، ولی بعد از اینکه مدل صفحه پیچیده‌تر شد و تعداد زیادی از دستورات شروع به تاثیرگذاری روی یکدیگر کردند دیگر مدیریت آن آسان نیست. پست زیر که به زبان فارسی هم هست توضیحات خیلی خوبی در مورد توصیف عملکرد این ویژگی داده‌است که برای تمام کسانی که با CSS کار می‌کنند مفید است.

https://css-tricks.ir/css_reference/float/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilisophy



___

به نظر می‌رسد که تکنولوژی آنقدرها هم که به نظر می‌رسد به موفقیت پروژه‌ها کمک نمی‌کند! برای مثال در کتاب «Peopleware: Productive Projects and Teams» عامل مهمتری را برای موفقیت یک پروژه معرفی کرده‌است: «اعتماد افراد به یکدیگر». در تیمی که افراد به یکدیگر اعتماد نداشته باشند ریسک خیلی بالایی متوجه پروژه می‌شود و آینده آن به شدت در خطر خواهد بود.

Better technology seemed unlikely to be much help. If a group of people who had to work together didn’t trust each other.

از کتاب
Peopleware: Productive Projects and Teams
نوشته:
Tom DeMarco & Timothy Lister


#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

کانال تلگرام:
@SoftwarePhilisophy



___

مایکروسافت قریب به یک سال است که یک CSS Framework به نام Office UI Fabric را به صورت متن باز توسعه داده است. با استفاده از این فریم ورک می توانید وب اپلیکشن هایی با شکل و شمایل Office و یا ویندوز 10 طراحی کنید.
https://dev.office.com/fabric

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


https://mehrandvd.me/2015/07/16/goalkeepers-vs-leaders-2/

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___

موقعیت‌های زیر را در نظر بگیرید:
۱) راننده‌ای که اگر به موقع به فرودگاه نرسد، پرواز را از دست می‌دهد.
۲) عابر پیاده‌ای که عجله دارد.
۳) خانم خانه‌داری که مهمان‌ها یک ساعت زودتر آمده‌اند و گرسنه هستند.
احتمالا هر یک از ما حالت مشابهی را تجربه کردیم که در آن یک محدودیت زمانی وجود دارد و ناخواسته قوانینی را که رعایت می‌کردیم، دیگر رعایت نمی‌کنیم.
۱) به احتمال زیاد دیگر به تابلو ورود ممنوع و یا حق تقدیم توجهی نمی‌کند .
۲) به چراغ قرمز توجه نمی‌کند و از پل عابر پیاده نیز استفاده نمی‌کند .
۳) از کیفیت غذا کاسته شده است.
برنامه‌نویس نیز از این قاعده مستثنی نیست. اگر تحت فشار زمان‌بندی پروژه باشد سریع‌تر کار میکند ولی به خاطر اینکه سر وقت بتواند پروژه را تحویل دهد قوانینی را نادیده می‌گیرد و در نتیجه از کیفیت کد کاسته می‌شود.

People under time pressure don’t work better—they just work
faster.

از کتاب:
Peopleware: Productive Projects and Teams (Tom DeMarco & Timothy Lister)

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

کانال تلگرام:
@SoftwarePhilisophy



___

وجود یک «لکه» یا Blob در کد برنامه شما یک نمونه ضد الگوی برنامه نویسی (Anti Pattern) محسوب می‌شود. یکی از علائمی که نشان می‌دهد برنامه شما لکه دارد، زمانی است که از این جمله استفاده می‌کنید: «این قسمت از کد، قلب سیستم است»
وقتی از این جمله استفاده می‌کنید، یعنی قسمتی از کد شما وجود دارد که در آن حجم زیادی از منطق برنامه شما نوشته شده‌است و شکسته نشده‌است. لکه‌ها تمایل به بزرگ شدن دارند،‌ یعنی خیلی وقت‌ها برای نوشتن یک کد جدید، احساس‌ می‌کنید باید آن را به «قلب سیستم» اضافه کنید. خیلی وقت‌ها علت این مشکل معماری بد و یا حتی «نبود معماری» است.

لینک زیر بیشتر در مورد این Anti Pattern توضیح داده است.

https://sourcemaking.com/antipatterns/the-blob

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___

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

Staying late or arriving early or staying home to work in peace is a damning indictment of the office environment.
The amazing thing is not that it’s so often impossible to work in the workplace; the amazing thing is that everyone
knows it and nobody ever does anything about it.

از کتاب:
Peopleware: Productive Projects and Teams (Tom DeMarco & Timothy Lister)

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

کانال تلگرام:
@SoftwarePhilisophy



___

قورباغه را دوباره اختراع نکنید!

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


https://mehrandvd.me/2016/03/09/reinventing-the-frog/

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___

با ما در ارتباط باشید!

تا امروز فیدبک‌های خیلی خوبی از شما دوستان گرفتیم. بر اساس فیدبک‌های شما تصمیم گرفتیم که پست‌های این کانال را در سه دسته بندی پست کنیم:
۱) مطالب مهندسی و معماری نرم‌افزار و مدیریت تیم‌های نرم‌افزاری
۲) مطالب مربوط به آخرین تکنولوژی‌ها
۳) مطالب مربوط به تکنولوژی‌های مرسوم که در شرکت‌ها استفاده می‌شود.

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

لطفا اگر نظر، پیشنهاد، انتقاد و یا هرگونه فیدبکی نسبت به این کانال دارید، در توئیتر بنویسید. مطمئن باشید ما آنها را می‌خوانیم. (در توئیتر https://twitter.com/mehrandvd را منشن کنید و از هشتگ #SoftwarePhilosophy استفاده کنید)

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

بروز خطا در سایت مشتری به مراتب اثر منفی بیشتری دارد تا دیر تحویل دادن یک پروژه با کیفیت عالی.

Managers jeopardize product quality by setting unreachable deadlines.

Workers kept under extreme time pressure will begin to sacrifice quality. They will push problems under the rug to be dealt with later or foisted off onto the product’s end user. They will deliver products that are unstable and not really complete. They will hate what they’re doing, but what other choice
do they have?

از کتاب:
Peopleware: Productive Projects and Teams (Tom DeMarco & Timothy Lister)


#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

کانال تلگرام:
@SoftwarePhilisophy



___

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

https://www.sitepoint.com/smooth-scrolling-vanilla-javascript/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilisophy



___

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

https://www.sitepoint.com/implement-javas-equals-method-correctly/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilisophy



___

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


https://mehrandvd.me/2015/10/26/spaces-shape-your-software-architecture/

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___