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

یکی از مفاهیمی که در دنیای امنیت بسیار از آن استفاده می‌شود، سخت بودن تجزیه اعداد بزرگ با عوامل اول بزرگ است. به این معنی که اگر دو عدد اول خیلی بزرگ را در هم ضرب کنیم و حاصلضرت را در اختیار شخصی بگذاریم، اون نمی‌تواند در زمان معقول به آن دو عدد اول دست پیدا کند. در حقیقت تا یکی از عوامل را نداشته باشد نمی‌تواند عامل دیگر را پیدا کند. این مفهوم یکی از مفاهیم پایه‌ای برای الگوریتم‌های 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


___

#پست_مجدد این پست تا به حال نزدیک به ۱۱۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

هوش مصنوعی، از آنچه شما فکر می‌کنید به شما نزدیک‌تر است!

پروژه onnxjs نام یک پروژه جذاب جاواسکریپتی است که امکان اجرا کردن مدل‌های ONNX روی بروزر با استفاده از WebAssembly و WebGL را ایجاد می‌کند. به این ترتیب تمامی مدل‌های ساخته شده از طریق Machine Learning‌ که در قابل ONNX باشد در سمت کلاینت قابل اجرا خواهد بود.

https://github.com/Microsoft/onnxjs

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

http://ow.ly/zuWq30mQrmr


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

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

___

رمزنگاری JWT و افزایش امنیت آن در ASP.NET Core

توکن JWT در حالت عادی به صورت Base64 کدگذاری(Encoding) میشه که این نوع Encoding به راحتی قابل رمزگشایی و خواندنه (امنیت در برابر خوانده شدن نداره).
در این مقاله میخوایم توکن JWT رو رمزنگاری کنیم و اون رو به Json Web Encryption (به اختصار JWE) تبدیل کنیم و امنیتش رو بالا ببریم
https://www.dotnettips.info/post/2992

مثال کامل و قابل اجرا در ریپازیتوری گیتهاب:
https://github.com/mjebrahimi/Jwt-Encryption-AspCore
__________
@IranAspMvc

برگه تقلب دیزاین از NN/g:
۱۰ اشتباه رایج در دیزاین محصولات

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

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

مجموعه Nielsen Norman Group که در چند نوبت درباره آن صحبت کرده ایم، حدود ۱۱ سال قبل به بررسی اشتباهات معمول دیزاینرها پرداخته و حالا پس از گذشت این زمان و بررسی‌های بیشتری که در این حوزه انجام داده است، مقاله‌ای را با همین عنوان و با اطلاعات مختص دیزاین محصولات این روزها منتشر کرده است.
در این مقاله با استفاده از مثال‌های بسیار کاربردی به بررسی مفاهیم بسیار مهمی مانند بازخورد، پیغام‌ها، پیش‌فرض‌ها، Affordance و … پرداخته شده و با نمایش نمونه‌های بد و خوب تلاش می‌کند این مفاهیم را به درستی در ذهن خواننده بنشاند.

مقاله امروز را به هیچ‌وجه از دست ندهید.

http://bit.ly/dxgn462

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

#اشتباهات #اصول #طراحی_محصول
@Dexign فلسفه دیزاین

___

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

در لینک زیر مانیفست این طراحی قرار داده شده است که تلاش می‌کند چارچوب و اصول آن را معرفی کند .

https://www.reactivemanifesto.org

#شهریار_انتظام (http://ow.ly/qDN430nPiCg)

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

___

#پست_مجدد این پست تا به حال نزدیک به ۱۰۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

