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

۱- قبل از مصاحبه حداقل چند روزی رو صرف مطالعه یه کتاب تو این زمینه بکنید و بد هم نیست چند تا مساله توی سایت‌هایی مثل Codeforces یا LeetCode یا HackerRank بکنید. برای کتاب هم من دو تا پیشنهاد دارم:
- کتاب Cracking the coding interview
https://www.crackingthecodinginterview.com/
- کتاب Algorithms Notes for Professionals
https://lnkd.in/dcC74Uxs

۲- حتما در طول مصاحبه سعی کنید بلند بلند فکر کنید و در مورد ابعاد مختلف مساله از مصاحبه‌کننده توضیح بخواید. این به شما کمک می‌کنه که هم فرصت بیشتری برای فکر کردن داشته باشید و هم مسیر رو درست برید. کلاً هر چی بیشتر در طول مصاحبه تعامل بکنید مثبت‌تره.

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

۴- معمولاً برای ارائه راه‌حل شما باید از یه زبان برنامه‌نویسی استفاده کنید و برخی مواقع مخصوصاً در مصاحبه‌های آنلاین ممکنه دسترسی به IDE نداشته باشید. بنابراین آماده این موضوع باشید. در زمان نوشتن سعی کنید کد رو تمیز و خوانا بنویسید چون معمولاً کیفیت کد روی نظر مصاحبه‌کننده تاثیر می‌ذاره.

پانوشت: پیرو کامنت بعضی از دوستان یه نکته اضافه کنم. ارزیابی توان حل مساله صرفاً بخشی از یه مصاحبه خوبه و نه تمامش و معمولاً سوالات خیلی سختی پرسیده نمیشه. برای یه نمونه سوال خوب، بد نیست ویدیو زیر رو ببینید که یه سوال ساده در مصاحبه شرکت گوگل هست:
https://www.youtube.com/watch?v=XKu_SEDAykw

Saeed Shahrivari Joghan

#note

@Syntax_fa

درک traceback پایتون

مطالعه

توضیح:
در برنامه نویسی مفهومی به اسم stack trace و یا stack backtrace مطرح است.
بصورت خیلی مختصر کاری که انجام می دهد این است مسیر اجرای کد شمارا از نقطه شروع اجرای کد تا زمانی که به اتمام برسد را در استک ذخیره میکند. برای مثال زمانی که با یک exception مواجه میشوید شما می توانید مسیری که برنامه از آن عبور کرده تا به exception خورده را مشاهده کنید که این کار با کمک stack trace انجام میشود.

در پایتون شما زمانی که با یک exception مواجه میشوید پیغامی به اسم traceback و متنی طولانی نمایش داده میشود.
در این مقاله به خوبی توضیح داده شده که چگونه در این شرایط عمل کنید.

#note

@Syntax_fa

Exit Code

وقتی شما یک دستوری رو اجرا می کنید، پس از اتمام در خروجی یک exit code هم دریافت می کنید. exit code یک پاسخ از سیستم شما است که نشان دهنده این است اجرای این برنامه موفقیت آمیز بوده، با ارور مواجه شده یا شرایط دیگری رخ داده.

اگه هنوز نمیدونی exit code چیه باید بگم موقع دیباگ کردن کدت میتونی ازش استفاده کنی. exit code عددی بین 0 تا 255 هستش، بیشترین exit code ها صفر، یک و دو هستن برای مثال:

کد صفر:
آخرین دستور و یا اسکریپت با موفقیت اجرا شد

کد یک:
کد یک را میتوان گفت نشان دهنده این است که شما یک عملیات غیر ممکن را میخواید انجام بدید. مثلا تقسیم کردن یک عدد به صفر.

کد دو:
کد دو برای زمانی استفاده میشه که دستور یا اسکریپت شما با permission denied یا نداشتن دسترسی مواجه میشه.

برای مطالعه بیشتر:
https://www.redhat.com/sysadmin/exit-codes-demystified#:~:text=An%20exit%20code%20is%20a,asks%20it%20to%20do%20so.

#note

@Syntax_fa

عملیات اتومیک در سخت افزار

تو این مقاله یه سری توضحات خوبی در خصوص اتومیک اپریشن داده

توضیح کوتاه:
اگه شما یک متغیری داشته باشید و قراره چندین پراسس همزمان روی این متغیر تغییری بوجود بیارن
برای مثال متغیر ما counter هستش و تمامی ترد ها میخوان counter++ کنند.

در این صورت ما میتونیم از mutex استفاده کنیم. اما بهتر از mutex استفاده از atomic operation هستش که performance بهتری داره زیرا از یک ویژگی در سی پی یو ما استفاده میکنه و میاد یک متغیر اتومیک درست میکنه که در لحظه فقط یک ترد میتونه بهش دسترسی داشته باشه و تغییراتی رو بده.

