خب سلام دوستان. تصمیم گرفتم تو یکسری پست سریالی(دوره) در مورد فناوری های نوین و جدید و آینده دار که در ایران متاسفانه کمتر بهشون پرداخته شده بپردازیم و چیزای جدید رو یاد بگیریم.

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

بخش اول: بلاکچین - انقلاب در دنیای دیجیتال
ما این دوره را با بلاکچین آغاز می‌کنیم، فناوری‌ای که با تمرکززدایی، امنیت و شفافیت خود، تحولات عظیمی در ارزهای دیجیتال، قراردادهای هوشمند و مدیریت زنجیره تأمین ایجاد کرده است.

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

ساختار دوره
این دوره به 4 فصل کلیدی تقسیم شده است:

فصل 1: بلاکچین چیست و چگونه کار می‌کند

1-بلاکچین چیست
2-بلاکچین چگونه کار می‌کند
3-کاربردهای بلاکچین
4-اولین بلاکچین و معروف‌ترین‌ها

فصل 2: مفاهیم پایه ارز دیجیتال

1-بلاکچین‌های معروف در حوزه ارزهای دیجیتال
2-استخراج (Mining)
3-کیف پول‌های دیجیتال و امنیت

فصل 3: کاربردهای پیشرفته بلاکچی

1-قراردادهای هوشمند
2-دپس (DApps) و وب 3.0
3-بلاکچین در صنایع مختلف
4-آینده بلاکچی

فصل 4: ابزارها و تکنولوژی‌های مرتبط با بلاکچین

1-زبان‌های برنامه‌نویسی بلاکچین
2-پلتفرم‌های توسعه و ابزارهای کاربردی
3-تحلیل داده‌های بلاکچین
4-آموزش و منابع یادگ

ادامه مسیر: وب 3 و کامپیوترهای کوانتومی
پس از تسلط بر بلاکچین، به سراغ وب 3 و سپس کامپیوترهای کوانتومی خواهیم رفت تا شما را برای آینده‌ای دیجیتالی و هوشمند آماده کنیم.



همچنین میتونید مطالب مرتبط با بلاکچین  و وب3 رو  و مطالب مرتبط  با کامپیوتر های کوانتومی رو با هشتگ های زیر ازین پس در چنل پیدا کنید.
#blockchain
#web3
#quantum_computing

تحلیل پیچیدگی عملیات‌ها بر روی آرایه

پیچیدگی زمانی¹:
عملیات پیمایش درج حذف جستجو
بهترین حالت Ω(1) Ω(1) Ω(1) Ω(N)
حالت میانگین θ(N) θ(N) θ(N) θ(N)
بدترین حالت O(N) O(N) O(N) O(N)

پیچیدگی فضایی²:
عملیات پیمایش درج حذف جستجو
بهترین حالت Ω(1) Ω(1) Ω(1) Ω(1)
حالت میانگین θ(1) θ(N) θ(N) θ(1)
بدترین حالت O(1) O(N) O(N) O(1)

پانوشت:
1. Time Complexity
2. Space Complexity

#data_structures
#algorithm

@code_crafters

نیاز به ساختمان‌های داده آرایه
آرایه‌ها یک ساختمان داده اساسی در علوم کامپیوتر هستند. آن‌ها در طیف گسترده‌ای از برنامه‌های کاربردی استفاده می‌شوند، از جمله:
- ذخیره‌سازی داده‌ها برای پردازش
- پیاده‌سازی ساختمان‌های داده مانند استک‌ها و صف¹ها
- نمایش داده‌ها در جداول و ماتریس²ها
- ایجاد ساختمان‌های داده پویا³ مانند لیست‌های پیوندی⁴ و درخت⁵ها

مزایای آرایه
- آرایه‌ها اجازه دسترسی تصادفی به عناصر را می‌دهند. این باعث می‌شود دسترسی به عناصر بر اساس موقعیت سریع‌تر شود.
- آرایه‌ها محل ذخیره حافظه‌پنهان(کَش)⁶ بهتری دارند که تفاوت نسبتاً بزرگی در عملکرد ایجاد می‌کند.
- آرایه‌ها چندین مورد داده از یک نوع را با استفاده از یک نام واحد نشان می‌دهند.
- آرایه‌ها برای پیاده‌سازی سایر ساختمان‌های داده مانند لیست‌های پیوندی، استک‌ها، صف‌ها، درخت‌ها، نمودارها⁷ و غیره استفاده می‌شوند.

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

