نظرات مطالب
اعمال تزریق وابستگی‌ها به مثال رسمی ASP.NET Identity
با تشکر از توجه شما. 
در این پروژه نمونه و با همین تنظیمات، شرایط بدین گونه است: 
کاربر سایت را به صورت ناشناس مشاهده می‌کند. سپس با اطلاعات خود وارد سایت می‌شود. پس از تعییت هویت، مثلا به بخش Product هم دسترسی پیدا می‌کند. تا این مرحله همه چیز خوب است و خیر. سپس از حساب خود خارج می‌شود و دقایقی بعد، مجددا وارد حساب خود می‌شود. از این لحظه به بعد، رفتار برنامه متفاوت می‌شود. چرا که با وجود اینکه کاربر تایید هویت شده، اما اگر بخواهد مثلا دوباره به همان بخش Product مراجعه کند، سیستم ابتدا او را به صفحه‌ی ورود هدایت کرده و با کاربر، به عنوان یک کاربر ناشناخته برخورد می‌کند. همین گونه است برای سایر قسمتهایی که صفت Authorize  برای آنها لحاظ شده. پرسش من این است که آیا این رفتار طبیعی ست؟
قبلا گفتم که با تغییر مقدار validateInterval   ظاهرا این مشکل بر طرف می‌شود. لااقل این رفتار تغییر می‌کند. شما  فرمودید که در نظرگرفتن هر عددی جز صفر، موجب می‌شود تا کوکی بلافاصله به روز نشود. این صحبت شما کاملا صحیح و منطقی. اما آیا ورودهای مکرر به نظر شما منطقی ست؟
به کدهای این پروژه هم دقت کردم. مقدار validateInterval   برابر با 30 لحاظ شده که ظاهرا نباید اینگونه باشد. برای اینکه هم به رویکردی که شما به آن اشاره کردید برسیم و هم کاربر مجبور نباشد مدام Login کند، لطفا بفرمایید که چه تغییراتی لازم است؟ در صورتیکه من اشتباه کرده ام و یا چیزی را ندیده و یا از قلم انداخته ام، لطف می‌کنید اگر راهنمایی بفرمایید.
مطالب
چرا باید از Git Hooks استفاده کنیم؟ معرفی Husky.Net
قبل از شروع این مقاله بهتر است ابتدا یک خاطره‌ی کوچک را تعریف کنم. مدتی پیش بود که برای سایت داکیومنتیشن یکی از پروژه‌های Open-Source سعی داشتم از vuepress که یک static site generator هست استفاده کنم. متاسفانه نسخه‌ی بتایی که استفاده میکردم یک فیچر مورد نیازم را نداشت و مجبور شدم خودم به‌آن این فیچر را اضافه کنم. سوروس را گرفتم، فیچر اضافه شد و ماجرا از اینجا شروع می‌شود ...

  • commit lint : اول اجازه نداد که کامیت را انجام دهم! با این توضیح که متن کامیت شما باید فرمت کامیت‌های این پروژه را رعایت کند. اگر به تصویر زیر دقت کنید، کامیت‌ها در این پروژه بسیار منظم هستند و هر کسی با هر متنی که دلش خواست کامیتی انجام نمی‌دهد. با یک بررسی کوچک متوجه شدم چطور باید فرمت این پروژه را رعایت کنم و مشکل رفع شد.



  • eslint : مرحله بعدی فایل‌هایی که تغییر داده بودم و یا ایجاد کرده بودم، با ابزار eslint به صورت خودکار بررسی شد. (eslint مشابه analyzer‌های دات نت است که برای بررسی مشکلات موجود در سورس کد استفاده می‌شود). در تصویر زیر یک مثال از خطای ایجاد شده‌ی توسط eslint را مشاهده می‌کنید. در این مرحله من با خطایی مواجه نشدم؛ ولی متوجه شدم کدی که نوشتم، مشکل خاصی ندارد. 



  • prettier  : مرحله سوم کد نوشته شده‌ی من توسط دستورات فرمتی که این پروژه رعایت می‌کند مانند style کد نویسی، استفاده از space یا tab، فاصله فرو رفتگی (indent) خطوط و غیره ... به صورت خودکار فرمت شد و کامیت من انجام شد. 

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