#note #atomic_operation

@Syntax_fa

لیست کلید واژه و شناسه ها در پایتون.

کدومش براتون کمترین استفاده رو داشته ؟

#Note

@Syntax_fa

پر استفاده ترین سمبل ها در زبان های برنامه نویسی.

#Note

@Syntax_fa

مفهوم اندازه و ظرفیت (Size, Capacity) در آرایه

یکی از پایه ای ترین ساختار داده آرایه ها هستند. در آرایه ها ما بصورت ترتیبی مقادیر را قرار می دهیم.

برای تعریف یک آرایه ما باید در قدم اول ظرفیت آرایه رو مشخص کنیم برای مثال ظرفیتش اگه 4 تا باشه فقط می تونیم 4 تا عنصر رو داخلش قرار بدیم.

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

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

در عکس کاملا مشخص است چگونه این اتفاق میوفتد.

#note #data_structures

@Syntax_fa

دوازده نکته مهم برای امنیت api هاتون که باید رعایت کنید

#Note

@Syntax_fa

Throughput و response time

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

1. Throughput (ظرفیت):
به میزان کلی از داده‌ها یا فرآیندهایی که یک سیستم می‌تواند در یک بازه زمانی خاص پردازش کند، اشاره دارد. به عبارت دیگر، throughput نشان‌دهنده تعداد واحدی از فعالیت (مثلاً تعداد درخواست‌های وب یا تعداد تراکنش‌های پایگاه داده) در یک بازه زمانی مشخص است.

مثال:
فرض کنید یک وب‌سایت دارید و می‌خواهید throughput آن را اندازه‌گیری کنید. اگر در یک دقیقه 60 درخواست وب به سرور شما برسد و همه آن‌ها با موفقیت پردازش شوند، throughput وب‌سایت شما برابر با 60 درخواست در دقیقه است.

2. Response Time (زمان پاسخ):
Response time
یا زمان پاسخ، مدت زمانی است که از زمان ارسال درخواست تا زمان دریافت پاسخ می‌گذرد. این مفهوم نشان‌دهنده واکنش سیستم به یک فرآیند یا درخواست خاص است و معمولاً در واحد زمانی مانند میلی‌ثانیه اندازه‌گیری می‌شود.

مثال:
اگر شما یک درخواست HTTP به یک سرور وب ارسال کنید و زمانی که می‌گذرد تا پاسخ از سمت سرور دریافت شود، به عنوان زمان پاسخ شناخته می‌شود. به عنوان مثال، اگر زمان پاسخ یک درخواست وب 200 میلی‌ثانیه باشد، این به معنای آن است که سرور توانسته است درخواست شما را در 200 میلی‌ثانیه پردازش و پاسخ دهد.

به طور کلی، معمولاً تلاش می‌شود تا تعادلی بین throughput و response time برقرار شود تا سیستم به طور کارآمد واکنش دهد و همزمان تعداد زیادی درخواست را پردازش کند و به کاربران پاسخ سریعی ارائه دهد.

#Note

@Syntax_fa

ساختار یک HTTP Request

#Note #HTTP

@Syntax_fa

سوال هایی که سطح دانش شما رو مشخص می کنه!

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

چیه؟
سوال سطحی که از یک جونیور توقع میره باهاش زیاد سر و کله بزنه این نوع سوال ها هستش.
برای مثال:
فریم ورک چیه؟
داکر چیه؟
رشته چیه؟
فرق بین همروندی و موازی سازی چیه؟

این نوع سوالات شمارو با مفاهیم برنامه نویسی بصورت سطحی آشنا میکنه

اما یه سطح بالاتر سوال هایی هست که درباره چیستی اون ابزار و مفهومه
برای مثال:
چرا از داکر استفاده میکنیم؟
چرا از لاگر ها استفاده میکنیم؟
چرا از میدلور استفاده میکنیم؟
چرا همروندی نیازه؟

در نهایت سوال هایی که پاسخ دادن بهشون، به شما درک عمیقی میدن، سوال هایی هستش که درباره چگونگی کار کردن اون ابزار پرسیده میشه.
برای مثال:
کانتینر چجوری کار میکنه؟
چجوری یک تایپ دیتا از نوع رشته توی حافظه ذخیره میشه؟
فرق بین hypervisor و روش container چی هستش؟
همروندی چجوری باعث پرفورمنس بهتر تو شرایطی که IO داریم میشه؟

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

#Note

@Syntax_fa

