نظرات مطالب
طراحی گردش کاری با استفاده از State machines - قسمت دوم
با تشکر؛
کل بحث جا افتاده است برایم  ولی در مثال BlogPostManager ، کمی غیر قابل درک میباشد که وقتی بحث سطح دسترسی مطرح است ، Guard‌ها چه استفاده ای خواهند داشت؟ منظور بنده این است که وقتی در یک برنامه فرضا Asp.net برای هر یک از Trigger‌ها یک اکشن متد خاص (برای ویرایش فیلد State رکورد) داشته باشیم ، همین چک کردن این مورد که آیا کاربر، نویسنده پست یا مدیر است هم در ابتدای اکشن باید صورت گیرد و اجازه دسترسی به ادامه کار داده نشود(Forbidden)  . اگر برداشت بنده صحیح نیست هم لطفا راهنمایی کنید.
ممنون میشوم بحث را با مثال واقعی تحت وب یا ویندوز مطرح کنید. 
نظرات مطالب
Anti CSRF module for ASP.NET
سلام استاد نصیری
راستشو بگم از مطلبی که گذاشتین خیلی سر درنیوردم.
الان در این کد:img src="http://www.example.com/logout.aspx">
چه اتفاقی میفته فرض کنید مدیر سیستم از این صفحه بازدید کنه.آیا برای SRC میشه کدهای جاوا نوشت که مثلا اطلاعات سشن رو میل بزنه؟آیا همچین دسترسی به سشن یا کوکی داریم؟
میشه یکمی هم از فرق روشهای Post و Get در این باره بگین؟من فرقشونو در این زمینه متوجه نشدم.
اگر میشه یکم بیشتر (جسارته اما با یه مثال عملی تر) مطلب رو باز کنین
موفق باشید
نیما
مطالب
تعرفه مصوب سال 1390

گاهی از اوقات که ... چه عرض کنم، «عموما» آمار و اطلاعات ما از دره سیلیکون بیشتر است از آمار و اطلاعات داخلی؛ از آمار عطسه کردن مدیر اجرایی گوگل تا جیغ کشیدن رئیس مایکروسافت تا نوسانات فشار خون استیو جابز در یک ماه اخیر و تا ... عوض شدن لوگوی فلان موبایل!
به همین جهت برای «تنوع» شاید بد نباشد «تعرفه نرخ پایه خدمات فنی - تخصصی انفورماتیک برای سال 1390» منتشره توسط سازمان نظام صنفی رایانه‌ای کشور را هم مطالعه کنیم:




پاسخ به بازخورد‌های پروژه‌ها
سوال در مورد Authenticate_Request
سلام؛
بله منطقی است. به این علت که role کاربر در کوکی‌های شخص ذخیره می‌شود این کوئری باید به بانک ارسال شود.
برای مثال فرض کنید که کاربری که وارد سایت شده را مدیر بن کرد یا سطح دسترسیش را تغییر داد، اما تا زمانی که کاربر مجددا اقدام به ورود به سایت نکنه نمی‌توانیم آن کاربر را مسدود کنیم. حال در اینجا به بانک اطلاعاتی متصل شده و سطوج دسترسی و وضعیت کاربر را بررسی می‌کنیم تا در صورت لزوم کاربر را logout اجباری کنیم.
این را هم در نظر بگیری ما با یک DBMS قدرتمند طرف هستیم. اگر قرار باشد با چند ده تا کوئری سیستم مختل شود که...
برای بهینه سازی هم می‌توانید از کش مدت دار سمت سرور استفاده کنید.
در ضمن قسمت مربوط به مدیریت کاربران این سیستم  را از صفر بازنویسی کردم که بسیار قوی‌تر از سیستم کنونی است و هر موقع رابط کاربریش تحت AngularJs آماده شد آن را به اشتراک می‌گذارم.
مطالب
آشنایی با CLR: قسمت هفدهم
در مقاله قبلی در مورد افزودن منابع به اسمبلی صحبت‌هایی کردم که قسمتی از این منابع مربوط به اطلاعات نسخه بندی بود. در این مقاله قصد داریم این مسئله را بازتر کرده و در مورد نحوه‌ی نسخه بندی بیشتر صحبت کنیم.
در مقاله‌ی قبلی وقتی نسخه‌ی یک اسمبلی را مشخص می‌کردیم، از 4 عدد که با نقطه از هم جدا شده بودند، استفاه کردیم که در جدول زیر این 4 نامگذاری را مشاهده می‌کنید:

 شماره بازبینی Revision Number

