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

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

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

🔹 Talent Acquisition - HR Generalist

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

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

@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 | کدهالیک

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

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

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

@codehalics | کدهالیک

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

@codehalics | کدهالیک

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

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

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

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

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

@codehalics | کدهالیک

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

@codehalics | کدهالیک

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

https://www.qdayprize.com/

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

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

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

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

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

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

https://algassert.com/post/2601

@codehalics | کدهالیک

FOR YOUR INFORMATION : FYI

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


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

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

@codehalics | کدهالیک

دن آبراموف، یکی از توسعه‌دهندگان اصلی React و خالق Redux، درباره تجربه‌ی خودش با Redux صحبت کرده و گفته اولین باری که مستنداتش رو دیده، حس کرده بیش از حد پیچیده و غیرضروریه. او حتی اشاره کرده که از سال ۲۰۱۸ به بعد دیگه از Redux استفاده نکرده. از نگاه او، این ابزار برای مدیریت state ساده، بیش از حد پیچیده طراحی شده، تغییر و توسعه‌اش سخت است و مقدار زیادی boilerplate (کد تکراری و اضافی) دارد. در نهایت هم روی یک اصل مهم در مهندسی تأکید می‌کند: اینکه نباید سیستم‌ها را بیش از حد پیچیده کرد و سادگی همیشه ارزشمندتر است.

رفرنس به KISS

@codehalics | کدهالیک

الان با وجود ابزارهایی مثل Zustand، MobX یا Recoil شاید بشه گفت Redux برای خیلی از سناریوهای ساده دیگه انتخاب ایده‌آلی نیست. ولی واقعیت اینه که Redux یکی از اولین و تاثیرگذارترین لایبرری‌هایی بود که مفهوم state management رو توی دنیای React جا انداخت.

مفاهیمی مثل action، reducer، dispatch و action type واقعاً از دید مهندسی نرم‌افزار جذاب و آموزنده بودن و باعث شدن خیلی‌ها عمیق‌تر با جریان داده توی اپلیکیشن‌ها آشنا بشن. شاید از یه جایی به بعد بیش از حد over-engineered شد، ولی در زمان خودش خیلی “خفن” به نظر می‌رسید.

از اون طرف، توی دنیای فرانت‌اند همیشه یه مرزی بین پیچیدگی و نیاز واقعی وجود داره. مثلاً Redux Saga با generatorها و مفهوم yield و yield.all برای خیلی‌ها (از جمله خودم) هیچ‌وقت طبیعی و قابل درک نبود، مخصوصاً وقتی در نهایت همون کار رو می‌شد با async/await ساده‌تر انجام داد. یا Redux Thunk که تازه بعداً اضافه شد، سوال ایجاد می‌کرد که چرا از اول این نیاز ساده دیده نشده بود.

در نهایت، Redux پر از ایده‌های قشنگ و معماری‌های جالب بود، ولی در خیلی از جاها پیچیدگی‌های غیرضروری هم به کد اضافه می‌کرد. با این حال، برای خیلی از ما یه تجربه آموزشی مهم بود. یادمه برای یاد گرفتنش چند بار کدها رو دستی از روی مثال‌ها می‌نوشتم تا بالاخره بفهمم reducer و dispatch دقیقاً چطور به هم وصل می‌شن چیزی که الان احتمالاً حتی سراغش هم نمی‌رم چون ابزارهای ساده‌تر و سریع‌تری وجود دارن.

با همه این‌ها، Redux بیشتر از اینکه فقط یک ابزار باشه، یه مرحله مهم توی یادگیری معماری فرانت‌اند بود.

@codehalics | کدهالیک

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

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

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

هر وقت یکی می‌گه «فریم‌ورک‌های JS یه روزی هایپ می‌شن و بعدش محو می‌شن»، من ناخودآگاه یاد Backbone.js می‌افتم. واقعاً دلم برای اون فریم‌ورک تنگ می‌شه؛ یه ابزار ساده، تمیز و به‌موقع که خیلی جلوتر از زمان خودش بود.

به نظرم یکی از under-rated ترین فریم‌ورک‌های تاریخ JS بود. اگه اون موقع بیشتر جدی گرفته می‌شد و کامیونیتی بزرگ‌تری پشتش شکل می‌گرفت، شاید امروز داستان خیلی فرق می‌کرد و حتی می‌تونست در حد React رقابت کنه. یه فریم‌ورک سبک و خوش‌ساخت که همه‌چی رو “اسموس” و مرتب جلو می‌برد.