اغلب در برنامه نویسی فرانت اند، در صفحات بیش از یک http request وجود دارد.
گاهی نتیجه یک ریکوست، بعنوان ورودی ریکوست بعدی لازم است که در این حالات باید دو ریکوست بصورت سری عمل کنند.
در برخی مواقع نیز لازم است که بعد از گرفتن نتیجه دو یا چند ریکوست، عملیات خاصی انجام شود به عبارت دیگر باید ریکوست‌ها بصورت موازی ارسال و بعد از اینکه نتیجه‌ی همه‌ی ریکوست‌ها بدست آمد، عملیات صورت گیرد.
در فریم ورک انگولار (Angular 2+) مدیریت این ریکوست‌های async توسط Http service و با کمک کتابخانه RxJS انجام می‌شود.
مقاله زیر هر دو مورد گفته شده را با Angular 7 و RxJS 6 توضیح داده است.

https://coryrylan.com/blog/angular-multiple-http-requests-with-rxjs

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


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

___

#پست_مجدد این پست تا به حال بیش از ۴۷۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد

شایع‌ترین دلیل تخمین زمان اشتباه یک پروژه

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

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

پست زیر این دو مفهوم را معرفی کرده و تفاوت آن‌ها را در مدیریت پروژه شرح داده‌است.

http://mehrandvd.me/2017/08/02/effort-vs-time-estimation/

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

http://ow.ly/958i30erVZs

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

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

___

سریع ترین Object Mapper دات نت
کتابخانه Mapster مشابه AutoMapper است ولی با پرفرمنس باورنکردنی و فوق سریع
این کتابخانه حتی از حالت دستی هم سریع تر است!
https://github.com/MapsterMapper/Mapster

طبق بنچمارک زیر متونین پرفرمنس این روش ها رو مقایسه کنین.
https://github.com/mjebrahimi/Benchmark.netCoreMappers
_______________
@IranAspMvc

#پست_مجدد این پست تا به حال بیش از ۴۱۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد

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

در مقاله زیر تجربه استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویس‌های Azure در یک پروژه عملی شرح داده شده است. در این فرایند Feature‌ ها به عنوان زبان مشترک بین تیم فنی و بیزنس طراحی می‌شوند. سپس این Feature ها به Backlog Item ها شکسته می‌شوند. یک Backlog Item در حقیقت یک نیازمندی‌است است که آنقدری کوچک شده که بتوان آن را به تنهایی تست کرد. به طوری که اگر تست تمام Backlog Item های یک Feature پاس شود، به معنی قابل تحویل بودن آن به تیم بیزنس باشد. سپس Task ها مجموعه کارهایی (فنی و غیر فنی) است که باید انجام شود تا بتوان تست یک Backlog Item را پاس کرد.

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

http://mehrandvd.me/2017/02/24/azure-experience-handling-requirements/

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

http://ow.ly/3NGm30b5IjZ

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

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


___

#پست_مجدد این پست تا به حال نزدیک به ۱۳۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

برای شروع برنامه‌نویسی با reactJS یکی از مشکلات اصلی برنامه‌نویسان (حتی حرفه‌ای ترین آن‌ها) طرز فکر و حل مساله به روش‌های پیاده‌سازی شده در reactJS است. عدم تغییر این طرز فکر باعث می‌شود برنامه‌نویس در عین کار با reactJS از تمام امکانات آن استفاده نکند و فقط اسما یک برنامه‌نویس reactJS باشد. یکی از تفاوت‌های اصلی طرز فکر reactJS با سایر زبان‌های برنامه‌نویسی است پیاده‌سازی درست «ارتباط بین کامپوننت‌ها» است.

در این مقاله به شکل شفاف و جامع ۸ روش برای ارتباط بین کامپوننت‌ها توضیح داده شده است.

https://www.javascriptstuff.com/component-communication/#3-callback-functions

#مریم_کمالی (http://ow.ly/9Wa430mFGeK)

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


___

این همه انواع Messaging Service روی Azure؟ چه خبره؟