تا اینجا با یکسری مزایای پایه‌ی داشتن چنین سیستمی آشنا شدیم ولی چطور این اتفاق رخ می‌دهد!؟ پاسخ: با استفاده از Git Hooks . البته ما صرفا محدود به انجام همین کارها نیستیم. هر کاری که در ترمینال سیستم قابل انجام باشد، از طریق Git hooks هم قابل انجام است. مثلا یکی دیگر از استفاده‌های رایج از git hooks میتواند اجرای Unit-Test‌ها قبل از push باشد.
در پروژه‌ی vuepress، تعداد زیادی ابزار به صورت هماهنگ نصب شده و کار میکنند که در نهایت با استفاده از Hook‌های Git، اجرا میشوند (مثلا از هوک pre-commit برای اجرای یکسری فرمان قبل از هر کامیت). با سه مورد از این ابزارها، در ابتدای این مقاله آشنا شدیم. ولی کلید اصلی تمام این‌ها، دو ابزار  husky  و  lint-staged هستند. husky ساخت و استفاده از git hook‌ها را آسان میکند و lint-staged وظیفه دارد تا فایل‌های stage شده‌ی در گیت را لیست کند و به سایر ابزارها برای اجرا ارسال نماید. 

شاید بپرسید که تمام اینها از Nodejs و npm استفاده میکنند، چطور میتوانیم از این امکانات در دات نت استفاده کنیم!   

معرفی Husky.Net 
این کتابخانه ترکیبی از ابزارهای husky و lint-staged و چند ابزار دیگر برای برنامه نویسان دات نت است. با استفاده از این ابزار به راحتی میتوانید از هوک‌های Git برای اجرای دستورات خود یا سایر ابزارها استفاده کنید. husky.net یک task-runner داخلی دارد که تعریف و ایجاد تسک‌های قابل اجرا توسط هوک‌ها را آسان میکند.

نصب husky.net
# local installation (recommended)
cd <Your project root directory>
dotnet new tool-manifest
dotnet tool install Husky

# global installation
dotnet tool install --global Husky

نکته نهایی
من در این مقاله قصد داشتم فقط دلیل نیاز به چنین ابزاری را شرح دهم؛ توضیح اینکه husky.net چه امکاناتی دارد و چطور میتوان از آن استفاده کرد، خارج از حوصله‌ی این مقاله است. اگر شد در آینده مقاله‌ای برای آموزش این ابزار تهیه میکنم؛ فعلا برای کسب اطلاعات بیشتر میتوانید به صفحه‌ی گیت هاب این ابزار مراجعه کنید و دلیل دیگر اینکه فکر میکنم الان زمان مناسبی برای آموزش نیست؛ چون این پروژه بسیار جوان است و به تازگی نوشته شده و احتمال اینکه فیچر‌های آن به زودی تغییر کند هم وجود دارد. همینطور از علاقمندان به مشارکت در پروژه‌های open-source دعوت می‌کنم که به بهبود این ابزار و یا تهیه‌ی ابزارهایی که در حال حاضر مشابهی در دات نت ندارند، کمک کنند. به طور مثال برای فرمت کد و آنالایزر، dotnet-format  مایکروسافت وجود دارد که بسیار کاربردیست؛ ولی ما ابزاری مثل commit lint هنوز در دات نت نداریم. فعلا در صورت نیاز باید برای استفاده از آن همچنان node و npm را نصب کنیم.
مطالب
آشنایی با Visual Studio 2012 Code Map
Code Map چیست؟
در نسخه Visual Studio 2012 Ultimate Update 1  قابلیتی به نام Code Map اضافه گردید که امکان تصویر سازی، روابط کد‌ها را فراهم می‌سازد.
در نسخه  Visual Studio 2012 Update 2 مایکروسافت Code Map را توسعه داد و با پشتیبانی از اشکال زدایی، با Code Map نیز می‌توانید قدم به قدم کد را اشکال زایی نمایید. به زبان ساده‌تر Code Map فلوچارت اجرای برنامه است که در آن ارتباط بین متود‌ها نمایش داده شده است.
چگونه  از Code Map Debugging استفاده نماییم؟

