💠 کانون کارآفرینی دانشگاه تهران جنوب برگزار می‌کند:

دوره 🔰 طراحی وب سایت 🔰 با رویکرد اشتغال

از علاقمندان تقاضا می‌شود جهت ثبت نام به آیدی ادمین کانون کارآفرینی پیام دهند.

🔸🔷 @karafarini_tj_admin 🔷🔸

‼ ظرفیت محدود ‼

#کانون‌کارآفرینی

🆔 @karafarini_tj

Automata Theory , Languages and Computation

@de_coder

در رشته علوم کامیپیوتر ( منظور از علوم کامپیوتر همان رشته Computer Science می باشد که تنها رشته تحصیلی در مقطع کارشناسی یا bachelor در زمینه کامپیوتر است که در دانشگاه های برتر دنیا ارائه می شود و با رشته علوم کامپیوتر که در دانشگاه های ایران ارائه می شود متفاوت است) درسی وجود دارد به اسم Languages and Automa Theory and Computations که در دانشگاه های ایران این درس با نام نظریه زبان ها و ماشین ها شناخته می شود . یکی از درس های مهم و base رشته علوم کامپیوتر می باشد به طوریکه اگر دانشجویان این رشته نتوانند به خوبی از پس درک و فهم این درس بر بیاید در ادامه کار با مشکلات زیادی رو به رو خواهند شد ( اما در ایران شاید به نظر برسد این حرف درست نیست )

سرفصل های پیشنهادی وزارت علوم برای این درس به این صورت است :
-مقدمه ای بر مباحث اولیه ریاضی مثل منطق و روش های اثبات
-معرفی انواع Automata
-معرفی انواع زبان ها
-مباحث Context-free Language
-مباحث Regular Lanuage
-مقدمه ای بر Computation Theory
-معرفی ماشین تورینگ و تئوری چرچ تورینگ و NP Hard و ...

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

دانشگاه Stanford که یکی از بهترین دانشگاه های دنیا در زمینه علوم کامپیوتر می باشد این درس را تحت عنوان دوره ی CS154 رائه می دهد و مدرس این دوره یکی از بهترین نویسنده های کتب های رشته علوم کامپیوتر یعنی Jeffrey D. Ullman می باشد

دوستان علاقه مند میتوانند از طریق لینک زیر ثبت نام کرده و به طور رایگان به تمامی منابع این دوره مانند جزوات اسلاید ها و تکالیف و امتحانات و از همه مهم تر "فیلم های ضبط شده این دوره" دسترسی داشته باشند و استفاده کنند

https://lagunita.stanford.edu/courses/course-v1:ComputerScience+Automata+SelfPaced/about

@de_coder

جلسه اول دوره CS154 یا همان Automata Theory - مدرس Jeffrey Ullman دانشگاه Stanford
@de_coder

زیرنویس انگلیسی جلسه اول CS154
@de_coder

يكي از مواردي كه دكتر ullman توي اين جلسه بهش اشاره ميكنه اين هستش كه افرادي كه روي يه سري مباحث از اين درس كار كردن و تونستن نتيجه تحقيقاتشون رو عملي كنند چه كساني بودن

يكي از اون افراد ken thompson بود. نام ايشون رو همه بخاطر ساخت Unix در خاطر دارند. سيستم عاملي كه با رهبري ايشون و آقاي dennis ritchie در مركز تحقيقات Bell Labs ساخته شد
تحقيقات ايشون در زمينه Regular Expressions منجر به نوشتن الگوريتم هايي شد براي تبديل كردن unix commands به program

نفر ديگر آقاي Jim Gray بود كه با مطالعه و تحقيق روي مبحث Push Down Automat موفق به كشف روش two phase locking براي مديريت concurrency control در DBMS ها شد