اگر از سرویس Cloud مایکروسافت یا همان Microsoft Azure برای طراحی و معماری Solution های خود استفاده می‌کنید، روزی خواهد رسید که به یک Service Bus نیاز خواهید داشت. سرویس باس، سرویسی است که در معماری به شما کمک می‌کند برنامه‌های مختلف سیستم که نیاز دارند با هم ارتباط داشته باشند را به هم متصل کنید. معمولا اگر این اتصال از طریق database polling صورت پذیرد در مقیاس بالا بسیار هزینه‌بر و پیچیده می‌شود. به همین دلیل استفاده از «باس» بسیار پر کاربرد است.
در Azure سه نوع سرویس به این منظور تعبیه شده که هر کدام کاربردهای تخصصی خود را دارند:
- Event Grid
- Event Hub
- Service Bus

برای درک تفاوت این سرویس‌ها ابتدا باید تفاوت مفهوم Event و Message را در Azure بدانید که در مقاله زیر توضیح داده شده‌است. اما کاربرد هر یک را می‌توان به این صورت خلاصه گفت:
- Event Grid:
انتشار رویدادها و Reactive Programming، مثلا عکس‌العمل نشان دادن به تغییر وضعیت‌ها در دیتا

- Event Hub:
کار با stream های سنگین دیتا. برای کار و مدیریت میلیون‌ها رویداد در ثانیه در Big data pipleline طراحی شده.

- Service Bus:
انتقال پیام (Message) بین سیستم‌های Enterprise.

مستند زیر این مفاهیم را با جزئیات کامل‌تری شرح می‌دهد.

https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services

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

http://ow.ly/fhwz30nWt1e

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

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


___

✅ معرفی پروژه DNTFrameworkCore

پروژه که نه بهتره بگیم یه فریمورک یا زیرساخت آماده واسه سایت هاتون هست که کلی امکانات و Best Practice رو تو خودش پیاده کرده و کارتون خیلی راحت میشه✌️

https://github.com/rabbal/DNTFrameworkCore

از امکانات این فریمورک میشه موارد زیر اشاره کرد :
🔹سبک و سریع (نکات پرفرمنسی رعایت شده)
🔸دارای معماری اصولی و توسعه پذیر
🔹پشتیبانی از طراحی چند مستاجری (Multi Tenancy)
🔸اعتبارسنجی خودکار
🔹مدیریت تراکنش ها
🔸پشتیبانی از آزمون واحد و کاملا تست پذیر
🔹و...

حتی اگه قصد استفاده ازشو ندارین، مرور و بررسی کد هاش خیلی میتونه آموزنده و مفید باشه و بهتون ایده بده
🌟 راستی یادتون نره Star هم بدین به ریپازیتوریش 😉

توضیحات بیشتر :
https://www.dotnettips.info/newsarchive/details/14242
_______________
@IranAspMvc

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

https://bit.ly/2STfrtg

@iranagile

#پست_مجدد این پست تا به حال نزدیک به ۳۴۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

تئوری اسب مرده!

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

یک ضرب‌المثل قدیمی هندی می‌گوید: اگه دیدین سوار یه اسب مرده هستید، بهترین استراتژی اینه که پیاده شین.

در حالی که معمولا استراتژی‌های پیشرفته‌تری در دولت‌ها، شرکت‌ها، سیستم‌های آموزشی و ... استفاده می‌شود. این استراتژی‌ها حتما برای شما هم آشنا هستند:

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

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

در پست زیر از بلاگم در مورد این مفهوم صحبت کردم.

http://mehrandvd.me/2018/06/27/the-dead-horse-theory/


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

http://ow.ly/AGJa30kQv8N

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

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


___

✅ خلاصه‌ای از دوره‌ی ASP.NET Core Fundamentals آقای اسکات آلن از سایت Pluralsight

واسه کسایی که دنبال آموزش متنی جامع ASP Core میگردن، خوبه 👌
https://github.com/SirwanAfifi/aspdotnet-core-fundamentals
لینک دانلود PDF :
https://bit.ly/2XaEhs2
_______________
@IranAspMvc