برنامه‌های کاربردی آرایه
آرایه‌ها در برنامه‌های کاربردی مختلفی استفاده می‌شوند، از جمله:
- ذخیره‌سازی داده‌ها برای پردازش
- آن‌ها در پیاده‌سازی سایر ساختمان‌های داده مانند لیست‌های آرایه⁸، استک‌ها و صف‌ها، هرم‌ها⁹، جداول درهم‌سازی یا چکیده‌سازی(جداول هَش)¹⁰، بُردارها(وِکتور)¹¹ و ماتریس‌ها استفاده می‌شوند.
- نمایش داده‌ها در جداول و ماتریس‌ها
- ایجاد ساختمان‌های داده پویا مانند لیست‌های پیوندی و درخت‌ها
- سوابق¹² پایگاه داده معمولاً به صورت آرایه پیاده‌سازی می‌شوند.
- در جداول جستجو¹³ توسط کامپیوتر استفاده می‌شود.

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

پانوشت:
1. Queues 2. Matrices
3. Dynamic Data Structures
4. Linked Lists 5. Trees
6. cache locality 7. Graphs
8. Array Lists 9. Heaps
10. Hash Tables 11. Vectors
12. records 13. lookup tables

#data_structures
#algorithm

@code_crafters

فصل اول
1-بلاکچین چیست؟

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

1-تغییر ناپذیری و مدیریت داده ها

به محض این که اطلاعاتی در بلاکچین ذخیره بشه به هیچ  عنوان قابلیت
پاک شدن یا تغییر رو نداره
  ما در دیتابیس عملیات CRUD رو داریم (create, read , update , delete)
اما  بلاکچین از عملیات تغییر  پذیری پیشتیبانی نمیکند. به عبارت دیگر در بلاکچین  فقط فقط عملیات C&R(Read, Create) داریم.
به این معنی که داده های یک بار نوشته میشن و دیگه نمیتونن پاک بشن یا جایگزین بشن.

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

به طور کلی یکسری ردیف از اطلاعات در فضایی با حجم محدود(مثلا 1 مگابایت) ذخیره میشه. فرض کنیم اسم این فضا رو بلوک انتخاب کنیم حالا هرکدوم از این بلوک ها یک کد منحصر به فردی دارن که به بلوک قبلی مرتبط میشه به این صورت که بلوک هایی که دارای اطالاعات هستند با کمک یک زنجیره فرضی بهم وصل میشن.
در نتیجه هر تغییری در اطلاعات یک بلوک نیازمند تغییر همه بلوک های بعد اون  است که این امر رو عملا غیر ممکن میکنه.


2-معماری

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

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

سایر تفاوت‌ها
3-هزینه و پیاده‌سازی
4-سرعت و عملکرد


#blockchain

@code_crafters

در ادامه مباحث در خصوص میکروسرویس و حاکمیت soa و سیاست‌های آن میرسیم به سیاست‌های مستند سازی


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


طراحی سرویس و سیاست داکیومنت سازی

۱-خدمات مستندسازی خود را ایجاد کنید:
برای مشتریان شما مهم است که اسناد خوبی برای خدماتی که می خواهند استفاده کنند داشته باشند.اغلب این مستندات در یک سند جداگانه است که باید قبل از اینکه با رابط سرویس ارتباط برقرار و معنادار شود، مطالعه کنند.
(با این خط‌مشی به شما نشان می‌دهم که بیشتر قابلیت‌هایی که یک سرویس ارائه می‌دهد را می‌توان توسط خود سرویس توصیف کرد، بدون نیاز به اسناد خارجی گسترده)


۲-استفاده مجدد از استانداردهای موجود:
یک ضد الگویی (anti pattern) که اغلب دیده می شود، الگوی "اختراع نشده" است.به جای استفاده از استانداردها (استانداردهای واقعی)، سازمان ها، به ویژه گروه های فناوری اطلاعات، تمایل به اختراع مجدد چرخ دارند. در اجرای این خط مشی، خواهید دید که استفاده مجدد از استانداردهای موجود در محیط های معماری های معروف چقدر آسان است


۳-طراحی برای قابلیت استفاده مجدد:
هنگامی که شما یک سرویس را طراحی می کنید، خوب است که این سرویس توسط سایر خدمات و مصرف کنندگان مجددا استفاده شود.در بخش مربوط به این خط‌مشی، من مجموعه‌ای از دستورالعمل‌ها و روش‌های رایج را ارائه می‌دهم که می‌تواند به شما در ایجاد سرویسی کمک کند که به راحتی قابل استفاده مجدد باشد

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

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