شماره ساخت Build Number
شماره جزئی Minor Number
شماره اصلی Major Number
 2 719
5
2

اسمبلی بالا به ورژن یا نسخه‌ی 2.5.719.2 اشاره دارد که دو شماره‌ی اول (2.5) مثل تمامی برنامه‌ها به میزان تغییرات کارکردی یک اسمبلی اشاره دارد و عموم مردم هم نسخه یک نرم افزار را به همین دو عدد میشناسند. عدد سوم به این اشاره دارد که در شرکت، این ورژن از اسمبلی چندبار build شده است و شما باید به ازای هر Build این عدد را افزایش دهید. عدد آخری به این اشاره دارد که در طول روز انتشار، این چندمین Build بوده است. اگر در زمان ارائه‌ی این اسمبلی باگ مهمی در آن یافت شود، با هر بار Build آن در یک روز، باید این عدد افزایش یابد و برای روزهای آتی این مقدار مجددا آغاز می‌شود. مایکروسافت از این سیستم نسخه بندی استفاده می‌کند و بسیار توصیه می‌شود که توسعه دهندگان هم از این روش تبعیت کنند.

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

AssemblyFileVersion: این شماره نسخه در منابع اطلاعاتی Win32 ذخیره می‌گردد و کاربرد آن تنها جهت نمایش این اطلاعات است و CLR هیچ گونه ارجاع یا استفاده‌ای از آن ندارد. در حالت عادی، شما باید دو شماره اولی را جهت نمایش عمومی مشخص کنید. سپس با هر بار Build کردن، شماره‌های ساخت و بازبینی را هم به همان ترتیب افزایش می‌دهید. حالت ایده‌آل این است که ابزار AL یا CSC به طور خودکار با هر بار Build شدن، با توجه به زمان سیستم، به طور خودکار این دو شماره آخر را مشخص کنند ولی متاسفانه واقعیت این است که چنین کاری صورت نمی‌گیرد. این اعداد جهت نمایش و شناسایی اسمبلی برای اشکال زدایی مشکلات اسمبلی به کار می‌رود.

AssemblyInformationalVersion: این شماره نسخه هم در منابع اطلاعاتی Win32 ذخیره می‌گردد و تنها هدف اطلاعاتی دارد. مجددا اینکه CLR هیچ گونه اهمیتی به آن نمی‌دهد. این شماره نسخه به محصولی اشاره می‌کند که شامل این اسمبلی است.

به عنوان مثال ورژن 2 یک نرم افزار ممکن است شامل چند اسمبلی باشد که ورژن یکی از این اسمبلی‌ها یک است و دلیلش هم این است که این اسمبلی از نسخه‌ی 2 به بعد اضافه شده و در نسخه‌ی یک نرم افزار وجود نداشته است. به همین دلیل در این مدل از نسخه بندی شما دو شماره اول را به نسخه خود نرم افزار مقداردهی کرده و سپس مابقی اعداد را با هر بار پکیج شدن کل نرم افزار با توجه به زمان افزایش می‌دهید.

AssemblyVersion: این شماره نسخه در جدول متادیتای AssemblyDef ذخیره می‌گردد. CLR از این شماره نسخه جهت اتصال نام قوی Strongly Named به اسمبلی استفاده می‌کند (این مورد در فصل سه کتاب  توضیح داده شده است). این شماره نسخه بسیار مهم بوده و به عنوان شناسه‌ی یکتا برای اسمبلی استفاده می‌شود.

موقعیکه شما شروع به توسعه‌ی یک اسمبلی می‌کنید، باید هر 4 شماره نسخه را مقداردهی کرده و تا زمانیکه توسعه‌ی نسخه بعدی آن اسمبلی را آغاز نکرده‌اید، نباید آن را تغییر دهید. علت اصلی آن این است که موقعیکه اسمبلی «الف» با یک نام قوی به اسمبلی «ب» ارجاع می‌کند، نسخه‌ی اسمبلی «ب» در ورودی جدول AssemblyRef  اسمبلی «الف» قرار گرفته است. این مورد باعث می‌شود زمانیکه CLR به بارگزاری اسمبلی «ب» احتیاج دارد، دقیقا می‌داند که چه نسخه‌ای با اسمبلی «الف» ساخته و تست شده است . البته این احتمال وجود دارد که CLR نسخه‌ای متفاوت از اسمبلی را با Binding Redirect بار کند که ادامه‌ی این مباحث در فصل سوم دنبال می‌شود.

