کدهالیک | codehalic

FOR YOUR INFORMATION : FYI

الگوریتم Shor یه الگوریتم کوانتومیه که برای شکستن رمزنگاری‌های مدرن (مثل RSA) طراحی شده.


این الگوریتم می‌تونه با استفاده از خاصیت‌های عجیب محاسبات کوانتومی، اعداد خیلی بزرگ رو به عوامل اولشون تجزیه کنه (factorization) خیلی سریع‌تر از کامپیوترهای معمولی.

اهمیتش اینه که امنیت خیلی از سیستم‌های رمزنگاری اینترنت (مثل بانک و پیام‌ها) به سخت بودن همین تجزیه وابسته‌ست.

@codehalics | کدهالیک

یه مسابقه ای چند روز پیش برگزار میشه به اسم QDay Prize

https://www.qdayprize.com/

برگزارکننده‌ها یه جایزه گذاشته بودن (حدود ۱ بیت‌کوین) برای کسی که با کامپیوتر کوانتومی بتونه با الگوریتم Shor یک مسئله رمزنگاری رو بهتر از بقیه حل کنه. هدفشون این بود که نشون بدن «حمله‌های کوانتومی به رمزنگاری واقعی شده».

ولی نویسنده (Craig Gidney) میگه کل این ایده از پایه مشکل داشته.

اولین مشکل اینه که کامپیوترهای کوانتومی فعلی خیلی پرخطا هستن. الگوریتم Shor برای اینکه واقعاً کار کنه به تصحیح خطا (error correction) نیاز داره، ولی تکنولوژی فعلی هنوز اونقدر پیشرفته نیست. پس هر چیزی که الان اجرا میشه، در واقع نماینده‌ی حمله واقعی به رمزنگاری نیست و فقط یه نسخه ناقصه.

مشکل دوم هم اینه که برای مسئله‌های کوچک، الگوریتم Shor حتی روی سیستم ضعیف یا حتی شانسی هم ممکنه جواب بده. یعنی ممکنه کسی فکر کنه «کامپیوتر کوانتومی موفق شده»، در حالی که در واقع نتیجه می‌تونه با شانس یا ترفندهای غیرواقعی هم به دست اومده باشه. همین باعث میشه قضاوت اینکه «واقعاً پیشرفت کوانتومی بوده یا نه» خیلی مبهم بشه.

در نهایت هم میگه اتفاقی که افتاده دقیقاً همون مشکل بوده: برنده مسابقه یه نتیجه گرفته که اگر به جای کامپیوتر کوانتومی از عدد تصادفی هم استفاده می‌کرد، تقریباً همون خروجی رو می‌داد. یعنی مسابقه به جای اینکه پیشرفت واقعی کوانتوم رو نشون بده، عملاً یه جور “توهم پیشرفت” تولید کرده.

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

https://algassert.com/post/2601

@codehalics | کدهالیک

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

@codehalics | کدهالیک

این مقاله میگه که یکی از ساده‌ترین ولی قوی‌ترین ابزارها برای جلو بردن پروژه‌های بزرگ، «جلسه‌های منظم تکرارشونده» هست.

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

راه‌حل پیشنهادیش اینه: یک جلسه ثابت (هفتگی، دو هفته یک‌بار یا ماهانه) بذارید و هر بار جلسه رو با مرور کارهای جلسه قبل شروع کنید. همین که آدم‌ها بدونن باید هفته بعد جواب بدن «اون کاری که قول داده بودی چی شد؟» باعث میشه واقعاً وقت براش بذارن. این فشار اجتماعی کوچیک، پروژه رو جلو می‌بره.

حتی میگه این روش تو کارهای مشاوره‌ای خیلی جواب میده، چون باعث میشه طرف مقابل هم مجبور بشه پیشرفت نشون بده، و یه جور «force کردن ملایم» ایجاد می‌کنه که کارها واقعاً انجام بشن.

https://www.mooreds.com/wordpress/archives/3734

@codehalics | کدهالیک

7 مگ آهنگ بود ولی صد گیگ خاطره توشه حسن بابا، نگهش دار.

@codehalics | کدهالیک

یه مقاله جدید خوندم که نویسنده تو مقاله به یه نکته جالب اشاره می‌کنه: طبق یه تحقیق، آدم‌ها تو سال ۲۰۰۸ روزانه حدود ۳۴ گیگابایت اطلاعات دریافت می‌کردن و این عدد هر سال حدود ۵.۴٪ رشد داشته؛ یعنی اگه ادامه‌ش بدیم، امروز به چیزی حدود ۸۰–۹۰ گیگابایت در روز رسیده! این حجم شامل همه‌چیزه؛ از ویدیو و صدا گرفته تا متن، و حتی کیفیت محتوا هم توش حساب میشه. خلاصه اینکه مغز ما عملاً زیر یه سیل دائمی از اطلاعاته.