در ادامه و تکمیل موارد ذکر شده در بالا مطرح کردن این موضوع که استاندارد HTTP میتواند سریعا به مصرف کنندگان سرویس‌های ما سندی توضیحی ارایه دهد بسیار قابل توجه هستش، استفاده از متدهای POST, DELETE, GET, PUT به مشتریان سریعا میرساند که چه چیزی بدست میگیرند رعایت موارد دیگر نیز میتواند درک صریحی رو ارائه دهند برای مثال ذکر json در ریپورت استاندارد HTML این رو میرسونن که در انتظار چه نوع خروجی باشد و همچنین کاربر با دیدن <report-ID> به این مسئله پی خواهد برد که با گذاشتن مقدار عددی بجای ID میتواند اطلاعات مربوط به ان را بگیرد

ذکر این مسائل به ما میگوید که در داکیومنت سازی لازم نیست هرچیزی را مطرح کنید، ذکر موارد زیر در داکیومنت سازی کافیست

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

ریپوزیتوری پروژه بهترین جای ممکن برای ذخیره و نگهداشت و ارائه اون به مشتریان هستش


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


#microservice
#soa

@code_crafters

بیایید به انواع مختلفی از خدماتی که می توانید تعریف کنید نگاه کنیم:

 ■ خدمات فرآیند: خدمات فرآیندی درشت ترین خدمات هستند. این نوع خدمات اغلب خدمات یا محصولاتی را به مصرف کنندگان خود ارائه می دهند.  به عنوان مثال، شما می توانید یک سرویس فرآیندی داشته باشید که فروش یک محصول(هر چیزی) را انجام می دهد. در این سناریو سیستم مالیاتی باید به روز شود، سیستم فروشندگی(فروشگاه، انبار و ...) باید به روز شود و سیستم های بسیار بیشتری در این معامله دخیل هستند. یک سرویس فرآیندی دیگر خدمات فرآیند و خدمات تجاری را برای انجام وظیفه خود فراخوانی می کند.  وقتی به ارکستراسیون(orchestrations) فکر می کنید، احتمالاً در مورد یک سرویس فرآیند صحبت می کنید.

■ خدمات تجاری: یک سرویس تجاری یک عملکرد تجاری واحد و خاص را برای یک سیستم فراهم می کند. در مثال قبلی، یک سرویس تجاری سرویسی است که می توانید برای به روز رسانی اطلاعات در یک سیستم مالیاتی استفاده کنید.

■ خدمات فنی: بهترین خدمات، خدمات فنی هستند. یک سرویس فنی بخش کوچکی از عملکرد را برای سایر خدمات فراهم می کند.  یک مثال از این می‌تواند سرویسی باشد که به شما امکان می‌دهد یک شخصیت شخصی را در پایگاه داده به‌ روزرسانی کنید، یک ایمیل ارسال کنید.

جدا سازی لایه انتقال transformer layer (سریالایزر) از لایه منطق تجاری business logic، این امکان رو براتون بوجود میاره که سرویس خود رو منتقل کنید، این امر باعث میشه که لایه منطق شما قابل استفاده و در صورت نیاز رابط‌های راه دوری ساخت که از منطق تحاری شما مجدد استفاده کنند


سیستم ما در حال توسعه است و دستخوش تغییراتی که ممکن است ورژن جدیدی رو خلق کنه، این تغییرات به دو دسته عملیات شکسته نشدن و عملیات شکسته شدن منجر گردد، که عواقب آن شامل سازگاری با نسخه قبلی و عدم سازگاری با نسخه قبلی گردد

سیاست‌های موجود در این خصوص

سازگاری با نسخه قبلی و شکسته نشدن:
(افزودن api جدید به سرویس‌های خاص و افزودن منابع غیر اجباری-مشتریان میتونن نادیده بگیرند)
۱-افزودن عملیات جدید- با افزودن عملیات جدید به سرویس‌های خود شکسته شدن رخ نمیدهد و سازگاری با نسخه قبلی همچنان پا بر جاست
۲-با افزودن عملیات جدید، طرحواره xml نیز بوجود می‌آید (schema)، تا زمانیکه طرحواره‌های بوجود اومده برای عملیات‌های جدید منجر به تغییر در طرحواره‌های قبلی و موجود فعلی نگردد سازگاری پا برجاست


عدم سازگاری با نسخه قبلی و شکسته شدن:
(حذف ویژگی از یک منبع، تغییر دادن یک ویژگی-حذف یک ارتباط و یا تغییر دادن ارتباط منابع)
۱-حذف یک عملیات از سرویس که منجر به شکسته شدن و عدم سازگاری با نسخه قبلی بوجود می‌آید

۲-تغییر نام یک عملیات موجود، این مسئله چیزی نیست جز حذف عملیات قبلی و خلق عملیات جدید که منجر به عدم سازگاری با نسخه قبلی میگردد

