اگه Wi-Fi سیستمتون اینتله و حس میکنید کنده با این تریک ممکنه مشکلتون حل بشه

برای این کار به فایل زیر برید
/etc/modprobe.d/iwlwifi.conf
و این خط رو اضافه کنید
options iwlwifi 11n_disable=8
این خط با غیرفعال کردن برخی از ویژگی‌های استاندارد 802.11n، می‌تونه به بهبود عملکرد در برخی شرایط خاص کمک کنه. به صورت کلی میاد فاصله زمانی بین فریم هارو کم میکنه و چند فریم رو میتونه ترکیب کنه با هم دیگه. همچنین تداخل با دستگاه های وایفای دیگه هم کم میشه.

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

امنیت در استفاده از <iframe> و window.open

اگر به دنیای امنیت وب و تست نفوذ علاقه‌مند هستید، حتماً با ابزارهایی مثل تگ <iframe> و متد window.open مواجه شده‌اید. این دو ابزار اگر به‌درستی مدیریت نشوند، می‌توانند به دریچه‌ای برای حملات XSS خطرناک تبدیل شوند. در این پست، به بررسی این دو و تهدیداتی که ممکن است ایجاد کنند، می‌پردازیم.

تگ  <iframe>

تگ <iframe> به توسعه‌دهندگان اجازه می‌دهد تا محتوای یک صفحه وب دیگر را درون صفحه‌ی اصلی خود نمایش دهند. این قابلیت به ظاهر بی‌خطر است اما می‌تواند به یک نقطه ضعف امنیتی تبدیل شود. مهاجمان می‌توانند از این تگ برای جاسازی محتوای مخرب در سایت‌های معتبر استفاده کنند.

مثال حمله XSS با iframe:
فرض کنید یک سایت به‌درستی ورودی‌های کاربران را فیلتر نمی‌کند و یک مهاجم موفق می‌شود کد زیر را در سایت تزریق کند:

<iframe src="https://attacker.com/steal_data"></iframe>

این iframe می‌تواند به صفحه‌ای هدایت شود که حاوی کدهای مخرب است. چنین کدهایی ممکن است برای سرقت کوکی‌ها یا اجرای عملیات ناخواسته روی حساب کاربری شما به کار رود.

متد window.open

متد window.open در جاوااسکریپت برای باز کردن یک پنجره یا تب جدید در مرورگر استفاده می‌شود. اگر این متد به‌درستی کنترل نشود، مهاجمان می‌توانند کاربران را به صفحات فیشینگ یا سایت‌های آلوده هدایت کنند.

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

window.open('https://attacker.com/phishing_page', '_blank');

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

روش‌های پیشگیری

برای جلوگیری از سوءاستفاده از <iframe> و window.open، این نکات را در نظر بگیرید:

1. استفاده از Content Security Policy (CSP): با تنظیم یک CSP مناسب، می‌توانید بارگذاری منابع از دامنه‌های غیرمجاز را محدود کنید.

2. محدود کردن iframe با sandbox: استفاده از ویژگی sandbox در iframe، از اجرای کدهای مخرب و ارسال فرم‌های ناخواسته جلوگیری می‌کند.

  
   <iframe src="https://example.com" sandbox="allow-scripts"></iframe>
  

3. کنترل دقیق ورودی‌ها: همیشه ورودی‌های کاربران را فیلتر کنید تا از حملات XSS جلوگیری شود.

4. بررسی URL‌ها در window.open: قبل از هدایت کاربران به یک صفحه جدید، URL را به دقت بررسی کنید.
---
به امید موفقیت در مسیر حرفه‌ای شدن در حوزه امنیت وب!

#جاوااسکریپت #تست_نفوذ #امنیت #برنامه‌نویسی #وب_اپلیکیشن

خطا داریم؟ همینه که هست!

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

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

در یک برنامه معمولی جوابِ (احتمالا) درست به خیلی از این سوالا اینه که خب کارکرد برنامه رو متوقف کن و بگو نمیتونم. برنامه کار نکنه تا دوباره با برطرف شدن مشکلات یکی از اول اجراش کنه،
ولی اگر برنامه ما قراره توی یکسری از محیط‌ها اجرا بشه دیگه خبری از «من کار نمیکنم تا شرایط درست بشه» نیست. چه محیط‌هایی؟ محیط‌هایی که availability بالا مهمه مثلا سیستم های امبدد یا بک‌اند.
مثلا قراره ما مسیریابی یک هواپیما رو انجام بدیم و سیگنال GPS دریافت نمی‌کنیم، خب به هواپیما بگیم فعلا من کار نمیکنم؟! یعنی چی که کار نمیکنم، با سرعت زیاد داره میره :)))
یا مثلاً توی کلود اگر ارور بدیم و برنامه کرش کنه کنیم چی میشه؟ کوبرنتیز دوباره برنامه رو اجرا می‌کنه و دوباره با مشکل درگیریم!

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