بعد نویسنده می‌گه همین فشار باعث اون «brain fog» و افت تمرکز میشه، و برای مقابله باهاش یه راه ساده پیشنهاد می‌کنه: وقتی ذهنت قفل می‌کنه، چند دقیقه بشین و فقط به دیوار خیره شو، بدون فکر و بدون ورودی جدید. به نظرش این کار مثل یه ریست برای مغزه که کمک می‌کنه از این اورلود اطلاعاتی بیای بیرون و تمرکزت برگرده.

لینک اصلی مقاله :
https://www.alexselimov.com/posts/men_who_stare_at_walls/

@codehalics | کدهالیک

در رابطه با KISS امروز یه خبر جدید خوندم که تو یه این مقاله یه مهندس نرم افزار راجب اتفاقات درون تیمیش نوشته بود که خیلی بامزه بود و تهشم خیلی دراماتیک تموم میشه و یه طورایی داره راجب همین KISS صحبت میکنه خلاصه اش این بود که:

داستان درباره یه Engineering Managerـه که یه‌دفعه توی جلسه می‌فهمه یه تیم جدید به اسم CX بهش اضافه شده، بدون اینکه ازش نظر بخوان یا حتی خبرش کنن. هدف این تیم این بوده که تجربه مشتری رو بهتر کنه و زمان رسیدگی به تیکت‌ها رو کم کنه. مشکل اینجا بوده که شرکت قبلاً از مدل تیم‌های جدا بر اساس تکنولوژی (مثلاً بک‌اند، فرانت، موبایل) حرکت کرده بود به سمت تیم‌هایی که کل محصول رو end-to-end مالک هستن، ولی این تصمیم جدید دوباره یه جور برگشت به همون مدل قدیمی بود. از طرفی تیم CX هم به‌جای حل مشکل واقعی (وابستگی شدید به دولوپرها برای حل تیکت‌ها)، بیشتر روی ساختن یه داشبورد پیچیده تمرکز کرده بود که عملاً با نیاز بیزینس align نبود.

نویسنده تصمیم می‌گیره مسیر خودش رو بره: به‌جای منتظر موندن برای اون سیستم پیچیده، هر تیم یه داشبورد ساده داخلی بسازه که فقط کارهای ضروری CX رو راه بندازه، و تیم CX رو هم آموزش بدن که خودشون بتونن مشکلات رو حل کنن (self-service). تو اجرا کلی چالش پیش میاد مثلاً دولوپرهای بک‌اند با فرانت‌اند راحت نبودن یا CX اولش از ابزار استفاده نمی‌کرد ولی با ساده‌سازی (مثلاً استفاده از HTML ساده به‌جای React) و آموزش، کم‌کم جا می‌افته. در نهایت زمان حل تیکت‌ها از چند روز می‌رسه به چند ساعت و وابستگی به تیم‌های فنی خیلی کم می‌شه. در عین حال، تیم CX که جدا ساخته شده بود چون عملاً ارزشی ایجاد نکرد، بعد از چند ماه منحل می‌شه. نتیجه کلی اینه که اضافه کردن تیم جدید همیشه راه‌حل نیست و گاهی یه راه‌حل ساده و سریع که درست adopt بشه، خیلی مؤثرتره از یه سیستم ایده‌آل ولی بلااستفاده.

لینک اصلی مقالش اینه
https://learnings.aleixmorgadas.dev/p/adding-a-team-was-the-wrong-strategic

دوست داشتین یه نگاه بهش بندازین بنظرم تجربه خیلی خیلی خوبیو شیر کرده مخصوصا ساید سافت اسکیلی که چطوری با این تیم جدید تا کرده تا در نهایت تیم به این نتیجه رسیده که اقا ما CX نمیخوایم !

@codehalics | کدهالیک

شرکت فراز در حال جذب نیرو برای سه موقعیت شغلی زیر است:

🔹 Senior Frontend Engineer (React.js)
https://jobinja.ir/1470720
🔹 Senior Backend Engineer (Node.js)
https://jobinja.ir/1470431

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

🔹 Talent Acquisition - HR Generalist

اگر حداقل ۲ سال سابقه کاری در حوزه منابع انسانی، به‌ویژه در سطح سازمانی و در زمینه جذب و استخدام دارید، لطفاً رزومه خود را ارسال کنید.

📍 تهران، پونک | حضوری | شنبه تا چهارشنبه ۹–۱۸ (شناوری)

@codehalics | کدهالیک

فرصت همکاری: Front-End Developer
شرکت ایزد تک (izad Tech) جهت گسترش تیم فنی خود، به‌دنبال جذب یک توسعه‌دهنده فرانت‌اِند خلاق و مسئولیت‌پذیر است.