هر دوي اين دانشمندان بخاطر زحمات خود موفق به دريافت جايزه ACM Turing Awards شدن كه اين جايزه با ارزش ترين و مهم ترين جايزه اي هست كه يك computer scientist ميتواند در طول عمر خود كسب كند

اين موضوع قابل تأمل است كه به راستي چرا در دانشگاه هاي ايران حتي مدرسين درس نظريه زبان ها و ماشين ها ارزشي براي مطالب آن قائل نيستند و نميتوانند جايگاه اصلي اين درس را براي دانشجويان خود مشخص كنند

@de_coder

RFC
@de_coder

کسانی که در دنیای شبکه و ارتباطات کار میکنن قطعا به این مورد بر خوردن .

شاید تا حالا از خودتون پرسیده باشید شبکه ها یا اینترنت چگونه کار میکنند یا استانداردی برای شبکه و ارتباطات وجود داره ؟

خب اینجاست که شما به مقوله اي به نام RFC برخورد میکنید .

درواقع RFC به مجموعه ای از document ها گفته میشه یا بصورت تجربی هستند یا بصورت علمی یا یک شخص آنهارو نوشته یا یک organization آنهارو به تحریر در آورده.

خب نحوه مشخص کردن و تمایز قائل شدن برای RFC به این صورت است که عبارت RFC نوشته میشود و در ادامه چندین عدد اضافه میشود. مثلا:
RFC 2516 (PPPoE)
RFC 7414 (roadmap for TCP)
حالا هر کدوم از rfc ها درباره یک موضوع جدا صحبت میکنند البته ناگفته نماند که بعضی از آنها نیز در ادامه یا نسخه جدید تری از rfc قبلی هستن یا کلا یک موضوع یا پروژه جدا را بیان کرده اند .

حالا چرا یک rfc جدا برای نسخه جدید تر اختصاص میدهند ؟ چون rfc های نوشته شده دیگه نمیتوانند تغیر کنند و وقتی publish شوند دیگه تغیر ناپذیرند ونسخهای جدید تری از آن به عنوان rfc جدید تر منتشر میشوند.

همانطور که گفته شد rfc ها رو اشخاص هم میتوانند بنویسند ، اما این اشخاص چه کسانی هستند ؟ معمولا و اغلب کسانی که باعث ساخت اون پروژه شدند و یا مسئول اون پروژه بودند آنهارو مینویسند.

حالا چه سازمان ها یا نهاد هایی rfc نوشته اند ؟
Internet Engineering Task Force (IETF)
Internet Research Task Force (IRTF)
Internet Architecture Board (IAB)

البته نا گفته نمونه بیشتر و معروف تر از همشون IETF هستش سایت تیم IETF تمام RFC ها رو پشتیبانی میکنه و شما میتونید از این سایت بخوانید.

اما پشتیبان این سازمان ها و یا نهاد ها چه کسانی هستند ؟
گروهی به نام ISOC یا به عبارت دیگه
Internet Society

گروه ISOC چه گروهی هستن ؟
بعد از اینکه شبکهای ARPANET و DARPANET منحل شدن سازندگان این شبکها گرد هم آمده و تشکلی گروهی موصوم به ISOC را دادند .

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

حالا این پروژهایی که میگیم یعنی چی؟
منظور از پروژها به عنوان مثال پروتکل های شبکه در لايه هاي مختلف هستند تمام پروتکل های شبکه rfc دارند و از این طریق به صورت بین المللی استاندارد میشن و باید این استاندارد ها رو شرکتها لحاظ کنند البته همه ی RFC ها استاندارد نیستند و همانطور که گفته شد میتوانند تجربی ویا عملیاتی ( تمرینی ) هم باشند .
@de_coder

ISM @de_coder

intimate shared memory (ISM)
یک مکانیزم بهینه سازی است که ابتدا در Solaris 2.2 معرفی شده است.
این مکانیزم به منظور share کردن Translation table ها درگیر در ترجمه آدرس Virtual به Physical برای Page های حافظه مشترک به وجود آمده .