مثلا چه مشکلاتی؟
مثلاً اگه قراره کانفیگ فایل رو از بیرون لود کنیم, آمادگی نبودنش رو هم داشته باشیم، مثلا یه کانفیگ پیشفرض داشته باشیم (البته کانفیگ چون موقع اولین اجرای برنامه خودش رو نشون میده شاید نیازی هم نباشه)
مثلا اگر داده gps به ما نرسید، با کمک داده های قبلی که ذخیره کردیم و یا ترکیبش با سرعت و شتاب و ... مشکل رو موقتا و حتی نادقیق حل کنیم
یا مثلاً اگر به سرور خارجی درخواست می‌زنیم و نیست، آمادگی نبودنش رو داشته باشیم، اینجا یکسری پترن که تو صنعت استفاده میشه داریم
مثلا چه پترنهایی؟
+ دوباره درخواست بده: retry pattern
+ به یکی دیگه درخواست بده: fallback
+ اگر خرابه تا یه مدت بهش درخواست نده تا ارور الکی نگیری: circuit breaker
+ اگه سرور خارجی کنده، خیلی صبر نکن تا response time خودت هم بالا نره
+ اگر سرور خارجی دیتا قراره بهت بده، دیتای قبلی رو کش کن.

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

منابع:
https://opensource.com/article/19/9/transient-faults-devops

https://www.jrebel.com/blog/microservices-resilience-patterns

https://learn.microsoft.com/en-us/azure/architecture/best-practices/transient-faults

https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/application-resiliency-patterns

حق:
من این مشکل رو زیاد دیدم؛ بیش از حداقل 20% پروژه‌های خدماتی که دوستان روش کار می‌کنن. می‌بینم که Postgresql به معنای واقعی کلمه OverKill هست. مخصوصا وقتی Sqlite کار رو در میاره.

شاید به روی خودتون نیارید ولی خیلی از شما هم ازین پروژه‌ها دیدید دیگه.

خواستم هم اهمیت SQLite رو یادآوری کنم
هم بگم پروژه‌هایی مثل rqlite هم وجود داره‌ها

مثال:
کاری به درست و غلط بودن دیزاین و ... ندارم و بحثم فقط همین مورد Sqlite هست.
یک کدی رو دیدم؛ طرف یک سیستم verification جدا براش طراحی کرده بود و تمام پروژه‌هاشون ازین سرویس استفاده می‌کرد. فکر کنم این سرویس یا .net بود یا golang بعد بحث اصلی سر این بود که Postgres بذارند یا MsSql من درجا پیشنهاد SQlite رو دادم.
این دیتابیس خیلی اهمیت زیادی نداره؛ هر کد قراره نهایتا ۱۰ دقیقه valid باشه. در صورت پاک شدن هم طرف یکبار دیگه درخواست میده (که من تاحالا پاک شدن خود به خود توش ندیدم).

چرا می‌خواید شر درست کنید برای تیم devops, server, database, ...
خیلی ها مشکلشون این هست که اطلاعات ندارند (هیچ‌وقت هم جرات تجربه کردن نداشتند)؛ خود SQLite روی SSD طبق بنچمارک‌ها.
بیش از 500 هزار insert در ثانیه رو پشتیبانی می‌کنه و برای read هم این مورد به بیش از 1 میلیون میرسه و این مورد بدون config های پرفورمنسی هست که توی داکیومنت خودش ارائه شده.
روی NVMe هم چندسال قبل تست کردیم؛ اعداد بهتر هم میشه.

اضافه کنم :
اینم rqlite اگر حتی خواستید SQlite رو بصورت distributed داشته باشید (قبلا توی اون کی کانال راجبش صحبت کردم با   K8s )

Source

Liger (Linkedin GPU Efficient Runtime) Kernel

لینکدین یک لایبرری بنام Liger Kernel معرفی کرده که به طرز قابل توجهی باعث افزایش سرعت و کاهش مصرف RAM در آموزش LLM میشه. آمار و ارقام نشون میده که شما با این لایبرری می‌تونید 20% افزایش سرعت و 60% کاهش مصرف RAM رو تجربه کنید! 🤯

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

import transformers
from liger_kernel.transformers import apply_liger_kernel_to_llama

model = transformers.AutoModelForCausalLM.from_pretrained("<some llama model>")