نیازمندی‌های کلیدی:
تخصص فنی: تسلط کامل بر Next.js ،TypeScript و Tailwind CSS.

مفاهیم مدرن: درک عمیق از استراتژی‌های رندرینگ (SSG ،SSR ،ISR) و مدیریت State (ترجیحاً Zustand).

ابزارها: تسلط بر Git و آشنایی با Docker و فرآیندهای CI/CD.

کیفیت کد: توانایی نوشتن کد تمیز (Clean Code) و پیاده‌سازی تست‌های خودکار.

مزایای همکاری:
فرهنگ سازمانی باز و شفاف.

تعادل میان کار و زندگی.

کار روی محصولات چالش‌برانگیز در یک تیم حرفه‌ای.

ارسال رزومه:
علاقه‌مندان می‌توانند رزومه خود را به آدرس ایمیل زیر ارسال نمایند:
📧 info@izadtech.ir

@codehalics | کدهالیک

موقعیت شغلی دلاری برنامه نویس پایتون
لوکیشن: ریموت
ساعات کاری منعطف
سطح زبان :c1 یا بالاتر
رنج حقوق: $4,000 – $2,000

About the Role
We are looking for a skilled Python Developer to join our growing team. In this role, you will design, develop, and maintain high-quality backend systems and applications.


2+ years of experience as a Python Developer or similar role

Strong proficiency in Python

Experience with frameworks like Django, FastAPI, or Flask

Solid understanding of REST APIs and backend development

Experience with databases (PostgreSQL, MySQL, or MongoDB)

Familiarity with Git and version control

Problem-solving mindset and attention to detail

ارسال رزومه :

https://forms.gle/dnNGjbzhdZHpPwku6

سورس آگهی :
لینکدین


@codehalics | کدهالیک

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

در این موقعیت، به دنبال یک Back-End Developer مسلط به C# / .NET هستیم. در این پروژه با موضوعاتی مثل طراحی و توسعه سرویس‌های Back-End، بهبود کارایی، دیباگ سیستم‌های عملیاتی، کار با دیتابیس، Message Broker، و آماده‌سازی سرویس‌ها برای محیط Production درگیر خواهید بود.

مهارت‌های اصلی مورد انتظار:

تسلط به C# و .NET / .NET Core
تجربه طراحی و توسعه RESTful API
تسلط قابل قبول به SQL Server و مفاهیم طراحی دیتابیس
آشنایی با معماری سرویس‌محور یا Microservices
آشنایی با Message Brokerهایی مثل RabbitMQ یا Kafka
آشنایی با Docker و مفاهیم Containerization
آشنایی با Git، CI/CD و فرآیندهای توسعه تیمی
توانایی تحلیل مسئله، دیباگ، مستندسازی و کار مسئولانه روی سیستم‌های Production

موارد زیر مزیت محسوب می‌شود:

تجربه کار با Kubernetes
تجربه در پروژه‌های Telecom ،FinTech یا سیستم‌های پرتراکنش
آشنایی با مفاهیم Observability، Logging، Monitoring و Performance Tuning
تجربه کار با معماری‌های مقیاس‌پذیر و سرویس‌های High-Load

محل کار: تهران، محدوده خیابان مطهری
نوع همکاری: تمام‌وقت
مزایا: ناهار سازمانی، بیمه تکمیلی، هدایای مناسبتی

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

لینکدینش

@codehalics | کدهالیک

دعوت به همکاری
موقعیت شغلی : متخصص DevOps
سطح حرفه ای : MID level ‌به بالا
نحوه همکاری : نیمه وقت، پاره وقت
نوع همکاری : حضوری، ریموت، هیبرید

محل کار: تهران - قیطریه
نحوه ارسال رزومه :

پیام در لینکدین، ارسال ایمیل به hosseini@techchi.ir

یا ارسال در بله به شماره 09018013690

@codehalics | کدهالیک

امروز یکی بهم پیام داد که استاد میخوام بیام برنامه نویسی یاد بگیرم از صفر روزی ۲ ساعت وقت بزارم
آقا نیایید ما خودمونم توش موندیم
بدون اینترنت مگ میشه کار کرد آخه؟
۶۰ روزه کک هیچ کسی نگزید که این اینترنت راه درآمدی ما بود :))))))))

@codehalics | کدهالیک

خب امروزم قراره بریم به ادامه ی بحث جذاب قوانین مهندسی نرم افزار و قانون هافستدر (Hofstadter)

second t is silent

تلفظ دقیق فارسی : هافس (ساکن) تَ دِ ر

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