اگر این روزها PDF مقاله(انگلیسی) میخونید، از مرورگر Microsoft Edge استفاده کنید، چرا؟ در ادامه به ۴ مورد اشاره می‌کنم:

۱- میتونید قسمت‌های مختلف متن رو با چندین رنگ ‌های‌لایت کنید ولی حتما بعدش Ctrl+S رو بزنید که ذخیره بشه.

۲- برای متن‌ها میتونید کامنت بزارید.

۳- مترجم هم داره، هرقسمت از متن رو انتخاب کنید،‌ براتون به هر زبانی ترجمه میکنه.

۴- و درنهایت یک فیچر جذاب، امکان استفاده از هوش‌مصنوعی Copilot در کنار مقاله. به این صورت که به مقاله دسترسی داره، میتونید هر قسمتی که متوجه نشدید رو ازش بپرسید و بگید براتون بیشتر توضیح بده یا....

امیدوارم براتون مفید باشه.

[amir motaheri]

#Note

@Syntax_fa

یکی از دوستام چند مدت نبود. دیشب این پیامو فرستاده:

اقا شرمنده من ی مدتی نبودم برای یکی پروژه انجام داده بودم پول دزدی واریز کرده بود بازداشت بودم

دقیقا من ۱۰ روز اگاهی بودم از تهران بازداشتم کردن فرستادن کرج الانم با سند بیرونم میخواستن بفرستنم زندان !

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

قاضی هم که اصلا هیچ دانشی از این حوزه ها نداره

خلاصه سرتونو درد نیارم خیلی اذیت شدم الان ۶ روزه اومدم ولی ی بارم دست به لپ تاپ نزدم اصلا از همچی بدم اومده

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

#Note

@Syntax_fa

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

مثلا این آدرس جیمیل ها:
[email protected]
[email protected]
[email protected]
[email protected]
And ...

همشون به یک جیمیل اشاره می کنن و اگه به هرکدومشون ایمیل کنیم به آدرس یکسان box اشاره دارن.

چه استفاده ای میشه و نکته مهم چیه؟
با این ویژگی من میتونم با یک جیمیل چندین بار تو یک سایت ثبت نام کنم.
اگه تو وب سایتمون جیمیلی رو بلاک کنیم میتونه به یه شکل دیگه جیمیلش رو بنویسه و بازم ازش استفاده کنه.

مقاله:
https://generator.email/blog/gmail-generator

@WikiWebb

#note

@Syntax_fa

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

✅ 10 توصیه مهم هم از من بشنوید برای اینکه ارتباط بهتری با کارفرما بگیرید و در نهایت حال خوب شما و اون بیشتر باشه:

1. اول از همه، وقت بذارید تا بفهمید کارفرما دقیقاً چی از شما میخواد. این یعنی سؤالات دقیق بپرسید و با تمام وجود گوش کنید، فعالانه گوش کنید!

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

3. سعی کنید از اصطلاحات فنی زیاد استفاده نکنید. بیشتر سعی کنید با زبان ساده حرف بزنید تا همه بتوانند منظور شما را به راحتی درک کنند. من همیشه گفتم که هر چی فنی تر صحبت کنی کارفرما رو بیشتر می ترسونی!

4. روی این تمرکز کنید که چطور راهحلهاتون میتونند به کارفرما کمک کنند تا به اهدافش برسه. در نهایت باید درد اون برطرف شه.

5. به کارفرما گزینههای مختلفی ارائه بدید و برای هر کدوم مزایا و معایب رو شرح بدهید تا بتونه یک تصمیم آگاهانه بگیره. می خواید کاریزماتیک تر باشی، نظر قاطعانه خودتون در مورد گزینه ای که برای کارفرما بهتر هست رو هم مطرح کنید.

6. توی جلسات به موقع حاضر بشید، ارائههاتون رو منظم و حرفهای انجام بدهید و باز اینجا مراقب باشید فنی گویی بیش از حد نداشته باشید!

7. از کارفرما بخواید تا در طول فرایند، نظراتش رو با شما به اشتراک بذاره. این طوری اونها حس میکنن که واقعاً بهشون اهمیت میدید.

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

9. صبور باشید و برای پاسخگویی به سؤالات، همیشه آماده باشید.

10. و در آخر اینکه، نشون بدید که شما به دنبال یادگیری و بهبود مداوم هستید تا بتونید بهترین خدمات رو به کارفرما ارائه بدید.

link

#note

@Syntax_fa

به دنبال ساختار باشید و نه چارچوب

