یه مشکلی که خیلیا توی گرفتن کلید API برای اکانت تلگرام بهش می‌خورن اینه که تلگرام یه ERROR می‌ده و به هر IP نمی‌ده،
دقت کنید اصلا لازم نیست برای هر اکانت API_HASH و API_ID بگیرین، برای ساخت اپلیکیشن اینارو می‌گیرن مثلا فرض کنید می‌خواین یه تلگرام جدید بسازین و روش کلی اکانت باشه، بنابرین شما که می‌خواین فقط یه اکانت رو منیج کنید اصلا نیازی به گرفتنش نیست می‌تونین از API مثلا تلگرام دسکتاپ با کلید زیر استفاده کنین :

API ID : 2040
API HASH : b18441a1ff607e10a989891a5462e627

من خودم چند ساله دارم از این استفاده می‌کنم.

@Linuxor

راه جلوگیری از Brute Force به روش ساقی پارک :

اگه پسورد درست هم بود برای بار اول بگین اشتباهه، خود واقعیش باشه دوباره می‌زنه.


@Linuxor

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

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

#دیابت

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

زیاد میشنوم که میگن تست به دیباگ کردن کد کمک میکنه، اما این ممکنه یکم گمراه کننده باشه.

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

ولی خب، تو یه سری مدل تست ها مثل e2e و load test هم مجددا سناریو رو میدونیم، با اینحال ممکنه قسمتی از فلو (flow)، مطابق انتظار پیش نره، لود تست که کلا داستان خاص خودشو داره،
ولی تو e2e هم مجددا اگه ایراد پیش‌بینی نشده ای پیدا بشه، احتمالا در نقاط اتصال هست، و e2e هم تو پیدا کردن باگ لاجیکی غیرمنتظره، کمکی به ما نمیکنه.

<--×-->

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

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

<--×-->

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

غیر منطقی به نظر میاد،
اما منم بارها شاهدش بودم!
ولی مسئله اینجا تست نیست،
باید به خیلی قبل ترش نگاه کنیم،
همون جایی که نیازمندی بیزنس داره مشخص میشه.

<--×-->

از خوبی های جانبی تست هم میشه به "مثال بودن" اش اشاره کرد. با فرض دنیای ایده آل، خوندن تست های یه پروژه خیلی ساده تر از خوندن کد خود پروژست، و از رو تست هاش میشه به سادگی فهمید که چیکار میکنه و ورودی و خروجی مورد انتظار سیستم چی هست.
البته خب تو دنیای واقعی و غیر ایده آل، ممکنه یه دولوپر تازه کار مدعی سینیوریتی همین تست هارو فراپیچیده (over complex) کنه.

یه مزیت جانبی دیگه تست هم میتونه بحث تمیزی کد باشه، کدی که تمیز نباشه به راحتی قابل تست نیست، پس در واقع تست مارو مجبور میکنه که کد تمیز تری بنویسیم.

<--×-->

ولی خب در کل نظر شما راجع به تست چیه؟
مزایا؟ معایب؟ پیشنهاد؟ انتقاد؟ به من، به پست، به کانال و... 🙂🙌🏼

وقتی دارین سرچ بار درست می‌کنین یوزر هر کاراکتری وارد کرد فورا به سمت سرور انتقالش ندید Debounce هم در نظر بگیرین یه تایمی صبر کنید که شاید چیز دیگه ای هم تایپ کرد بعد ارسال کنید مثلا 300 میلی ثانیه درواقع با هر کاراکتر جدید اگه تایم درخواست قبلی فرا نرسیده بود اون درخواستو ابطالش کنید و به سرور ارسال نکنید

توی حالت عادی

/search?q=h
/search?q=he
/search?q=hel
/search?q=hell
/search?q=hello

پنج تا درخواست برای hello میره ولی نیازی نیست این همه درخواست بره. توی سرعت تایپ معمولی با دیبانس فقط

/search?q=hello

ارسال میشه و فشار روی سرور کم می‌شه.

@Linxuor

Animation vs. Coding

https://www.youtube.com/watch?v=EFmxPMdBqmU&t=11s

۱۰ برابر شدن سرعت TypeScript با پورت کامپایلر به GO

در این ویدئو Andres Hejlsberg (خالق تایپ‌اسکریپت و سی‌شارپ) توضیح می‌دهد که چگونه با پورت کردن کدهای کامپایلر TypeScript به GO، سرعت کامپایل را 10x بهتر کرده‌اند!

او همچنین توضیح می‌دهد که چرا زیرساخت JavaScript برای این کار مناسب نیست. در حقیقت این زبان بیشتر برای کارهای UI طراحی شده بوده و زیرساخت‌های لازم برای کارهای performance-intensive مانند این کار را ندارد.

برای من خیلی جالب بود خالق سی‌شارپ، زبان GO را برای این کار انتخاب کرده، پس مستندات مربوط به این تصمیم را خواندم.
https://github.com/microsoft/typenoscript-go/discussions/411

اولین نکته جالب این بود که چقدر بدون تعصب و با ذهن باز زبان‌های مختلف رو بررسی کردن.
با توجه به اینکه هر دو زبان‌ C#, GO از لحاظ پرفورمنسی بسیار خوب هستند، یکی از مهم‌ترین دلایل انتخاب GO تشابه بسیار بالای سینتکس آن با TypeScript بوده است.

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

از بین زبان‌های C#, GO و Rust، زبان گو تشابه سینتکسی بیشتری با تایپ‌اسکریپت داشته و در نهایت انتخاب شده.

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


https://www.youtube.com/watch?v=pNlq-EVld70

#مهران_داودی (لینکدین - بلاگ)

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

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

______