برنامه نویس حرفه‌ای به نظر من چهار تا بال داره که باید همیشه و حسابی مراقبشون باشه:

دانش و تجربه، تعامل و انتقال این سه تا

1. درباره‌ی شغل و حرفه‌ی خودتون باید دانش کسب کنید و مدام خودتون رو بروزرسانی کنید. گارد نداشته باشید در یادگیری چیزهای جدید تا از گفتن «نه، غیر ممکنه و نمیشه» به کارفرما اجتناب کنید.

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

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

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

#بالهای_شما
#برنامه_نویسی
#برنامه_نویس
#شغل
#مهارت_های_نرم
#مهارت_های_سخت
#تخصص

یه مشکلی که خیلیا توی گرفتن کلید 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