Software Philosophy – Telegram
Software Philosophy
3.45K subscribers
160 photos
41 videos
1.54K links
چکیده‌ای از مفاهیم به روز مهندسی نرم افزار برای مهندسین نرم‌افزار.
معماری نوین نرم‌افزار، تکنولوژی‌های برنامه نویسی جدید
Download Telegram
من در استفاده از git بیسوادم، چون هنوز با طرز تفکر قدیمی خود از آن استفاده می‌کنم!

ساختار گیت و معماری فکری آن به گونه‌ای است که می‌توان با روش‌های بسیار متنوعی از آن استفاده کرد. اینکه چه موقعی یک branch جدید ساخته شود، چه موقعی merge انجام شود و یا اینکه اصولا چند branch موازی وجود داشته باشد همه و همه به یک استراتژی و معماری بلندمدت‌تر نیاز دارد. در بررسی روش‌های مختلفی که از git استفاده می‌شود با تجربه افراد مختلفی آشنا شدم که شامل راهکارهایی بسیار کمال‌گرا (و غیر عملی) و یا راهکارهایی بسیار ابتدایی بودند.
یکی از بهترین روش‌هایی که به آن رسیدم مدلی است که یک برنامه‌نویس به نام Vincent Driessen بر اساس تجربه شخصیش به آن رسده و آن را بلاگش توضیح داده و در سال‌های اخیر توجه بسیاری را به خود جلب کرده.
در این روش مدل‌های مختلف branching برای سناریوهای زیر به زیبایی شرح داده شده‌است:
• Main Branch
• Feature Branch
• Release Branch
• Hotfix Branch
این مدل branching که اکنون به gitflow معروف است و در GitHub و BitBucket به عنوان یک روش مرسوم استفاده می‌شود و در مستندات آنها نیز می‌توانید این مدل را مطالعه کنید. در اینجا لینک مقاله اصلی معرفی می‌شود.

http://nvie.com/posts/a-successful-git-branching-model/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

http://ow.ly/Iezl30jhTeJ

#مهران_داودی (http://ow.ly/GwIl309lFEm)

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


___
Forwarded from Iran .Net (Ehsan Mirsaeedi)
سوال هایی در مورد شی گرایی در سی شارپ

1. فیلد f را به صورت static و public در کلاس A تعریف کرده ایم. کلاس های B و C از کلاس A به ارث برده شده اند. آیا فیلد f به ازای کلاس های B و C، کپیِ مجزایی را خواهد داشت؟ در مورد کلاس های جنریک چطور؟
پاسخ:
https://stackoverflow.com/questions/5851497/static-fields-in-a-base-class-and-derived-classes

2. زمان اجرای constructor های static چه وقت می باشد؟
پاسخ:
https://stackoverflow.com/questions/1437352/when-is-a-static-constructor-called-in-c

3. چطور می توانیم، متدی تک پارامتری را تعریف کنیم که هر نوع ورودی ایی را بتواند بپذیرد و نوع پارامترِ متد از نوع object و یا dynamic نباشد.
پاسخ:
https://stackoverflow.com/questions/5886875/let-method-take-any-data-type-in-c-sharp

4. در دو کلاس A و B، متد M با نام و امضای یکسان تعریف شده است. این دو کلاس به طور کلی مجزا می باشند و از کلاس واحدی به ارث نرفته اند. چطور می توانیم در کلاس C متدی تعریف کنیم که با گرفتن یک نمونه از کلاس A و یا B، متد M را صدا بزند با این فرض که متدی که تعریف می کنیم فقط یک پارامتر دریافت کند و درون متد هم هیچ نوع Cast ایی صورت نگیرد. (Duck Typing)
پاسخ:
https://stackoverflow.com/questions/21278078/what-is-interface-duck-typing

5. چرا متد هایی که در یک کلاس virtual تعریف شده اند، نباید یکدیگر را صدا بزنند؟
پاسخ: وقتی متدی، متد دیگری را صدا می زند، یعنی متدِ اولی به متدِ دومی وابسته است. مشکل اینجاست که این وابستگی در پیاده سازی پنهان شده و قابل رویت نیست. در نتیجه اگر کسی در کلاسی که ارث بری شده، متد اول را override کند، هیچ گاه نخواهد فهمید که باید متدِ دوم را صدا بزند. در نتیجه در پیاده سازی جدید، بعد از صدا زدن متدِ اول در کلاس پیاده سازی شده، سیستم در وضعیت پایدار نخواهد بود.