نظرات مطالب
تعرفه مصوب سال 1390
بحث برنامه نویس یا توسعه دهنده مثل بحث یک خیاط است. شما به خیاط می‌گید «من یک دست کت و شلوار خوب می‌خوام». این خوب بودن رو اون هست که باید تفسیر کنه. من نمی‌دونم. من خیاط نیستم؛ هرچند از دیدگاه خیاط شاید من به قول شما یک نفر بی اطلاع محض باشم! این وضع، همه جای دنیا هم به همین صورت است.
در کل این نوع حرکات، جهت انتشار حداقل حقوق برنامه نویس یا مصرف کننده بسیار مفید است. خیلی‌ از برنامه نویس‌ها حداقل حقوق خودشون رو نمی‌دونند و بی‌جهت بازار رو خراب می‌کنند. عده‌ای سودجو هم هستند که برای مثال پروژه‌های سورس باز رو با یک لایه فارسی به قیمت‌های گزافی می‌فروشند. روشن شدن یک سری از حداقل‌ها در کل به نفع جامعه است.
مطالب
ارتقاء از WinForms به WPF

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


ماخذ
نظرات نظرسنجی‌ها
آیا در کنفرانس‌های توسعه دهندگان داخلی شرکت می‌کنید؟
یادمه در یکی از کنفرانس‌های پیشین در تهران، از صاحبان اپ هایی مثل پی سی دانلود و یا سایت‌های تبلیغاتی دعوت کرده بودند که برای مردم سخنرانی کنند و علت موفقیتشون رو بگن :)))

خب فکر میکنم همین خودش دیگه برای شرکت نکردن در یک چنین کنفرانسی کفایت میکنه. وقتی که سطح دید و سواد اون کنفرانس در حد تولید وب سایت دانلود ! و یا اپلیکیشن‌های کپی شده از نمونه‌های خارجی هست، دلیلی برای یک توسعه دهنده وجود نداره که اون رو به شرکت کردن وادار کنه.
در واقع اگر بخوام دقیقتر و رک‌تر توضیح بدم، این کنفرانس‌ها بیشتر یک بازار بلیط فروشی (هر بلیط حدود ۲۰ تا ۵۰ هزار تومان) و تبلیغ کالاهای کپی شده هستن تا یک کنفرانس در رابطه با پیشرفت علم نرم افزار.
مطالب
وادار کردن خود به کامنت نوشتن

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

برای این تنظیم، ابتدا به برگه خواص پروژه مراجعه کنید. سپس در قسمت Build تنظیمات زیر را اعمال نمائید:
Treat warnings as errors را بر روی All قرار دهید.
در ذیل آن، در قسمت Output‌، گزینه‌ی XML Documentation file را تیک بزنید.

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

مطالب مرتبط:



مطالب
مروری بر کتابخانه ReactJS - قسمت دوم - نصب و پیکربندی React‌JS برای Visual Studio Code

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

var ClickableImage = function (props) {
    return (
        <a href={props.href}>
            <img src={props.src} />
        </a>
    )
};
میان یک فایل جاوااسکریپت، از تگ‌های HTML استفاده شده‌است. چرا و چطور؟! 

React از دو روش برای ساخت تگ‌ها استفاده میکند. روش ساده‌تر همین مثالی است که در بالا آمده؛ یعنی از تگ‌های HTML را به صورت مستقیم استفاده می‌کند. روش دیگر، استفاده از زبان جاوااسکریپت به تنهایی است. مثلا تگ‌های <a> و <img>  بالا به صورت زیر نوشته میشوند:

var ClickableImage = function(props) {
    React.createElement(
        "a", 
        {href: props.href}, 
        React.createElement(
            "img",
            {src: props.src}
        )
    )
};

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


JSX

