@SoftwareEngineers
چند وقتی هست که مایکروسافت در راستای تعهدات اش به جامعه توسعه دهندگانِ دات نت، طرحی را تحت عنوان Visual Studio Dev Essentials اجرا کرده است. عضویت در این طرح رایگان می باشد و پس از ثبت نام می توانید از بسیازی از خدمات مایکروسافت و باقی شرکت ها به طور رایگان استفاده کنید. مثلا می توانید شش ماه دسترسی رایگان به تمامی مطالب PluralSight داشته باشید. همچنین از برخی سرویس های آژور و خدمات آموزشی مایکروسافت، Xamarin و ... بهره مند خواهید شد.

با مراجعه به آدرس زیر در طرح فوق ثبت نام کنید:
https://www.visualstudio.com/en-us/products/visual-studio-dev-essentials-vs.aspx

لینک کانال جهت اشتراک گذاری: https://telegram.me/SoftwareEngineers

انجمن علمی دانشکده کامپیوتر دانشگاه خواجه نصیر برگزار می‌کند.
کارگاه‌های دو روزه رایگان در تاریخ ۲۳ و ۳۰ اردیبهشت ۱۳۹۵
آدرس دوره جهت ثبت نام:
http://bit.ly/1WctGbI


@SoftwareEngineers

جشنواره لینوکس و نرم‌افزار های متن باز امیرکبیر
تخفیف ۴۰ درصدی برای دانشجویان با کد تخفیف : STU
جهت کسب اطلاعات بیشتر و ثبت نام به آدرس زیر مراجعه کنید.
http://bit.ly/1YeorpQ

@SoftwareEngineers

🍁دوره آموزشی مدیریت پروژه چابک
#Agile
🌟 درس چهاردهم

خوب، تو درس قبل بیانیه چابک رو به سرعت مرور کردیم. حالا تو این درس می‌ریم سراغ اولین ارزش بیانیه: این‌که برای افراد و تعامل‌هاشون بیشتر از فرآیندها و ابزارها ارزش قایلیم. اسم تیلور (taylor) تا حالا به گوشتون خورده؟ تیلور پیشروی طرز فکری بود که از سال‌های ۱۸۸۰ شکل گرفت و بهش می‌گن مدیریت علمی. این طرز فکر که بعد از اون تقریبا با کمی پس و پیش طرز فکر مدیریتی «درست» به حساب اومد عمدتا مبتنی بر فرآیندها و ابزارهاس و از طریق اون‌ها محصول و نتیجه رو بهبود می‌داد.
روش‌ها خیلی عالی بودن و تمام زحمت‌هایی که کشیده بودن هنوز هم اثرهای مثبتش برای ما وجود داره. با این حال الان اوضاع خیلی فرق کرده. خیلی از کارهای ساده و تکراری که اون موقع به عهده آدم‌ها بود رو الان ماشین‌ها انجام می‌دن و چیزهایی که برای آدم‌ها باقی مونده مجموعا خیلی پیچیده‌تر و خلاقانه‌تر از اون زمانه. به همین خاطر تمرکز بیش از اندازه روی فرآیندها و ابزارها نمی‌تونه مشکلاتمون رو به اندازه کافی حل کنه. وقتی تمرکز زیاد از حد روی ابزار و فرآیند باشه، آدم‌ها به چشم قطعه‌های یه ماشین دیده می‌شن. ماشین ایده‌آلی که اگه یکی از قطعه‌هاش مشکل داشته باشه عوض می‌کنیمش و درست می‌شه.
الان متوجه شدیم که مشکل‌های اصلی تو فرآیندها و ابزارها نیست، تو آدم‌ها و تعامل‌هاشونه. به همین خاطر هم باید برای رفع مشکلات کارمون رو از اصلاح اون قسمت شروع کنیم. شما هم تو پروژه‌ها و شرکت‌هاتون احساس می‌کنین که تمرکز اکثر مدیرها روی فرآیندهاس و به ساده‌ترین مسایلی که به تعامل‌های بین آدم‌ها مربوط می‌شه توجه نمی‌کنن؟ هرچقدر هم که فرآیندها رو اصلاح می‌کنن مشکل حل نمی‌شه، ولی باز هم حل نشدنش رو می‌ندازن گردن فرآیندها و ابزارها و سعی می‌کنن با بهتر کردنشون به نتیجه برسن. معمولا هم نمی‌رسن.
بگذریم. این اولین ارزش بیانیه چابک بود. تو فضاهای چابک فرآیندها و ابزارهامون خیلی ساده هستن و تمام تمرکزمون روی آدم‌ها و ارتباط‌هاشونه. حتی ترجیح می‌دیم از نرم‌افزار برای کنترل پروژه‌هامون استفاده نکنیم، چون بی‌دلیل کارها رو تو این فضا پیچیده می‌کنه. یه وایت‌برد برای کنترل موثر پروژه کافیه.
فردا درباره دومین ارزش صحبت می‌کنیم:‌ این‌که برای نرم‌افزار در حال کار بیشتر از اسناد مفصل و جامع ارزش قایلیم. اگه از جمله‌بندیش زیاد راضی نیستین به جای نرم‌افزار بذارین «محصول». به این فکر کنین که تبعات این بخش از بیانیه چجوریه و چطوری می‌تونین با پروژه‌هاتون تطبیقشون بدین.

🍁دوره آموزشی مدیریت پروژه چابک

#Agile
🌟 درس پانزدهم

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

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

این دوره ادامه دارد.....

@SoftwareEngineers

یک لپ تاپ هم برای برنامه نویس های که میخوان سرور با خودشان حمل کنند معرفی کنیم.
از 1300 دلار شروع میشه تا نزدیک 5000 دلار که میشه سی پی یو Xeon و رم 64 و 3 تا هارد با امکان رید 0 و 1، و ...براش سفارش داد

http://shop.lenovo.com/us/en/laptops/thinkpad/p-series/p50/#SYSTEM

توسط cnet تخمین زده شده بود که استفاده از یک رنگ آبی مخصوص در bing موجب افزایش 80 میلیون دلاری درآمد سالیانه bing شد


@SoftwareEngineers

نرم افزار سلفی مایکروسافت برای آیفون

@SoftwareEngineers

👆راهنمای سریع Regular Expression 👆

@SoftwareEngineers

👆 راهنمای سریع HTML 5 👆

@SoftwareEngineers

👆 راهنمای سریع CSS 3 👆

@SoftwareEngineers