این آقا خیلی تو لینکدین فارسی سروصدا به پا کرده و تو کتابخونه tensorflow کانتریبیوت کرده.
چند روز پیش تو یه کانال دیگم اشاره کرده بودن اما اینبار تو لینکدین خودمم پستشو دیدم.
هزارو خورده ای ری اکشن با کلی کامنت
اما قسمت دارک ماجرا زمانیه که محتویات کانتریبیوتش رو میبینیم که کلا یدونه کلمه از کامنت رو تغییر داده
واقعا لینکدین خیلی عجیبه
#fun
@Syntax_fa
چند روز پیش تو یه کانال دیگم اشاره کرده بودن اما اینبار تو لینکدین خودمم پستشو دیدم.
هزارو خورده ای ری اکشن با کلی کامنت
اما قسمت دارک ماجرا زمانیه که محتویات کانتریبیوتش رو میبینیم که کلا یدونه کلمه از کامنت رو تغییر داده
واقعا لینکدین خیلی عجیبه
#fun
@Syntax_fa
🤣53😁3👍1
کمی دور از انتظار باشه این رو به عنوان کسی دارم میگم که سالها ظهور و ناپدید شدن تکنولوژی ها و نوع تفکر قالب بر نرم افزار رو لمس کردم و در این فضا کار کردم به عنوان کسی که وقتی #ویژوال بیسیک کار میکردم فکر نمیکردم روزی از بازار حذف بشه یا فکر نمیکردم دات نت با یک تغییر در ساختار و رفتن سراغ #netcore بتونه با جاوا رقابت کنه و باز هم برام قابل تعریف نبود که زبان تازه به دنیا اومده ای مثل #گولنگ و #راست چنین با اقتدار قد علم کنن و مرزهای پرفورمنس رو به لرزه دربیارن و شاید تصور اینکه روزی در دنیای وب رقیبهایی به این قدرت رو برای #php متصور بشم سخت بود اما امروز با توجه به تمام تغیرات چه در نگرش به نرم افزار و معماری نرم افزار و همچنین پیش اومدن هوش مصنوعی در این حوزه به ناچار باید بگم دنیای #شی گرایی و #معماریهای شی گرا کم کم دارن کوله بارشون رو میبندن و زبانهای شی گرا باید جاشون رو به زبانهای جوانتر مثل همین #گولنگ و #راست بدن حرف من کنار رفتن زبانهای جاوا یا سی شارپ نیست دوستان موضوع کم رنگ شدن و قدرت گرفتن تفکر جدید هست تغییر نگرش زمانبر و طولانی مدت خواهد بود ولی #ساده سازی نوع #تفکر در برنامه نویسی و گذار از روش های سنتی و معماریهای سنتی در حال انجامه برای همین شما اسم #ورتیکال یا معماریهای مدرن دیگه رو میشنوید #مراقب جا موندن از قطار پر سرعت تغییرات باشید
Source
@Syntax_fa
Source
@Syntax_fa
👍25🔥3👻1
~> چالشهای یادگیری Go برای برنامهنویسهای تازهکار 🥰
یکی از مهمترین چالشهایی که برنامهنویسهای جدید موقع یادگیری Go باهاش روبرو میشن، درک مفهوم کانکارنسی هستش. Go با معرفی goroutines و channels سعی میکنه مدل سادهای برای برنامهنویسی همروند ارائه بده، اما درک عمیق این مفاهیم برای افرادی که تازه شروع کردن سخت میشه.
ارور هندلینگ در Go هم چالش دیگهای هستش که برنامهنویسهای جدید باهاش درگیر میشن. برخلاف زبانهایی مثل Java که از try-catch استفاده میکنن، Go از یک پترن سادهتر با استفاده از مقادیر error استفاده میکنه. این روش باعث میشه کد تمیزتر بشه، اما نیاز به چک کردن مکرر خطاها داره که میتونه برای تازهکارها گیجکننده باشه.
درک سیستم تایپهای Go برای برنامهنویسهایی که از زبانهای شیگرا میان میتونه چالشبرانگیز باشه. Go اصلاً یک زبان شیگرا نیست و به جای کلاس و آبجکت، از type برای تعریف structها و interfaceها استفاده میکنه. این structها و interfaceها صرفاً تایپ هستن و برای داک تایپینگ استفاده میشن. این تفاوت پارادایم برای کسایی که با OOP آشنا هستن میتونه گیجکننده باشه.
پوینترها توی Go یکی دیگه از نقاط چالشبرانگیز هستن. اگرچه Go نسبت به C مدیریت حافظه رو سادهتر کرده، اما هنوز هم درک اینکه کی باید از پوینتر استفاده کرد و کی نباید، برای برنامهنویسهای جدید سخت میشه.
سیستم پکیجهای Go و نحوه مدیریت dependencyها هم میتونه گیجکننده باشه. از Go 1.11 به بعد، سیستم module معرفی شد که اگرچه مشکلات قبلی GOPATH رو حل کرده، اما یادگیری نحوه کار با go.mod و go.sum برای تازهکارها زمانبر هستش.
یکی از ویژگیهای خاص Go که درکش برای برنامهنویسهای جدید سخت میشه، interfaceها هستن. Go از implicit interface implementation استفاده میکنه که با زبانهای دیگه متفاوت هستش و نیاز به تغییر دیدگاه داره.
نکته دیگهای که برای برنامهنویسهای تازهکار چالشبرانگیز میشه، عدم وجود جنریکها تا قبل از Go 1.18 بود. حالا که جنریکها اضافه شدن، یادگیری syntax و best practiceهای مربوط به اونها خودش یه چالش جدید محسوب میشه.
همچنین، Go یه سری قوانین سختگیرانه در مورد code formatting و نامگذاری داره. مثلاً اگه یه متغیر exported تعریف کنی، حتماً باید با حرف بزرگ شروع بشه، یا اینکه هر statement باید با semicolon تموم بشه (که البته کامپایلر خودش اضافه میکنه). این قوانین اگرچه به خوانایی کد کمک میکنن، اما رعایت کردنشون برای تازهکارها میتونه سخت باشه.
Source
@Syntax_fa
یکی از مهمترین چالشهایی که برنامهنویسهای جدید موقع یادگیری Go باهاش روبرو میشن، درک مفهوم کانکارنسی هستش. Go با معرفی goroutines و channels سعی میکنه مدل سادهای برای برنامهنویسی همروند ارائه بده، اما درک عمیق این مفاهیم برای افرادی که تازه شروع کردن سخت میشه.
ارور هندلینگ در Go هم چالش دیگهای هستش که برنامهنویسهای جدید باهاش درگیر میشن. برخلاف زبانهایی مثل Java که از try-catch استفاده میکنن، Go از یک پترن سادهتر با استفاده از مقادیر error استفاده میکنه. این روش باعث میشه کد تمیزتر بشه، اما نیاز به چک کردن مکرر خطاها داره که میتونه برای تازهکارها گیجکننده باشه.
درک سیستم تایپهای Go برای برنامهنویسهایی که از زبانهای شیگرا میان میتونه چالشبرانگیز باشه. Go اصلاً یک زبان شیگرا نیست و به جای کلاس و آبجکت، از type برای تعریف structها و interfaceها استفاده میکنه. این structها و interfaceها صرفاً تایپ هستن و برای داک تایپینگ استفاده میشن. این تفاوت پارادایم برای کسایی که با OOP آشنا هستن میتونه گیجکننده باشه.
پوینترها توی Go یکی دیگه از نقاط چالشبرانگیز هستن. اگرچه Go نسبت به C مدیریت حافظه رو سادهتر کرده، اما هنوز هم درک اینکه کی باید از پوینتر استفاده کرد و کی نباید، برای برنامهنویسهای جدید سخت میشه.
سیستم پکیجهای Go و نحوه مدیریت dependencyها هم میتونه گیجکننده باشه. از Go 1.11 به بعد، سیستم module معرفی شد که اگرچه مشکلات قبلی GOPATH رو حل کرده، اما یادگیری نحوه کار با go.mod و go.sum برای تازهکارها زمانبر هستش.
یکی از ویژگیهای خاص Go که درکش برای برنامهنویسهای جدید سخت میشه، interfaceها هستن. Go از implicit interface implementation استفاده میکنه که با زبانهای دیگه متفاوت هستش و نیاز به تغییر دیدگاه داره.
نکته دیگهای که برای برنامهنویسهای تازهکار چالشبرانگیز میشه، عدم وجود جنریکها تا قبل از Go 1.18 بود. حالا که جنریکها اضافه شدن، یادگیری syntax و best practiceهای مربوط به اونها خودش یه چالش جدید محسوب میشه.
همچنین، Go یه سری قوانین سختگیرانه در مورد code formatting و نامگذاری داره. مثلاً اگه یه متغیر exported تعریف کنی، حتماً باید با حرف بزرگ شروع بشه، یا اینکه هر statement باید با semicolon تموم بشه (که البته کامپایلر خودش اضافه میکنه). این قوانین اگرچه به خوانایی کد کمک میکنن، اما رعایت کردنشون برای تازهکارها میتونه سخت باشه.
Source
@Syntax_fa
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥3👻1
This media is not supported in your browser
VIEW IN TELEGRAM
شما در این ویدئو یک CPU آیفون را در زیر میکروسکوپ در کنار یک تار مو بعنوان مقایسه اندازه آن مشاهده میکنید.
@Syntax_fa
@Syntax_fa
😱20🤣5👍2👻2
تست Canary: راز پشت پرده تغییرات گوگل
چند وقت پیش داشتم ایمیلهایم را در گوگل چک میکردم که یک ویژگی جدید توجه من را جلب کرد؛ دکمهای مخصوص پرسش از هوش مصنوعی دربارهی محتوای ایمیلها. فکر کردم این یک تغییر جذاب است و سری به بقیه ایمیلهایم زدم تا از این فیچر استفاده کنم. اما جالب بود که این ویژگی فقط در یک ایمیل فعال شده بود! چرا همه کاربران این ویژگی را ندارند؟ مگر این همان گوگل نیست که وقتی چیزی اضافه میکند برای همه فعال میشود؟
با کمی تحقیق و کنجکاوی، به یک واژه رسیدم:
Canary Test
چرا تست Canary؟
تصور کنید گوگل میخواهد ویژگی جدیدی را به سرویس ایمیل خود اضافه کند. اگر این ویژگی بهدرستی کار نکند، ممکن است کل سیستم ایمیل دچار مشکل شود. اما به کمک Canary Test، ابتدا این تغییرات را برای گروه کوچکی از کاربران فعال میکنند. اگر همهچیز درست کار کرد، این تغییر را برای کاربران بیشتری اجرا میکنند؛ و اگر مشکلی رخ داد، بهسرعت به نسخه قبلی برمیگردند، بدون اینکه کسی متوجه شود.
فواید این تست
این تست مثل نگهبانی است که با فداکاری جلوی آسیبهای بزرگ را میگیرد
ریسک کمتر: ابتدا در شرایط محدود بررسی میشود که ویژگی جدید مشکلی ایجاد نکند.
شناسایی مشکلات: قبل از اینکه همه کاربران با باگها روبرو شوند، تیم توسعه آنها را شناسایی و رفع میکند.
تجربهی کاربری بهتر: بدون اختلال و با اطمینان بالا، کاربران از قابلیتهای جدید لذت میبرند.
گوگل، فیسبوک و سایر غولها چطور از Canary Test استفاده میکنند؟
در این روش، غولهای فناوری مثل گوگل و فیسبوک ابتدا تغییرات را به درصد کوچکی از کاربران عرضه میکنند. این کاربران بهعنوان "قناریهای" سیستم انتخاب میشوند تا در صورت شناسایی خطر، باقی کاربران در امان بمانند. اگر همهچیز خوب پیش رفت، تغییرات به همه عرضه میشود؛ و اگر نه، بهراحتی تغییرات را متوقف میکنند.
پس اگر روزی دیدید که شما یک قابلیت خاص در یک اپلیکیشن دارید و دوستانتان نه، بدانید شاید شما هم یکی از «قناریها»ی سیستم باشید! 🐤
Source
@Syntax_fa
چند وقت پیش داشتم ایمیلهایم را در گوگل چک میکردم که یک ویژگی جدید توجه من را جلب کرد؛ دکمهای مخصوص پرسش از هوش مصنوعی دربارهی محتوای ایمیلها. فکر کردم این یک تغییر جذاب است و سری به بقیه ایمیلهایم زدم تا از این فیچر استفاده کنم. اما جالب بود که این ویژگی فقط در یک ایمیل فعال شده بود! چرا همه کاربران این ویژگی را ندارند؟ مگر این همان گوگل نیست که وقتی چیزی اضافه میکند برای همه فعال میشود؟
با کمی تحقیق و کنجکاوی، به یک واژه رسیدم:
Canary Test
چرا تست Canary؟
تصور کنید گوگل میخواهد ویژگی جدیدی را به سرویس ایمیل خود اضافه کند. اگر این ویژگی بهدرستی کار نکند، ممکن است کل سیستم ایمیل دچار مشکل شود. اما به کمک Canary Test، ابتدا این تغییرات را برای گروه کوچکی از کاربران فعال میکنند. اگر همهچیز درست کار کرد، این تغییر را برای کاربران بیشتری اجرا میکنند؛ و اگر مشکلی رخ داد، بهسرعت به نسخه قبلی برمیگردند، بدون اینکه کسی متوجه شود.
فواید این تست
این تست مثل نگهبانی است که با فداکاری جلوی آسیبهای بزرگ را میگیرد
ریسک کمتر: ابتدا در شرایط محدود بررسی میشود که ویژگی جدید مشکلی ایجاد نکند.
شناسایی مشکلات: قبل از اینکه همه کاربران با باگها روبرو شوند، تیم توسعه آنها را شناسایی و رفع میکند.
تجربهی کاربری بهتر: بدون اختلال و با اطمینان بالا، کاربران از قابلیتهای جدید لذت میبرند.
گوگل، فیسبوک و سایر غولها چطور از Canary Test استفاده میکنند؟
در این روش، غولهای فناوری مثل گوگل و فیسبوک ابتدا تغییرات را به درصد کوچکی از کاربران عرضه میکنند. این کاربران بهعنوان "قناریهای" سیستم انتخاب میشوند تا در صورت شناسایی خطر، باقی کاربران در امان بمانند. اگر همهچیز خوب پیش رفت، تغییرات به همه عرضه میشود؛ و اگر نه، بهراحتی تغییرات را متوقف میکنند.
پس اگر روزی دیدید که شما یک قابلیت خاص در یک اپلیکیشن دارید و دوستانتان نه، بدانید شاید شما هم یکی از «قناریها»ی سیستم باشید! 🐤
Source
@Syntax_fa
👍13👻4
ادعای هک اطلاعات یکونیم میلیون کاربران بلو بانک.
دیگه فکر کنم برای ملت فرقی نمیکنه چون کل ایران اپن سورسه.
https://youtu.be/iaMeC798mdI?si=uN3oCDuAuIHUjRY6
@Syntax_fa
دیگه فکر کنم برای ملت فرقی نمیکنه چون کل ایران اپن سورسه.
https://youtu.be/iaMeC798mdI?si=uN3oCDuAuIHUjRY6
@Syntax_fa
YouTube
ادعای هک اطلاعات یک و نیم میلیون کاربر بلو بانک!
در این ویدیو به بررسی ادعای هکر به بدست آوردن اطلاعات یک و نیم میلیون از کاربران بلو بانک می پردازیم.
#hack #بلو_بانک #بانک #هک
#hack #بلو_بانک #بانک #هک
👍12👎2😱2
گفتگو شنیدنی GoCasts با مهندس کیانوش مختاریان، مهندس نرم افزار، رهبر فنی سابق در گوگل.
https://gocasts.ir/talk-with-kain
@Syntax_fa
https://gocasts.ir/talk-with-kain
@Syntax_fa
🔥15👍4👎4
در برنامهنویسی، اصطلاح "Idiomatic" به معنای استفاده از الگوها و روشهایی است که در یک زبان برنامهنویسی خاص به عنوان استاندارد و رایج شناخته میشوند. این موضوع اهمیت زیادی دارد و چندین دلیل برای آن وجود دارد:
1. خوانایی کد: کدی که به صورت idiomatic نوشته شده باشد، برای سایر برنامهنویسانی که با آن زبان آشنا هستند، راحتتر قابل درک است. این باعث میشود که تیمها به راحتی بتوانند با یکدیگر همکاری کنند.
2. نگهداری آسانتر: کدی که از الگوهای استاندارد پیروی میکند، به راحتی قابل نگهداری و اصلاح است. این امر بهویژه در پروژههای بزرگتر که افراد مختلفی روی آن کار میکنند، بسیار مهم است.
3. عملکرد بهتر: در بسیاری از موارد، استفاده از روشهای idiomatic به بهبود عملکرد کمک میکند، زیرا این روشها اغلب بهترین شیوههای بهینهسازی شده برای زبان مربوطه هستند.
4. کاهش خطاها: پیروی از الگوهای رایج به کاهش خطاها و باگها کمک میکند، زیرا این الگوها معمولاً توسط جامعه توسعهدهندگان آزمایش شدهاند و مطمئنتر هستند.
#idiomatic
@Syntax_fa
1. خوانایی کد: کدی که به صورت idiomatic نوشته شده باشد، برای سایر برنامهنویسانی که با آن زبان آشنا هستند، راحتتر قابل درک است. این باعث میشود که تیمها به راحتی بتوانند با یکدیگر همکاری کنند.
2. نگهداری آسانتر: کدی که از الگوهای استاندارد پیروی میکند، به راحتی قابل نگهداری و اصلاح است. این امر بهویژه در پروژههای بزرگتر که افراد مختلفی روی آن کار میکنند، بسیار مهم است.
3. عملکرد بهتر: در بسیاری از موارد، استفاده از روشهای idiomatic به بهبود عملکرد کمک میکند، زیرا این روشها اغلب بهترین شیوههای بهینهسازی شده برای زبان مربوطه هستند.
4. کاهش خطاها: پیروی از الگوهای رایج به کاهش خطاها و باگها کمک میکند، زیرا این الگوها معمولاً توسط جامعه توسعهدهندگان آزمایش شدهاند و مطمئنتر هستند.
#idiomatic
@Syntax_fa
👍14👻3🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Backpressure
تو این پست با چند مثال Backpressure رو بررسی میکنیم.
مثال اول:کارخانه شکلات
در برنامه تلویزیونی "I Love Lucy" قسمتی وجود دارد که Lucy در یک کارخانه بستهبندی شیرینی کار میکند. وظیفه او برداشتن شیرینی از نوار نقاله و بستهبندی هر کدام در کاغذ است.
او با این مشکل مواجه می شود که تعداد شیرینی هایی که در نوار نقاله می أید بیشتر از توان او در بسته بندی است.
او دو روش مختلف برای مقابله با آن را امتحان میکند: کنار گذاشتن برخی تا بعدا بهشون رسیدگی کنه (buffering)، و در نهایت شروع به خوردن و پنهان کردن آنها در کلاهش میکند (dropping). با این حال، در مورد یک کارخانه شکلات، هیچ یک از این استراتژیهای Backpressure عملی نیستند. در عوض، او نیاز داشت که نوار نقاله را آهستهتر کنند؛ به عبارت دیگر، او نیاز به کنترل سرعت producer دارد.
مثال دوم: خواندن و نوشتن از فایل:
حالا درباره Backpressure مرتبط با نرمافزار صحبت میکنیم. رایجترین حالت هنگام کار با file system است.
نوشتن در فایل کندتر از خواندن فایل است. تصور کنید یک hard drive که سرعت موثر خواندن ۱۵۰ مگابایت بر ثانیه و سرعت نوشتن ۱۰۰ مگابایت بر ثانیه را ارائه میدهد. اگر بخواهید فایلی را با حداکثر سرعت ممکن به memory بخوانید، در حالی که همزمان آن را با حداکثر سرعت ممکن به دیسک بنویسید - باید هر ثانیه ۵۰ مگابایت را buffer کنید. در هر ثانیه 50 مگابایت را باید بافر کنید!
شما نمیتوانید به بافر رسیدگی کنید تا زمانی که خواندن فایل ورودی کاملاً به پایان برسد.
حالا تصور کنید این کار را با یک فایل ۶ گیگابایتی انجام میدهید. تا زمانی که فایل را کاملاً خواندهاید، یک buffer ۲ گیگابایتی خواهید داشت که هنوز باید نوشتن آن را تمام کنید.
مقدار زیادی memory هدر رفته است. در برخی سیستمها این ممکن است حتی از مقدار memory موجود فراتر رود.
نگران نباشید، راهحل ساده است: فقط به همان سرعتی بخوانید که میتوانید بنویسید. تقریباً تمام I/O library ها abstraction هایی را برای انجام خودکار این کار برای شما ارائه میدهند.
مثال سوم: ارتباط Server
مثال بعدی ارتباط بین server ها است. امروزه استفاده از معماری microservice که در آن مسئولیتها بین چندین server تقسیم میشود بسیار رایج است.
Backpressure
معمولاً این سناریو زمانی رخ میدهد که یک server درخواستها را سریعتر از آنچه server دیگر میتواند پردازش کند، ارسال میکند.
اگر server A، ۱۰۰ rps (requests per second) به server B بفرستد، اما server B فقط بتواند ۷۵ rps را پردازش کند، شما یک کسری ۲۵ rps دارید.
در هر صورت، server B باید به نوعی با Backpressure مقابله کند. Buffer کردن آن کسری ۲۵ rps یک گزینه است، اما اگر آن افزایش ثابت بماند، به زودی memory تمام میشود و از کار میافتد. Drop کردن درخواستها گزینه دیگری است که در اکثر سناریو ها قابل قبول نیست.
گزینه ایدهآل این است که server B نرخ ارسال درخواستهای server A را کنترل کند، اما باز هم این همیشه عملی نیست - اگر server A به نمایندگی از یک کاربر درخواست میکند، شما نمیتوانید کاربر ها را کنترل کنید که آهستهتر شوند، اغلب بهتر است که server درخواست کننده buffer داشته باشد، تا بتوانید بار memory را در downstream، جایی که استرس وجود دارد، بهتر توزیع کنید و بر سایر درخواست کنندگان تأثیر نگذارید.
به عنوان مثال، اگر سه نوع مختلف سرویس (A, B, C) همگی به یک سرویس downstream مشترک (Z) درخواست بدهند، و یکی از آنها (A) تحت بار بالا باشد، سرویس Z میتواند به طور موثر به سرویس A بگوید "آهستهتر شو" (کنترل producer) که باعث میشود سرویس A درخواستها را buffer کند. اگر این ادامه پیدا کند، در نهایت سرویس A با کمبود memory مواجه میشود، با این حال، دو سرویس دیگر (B, C) همچنان فعال میمانند، همانطور که سرویس downstream Z نیز فعال میماند زیرا اجازه نمیدهد یک سرویس بدرفتار از دسترسی برابر برای دیگران جلوگیری کند. در این مورد ممکن است قطعی اجتنابناپذیر باشد، اما ما محدوده را محدود کردیم و از Denial of Service زنجیرهای جلوگیری کردیم.
مثال ها:
https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7
#Backpressure
@Syntax_fa
تو این پست با چند مثال Backpressure رو بررسی میکنیم.
مثال اول:کارخانه شکلات
در برنامه تلویزیونی "I Love Lucy" قسمتی وجود دارد که Lucy در یک کارخانه بستهبندی شیرینی کار میکند. وظیفه او برداشتن شیرینی از نوار نقاله و بستهبندی هر کدام در کاغذ است.
او با این مشکل مواجه می شود که تعداد شیرینی هایی که در نوار نقاله می أید بیشتر از توان او در بسته بندی است.
او دو روش مختلف برای مقابله با آن را امتحان میکند: کنار گذاشتن برخی تا بعدا بهشون رسیدگی کنه (buffering)، و در نهایت شروع به خوردن و پنهان کردن آنها در کلاهش میکند (dropping). با این حال، در مورد یک کارخانه شکلات، هیچ یک از این استراتژیهای Backpressure عملی نیستند. در عوض، او نیاز داشت که نوار نقاله را آهستهتر کنند؛ به عبارت دیگر، او نیاز به کنترل سرعت producer دارد.
مثال دوم: خواندن و نوشتن از فایل:
حالا درباره Backpressure مرتبط با نرمافزار صحبت میکنیم. رایجترین حالت هنگام کار با file system است.
نوشتن در فایل کندتر از خواندن فایل است. تصور کنید یک hard drive که سرعت موثر خواندن ۱۵۰ مگابایت بر ثانیه و سرعت نوشتن ۱۰۰ مگابایت بر ثانیه را ارائه میدهد. اگر بخواهید فایلی را با حداکثر سرعت ممکن به memory بخوانید، در حالی که همزمان آن را با حداکثر سرعت ممکن به دیسک بنویسید - باید هر ثانیه ۵۰ مگابایت را buffer کنید. در هر ثانیه 50 مگابایت را باید بافر کنید!
شما نمیتوانید به بافر رسیدگی کنید تا زمانی که خواندن فایل ورودی کاملاً به پایان برسد.
حالا تصور کنید این کار را با یک فایل ۶ گیگابایتی انجام میدهید. تا زمانی که فایل را کاملاً خواندهاید، یک buffer ۲ گیگابایتی خواهید داشت که هنوز باید نوشتن آن را تمام کنید.
6 GB / 150 MB = 40 seconds
150 MB - 100 MB = 50 MB deficit
50 MB x 40 = 2 GB !!!
مقدار زیادی memory هدر رفته است. در برخی سیستمها این ممکن است حتی از مقدار memory موجود فراتر رود.
نگران نباشید، راهحل ساده است: فقط به همان سرعتی بخوانید که میتوانید بنویسید. تقریباً تمام I/O library ها abstraction هایی را برای انجام خودکار این کار برای شما ارائه میدهند.
مثال سوم: ارتباط Server
مثال بعدی ارتباط بین server ها است. امروزه استفاده از معماری microservice که در آن مسئولیتها بین چندین server تقسیم میشود بسیار رایج است.
Backpressure
معمولاً این سناریو زمانی رخ میدهد که یک server درخواستها را سریعتر از آنچه server دیگر میتواند پردازش کند، ارسال میکند.
اگر server A، ۱۰۰ rps (requests per second) به server B بفرستد، اما server B فقط بتواند ۷۵ rps را پردازش کند، شما یک کسری ۲۵ rps دارید.
در هر صورت، server B باید به نوعی با Backpressure مقابله کند. Buffer کردن آن کسری ۲۵ rps یک گزینه است، اما اگر آن افزایش ثابت بماند، به زودی memory تمام میشود و از کار میافتد. Drop کردن درخواستها گزینه دیگری است که در اکثر سناریو ها قابل قبول نیست.
گزینه ایدهآل این است که server B نرخ ارسال درخواستهای server A را کنترل کند، اما باز هم این همیشه عملی نیست - اگر server A به نمایندگی از یک کاربر درخواست میکند، شما نمیتوانید کاربر ها را کنترل کنید که آهستهتر شوند، اغلب بهتر است که server درخواست کننده buffer داشته باشد، تا بتوانید بار memory را در downstream، جایی که استرس وجود دارد، بهتر توزیع کنید و بر سایر درخواست کنندگان تأثیر نگذارید.
به عنوان مثال، اگر سه نوع مختلف سرویس (A, B, C) همگی به یک سرویس downstream مشترک (Z) درخواست بدهند، و یکی از آنها (A) تحت بار بالا باشد، سرویس Z میتواند به طور موثر به سرویس A بگوید "آهستهتر شو" (کنترل producer) که باعث میشود سرویس A درخواستها را buffer کند. اگر این ادامه پیدا کند، در نهایت سرویس A با کمبود memory مواجه میشود، با این حال، دو سرویس دیگر (B, C) همچنان فعال میمانند، همانطور که سرویس downstream Z نیز فعال میماند زیرا اجازه نمیدهد یک سرویس بدرفتار از دسترسی برابر برای دیگران جلوگیری کند. در این مورد ممکن است قطعی اجتنابناپذیر باشد، اما ما محدوده را محدود کردیم و از Denial of Service زنجیرهای جلوگیری کردیم.
مثال ها:
https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7
#Backpressure
@Syntax_fa
👍5❤2👻2🔥1
وقتی به جای سیستمها، انسانها هک میشوند!
طبق تحقیقات و گزارشها، تخمین زده میشود که حدود 70 تا 90 درصد از حملات سایبری موفق، به نوعی از تکنیکهای مهندسی اجتماعی استفاده میکنند. این آمار نشاندهنده اهمیت آموزش و آگاهیبخشی به کاربران برای کاهش ریسک این گونه حملات است.
https://youtu.be/Z_S9jFkdCjY
@Syntax_fa
طبق تحقیقات و گزارشها، تخمین زده میشود که حدود 70 تا 90 درصد از حملات سایبری موفق، به نوعی از تکنیکهای مهندسی اجتماعی استفاده میکنند. این آمار نشاندهنده اهمیت آموزش و آگاهیبخشی به کاربران برای کاهش ریسک این گونه حملات است.
https://youtu.be/Z_S9jFkdCjY
@Syntax_fa
👍7👻4😱2
This media is not supported in your browser
VIEW IN TELEGRAM
یه تنوعی بدین به خودتون😂🔥
VsCode Extention : power mode
VsCode Extention : power mode
👻11🤣7🔥1
Forwarded from Normal Developer
مشکل خود سنیور پنداری!
جدیدا خیلیا رو میبینم که قبل از تخصصشون عنوان سنیور رو وصل میکنن. ولی واقعیت امر اینه که سنیور بودن یه لقب نیست. به زمان هم خیلی بستگی نداره که بعد از فعالیت n ساله در یک زمینه شما به این مرحله برسید.
کسی که خودش رو سنیور خطاب میکنه در واقع مهارت های خیلی زیادی رو باید داشته باشه که یکیشون برنامه نویسیه!
مهارت های نرم، مهارت یادگیری چیزهای جدید، طرز فکر و راهکار یابی و ... بخشی از پیشنیاز این صفت میشه.
تو فرایند جذب نیروی جدید برای شرکتمون رزومه های زیادی رو چک کردم و واقعا همه دوست دارن این عنوان رو قبل اسمشون داشته باشن.
عجیب ترین چیزی که دیدم هم مربوط میشه به یه فردی که بعد از یه بوت کمپ با یه شرکت شروع به همکاری چند ماهه کرده بود و عنوان شغلی خودش تو اون شرکت رو نوشته بود "Senior Django Developer"!
یعنی در فاصله کمتر از چند ماه به این درجه از عرفان رسیده بوده!
@normal_developer
جدیدا خیلیا رو میبینم که قبل از تخصصشون عنوان سنیور رو وصل میکنن. ولی واقعیت امر اینه که سنیور بودن یه لقب نیست. به زمان هم خیلی بستگی نداره که بعد از فعالیت n ساله در یک زمینه شما به این مرحله برسید.
کسی که خودش رو سنیور خطاب میکنه در واقع مهارت های خیلی زیادی رو باید داشته باشه که یکیشون برنامه نویسیه!
مهارت های نرم، مهارت یادگیری چیزهای جدید، طرز فکر و راهکار یابی و ... بخشی از پیشنیاز این صفت میشه.
تو فرایند جذب نیروی جدید برای شرکتمون رزومه های زیادی رو چک کردم و واقعا همه دوست دارن این عنوان رو قبل اسمشون داشته باشن.
عجیب ترین چیزی که دیدم هم مربوط میشه به یه فردی که بعد از یه بوت کمپ با یه شرکت شروع به همکاری چند ماهه کرده بود و عنوان شغلی خودش تو اون شرکت رو نوشته بود "Senior Django Developer"!
یعنی در فاصله کمتر از چند ماه به این درجه از عرفان رسیده بوده!
@normal_developer
👍22🤣9😁2
Hard Coding
به معنای استفاده از مقادیر ثابت و تعریفشده درون کد یک برنامه، بهجای استفاده از ورودیهای داینامیک، متغیرها یا منابع خارجی (مثل فایلهای کانفیگ یا پایگاههای داده). در این روش، مقادیر بهصورت مستقیم در کد قرار میگیرند و برای تغییر آنها نیاز به ویرایش دستی کد است.
مثال ساده:
مزایای Hard Coding
1. سادگی اولیه: کدنویسی سریعتر و آسانتر است، زیرا نیازی به ایجاد ساختارهای پیچیده برای مدیریت مقادیر نیست.
2. کاهش پیچیدگی در پروژههای کوچک: در برنامههای کوچک و ساده، ممکن است نیازی به طراحی سیستمهای دینامیک برای مدیریت مقادیر نباشد.
3. کاهش وابستگی به منابع خارجی: در صورت hard coding، نیازی به مدیریت فایلهای پیکربندی، پایگاه داده یا ورودیهای خارجی وجود ندارد.
معایب Hard Coding
1. کاهش انعطافپذیری: تغییر مقادیر ثابت نیازمند تغییر کد منبع و بازنویسی یا بازسازی برنامه است، که میتواند زمانبر باشد.
2. نگهداری سختتر: در برنامههای بزرگ، مدیریت مقادیر hard coded دشوار است و میتواند باعث افزایش احتمال بروز خطا شود.
3. محدودیت در تنظیمات داینامیک: برنامههای مبتنی بر hard coding نمیتوانند به راحتی خود را با شرایط یا محیطهای مختلف سازگار کنند.
جایگزینها برای Hard Coding
1. استفاده از فایلهای تنظیمات (Config Files): ذخیره مقادیر در فایلهای خارجی مانند
2. دیتابیس: استفاده از دیتابیس برای مدیریت مقادیر پویا.
3. متغیرهای محیطی (Environment Variables): استفاده از متغیرهای سیستمعامل برای ذخیره مقادیر حساس مانند secret key.
4. ورودیهای پویا از کاربر: گرفتن مقادیر از کاربر بهصورت runtime.
متغیر هایی که حساس نیستند بهتره براشون fallback تعریف کنیم.
برای مثال اول چک بشه اگه بصورت دستی داخل کانفیگ مقداری براشون ست شده، از اونجا بخونه ولی اگه نبود با مقدار پیشفرض کار کنه و اروری نده. تا برناممون برای استفاده راحت تر باشه و برای شخصی سازی هم دستمون رو باز بذاره.
#hard_coding
@Syntax_fa
به معنای استفاده از مقادیر ثابت و تعریفشده درون کد یک برنامه، بهجای استفاده از ورودیهای داینامیک، متغیرها یا منابع خارجی (مثل فایلهای کانفیگ یا پایگاههای داده). در این روش، مقادیر بهصورت مستقیم در کد قرار میگیرند و برای تغییر آنها نیاز به ویرایش دستی کد است.
مثال ساده:
# Hard coded example
deposit = 0.1
price = 100
final_price = price + (price * deposit)
print(final_price)
مزایای Hard Coding
1. سادگی اولیه: کدنویسی سریعتر و آسانتر است، زیرا نیازی به ایجاد ساختارهای پیچیده برای مدیریت مقادیر نیست.
2. کاهش پیچیدگی در پروژههای کوچک: در برنامههای کوچک و ساده، ممکن است نیازی به طراحی سیستمهای دینامیک برای مدیریت مقادیر نباشد.
3. کاهش وابستگی به منابع خارجی: در صورت hard coding، نیازی به مدیریت فایلهای پیکربندی، پایگاه داده یا ورودیهای خارجی وجود ندارد.
معایب Hard Coding
1. کاهش انعطافپذیری: تغییر مقادیر ثابت نیازمند تغییر کد منبع و بازنویسی یا بازسازی برنامه است، که میتواند زمانبر باشد.
2. نگهداری سختتر: در برنامههای بزرگ، مدیریت مقادیر hard coded دشوار است و میتواند باعث افزایش احتمال بروز خطا شود.
3. محدودیت در تنظیمات داینامیک: برنامههای مبتنی بر hard coding نمیتوانند به راحتی خود را با شرایط یا محیطهای مختلف سازگار کنند.
جایگزینها برای Hard Coding
1. استفاده از فایلهای تنظیمات (Config Files): ذخیره مقادیر در فایلهای خارجی مانند
JSON`، `YAML`، یا `INI.2. دیتابیس: استفاده از دیتابیس برای مدیریت مقادیر پویا.
3. متغیرهای محیطی (Environment Variables): استفاده از متغیرهای سیستمعامل برای ذخیره مقادیر حساس مانند secret key.
4. ورودیهای پویا از کاربر: گرفتن مقادیر از کاربر بهصورت runtime.
متغیر هایی که حساس نیستند بهتره براشون fallback تعریف کنیم.
برای مثال اول چک بشه اگه بصورت دستی داخل کانفیگ مقداری براشون ست شده، از اونجا بخونه ولی اگه نبود با مقدار پیشفرض کار کنه و اروری نده. تا برناممون برای استفاده راحت تر باشه و برای شخصی سازی هم دستمون رو باز بذاره.
#hard_coding
@Syntax_fa
👍12🔥2👻2
نمونههایی از وبسایتها و شرکتهای بزرگ که استانداردهای مشخصشده را رعایت نکردهاند
1. Dropbox
- مشکل: استفاده از یک متد HTTP (POST) برای همه درخواستها
- توضیح:
در نسخههای اولیه API خود، تقریباً همه درخواستها (حتی موارد مربوط به خواندن دادهها) را با متد POST انجام میداد. این در حالی است که طبق استاندارد HTTP، متدهای GET باید برای دریافت دادهها استفاده شوند و نیازی به ارسال داده در بدنه (Body) نیست.
2. Twitter
- مشکل: استفاده از Query String برای ارسال اطلاعات حساس
- توضیح:
در نسخههای اولیه API توییتر، برخی از درخواستهای احراز هویت (مانند ارسال کلید API یا Access Token) از طریق Query String انجام میشد. این روش باعث میشد که اطلاعات حساس در URL ذخیره شوند و در لاگهای سرور یا مرورگر ثبت شوند.
چرا استاندارد نیست؟
طبق اصول امنیتی، اطلاعات حساس باید در بدنه درخواست (Body) یا هدر (Header) ارسال شوند، نه در Query String.
3. GitHub
- مشکل: استفاده از Status Code 404 برای پنهان کردن اطلاعات
- توضیح:
گیت هاب در برخی از APIهای خود، وقتی کاربری به یک منبع غیرمجاز دسترسی پیدا میکند (مثلاً یک ریپازیتوری خصوصی)، به جای استفاده از کد وضعیت 403 Forbidden، کد 404 Not Found را برمیگرداند. این کار برای جلوگیری از افشای وجود منابعی که کاربر به آنها دسترسی ندارد انجام میشود.
4. Facebook
- مشکل: عدم استفاده صحیح از محدودیت نرخ (Rate Limit) در برخی نسخههای اولیه API
- توضیح:
در نسخههای اولیه API فیسبوک، محدودیت نرخ (Rate Limit) به صورت یکنواخت برای همه کاربران اعمال نمیشد و رفتار مشخصی برای درخواستهای بیش از حد وجود نداشت. گاهی درخواستهای اضافی به صورت موفقیتآمیز پاسخ داده میشدند، اما در برخی موارد دیگر خطای غیرشفاف بازگردانده میشد.
5. Instagram
- مشکل: استفاده از کد وضعیت 200 برای خطاها
- توضیح:
در API اینستاگرام، در برخی از نسخههای قدیمی، خطاها (مانند درخواستهای نامعتبر) با کد وضعیت 200 OK بازگشت داده میشدند و جزئیات خطا در بدنه پاسخ قرار میگرفت.
6. PayPal
- مشکل: استفاده از کدهای وضعیت غیررایج
- توضیح:
در برخی پاسخهای APIهای قدیمی PayPal، کدهای وضعیت غیررایج یا غیرمستند (مانند 490) ارسال میشدند. این کدها در مستندات HTTP تعریف نشدهاند و کلاینتها نمیتوانند به درستی آنها را پردازش کنند.
7. Amazon S3
- مشکل: استفاده از کد وضعیت 200 برای پاسخهای جزئی
- توضیح:
در برخی از عملیات S3 (مانند لیست کردن اشیاء در یک باکت بزرگ)، اگر پاسخ به دلیل محدودیت اندازه به صورت چندبخشی باشد (Partial Response)، همچنان کد وضعیت 200 OK بازگردانده میشود.
چرا استاندارد نیست؟
برای پاسخهایی که تنها بخشی از دادهها را شامل میشوند، استاندارد HTTP کد 206 Partial Content را پیشنهاد میکند.
8. LinkedIn
- مشکل: ساختار غیریکسان در پاسخهای JSON
- توضیح:
در برخی از نسخههای قدیمی APIهای لینکدین، ساختار پاسخهای JSON در درخواستهای مختلف یکنواخت نبود. مثلاً کلیدها در یک پاسخ به صورت snake_case و در پاسخ دیگر به صورت camelCase بودند.
چرا استاندارد نیست؟
یکی از اصول طراحی API این است که ساختار پاسخها باید یکنواخت باشد تا توسعهدهندگان بتوانند به راحتی آنها را پردازش کنند.
9. Google Maps API
مشکل: ارسال دادههای غیرضروری در پاسخها
- توضیح:
در برخی پاسخهای Google Maps API، مقادیر غیرضروری و اضافی که گاهی هیچ ارتباطی با درخواست کاربر ندارند، بازگردانده میشدند. این میتواند باعث افزایش حجم داده و تأخیر در پردازش شود.
@Syntax_fa
1. Dropbox
- مشکل: استفاده از یک متد HTTP (POST) برای همه درخواستها
- توضیح:
در نسخههای اولیه API خود، تقریباً همه درخواستها (حتی موارد مربوط به خواندن دادهها) را با متد POST انجام میداد. این در حالی است که طبق استاندارد HTTP، متدهای GET باید برای دریافت دادهها استفاده شوند و نیازی به ارسال داده در بدنه (Body) نیست.
2. Twitter
- مشکل: استفاده از Query String برای ارسال اطلاعات حساس
- توضیح:
در نسخههای اولیه API توییتر، برخی از درخواستهای احراز هویت (مانند ارسال کلید API یا Access Token) از طریق Query String انجام میشد. این روش باعث میشد که اطلاعات حساس در URL ذخیره شوند و در لاگهای سرور یا مرورگر ثبت شوند.
چرا استاندارد نیست؟
طبق اصول امنیتی، اطلاعات حساس باید در بدنه درخواست (Body) یا هدر (Header) ارسال شوند، نه در Query String.
3. GitHub
- مشکل: استفاده از Status Code 404 برای پنهان کردن اطلاعات
- توضیح:
گیت هاب در برخی از APIهای خود، وقتی کاربری به یک منبع غیرمجاز دسترسی پیدا میکند (مثلاً یک ریپازیتوری خصوصی)، به جای استفاده از کد وضعیت 403 Forbidden، کد 404 Not Found را برمیگرداند. این کار برای جلوگیری از افشای وجود منابعی که کاربر به آنها دسترسی ندارد انجام میشود.
4. Facebook
- مشکل: عدم استفاده صحیح از محدودیت نرخ (Rate Limit) در برخی نسخههای اولیه API
- توضیح:
در نسخههای اولیه API فیسبوک، محدودیت نرخ (Rate Limit) به صورت یکنواخت برای همه کاربران اعمال نمیشد و رفتار مشخصی برای درخواستهای بیش از حد وجود نداشت. گاهی درخواستهای اضافی به صورت موفقیتآمیز پاسخ داده میشدند، اما در برخی موارد دیگر خطای غیرشفاف بازگردانده میشد.
5. Instagram
- مشکل: استفاده از کد وضعیت 200 برای خطاها
- توضیح:
در API اینستاگرام، در برخی از نسخههای قدیمی، خطاها (مانند درخواستهای نامعتبر) با کد وضعیت 200 OK بازگشت داده میشدند و جزئیات خطا در بدنه پاسخ قرار میگرفت.
6. PayPal
- مشکل: استفاده از کدهای وضعیت غیررایج
- توضیح:
در برخی پاسخهای APIهای قدیمی PayPal، کدهای وضعیت غیررایج یا غیرمستند (مانند 490) ارسال میشدند. این کدها در مستندات HTTP تعریف نشدهاند و کلاینتها نمیتوانند به درستی آنها را پردازش کنند.
7. Amazon S3
- مشکل: استفاده از کد وضعیت 200 برای پاسخهای جزئی
- توضیح:
در برخی از عملیات S3 (مانند لیست کردن اشیاء در یک باکت بزرگ)، اگر پاسخ به دلیل محدودیت اندازه به صورت چندبخشی باشد (Partial Response)، همچنان کد وضعیت 200 OK بازگردانده میشود.
چرا استاندارد نیست؟
برای پاسخهایی که تنها بخشی از دادهها را شامل میشوند، استاندارد HTTP کد 206 Partial Content را پیشنهاد میکند.
8. LinkedIn
- مشکل: ساختار غیریکسان در پاسخهای JSON
- توضیح:
در برخی از نسخههای قدیمی APIهای لینکدین، ساختار پاسخهای JSON در درخواستهای مختلف یکنواخت نبود. مثلاً کلیدها در یک پاسخ به صورت snake_case و در پاسخ دیگر به صورت camelCase بودند.
چرا استاندارد نیست؟
یکی از اصول طراحی API این است که ساختار پاسخها باید یکنواخت باشد تا توسعهدهندگان بتوانند به راحتی آنها را پردازش کنند.
9. Google Maps API
مشکل: ارسال دادههای غیرضروری در پاسخها
- توضیح:
در برخی پاسخهای Google Maps API، مقادیر غیرضروری و اضافی که گاهی هیچ ارتباطی با درخواست کاربر ندارند، بازگردانده میشدند. این میتواند باعث افزایش حجم داده و تأخیر در پردازش شود.
@Syntax_fa
👍20🔥3👻3❤1👎1
ساختار پروژه های جنگویی تیم سینتکسفا
در پروژههای نرمافزاری، به ویژه پروژههای بزرگ، ساختار مناسب کد نقش کلیدی داره. ساختار پروژه تأثیر مستقیمی به خوانایی، قابلیت نگهداری، و مقیاسپذیری کد داره.
در جنگو، یک ساختار مناسب تضمین میکنه که تیم توسعهدهنده به راحتی میتونن کد رو گسترش بدن اشکالات رو رفع کنن و ویژگیهای جدیدی به پروژه اضافه کنن. بدون معماری منسجم و اصولی، مدیریت کد پیچیده و زمانبر میشه.
تیم سینتکس در حال حاضر از ساختاری که توی این ریپو بصورت پابلیک قرار دادیم استفاده میکنه.
امیدوارم براتون مفید باشه 🙏
اگه اشکالی توی ساختار میبینید و جای بهبود داره حتما پول ریکوئست بزنید یا بهمون اطلاع بدید.
همچنین به مرور زمان داکیومنت رو هم اضافه میکنیم و سعی میکنیم همیشه آپدیت باشه.
برای حمایت از ما ستاره فراموش نشه🍸
https://github.com/syntaxfa/django-structure
#django #structure
@Syntax_fa
در پروژههای نرمافزاری، به ویژه پروژههای بزرگ، ساختار مناسب کد نقش کلیدی داره. ساختار پروژه تأثیر مستقیمی به خوانایی، قابلیت نگهداری، و مقیاسپذیری کد داره.
در جنگو، یک ساختار مناسب تضمین میکنه که تیم توسعهدهنده به راحتی میتونن کد رو گسترش بدن اشکالات رو رفع کنن و ویژگیهای جدیدی به پروژه اضافه کنن. بدون معماری منسجم و اصولی، مدیریت کد پیچیده و زمانبر میشه.
تیم سینتکس در حال حاضر از ساختاری که توی این ریپو بصورت پابلیک قرار دادیم استفاده میکنه.
امیدوارم براتون مفید باشه 🙏
اگه اشکالی توی ساختار میبینید و جای بهبود داره حتما پول ریکوئست بزنید یا بهمون اطلاع بدید.
همچنین به مرور زمان داکیومنت رو هم اضافه میکنیم و سعی میکنیم همیشه آپدیت باشه.
برای حمایت از ما ستاره فراموش نشه
https://github.com/syntaxfa/django-structure
#django #structure
@Syntax_fa
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - syntaxfa/django-structure: In this repository, you will learn about the structure used by the Syntax team.
In this repository, you will learn about the structure used by the Syntax team. - syntaxfa/django-structure
🔥14👍9❤3👻2👎1😱1
Forwarded from Kereshme | کِرِشمه
Media is too big
VIEW IN TELEGRAM
قبل اینکه روشن بشه بگو کدوم نقاشیه 😏
اینم یکی از خاص ترین تابلو لومن هامون، شب پر ستاره ونگوگ
ــــــــــــــــــــــــــــــــ
همچنین عکس و طرح دلخواه خودتونم میزنیم😀
سفارش از طریق آیدی زیر:
@ayeef
#محصول@kereshme_tel
#تابلو_لومن@kereshme_tel
@Kereshme_tel
ــــــــــــــــــــــــــــــــ
همچنین عکس و طرح دلخواه خودتونم میزنیم
سفارش از طریق آیدی زیر:
@ayeef
#محصول@kereshme_tel
#تابلو_لومن@kereshme_tel
@Kereshme_tel
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥6🔥4👍2🥰1
Kereshme | کِرِشمه
قبل اینکه روشن بشه بگو کدوم نقاشیه 😏 اینم یکی از خاص ترین تابلو لومن هامون، شب پر ستاره ونگوگ ــــــــــــــــــــــــــــــــ همچنین عکس و طرح دلخواه خودتونم میزنیم 😀 سفارش از طریق آیدی زیر: @ayeef #محصول@kereshme_tel #تابلو_لومن@kereshme_tel @Kereshme_tel
ادمینتون از این کارام میکنه
کسی خواست بخره با تخفیف سینتکسی در خدمتم🍸
کسی خواست بخره با تخفیف سینتکسی در خدمتم
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍4
قبل از DNS
بذارید یه نگاه به دوران قبل از DNS بندازیم. اون زمان خبری از این راحتیای که الان داریم نبود. اینترنت بود، ولی به جای اینکه اسم سایتها رو وارد کنید، باید با یه مشت عدد و رقم سر و کله میزدید. حالا ببینیم اون روزا مردم چطوری با اینترنت کار میکردن:
1. حفظ کردن آدرسهای IP
قبل از DNS، شما برای باز کردن سایتها مجبور بودید آدرسهای IP مثل
2. فایل HOSTS
کامپیوترها اون زمان یه فایل به اسم `hosts` داشتن که مثل دفترچه تلفن عمل میکرد. تو این فایل، آدرس IPها به اسمهای خاصی (اگه وجود داشت) نگاشت میشدن. مثلاً نوشته میشد:
این فایل هم بهصورت دستی بهروزرسانی میشد. حالا تصور کنید اگه یه سایت جدید اضافه میشد یا سرور یه سایت تغییر میکرد، دوباره باید فایل رو باز میکردید، خط جدید اضافه میکردید یا آدرس قدیمی رو عوض میکردید. یه کار خستهکننده و وقتگیر!
3. کشف سایتها؟ یه چالش واقعی!
یادمون باشه که اون زمان خبری از موتورهای جستجو مثل گوگل یا یاهو نبود. شما یا باید آدرس IP یه سایت رو از کسی میشنیدید، یا توی یه مجله یا کتاب میدیدید. اگه یه سایت جدید میخواستید پیدا کنید، باید امیدوار میبودید که کسی آدرسش رو بهتون بده.
4. مشکل هماهنگی
هر شبکهای نسخه خودش از فایل
#fun
@Syntax_fa
بذارید یه نگاه به دوران قبل از DNS بندازیم. اون زمان خبری از این راحتیای که الان داریم نبود. اینترنت بود، ولی به جای اینکه اسم سایتها رو وارد کنید، باید با یه مشت عدد و رقم سر و کله میزدید. حالا ببینیم اون روزا مردم چطوری با اینترنت کار میکردن:
1. حفظ کردن آدرسهای IP
قبل از DNS، شما برای باز کردن سایتها مجبور بودید آدرسهای IP مثل
192.168.1.1 یا 216.58.214.14 رو تایپ کنید. مثلاً اگه میخواستید به یه سایت خاص برید، باید آدرس IP اون رو از جایی پیدا میکردید و دستی وارد میکردید. کاملاً منطقیه که خیلیها دفترچهای کنار دستشون داشتن و توش آدرسهای IP مهم رو مینوشتن، چون حفظ کردن این اعداد اصلاً کار سادهای نبود.2. فایل HOSTS
کامپیوترها اون زمان یه فایل به اسم `hosts` داشتن که مثل دفترچه تلفن عمل میکرد. تو این فایل، آدرس IPها به اسمهای خاصی (اگه وجود داشت) نگاشت میشدن. مثلاً نوشته میشد:
93.184.216.34 example.com
216.58.214.14 google.com
این فایل هم بهصورت دستی بهروزرسانی میشد. حالا تصور کنید اگه یه سایت جدید اضافه میشد یا سرور یه سایت تغییر میکرد، دوباره باید فایل رو باز میکردید، خط جدید اضافه میکردید یا آدرس قدیمی رو عوض میکردید. یه کار خستهکننده و وقتگیر!
3. کشف سایتها؟ یه چالش واقعی!
یادمون باشه که اون زمان خبری از موتورهای جستجو مثل گوگل یا یاهو نبود. شما یا باید آدرس IP یه سایت رو از کسی میشنیدید، یا توی یه مجله یا کتاب میدیدید. اگه یه سایت جدید میخواستید پیدا کنید، باید امیدوار میبودید که کسی آدرسش رو بهتون بده.
4. مشکل هماهنگی
هر شبکهای نسخه خودش از فایل
hosts رو داشت. حالا اگه یه سایت جدید اضافه میشد یا تغییری توی یه آدرس IP رخ میداد، باید اون تغییر رو دستی به همه شبکهها اطلاع میدادید. این هماهنگی برای شبکههای بزرگتر شبیه یه کابوس بود.#fun
@Syntax_fa
👍10😱6❤1👏1🤣1👻1
تایپهای مختلف DNS رکورد و کاربردهای آنها
1. A Record (Address Record)
کاربرد:
این رکورد، نام دامنه را به آدرس IPv4 تبدیل میکند. این نوع رکورد یکی از رایجترین و مهمترین رکوردها در DNS است.
مثال:
اگر کاربری آدرس
موارد استفاده:
- اتصال نام دامنه به آدرس IPv4 سرور
2. AAAA Record
کاربرد:
مشابه رکورد A است، اما برای آدرسهای IPv6 استفاده میشود.
مثال:
اگر نام دامنه
موارد استفاده:
- اتصال دامنه به آدرس IPv6
3. CNAME Record (Canonical Name Record)
کاربرد:
این رکورد نام یک دامنه را به دامنه دیگری اشاره میدهد. به جای ذخیره مستقیم آدرس IP، از این رکورد برای هدایت به نام دامنهای دیگر استفاده میشود.
مثال:
اگر
موارد استفاده:
- تغییر مسیر زیردامنهها.
- سادهسازی مدیریت DNS در صورت تغییر آدرس IP.
4. MX Record (Mail Exchange Record)
کاربرد:
این رکورد برای مشخص کردن سرورهای ایمیل دامنه استفاده میشود. رکورد MX مشخص میکند که ایمیلهای ارسالی به دامنه باید به کدام سرور ارسال شوند.
مثال:
اگر رکورد MX برای
موارد استفاده:
- تنظیم سرور ایمیل.
- مدیریت اولویت ارسال ایمیل (اولویتها با اعداد مشخص میشوند).
5. TXT Record
کاربرد:
این رکورد برای ذخیره اطلاعات متنی استفاده میشود. معمولاً از آن برای تأیید مالکیت دامنه و اطلاعات امنیتی استفاده میشود.
مثال:
- تأیید مالکیت دامنه برای Google Search Console.
- پیادهسازی پروتکلهای امنیتی مانند SPF، DKIM، و DMARC.
موارد استفاده:
- جلوگیری از اسپم و جعل هویت ایمیل.
- تأیید سرویسهای خارجی.
6. NS Record (Name Server Record)
کاربرد:
این رکورد مشخص میکند که کدام سرورهای DNS مسئول مدیریت رکوردهای دامنه هستند.
مثال:
برای دامنه
موارد استفاده:
- تعیین سرورهای DNS اصلی یک دامنه.
- مدیریت و نگهداری رکوردهای دامنه.
7. SOA Record (Start of Authority)
کاربرد:
این رکورد اطلاعات پایهای درباره دامنه و سرور DNS اولیه ارائه میدهد. SOA رکورد شامل اطلاعاتی مانند آدرس ایمیل مدیر دامنه و زمان بهروزرسانی رکوردها است.
موارد استفاده:
- مشخص کردن سرور اصلی DNS.
- مدیریت بهروزرسانی رکوردهای DNS.
8. PTR Record (Pointer Record)
کاربرد:
این رکورد برای جستجوی معکوس DNS استفاده میشود (تبدیل آدرس IP به نام دامنه). برخلاف رکورد A که دامنه را به IP تبدیل میکند، PTR آدرس IP را به نام دامنه تبدیل میکند.
موارد استفاده:
- تأیید هویت سرورها.
- جلوگیری از ارسال ایمیلهای اسپم.
#DNS_records
@Syntax_fa
1. A Record (Address Record)
کاربرد:
این رکورد، نام دامنه را به آدرس IPv4 تبدیل میکند. این نوع رکورد یکی از رایجترین و مهمترین رکوردها در DNS است.
مثال:
اگر کاربری آدرس
example.com را وارد کند، DNS با استفاده از رکورد A، آدرس IP مربوط به آن (مثلاً 93.184.216.34) را برمیگرداند.موارد استفاده:
- اتصال نام دامنه به آدرس IPv4 سرور
2. AAAA Record
کاربرد:
مشابه رکورد A است، اما برای آدرسهای IPv6 استفاده میشود.
مثال:
اگر نام دامنه
example.com از رکورد AAAA استفاده کند، ممکن است به آدرس IPv6 مانند 2606:2800:220:1:248:1893:25c8:1946 اشاره کند.موارد استفاده:
- اتصال دامنه به آدرس IPv6
3. CNAME Record (Canonical Name Record)
کاربرد:
این رکورد نام یک دامنه را به دامنه دیگری اشاره میدهد. به جای ذخیره مستقیم آدرس IP، از این رکورد برای هدایت به نام دامنهای دیگر استفاده میشود.
مثال:
اگر
www.example.com یک رکورد CNAME داشته باشد که به example.com اشاره کند، تمامی درخواستها به www.example.com به آدرس example.com هدایت میشوند.موارد استفاده:
- تغییر مسیر زیردامنهها.
- سادهسازی مدیریت DNS در صورت تغییر آدرس IP.
4. MX Record (Mail Exchange Record)
کاربرد:
این رکورد برای مشخص کردن سرورهای ایمیل دامنه استفاده میشود. رکورد MX مشخص میکند که ایمیلهای ارسالی به دامنه باید به کدام سرور ارسال شوند.
مثال:
اگر رکورد MX برای
example.com به mail.example.com اشاره کند، تمامی ایمیلها به سرور mail.example.com ارسال میشوند.موارد استفاده:
- تنظیم سرور ایمیل.
- مدیریت اولویت ارسال ایمیل (اولویتها با اعداد مشخص میشوند).
5. TXT Record
کاربرد:
این رکورد برای ذخیره اطلاعات متنی استفاده میشود. معمولاً از آن برای تأیید مالکیت دامنه و اطلاعات امنیتی استفاده میشود.
مثال:
- تأیید مالکیت دامنه برای Google Search Console.
- پیادهسازی پروتکلهای امنیتی مانند SPF، DKIM، و DMARC.
موارد استفاده:
- جلوگیری از اسپم و جعل هویت ایمیل.
- تأیید سرویسهای خارجی.
6. NS Record (Name Server Record)
کاربرد:
این رکورد مشخص میکند که کدام سرورهای DNS مسئول مدیریت رکوردهای دامنه هستند.
مثال:
برای دامنه
example.com، رکورد NS ممکن است به ns1.example.com و ns2.example.com اشاره کند.موارد استفاده:
- تعیین سرورهای DNS اصلی یک دامنه.
- مدیریت و نگهداری رکوردهای دامنه.
7. SOA Record (Start of Authority)
کاربرد:
این رکورد اطلاعات پایهای درباره دامنه و سرور DNS اولیه ارائه میدهد. SOA رکورد شامل اطلاعاتی مانند آدرس ایمیل مدیر دامنه و زمان بهروزرسانی رکوردها است.
موارد استفاده:
- مشخص کردن سرور اصلی DNS.
- مدیریت بهروزرسانی رکوردهای DNS.
8. PTR Record (Pointer Record)
کاربرد:
این رکورد برای جستجوی معکوس DNS استفاده میشود (تبدیل آدرس IP به نام دامنه). برخلاف رکورد A که دامنه را به IP تبدیل میکند، PTR آدرس IP را به نام دامنه تبدیل میکند.
موارد استفاده:
- تأیید هویت سرورها.
- جلوگیری از ارسال ایمیلهای اسپم.
#DNS_records
@Syntax_fa
👍13💋6🔥4❤1👻1