این موضوع مستقیم به استیمیت دادن توی Jira ربط داره، چون معمولاً تسک‌ها رو کمتر از واقعیت برآورد می‌کنیم و حتی وقتی سعی می‌کنیم محافظه‌کار باشیم باز هم خطا داریم. به همین خاطر تیم‌ها معمولاً از داده‌های اسپرینت‌های قبلی (velocity) و یه مقدار بافر استفاده می‌کنن تا استیمیت‌ها واقعی‌تر بشه و برنامه‌ریزی قابل اتکاتری داشته باشن.

#lawsofsoftwareengineering

@codehalics | کدهالیک

امروز روی مهاجرت داکیومنت API از Swagger به Scalar کار کردم و همزمان مزیت‌های Scalar رو هم بررسی کردم. نسبت به Swagger، یو آی مدرن‌تر و خواناتری داره و در کل developer experience بهتری میده. همچنین performance بهتری روی APIهای بزرگ داره و کار باهاش روان‌تره.

اسکالار یه API playground پیشرفته با تست و لاگ real-time داره و SDKهایی که میده تمیزتر و type-safe ترن. از workflowهای مدرن مثل Git-native بودن و سازگاری بهتر با ابزارهای جدید (مثل AI tooling) هم پشتیبانی می‌کنه؛ یکی از جذاب‌ترین بخش‌هاش هم پشتیبانی نیتیو از MCP بود. از طرفی، نمایش داکیومنت برای end-user ساده‌تره، هر روت URL جدا داره برای share راحت‌تر، و چون از OpenAPI پشتیبانی می‌کنه، سوییچ بین Swagger و Scalar خیلی راحت انجام میشه.

#ابزار_مفید

https://scalar.com/

@codehalics | کدهالیک

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


https://tajrobe.github.io/

@codehalics | کدهالیک

Senior Software Engineer (php)

ارسال رزومه و مشاهده جاب دسکریپشن در :

https://career.hrcando.ir/co/takhfifan/job-detail/79dcdacb-51ca-4c2a-9190-9a50d7f7fd4b


@codehalics| کدهالیک

تیم TWO-X در حال گسترش است!
در روزهایی که خیلی‌ها مکث کرده‌اند، ما تصمیم گرفته‌ایم ادامه بدهیم. ما هنوز به آینده امیدواریم و باور داریم رشد، همکاری و ساختن، حتی در دل چالش‌ها هم متوقف نمی‌شود.
اگر به دنبال یک محیط حرفه‌ای، پویا و در حال رشد هستی، جای تو کنار ما خالیه.
ما به دنبال افراد باانگیزه و متخصص برای موقعیت‌های زیر هستیم:
🔹 Backend Chapter Lead
🔹 Frontend Developer
🔹 .NET Developer
🔹 Digital Marketing Specialist
🔹 UI/UX Designer
🔹 Senior Product Manager
اینجا فرصتی داری برای کار روی پروژه‌های جدی، یادگیری مداوم و ساختن چیزی که واقعاً اثرگذار است.
اگر فکر می‌کنی این موقعیت‌ها مناسب تو هست — یا کسی رو می‌شناسی که می‌تونه همراه خوبی برای این مسیر باشه — رزومه‌ات رو برامون ارسال کن:

📧 twoxoffice@gmail.com
یا این پست رو به اشتراک بذار.

@codehalics | کدهالیک

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

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

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

@codehalics | کدهالیک

امروز می‌خوام ادامه قوانین مهندسی نرم‌افزار رو ببرم سراغ یکی از خطرناک‌ترین باگ‌های ذهنی که حتی از باگ‌های کد هم بدتره؛ اثر Confirmation Bias یا سوگیری تأییدی. مغز ما دنبال حقیقت نیست، دنبال تأیید چیزیه که از قبل بهش باور داریم. وقتی یه فرض تو ذهنمون شکل می‌گیره (مثلاً مشکل از یه سرویسه)، فقط چیزهایی رو می‌بینیم که همونو تأیید کنه و بقیه نشونه‌ها رو نادیده می‌گیریم یا کم‌اهمیت می‌کنیم. همین باعث میشه تو دیباگ، طراحی سیستم یا تصمیم‌های معماری، مسیر اشتباه رو با اعتمادبه‌نفس بالا ادامه بدیم.

جالب اینجاست که هرچی مطمئن‌تر باشی “مشکل رو فهمیدی”، بیشتر تو این خطایی. چون ذهن دیگه دنبال رد فرضت نیست، فقط دنبال اثباتشه. برای همین آدم‌های باتجربه برعکس عمل می‌کنن؛ به جای اینکه بپرسن «چرا درسته؟» می‌پرسن «چرا ممکنه اشتباه باشه؟» و دنبال داده‌ای می‌گردن که فرضشون رو نقض کنه، نه تأیید. چون تو مهندسی نرم‌افزار، واقعیت به باور ما وفادار نیست، به چیزی وفاداره که واقعاً تو سیستم اتفاق می‌افته.

#lawsofsoftwareengineering
@codehalics | کدهالیک