نحوه کار با Git

قبل شروع  لطفا  مقدمه Gitرا  در اینجا مطالعه کنید.

Git توسط سازنده سیستم عامل لینوکس یعنی آقای Linus Torvalds و برای مدیریت کد‌های آن ساخته شد که بعدها توسط Linux-BitKeeper ارتقا  یافت. BitKeeper یک سیستم مدیریت کد توزیع شده است که البته رایگان نیست. تیم BitKeeper در ابتدا پروژه لینوکس را به صورت رایگان پشتیبانی می‌کرد اما در سال ۲۰۰۵ این حمایت را قطع کرد. در این هنگام تیم توسعه لینوکس تصمیم گرفت که خود یک سیستم مدیریت کد توزیع شده ایجاد کند. آن‌ها این سیستم را با Perl و C نوشتند و آن را برای اجرا شدن بر روی انواع سیستم عامل‌ها نظیر لینوکس ویندوز و حتی مک آماده کردند اهداف اصلی Git عبارتند از:

۱) سرعت بالا
۲) سادگی
۳) قدرت پشتیبانی بالا از Merge/Branching
۴) یک سیستم کاملا توزیع شده
۵) قابلیت توسعه برای پروژه‌های بزرگ

برای شروع کار ابتدا آن را نصب می کنیم:

برای نصب در لینوکس ابتدا باید پیش نیازهای نصب کرد:

 apt-get install libcurl4-gnutls-dev libexpat1-dev gettext  libz-dev libssl-dev

و سپس باید خود Git  را نصب کنید:

$ apt-get install git

 بعد از نصب گیت شما نیاز داربد که دایرکتوری که در آن می خواهید با استفاده از گیت فایل ها را مدیریت کند مشخص کنید.روش کار به این صورت است که ابتدا شما وارد مسیر دایرکتوری می شوید(با استفاده از کنسول)سپس عبارت git init را تایپ می کنید.اگر به دایرکتوری نگاه بیاندازید شما یک فولدر به نام .git خواهید دید.

git init

دستوری نام status وجود دارد که وسیله  آن از وضعیت فایل های موجود در دایرکتوری که توسط گیت مدیریت می شود مطلع خواهید شد.

 git status

به طور مثال ما یک فایلی را اضافه کردیم در این صورت اگر status را اجرا کنیم متوجه فایل اضافه شده می شویم.

فایل ها در گیت می توانند دو وضعیت دسته بندی شوند:

۱-tracked:هر فایل در این دسته بندی ۳ حالت دارد

  • unmodified
  • modified
  • staged:آماده commit

۲-untracked:فایل هایی که توسط گیت از آنها snapshot گرفته نمی شود.

Git lifsycle

گفتیم که با status می توان  وضعیت جاری را مشاهده کرد.حال می خواهیم یک فایل را به مخزن اضافه کنیم و به گیت بگوییم که از این فایلsnapshot بگیرد.برای این کار از دستور add استفاده می کنیم.

git add filename

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

git add .

استفاده کرد.

بعد از افزودن فایل ها به گیت حال آماده برای commit کردن هستیم در واقع یک commit عبارت است از snapshot از  مخزن که در صورتی که نیاز بود به عقب باز گردیم بتوانیم از آن استقاده کنیم.

برای commit از دستور زیر استفاده می کنیم:

git commit -m “comment”

اگر نیاز داشتید به لاگ ها نگاهی بیاندازید از

git log

استفاده کنید.

تا به اینجا ما در حال کار برروی مخزن local بودیم حال اگر بخواهیم به یک مخزن remote وصل شویم نیاز داریم ابتدا آدرس آن را به گیت اضافه کنیم :

git remote add origin https://github.com/try-git/try_git.git

حال آماده push کردن به مخزن remote هستیم برای این کار از :

 git push -u origin master

استفاده می کنیم.

در این حالت-u  برای این منظور استفاده خواهیم کرد که هر سری محبور به مشخص کردن  origin master نباشیم.

در آخر هم برای گرفتن تغییرات از مخزن نیز باید از pull استفاده کنیم.

git pull origin master

DetectChanges در EF چه کاری انجام می دهد؟

در طی چند پست قصد دارم که به طور دقیق DetectChanges  را در Entity Framework به شما توضیح دهم.

مثال codefirst زیر را در نظر بگیرید:


public class Blog
{
public int Id { get; set; }
public string Title { get; set; }

public virtual ICollection Posts { get; set; }
}

public class Post
{
public int Id { get; set; }
public string Title { get; set; }
public string Content { get; set; }

public int BlogId { get; set; }
public virtual Blog Blog { get; set; }
}