۳-تغییر پارامترهای موجود، این عمل منجر میشود که ورودی و خروجی عملیات شما دچار دگرگونی شود

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

نسخه گذاری و ورژنینگ بر اساس شکسته شدن یا عدم شکسته شدن روی میدهد برای مثال ورژن فعلی ما 1.1 میباشد، اگر عملیات بدون شکسته شدن باشد ورژن ما 1.2 و اگر همراه با شکسته شدن باشد ورژن ما 2.1 خواهد شد، که به آن افزایش جزئی و افزایش تعداد نسخه میگوییم


اضافه بر مباحث کتاب:

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

لایه ذخیره ساز شما دیتابیس میباشد

لایه دیتای شما مدل‌های شما میباشد

لایه کوئری شما در مدلهای شما می‌باشد(object manager) که عملیات جستجو در ان قرار میگیرد

لایه دسترسی دیتای شما شامل تمامی عملیات‌های crud می باشد

لایه منطق تجاری شما شامل تمام عملیات‌های اعتبار سنجی و پردازش می‌باشد(لایه کوئری و لایه دسترسی داده شما در اینجا فراخوانی میشود)-ویو در این لایه قرار دارد اما اکسپرت این است که در کنار view ما فایل service هم داشته باشیم که رابطی بین viewی ما با لایه کوئری و دسترسی داده باشد و قرار بگیرد

لایه انتقال داده شما سریالایزرهای شما می‌باشد

لایه نمایش شما شامل هر چیزی میشود که کاربر میبیند(html, css, js, swagger)

رعایت کردن این لایه‌ها در سرویس‌های ما منجر به انعطاف پذیری و قابلیت استفاده مجدد میگردد

#microservice
#soa

@code_crafters

فصل اول
2- بلاکچین چگونه کار می‌کند؟

بلاکچین را مجموعه‌ای از بلاک‌ها تصور کنید که به صورت زنجیره‌وار به یکدیگر متصل‌اند.

1- ساختار هر بلاک
هر بلاک در زنجیره شامل 3 بخش اصلی است:

1.1- داده (Data): این بخش شامل اطلاعاتی است که بلاک ذخیره می‌کند. برای نمونه، در بلاکچین بیتکوین داده‌ها شامل جزئیات هر تراکنش است مانند فرستنده، گیرنده و مقدار بیتکوین انتقال داده شده.

1.2- هش بلاک (Block Hash): هر بلاک دارای یک کد منحصر به فرد به نام هش است که با استفاده از الگوریتم‌های رمزنگاری تولید می‌شود. هش یک بلاک مانند اثر انگشت آن بلاک است و کوچکترین تغییری در جزئیات داده‌های بلاک، هش آن را به کلی تغییر می‌دهد.
الگوریتم‌های هشینگ توابع ریاضی یک‌طرفه‌ای هستند که ورودی آن هر چیزی می‌تواند باشد اما خروجی آن یک مقدار منحصر به فرد با اندازه ثابت است. یک‌طرفه بودن این توابع به این معناست که با داشتن خروجی نمی‌توان به داده ورودی آن دست پیدا کرد.

1.3- هش بلاک قبلی (Previous Block Hash): هر بلاک حاوی هش بلاک قبلی است که به آن متصل است. این ویژگی باعث ایجاد زنجیره‌ای از بلاک‌ها می‌شود و امنیت و تغییرناپذیری بلاکچین را تضمین می‌کند.

2- فرایند افزودن بلاک به زنجیره
برای افزودن بلاک جدید به زنجیره، مراحل زیر انجام می‌شود:


2.1- تایید تراکنش‌ها (Transaction Verification): ابتدا تراکنش‌های جدید توسط نودهای شبکه تایید می‌شوند. این تایید شامل بررسی صحت امضاهای دیجیتال و اطمینان از عدم تکراری بودن تراکنش‌ها است.

2.2- حل مسئله ریاضی (Proof of Work): برای اضافه کردن بلاک جدید به زنجیره، نودها باید یک مسئله ریاضی پیچیده را حل کنند که به آن اثبات کار می‌گویند. این فرآیند نیازمند قدرت محاسباتی زیادی است و زمان و انرژی زیادی مصرف می‌کند.

2.3- اضافه شدن به زنجیره (Block Addition): پس از حل مسئله و تایید صحت بلاک جدید توسط سایر نودهای شبکه، بلاک به زنجیره اضافه می‌شود.

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

تکمیلی:
بعضی از سایت‌های تولید محتوا مانند ویکی‌پدیا و everpedia بر بستر بلاکچین هستند.که اصولا برای اضافه کردن بلاک جدید نیاز به حل معادلات پیچیده نیست،مثلا در سایت everpedia براساس یک سری الگورتیم های دیگه بلاکچین باشه که هیچ یک از این کار ها رو کاربر انجام نمیده.

