Forwarded from فلسفه دیزاین
«پراگرسیو وباپ» یا PWA چیست؟
تکنولوژی PWA یا Progressive Web Apps یکی از پرطرفدارترین تغییرات تکنولوژی در وب است که در دنیای تکنولوژی وب برای خود امپراتوری بینظیری بوجود آورده است. این موضوع تعجب آور نیست زیرا پراگرسیو وب اپها توانستهاند رویای نصب تعداد زیادی برنامه بر روی گوشی کاربران را متصور سازند.
عبارت PWA اصطلاحی است که برای نشان دادن یک روش جدید توسعه نرمافزارها استفاده میشود. در این روش تلاش توسعه دهندگان در جهت ترکیب ویژگیهای مرورگرهای مدرن با مزایای استفاده از تلفن همراه میباشد. پراگرسیو وب اپها بر خلاف برنامههای سنتی، ترکیبی از صفحات وب و یک برنامه تلفن همراه میباشند.
از یک پراگرسیو وب اپ میتوان بهعنوان یک صفحه وب معمولی در یک مرورگر استفاده نمود و یا اگر کاربر تمایل داشته باشد میتواند با اضافه کردن کلید میانبر آن پراگرسیو وباپ به صفحه اصلی گوشی خود از آن استفاده نماید. در این حالت حتی میتوان کنترلهای UI مرورگر را پنهان کرده و برای کاربر حس تجربه کار با یک برنامه مستقل را ایجاد نمود.
از زمان معرفی PWAها، شرکتهای زیادی در استفاده از آنها پیش قدم شدهاند. مثلا توییتر PWA را بکار برد تا بتواند با بهره گیری از امکانات آن نسخه پیشفرض دسکتاپ خود را بازطراحی کند.
پراگرسیو وب اپها به دو دسته کلی ذیل تقسیم میشوند:
۱- وب سایتهایی که مانند اپلیکیشنها رفتار میکنند.
۲- اپلیکیشنهایی که تحت فضای وب هستند.
بر اساس توضیحات گوگل، انواع پراگرسیو وب اپها دارای ویژگیهای مشترکی نظیر قابلاطمینانبودن (Reliable)، سرعت عملداشتن (Fast) و ترغیبکنندگی (Engaging) هستند. بطور کلی تمرکز همه پراگرسیو وباپها بر کاربرد آسانتر برنامه و حذف هرگونه اصطکاکی است که جلوی سریعتر رسیدن کاربران به آنچه از برنامه میخواهند را میگیرد. ایده PWA موفق به پرکردن شکاف میان فضای وب و اپلیکیشنها شدهاست. با توجه به روشنبودن آینده پیشروی PWA و مزیتهای کاربردی آن، بنظر میرسد تمرکز بر ایننوع از برنامهها یکی از مباحث جذاب مورد توجه طراحان و توسعه دهندهگان دنیای وب میباشد.
نویسنده مقاله امروز که مطالعه آن را به شما پیشنهاد میکنم، به توضیح مفهوم Progressive Web App پرداخته و ویژگیهای آن را بررسی میکند.
مقاله امروز را از دست ندهید:
https://www.invisionapp.com/inside-design/whats-a-pwa/
(زمان حدودی مطالعه، ۱۱ دقیقه)
نویسنده: نیما حکیم رابط
#معرفی_مفاهیم #تکنولوژی #PWA
@Dexign فلسفه دیزاین
ـــــــــ
تکنولوژی PWA یا Progressive Web Apps یکی از پرطرفدارترین تغییرات تکنولوژی در وب است که در دنیای تکنولوژی وب برای خود امپراتوری بینظیری بوجود آورده است. این موضوع تعجب آور نیست زیرا پراگرسیو وب اپها توانستهاند رویای نصب تعداد زیادی برنامه بر روی گوشی کاربران را متصور سازند.
عبارت PWA اصطلاحی است که برای نشان دادن یک روش جدید توسعه نرمافزارها استفاده میشود. در این روش تلاش توسعه دهندگان در جهت ترکیب ویژگیهای مرورگرهای مدرن با مزایای استفاده از تلفن همراه میباشد. پراگرسیو وب اپها بر خلاف برنامههای سنتی، ترکیبی از صفحات وب و یک برنامه تلفن همراه میباشند.
از یک پراگرسیو وب اپ میتوان بهعنوان یک صفحه وب معمولی در یک مرورگر استفاده نمود و یا اگر کاربر تمایل داشته باشد میتواند با اضافه کردن کلید میانبر آن پراگرسیو وباپ به صفحه اصلی گوشی خود از آن استفاده نماید. در این حالت حتی میتوان کنترلهای UI مرورگر را پنهان کرده و برای کاربر حس تجربه کار با یک برنامه مستقل را ایجاد نمود.
از زمان معرفی PWAها، شرکتهای زیادی در استفاده از آنها پیش قدم شدهاند. مثلا توییتر PWA را بکار برد تا بتواند با بهره گیری از امکانات آن نسخه پیشفرض دسکتاپ خود را بازطراحی کند.
پراگرسیو وب اپها به دو دسته کلی ذیل تقسیم میشوند:
۱- وب سایتهایی که مانند اپلیکیشنها رفتار میکنند.
۲- اپلیکیشنهایی که تحت فضای وب هستند.
بر اساس توضیحات گوگل، انواع پراگرسیو وب اپها دارای ویژگیهای مشترکی نظیر قابلاطمینانبودن (Reliable)، سرعت عملداشتن (Fast) و ترغیبکنندگی (Engaging) هستند. بطور کلی تمرکز همه پراگرسیو وباپها بر کاربرد آسانتر برنامه و حذف هرگونه اصطکاکی است که جلوی سریعتر رسیدن کاربران به آنچه از برنامه میخواهند را میگیرد. ایده PWA موفق به پرکردن شکاف میان فضای وب و اپلیکیشنها شدهاست. با توجه به روشنبودن آینده پیشروی PWA و مزیتهای کاربردی آن، بنظر میرسد تمرکز بر ایننوع از برنامهها یکی از مباحث جذاب مورد توجه طراحان و توسعه دهندهگان دنیای وب میباشد.
نویسنده مقاله امروز که مطالعه آن را به شما پیشنهاد میکنم، به توضیح مفهوم Progressive Web App پرداخته و ویژگیهای آن را بررسی میکند.
مقاله امروز را از دست ندهید:
https://www.invisionapp.com/inside-design/whats-a-pwa/
(زمان حدودی مطالعه، ۱۱ دقیقه)
نویسنده: نیما حکیم رابط
#معرفی_مفاهیم #تکنولوژی #PWA
@Dexign فلسفه دیزاین
ـــــــــ
Invisionapp
What’s a progressive web app, and why should designers care? | Inside Design Blog
Web and app designers, it's time to meet PWAs, or progressive web apps: where your jobs combine.
#پست_مجدد این پست تا به حال بیش از ۵۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
تجربه کاربری یا UX یکی از مفاهیمی است که تاثیر زیادی در محبوب شدن یک محصول دارد. مفهوم DX یا Developer Experience نیز مفهوم جدیدی است که تجربه یک برنامهنویس هنگام استفاده از یک پلتفرم یا فریمورک را بررسی میکند. چرا یک پلتفرم یا فریمورک محبوب میشود و دیگری نه؟ این سوالی است که عوامل زیادی در پاسخ دادن به آن موثر هستند. اینکه یک برنامه نویس هنگام کار با آن پلتفرم چه تجربهای احساس میکند یکی از عوامل مهم موفقیت یک پلتفرم است. در مقاله زیر مفهوم جدیدی به نام Dotability معرفی شده که میتوان به وسیله آن کتابخانهها و فریمورکهای مختلف را از لحاظ DX بررسی کرد.
http://mehrandvd.me/2016/05/31/developer-experience-dotability/
http://mehrandvd.me/2016/05/31/developer-experience-dotability/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
http://mehrandvd.me/2016/05/31/developer-experience-dotability/
http://mehrandvd.me/2016/05/31/developer-experience-dotability/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Dot Philosophy
Developer Experience: Dotability - Dot Philosophy
Again, this famous 'X', as in UX. It's all about experience. The good experience is the key that makes a product valuable. We are always talking about user experience, but here in this post, I am going to talk about developer experience. As a developer, you…
این روزها بحث انتخاب بین ریاکت و انگولار داغ است هر کدام از آنها امکاناتی دارند که دیگری فاقد آنها است.
ریاکت یک کتابخانه است که توسط فیسبوک معرفی شده است ولی انگولار مجموعهای از کتابخانههاست که با هم کار میکنند.
در این مقاله نحوه انتخاب بین این دو و موجی که اخیرا در جهت استفاده از ریاکت ایجاد شده است بررسی شده است.
https://itnext.io/is-angular-dying-because-of-react-a8e885f09421
#مریم_کمالی (http://ow.ly/9Wa430mFGeK)
کانال تلگرام:
@SoftwarePhilosophy
___
ریاکت یک کتابخانه است که توسط فیسبوک معرفی شده است ولی انگولار مجموعهای از کتابخانههاست که با هم کار میکنند.
در این مقاله نحوه انتخاب بین این دو و موجی که اخیرا در جهت استفاده از ریاکت ایجاد شده است بررسی شده است.
https://itnext.io/is-angular-dying-because-of-react-a8e885f09421
#مریم_کمالی (http://ow.ly/9Wa430mFGeK)
کانال تلگرام:
@SoftwarePhilosophy
___
Medium
Is Angular dying because of React?
What’s happening with the future of web development
Forwarded from Software Philosophy
توسعه دهندگان در ارتباط با APIها همیشه با چالشهایی رودرو بودهاند مانند:
-Multiple Endpoints
- Over-fetching/Under-fetching Data
- API Versioning
این مشکلات باعث شد تا برخی متخصصین به دنبال روشهایی برای کاهش این چالشها باشند . GraphQL یکی از این راهکارهاست که در سال 2012 توسط facebook ارائه شد.
از نکات مهم این است که یک پرس و جو را به API خود ارسال کنید و دقیقا همان چیزی که نیاز دارید را دریافت کنید ، نه اطلاعات اضافه را که هر API ممکن است در خروجی خود ارسال کند. لینک زیر یک فیلم با عنوان: "Moving Existing "API From REST To GraphQL است که نگاه جالبی نسبت به موضوع دارد:
https://www.youtube.com/watch?v=broQmxQAMjM
#شهریار_انتظام (http://ow.ly/qDN430nPiCg)
کانال تلگرام:
@SoftwarePhilosophy
___
-Multiple Endpoints
- Over-fetching/Under-fetching Data
- API Versioning
این مشکلات باعث شد تا برخی متخصصین به دنبال روشهایی برای کاهش این چالشها باشند . GraphQL یکی از این راهکارهاست که در سال 2012 توسط facebook ارائه شد.
از نکات مهم این است که یک پرس و جو را به API خود ارسال کنید و دقیقا همان چیزی که نیاز دارید را دریافت کنید ، نه اطلاعات اضافه را که هر API ممکن است در خروجی خود ارسال کند. لینک زیر یک فیلم با عنوان: "Moving Existing "API From REST To GraphQL است که نگاه جالبی نسبت به موضوع دارد:
https://www.youtube.com/watch?v=broQmxQAMjM
#شهریار_انتظام (http://ow.ly/qDN430nPiCg)
کانال تلگرام:
@SoftwarePhilosophy
___
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
✅ معرفی Windows Terminal
مایکروسافت در روز اول کنفرانس Build 2019 از برنامه ای به نام Windows Terminal پرده برداری کرد.
این برنامه، یک ترمینال مرکزی برای دسترسی به PowerShell و Cmd و WSL (کرنل Linux در Windows) است.
این برنامه گرافیک بهتری دارد و دارای قابلیت Multiple Tab - Theming and Styling - Emoji and GPU text-rendering - Syntax Highlight می باشد.
ویدیوی دموی برنامه (حتما ببینین) :
https://aka.ms/terminal-video
اطلاعات بیشتر :
https://devblogs.microsoft.com/commandline/introducing-windows-terminal/
مخزن پروژه در گیتهاب :
https://github.com/Microsoft/Terminal
_______________
@IranAspMvc
مایکروسافت در روز اول کنفرانس Build 2019 از برنامه ای به نام Windows Terminal پرده برداری کرد.
این برنامه، یک ترمینال مرکزی برای دسترسی به PowerShell و Cmd و WSL (کرنل Linux در Windows) است.
این برنامه گرافیک بهتری دارد و دارای قابلیت Multiple Tab - Theming and Styling - Emoji and GPU text-rendering - Syntax Highlight می باشد.
ویدیوی دموی برنامه (حتما ببینین) :
https://aka.ms/terminal-video
اطلاعات بیشتر :
https://devblogs.microsoft.com/commandline/introducing-windows-terminal/
مخزن پروژه در گیتهاب :
https://github.com/Microsoft/Terminal
_______________
@IranAspMvc
Forwarded from فلسفه دیزاین
دیزاین اسپرینت، منظومه ۵ فرمان
دیزاین اسپرینت یکی از متدهای تجربه کاربری بود که گوگل از آن رونمایی کرده و هدف اصلیش، حداقل کردن زمان تست و ارزیابی یک ایده و امکان پیادهسازی همزمان است. این متد توسط تیم Google Ventures ساخته و ارائه شد و به دلیل کارآیی و بازده زیاد، خیلی سریع بین طراحان UX فراگیر شد.
دیزاین اسپرینت فرایندی است که در پنج روز کاری اتفاق میافتد و به تیم طراحان کمک میکند که یک مشکل را به شکلی کاربردی (و با زمان کوتاه با کمک دیگر اعضای شرکتی که دارند برایش طراحی میکنند)، حل کنند. در صورتی که این اتفاق رخ ندهد و مشکل بعد از پنج روز حل نشود نیز زمان زیادی از دست نرفته و امکان تست و ارزیابی دوباره وجود دارد.
دیزاین اسپرینت به این دلیل که اولین بار بصورت تخصصی برای طراحی UX استفاده شد، باعث به وجود امدن برخی افسانه ها شد که به پنج مورد از بزرگترین آنها اشاره میکنیم:
۱- دیزاین اسپرینتها فقط برای تیمهای کوچک هستند.
۲- در دیزاین اسپرینتها فقط طراحان باید حضور داشته باشند.
۳- دیزاین اسپرینتها برای هر مشکلی میتوانند استفاده شوند.
۴- تنها تیمهای دیزاین میتوانند از دیزاین اسپرینت استفاده کنند.
۵- بعد از یکبار استفاده از متد اسپرینت دیگر نیازی به استفاده دوباره از این فرآیند نیست.
برای خواندن ادامه مطلب برروی لینک زیر ضربه بزنید:
http://bit.ly/dxgn494
(زمان حدودی مطالعه، ۸ دقیقه)
نویسنده: رضا دانشیان
#تجربه_کاربری #دیزاین_اسپرینت #متد
@Dexign فلسفه دیزاین
ـــــــ
دیزاین اسپرینت یکی از متدهای تجربه کاربری بود که گوگل از آن رونمایی کرده و هدف اصلیش، حداقل کردن زمان تست و ارزیابی یک ایده و امکان پیادهسازی همزمان است. این متد توسط تیم Google Ventures ساخته و ارائه شد و به دلیل کارآیی و بازده زیاد، خیلی سریع بین طراحان UX فراگیر شد.
دیزاین اسپرینت فرایندی است که در پنج روز کاری اتفاق میافتد و به تیم طراحان کمک میکند که یک مشکل را به شکلی کاربردی (و با زمان کوتاه با کمک دیگر اعضای شرکتی که دارند برایش طراحی میکنند)، حل کنند. در صورتی که این اتفاق رخ ندهد و مشکل بعد از پنج روز حل نشود نیز زمان زیادی از دست نرفته و امکان تست و ارزیابی دوباره وجود دارد.
دیزاین اسپرینت به این دلیل که اولین بار بصورت تخصصی برای طراحی UX استفاده شد، باعث به وجود امدن برخی افسانه ها شد که به پنج مورد از بزرگترین آنها اشاره میکنیم:
۱- دیزاین اسپرینتها فقط برای تیمهای کوچک هستند.
۲- در دیزاین اسپرینتها فقط طراحان باید حضور داشته باشند.
۳- دیزاین اسپرینتها برای هر مشکلی میتوانند استفاده شوند.
۴- تنها تیمهای دیزاین میتوانند از دیزاین اسپرینت استفاده کنند.
۵- بعد از یکبار استفاده از متد اسپرینت دیگر نیازی به استفاده دوباره از این فرآیند نیست.
برای خواندن ادامه مطلب برروی لینک زیر ضربه بزنید:
http://bit.ly/dxgn494
(زمان حدودی مطالعه، ۸ دقیقه)
نویسنده: رضا دانشیان
#تجربه_کاربری #دیزاین_اسپرینت #متد
@Dexign فلسفه دیزاین
ـــــــ
Invisionapp
5 myths about design sprints | Inside Design Blog
The mythical design sprint: shrouded in mystery, understood by few. This is a breakdown of the myths, and truths, of design sprints.
اگر شما دولوپرید و درون تیمی مشغول به کارید که همکار دیتا ساینتیست دارید، به احتمال زیاد در هنگام ریفکتور کد یا کد ریویو، با نام گذاری متغیرها توسط همکار دیتا ساینتیست خودتان به مشکل برخورده اید و یا شاید به ستوه آمده باشید!
مقاله زیر به صورت مفصل، راهنماییهایی جامع در مورد نام گذاری Variableها و Constantها در زبان پایتون به شما ارائه میدهد که با اشتراک گذاری آنها با هم تیمیهایتان به عنوان یک قرارداد، میتوانید در زمان و انرژی مورد استفاده برای توسعه نرم افزارها صرفه جویی بسیاری داشته باشید.
https://bit.ly/2G31PZ3
#محمدرضا_حاج_بابایی (https://bit.ly/2ThD3YO)
کانال تلگرام:
@SoftwarePhilosophy
ـــــــــ
مقاله زیر به صورت مفصل، راهنماییهایی جامع در مورد نام گذاری Variableها و Constantها در زبان پایتون به شما ارائه میدهد که با اشتراک گذاری آنها با هم تیمیهایتان به عنوان یک قرارداد، میتوانید در زمان و انرژی مورد استفاده برای توسعه نرم افزارها صرفه جویی بسیاری داشته باشید.
https://bit.ly/2G31PZ3
#محمدرضا_حاج_بابایی (https://bit.ly/2ThD3YO)
کانال تلگرام:
@SoftwarePhilosophy
ـــــــــ
Medium
Data Scientists: Your Variable Names Are Awful. Here’s How to Fix Them.
A Simple Way to Greatly Improve Code Quality
#پست_مجدد این پست تا به حال بیش از ۷۹۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
محصولی مانند BMW واقعا چگونه در ذهن ما به عنوان یک محصول با کیفیت شکل گرفته است؟ آیا ما تخصص بررسی عملکرد موتور و گیربکس آن را داریم؟ آیا مقایسهای فنی روی آن انجام دادهایم تا بفهمیم ماشین BMW یک محصول با کیفیت است؟
در حقیقت یک محصول را مفهومی به نام «نقاط تماس» یا Touch Points تعریف میکند. نقاط تماس مجموعه لحظاتی است که مشتری محصول را تجربه میکند. یک نقطه تماس میتواند لحظاتی باشد که مشتری با آن کار میکند، یا لحظاتی که مشتری پوستر محصول را میبیند و یا زمانی که صدای تیم پشتیبانی شما را از پشت تلفن میشوند.
ما برنامه نویسها عادت کردیم برنامه بنویسیم! و البته دوست داریم مشتریان برای این عادت ما ارزش قائل شوند و برای آن پول پرداخت کنند. اما حقیقت این است که مشتریان چیزی از زیبایی معماری نرمافزار ما نمیبینند همانطور که چیزی از جزئیات گیربکس یک BMW نمیدانند.
در حقیقت بهترین معماری و برنامهنویسی زمانی اتفاق میافتد که آنقدر همه چیز درست کار کند که مشتری اصلا نفهمد برنامه نویسی انجام شده، همانطور که یک گیربکس عالی گیربکسی است که مشتری هیچوقت متوجه وجودش نشود و فقط مطمئن باشد که دنده به درستی عمل میکند.
بنابر این در اکثر مواقع توضیح اینکه برنامه چقدر خوب نوشته شده ارزشی برای مشتریان ندارد.
مقاله زیر به طور خلاصه مفهوم Touch Point و نقش آن در تعریف محصولات نرمافزاری را شرح دادهاست.
http://mehrandvd.me/2016/10/02/touch-point-real-percepction-product/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
در حقیقت یک محصول را مفهومی به نام «نقاط تماس» یا Touch Points تعریف میکند. نقاط تماس مجموعه لحظاتی است که مشتری محصول را تجربه میکند. یک نقطه تماس میتواند لحظاتی باشد که مشتری با آن کار میکند، یا لحظاتی که مشتری پوستر محصول را میبیند و یا زمانی که صدای تیم پشتیبانی شما را از پشت تلفن میشوند.
ما برنامه نویسها عادت کردیم برنامه بنویسیم! و البته دوست داریم مشتریان برای این عادت ما ارزش قائل شوند و برای آن پول پرداخت کنند. اما حقیقت این است که مشتریان چیزی از زیبایی معماری نرمافزار ما نمیبینند همانطور که چیزی از جزئیات گیربکس یک BMW نمیدانند.
در حقیقت بهترین معماری و برنامهنویسی زمانی اتفاق میافتد که آنقدر همه چیز درست کار کند که مشتری اصلا نفهمد برنامه نویسی انجام شده، همانطور که یک گیربکس عالی گیربکسی است که مشتری هیچوقت متوجه وجودش نشود و فقط مطمئن باشد که دنده به درستی عمل میکند.
بنابر این در اکثر مواقع توضیح اینکه برنامه چقدر خوب نوشته شده ارزشی برای مشتریان ندارد.
مقاله زیر به طور خلاصه مفهوم Touch Point و نقش آن در تعریف محصولات نرمافزاری را شرح دادهاست.
http://mehrandvd.me/2016/10/02/touch-point-real-percepction-product/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Dot Philosophy
Touch Point: The Real Percepction of a Product - Dot Philosophy
Recently I've participated in a great workshop about Service Design. It was a totally new concept to me. The course was designed surprisingly great by Joannes Vandermeulen from Namahn. If you ask me about the most important keyword I've learned in the course…
کانالهای فارسی خود را دوطرفه کنید!
مدتی قبل به عنوان یک پروژه دستگرمی! یک کار جالب کردیم.
چند تا از برنامهنویسان حرفهای کانال «فلسفه نرمافزار» و طراحان حرفهای کانال «فلسفه دیزاین» طی یک هفته دست به کار شدیم و یک بات تلگرام درست کردیم که امکان «کامنتگذاری فارسی» زیر پستها را به کانال تلگرام اضافه کنیم.
پروژه بسیار جذابی بود و تصمیم گرفتیم که با شما هم به اشتراک بگذاریم.
از جذابیتهای فنی این بات:
۱. کل تیمی که یک هفته روی این بات کار کردند کاملا ریموت بوده و همدیگر را ندیدهاند!
۲. همه این سیستم روی Azure ریلیز شده و به شدت آماده گسترش (Scale شدن) است. اگر کانالهای زیادی شروع به استفاده از این بات کنند، گزارشهایی را از روش گسترش این سرویس روی Azure، همینجا با شما به اشتراک میگذاریم.
۳. این بات از ویژگی جدید LoginURL که جدیدا به تلگرام اضافه شده استفاده میکند. این ویژگی به کاربران این امکان را میدهد که وقتی از طریق تلگرام یک لینک را باز میکنند، بصورت اتوماتیک Login شوند.
ناگفته نماند خود تلگرام هم یک بات برای کامنتگذاری اضافه کرده که برای زبان فارسی اصلا خوب کار نمیکند. همین موضوع انگیزهای برای ما شد که این بات را ساخته و تجربه خوشآیندی را از کامنت گذاشتن به زبان فارسی به کانالهای تلگرام بیاوریم.
برای اضافه شدن این امکان، کافیست بات @CommentFarsiBot را به کانال خود اضافه کنید (به عنوان ادمین).
حالا دیگه ما هم صدای شما را میشنویم!
کانال فلسفه نرمافزار: @SoftwarePhilosophy
کانال فلسفه دیزاین: @Dexign
ــــــــ
مدتی قبل به عنوان یک پروژه دستگرمی! یک کار جالب کردیم.
چند تا از برنامهنویسان حرفهای کانال «فلسفه نرمافزار» و طراحان حرفهای کانال «فلسفه دیزاین» طی یک هفته دست به کار شدیم و یک بات تلگرام درست کردیم که امکان «کامنتگذاری فارسی» زیر پستها را به کانال تلگرام اضافه کنیم.
پروژه بسیار جذابی بود و تصمیم گرفتیم که با شما هم به اشتراک بگذاریم.
از جذابیتهای فنی این بات:
۱. کل تیمی که یک هفته روی این بات کار کردند کاملا ریموت بوده و همدیگر را ندیدهاند!
۲. همه این سیستم روی Azure ریلیز شده و به شدت آماده گسترش (Scale شدن) است. اگر کانالهای زیادی شروع به استفاده از این بات کنند، گزارشهایی را از روش گسترش این سرویس روی Azure، همینجا با شما به اشتراک میگذاریم.
۳. این بات از ویژگی جدید LoginURL که جدیدا به تلگرام اضافه شده استفاده میکند. این ویژگی به کاربران این امکان را میدهد که وقتی از طریق تلگرام یک لینک را باز میکنند، بصورت اتوماتیک Login شوند.
ناگفته نماند خود تلگرام هم یک بات برای کامنتگذاری اضافه کرده که برای زبان فارسی اصلا خوب کار نمیکند. همین موضوع انگیزهای برای ما شد که این بات را ساخته و تجربه خوشآیندی را از کامنت گذاشتن به زبان فارسی به کانالهای تلگرام بیاوریم.
برای اضافه شدن این امکان، کافیست بات @CommentFarsiBot را به کانال خود اضافه کنید (به عنوان ادمین).
حالا دیگه ما هم صدای شما را میشنویم!
کانال فلسفه نرمافزار: @SoftwarePhilosophy
کانال فلسفه دیزاین: @Dexign
ــــــــ
Forwarded from اِسکیلی Skilly (مهدی کرامتی)
✅ معرفی ورژن 2 Windows Subsystem for Linux (به اختصار WSL 2)
ماکروسافت در یک اقدام جالب، کرنل لینوکس (ورژن 4.19 - آخرین ورژن پایدار و LTS) رو به طور کامل به ویندوز منتقل کرد.
در نتیجه امکان اجرای کانتینر های Docker به صورت Native در آن وجود دارد و دیگر نیازی به VM برای اجرای کانتینر ها بر روی Windows نیست!
همچنین ماکروسافت ادعا کرده در این روش، زمان boot time لینوکس و میزان رم مصرفی کاهش پیدا کرده و نیز عملیات I/O filesystem افزایش پرفرمنس داشته است.
این یه حرکت بزرگ است و اولین باری هست که کرنل لینوکس به عنوان بخشی از ویندوز قرار می گیرد.
این قابلیت، اواخر امسال همراه با اپدیت ویندوز 10 به نام (Codename 19H2) عرضه خواهد شد.
اطلاعات بیشتر :
https://devblogs.microsoft.com/commandline/shipping-a-linux-kernel-with-windows
@barnamenevis_org
ماکروسافت در یک اقدام جالب، کرنل لینوکس (ورژن 4.19 - آخرین ورژن پایدار و LTS) رو به طور کامل به ویندوز منتقل کرد.
در نتیجه امکان اجرای کانتینر های Docker به صورت Native در آن وجود دارد و دیگر نیازی به VM برای اجرای کانتینر ها بر روی Windows نیست!
همچنین ماکروسافت ادعا کرده در این روش، زمان boot time لینوکس و میزان رم مصرفی کاهش پیدا کرده و نیز عملیات I/O filesystem افزایش پرفرمنس داشته است.
این یه حرکت بزرگ است و اولین باری هست که کرنل لینوکس به عنوان بخشی از ویندوز قرار می گیرد.
این قابلیت، اواخر امسال همراه با اپدیت ویندوز 10 به نام (Codename 19H2) عرضه خواهد شد.
اطلاعات بیشتر :
https://devblogs.microsoft.com/commandline/shipping-a-linux-kernel-with-windows
@barnamenevis_org
Forwarded from فلسفه دیزاین
ماجرای یک دست و دو هندوانه
مدتها به دنبال روشی بودم که بتوانم وظایف و دیزاینهایی که در یک روز به من محوّل شدهاند را تا انتهای همان روز تمام و کمال تحویل بدهم.
گاهی هم در ضرورتهای عجلهای، که زمان کم است و فشار کارفرما ایجاب میکند که دیزاین زودتر تحویل داده شود؛ پیش میآید که در حین دیزاین، باید کامنتهای زپلین را بررسی کنم، پیامهای واتساپ، تلگرام و ایمیل را چک بکنم. صحبتهای مدیر را خوب گوش دهم. و همهی اینها زمانی رخ میدهد که درحال دیزاین طرح فعلی هستم. طرحی که باید تا انتهای روز تحویل بدهم و برنامهام را نیز طبق همان چیدهام. حال باید به سرعت روی دیزاین جدید کار کرده و درعرض یکساعت آن را تحویل بدهم. شغل ما دیزاینرها مثل خلبانها، پیشخدمتها و... عملکرد چندوظیفهای را نیاز دارد.
اما به چه قیمت؟ به قیمت از دست دادن چند امتیازی سطح IQ ما؟ آن هم زمانی که ما به بیشترین سطح خلاقیت خود در دیزاین نیاز داریم؟
طبق تحقیقات و آزمایشهایی که تحت نظر دکتر ارل میلر عصب شناس دانشگاه امآیتی انجام شده به این نتیجه رسیدهاند که ذهن ما برای عملکرد چندوظیفهای ساخته نشده و بهترین عملکرد آن زمانیست که روی یک موضوع تمرکز دارد. در واقع ذهن ما بین وظایف مختلف به طور خیلی سریع جابجا میشود و این طور نیست که بتواند به صورت همزمان روی چندین موضوع تمرکز کند. این جابجاییهای پیدرپی و سریع باعث ایجاد یک عادت بد در رفتار ما میشود.
وقتی یک عملکرد کوچک را به پایان میرسانیم در واقع باعث ترشح هورمون دوپامین که به هورمون پاداش نیز معروف است، میشویم. ذهن ما این هورمون را دوست دارد و ما را تشویق به ترشح هرچه بیشتر آن میکند. ما را وادار به به جابجایی سریع بین وظایف میکند تا به ما خوشی لحظهای بدهد.
این ترشحات پیدرپی ما را وارد چرخهی خطرناکی میکند. به ما این احساس را میدهد که عملکردهای زیادی را به اتمام رساندهایم که درواقع چیز خاصی نبودهاند. ( چک کردنهای اعتیادآور شبکهها و پیامرسانهای مجازی)
آقای دیوید استب مؤسس و مربی استارلینگتیم میگوید: " مدیران زمانیکه بین عملکردشان و روابط اعضای تیمشان به صورت چندوظیفهای عمل میکنند، در انتها با این مواجه خواهند شد که افرادشان یک شئ هستند! "
این شئنگری به افراد گروه نتایج غیرقابل جبرانی دارد که در ادامه شما را با یک داستان واقعی ازین مدیر که باعث متحمل شدن هزینههای زیادی به او و تیمش شده، آشنا میکنم. بلایی که multitasking (عملکرد چندوظیفهای) سر یک سیستم و افراد آن میآورد گاهی اوقات غیرقابل جبران است.
http://bit.ly/dxgn495-1
جزئیات و نتایج بیشتر آزمایشات با محتوای multitasking را می توانید در لینک زیر ببینید:
http://bit.ly/dxgn495-2
(زمان حدودی مطالعه، ۱۰دقیقه)
نویسنده: حسین میرزاده
#عملکردچندوظیفهای #مدیریت #محیطکار
@Dexign فلسفه دیزاین
ـــــ
مدتها به دنبال روشی بودم که بتوانم وظایف و دیزاینهایی که در یک روز به من محوّل شدهاند را تا انتهای همان روز تمام و کمال تحویل بدهم.
گاهی هم در ضرورتهای عجلهای، که زمان کم است و فشار کارفرما ایجاب میکند که دیزاین زودتر تحویل داده شود؛ پیش میآید که در حین دیزاین، باید کامنتهای زپلین را بررسی کنم، پیامهای واتساپ، تلگرام و ایمیل را چک بکنم. صحبتهای مدیر را خوب گوش دهم. و همهی اینها زمانی رخ میدهد که درحال دیزاین طرح فعلی هستم. طرحی که باید تا انتهای روز تحویل بدهم و برنامهام را نیز طبق همان چیدهام. حال باید به سرعت روی دیزاین جدید کار کرده و درعرض یکساعت آن را تحویل بدهم. شغل ما دیزاینرها مثل خلبانها، پیشخدمتها و... عملکرد چندوظیفهای را نیاز دارد.
اما به چه قیمت؟ به قیمت از دست دادن چند امتیازی سطح IQ ما؟ آن هم زمانی که ما به بیشترین سطح خلاقیت خود در دیزاین نیاز داریم؟
طبق تحقیقات و آزمایشهایی که تحت نظر دکتر ارل میلر عصب شناس دانشگاه امآیتی انجام شده به این نتیجه رسیدهاند که ذهن ما برای عملکرد چندوظیفهای ساخته نشده و بهترین عملکرد آن زمانیست که روی یک موضوع تمرکز دارد. در واقع ذهن ما بین وظایف مختلف به طور خیلی سریع جابجا میشود و این طور نیست که بتواند به صورت همزمان روی چندین موضوع تمرکز کند. این جابجاییهای پیدرپی و سریع باعث ایجاد یک عادت بد در رفتار ما میشود.
وقتی یک عملکرد کوچک را به پایان میرسانیم در واقع باعث ترشح هورمون دوپامین که به هورمون پاداش نیز معروف است، میشویم. ذهن ما این هورمون را دوست دارد و ما را تشویق به ترشح هرچه بیشتر آن میکند. ما را وادار به به جابجایی سریع بین وظایف میکند تا به ما خوشی لحظهای بدهد.
این ترشحات پیدرپی ما را وارد چرخهی خطرناکی میکند. به ما این احساس را میدهد که عملکردهای زیادی را به اتمام رساندهایم که درواقع چیز خاصی نبودهاند. ( چک کردنهای اعتیادآور شبکهها و پیامرسانهای مجازی)
آقای دیوید استب مؤسس و مربی استارلینگتیم میگوید: " مدیران زمانیکه بین عملکردشان و روابط اعضای تیمشان به صورت چندوظیفهای عمل میکنند، در انتها با این مواجه خواهند شد که افرادشان یک شئ هستند! "
این شئنگری به افراد گروه نتایج غیرقابل جبرانی دارد که در ادامه شما را با یک داستان واقعی ازین مدیر که باعث متحمل شدن هزینههای زیادی به او و تیمش شده، آشنا میکنم. بلایی که multitasking (عملکرد چندوظیفهای) سر یک سیستم و افراد آن میآورد گاهی اوقات غیرقابل جبران است.
http://bit.ly/dxgn495-1
جزئیات و نتایج بیشتر آزمایشات با محتوای multitasking را می توانید در لینک زیر ببینید:
http://bit.ly/dxgn495-2
(زمان حدودی مطالعه، ۱۰دقیقه)
نویسنده: حسین میرزاده
#عملکردچندوظیفهای #مدیریت #محیطکار
@Dexign فلسفه دیزاین
ـــــ
Medium
Response to
Not only are we bad at doing many things at once, but it can actually be harmful to try
#پست_مجدد این پست تا به حال بیش از ۷۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
معماری نرمافزار مانند معماری ساختمان یک هنر است آیا تا به حال به فرق یک معمار و یک مهندس عمران فکر کردهاید؟ تمرکز مهندسان عمران معمولا بر ساخت سازهها است. آنها فکر میکنند چطور سازههایی مانند دیوار، در، پنجره و سایر اجزا را به طور صحیح بسازند. از طرف دیگر معمارها معمولا به اینها فکر نمیکنند! تمرکز اصلی آنها روی ساخت و معماری فضاهایی است که بین این اجزا به وجود میآید. در حقیقت مهندسین عمران به دیوارها فکر میکنند و معمارها به فضای بین دیوارها.
نکته جالب این است که انسانها یا مشتریان در نهایت از فضاها استفاده میکنند نه دیوارها! آنها پول خرج میکنند تا فضای زیبایی بخرند و به ندرت دیوارها را میبینند.
در مهندسی نرمافزار، ساخت دیوار مانند کد نویسی است. برنامهنویسان با کد نویسی در حقیقت در حال ساخت دیوارهایی هستند که این دیوارها مستقیما برای مشتری معنی ندارد. مشتریان امکاناتی را میبینند که توسط این کدها برای آنها خلق شدهاست. یکی از وظایف یک مهندس نرمافزار تمرکز بر فضاهای ایجاد شده برای مشتری است. اینکه این فضاها چقدر کارا و مفید طراحی شدهاند.
توضیحات کامل مفهوم فضا و تاثیر آن بر مشتری را میتوانید در لینک زیر بخوانید.
http://mehrandvd.me/2015/10/26/spaces-shape-your-software-architecture/
#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
نکته جالب این است که انسانها یا مشتریان در نهایت از فضاها استفاده میکنند نه دیوارها! آنها پول خرج میکنند تا فضای زیبایی بخرند و به ندرت دیوارها را میبینند.
در مهندسی نرمافزار، ساخت دیوار مانند کد نویسی است. برنامهنویسان با کد نویسی در حقیقت در حال ساخت دیوارهایی هستند که این دیوارها مستقیما برای مشتری معنی ندارد. مشتریان امکاناتی را میبینند که توسط این کدها برای آنها خلق شدهاست. یکی از وظایف یک مهندس نرمافزار تمرکز بر فضاهای ایجاد شده برای مشتری است. اینکه این فضاها چقدر کارا و مفید طراحی شدهاند.
توضیحات کامل مفهوم فضا و تاثیر آن بر مشتری را میتوانید در لینک زیر بخوانید.
http://mehrandvd.me/2015/10/26/spaces-shape-your-software-architecture/
#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
#پست_مجدد این پست تا به حال بیش از ۲۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
اگر بخواهیم امروز یک stack برای ۳ سال آینده انتخاب کنیم؟
در یکی از شرکتهایی که مشاور هستم سوال جالبی مطرح شده. قرار هست که برای ۳ سال آینده برنامهریزی فنی داشته باشیم و الان یک stack انتخاب کنیم که پروژههای آینده رو با اونها انجام بدیم. و خوب احتمالا ۳ سال بعد باز هم باید این تصمیم جدی رو دوباره بگیریم!
قرار شده هر کسی که پیشنهادی داره، پیشنهادش رو در قابل یک پروپوزال ارائه بده!
من تصمیم گرفتم این مستند رو روی گیتهاب درست کنم تا هم در اختیار همه باشه و هم بتونم از نظر همه شما استفاده کنم. اگر فکر میکنید در انتخاب stack تا حدودی شبیه هم فکر میکنیم خیلی خوشحال میشم تو تکمیلش بهم کمک کنین. تو گیتهاب نظراتتون رو به صورت issue مطرح کنین تا در موردشون بحث کنیم و یا حتی تغییراتی رو که به نظرتون میاد رو به صورت pull request بفرستید واسم.
https://github.com/mehrandvd/general-stack
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/DaUO30oz4z2
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
در یکی از شرکتهایی که مشاور هستم سوال جالبی مطرح شده. قرار هست که برای ۳ سال آینده برنامهریزی فنی داشته باشیم و الان یک stack انتخاب کنیم که پروژههای آینده رو با اونها انجام بدیم. و خوب احتمالا ۳ سال بعد باز هم باید این تصمیم جدی رو دوباره بگیریم!
قرار شده هر کسی که پیشنهادی داره، پیشنهادش رو در قابل یک پروپوزال ارائه بده!
من تصمیم گرفتم این مستند رو روی گیتهاب درست کنم تا هم در اختیار همه باشه و هم بتونم از نظر همه شما استفاده کنم. اگر فکر میکنید در انتخاب stack تا حدودی شبیه هم فکر میکنیم خیلی خوشحال میشم تو تکمیلش بهم کمک کنین. تو گیتهاب نظراتتون رو به صورت issue مطرح کنین تا در موردشون بحث کنیم و یا حتی تغییراتی رو که به نظرتون میاد رو به صورت pull request بفرستید واسم.
https://github.com/mehrandvd/general-stack
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/DaUO30oz4z2
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
GitHub
mehrandvd/general-stack
The question is as simple as this: Which stack to use for the next 3 years! - mehrandvd/general-stack
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
🔰 بررسی تغییرات جدید NET Core 3.0 Preview 5
توی این نسخه که همزمان با کنفرانس Microsoft Build 2019 منتشر شد شاهد تغییرات کم ولی مهمی هستیم.
🔸بهبود های WPF و Windows Forms
توی این نسخه پرفرمنس Startup (اجرای اولیه) این دو تکنولوژی به لطف قابلیتی به نام AOT Compilation افزایش پیدا کرده
ما 2 روش کامپایل داریم:
یکی حالت معمولی که کد رو به یک زبان میانی (توی دات نت بهش IL یا CIL هم میگن) کامپایل میکنه، در واقع DLL های خروجی پروژه ها شامل کد های IL یا همون Intermediate Language هستند و توسط Just-In-Time (به اختصار JIT) اجرا میشن
روش دوم که پرفرمنس خیلی بیشتری داره اسمش هست Ahead-Of-Time (یا به اختصار AOT) که کد ها رو نه به یک زبان میانی، بلکه مستقیما به کد ماشین (Native) تبدیل میکنه
در این روش کد ها مستقیما بر روی سیستم عامل اجرا میشن و شامل کد های Optimize شده برای همون سیستم عامل هستند
حالا یه چیز جدیدی به نام Runtime دیگه برای NET Core هم هست به نام CoreRT که برای همین AOT Compilation کاربرد داره و دیگه نهایت سرعته و قراره به عنوان بخشی از NET 5. منتشر بشه. [بعدا در موردش صحبت خواهیم کرد]
🔹بهبود های کلاس SqlClient
این کلاس، جز کلاس های پایه ADO.NET هست و کارش دسترسی به دیتابیس SQL Server هست و توی ORM ها از جمله EF/EF Core و Dapper هم از همین کلاس استفاده شده
این کلاس جز کلاس های پایه NET Framework و Core بوده (داخل اسمبلی System.Data.dll) و به صورت Package جدا گانه نیست به همین خاطر هر موقع فیچر های جدیدی بهش اضافه میشد باید صبر میکردیم تا آپدیت جدید دات نت بیاد تا بتونیم ازش استفاده کنیم
ولی الان ماکروسافت اون رو به یه پکیج جداگانه به نام Microsoft.Data.SqlClient منتقل کرده تا بتونه سریع تر براش آپدیت بده. همین الان بهبود هایی بهش اضافه شده و قراره در کنار توسعه دات نت کور، این پکیچ هم توسعه و بهبود داده بشه
کلاس قبلی (System.Data.SqlClient) قرار نیست حذف بشه و بروزرسانی های مهم رو دریافت خواهد کرد پس نگران تغییر نباشید ولی برای استفاده از کلاس جدید :
اگه از این کلاس به صورت مستقم (به روش ADO.NET) استفاده کردید به راحتی با نصب این پکیج و تغییر به namespace مورد نظر میتونین ازش استفاده کنین ولی اگه از ORM هایی مثل EF Core یا Dapper استفاده میکنین باید صبر کنین تا این ORM ها هم از این پکیج جدید استفاده کنن
🔸پابلیش تک فایلی یا (Single EXEs)
از این پس میتونین خروجی پروژه هاتون رو به صورت یک فایل تکی پابلیش بگیرید. دیگه لازم نیست کلی فایل رو توی سیستم مشتری کپی کنین
این فایل به صورت self-extracting خواهد بود و تمام DLL ها و فایل های مورد نیازش (Dependencies) رو داخل خودش Embed کرده و موقع اجرا، فایل ها رو تو یه مسیر Temp کپی میکنه و Load شون میکنه
🔹بهبود های JSON Serializer
قبلا در مورد JSON Serializer داخلی فوق سریع توی NET Core 3.0 Preview 2 صحبت کردیم. اینبار اما یه سری بهبود و تغییرات دیزاینی تو پیاده سازیش داشته که خیلی کاربردی نیست پس ازش میگذریم [اطلاعات بیشتر]
🔸تغییرات Index و Range
توی سی شارپ 8 شاهد قابلیت جدید و باحالی به نام index و range بودیم که توی NET Core 3 هم کم کم پیاده سازی شد ولی الان ماکروسافت تصمیم گرفته بر اساس فیدبک های کامیونتی یه سری تغییر در این رابطه انجام بده
این تغییرات و مثال هاش کمی طولانیه و اینجا جا نمیشه. [اطلاعات بیشتر]
🔹تغییرات دیگه ای هم بوده که زیاد مهم نیستند یا خیلی تخصصی اند
اطلاعات بیشتر :
https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0-preview-5/
_______________
@IranAspMvc
توی این نسخه که همزمان با کنفرانس Microsoft Build 2019 منتشر شد شاهد تغییرات کم ولی مهمی هستیم.
🔸بهبود های WPF و Windows Forms
توی این نسخه پرفرمنس Startup (اجرای اولیه) این دو تکنولوژی به لطف قابلیتی به نام AOT Compilation افزایش پیدا کرده
ما 2 روش کامپایل داریم:
یکی حالت معمولی که کد رو به یک زبان میانی (توی دات نت بهش IL یا CIL هم میگن) کامپایل میکنه، در واقع DLL های خروجی پروژه ها شامل کد های IL یا همون Intermediate Language هستند و توسط Just-In-Time (به اختصار JIT) اجرا میشن
روش دوم که پرفرمنس خیلی بیشتری داره اسمش هست Ahead-Of-Time (یا به اختصار AOT) که کد ها رو نه به یک زبان میانی، بلکه مستقیما به کد ماشین (Native) تبدیل میکنه
در این روش کد ها مستقیما بر روی سیستم عامل اجرا میشن و شامل کد های Optimize شده برای همون سیستم عامل هستند
حالا یه چیز جدیدی به نام Runtime دیگه برای NET Core هم هست به نام CoreRT که برای همین AOT Compilation کاربرد داره و دیگه نهایت سرعته و قراره به عنوان بخشی از NET 5. منتشر بشه. [بعدا در موردش صحبت خواهیم کرد]
🔹بهبود های کلاس SqlClient
این کلاس، جز کلاس های پایه ADO.NET هست و کارش دسترسی به دیتابیس SQL Server هست و توی ORM ها از جمله EF/EF Core و Dapper هم از همین کلاس استفاده شده
این کلاس جز کلاس های پایه NET Framework و Core بوده (داخل اسمبلی System.Data.dll) و به صورت Package جدا گانه نیست به همین خاطر هر موقع فیچر های جدیدی بهش اضافه میشد باید صبر میکردیم تا آپدیت جدید دات نت بیاد تا بتونیم ازش استفاده کنیم
ولی الان ماکروسافت اون رو به یه پکیج جداگانه به نام Microsoft.Data.SqlClient منتقل کرده تا بتونه سریع تر براش آپدیت بده. همین الان بهبود هایی بهش اضافه شده و قراره در کنار توسعه دات نت کور، این پکیچ هم توسعه و بهبود داده بشه
کلاس قبلی (System.Data.SqlClient) قرار نیست حذف بشه و بروزرسانی های مهم رو دریافت خواهد کرد پس نگران تغییر نباشید ولی برای استفاده از کلاس جدید :
اگه از این کلاس به صورت مستقم (به روش ADO.NET) استفاده کردید به راحتی با نصب این پکیج و تغییر به namespace مورد نظر میتونین ازش استفاده کنین ولی اگه از ORM هایی مثل EF Core یا Dapper استفاده میکنین باید صبر کنین تا این ORM ها هم از این پکیج جدید استفاده کنن
🔸پابلیش تک فایلی یا (Single EXEs)
از این پس میتونین خروجی پروژه هاتون رو به صورت یک فایل تکی پابلیش بگیرید. دیگه لازم نیست کلی فایل رو توی سیستم مشتری کپی کنین
این فایل به صورت self-extracting خواهد بود و تمام DLL ها و فایل های مورد نیازش (Dependencies) رو داخل خودش Embed کرده و موقع اجرا، فایل ها رو تو یه مسیر Temp کپی میکنه و Load شون میکنه
🔹بهبود های JSON Serializer
قبلا در مورد JSON Serializer داخلی فوق سریع توی NET Core 3.0 Preview 2 صحبت کردیم. اینبار اما یه سری بهبود و تغییرات دیزاینی تو پیاده سازیش داشته که خیلی کاربردی نیست پس ازش میگذریم [اطلاعات بیشتر]
🔸تغییرات Index و Range
توی سی شارپ 8 شاهد قابلیت جدید و باحالی به نام index و range بودیم که توی NET Core 3 هم کم کم پیاده سازی شد ولی الان ماکروسافت تصمیم گرفته بر اساس فیدبک های کامیونتی یه سری تغییر در این رابطه انجام بده
این تغییرات و مثال هاش کمی طولانیه و اینجا جا نمیشه. [اطلاعات بیشتر]
🔹تغییرات دیگه ای هم بوده که زیاد مهم نیستند یا خیلی تخصصی اند
اطلاعات بیشتر :
https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0-preview-5/
_______________
@IranAspMvc
.NET Blog
Announcing .NET Core 3.0 Preview 5 | .NET Blog
Today, we are announcing .NET Core 3.0 Preview 5. It includes a new Json serializer, support for publishing single file executables, an update to runtime roll-forward, and changes in the BCL. If you missed it, check out the improvements we released in .NET…
Forwarded from فلسفه دیزاین
که آسان مینمود اول ولی …
انتقال از مرحله دیزاین به مرحله توسعه نقطه عطفی در روند پیشبرد هر پروژه است. کلید موفقیت این انتقال، ارتباط و هماهنگی بین دیزاینر و توسعهدهندگان است که در اغلب موارد یکی از چالشهای اصلی هر تیم فعال در این زمینه است.
در این انتقال عدم ارتباط و بدفهمی در نیت طراحی را میتوان از مشکلات شناخته شدهای دانست که باعث ایجاد استرسهای بیمورد در تمامی اعضای تیم میشود.
حال این سوال مطرح میشود که یک دیزاینر چه کاری میتواند انجام دهد تا این انتقال هر چه سریعتر و باکیفیتتر صورت گیرد؟ یا بطور کلی چه مواردی را در این انتقال باید در نظر بگیرد.
هنگامی که طرحی به توسعهدهنده تحویل داده میشود، چندین لایه اطلاعاتی وجود دارد که باید منتقل شود. علاوه بر Mockups و Specs ،Assets، باید Interactions، Copy و Checklist را نیز به اشتراک گذاشت. تمامی این اطلاعات زوایای مختلفی از راهکار دیزاین شده را به توسعهدهنده نشان میدهد. تمامی این موارد را در قالب یک مستند میتوان “Design Handoff Document" نامید. این مستند جامع و کاملیست از اطلاعات و عناصری که به توسعهدهندهها در تحلیل و فهم درست دیزاین کمک کرده، همچنین باعث تسریع در کار آنها میشود. که این اتفاق کیفیت توسعه و برنامهنویسی را ارتقا میبخشد.
امروز آنچه در این مقاله میخوانید، مروری کلی بر کارآمدترین روشهای موجود برای دیزاینرها و تیمهای توسعه است تا در نتیجه آن بتوانند به بهترین هماهنگی و خروجی برسند.
مقاله امروز را از دست ندهید:
http://bit.ly/dxgn496
(زمان حدودی مطالعه، ۱۰ دقیقه)
نویسنده: نیما حکیمرابط
#Handoff #تعامل #توسعه
@Dexign فلسفه دیزاین
ــــــــ
انتقال از مرحله دیزاین به مرحله توسعه نقطه عطفی در روند پیشبرد هر پروژه است. کلید موفقیت این انتقال، ارتباط و هماهنگی بین دیزاینر و توسعهدهندگان است که در اغلب موارد یکی از چالشهای اصلی هر تیم فعال در این زمینه است.
در این انتقال عدم ارتباط و بدفهمی در نیت طراحی را میتوان از مشکلات شناخته شدهای دانست که باعث ایجاد استرسهای بیمورد در تمامی اعضای تیم میشود.
حال این سوال مطرح میشود که یک دیزاینر چه کاری میتواند انجام دهد تا این انتقال هر چه سریعتر و باکیفیتتر صورت گیرد؟ یا بطور کلی چه مواردی را در این انتقال باید در نظر بگیرد.
هنگامی که طرحی به توسعهدهنده تحویل داده میشود، چندین لایه اطلاعاتی وجود دارد که باید منتقل شود. علاوه بر Mockups و Specs ،Assets، باید Interactions، Copy و Checklist را نیز به اشتراک گذاشت. تمامی این اطلاعات زوایای مختلفی از راهکار دیزاین شده را به توسعهدهنده نشان میدهد. تمامی این موارد را در قالب یک مستند میتوان “Design Handoff Document" نامید. این مستند جامع و کاملیست از اطلاعات و عناصری که به توسعهدهندهها در تحلیل و فهم درست دیزاین کمک کرده، همچنین باعث تسریع در کار آنها میشود. که این اتفاق کیفیت توسعه و برنامهنویسی را ارتقا میبخشد.
امروز آنچه در این مقاله میخوانید، مروری کلی بر کارآمدترین روشهای موجود برای دیزاینرها و تیمهای توسعه است تا در نتیجه آن بتوانند به بهترین هماهنگی و خروجی برسند.
مقاله امروز را از دست ندهید:
http://bit.ly/dxgn496
(زمان حدودی مطالعه، ۱۰ دقیقه)
نویسنده: نیما حکیمرابط
#Handoff #تعامل #توسعه
@Dexign فلسفه دیزاین
ــــــــ
Medium
A Guide to Successful Design Handoffs
A comprehensive walkthrough to help Designers handoff their designs effectively. Also includes a few tips & tricks to simplify the process.
خرمشهر را اسکات هانسلمن آزاد کرد!!
چند روزی بود که دنیای نرمافزار اوپن سورس ایران دچار کابوس شده بود! شهر آرمانی دنیای اوپنسورس، جایی که همه آزادانه سورسهای خود را به اشتراک میگذارند، یعنی GitHub به علت تحریمها برای ایرانیان محدود شده بود.
خرمشهر در فارسی یعنی شهری که همه در اون خوش و خرم هستند و در ادبیات تاریخی ما نماد جایی هست که به زور میخواستند بگیرنش، بی شباهت به گیتهاب نیست!
خبر جذذاب (با تو تا ذ!) این بود که اسکات هانسلمن امروز فارسی توییت کرد «خسته نباشید!» اما چه ربطی داره!؟
ظاهرا تعداد زیادی برنامهنویس ایرانی که در توییتر با اسکات هانسلمن در این مورد صحبت کردن باعث شدن که صحبتی بین اسکات و «نات فریمن» مدیر عامل گیتهاب شکل بگیره و در حال حاضر این امکان فراهم شده که برنامهنویسانی که ریپازیتوری خصوصی داشتن بتونن پابلیکش کنن و به کدهاشون دسترسی پیدا کنن.
نات فریمن در توییتی توضیح داده که: «فعلا تونستیم کاری کنیم که افراد بتونن ریپازیتوریهاشون رو پابلیک کنن تا بهش دسترسی داشته باشن، طبق فهم ما از قانون فعلا نمیتونیم کار بیشتری کنیم...» و در توییتی دیگه نوشته: «ما این کار رو نکردیم چون میخواستیم، این کار رو کردیم چون مجبور شدیم...»
و در آخر اینکه لامصب اسکات هانسلمن، فارسی هم میخواد صحبت کنه فلوئنت صحبت میکنه!
لینک توییتهای ذکر شده:
https://twitter.com/shanselman/status/1155240674301624321
https://twitter.com/natfriedman/status/1155311124687945728
https://twitter.com/natfriedman/status/1155311125967171585
https://twitter.com/mehrandvd/status/1155385194657935360
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، دکمه پایین را بزنید. 👇👇
چند روزی بود که دنیای نرمافزار اوپن سورس ایران دچار کابوس شده بود! شهر آرمانی دنیای اوپنسورس، جایی که همه آزادانه سورسهای خود را به اشتراک میگذارند، یعنی GitHub به علت تحریمها برای ایرانیان محدود شده بود.
خرمشهر در فارسی یعنی شهری که همه در اون خوش و خرم هستند و در ادبیات تاریخی ما نماد جایی هست که به زور میخواستند بگیرنش، بی شباهت به گیتهاب نیست!
خبر جذذاب (با تو تا ذ!) این بود که اسکات هانسلمن امروز فارسی توییت کرد «خسته نباشید!» اما چه ربطی داره!؟
ظاهرا تعداد زیادی برنامهنویس ایرانی که در توییتر با اسکات هانسلمن در این مورد صحبت کردن باعث شدن که صحبتی بین اسکات و «نات فریمن» مدیر عامل گیتهاب شکل بگیره و در حال حاضر این امکان فراهم شده که برنامهنویسانی که ریپازیتوری خصوصی داشتن بتونن پابلیکش کنن و به کدهاشون دسترسی پیدا کنن.
نات فریمن در توییتی توضیح داده که: «فعلا تونستیم کاری کنیم که افراد بتونن ریپازیتوریهاشون رو پابلیک کنن تا بهش دسترسی داشته باشن، طبق فهم ما از قانون فعلا نمیتونیم کار بیشتری کنیم...» و در توییتی دیگه نوشته: «ما این کار رو نکردیم چون میخواستیم، این کار رو کردیم چون مجبور شدیم...»
و در آخر اینکه لامصب اسکات هانسلمن، فارسی هم میخواد صحبت کنه فلوئنت صحبت میکنه!
لینک توییتهای ذکر شده:
https://twitter.com/shanselman/status/1155240674301624321
https://twitter.com/natfriedman/status/1155311124687945728
https://twitter.com/natfriedman/status/1155311125967171585
https://twitter.com/mehrandvd/status/1155385194657935360
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، دکمه پایین را بزنید. 👇👇
X (formerly Twitter)
Scott Hanselman 🌮 (@shanselman) on X
خسته نباشید
#پست_مجدد این پست تا به حال بیش از ۳۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.