NetSqlAzMan
- NetSqlAzMan allows you to change User Authorizations without recompile your application !
- NetSqlAzMan supports AOP (Aspect Oriented Programming
مشاهده تغییرات فایل ها:
در بسیاری از موارد نیاز است تا بتوانیم تفاوت فایلهای موجود در working tree و فایلهای موجود در stage و repository را دریابیم. بدین منظور میتوان از دستورات زیر استفاده کرد:
git log
git diff
git diff HEAD~[number]..HEAD~[number]
توجه کنید که کلمه HEAD اشاره به وضعیت جاری head دارد و عدد number اختلاف آن را با وضعیت جاری مشخص مینماید. به عنوان مثال در شکل زیر ما میخواهیم اختلاف فایلها را بین ۲ دستور commit با مقادیر 9da و e0e را مشخص نماییم. همانطور که ملاحظه میکنید اولی اشاره به وضعیت جاری head و دومی وضعیت قبلی head است. بنابراین ما از دستور زیر استفاده میکنیم:
git diff HEAD~1..HEAD
git diff --staged [filename]
git config --global diff.external <path_to_wrapper_script>
تذکر: راه حل ساده برای این منظور نصب git extension است که در آموزش نصب گفته شد.
تنظمیم git برای صرفنظر کردن از برخی فایلها:
اگراز دستوراتی نظیر . add استفاده کنید متوجه خواهید شد در بعضی موارد نیازی ندارید که تمامی فایلهای موجود در working tree به repository اضافه شوند. فایلها در git به دو دسته تقسیم میشوند؛ برخی که در حال حاضر دنبال شده و برخی که git تغییرات آنها را دنبال نمیکند. در صورتیکه بخواهید فایلی که تغییرات آن دنبال نمیشود را به طور کلی حذف کنید، میتوانید از دستور clean استفاده کنید. دو اصلاح کننده معروف این دستور n- برای نمایش آنکه چه فایل هایی حذف خواهند شد و -f برای اجبار در حذف آنها:
git clean -n [filename] git clean -f [filename]
۱ مجموعه: مثال [adgJHn]
۲ بازه: [9-0] یا [a-z]
۳ حذف یک دایرکتوری با نوشتن آدرس آن و قرار دادن / (البته توجه کنید که با این کار sub directoryها هنوز هم track خواهند شد)
میتوان با استفاده از علامت ! برخی از فایلها و یا دایرکتوریها را مستثنی کرد
میتوان این تنظیمات را در فایلی با نام دلخواه ذخیره کرد و سپس با استفاده از دستور زیر آنها را به صورت global یا سراسری اعمال نمود:
git config global core.excludesfile [path and filename]
چند مثال:
اگر بخواهید فایلهای باینری داخل فولدر bin در repository ذخیره نشوند این خط را در این فایل اضافه میکنیم:
bin/
*.txt
/bin/*.txt
*.txt !readme1.txt
- چرا به کامنت گذاری یا مستند نویسی نیاز داریم؟
- چگونه کامنت بنویسیم؟
- انواع کامنتها چیست؟
- چه کامنتهایی اشتباه هستند؟
همانطور که بیان کردیم، کامنت گذاری یکی از مهمترین کارهایی است که یک برنامه نویس انجام میدهد. به خصوص زمانیکه به صورت تیمی کار میکنید، این امر مهمتر از قبل خود را نشان میدهد. بسیاری از برنامه نویسان که بیشتر دلیل آن تنبلی است، از این کار سرباز میزنند و ممکن است آن را اتلاف وقت بدانند. ولی با کامنت گذاری فهم و درک کد، در آینده بالاتر میرود. در مقالهی تخصصی «هنر کامنت نویسی» نوشتهی «برنهارد اسپویدا» بهانههای جالبی از برنامه نویسان را برای سرباز زدن از اینکار، ذکر شده است؛ به عنوان نمونه:
من کدم را به خوبی متوجه میشوم.کد خوب، خودش گویای همه چیز هست.وقتی برای کامنت نویسی وجود ندارد. باید چسبید به کد.
- شاید امروز معنای یک کد را متوجه شوید، ولی آیا در آینده، مثلا یک سال بعد هم چنین خواهد بود؟
- آیا میتوانید هر سیستمی را که طراحی میکنید، به خاطر بسپارید که فعالیتهایش را به چه نحوی انجام میدهد؟
- اگر در یک کار تیمی باشید، شاید شما متوجه کدتان میشوید، ولی آیا تضمینی وجود دارد که دیگران هم متوجه روش شما شوند؟
- آیا کدی که شما بر روی آن فکر کردهاید و در ذهن خود روش انجام آن را ترسیم کردهاید، میتواند برای برنامه نویسی که کد شما را میبیند هم رخ دهد؟
- اگر شما به صورت تیمی کاری را انجام دهید و یکی از برنامه نویسهای شما از تیم جدا شود، چگونه میتوانید کار او را دنبال کنید؟
- اگر برای برنامه نویسی اتفاق یا حادثهای پیش بیاید که دسترسی شما به او ممکن نباشد چه؟
Documentary Comments: این مستند سازی در سطح یک سند مثل فایل یا به خصوص یک پروژه رخ میدهد که شامل اطلاعات و تاریخچهی آن سند است که این اطلاعات به شرح زیر هستند:
File Name | نام سند |
File Number/Version Number | شماره نسخه آن سند |
Creation Date | تاریخ ایجاد آن |
Last Modification Date | تاریخ آخرین تغییر سند |
Author's Name | سازندهی سند |
Copyright Notice | اطلاعاتی در مورد کپی رایت سند |
Purpose Of Program | هدف کاری برنامه. یک خلاصه از آن چه برنامه انجام میدهد. |
Change History | لیستی از تغییرات مهمی که در جریان ایجاد آن رخ داده است. |
Dependencies | وابستگیهای سند. بیشتر در سطح پروژه معنا پیدا میکند؛ مانند نمونهی آن برای سایت جاری که به صورت عمومی منتشر شده است. |
Special Hardware Requirements | سخت افزار مورد نیاز برای اجرای برنامه. حتی قسمتی میتواند شامل نیازمندیهای نرم افزاری هم باشد. |
PCMBOAT5.PAS************************************************************* ** File: PCMBOAT5.PAS Author: B. Spuida Date: 1.5.1999 Revision: 1.1 PCM-DAS08 and -16S/12 are supported. Sorting routine inserted. Set-files are read in and card as well as amplification factor are parsed. 1.1.1 Standard deviation is calculated. 1.1.2 Median is output. Modal value is output. 1.1.4 Sign in Set-file is evaluated. Individual values are no longer output. (For tests with raw data use PCMRAW.EXE) To do: outliers routine to be revised. Statistics routines need reworking. Existing Datafile is backed up. Purpose: Used for measurement of profiles using the Water-SP-probes using the amplifier andthe PCM-DAS08-card, values are acquired with n = 3000. Measurements are taken in 1 second intervals. The values are sorted using Quicksort and are stacked "raw" as well as after dismissing the highest and lowest 200 values as 'outliers'. Requirements: The Card must have an A/D-converter. Amplifier and probes must be connected. Analog Signal must be present. CB.CFG must be in the directory specified by the env-Variable "CBDIREC" or in present directory.
در بالا، خصوصیت کپی رایت حذف شده است. دلیل این امر این است که این برنامه برای استفاده در سطح داخلی یک شرکت استفاده میشود.
Functional Comments: کامنت نویسی در سطح کاربردی به این معنی نیست که شما اتفاقاتی را که در یک متد یا کلاس یا هر بخشی روی میدهد، خط به خط توضیح دهید؛ بلکه چرخهی کاری آن شی را هم توضیح بدهید کفایت میکند. این مورد میتواند شامل این موارد باشد:
- توضیحی در مورد باگهای این قسمت
- یادداشت گذاری برای دیگر افراد تیم
- احتمالاتی که برای بهبود ویژگیها و کارایی کد وجود دارد.
Explanatory Comment: کامنت گذاری توصیفی در سطح کدنویسی رخ میدهد و شامل توضیح در مورد کارکرد یک شیء و توضیح کدهای شیء مربوطه میگردد. برای قرار دادن کامنت الزامی نیست که کدها را خط به خط توضیح دهید یا اینکه خطوط ساده را هم تشریح کنید؛ بلکه کامنت شما همینقدر که بتواند نحوهی کارکرد هر چند خط کد مرتبط به هم را هم توضیح دهد، کافی است. این توضیحها بیشتر شامل موارد زیر میشوند:
- کدهای آغازین
- کدهای خروجی
- توضیح کوتاه از آنچه که این شیء ، متد یا ... انجام میدهد.
- حلقههای طولانی یا پیچیده
- کدهای منطقی عجیب و پیچیده
- Regular Expression
کدهای آغازین شروع خوبی برای تمرین خواهند بود. به عنوان نمونه اینکه توضیحی در مورد ورودی و خروجی یک متد بدهید که آرگومانهای ورودی چه چیزهایی هستند و چه کاربری داردند و در آغاز برنامه، برنامه چگونه آماده سازی و اجرا میشود. مقادیر پیش فرض چه چیزهایی هستند و پروژه چگونه تنظیم و مقداردهی میشود.
کدهای خروجی هم به همین منوال است. خروجیهای نرمال و غیرنرمال آن چیست؟ کدهای خطایی که ممکن است برگرداند و ... که باید به درستی توضیح داده شوند.
توضیح اشیاء و متدها و ... شامل مواردی چون: هدف از ایجاد آن، آرگومان هایی که به آن پاس میشوند و خروجی که میدهد و اینکه قالب یا فرمت آنها چگونه است و چه محدودیتهایی در مقادیر قابل انتظار وجود دارند. ذکر محدودیتها، مورد بسیاری مهمی است و دلیل بسیاری از باگها، عدم توجه یا اطلاع نداشتن از وجود این محدودیت هاست. مثلا محدودهی خاصی برای آرگومانهای ورودی وجود دارد؟ چه اتفاقی میافتد اگر به یک بافر 128 کاراکتری، 1024 کاراکتر را ارسال کنیم؟
کدهای منطقی عجیب، یکی از حیاتیترین بخشهای کامنت گذاری برای نگه داری یک برنامه در آینده است. به عنوان نمونه استفاده از عبارات با قاعده، اغلب اوقات باعث سردرگمی کاربران شده است. پس توضیح دادن در مورد این نوع کدها، توصیه زیادی میشود. اگر عبارات با قاعده شما طولانی هستند، سعی کنید از هم جدایشان کنید یا خطوط آن را بشکنید و هر خط آن را توضیح دهید.
هر زبانی از یک سیستم خاص برای کامنت گذاری استفاده میکند. به عنوان مثال پرل از سیستم (POD (Plain Old Documentation استفاده میکند یا برای Java سیستم JavaDoc یا برای PHP از سیستم PHPDoc (+ ) که پیاده سازی از JavaDoc میباشد استفاده میکنند. این سیستم برای سی شارپ استفاده از قالب XML است. کد زیر نمونهای از استفاده از این سیستم است:
// XMLsample.cs // compile with: /doc:XMLsample.xml using System; /// <summary> /// Class level summary documentation goes here.</summary> /// <remarks> /// Longer comments can be associated with a type or member /// through the remarks tag</remarks> public class SomeClass { /// <summary> /// Store for the name property</summary> private string myName = null; /// <summary> /// The class constructor. </summary> public SomeClass() { // TODO: Add Constructor Logic here } /// <summary> /// Name property </summary> /// <value> /// A value tag is used to describe the property value</value> public string Name { get { if (myName == null) { throw new Exception("Name is null"); } return myName; } } /// <summary> /// Description for SomeMethod.</summary> /// <param name="s"> Parameter description for s goes here</param> /// <seealso cref="String"> /// You can use the cref attribute on any tag to reference a type or member /// and the compiler will check that the reference exists. </seealso> public void SomeMethod(string s) { } }
دستورات سیستم کامنت گذاری سی شارپ
در سایت جاری، دو مقاله زیر اطلاعاتی در رابطه با نحوهی کامنت گذاری ارئه دادهاند.
- در مقاله «زیباتر کد بنویسیم» چند مورد آن به این موضوع اختصاص دارد.
- مقاله «وادار کردن خود به کامنت نوشتن» گزینهی کامنت گذاری اجباری در ویژوال استودیو را معرفی میکند.
Dependency Injection
در ادامه مباحث بهتر کد بنویسیم و الگوهایی که در این رابطه معرفی شدند، اخیرا کتابی از انتشارات manning منتشر شده تحت عنوان Dependency Injection . هر چند به ظاهر این کتاب برای جاوا کارها تهیه شده اما قسمت عمدهای از آن برای سایر زبانهای برنامه نویسی دیگر نیز قابل استفاده است.
In object-oriented programming, a central program normally controls other objects in a module, library, or framework. With dependency injection, this pattern is inverted—a reference to a service is placed directly into the object which eases testing and modularity. Spring or Google Guice use dependency injection so you can focus on your core application and let the framework handle infrastructural concerns.
Dependency Injection explores the DI idiom in fine detail, with numerous practical examples that show you the payoffs. You'll apply key techniques in Spring and Guice and learn important pitfalls, corner-cases, and design patterns. Readers need a working knowledge of Java but no prior experience with DI is assumed.
WHAT'S INSIDE:
◊ How to apply it (Understand it first!)
◊ Design patterns and nuances
◊ Spring, Google Guice, PicoContainer, and more
◊ How to integrate DI with Java frameworks
راستی، این کتاب تر و تازه رو میتونید از همین کتاب فروشیهای دور و اطراف نیز تهیه کنید! در سایت booktraining دات ارگ در قسمت graphics-and-design به تاریخ 4 آگوست.
محصول ، مدیریت محصول و مدیریت پروژه
There a misinformed notions floating around the agile community that products and better than projects. That some how - unspecified and unsubstantiated as usual - that projects are undesirable and focusing on products and their value - again unspecified how to measure that value and unsubstantiated that value measurement isn't what projects do as well.
راهنمای زبان Rust از مایکروسافت
This is a (non-comprehensive) guide for C# and .NET developers that are completely new to the Rust programming language. Some concepts and constructs translate fairly well between C#/.NET and Rust, but which may be expressed differently, whereas others are a radical departure, like memory management. This guide provides a brief comparison and mapping of those constructs and concepts with concise examples.
As we’ve been moving forward on the Outdated Answers project, one of the things that’s been clear is that on questions with multiple answers, we need a way to surface newer answers that may be more current, while reducing the visibility of older answers that may no longer be correct or relevant
معرفی WebHook ها
Introducing Microsoft ASP.NET WebHooks Preview
ASP.NET WebHooks Documentation