# Adding this line automatically monkey-patches the model with the optimized Liger kernels
apply_liger_kernel_to_llama()

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

لینک گیتهاب

تحلیل 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 که از دسترسی‌های نادرست به حافظه جلوگیری می‌کنند، می‌تواند به کاهش این خطرات کمک کند.

➖➖➖➖➖➖➖➖

🔶 متاسفانه زیر ساخت شبکه TON تلگرام بسیار ضعیف اجرا شد و آنها انتظار نداشتند چنین حجم سنگینی از تراکنش های روی شبکه TON انجام شود. گزارشی رسیده که حجم تراکنش از روزانه 2.5 ملیون تراکنش به 9.5 ملیون تراکنش رسیده است و بسیاری از تراکنش ها انجام نمی شود و برخی از صرافی ها مثل بایننس مجبور شدند که برداشت از شبکه TON ببندد. بهرحال این اتفاق به ایردارپ داگز بر می گردد که نتوانست به ۴۰ میلیون کاربر خود توکن های داگز از طریق شبکه TON به حساب آنها انتقال دهد.

باید دید شبکه TON چه برنامه ای برای ارتقای زیرساخت خود در کوتاه مدت دارد.


@TheRaymondDev

#regreSSHion #OpenSSH #CVE-2024-6387
اخیرا برنامه OpenSSH که استفاده گسترده ای در پروتکل SSH دارد، دارای یک آسیب پذیری شرایط رقابتی یا Race Condition شده است.

این آسیب پذیری از نسخه 8.5p1 => 9.8p1 که در برابر signal handler آسیب پذیری Race Condition رخ خواهد داد، که به زبان ساده میشود اینکه در یک بازه زمانی مشخص، چندین Thread موازی تلاش میکنند در یک منطقه حافظه برخی فرایند خواندن و برخی فرایند نوشتن را انجام دهند.

اینجا تقدم و تأخر لحظه استفاده و لحظه چک بهم خواهد خورد و آسیب پذیری این امکان رو خواهد داد که شما از 200 درخواست یا Request ارسالی چند مورد رو به اشتباه مجوز تایید بگیرید.

خب حالا نحوه رخداد آسیب پذیری چطور بوده؟ این آسیب پذیری بر روی سیستم عامل های لینوکسی که از کتابخونه glibc بهره میگیرند، قابل بهره برداری است.

چرا که تابع syslog خود تابع async-signal-unsafe را فراخوانی میکند که این تابع از malloc و free برای تخصیص حافظه استفاده میکند که در منطقه سیستم است لذا سطح دسترسی نیز root خواهد بود، همچنین در تابع main_sigchld_handler شرط آسیب قرار دارد.

فصل اول
2- بلاکچین چگونه کار می‌کند؟

بلاکچین را مجموعه‌ای از بلاک‌ها تصور کنید که به صورت زنجیره‌وار به یکدیگر متصل‌اند.

1- ساختار هر بلاک
هر بلاک در زنجیره شامل 3 بخش اصلی است:

1.1- داده (Data): این بخش شامل اطلاعاتی است که بلاک ذخیره می‌کند. برای نمونه، در بلاکچین بیتکوین داده‌ها شامل جزئیات هر تراکنش است مانند فرستنده، گیرنده و مقدار بیتکوین انتقال داده شده.

1.2- هش بلاک (Block Hash): هر بلاک دارای یک کد منحصر به فرد به نام هش است که با استفاده از الگوریتم‌های رمزنگاری تولید می‌شود. هش یک بلاک مانند اثر انگشت آن بلاک است و کوچکترین تغییری در جزئیات داده‌های بلاک، هش آن را به کلی تغییر می‌دهد.
الگوریتم‌های هشینگ توابع ریاضی یک‌طرفه‌ای هستند که ورودی آن هر چیزی می‌تواند باشد اما خروجی آن یک مقدار منحصر به فرد با اندازه ثابت است. یک‌طرفه بودن این توابع به این معناست که با داشتن خروجی نمی‌توان به داده ورودی آن دست پیدا کرد.

1.3- هش بلاک قبلی (Previous Block Hash): هر بلاک حاوی هش بلاک قبلی است که به آن متصل است. این ویژگی باعث ایجاد زنجیره‌ای از بلاک‌ها می‌شود و امنیت و تغییرناپذیری بلاکچین را تضمین می‌کند.

2- فرایند افزودن بلاک به زنجیره
برای افزودن بلاک جدید به زنجیره، مراحل زیر انجام می‌شود:


2.1- تایید تراکنش‌ها (Transaction Verification): ابتدا تراکنش‌های جدید توسط نودهای شبکه تایید می‌شوند. این تایید شامل بررسی صحت امضاهای دیجیتال و اطمینان از عدم تکراری بودن تراکنش‌ها است.

2.2- حل مسئله ریاضی (Proof of Work): برای اضافه کردن بلاک جدید به زنجیره، نودها باید یک مسئله ریاضی پیچیده را حل کنند که به آن اثبات کار می‌گویند. این فرآیند نیازمند قدرت محاسباتی زیادی است و زمان و انرژی زیادی مصرف می‌کند.

2.3- اضافه شدن به زنجیره (Block Addition): پس از حل مسئله و تایید صحت بلاک جدید توسط سایر نودهای شبکه، بلاک به زنجیره اضافه می‌شود.

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

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

بیشتر بخوانید:
الگوریتم های هشینگ Hashing algorithms
هش بلاک Block Hash
نود Node

#blockchain
@code_crafters

دوره آنلاین "معاملات الگوریتمی براساس یادگیری ماشین"
Machine Learning-based Algorithmic Trading

زمان:
از 15 شهریور تا 20 مهر
پنجشنبه‌ها: 16:30 تا 19
جمعه‌ها: 17:30 تا 20
طول دوره:
30 ساعت
امکان برگزاری جلسات تکمیلی و رفع اشکال بدون هزینه اضافی وجود دارد. این امکان به دلیل گستردگی مباحث و ذات بین رشته‌ای دوره ایجاد شده است.
✅ مشاهده سرفصل‌ها و ثبت‌نام: Link

ظرفیت کل به دلیل کیفیت و نیاز به تعامل محدود است.

🔴 ظرفیت بلیط‌هایِ زودهنگام به پایان رسید
🔵 تعدادی بلیط معمولی باقی مانده است

Event storming

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

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

در دنیای DDD ما نیاز به رویکردی جدید و مدرنتر داشتیم که بتوان موارد زیر رو رفع کرد:
۱- فضای مسئله و راه حل‌ها
۲- شناخت و یافتن BC یا همان مرزهای محدود
۳ـ جلسات منفعل با BR یا همان متخصصان کسب و کار
۴- فرار از مدلسازی‌های نامناسب
۵- تهیه کردن لیست نیازمندی ها
۶- دست یافتن سریع به یک زبان مشترک


همیشه دیدگاه اشتباهی راجب DDD وجود دارد اینکه این رویکرد فقط برای سیستم‌هایی جوابگو هستش که در ابتدای راه و ساختن قراردارد اما این یک اشتباه هست اتفاقا این رویکرد برای سیستم‌های قهوه‌ای (امیدوارم منظور نویسنده از قهوه‌ای را گرفته باشید) بهتر پاسخ میدهد

در سال ۲۰۱۳ یک روش خلاقانه با عنوان event storming معرفی شد که پایان هرآنچه که در بالاتر مطرح کردیم رو ختم کرد

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


با توجه به اینکه مطالب مربوط به event storming زیاد و گوناگون است لذا این بخش از کتاب رو بهتر هستش خودتون با سرچ کردن و خوندن مقالات متنوع یاد بگیرید

#DDD
#domain_driven_design

@code_crafters

تحلیل دیتاست‌های جدولی (Tabular) هم در ریسرچ و هم در کاربردهای واقعی خیلی مورد توجه هست. مقایسه‌هایی که تا الان انجام شده، نشون میده عملکرد مدل‌های دیپ اغلب پایین‌تر یا هم‌سطح مدل‌های بوستینگ گرادیان (GBMs) هست.

می‌خوام درباره مقاله‌ای صحبت کنم که مقایسه عمیقی روی مدل‌های آنسامبل مبتنی بر درخت تصمیم (TE)، دیپ (DL) و مدل‌های کلاسیک ML انجام داده. عنوان مقاله:
A Comprehensive Benchmark of Machine and Deep Learning Across Diverse Tabular Datasets link

حدود 111 دیتاست جدولی و 20 مدل مختلف برای مقایسه انتخاب شده. مقایسه‌های متنوعی انجام شده؛ مقایسه عملکرد مدل‌های DL و TE رو در تصویر بالا آوردم. نتایج جالبی بدست اومده:
* مدل CatBoost در 19 مورد از 111 دیتاست بهترین بوده.
* رتبه Random Forest قابل توجه هست.
* مدل XGBoost که خیلی‌ها انتخاب اولشون هست، در رتبه 10 دیده میشه!
* رتبه اول تا چهارم رو مدل‌های ML اشغال کردن.
* اولین مدل دیپ لرنینگی در رتبه 5 دیده میشه.
* شبکه MLP در رتبه 9 دیده میشه.
* شبکه TabNet آخره!