JSX زبان یا روشی است که اجازه میدهد از تگ‌های مشابه با HTML در جاوااسکریپت استفاده کنیم. به دلیل تفاوت‌های مختصری که دارند، گفته شد که این تگ‌ها دقیقا HTML نیستند. برای مثال در تگ‌های HTML خاصیت‌های class و for را داریم؛ اما در تگ‌های JSX باید به ترتیب از className و htmlFor استفاده کنیم. مسئله بعدی این است که اساسا JSX همراه با React ارائه نشده و برای اینکه بتوانیم از JSX استفاده کنیم، نیاز به ابزاری اضافه داریم تا JSX را برای JavaScript و مرورگر ترجمه کند که فیسبوک، Babel را پیشنهاد میدهد. اگر از JSX بدون ابزار مترجم استفاده کنیم با پیام خطای زیر مواجه می‌شویم. 

  > Uncaught SyntaxError: Unexpected token

یعنی کاراکتر شروع (>) تگ‌ها را تشخیص نمیدهد.


نصب کتابخانه‌ها

این کتابخانه‌ها را می‌شود به مدل‌های مختلفی دریافت و پیکربندی کرد. بسته به نوع پروژه و محیط توسعه و پیکربندی‌های خاص هر پروژه، روش کار میتواند متفاوت باشد. هدف اصلی، مروری بر امکانات React است. پس ساده‌ترین روش نصب را برای ادامه کار انتخاب میکنیم. مانند هر کتابخانه‌ی دیگری میشود بطور یکجا React و Babel را از سایت‌های اصلی یا Github دانلود و به پروژه اضافه و استفاده کرد؛ مثل jQuery و Bootstrap. اما راه استاندارد و پیشنهاد شده، استفاده از ابزارهای مدیریت بسته‌ها مثل npm است. در قدم اول با فرض بر اینکه VSCode و npm بر روی سیستم نصب هستند، اول یک پوشه خالی را در VSCode به عنوان پروژه باز میکنیم و از منوی View -> Integrated Terminal  را انتخاب میکنیم. در ترمینال باز شده دستور نصب زیر را وارد میکنیم.

npm install react react-dom
با این کار پوشه node_modules به ریشه پروژه اضافه میشود که حاوی کتابخانه React است. پوشه node_modules مختص به React نیست. هر کتابخانه‌ای را که به این صورت نصب کنیم، به این پوشه اضافه میشود. مرحله بعد، نصب کتابخانه Babel جهت استفاده‌ی از JSX است. کتابخانه Babel یک مترجم بزرگ است که اجزای مختلفی دارد. ما به حداقل‌هایی از آن برای ترجمه تگ‌های JSX  احتیاج داریم. برای این کار همانند قبل، ترمینال را انتخاب میکنیم و دستور نصب زیر را اجرا میکنیم. با این دستور نصب، کتابخانه مختصر babel-standalone به پوشه node_modules اضافه میشود.
npm install babel-standalone

نحوه استفاده

فایل index.html را به ریشه پروژه اضافه کنید و کدهای زیر را درون تگ Body قرار دهید: 

<div id="reactTestContainer"></div>

<script src="node_modules/react/dist/react.min.js"></script>
<script src="node_modules/react-dom/dist/react-dom.min.js"></script>
<script src="node_modules/babel-standalone/babel.min.js"></script>
<script src="react-test.js" type="text/babel"></script>

برای کار با کتابخانه React به دو فایل react.js و react-dom.js نیاز داریم. اولی بخش اصلی کتابخانه و دومی برای ساخت تگ‌ها و تبادل با بخش HTML DOM استفاده میشود؛ مثلا اضافه کردن تگ‌های ساخته شده به HTML. ذکر ویژگی "type="text/babel برای فایل‌هایی که در آنها از تگ‌های JSX استفاده شده ضروری است؛ در غیر اینصورت Babel  تشخیص نمیدهد که کار ترجمه را برای چه فایلهایی باید انجام دهد. در نهایت قطعه کد زیر را در فایل react-test.js وارد کنید. 

var ClickableImage = function (props) {
    return (
        <a href={props.href}>
            <img src={props.src} />
        </a>
    )
};

ReactDOM.render(
    <ClickableImage href="http://google.com" src="google.jpg"/>, 
    document.getElementById("reactTestContainer")
)

با اجرا کردن پروژه، تصویری قابل کلیک به مقصد گوگل، در تگ <div>، با ویژگی "id=”reactTestContainer ایجاد خواهد شد.

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