6. کلاس PersonManager متدی تک پارامتری virtual به نام Manage دارد که یک Person را دریافت می کند. کلاس های EmployeeManager و StudentManager را چگونه از کلاس PersonManager ارث بری کنیم، که متد به ارث برده شده و override شده Manage در آن ها به جای پارامتر Person، نوع متناظر Employee و یا Student را دریافت کند.
پاسخ:
https://stackoverflow.com/questions/12593082/c-sharp-override-method-with-subclass-parameter

7. چرا متد های virtual نباید در constructor صدا زده شوند؟
پاسخ:
https://stackoverflow.com/questions/119506/virtual-member-call-in-a-constructor
Forwarded from فلسفه دیزاین
چرا باید به Figma فرصت امتحان شدن بدهید

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

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

این مقاله را از دست ندهید.

https://blog.figma.com/how-to-convince-your-team-to-switch-to-figma-921ca51c5f2a

(زمان حدودی مطالعه، ۱۰ دقیقه)

#بررسی #ابزار #Figma
@Dexign فلسفه دیزاین

___‌
#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. من در استفاده از git بیسوادم، چون هنوز با طرز تفکر قدیمی خود از آن استفاده می‌کنم!

https://news.1rj.ru/str/SoftwarePhilosophy/1195

۲. سوال هایی در مورد شی گرایی در سی شارپ (Iran .Net)

https://news.1rj.ru/str/SoftwarePhilosophy/1196

۳. چرا باید به Figma فرصت امتحان شدن بدهید (فلسفه دیزاین)

https://news.1rj.ru/str/SoftwarePhilosophy/1197

ـــــــــــ

@SoftwarePhilosophy
مقایسه ایران با مایکروسافت ۱۰ سال پیش! تلگرام را فیلتر کنیم؟

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

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

از این لحاظ رویکرد ما خیلی شبیه مایکروسافت ۱۰ سال پیش است. مایکروسافتی که با دنیای open-source مخالف بود و سعی در نادیده گرفتن آن داشت تا جایی که به مرز حذف از بازار برنامه‌نویسی رسید. ولی آنها فهمیدند، خود را تغییر دادند، اوپن‌سورس بودن را درک کردند. به جای مقابله با آن شروع به استفاده از مزایای آن کردند و اکنون فعال‌ترین open-souce community در github هستند. و آرام آرام در حال بازگشت به بازار.

اگر تلگرام را تهدید می‌بینیم، به خاطر این است که «باز بودن« یا «open-source بودن» را تهدید می‌بینیم و باید به حال آن فکری کنیم. با فیلتر کردن ابزار، این طرز فکر از بین نمی‌رود، فقط تبدیل به حالت جنگجویانه‌ترش می‌شود و فیلتر کننده را از بین می‌برد.

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

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

نکته بعدی تکنولوژی blockchain است. قبل از آنکه باز هم دیر شود باید از الان روی آن کار کنیم. به جای اینکه از آن بترسیم باید آن را یاد بگیریم و از آن استفاده کنیم. من از آقای کورنگی، مدیرعامل MAPS متشکرم که سال پیش من را با این مفهوم آشنا کردند و باعث شدند مطالعاتی را در این زمینه شروع کنم. معتقدم باید از قدرت آینده‌بینی و آینده‌نگاری افرادی مثل ایشان نهایت استفاده را ببریم.

http://mehrandvd.me

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

http://ow.ly/wJ6i30jn1B4

#مهران_داودی (http://ow.ly/GwIl309lFEm)

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


___
#پست_مجدد این پست تا به حال بیش از ۵۰۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
یکی از مباحثی که همیشه در تشکیل تیم‌های نرم‌افزاری مطرح است، انتخاب زبان برنامه‌نویسی و یا تکنولوژی‌های مورد استفاده است. مقایسه محصولات موفق و نا موفق نشان می‌دهد هیچکدام از آنها صرفا با یک تکنولوژی و یا یک زبان خاص نوشته نشده‌اند. برای مثال سیستم‌های موفق زیادی وجود دارند که با Java و یا C# نوشته شده‌اند. همچنین سیستم‌های بی کیفیت زیادی نیز وجود دارد که با Java و یا C# نوشته شده‌اند. این حقیقت نشان می‌دهد دلیل موفقیت یا شکست سیستم‌ها نمی‌تواند زبان برنامه‌نویسی باشد. مقاله زیر توضیح می‌دهد که چطور طرز فکر برنامه‌نویس‌ها موفقیت و یا شکست یک سیستم را رقم می‌زند.

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

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


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