به طور معمول، سیستم های غیر ISM یک mapping در Process برای Page های حافظه مشترک را حفظ می کنند. با بسیاری از Process های متصل به حافظه مشترک، این طرح مقدار زیادی از mapping های بیش از حد را به Page های فیزیکی مشابهی ایجاد می کند. که Kernel باید maintain کند
یعنی به عبارت دیگر این مکانیزم از redundant شدن این mapping ها به ازای هر process جلوگیری میکند .


@de_coder

با سلام خدمت همه همراهان عزيز و ارجمند تيم Decoder

به زودي سايت ما آماده خواهد شد و از اين به بعد كتاب ها و فيلم هاي آموزشي و سورس كد هاي جديد و آرشيو موجود در كانال هاي مان را در آن قرار خواهيم داد

با تشكر از صبر و همراهي شما عزيزان كه با توجه به كم كاري تيم ما در سال اخير هنوز هم همراه ما هستيد 🙏🏻🌺

@debrary
@de_coder
@detube

شبیه سازی تکنیک Multiplexed I/O به روش سیستم کال select
زبان C
Developed by : mhmv
@de_coder

شبیه سازی تکنیک Multiplexed I/O به روش سیستم کال poll
زبان C
Developed by : mhmv
@de_coder

⭕️بررسی دقیق تر این دو system call (❌نه فراخوانی سیستمی !!!❌)


✳️select
این system call جهت فراهم کردن مکانیزمی برای پیاده سازی Multiplexed IO ولی به صورت synchronized است
و در کد هنگام call کردن . این system call بلاک شده تا زمانی که براساس file descriptor های تعریف شده برای آن . این فایل ها آماده برای انجام عمل io باشند
همان گونه که باید شنیده باشید این سناریو دقیقا همان سناریوی polling میباشد
توجه داشته باشید که در Actual parameter اولین این system call باید بزرگترین مقدار file descriptor (از مجموعه fd ها )بعلاوه ی ۱ واحد حتما محاسبه و به این system call ارسال شود

✳️poll
این system call در سیستم عامل یونیکس System V پیاده سازی شده
و ویژگی عمده ی آن تعریف شدن دو سری event به ازای هر file descriptor است
که یک سری event هایی که روی request ها و سری دیگر event هایی هستند که روی return ها تعریف میشوند

حال مقایسه ی بیشتر این دو system call :
1️⃣دومین system call (یعنی poll ) نیازی به محاسبه ی بزرگترین fd و بعلاوه ۱ نمودن آن ندارد
2️⃣ به همین دلیل اول میتوان گفت poll برای fd های با مقادیر بالا بهینه تر عمل میکند چون select به بررسی sequential بیت به بیت هر fd میپردازد
3️⃣در select مقادیر fd تعریف شده کاملا static هستند
4️⃣ هنگام return شدن select دوباره fd های تعریف شده را اصطلاحا reconstruct میکند یعنی مقادیر fd ها با تفییر همراه است ولی poll به دلیل متمایز تعریف نمودن دو سری event هنگام request و return این امکان را دارد که مجموعه fd ها را بدون تغییر باقی نگه دارد
5️⃣عملا select دارای خاصیت portability بالاتری است زیرا poll در تمامی سیستم های یونیکسی پیاده سازی نشده است
6️⃣در نهایت select دارای timeout resolution بالاتری نسبت به poll است زیرا select در سطح نانو ثانیه و poll در سطح میلی ثانیه عمل خواهند کرد

@de_coder

Browser structure
Describe by Pilofil
@de_coder

میخواییم ساختار مرورگر رو از سطح قابل فهم برای انسان بررسی کنیم.

مروگر از 7 قسمت تشکیل شده :

1. User interfaces
بخشایی مثل دکمه های عقب و جلو و یا دکمه refresh و یا بخش uri و یا bookmark در بر میگیره .