در خطی از برنامه Break Point گذاشته و برنامه را اجرا نمایید. وقتی برنامه به خط مورد نظر رسید، نوار ابزار Debug را فعال و گزینه Code Map را انتخاب کنید تا پنجره Code Map باز شده و فلوچارت کد مورد نظر را رسم نماید. نوار قرمز رنگ دور گره، قسمتی از کد که در حال حاضر در حال اشکال زدایی است را نشان می‌دهد. وقتی با کلید F11 به درون متودی می‌روید گره متناظر آن نیز رسم می‌شود.

اگر بر روی فیلد Summary راست کلیک و گزینه Find All References on Code Map را انتخاب کنید، همه ارجاع‌های که این فیلد در آنها صدا زده شده است را نمایش می‌دهد.

اگر بر روی هر کدام از گره‌ها موس خود را نگه دارید پنچره ای باز شده و اطلاعات درباره آن گره به شما نمایش می‌دهد. مثلا برای متود‌ها امضای متود را نمایش می‌دهد.

بررسی ویژگی‌های Code Map:
برای هر گره در صورت لزوم می‌توانید یادداشتی اضافه نماید برای این کار گره مورد نظر را انتخاب تا نوار ابزاری در کنار آن ظاهر شود و گزینه create new comment node را انتخاب و یادداشت خود را ثبت نمایید.

می توانید code map را با دیگران از طریق ایمیل به اشتراک گذارید یا آن را ذخیره نمایید. برای این کار در بالای پنجره code map گزینه share را انتخاب و یکی از آینم‌ها مورد نظر را کلیک نمایید.

علاوه بر این برای تعقیب کردن یک گره آن می‌توانید آن را با یک پرچم و تغییر رنگ آن در پنجره code map از دیگر گره‌ها مجزا و تعقیب نمایید. برای این کار بر روی گره مورد نظر راست کلیک و گزینه Flag for Follow Up را انتخاب نمایید. از گزینه Other Flag Colors رنگ پیش فرض آن را می‌توانید تغییر دهید.

بازبینی اشاره گر ها:

در کنار هر گره علامتی نمایان می‌شود که وضعیت code amp در آن لحظه برای آن گره را نمایش می‌دهد.

تغییر نمای دیاگرام:

برای تغییر نمای گراف code map و نمایش بهتر آن از گزینه layout یکی از حالات موجود را می‌توانید انتخاب نمایید. هر وقت گره ای  اضافه شود که قبلا اضافه شده باشد رنگ آن سبر می‌شود برای پاک کردن این چنین گره‌های گزینه clear Result Highlighting را انتخاب نمایید.

مطالب
راحت بگویید نه!

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

- در مواقعی که کار جدیدی به شما میرسد و برآوردی از زمان انجام آن ندارید قبل از دادن هر قولی زمان کوتاهی بین نیمروز تا 2 روز برای بررسی درخواست کنید که با توجه به اهمیت موضوع ممکن است در حد بیان شفاهی یک درخواست بماند و ادامه ای نداشته باشد.

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

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

- هیچگاه خودتان را بیکار نشان ندهید، در خیلی از مواقع فرد مزاحم از کم کار بودن شما منظور تعداد کارهای در دست انجام به سراغ شما میاید. بگذارید مثالی برایتان بیاورم که در واقع خاطره ای از همکاران خودمان است. رئیس بخش به X میگوید که کارتان خیلی کم شده و Y را که نوع فعالیتش (شاید سخت افزاری که دائما بین میزها و اتاقها جابجا میشود و یا یک کیس کامپیوتر را هم ممکن است جابجا کند) با شما (خاص پشت میز بنشینید و شروع به خلق قسم‌های مختلف نرم افزار کنید) سنخیتی ندارد را در کفه دیگر ترازو قرار میدهد، خوب X هم بعد از جابجایی بی مورد چند کیس به اتاقهای در دسترس از کسی بنقل از رئیس میشنود که شما یعنی X خیلی فعالیتتان زیاد است و دارید در این مجموعه سخت تلاش میکنید.

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