___
Forwarded from Iran Agile
درباره اعتماد و اعتماد سازی

چابکی بدون کار تیمی می لنگد و کار تیمی هم بدون اعتماد بین اعضای تیم وهمی بیش نیست. اما اعتماد چیست؟

اعتماد: نداشتن ترس از آسیب پذیر شدن در برابر دیگران.
بی اعتمادی: وقتی که برای انجام دادن کارها از جانب دیگران احساس امنیت نمیکنیم و بیم این داریم که در برابر ایشان آسیب پذیر شویم.

BRAVING
یک acronym است که اجزای تشکیل دهنده اعتماد را بیان می کند:

Boundaries (مرزها)
من مرزهای مشخص خود را دارم و تو هم مرزهای خود را . هر دوی ما به مرزهای یکدیگر احترام میگذاریم

Reliability (اطمینان)
همواره من همان کاری که میگویم را انجام میدهم. تو نیز همواره همان کاری که میگویی انجام میدهی

Accountability (پاسخگویی)
من تو را برای پاسخگویی نسبت به انجام دادن کارهایی که گفته ای انجام میدهی متعهد می دانم. تو نیز می توانی مرا برای پاسخگویی نسبت به کارهایی که گفته ام انجام میدهم متعهد بدانی

Vault (صندوق اسرار)
هرچه که با من در میان می گذاری را نزد خود نگه می دارم و من نیز انتظار دارم که تو با من و دیگران چنین باشی

Integrity (درستی)
انتخاب آنچه درست است به آنچه آسان تر، بامزه تر یا سریع تر است. بجای فقط حرف زدن در مورد ارزش ها آنها را عملا تمرین کنیم

Non-Judgment (بدون قضاوت)
تو میتوانی در کنار تلاش خود، از دیگران کمک بخواهی و من قضاوتت نمی کنم. من می توانم در کنار تلاش خود از دیگران کمک بخواهم و تو قضاوتم نمی کنی

Generosity (خیرخواهی)
تو در مورد گفتار، رفتار و نیات من، خیرخواهانه ترین مفروضات را داری و من نیز در مورد تو همین گونه هستم.


توضیحات بیشتر در لینک زیر:

https://goo.gl/g6XsP8
Forwarded from Iran .Net (Ehsan Mirsaeedi)
نظرسنجی سالانه Stackoverflow

هر سال وب سایت Stackoverflow نظرسنجی ایی را برگزار می کند تا وضعیت صنعت توسعه نرم افزار را روشن و مشخص سازد. امسال بیش از 100 هزار نفر در این نظر سنجی شرکت کرده بودند. ایران با داشتن 0.9% شرکت کنندگان رتبه 21 ام را داشت.

مطالعه نتیجه این نظرسنجی را به همه توسعه دهندگان و مدیران شرکت ها توصیه می کنم تا تصویر شفاف تری از آینده پیدا کنند. برخی از نکات جالب از نظر من به شرح زیر هستند:

* پر استفاده ترین IDE در بین شرکت کنندگان Visual Studio Code و Visual Studio بوده اند. هر کدام سهمی تقریبا برابر با 35% داشته اند.

* نزدیک به 50% توسعه دهندگان از ماشین های ویندوزی استفاده می کنند. سیستم های مک و لینوکس هر کدام سهمی برابر با 25% دارند.

* کنترل نسخه GIT تقریبا همه رقیبان دیگر نظیر SVN و Team Foundation Version Control را منسوخ کرده و نزدیک به 90% افراد از گیت استفاده می کنند.

* برای اشتراک دانش و مدیریت تیم سیستم های Slack و Jira پر استفاده ترین هستند و تقریبا نیمی از شرکت کنندگان از این دو استفاده می کنند. با کمال تعجب سرویس های مایکروسافتی در این حوزه هیچ بُردی ندارند.

* محبوب ترین فریم ورک ها به ترتیب Angular و React و dotNet Core و سپس Java Spring می باشند.