چند روز پیش یه مربی کودک یه حرف خیلی مهمی زد با این مفهوم: «ما اینجا برای بچه ها ساختار تعیین می کنیم نه چارچوب، چارچوب یعنی حد و مرز!»
این جمله رو باید قاب کرد و زد رو دیوار، احتمالا در ابعاد خیلی زیادی از زندگی مهم باشه. در مهندسی نرم افزار و توسعه محصول هم خیلی حرف مهمیه.
بیشتر اوقات ما دنبال چارچوب هستیم در مهندسی نرم افزار، به همین دلیل وقتی خودمون رو به یه چارچوب خاص محدود می کنیم با چالش های زیادی روبرو میشیم. در حالیکه بهتره ما برای توسعه محصول ساختار داشته باشیم و طبق اصول ساختاری کار رو پیش ببریم، اینطوری چالش مون کمتر میشه.
اجازه بدید برداشت خودم از چارچوب و ساختار رو کمی بیشتر باز کنم. ساختار میشه مجموعه از قواعد رفتاری که باید سعی کنیم در توسعه محصول بهشون پایبند باشیم، در مقابل، چارچوب میشه تعیین کردن یه سری حد و مرز مشخص به شیوه ای سختگیرانه.
مثلا اگه بخوام برای توسعه یک سرویس ساختار تعیین کنم احتمالا میگم: این سرویس باید توان پاسخگویی بالایی داشته باشه، در مقابل خطا مقاوم باشه، قابلیت مقیاس پذیری داشته باشه، یک قرارداد ساده و شفاف به کلاینت ها ارائه بده و مواردی از این دست.
اما اگه بخوام چارچوب برای سرویس تعیین کنم احتمالا میگم: ما باید از ساختار کد مبتنی بر clean code یا ddd در فلان repository که خودمون یا دیگران اونو نوشتن پیروی کنیم، باید همه ورودی هارو تو پوشه port قرار بدیم، باید همه مدل هامون تو پوشه models باشه، باید از فلان روش ci/cd استفاده کنیم.

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

خیلی از practiceهایی که معروف شدند مثل clean code و ddd و tdd و غیره هم از نظر من بیشتر به دنبال این هستند که به شما کمک کنند که برای کارتون ساختار تعیین کنید. در حالیکه اشتباهی که زیاد رخ میده اینه که ما با خوندن این مطالب احتمالا بیشتر به سمت درآوردن چارچوب میریم... همه ش به دنبال این هستیم که مثلا یه boilerplate داشته باشیم که از clean code پیروی کنه و همون رو همه جا استفاده کنیم.

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

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

@gocasts

#Note

@Syntax_fa

نکته:
میدونستید جنگو translation بر اساس زبان دیفالت مروگر کاربر، زبانی که باید نشون بده رو انتخاب می کنه؟

اگه زبان دیفالت مرورگرش توی لیست زبان های برناممون نبود میره سراغ دومین زبانی که تو مرورگرش ست کرده

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

#Note #Django

@Syntax_fa

تحلیل BSOD پتچ امنیتی CrowdStrike

مشکل اصلی که در نرم‌افزار CrowdStrike رخ داد، به دلیل دسترسی نادرست به حافظه از طریق یک اشاره‌گر تهی (NULL pointer) در زبان برنامه‌نویسی C++ بود. حافظه در کامپیوتر به صورت یک آرایه بزرگ از اعداد سازماندهی شده است. اگر برنامه‌ای تلاش کند به یک آدرس حافظه نامعتبر دسترسی پیدا کند، سیستم‌عامل بلافاصله برنامه را متوقف می‌کند و این موضوع منجر به خرابی سیستم می‌شود.

در این حالت خاص، برنامه سعی کرد به آدرس حافظه 0x9c (که معادل 156 در مبنای 10 است) دسترسی پیدا کند. این آدرس حافظه نامعتبر است و دسترسی به آن باعث می‌شود که سیستم‌عامل برنامه را متوقف کند. این مسئله به دلیل عدم بررسی اشاره‌گر تهی توسط برنامه‌نویس اتفاق افتاد.

برای مثال:

struct Obj {
    int a;
    int b;
};

Obj* obj = NULL;

print(obj->a);

در این مثال، اشاره‌گر obj تهی (NULL) است. هنگامی که برنامه سعی می‌کند به عضو a از شیء obj دسترسی پیدا کند، به دلیل تهی بودن اشاره‌گر، به یک آدرس نامعتبر دسترسی پیدا می‌کند و باعث خرابی برنامه می‌شود.

این مشکل به‌خصوص خطرناک بود زیرا در یک درایور سیستمی رخ داد. درایورهای سیستمی دسترسی‌های سطح بالایی به منابع سیستم دارند و خرابی در این درایورها می‌تواند منجر به توقف کل سیستم‌عامل و نمایش صفحه آبی مرگ (BSOD) شود.

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

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

Source:
@GoInsights

#note

@Syntax_fa | boost