public class AnotherBlogContext : DbContext
{
public DbSet Blogs { get; set; }
public DbSet Posts { get; set; }
}

در کد بالا در هیچ کدام از موجودیت ها کدی برای پیگیری کردن تغییرات وجود ندارد به این معنا که مثلا شما در Title موجودیت Blog چیزی را ندارید که مشخص کند که این پراپرتی تغییر کرده است.

با یک مثال بهتر توضیح خواهم داد.

به کد زیر دقت کنید:

using (var context = new AnotherBlogContext())
{
    var post = context.Posts
                   .Single(p => p.Title == "My First Post");

    post.Title = "My Best Post";
    context.SaveChanges();
}

در کد بالا می یک post را از دیتا بیس استخراج کرده ایم و Title آن را تغییر داده ایم.حال در این حالت زمانی که ما SaveChanges را صدا می زنیم Entity Framework از کجا خواهد فهمید که مدل ما تغییر کرده و باید آن را در دیتابیس ذخیره کند؟

جواب سوال بالا چیزی نیست به جز Snapshot change tracking و DetectChanges.

EF یک snapshot از تمام پراپرتی هایی که ما از دیتابیس کوئری زده ایم،می گیرید و بنابراین در مثال بالا یک snapshot  از موجودیت post با Titleی به مقدار My First Post را تهیه می کند.

در این حالت زمانی که ما SaveChanges را صدا می زنیم متد DetectChanges به صورت خودکار فراخوانی می شود.در این حالت DetectChanges  تمام property های موجودیت های موجود در context را با مقادیر جاری آن ها در snapshot  مقایسه می کند و در صورتی که تغییری حاصل شده بود آن ها در دیتابیس ذخیره می کند.

یکی دیگر از کارهایی که انجام می دهد  “fixup” است که با یک مثال توضیح خواهم داد که کار دقیق آن چیست.

using (var context = new AnotherBlogContext())
{
    context.Blogs.Load();
    var post = context.Posts
                   .Single(p => p.Title == "My First Post");

    post.Title = "My Best Post";
    post.BlogId = 7;
    context.SaveChanges();
}

کد بالا نشان دهنده تغییر Title و همچنین کلید خارجی (FK) است.حال زمانی که DetectChanges  توسط SaveChanges صدا زده می شود کارهای زیر انجام می شود:

  • اطمینان حاصل می کند که کلید خارجی به درستی در پایگاه داده ذخیره شود.
  • navigation property  موجود در Post را با موجودیت جدید Blog بروز رسانی می کند.
  • اطمینان حاصل می کند Collection از Post ها که در موجودیت Blog است نیز به درستی بروزرسانی شده باشد.
  • state  پراپرتی های Blog را نیز بروزرسانی می کند.

همانطور که مشاهده می کنید DetectChanges  کارهای زیادی انجام دهد که می تواند در بسیاری از جاها مفید و در بعضی از موارد کارایی سیستم را پایین بیاورد.

در پست های آینده به طور جزئی تر به آن خواهم پرداخت.

همکاری در مقابل روابط رئیس-مرئوسی

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

همکاری در مقابل روابط رئیس-مرئوسی

همدردی در مقابل همدلی

برن براون، یک مددکار اجتمای و محقق معروف، به خوبی تفاوت این دو کلمه را در ویدیویی آموزشی و طنزآمیز به تصویر کشیده است[۱].

همدردی تلاشی مذبوحانه برای کاهش درد فرد گرفتار است. همدردی معمولاً بیان جملاتی است برای کاهش درد فرد گرفتار، و ایجاد امید در وی. در این تلاش، معمولاً افراد میکوشند شرایط منفی طرف گرفتار را تفسیر مثبت کنند، تا از این طریق نیمه پر لیوان را به وی نشان داده و او را امیدوار سازند. همدردی از این جهت مذبوحانه است که در آن ارتباط قلبی[۲] وجود ندارد. فردی که همدردی میکند، در بطن گرفتاری قرار نداشته و حقیقتاً درک صحیحی از شرایط فرد گرفتار ندارد. نبود ارتباط قلبی و عمیق توسط فرد گرفتار درک میشود، و اغلب منجر به رفتاری منفعلانه در مقابل فرد همدردی کننده میگردد. همدردی زاینده شرایط زیر است:

آب در هاون کوبیدن

یک گوش در و یک گوش دروازه

مثالی از گفتگویی که در فضای همدردی صورت میپذیرد میتواند اینچنین باشد:

برنامه نویس: برآورد مقیاس برخی از کارها واقعاً کار سخت و خسته کننده ایست. گاهاً انرژی انجام این کار را ندارم.

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

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