* نزدیک به 50 درصد توسعه دهندگان در حال توسعه سیستمی برای استقرار در لینوکس هستند و نزدیک به 35 درصد برای پلتفرمی ویندوزی سیستم طراحی می کنند. پلتفرم بعدی اندروید با 20% می باشد.

* دیتابیس MySQL با نزدیک به 60% پیشتاز می باشد. سپس SQL Server با 42% محبوب ترین دیتابیس می باشد. جایگاه بعدی متعلق به PostgreSQL می باشد. فراموش نکنیم که دیتابیس های اول و سوم بر خلاف SQL Server رایگان هستند.

* دیتابیس درون حافظه ای Redis، محبوب ترین سیستم برای استفاده به عنوان Cache می باشد.

* زبان های برنامه نویسی به ترتیب محبوبیت Java و سپس Python و سپس C# و سپس PHP می باشند.

گزارش نشان از رشد فزاینده ای در حوزه های مرتبط با "DevOps" و همچنین "Machine Learning" و "Data Science" حکایت می کند. این پوزیشن ها دارای حقوق های بسیار بالا و تقاضای زیادی هستند. علت رشد محبوبیت بالای زبان پایتون که زبان اصلی یادگیری ماشین هست و سایر کتابخانه ها نظیر "TensorFlow" می تواند همین باشد. اهمیت این حوزه ها به قدری است که مدیریت گوگل در کانادا اذعان داشت تا 5 سال دیگر افراد ناآشنا با حوزه "یادگیری ماشین" همه مزیت رقابتی خود را از دست خواهند داد.

* مشاهده نظرسنجی:

https://insights.stackoverflow.com/survey/2018?utm_source=so-owned&utm_medium=meta&utm_campaign=dev-survey-2018-promotion#technology

سال نوی همگی مخاطبان ایران دات نت مبارک

@irandotnet
Forwarded from فلسفه دیزاین
ایده‌هایی از بازی شطرنج برای آموزش دیزاین

حتما برای شما هم پیش آمده که به کسی بازی شطرنج را یاد بدهید یا از کسی آن را یاد بگیرید.
اکثر ما شطرنج را با این جملات یاد گرفته ایم:
سرباز (پیاده) می‌تواند به این شکل حرکت کند، حرکت فیل به این شکل است ولی رخ را به این شکل باید حرکت داد، حرکت‌های شاه محدود به این‌هاست ولی وزیر …
تازه فقط این‌ها نیست، مناطق حساس بازی و تکنیک‌های معروف آن هم هست.

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

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

مقاله امروز با ایده گرفتن از نحوه تدریس یک استاد شطرنج، راهکارهایی برای دیزاین و آموزش دیزاین ارائه می‌دهد که بسیار هیجان‌انگیز و جالب هستند.

مقاله امروز را از دست ندهید!

http://alistapart.com/article/the-king-vs-pawn-game-of-ui-design

(زمان حدودی مطالعه، ۱۵ دقیقه)

پ. ن.
پیش‌تر هم درباره عناصر دیزاین به مثابه اتم‌های آن صحبت کرده‌ایم. اگر آن مقاله را نخوانده‌اید، پیشنهاد می‌کنم که آن را هم مطالعه کنید چراکه می‌تواند کامل کننده این موضوع باشد:
«درس‌هایی درباره «دکمه‌ها»، خالص‌ترین نماینده یک طراحی»
https://news.1rj.ru/str/Dexign/57

#متد #آموزش #دیزاین
@Dexign فلسفه دیزاین

___
#پست_مجدد این پست تا به حال بیش از ۳۸۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
ما به عنوان مهندسین نرم‌افزار عادت کردیم که نرم‌افزار بسازیم، در حقیقت به آن معتاد شده‌ایم. به خاطر همین موضو است که اغلب دوست نداریم به این فکر کنیم که تغییری که در نرم‌افزار می‌دهیم چطور باید در نسخه لایو اجرایی شود. خیلی وقت‌ها نرم‌افزار را به صورت بسیار عالی تغییر می‌دهیم، ولی برنامه‌ای برای اینکه این تغییر چطور باید در نسخه‌اجرایی اعمال شود نداریم.
یکی از دغدغه‌ اصلی یک مهندس نرم‌افزار خوب، تمرکز بر Software Migration است. هر قطعه کدی که توسط یک مهندس نرم‌افزار نوشته می‌شود باید با دید یک Change دیده شود که باید روی نسخه لایو اعمال شود، نه صرفا یک کد جدید که Create شده‌است.