بیشتر بخوانید:
الگوریتم های هشینگ Hashing algorithms
هش بلاک Block Hash
نود Node

#blockchain
@code_crafters

پ ن(تخصصی):
خب سوالی که پیش میاد این که این نود ها چطوری پیوسته و همیشه در حال چک کردن و پردازش هش بلوک ها هستن تا اونارو تایید یا رد بکنن!؟



  ما در نظر میگیریم  که ۵ بلوک داریم
هش بلوک ۲ تغییر کرده ، این باعث میشه که بلوک ۳ ناساگاز بشه و اون با بلوک ۴ و...
این پروسه مثل یک دومینو ادامه پیدا می‌کنه
حالا نود که دائم داره بلوک های جدید رو پردازش و صحت سنجی  میکنه تشخیص میده

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

حالا اگه هش‌ها مطابقت داشته باشن نود به مرحله بعدی می‌ره اگر مطابقت نداشته باشه هم که خب بلوک رد میشه


مثال علمی:

بلوک 1 (هش: ABC)
بلوک 2 (هش: DEF) - شامل هش بلوک 1 (ABC)
بلوک 3 (هش: GHI) - شامل هش بلوک 2 (DEF)
بلوک 4 (هش: JKL) - شامل هش بلوک 3 (GHI)
بلوک 5 (هش: MNO) - شامل هش بلوک 4 (JKL)

‌ ‌ اگر دیتایی در بلوک 2 تغییر کنه هش بلوک 2 تغییر میکنه

مثلاً به XYZ حالا بلوک 3 که شامل هش قبلی (DEF) بود الان باید شامل XYZ باشه، اما هش بلوک 3 با این تغییر سازگار نیست.


نودها این تغییر را تشخیص میده زیرا وقتی اطلاعات بلوک 2 را هش می‌کنند هش جدید (XYZ) با هش اعلام شده (DEF) در بلوک 3 مطابقت نداره

و درواقع عدم تطابق باعث میشه که نودها بلوک 2 و بلوک‌های بعدی رپ کلا نامعتبر بدونه

#blockchain
@code_crafters

فصل اول
3-کاربردهای بلاکچین

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

1- ارزهای دیجیتال

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

2- قراردادهای هوشمند

قراردادهای هوشمند (Smart Contracts) برنامه‌هایی هستند که بر روی بلاکچین اجرا می‌شوند و شرایط قراردادی را به صورت خودکار و بدون نیاز به واسطه‌های سنتی اجرا می‌کنند.
- مزایا: حذف واسطه‌ها، کاهش هزینه‌ها و افزایش سرعت اجرای قراردادها.
- مثال: می‌توان از قراردادهای هوشمند برای اتوماسیون فرآیندهای حقوقی، بیمه و معاملات املاک استفاده کرد.

3- زنجیره تأمین

بلاکچین می‌تواند شفافیت و کارایی زنجیره تأمین را بهبود بخشد. از تولید تا مصرف، هر مرحله از زنجیره تأمین می‌تواند به صورت امن و قابل ردیابی در بلاکچین ثبت شود.
- مزایا: افزایش شفافیت، کاهش تقلب و بهبود مدیریت موجودی.
- مثال: پیگیری محصولات غذایی از مزرعه تا فروشگاه برای اطمینان از کیفیت و اصالت کالا.


4- رأی‌گیری الکترونیکی

استفاده از بلاکچین در سیستم‌های رأی‌گیری الکترونیکی می‌تواند شفافیت و امنیت انتخابات را افزایش دهد.
- مزایا: جلوگیری از تقلب، افزایش شفافیت و امکان رأی‌گیری از راه دور.
- مثال: پیاده‌سازی سیستم‌های رأی‌گیری برای انتخابات ملی و محلی با استفاده از بلاکچین

5- بهداشت و درمان

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

6- مدیریت

هویت
بلاکچین می‌تواند به ایجاد سیستم‌های مدیریت هویت دیجیتال امن و غیرمتمرکز کمک کند.
- مزایا: افزایش امنیت اطلاعات شخصی، کاهش تقلب و سوء استفاده از هویت.
- مثال: ایجاد شناسه‌های دیجیتال برای افراد که به صورت امن در بلاکچین ذخیره می‌شوند و در دسترسی به خدمات مختلف مورد استفاده قرار می‌گیرند

نتیجه‌گیری

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

#blockchain

@code_craftesr

گپ فنی و خودمونی گروه بابت امشب

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


به زودی میت‌های تخصصیش هم راه میندازیم
@code_crafters