2. Browser engine ( * )
وظیفه به ترتیب و مرتب نمایش دادن فعالیت هایی که بین بخش user interface و render engine داره .

3. Rendering engine ( * )
وظیفه نمایش دادن و parsing نوشته ها (text) هارو داره یا بهتر بگیم وظیفه parsing کدها را دارد

4. Networking
ارسال درخواست ها و دریافت پاسخ ها و پردازش آنها و تحویل آنها به لایهای مربوطه.

5. Ui backend
وظیفه نمایش دادن عناصری که توی مرورگر نیست را با کمک بخش گرافیکی سیستم عامل داره ( مثلا ممکنه توی مروگری نمایش دکمه تعریف نشده و یا یک عنصر وجود نداشته باشه ) از این لایه به عنوان لایه widget ها نیز یاد شده. عوامیلی که مثلا باعث میشه عنصر input در ویندوز ها یا سیستم عامل ها ساختار گرافیکیش فرق بکنه مربوط به این بخش هستش.

6. Javascript interpreter
وظیفه پردازش و اجرا کردن کد های js

7. Data storage
وظیفه نگهداری فایلا و یا داده ها با استفاده از مکانیزم های پشتیبانی مثل :
1. Local storage
2. IndexedDB
3. WebSQL
4. File system
دارد .
مثل ذخیره کردن cookie ها و یا نمایش عکسها و...

این موارد استاندارد نیستند و حتی ممکنه در مروگر های مختلف عملکرد متفاوتی نشون بدن .
این موارد بر اساس تجربه شرکت های سازنده مروگر و یا تیم های توسعه دهنده تشکیل شده .
اما بخش Network دارای استاندارد های جهانی
هستش.

Describe by : Pilofil
@de_coder

Webkit Render Engine Main flow
@de_coder

Gecko Render Engine Main flow
@de_coder

Render Engine Basic flow
@de_coder

The main flow of render engine :

در وحله اول render engine اطلاعات در خواستی کاربر را از لایه network دریافت میکند که بصورت 8kB تقسیم بندی شده و به engin ارسال میشود بدین صورت که engine در خواست میکند و لایه network اطلاعات را 8kB به لایه engine تحویل میدهد.
بعد از این مرحله engine کار خود را بصورت زیر ادامه میدهد :
در وحله دوم engine عمل parsing را بر روی html انجام میدهد و element های html را به DOM node تبدیل کرده و با این node ها درختی به نام content tree و یا DOM tree میسازد

در ادامه مرورگر فایلهای مربوط به style که توسط css ساخته شده را parse میکند . فایلهای external با css های داخلی html چه بصورت inline چه به صورت internal هستند ، روی همه آنها عملیات parsing اعمال میشه.
در ادامه مروگر DOM node هایی که بدست آمده را با حاصل عملیات parsing بر روی style ها را با هم ادغام میکند و درخت جدیدی به نام Render tree میسازد

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

Painting The Render tree :

بعد از ساخت render tree نوبت به بخش layout میرسد. این بدین معنی می باشد که برای هر node مشخصات و مختصات مربوط به نمایش آن بر روی صفحه تعیین میشود . در وحله بعدی نوبت به رنگ کردن render tree می رسد این بدان معنی میباشد که render engine با پیمایش هر یک از node ها با استفاده از بخش UI backend ویژگی ها را به عناصر اختصاص میدهد یا به عبارت دیگر رنگ میکند و بعد به نمایش در میایند.

این نکته قابل توجه است :
تمام render engine ها برای user experience هر کدام از عملیات ها زود تر آماده شد و وقت کمتری برای پردازش برد ، در صفحه زودتر به نمایش درمیاید . این عملیات تا زمانی که کل درخت پیمایش بشه انجام میشه و engine صبر نمیکند تا کل درخت پیمایش بشه و بعد نمایش یابد.

@de_coder

Parsing process
@de_coder