http://mehrandvd.me/2015/09/06/be-a-developer-not-a-programmer/


@SoftwarePhilosophy


___
#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. مقایسه ایران با مایکروسافت ۱۰ سال پیش! تلگرام را فیلتر کنیم؟

https://news.1rj.ru/str/SoftwarePhilosophy/1199

۲. آیا تکنولوژی یا زبان برنامه‌نویسی در موفقیت یا شکست پروژه‌های نرم‌افزاری تاثیری دارند؟

https://news.1rj.ru/str/SoftwarePhilosophy/1201

۳. درباره اعتماد و اعتماد سازی (Iran Agile)

https://news.1rj.ru/str/SoftwarePhilosophy/1202

۴. نظرسنجی سالانه Stackoverflow (Iran .Net)

https://news.1rj.ru/str/SoftwarePhilosophy/1203

۵. ایده‌هایی از بازی شطرنج برای آموزش دیزاین (فلسفه دیزاین)

https://news.1rj.ru/str/SoftwarePhilosophy/1204

۶. اهمیت Software Migration و نوع نگاه در زمان تولید نرم‌افزار

https://news.1rj.ru/str/SoftwarePhilosophy/1206

ـــــــــــ

@SoftwarePhilosophy
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
یکی از دغدغه‌های همیشگی برنامه‌نویسان، تولید نرم‌افزار با سرعت بیشتر و کیفیت بالاتر می‌باشد. یکی از زبان‌های جدید پرطرفدار که به این امر کمک می کند F# است. با F# می‌توان بصورت Functional کد نوشت. تعداد خطوط نوشته شده در زبانهای Functional نسبت به سایر زبان‌ها کم می‌باشد. بطور مثال ۲۰ خط کد در C# با حدود ۵ خط کد در F# قابل بازنویسی است. ویدیو زیر به معرفی F# برای برنامه نویسان C# پرداخته است.

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

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

http://ow.ly/KfWV30h1wUK

#علیرضا_وفی (http://ow.ly/Vna930dsUGr)

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

___
تجزیه اعداد به عوامل اول با استفاده از یکوارها

یکی از مفاهیمی که در دنیای امنیت بسیار از آن استفاده می‌شود، سخت بودن تجزیه اعداد بزرگ با عوامل اول بزرگ است. به این معنی که اگر دو عدد اول خیلی بزرگ را در هم ضرب کنیم و حاصلضرت را در اختیار شخصی بگذاریم، اون نمی‌تواند در زمان معقول به آن دو عدد اول دست پیدا کند. در حقیقت تا یکی از عوامل را نداشته باشد نمی‌تواند عامل دیگر را پیدا کند. این مفهوم یکی از مفاهیم پایه‌ای برای الگوریتم‌های public key/private key مانند RSA است.
مقاله زیر یک روش جدید را برای تجزیه اعداد با استفاده از خواص اعداد Repunit یا همان اعداد متشکل از 1 مانند 11, 111, 1111, 11111, … ارائه داده‌است. این الگوریتم بیشتر از لحاظ چند اثبات ریاضی جالب است که ارتباط بین این اعداد با اعداد اول را تشریح کرده‌است.

لینک کامل این مقاله در پست زیر آمده است.

http://mehrandvd.me/2018/02/16/using-repunits-prime-factorization/


⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

http://ow.ly/9Yrt30jvRhK

#مهران_داودی (http://ow.ly/GwIl309lFEm)

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


___
Forwarded from Iran Agile
🔴 کتاب مدیریت محصول چابک با اسکرام : خلق محصولی که مشتری عاشقش می شود

اثر رومن پیچلر

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

این کتاب دید جامعی در جهت شناخت نقش مدیر محصول چابک ایجاد می کند تا به امروز کتاب های خوبی در مورد موضوع مدیریت محصول و توسعه نرم افزار نوشته و ترجمه شده است اما کتاب جامعی در مورد مدیریت محصول چابک وجود نداشته است.

خرید و اطلاعات بیشتر
https://goo.gl/1397QR
Forwarded from فلسفه دیزاین
به نام دیزاین، به کام تاریکی

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