- همیشه در بیان و جواب درخواست‌ها از مکالمه بصورت زنده استفاده کنید و نه از ایمیل و یا یادداشت.

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

- اگر تا پیش از این به خلوت بودن میز کارتان اهمیت میدادید. مطمئن باشید با ادامه این رفتار کاغذهای میز شما را دیگران افزایش میدهند نه شما، پس بهتر است که شما کاغذها را آنقدرها هم کاهش ندهید و هر از چندگاهی هم کاغذها را بور بزنید.

- ما بیکار ننشسته ایم، چطور؟ بگذارید خاطره ای برایتان تعریف کنم. یکی از دوستان مسئول قسمتی از نگهداری سرورهای اداره ای را بر عهده گرفته بود و تقریبا در یک سیکل بر اساس شیفت، کابل شبکه سرور را بیرون میکشید همکار دیگر مبهوت میشد که این کار چه سودی دارد. به تلفنهای زیادی که زده میشد جواب در حال بررسی و حل مشکل هستیم داده میشد و در آخر این سوال چرا را با این جواب میداد " ما بیکار ننشسته ایم ". یعنی این تفکر باید خلق شود که شما دور از چشم دیگران هم بیکار نیستید .

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

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

- توضیح فنی ممنوع، شاید برای شما مهم باشد که از چه تکنیک و یا کتابخانه هایی استفاده میکنید ولی بالاتر از شما به این موضوع اهمیت میدهند که چند ساعت باز هم میگویم چند ساعت وقت برای آن کار صرف کرده اید. یعنی هرچه بیشتر شیفتگی خود را به کتابخانه‌های تسهیل کننده مانند افزونه هایی مثل ریشارپر نشان بدهید برای فرد مقابل که ممکن است یک برنامه نویس ADO.NET باشد شما به چشم یک کلاهبردار و یا سوء استفاده گر بنظر میایید. 

اگر دوستان هم مورادی مشابه را در نظر دارند لطفا برای مشارکت در نظرات درج کنند.

پ.ن: با توجه به بعضی نظرات لازم میدونم اینو بگم که متن بالا در واقع تمثیل ادب از که آموختی بوده تا رواج بی ادبی. البته امیدوارم برداشت خواننده این نباشه که همه مجموعه رو باید سر کار گذاشت.

اشتراک‌ها
آموزش PL/SQL
همان طور که می‌دانید pl/sql زبان برنامه نویسی قدرتمند هست که شرکت اراکل آنرا ارائه کرده، این سایت یک خودآموز برای یادگیری این زبان برنامه نویسی هست
آموزش PL/SQL
نظرات نظرسنجی‌ها
کدامیک از روش‌های زیر را برای تولید App های موبایل ترجیح می‌دهید؟ چرا؟
با فرض این که یک تیم با تجربه به هر سه روش مسلط باشند، این انتخاب کاملا به کاربرد اپلیکیشن مورد نظر بستگی دارد. ضمننا در هزینه تمام شده (تولید، توسعه، نگهداری) نرم افزار هم موثر است.
در صورتی که یک برنامه نویس بخواهد روشی انتخاب کند بسته به شرایط برنامه نویس متغییر است. 
  • پس زمینه برنامه نویسی
  • تکنولوژی هایی که مسلط است
  • چقدر وقت دارد چیز جدید یاد بگیرد
Cross-platform خودش چند مدله (معروف‌تر هاش این موارد):
  • HTML+JS +WebView (Cordova)
  • C#+ XAMARIN
  • HTML+JS+ Native Run (Native Script)
...
اشتراک‌ها
برنامه نویسی Paranoid
برنامه نویس‌ها نیاز است اندکی تا قسمتی Paranoid باشند ... از بررسی دقیق ورودی‌ها گرفته تا درنظر گرفتن تمام خطاهای ممکن و ...
برنامه نویسی Paranoid