فصل اول
4-اولین و معروف ترین بلاکچین ها

1-اولین بلاکچین ها:

1.1-بیتکوین(Bitcoin):

بیتکوین اولین و معروف ارز دیجیتالی و بلاکچین غیر متمرکزی است که توسط ساتوشی ناکوموتو در سال 2008 معرفی و در سال 2009 عملی شد.

سازنده: ساتوشی ناکاموتو
سال راه اندازی: 2009
کاربرد اصلی: ارز دیجیتال
ویژگی: اولین بلاکچین غیر متمرکز و آغازگر انقلاب ارزهای دیجیتال.

1.2-لایتکوین(litecoin):

زمان راه‌اندازی: 2011
سازنده: چارلی لی
کاربرد اصلی: ارز دیجیتال برای پرداخت‌های سریع‌تر و ارزان‌تر
ویژگی‌ها: تأیید سریع‌تر تراکنش‌ها، الگوریتم Scrypt، کارمزد پایین.

2-معروفترین بلاکچین ها

2.1-اتریوم (Ethereum):

زمان راه‌اندازی: 2015
سازنده: ویتالیک بوترین
کاربرد اصلی: قراردادهای هوشمند و اپلیکیشن‌های غیرمتمرکز (DApps)
ویژگی‌ها: قابلیت اجرای قراردادهای هوشمند و اپلیکیشن‌های متنوع.

2.2-ریپل (Ripple):

زمان راه‌اندازی: 2012
سازنده: کریس لارسن و جد مک‌کالب
کاربرد اصلی: سیستم پرداخت بین‌المللی
ویژگی‌ها: انتقال سریع و ارزان پول، استفاده توسط بانک‌ها.

2.3-هایپرلجر (Hyperledger):

زمان راه‌اندازی: 2015
سازنده: بنیاد لینوکس
کاربرد اصلی: بلاک‌چین‌های خصوصی و کنسرسیومی برای کسب‌وکارها.
ویژگی‌ها: پلتفرم منعطف برای صنایع مختلف

2.4-کاردانو (Cardano):

زمان راه‌اندازی: 2017
سازنده: چارلز هاسکینسون
کاربرد اصلی: قراردادهای هوشمند و اپلیکیشن‌های غیرمتمرکز
ویژگی‌ها: امنیت و مقیاس‌پذیری بالا.

2.5-ایاس (EOS):

زمان راه‌اندازی: 2018
سازنده: بلاک‌وان
کاربرد اصلی: قراردادهای هوشمند و اپلیکیشن‌های غیرمتمرکز
ویژگی‌ها: سرعت و کارایی بالا، کاهش کارمزدها.

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

بیشتر بخوانید:
بیتکوین (Bitcoin)
لایتکوین(litecoin)
اتریوم (Ethereum)
ریپل (Ripple)
هایپرلجر (Hyperledger)
کاردانو (Cardano)
ایاس (EOS)
#blockchain
#web3
@code_crafters

گپ فنی امشب داخل گروه با سعید جان ، در خصوص استوریج فایلهای حجیم در بستر وب


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


@code_crafters

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


https://blog.min.io/selecting-hardware-for-minio-deployment/

گپ امشب گروه با سعید جان
موضوع گپ:
تحلیل و بررسی فنی سرویس هایی مانند پرداخت، سفارش، سبد خرید و چالش های یک سیستم فروشگاهی چند منطوره با تجربه های شخصی

برخی از مباحث گفته شده:
- چگونگی عملکرد درگاه های پرداخت انلاین
- چگونگی و چالش های طراحی سرویس فروشگاهی، خرید، سبد خرید و انبار داری
- صحبت در باره retry handling و rollback تغییرات و Saga state machine
- بررسی زنده یک اپلیکیشن دارای فروشگاه، تحلیل محصولات و اپلیکیشن های مشابه
- توضیح درباره کیف پول مجازی، روش های پرداخت، پرداخت
- بحث مدیریت همزمانی، اعتبار سنجی خرید ها، کنترل و رزرو موجودی و Checkout
- پرسش و پاسخ سوالات مرتبط دوستان

بزودی میت‌های تخصصی رو مجدد شروع میکنیم


@code_crafters

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


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


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

@code_crafters

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


@code_crafters




https://google.github.io/styleguide/pyguide.html

#مقیاس_پذیری و چالش های آن - پارت 1
Horizontal & Vertical #Scaling ⚖️