همدلی نماد قانون طلایی است. قانون طلایی بیان میدارد که “با دیگران آنگونه رفتار کنید که میخواهید با شما رفتار شود”. تفسیر این قانون در بستر توسعه چابک در یک فضای همدلی میتواند این موارد باشد:

۱)      چابکی باید در تمامی سازمان جریان داشته باشد. مدیرانی که خود نمیتوانند در مدیریت خود چابک باشند، چگونه انتظار چابکی در تیم را دارند

۲)      برآورد مقیاس کارها مشکل است. اگر از تیم انتظار انجام آن را دارید، خودتان نیز انجام دهید.

a.       مشکل در برآورد

b.      خطای برآورد

c.       فضای ناشی از خطای برآورد

۳)      جلسات هماهنگی روزانه در سطح مسئولین برگزار گردد

مثالی از گفتگویی که در فضای همدلی صورت میپذیرد میتواند اینچنین باشد:

برنامه نویس: برآورد مقیاس برخی از کارها واقعاً کار سخت و خسته کننده ایست. گاهاً انرژی انجام این کار را ندارم.

عضو تیم مدیریت: بله. این موضوع را کاملاً درک میکنم. به خصوص اگر ماهیت کار ناشناخته باشد. من نیز خسته میشوم.

فضای اعتماد

توسعه چابک به شدت مبتنی بر اعتماد است، و ذات اعتماد دوطرفه بودن آن است. شاید این فضا ناشی از فضای حاکم بر جامعه، خدشه دار میگردد.

مراسمات توسعه چابک[۳]

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

نقطه مشترک تمامی چارچوب های فکر موفق در این است که “رهبران آن چارچوب های فکری و مکاتب، همپای دون پایه ترین اعضای آن جامعه، در برگزاری و حفظ آداب و مراسم میکوشیدند”. اگر در چابک تأکید شده است که “افراد و تعاملات به روال ها ارجحیت دارند”، این تفکر به همراه مناسک و آداب آن باید در تمامی سازمان متبلور شده باشند. به عنوان مثال اگر در سازمانی فردی به دلایلی خاص نمیتواند رأس ساعت ۸ صبح در محل کار حضور داشته باشد، این فرد و درک وی و تلاش برای تعامل و همکاری با وی باید نقشی پر رنگ تر از روال حضور و غیاب شرکت داشته باشد. قطعاً مثال مذکور توجیهی برای غلط انگاشتن روال های لازم برای مدیریت یک مجموعه نیست. تنها تأکیدی است که اصول ارائه شده در مانیفست چابک، اصولی محدود به تیم توسعه نبوده، و نیازمند پوشش کامل سازمانی هستند.

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

فرم و محتوا[۴]

اگر بخواهیم تعریفی ساده از فرم و محتوا ارائه کنیم، میگوییم که محتوا یعنی چیزی که ارائه یا انجام میشود، و فرم یعنی اینکه آن چیز چگونه ارائه یا انجام میشود. در واقع محتوی یعنی قسمت چه و چرا[۵]، اما فرم یعنی قسمت چگونگی[۶].

بزرگترین مشکل مبحث فرم و محتوا این است که محتوا در معرض خطر فراموشی قرار دارد. فرم به دلیل اینکه ملموس، محسوس، و قابل رویت است، معمولاً در کانون توجه قرار میگیرد. اما درک محتوا همواره نیازمند گذر از فرم، و تعمقی قابل توجه است. بهترین استدلالی که برای این منظور میتوان ارائه کرد، مثال میمون ها، موز و نردبان است که اگرچه واقعیت آن مورد شک می باشد[۷]، اما بسیار زیبا از یاد رفتن محتوی (اصل موضوع) و ظاهرگرایی یا صورت گرایی را به تصویر میکشد.

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

مثال دیگر میتواند Daily Standup در Scrum باشد. هدف این جلسه روزانه، ایجاد هماهنگی بین اعضای تیم، درک موقعیت کنونی و رفع مشکلات است. اما خیلی زود مواردی نظیر اینکه این جلسه در کجا، چه زمانی و تحت نظارت چه کسی برگزار شود اولویت یافته و جلسه از حالت هماهنگی به سمت گزارش دهی سوق می یابد.


معرفی مطلب:خطای نجات یافتگان

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

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

ادامه مطلب

Inner join،Full outer join،Left outer join به روایت تصویر

join ها از آن دسته از مطالبی هستند که براحتی فراموش می شوند و  کمی گیج کننده هستند.