مقاله بخش‌های متنوعی داره و من فقط یک مقایسه رو آوردم. شاید بعدا بیشتر بنویسم.

از جان مهندسین نرم افزار چه میخواهند؟؟


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

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

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

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

در این سری از پست‌ها میخواهیم راجب BDD (Behavior-Driven Development) توسعه مبتنی بر رفتار صحبت کنیم که از بالاترین سطح تا پایینترین سطح کدزنی را تحت تاثیر خواهد گذاشت و منجر به ایجاد یک نرم افزار مناسب میشود و علاوه بر آن به شما کمک خواهد کرد تا به یکی از بزرگترین چالش‌های موجود که زمان تحویل بموقع نرم افزار است فائق آیید


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


شما با ردگیری دو هشتک زیر در کانال ازین ببعد میتوانید به سلسله پست‌ها مربوط به توسعه رفتار محور دست پیدا کنید

#BDD
#behavior_driven_development

@code_crafters

شاپرک برگزار می‌کند: رویداد امنیت سایبری CASH24

رویداد فتح پرچم  CASH24 با هدف ارتقاء دانش و مهارت‌های امنیت سایبری به ویژه در صنعت پرداخت برای نخستین بار از سوی شرکت شاپرک برگزار می‌شود.
به گزارش روابط عمومی شرکت شاپرک، این رویداد در دو بخش مسابقه CTF و همایش علمی طی سه روز در هفته آخر شهریور ماه و با حضور مدیران ارشد بانک مرکزی، گروه ملی انفورماتیک و متخصصان امنیت سایبری برگزار خواهد شد.
نخستین دوره از رقابت‌های تست نفوذ سایبری شاپرک تحت عنوان رقابت‌های فتح پرچم (Capture the Flag (CTF با هدف شناسایی و مقابله با آسیب‌پذیری‌های محصولات نرم‌افزاری و سامانه‌های امنیتی در روزهای 24 و 25 شهریورماه به صورت آنلاین برگزار می‌شود.
مسابقهCASH24 (CTF Arena For Security & Hacking)  شاپرک شامل بخش‌های مختلفی از جمله امنیت برنامه‌های وب و برنامک‌های موبایل، رمزنگاری و مهندسی معکوس و تحلیل جرم‌شناسی دیجیتال است.
جوایز تیم‌های برنده که شامل جایزه‌های ارزنده‌ای است، همزمان با رویداد امنیت سایبری شاپرک به برندگان اهدا خواهد شد.
رویداد علمی ـ تخصصی امنیت سایبری شاپرک با همکاری آکادینو و حمایت چهار شرکت پرداخت الکترونیک امیدپی، به پرداخت، پارسیان و سپ در روز 27 شهریورماه در قالب کارگاه‌ها و سخنرانی‌های علمی برگزار خواهد شد.
تیم‌های علاقه‌مند برای شرکت در مسابقه می‌توانند از طریق لینک زیر ثبت نام کنند:
https://cash.ctfd.io

توی برنامه نویسی زیادی خسیس نباشید

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

بعضی مواقع انقدری به سمت الگوریتم میریم که داریم به کلیت سیستم آسیب میزنیم مثلا قراره یه دیتایی ارسال کنیم بجای اینکه به این شکل ارسال کنیم

{"name":"linuxor","type":"channel"}

میایم یه صرفه جویی کثیف میکنیم

["linuxor",2]

ما اینجا توی حافظه صرفه جویی کردیم ولی هر جایی بخوایم از این دیتا استفاده کنیم باید بدونیم ایندکس صفرم name هست و ایندکس یکم type و عدد 2 هم برای type یعنی channel این یعنی نیاز به مستندات بیشتر.

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

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

و این تصور که اگه تعداد پردازنده هارو به سمت بی نهایت ببریم سرعت هم بینهایت افزایش پیدا میکنه اشتباهه و در نهایت به یه جایی میرسه که دیگه با افزایش تعداد پردازنده سرعت بیشتر نمیشه.

وقتی که دو نفر، در دو منطقه‌ی جغرافیایی، همزمان اقدام به نصب یک کتابخونه، بعنوان مثال با دستور

pip install 'NAME-OF-LIBRARY'

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

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

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

و همین اختلاف‌های ریز، گاهن مشکلات بزرگی رو تولید می‌کنه. حالا برو بگرد دنبال دلیل 😎.

راه‌ حلش هم ساده است؛ یا دقیقن ورژن مد نظر رو ذکر کنیم. یا هر دو شخص از یک آدرس مخزن استفاده کنند.