نویسنده مقاله امروز آقای Nir Eyal است. ایشان نویسنده کتابی با عنوان Hooked هستند که در آن توضیح می‌دهد چگونه می‌توان استفاده از یک محصول را به عادتی برای کاربران‌ش تبدیل کرد.
جدای از اینکه مطالعه این کتاب را به شدت توصیه می‌کنم،‌ مقاله ایشان هم نکته قابل توجهی را مطرح می‌کند. اینکه بهتر است دیزاینرها قدرت‌های خود را با درایت بیشتری استفاده کنند؛ صرفا به «در دایره قوانین حقوقی بودن» اکتفا نکرده و قوانین اخلاقی را هم در نظر بیاورند.
برای کمک به این اتفاق، ایشان تستی را پیشنهاد می‌دهند. نام این تست را «تست پشیمانی» گذاشته‌اند و به صورت یک سوال آن را مطرح می‌کنند:
اگر کاربران تمامی اطلاعاتی را که دیزاینر یک محصول، از آن محصول دارد بدانند، باز هم به استفاده از آن محصول ادامه می‌دهند؟

نظر شما چیست؟
مقاله امروز را از دست ندهید. همچنین خوشحال می‌شوم نظراتتان را با من در میان بگذارید.

https://medium.com/wordsthatmatter/designers-need-the-regret-test-86ef957e0d34

(زمان حدودی مطالعه، ۷ دقیقه)

پ. ن.
پیش‌تر هم درباره جنبه‌های سیاه قدرت‌ها و ابزارهای دیزاین صحبت کرده بودیم که در لینک زیر قابل بازبینی‌ست:
«جادوی سیاهی به نام نوتیفیکیشن»
t.me/Dexign/225

#چالش #دیزاین #تست_پشیمانی
@Dexign فلسفه دیزاین

___
#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. معرفی F# برای برنامه نویسان C#

https://news.1rj.ru/str/SoftwarePhilosophy/1210
https://news.1rj.ru/str/SoftwarePhilosophy/1211

۲. تجزیه اعداد به عوامل اول با استفاده از یکوارها

https://news.1rj.ru/str/SoftwarePhilosophy/1212

۳. کتاب مدیریت محصول چابک با اسکرام : خلق محصولی که مشتری عاشقش می شود (Iran Agile)

https://news.1rj.ru/str/SoftwarePhilosophy/1213

۴. به نام دیزاین، به کام تاریکی (فلسفه دیزاین)

https://news.1rj.ru/str/SoftwarePhilosophy/1214

ـــــــــــ

@SoftwarePhilosophy
Forwarded from Iran .Net (Ehsan Mirsaeedi)
قابلیت های جدید Entity Framework Core
FromSql

در نسخه Core، قابلیت جدیدی تحت عنوان FromSql به Entity Framework افزوده شده است. در وهله اول ممکن است اینطور برداشت شود این قابلیت در واقع همان قابلیت SqlQuery سابق در نسخه های گذشته باشد که یک کوئری را به صورت متن دریافت می کرد و سطرها را برگشت میداد. اما، FromSql در واقع ویژگی به کلی مجزایی می باشد که فرصت های جدیدی را می تواند برای ما فراهم کند.
پیش از پرداخت به جزییات بیشتر باید بدانیم که در FromSql بر خلاف SqlQuery نمی توانیم هر نوع ساختار دلخواهی را برای سطر های برگشتی انتخاب کنیم، بلکه ساختار برگشتی باید عینا مشابه Entity تعریف شده در DbContext باشد. در واقع این متد صرفا از طریق DbSet دسترس می باشد.

var custs = db.Customers
.FromSql("Select * from Customers")
.ToList();



این محدودیت، موجب می شود که بتوانیم از FromSql همراه متدهای دیگر Linq نظیر Where و Include استفاده کنیم. حتی می توانیم توابع متنوع و پرقدرت SQL Server را که از طریق EF در دسترسی نمی باشند صدا بزنیم و همچنان ازمزایای Linq استفاده کنیم.

برای شرح دقیق تر این قابلیت و درهای جدیدی که باز می کند، می تواند به مقاله کوتاه زیر از سایت VisualStudio Magazine مراجعه کنید:

https://visualstudiomagazine.com/articles/2018/04/01/leveraging-raw-sql.aspx