در این مطلب سعی کردم یک برداشت آزاد از مطلب Jeff Atwood داشته باشم.

به دو جدول زیر دقت کنید:

joins

حالت های مختلف Join را بین این دو جدول به ترتیب بررسی خواهم کرد:

Inner join:

6a0120a85dcdae970b012877702708970c

دستور:

SELECT * FROM TableA
INNER JOIN TableB
ON TableA.name = TableB.name

خروجی:

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

innerjoin

توضیح:شامل رکوردهایی که در دو جدول باهم برابرند.

Full outer join :

6a0120a85dcdae970b012877702725970c

دستور:

SELECT * FROM TableA
FULL OUTER JOIN TableB
ON TableA.name = TableB.name

خروجی:

Full outer join

توضیح:مطابقت دادن رکوردهای هر جدول به صورت نظیر به نظیر که در صورت عدم تطبیق رکورد متناظر null خواهد بود.

Left outer join:

join

دستور:

SELECT * FROM TableA
LEFT OUTER JOIN TableB
ON TableA.name = TableB.name
WHERE TableB.id IS null

خروجی:

lefttouter join

توضیح:تمامی رکورد ها از Table A را بر می گرداند و سپس با جدول متناظر مطابقت داده می شود و در صورت که رکورد متناظر نبود null بر می گرداند.

Roslyn چیست؟

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

برای ده ها سال  این کار یک کار روتین کامپایلر بود.

به تازگی تکیه ما روی IDE بسیار زیاد شده و امکاناتی مثل :

IntelliSense ،refactoring،intelligent rename ، Find all references وGo to definition به شدت بهره برداری ما را از کد بالا برده .

ما تکیه بیشتری بر روی کد آنالیزر ها برای بهبود بخشیدن به کیفیت کد خود داریم و همچنین code generator ها باعث تولید راحتر برنامه می شوند.

این ابزار روز به روز باهوش تر می شوند و نیاز مند دسترسی بیشتر به اطلاعات کدی دارند که تا پیش از این فقط کامپایلر از آن آگاه بوده.این کارِ هسته اصلی Roslyn است:

باز کردن black box  و اجازه دادن به ابزار و کاربران برای بدست آوردن اطلاعاتی از کامپایلر که درباره کد مااست .

در این حالت به جای اینکه ما یک کد به کامپایلر تحوبل دهیم و یک شی ترجمه شده را دریافت کنیم به وسیله پروژه Roslyn کامپایلر تبدیل به سرویس هایی می شود که از این API ها می توان به منظور انجام یک سری از عملیات که در بالا نام برد ه شد استفاده شوند.

تبدیل شدن کامپایلر ها به سرویس به طور چشمگیری کار نوشتن ابزار و کدهایی که روی meta-programming, code generation  تمرکز دارند را راحت تر خواهد کرد.

پروژه Roslyn در کامپایلر سی شارپ و وی بی code analysis خود را به وسیله یک لایه API به دنیای بیرون منتشر می کند.

roslyn

هر کدام از فاز هایی که در pipeline کامپایلر تا  به قبل یکی بوده اند جدا شده  و در کامپنیت های جدا گانه ای قرار گرفته اند.

در فاز اول سورس شکسته شده و سینتکس آن با توجه به اینکه با چه زبانی است پارس می شود.

در فاز دوم که فاز اعلامیه است ،اعلامیه ها و  metadata های وارد شده تجزیه و تحلیل می شوند.

فاز بعدی فازی است که شناسه ها با symbols تطبیق داده می شوند.

در آخر هم اطلاعات ساخته شده در داخل اسمبلی گنجانده می شوند.

roslynهمانطور که در بالا مشاهده میکنید به ازای هر فازی که توضیج داده شد API متناظرش نیز به وجود آمده که این  API ها هر کدام برای گرفتن یک سری از اطلاعات از کامپایلر در رابطه با کد مفید است . لیست کامل آن را در زیر مشاهده می کنید:

roslyn

نخستین همایش چابک ایران

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

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

امنیت در Strongly named assemblyها

یکی دیگر از فواید Strongly named assembly این است که شما می توانید اطمینان حاصل کنید که یک اسمبلی واقعا توسط انتشار دهنده آن منتشر شده .به طور مثال می توان مطمئن شد که اسمبلی mscorelib.dll توسط خود مایکروسافت انتشار داده شده و در این بین هیچ هکری کد آن را تغییر نداده.

Wallpaper XP Effet Matrix

حالا این فرایند چگونه انجام می شود؟

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

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

پیشنهاد می کنم این مطلب زیبا را برای تکمیل شده بحث بخوانید.

نکات تکمیلی