زمانی که فرآیند تولید نرم افزار به مرحله Production می‌رسد و اپلیکیشن روی سرور می‌رود، چالش‌ها و مخاطرات جدیدی برای صاحبان آن ایجاد می‌شود. ما در عصری هستیم که استفاده از اینترنت به سبک زندگیمان تبدیل شده. بنابراین پس از معرفی اپلیکیشن یا وبسایت، کاربران آن به سرعت افزایش پیدا می‌کند.
زمانی فرا می‌رسد که سیستم دیگر توان هندل کردن حجم بازدیدکنندگان و پردازش درخواست ها را ندارد.
در مواردی هم حجم دیتا به حدی می‌رسد که سیستم نمی‌تواند آن را در پایگاه داده خود ذخیره کند. در این گونه موارد، زمان آن فرا رسیده که محصول Scale یا مقیاس پذیر شود.
معمول ترین راهکار، مقیاس پذیری عمودی یعنی افزایش منابع سخت افزاری مانند RAM, CPU است اما در نرم‌افزار های بزرگتر، مقیاس پذیری عمودی تا حدی کارساز است.
از یک حدی به بعد تک سرور شما قادر به افزایش منابع نخواهد بود و یا صرفه اقتصادی نخواهد داشت. کما اینکه vertical Scaling محدودیت هایی مانند دیسک و شبکه را مقیاس پذیر نمیکند. (به خصوص پهنای باند در سرور های داخل که سرشار از اختلال و از نسل 3G است!)

بنابراین مقیاس پذیری افقی با افزودن سرور های بیشتر (که زین پس به آنها Node خواهیم گفت) و تقسیم بار بین انها ( Load Balanacing) راه حل بهتری خواهد بود. چرا که هم افزایش سرور ها ارزان تر خواهد بود (به نسبت خرید منابع حافظه و پردازنده بیشتر) و هم هر سرور مستقلا میتواند به‌ مقدار نیاز مقیاس پذیری عمودی هم داشته باشد (هر سرور منابع اختصاصی متفاوتی از حافظه ram، پردازنده، iops دیسک و پهنای باند / پورت شبکه داشته باشد)
تا به اینجا اصلی ترین تفاوت های دو مدل مقیاس پذیری را بررسی کردیم. اما همیشه چالش ها،‌ مزایا و معایبی هم وجود دارد که در جایگاه یک مهندس نرم افزار حرفه ای و معمار سیستم، ما باید با علم به این مباحث برای یک کسب و کار تصمیم بگیریم.

یکی از چهار هدف اصلی مقیاس پذیری، توسعه پذیر تر کردن یک نرم افزار است.
در مقیاس پذیری افقی مهمترین و اصلی ترین چالش های پیش رو مباحثی مانند همزمانی در عملیات ها، یکپارچگی داده ها، از بین بردن Single point of failure و کاهش گلوگاه ها است.
همانطور که در بالاتر اشاره شد در مقیاس پذیری افقی ما بجای تکیه بر سخت افزار محدود یک سرور، به طرف توزیع بار و کلاستر سرویس ها بر روی چند سرور (نود) متعدد میرویم.

فرض کنید نرم افزاری دارید که متشکل از ده ها میکروسرویس‌ و ده ها دیتابیس و ابزار مختلف میباشد. هر کدام ازین میکروسرویس ها بر روی سرور های 1 الی 5 در حال اجرا هستند. همچنین ممکن است هر یک ازین سرویس ها نیاز به replication و load balancing پیدا کنند (هدف از مقیاس پذیری افقی).
در اینصورت علاوه بر این که کلاستر سرور های شما میبایستی در یک شبکه داخلی یا خصوصی پایدار و قابل اتکا با هم در ارتباط باشند، بایستی بتوانند بصورت پایدار عملیات های خود را انجام دهند.
برخی از پارامتر های پایداری:
- درخواست های همزمان متعدد نباید منجر به پاسخ های مختلف شوند.
- داده های خروجی باید جدیدترین داده های موجود باشند.

به عنوان مثال، سرویس سفارش یا احراز هویت مان را مقیاس پذیر کردیم و لود بالانسینگ تعیین میکند هر بار درخواست ها به کدام node / سرور ارسال شود.
در صورتی که دو یا چند کاربر بطور همزمان قصد دسترسی به یک ریسورس مشترک (فایل / دیتابیس / etc) داشته باشند مشکلاتی همچون همزمانی یا concurrency و شرایط مسابقه یا race conditions پدیدار خواهد شد.

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

در مطلب بعدی (پارت 2 مقیاس پذیری)، به برخی شیوه های مدیریت این چالش ها و تجربه های شخصی میپردازیم.

بیشتر بخوانید (مقالات / مفاهیم مرتبط):
دسترسی پذیری بالا HA
گلوگاه Bottleneck
خوشه ها Cluster
تئوری CAP
مقیاس پذیری Scalability
سیستم های توزیع شده Distributed Systems