الان اگه یه نگاه به پروژه‌هایی مثل delino.com بندازید، می‌تونید بفهمید Backbone چقدر می‌تونست قوی باشه؛ همه‌چی روان، منظم و بدون شلوغی اضافه پیش میره. البته بدون شک پشتش برنامه‌نویس‌های حرفه‌ای مثل حمیدرضا رحیمی بود ( خفن ترین کسی که جی اس به معنای واقعی میفهمید) ، ولی واقعیت اینه که Backbone اون چیزی بود که خیلی زودتر از زمان خودش اومد و شاید به اندازه‌ای که باید، دیده نشد.

در کل هنوزم وقتی اسمش میاد، یه حس “حیف شد” واقعی میاد سراغم.

@codehalics | کدهالیک

کارخونه نوآوری آزادی، سالن هفت وهشت از ساعت ۸ صبح تا ۱۰ شب یک سیت با اینترنت قابل اتصال به جهان میده ۳۸٥ تومن.
گفتم شاید به دردتون بخوره.

منبع

@codehalics | کدهالیک

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

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

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

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

https://raaznet.com/en/reports/filimo-streaming-privacy-audit

سورس خبر

@codehalics | کدهالیک

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

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


@codehalics | کدهالیک

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

قانون پرایس می‌گه در هر تیم، ریشه دوم افراد (√N) حدود ۵۰٪ خروجی رو تولید می‌کنن. یعنی همیشه یک گروه کوچک بیشترین اثر رو روی نتیجه داره و بقیه نقش‌های مکمل دارن.

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

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

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

#استخدام

دورکاری اما تمام‌وقت

استخدام سنیور UIUX دیزاینر

یکشنبه تا پنجشنبه از ساعت ۹ الی ۱۷.۳۰
حقوق به صورت ریالی پرداخت می‌شود.

قبل از ارسال رزومه شرایط حتما مطالعه شود.
سنیور بودن بیشتر از یک عنوان است:
۱. سنیور بودن را کیفیت و عمق پورتفولیو مشخص می‌کند، نه نام برندها.
۲. پورتفولیوهای سطحی یا با تعداد کم پروژه بررسی نمی‌شوند.
۳. تجربه کوتاه‌مدت (مثلاً حدود یک سال) برای این نقش کافی نیست.
۴. داشتن نمونه‌کار LTR با هر زبانی ضروری است.

برای ارسال پورتفولیو:

Tasharofi.behnaz@gmail.com

@codehalics | کدهالیک

📢 ما در شنوتو به دنبال یه هم‌تیمی جدید برای موقعیت برنامه‌نویس Backend (PHP) هستیم

اگر به توسعه محصول، کار تیمی و یادگیری تکنولوژی‌های جدید (به‌ویژه در حوزه AI) علاقه‌مندی، این موقعیت می‌تونه برات مناسب باشه 👇

🔹 کار با فریم‌ورک Laravel و توسعه بک‌اند پلتفرم وب و اپ
🔹 پیاده‌سازی و بهینه‌سازی قابلیت‌های مبتنی بر هوش مصنوعی (LLM، Speech-to-Text، Text-to-Speech و ...)
🔹 کار با تکنولوژی‌هایی مثل Redis، Elasticsearch، Docker و RabbitMQ
🔹 مشارکت در طراحی و بهبود فیچرهای محصول

🔹 همکاری به‌صورت تمام‌وقت و حضوری
📍 تهران، بالاتر از پارک ساعی (دسترسی از ولیعصر و گاندی)


لینک برای اپلای


@codehalics | کدهالیک

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

اینا که بدرد ما نمیخوره ما ۶۰ روز بیشتره که اینترنت نداریم چه برسه سی پنل بخوایم اپدیت کنیم :)))))

البته که همین الانم میشه این باگ هارو بیاری رو نت ملی و سرورای داخلی تست کنی کارشون یه سره کنی :))

@codehalics | کدهالیک

بازم ai تونسته یک حفره امنیتی روی لینوکس های ۲۰۱۷ به بعد پیدا کنه که بازم بدون sudo دسترسی روت بگیری روی سرور :)
کلا یه پایتون اسکریپت ۷۳۲ بایتی این کارو برات انجام میده و خیلی هم سر صدا کرده این داستان ولی توی کرنل پچ شده این باگ

copy.fail

@codehalics | کدهالیک