یه سایت عالی که در هر زمینه کامپیوتر سر فصل آموزشی داره http://www.tutorialspoint.com/tutorialslibrary.htm
Tutorialspoint
Free Tutorials Library - TutorialsPoint
Explore a comprehensive library of free tutorials on programming languages, web development, data science, machine learning, and more at Tutorials Point. Start learning today!
http://www.friendlyarm.com/index.php?route=product/product&product_id=123
👆مشاهده جزئیات این مینی پیسی👆
@SoftwareEngineers
👆مشاهده جزئیات این مینی پیسی👆
@SoftwareEngineers
🍁دوره آموزشی مدیریت پروژه چابک
#Agile
🌟 درس دوازدهم
بله، چابکی یعنی تطبیقی اجرا کردن پروژه. با این حال هر چیزی تبعات خودش رو داره. مثلا میدونیم که امکان تطبیقی پیش رفتن فقط زمانی فراهم میشه که متخصصها تا حدی خودمختار (self-organized) باشن.
از کسایی که تو پروژههای چابک کار میکنن انتظار داریم که تمرکزشون روی کل پروژه باشه، نه روی تخصص خودشون. همه با هم همکاری میکنن و هیچکس نمیتونه بگه که این به من ربطی نداره و کار من چیز دیگهایه. فقط خروجی پروژهس که اهمیت داره و نه کارهایی که تک تک افراد انجام میدن.
مدیرای شرکت هم باید درک مناسبی از چابکی داشته باشن و برای تیم مشکل ایجاد نکنن. قدمهای تدریجی تولید محصول رو یادتونه؟ معمولا تو همه روشها گستره کاری که برای اون محدوده زمانی انتخاب میشه قابل تغییر نیست. دلیلش اینه که در غیر این صورت واقعا آدمها نمیتونن تمرکز کنن و کاری رو پیش ببرن. پس مدیرای شرکت هم باید به این روند احترام بذارن. مثلا مدیر عامل اجازه نداره به تیم بگه چیزی رو تو اون قدم دو هفتهای تغییر بده!
کارفرما هم باید چابکی رو درک کنه. باید با تیم همکاری کنه، نباید ازشون چیزهایی بخواد که متعینه و تو پروژههای تطبیقی وجود نداره (مثلا طراحی اولیه) و نباید قراردادهای قیمت ثابت که مبتنی بر تعریف اولیه گستره هستن رو بهشون تحمیل کنه.
پس جنبه فرهنگی خیلی مهمه. فردا درباره مانیفست اجایل صحبت میکنیم که ماجراهای فرهنگی رو تا حدی مشخص میکنه. تو این فاصله شما هم به این موضوع فکر کنین و ببینین چه چیزهایی به نظرتون لازمه.
این دوره ادامه دارد.....
#Agile
🌟 درس دوازدهم
بله، چابکی یعنی تطبیقی اجرا کردن پروژه. با این حال هر چیزی تبعات خودش رو داره. مثلا میدونیم که امکان تطبیقی پیش رفتن فقط زمانی فراهم میشه که متخصصها تا حدی خودمختار (self-organized) باشن.
از کسایی که تو پروژههای چابک کار میکنن انتظار داریم که تمرکزشون روی کل پروژه باشه، نه روی تخصص خودشون. همه با هم همکاری میکنن و هیچکس نمیتونه بگه که این به من ربطی نداره و کار من چیز دیگهایه. فقط خروجی پروژهس که اهمیت داره و نه کارهایی که تک تک افراد انجام میدن.
مدیرای شرکت هم باید درک مناسبی از چابکی داشته باشن و برای تیم مشکل ایجاد نکنن. قدمهای تدریجی تولید محصول رو یادتونه؟ معمولا تو همه روشها گستره کاری که برای اون محدوده زمانی انتخاب میشه قابل تغییر نیست. دلیلش اینه که در غیر این صورت واقعا آدمها نمیتونن تمرکز کنن و کاری رو پیش ببرن. پس مدیرای شرکت هم باید به این روند احترام بذارن. مثلا مدیر عامل اجازه نداره به تیم بگه چیزی رو تو اون قدم دو هفتهای تغییر بده!
کارفرما هم باید چابکی رو درک کنه. باید با تیم همکاری کنه، نباید ازشون چیزهایی بخواد که متعینه و تو پروژههای تطبیقی وجود نداره (مثلا طراحی اولیه) و نباید قراردادهای قیمت ثابت که مبتنی بر تعریف اولیه گستره هستن رو بهشون تحمیل کنه.
پس جنبه فرهنگی خیلی مهمه. فردا درباره مانیفست اجایل صحبت میکنیم که ماجراهای فرهنگی رو تا حدی مشخص میکنه. تو این فاصله شما هم به این موضوع فکر کنین و ببینین چه چیزهایی به نظرتون لازمه.
این دوره ادامه دارد.....
🍁دوره آموزشی مدیریت پروژه چابک
#Agile
🌟 درس سیزدهم
عنوان این درس شاید یه کم عجیب باشه. معمولا واژه کمابیش نامانوس «مانیفست» رو بیشتر تو متون سیاسی و گاهی اجتماعی میبینیم. واقعیت اینه که روشهای چابک خیلی هم جدید نیستن. اصلا به نظر من نمیشه تصور کرد که بشر تا همین چند سال پیش به نظرش نیومده پروژههاش رو اینطوری اجرا کنه. این روشها همیشه بودن، ولی به خاطر طبیعت پروژههایی که در گذشته رایج بودن چندان جایی برای رشد نداشتن. با زیاد شدن پروژههای نرمافزاری، نیاز به این روشها بیشتر شد و کم کم افراد مختلف شروع کردن به استفاده از اون.
آدمهای مختلفی به موازات روی روشهای چابک متفاوت کار میکردن، بدون اینکه این مفهوم رسمیت چندانی داشته باشه. در نهایت ۱۷ نفر از پیشروهاشون سال ۲۰۰۱ دور هم جمع میشن و بر اساس اشتراکهایی که تو روشهاشون بوده یه «بیانیه» صادر میکنن. اسمش رو هم میذارن Agile Manifesto (بیانیه چابک).
این بیانیه کلیات این روشها رو توضیح میده و میگه که بر اساس تجربهشون به این نتیجه رسیدن که باید برای چهار عامل ارزش قایل باشن و بهش توجه کنن:
افراد و تعاملهاشون، بیشتر از فرآیندها و ابزارها
نرمافزار در حال کار، بیشتر از اسناد مفصل
مشارکت کارفرما، بیشتر از مذاکرات قراردادی
واکنش به تغییر، بیشتر از اجرای برنامه
کل بیانیه همینه. البته تاکید هم میکنه که بیانیه به این معنی نیست که برای عوامل سمت چپ ارزش قایل نیستن؛ معنیش اینه که از نظرشون سمت راستیها خیلی مهمترن.خوب، تو درسهای بعدی درباره این ارزشها و معنایی که دارن با هم صحبت میکنیم. الان روی ارزش اول دقیق بشین و ببینین به نظرتون دقیقا معنیش چیه و اگه واقعا آدم اینطور فکر کنه چه تغییری تو پروژههاش به وجود میاد. پروژههای خودتون رو هم مرور کنین و ببینین توش بیشتر به کدوم جنبه اهمیت داده شده.
این دوره ادامه دارد.....
#Agile
🌟 درس سیزدهم
عنوان این درس شاید یه کم عجیب باشه. معمولا واژه کمابیش نامانوس «مانیفست» رو بیشتر تو متون سیاسی و گاهی اجتماعی میبینیم. واقعیت اینه که روشهای چابک خیلی هم جدید نیستن. اصلا به نظر من نمیشه تصور کرد که بشر تا همین چند سال پیش به نظرش نیومده پروژههاش رو اینطوری اجرا کنه. این روشها همیشه بودن، ولی به خاطر طبیعت پروژههایی که در گذشته رایج بودن چندان جایی برای رشد نداشتن. با زیاد شدن پروژههای نرمافزاری، نیاز به این روشها بیشتر شد و کم کم افراد مختلف شروع کردن به استفاده از اون.
آدمهای مختلفی به موازات روی روشهای چابک متفاوت کار میکردن، بدون اینکه این مفهوم رسمیت چندانی داشته باشه. در نهایت ۱۷ نفر از پیشروهاشون سال ۲۰۰۱ دور هم جمع میشن و بر اساس اشتراکهایی که تو روشهاشون بوده یه «بیانیه» صادر میکنن. اسمش رو هم میذارن Agile Manifesto (بیانیه چابک).
این بیانیه کلیات این روشها رو توضیح میده و میگه که بر اساس تجربهشون به این نتیجه رسیدن که باید برای چهار عامل ارزش قایل باشن و بهش توجه کنن:
افراد و تعاملهاشون، بیشتر از فرآیندها و ابزارها
نرمافزار در حال کار، بیشتر از اسناد مفصل
مشارکت کارفرما، بیشتر از مذاکرات قراردادی
واکنش به تغییر، بیشتر از اجرای برنامه
کل بیانیه همینه. البته تاکید هم میکنه که بیانیه به این معنی نیست که برای عوامل سمت چپ ارزش قایل نیستن؛ معنیش اینه که از نظرشون سمت راستیها خیلی مهمترن.خوب، تو درسهای بعدی درباره این ارزشها و معنایی که دارن با هم صحبت میکنیم. الان روی ارزش اول دقیق بشین و ببینین به نظرتون دقیقا معنیش چیه و اگه واقعا آدم اینطور فکر کنه چه تغییری تو پروژههاش به وجود میاد. پروژههای خودتون رو هم مرور کنین و ببینین توش بیشتر به کدوم جنبه اهمیت داده شده.
این دوره ادامه دارد.....
لاگ کردن خطاها و رویدادها با Elmah http://www.asp.net/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/logging-error-details-with-elmah-cs
The Official Microsoft ASP.NET Site
Logging Error Details with ELMAH (C#)
Error Logging Modules And Handlers (ELMAH) offers another approach to logging runtime errors in a production environment. ELMAH is a free, open source error logging library that includes features l...
@SoftwareEngineers
چند وقتی هست که مایکروسافت در راستای تعهدات اش به جامعه توسعه دهندگانِ دات نت، طرحی را تحت عنوان Visual Studio Dev Essentials اجرا کرده است. عضویت در این طرح رایگان می باشد و پس از ثبت نام می توانید از بسیازی از خدمات مایکروسافت و باقی شرکت ها به طور رایگان استفاده کنید. مثلا می توانید شش ماه دسترسی رایگان به تمامی مطالب PluralSight داشته باشید. همچنین از برخی سرویس های آژور و خدمات آموزشی مایکروسافت، Xamarin و ... بهره مند خواهید شد.
با مراجعه به آدرس زیر در طرح فوق ثبت نام کنید:
https://www.visualstudio.com/en-us/products/visual-studio-dev-essentials-vs.aspx
چند وقتی هست که مایکروسافت در راستای تعهدات اش به جامعه توسعه دهندگانِ دات نت، طرحی را تحت عنوان Visual Studio Dev Essentials اجرا کرده است. عضویت در این طرح رایگان می باشد و پس از ثبت نام می توانید از بسیازی از خدمات مایکروسافت و باقی شرکت ها به طور رایگان استفاده کنید. مثلا می توانید شش ماه دسترسی رایگان به تمامی مطالب PluralSight داشته باشید. همچنین از برخی سرویس های آژور و خدمات آموزشی مایکروسافت، Xamarin و ... بهره مند خواهید شد.
با مراجعه به آدرس زیر در طرح فوق ثبت نام کنید:
https://www.visualstudio.com/en-us/products/visual-studio-dev-essentials-vs.aspx
Visual Studio
Visual Studio Dev Essentials - Visual Studio
Everything you need to build and deploy your app on any platform including tools, services, training, and more. Join our free developer program.
لینک کانال جهت اشتراک گذاری: https://telegram.me/SoftwareEngineers
Telegram
Iranian Software Engineers
Admin: @VahidDotNet
انجمن علمی دانشکده کامپیوتر دانشگاه خواجه نصیر برگزار میکند.
کارگاههای دو روزه رایگان در تاریخ ۲۳ و ۳۰ اردیبهشت ۱۳۹۵
آدرس دوره جهت ثبت نام:
http://bit.ly/1WctGbI
@SoftwareEngineers
کارگاههای دو روزه رایگان در تاریخ ۲۳ و ۳۰ اردیبهشت ۱۳۹۵
آدرس دوره جهت ثبت نام:
http://bit.ly/1WctGbI
@SoftwareEngineers
جشنواره لینوکس و نرمافزار های متن باز امیرکبیر
تخفیف ۴۰ درصدی برای دانشجویان با کد تخفیف : STU
جهت کسب اطلاعات بیشتر و ثبت نام به آدرس زیر مراجعه کنید.
http://bit.ly/1YeorpQ
@SoftwareEngineers
تخفیف ۴۰ درصدی برای دانشجویان با کد تخفیف : STU
جهت کسب اطلاعات بیشتر و ثبت نام به آدرس زیر مراجعه کنید.
http://bit.ly/1YeorpQ
@SoftwareEngineers
🍁دوره آموزشی مدیریت پروژه چابک
#Agile
🌟 درس چهاردهم
خوب، تو درس قبل بیانیه چابک رو به سرعت مرور کردیم. حالا تو این درس میریم سراغ اولین ارزش بیانیه: اینکه برای افراد و تعاملهاشون بیشتر از فرآیندها و ابزارها ارزش قایلیم. اسم تیلور (taylor) تا حالا به گوشتون خورده؟ تیلور پیشروی طرز فکری بود که از سالهای ۱۸۸۰ شکل گرفت و بهش میگن مدیریت علمی. این طرز فکر که بعد از اون تقریبا با کمی پس و پیش طرز فکر مدیریتی «درست» به حساب اومد عمدتا مبتنی بر فرآیندها و ابزارهاس و از طریق اونها محصول و نتیجه رو بهبود میداد.
روشها خیلی عالی بودن و تمام زحمتهایی که کشیده بودن هنوز هم اثرهای مثبتش برای ما وجود داره. با این حال الان اوضاع خیلی فرق کرده. خیلی از کارهای ساده و تکراری که اون موقع به عهده آدمها بود رو الان ماشینها انجام میدن و چیزهایی که برای آدمها باقی مونده مجموعا خیلی پیچیدهتر و خلاقانهتر از اون زمانه. به همین خاطر تمرکز بیش از اندازه روی فرآیندها و ابزارها نمیتونه مشکلاتمون رو به اندازه کافی حل کنه. وقتی تمرکز زیاد از حد روی ابزار و فرآیند باشه، آدمها به چشم قطعههای یه ماشین دیده میشن. ماشین ایدهآلی که اگه یکی از قطعههاش مشکل داشته باشه عوض میکنیمش و درست میشه.
الان متوجه شدیم که مشکلهای اصلی تو فرآیندها و ابزارها نیست، تو آدمها و تعاملهاشونه. به همین خاطر هم باید برای رفع مشکلات کارمون رو از اصلاح اون قسمت شروع کنیم. شما هم تو پروژهها و شرکتهاتون احساس میکنین که تمرکز اکثر مدیرها روی فرآیندهاس و به سادهترین مسایلی که به تعاملهای بین آدمها مربوط میشه توجه نمیکنن؟ هرچقدر هم که فرآیندها رو اصلاح میکنن مشکل حل نمیشه، ولی باز هم حل نشدنش رو میندازن گردن فرآیندها و ابزارها و سعی میکنن با بهتر کردنشون به نتیجه برسن. معمولا هم نمیرسن.
بگذریم. این اولین ارزش بیانیه چابک بود. تو فضاهای چابک فرآیندها و ابزارهامون خیلی ساده هستن و تمام تمرکزمون روی آدمها و ارتباطهاشونه. حتی ترجیح میدیم از نرمافزار برای کنترل پروژههامون استفاده نکنیم، چون بیدلیل کارها رو تو این فضا پیچیده میکنه. یه وایتبرد برای کنترل موثر پروژه کافیه.
فردا درباره دومین ارزش صحبت میکنیم: اینکه برای نرمافزار در حال کار بیشتر از اسناد مفصل و جامع ارزش قایلیم. اگه از جملهبندیش زیاد راضی نیستین به جای نرمافزار بذارین «محصول». به این فکر کنین که تبعات این بخش از بیانیه چجوریه و چطوری میتونین با پروژههاتون تطبیقشون بدین.
#Agile
🌟 درس چهاردهم
خوب، تو درس قبل بیانیه چابک رو به سرعت مرور کردیم. حالا تو این درس میریم سراغ اولین ارزش بیانیه: اینکه برای افراد و تعاملهاشون بیشتر از فرآیندها و ابزارها ارزش قایلیم. اسم تیلور (taylor) تا حالا به گوشتون خورده؟ تیلور پیشروی طرز فکری بود که از سالهای ۱۸۸۰ شکل گرفت و بهش میگن مدیریت علمی. این طرز فکر که بعد از اون تقریبا با کمی پس و پیش طرز فکر مدیریتی «درست» به حساب اومد عمدتا مبتنی بر فرآیندها و ابزارهاس و از طریق اونها محصول و نتیجه رو بهبود میداد.
روشها خیلی عالی بودن و تمام زحمتهایی که کشیده بودن هنوز هم اثرهای مثبتش برای ما وجود داره. با این حال الان اوضاع خیلی فرق کرده. خیلی از کارهای ساده و تکراری که اون موقع به عهده آدمها بود رو الان ماشینها انجام میدن و چیزهایی که برای آدمها باقی مونده مجموعا خیلی پیچیدهتر و خلاقانهتر از اون زمانه. به همین خاطر تمرکز بیش از اندازه روی فرآیندها و ابزارها نمیتونه مشکلاتمون رو به اندازه کافی حل کنه. وقتی تمرکز زیاد از حد روی ابزار و فرآیند باشه، آدمها به چشم قطعههای یه ماشین دیده میشن. ماشین ایدهآلی که اگه یکی از قطعههاش مشکل داشته باشه عوض میکنیمش و درست میشه.
الان متوجه شدیم که مشکلهای اصلی تو فرآیندها و ابزارها نیست، تو آدمها و تعاملهاشونه. به همین خاطر هم باید برای رفع مشکلات کارمون رو از اصلاح اون قسمت شروع کنیم. شما هم تو پروژهها و شرکتهاتون احساس میکنین که تمرکز اکثر مدیرها روی فرآیندهاس و به سادهترین مسایلی که به تعاملهای بین آدمها مربوط میشه توجه نمیکنن؟ هرچقدر هم که فرآیندها رو اصلاح میکنن مشکل حل نمیشه، ولی باز هم حل نشدنش رو میندازن گردن فرآیندها و ابزارها و سعی میکنن با بهتر کردنشون به نتیجه برسن. معمولا هم نمیرسن.
بگذریم. این اولین ارزش بیانیه چابک بود. تو فضاهای چابک فرآیندها و ابزارهامون خیلی ساده هستن و تمام تمرکزمون روی آدمها و ارتباطهاشونه. حتی ترجیح میدیم از نرمافزار برای کنترل پروژههامون استفاده نکنیم، چون بیدلیل کارها رو تو این فضا پیچیده میکنه. یه وایتبرد برای کنترل موثر پروژه کافیه.
فردا درباره دومین ارزش صحبت میکنیم: اینکه برای نرمافزار در حال کار بیشتر از اسناد مفصل و جامع ارزش قایلیم. اگه از جملهبندیش زیاد راضی نیستین به جای نرمافزار بذارین «محصول». به این فکر کنین که تبعات این بخش از بیانیه چجوریه و چطوری میتونین با پروژههاتون تطبیقشون بدین.
🍁دوره آموزشی مدیریت پروژه چابک
#Agile
🌟 درس پانزدهم
به ارزش دوم فکر کردین؟ به نظرم ماجراییه که همه دایما باهاش سر و کار داریم. البته ممکنه تو نگاه اول خیلی واضح نباشه. دومین قسمت بیانیه اینه که برای نرمافزار در حال کار خیلی بیشتر از اسناد مفصل و جامع ارزش قایلیم. کسایی که بیانیه رو تهیه میکردن همه تو حوزه نرمافزار کار میکردن و هنوز هم مهمترین استفاده روشهای چابک تو نرمافزاره. با این حال به اون محدود نمیشه. به همین خاطر میتونیم ارزش دوم رو اینطوری بازنویسی کنیم: برای محصول کاربردی بیشتر از اسناد ارزش قایلیم.
ماجرا اینه که تو روشهای سنتی از انواع و اقسام اسناد برای تعامل با کارفرما و حتی داخل تیم استفاده میکنیم. مثلا سندی در مورد گستره پروژه تهیه میکنیم و تایید کارفرما رو میگیریم، به این خیال که الان هر دو تصور مشترکی از موضوع داریم. همون رو مبنای پروژه قرار میدیم و محصول نهایی رو میسازیم، ولی بعد میبینیم که کارفرما ازش راضی نیست، چون برداشتی که از سند داشته با برداشت ما متفاوت بوده. به همین خاطره که به جای اسناد از خود محصول استفاده میکنیم. البته منظورم محصول نهایی نیست، اجزای قابل استفاده محصول نهایی، انواع مدلها و چیزهایی از اون دسته. چیزهایی که کارفرما میتونه باهاشون کار کنه و ببینه همونی که میخواسته هست یا نه و بر اون اساس بازخورد بده. از بازخوردش برای اصلاح روندمون در ادامه پروژه استفاده میکنیم. قطعا مستندسازی تو پروژه خیلی مهمه، ولی کاربردهای خاص خودش رو داره و هیچوقت نباید فکر کنیم بر هر درد بیدرمان دواست و هروقت به مشکلی خوردیم یه مرحله مستندسازیهامون رو پیچیدهتر و کسالتآورتر کنیم. قبل از اینکه این رو تموم کنم این نکته رو هم بگم که ماجرای شیوه تولید محصول و مدیریت گستره چیزیه که تو درسهای بعدیمون خیلی مفصلتر و دقیقتر بررسیش میکنیم.
خوب، فردا درباره ارزش سوم صحبت میکنیم: اینکه برای مشارکت مشتری بیشتر ارزش قایلیم تا مذاکرات قراردادی. مطمئنم که انواع و اقسام خاطرات داره تو ذهنتون مرور میشه. احتمالا اون شرایطی رو هم به یاد آوردین که کارفرما و پیمانکار مثل دوتا دشمن با هم برخورد میکنن، انگار نه انگار که هدف مشترکی دارن (تولید محصول پروژه). خوب، لطفا به مرور خاطراتتون ادامه بدین و ببینین چه جنبههای دیگهای ازش به نظرتون میاد، تا فردا دربارهش با هم صحبت کنیم.
این دوره ادامه دارد.....
#Agile
🌟 درس پانزدهم
به ارزش دوم فکر کردین؟ به نظرم ماجراییه که همه دایما باهاش سر و کار داریم. البته ممکنه تو نگاه اول خیلی واضح نباشه. دومین قسمت بیانیه اینه که برای نرمافزار در حال کار خیلی بیشتر از اسناد مفصل و جامع ارزش قایلیم. کسایی که بیانیه رو تهیه میکردن همه تو حوزه نرمافزار کار میکردن و هنوز هم مهمترین استفاده روشهای چابک تو نرمافزاره. با این حال به اون محدود نمیشه. به همین خاطر میتونیم ارزش دوم رو اینطوری بازنویسی کنیم: برای محصول کاربردی بیشتر از اسناد ارزش قایلیم.
ماجرا اینه که تو روشهای سنتی از انواع و اقسام اسناد برای تعامل با کارفرما و حتی داخل تیم استفاده میکنیم. مثلا سندی در مورد گستره پروژه تهیه میکنیم و تایید کارفرما رو میگیریم، به این خیال که الان هر دو تصور مشترکی از موضوع داریم. همون رو مبنای پروژه قرار میدیم و محصول نهایی رو میسازیم، ولی بعد میبینیم که کارفرما ازش راضی نیست، چون برداشتی که از سند داشته با برداشت ما متفاوت بوده. به همین خاطره که به جای اسناد از خود محصول استفاده میکنیم. البته منظورم محصول نهایی نیست، اجزای قابل استفاده محصول نهایی، انواع مدلها و چیزهایی از اون دسته. چیزهایی که کارفرما میتونه باهاشون کار کنه و ببینه همونی که میخواسته هست یا نه و بر اون اساس بازخورد بده. از بازخوردش برای اصلاح روندمون در ادامه پروژه استفاده میکنیم. قطعا مستندسازی تو پروژه خیلی مهمه، ولی کاربردهای خاص خودش رو داره و هیچوقت نباید فکر کنیم بر هر درد بیدرمان دواست و هروقت به مشکلی خوردیم یه مرحله مستندسازیهامون رو پیچیدهتر و کسالتآورتر کنیم. قبل از اینکه این رو تموم کنم این نکته رو هم بگم که ماجرای شیوه تولید محصول و مدیریت گستره چیزیه که تو درسهای بعدیمون خیلی مفصلتر و دقیقتر بررسیش میکنیم.
خوب، فردا درباره ارزش سوم صحبت میکنیم: اینکه برای مشارکت مشتری بیشتر ارزش قایلیم تا مذاکرات قراردادی. مطمئنم که انواع و اقسام خاطرات داره تو ذهنتون مرور میشه. احتمالا اون شرایطی رو هم به یاد آوردین که کارفرما و پیمانکار مثل دوتا دشمن با هم برخورد میکنن، انگار نه انگار که هدف مشترکی دارن (تولید محصول پروژه). خوب، لطفا به مرور خاطراتتون ادامه بدین و ببینین چه جنبههای دیگهای ازش به نظرتون میاد، تا فردا دربارهش با هم صحبت کنیم.
این دوره ادامه دارد.....
@SoftwareEngineers
یک لپ تاپ هم برای برنامه نویس های که میخوان سرور با خودشان حمل کنند معرفی کنیم.
از 1300 دلار شروع میشه تا نزدیک 5000 دلار که میشه سی پی یو Xeon و رم 64 و 3 تا هارد با امکان رید 0 و 1، و ...براش سفارش داد
http://shop.lenovo.com/us/en/laptops/thinkpad/p-series/p50/#SYSTEM
یک لپ تاپ هم برای برنامه نویس های که میخوان سرور با خودشان حمل کنند معرفی کنیم.
از 1300 دلار شروع میشه تا نزدیک 5000 دلار که میشه سی پی یو Xeon و رم 64 و 3 تا هارد با امکان رید 0 و 1، و ...براش سفارش داد
http://shop.lenovo.com/us/en/laptops/thinkpad/p-series/p50/#SYSTEM
Lenovo
ThinkPad P50 | Mobile Workstation |
15.6" mobile workstation with enterprise-class features for the most demanding mobile workstation use, including Intel Xeon processors, professional-caliber displays, ISV certifications, & optional touchscreen.