#مهندسی_نرم‌افزار #معماری
#software_engineering #architecture #Scalability #distributed_systems #devops #infrastructure

@csharpfriends @Code_Crafters

Example of Microservices System design template overview

#microservices #Scaling #bestpractice #architecture #distributed_systems #مهندسی_نرم‌افزار

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

@csharpfriends @Code_Crafters

دورنمای بسیار ساده و خلاصه لودبالانسینگ در معماری و طراحی میکروسرویس ها
در مطالب آینده درباره لودبالانسینگ یا توزیع بار صحبت خواهیم کرد
#microservices #load_balancing #api_gateway #Scaling #architecture #مهندسی_نرم‌افزار

@csharpfriends @Code_Crafters

میکروسرویس و حکمرانی soa، در ادامه مباحث مربوط به سیاست‌های سازمانی soa در ادامه میریم به سراغ سیاست‌های امنیتی

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


سیاست‌های امنیتی

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

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

از یک سیستم هویت متمرکز برای احراز هویت استفاده کنید: احراز هویت مصرف کنندگان (یا کاربران داخلی شما) چیزی است که تقریباً همه خدمات به آن نیاز دارند. اغلب این برای هر سرویس دوباره اختراع می شود. با استفاده از یک سیستم هویت متمرکز، می توانید مطمئن شوید که هر سرویس از سیاست های سختگیرانه ای که در مورد شناسایی تعیین شده است پیروی می کند.

از یک سیستم هویت متمرکز برای مجوز استفاده کنید: قوانین مشابهی برای مجوز اعمال می شود. این اغلب چیزی است که در گذشته به برنامه ها اضافه می شود و نگهداری از آن اغلب دشوار است. با متمرکز کردن مجوز می توانید مطمئن شوید که همه سرویس ها از دستورالعمل های مجوز یکسانی که در سازمان تعریف شده است پیروی می کنند.


وب سرویس‌ خود را بشناسید و یکپارچگی پیام را در آن رعایت و پیاده سازی کنید (SOAP, REST, ...) برای مثال در REST این مسئله با https فراهم گشته اما اگر جایی این پروتکل نبود میتوانید از HMAC استفاده کنید، کمپانی های بزرگی مانند azure, aws, ... از این موضوع برای سرویس REST خود استفاده میکنند و عموما یک رویکرد مشابه دارن، یک سرویس تولید HMAC بالا بیاورید کاربر قبل از ارسال پیام به شما یک کلید گرفته و همراه پیام برای شما ارسال میکند شما پیام را گرفته و بر اساس پارامترهای خود از سرویس HMAC کلید رو میگیرید حالا دو کلید HMAC رو باهم مقایسه کرده و یکپارچگی و یا عدم یکپارچگی رو تایید کنید، اما سوال پارامترهای ورودی ما چه چیزهایی باشد، AWS به شکل زیر عمل میکند

روش HTTP:
با REST نوعی از روش HTTP که اجرا می کنید رفتار سمت سرور را مشخص می کند.  DELETE به یک URL خاص به طور متفاوتی با GET به آن URL مدیریت می شود

هدر Content-MD5:
این هدر HTTP یک هدر استاندارد HTTP است.این یک هش MD5 از بدنه درخواست است.اگر این هدر را در تولید کد HMAC قرار دهید، یک مقدار HMAC دریافت می کنید که با تغییر بدنه درخواست تغییر می کند

هدر Content-Type: 
هدر Content-Type یک هدر مهم هنگام برقراری تماس های REST است. بسته به نوع رسانه، سرور می تواند به یک درخواست پاسخ متفاوتی بدهد.بنابراین باید در HMAC گنجانده شود.

 هدر تاریخ:
شما همچنین تاریخ ایجاد درخواست برای محاسبه HMAC را درج می کنید. در سمت سرور می توانید مطمئن شوید که تاریخ در حین انتقال تغییر نکرده است.  علاوه بر این می توانید قابلیت انقضای پیام را در سرور اضافه کنید.

 مسیر روش HTTP:
بخشی از مسیر URL که فراخوانی شده است نیز در محاسبه HMAC استفاده می شود، زیرا یک URI منبعی را در REST شناسایی می کند.

یک سیستم احرازهویت مرکزی و مجوزدهی (authentication, authorization) راه اندازی کنید SSO (دقت کنید ممکن سیستم مجوز هی شما متفاوت از هویت سنجی باشد این بستگی به سیستم شما دارد) (در کتاب که بر اساس جاوا نوشته شده، پلتفرم openam را معرفی و پیش برده، در پست‌های قبلی کانال راجب keycloak صحبت شد)


#microservice
#soa

@code_crafters