#پست_مجدد این پست تا به حال بیش از ۱۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
مسالهای که ممکن است برای هر برنامهنویسی چالش باشد این است که کدها را چگونه و بر چه اساسی در قالب فولدرها مرتب نماید. بعنوان مثال در یک پروژهی وب View ها، Controller ها و Model ها هر کدام در یک فولدر جداگانه باشند و یا بر اساس کارکرد View ، Controller و Model ها در کنار هم قرار داشته باشند. در ویدیو زیر اسکات آلن بر اساس تجربه اش به این موضوع و 51 مساله ی دیگر می پردازد.
https://www.youtube.com/watch?v=6Fi5dRVxOvc
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/b1QP30e0yvS
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
https://www.youtube.com/watch?v=6Fi5dRVxOvc
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/b1QP30e0yvS
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
YouTube
An Opinionated Approach to ASP.NET Core - Scott Allen
Improve the architecture, design, and code inside your ASP.NET Core applications with an opinionated approach to ASP.NET.
In this talk we’ll look at strategies for organizing projects, solutions, files and folders. We'll look at data access alternatives and…
In this talk we’ll look at strategies for organizing projects, solutions, files and folders. We'll look at data access alternatives and…
طراحی کلمه عجیبی است. در زمینههای گوناگون و حتی علوم مختلف شاید مهمترین کلمهای باشد که در مورد آن صحبت میشود.
طراحی یک اثر هنری، طراحی داخلی یک ساختمان، طراحی نرمافزار، طراحی داستان، طراحی یک گفتگو، طراحی جنگ، طراحی تفکر!
در زبان فارسی ترجمه هر دو کلمه Drawing و Design طراحی است. خیلی بهتر بود اگر برای Design کلمه دیگری داشتیم، ولی نداریم. به همین دلیل توضیح اینکه طراحی چیست کمی سخت است.
شاید بتوان گفت که طراحی روشیست برای فکر کردن؛ که در اینصورت توضیح آن حتی سختتر هم میشود.
مدتیست به باور بسیاری، دیگر مرزی در دیزاین و طراحی چیزهای مختلف وجود ندارد و هرکسی که بتواند به حل هوشمندانهی مشکلی فکر کند، یک طراح است.
با توجه به تاثیر عمیق مفهوم طراحی در کدنویسی ما، محصول ما، بیزنس ما و حتی زندگی ما، تصمیم گرفتیم کانال «فلسفه دیزاین» را معرفی کنیم تا در مورد فلسفه طراحی صحبت کنیم.
در فارسی ترجمه خوبی برای عبارت Design وجود نداشت، تصمیم گرفتیم از کلمه «دیزاین» استفاده کنیم و برای انتقام از زبان انگلیسی نیز نام کانال را @Dexign گذاشتیم.
اگر «فکر» میکنید، یعنی طــــراح هستید و مطالب کانال «فلسفه دیزاین» برای شما نوشته میشود.
https://t.iss.one/dexign
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
__
طراحی یک اثر هنری، طراحی داخلی یک ساختمان، طراحی نرمافزار، طراحی داستان، طراحی یک گفتگو، طراحی جنگ، طراحی تفکر!
در زبان فارسی ترجمه هر دو کلمه Drawing و Design طراحی است. خیلی بهتر بود اگر برای Design کلمه دیگری داشتیم، ولی نداریم. به همین دلیل توضیح اینکه طراحی چیست کمی سخت است.
شاید بتوان گفت که طراحی روشیست برای فکر کردن؛ که در اینصورت توضیح آن حتی سختتر هم میشود.
مدتیست به باور بسیاری، دیگر مرزی در دیزاین و طراحی چیزهای مختلف وجود ندارد و هرکسی که بتواند به حل هوشمندانهی مشکلی فکر کند، یک طراح است.
با توجه به تاثیر عمیق مفهوم طراحی در کدنویسی ما، محصول ما، بیزنس ما و حتی زندگی ما، تصمیم گرفتیم کانال «فلسفه دیزاین» را معرفی کنیم تا در مورد فلسفه طراحی صحبت کنیم.
در فارسی ترجمه خوبی برای عبارت Design وجود نداشت، تصمیم گرفتیم از کلمه «دیزاین» استفاده کنیم و برای انتقام از زبان انگلیسی نیز نام کانال را @Dexign گذاشتیم.
اگر «فکر» میکنید، یعنی طــــراح هستید و مطالب کانال «فلسفه دیزاین» برای شما نوشته میشود.
https://t.iss.one/dexign
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
__
Telegram
فلسفه دیزاین
این کانال چکیدهای از مقالات روز، نمونههای موفق، ابزارهاییست که ما در DeXign Studio با آن برخورد داشته و معرفیشان میکنیم.
ارتباط با کانال:
@mohsenissapour
منابع و ابزارهای دیزاین:
DexignResources.com
دسخط:
https://daskhat.dexignresources.com
ارتباط با کانال:
@mohsenissapour
منابع و ابزارهای دیزاین:
DexignResources.com
دسخط:
https://daskhat.dexignresources.com
Forwarded from فلسفه دیزاین
دیزاینهایی که کاربر را صدا میزنند
صداها هم مثل بوها و رنگها، موجودات عجیب هستند. شنیدنشان خاطرهها، حس و حال بسیاری را با خود به همراه دارد. برای لحظاتی چشمهایتان را ببندید و فکر کنید که صدای بالا آمدن ویندوز یا مک را به خاطر دارید؟ صدای شروع اخبار ساعت ۱۴ شبکه یک صدا و سیمای ایران را چطور؟ صدای زنگ پیشفرض گوشیهای نوکیا و آیفون را چی؟ یا حتی معروفترین آواهای خاطرات ایرانیان: تبلیغات صاایران، بوتان و مودم دایلآپ!
حدود سه سال قبل، همراه یک تیم خوب به طراحی یک بازی Endless به نام Bring Me Up مشغول بودیم. وقتی به مرحله صداگذاری رسیدیم، در ابتدا تصمیم به دریافت صداهای رایگان روی اینترنت گرفتیم. نتیجه باب میلمان نبود. بعد از کمی فکر شروع کردیم به گفتن آواهایی با دهان و هرکدام را با کامپیوتر کمی تغییر داده و روی بازی قرار دادیم. نتیجه بسیار رضایتبخشتر بود.
گرچه این بازی که در عرض دو هفته طراحی و پیادهسازی شده بود، طرفدار زیادی پیدا نکرد، ولی تجربه ساخت یک بازی و بخصوص صداگذاری آن، به قدری برای من جذاب بود که به یکی از موضوعات مورد علاقهام در دیزاین تبدیل شد.
با مقدمه بالا، احتمالا فهمیدهاید که مقاله امروز درباره دیزاین صداهاست. صداهایی که ما برای دمیدن روح و دادن جان به رابطهای کاربری و محصولاتمان از آنها استفاده میکنیم.
این مقاله از پایهایترین نکات آغاز کرده و با گنجاندن نمونههای مختلفی از صداهای Notificationها و شما را در مسیر یادگیری استفاده کاملا حرفهای از صداها در محصولاتتان یاری خواهد کرد.
پیش از شروع خواندن این مقاله عالی، توجه شما را به ویدئویی که در ادامه ارسال شدهست جلب میکنم که کار بسیار خوبی از مجله WIRED است، درباره رواشناسی صداها.
https://icons8.com/articles/ui-sounds/
(زمان حدودی مطالعه، ۱۲ دقیقه + تماشای ویدئوها)
#آموزش #صدا #رابط_کاربری
@Dexign فلسفه دیزاین
ــــــــــــــــــــ
صداها هم مثل بوها و رنگها، موجودات عجیب هستند. شنیدنشان خاطرهها، حس و حال بسیاری را با خود به همراه دارد. برای لحظاتی چشمهایتان را ببندید و فکر کنید که صدای بالا آمدن ویندوز یا مک را به خاطر دارید؟ صدای شروع اخبار ساعت ۱۴ شبکه یک صدا و سیمای ایران را چطور؟ صدای زنگ پیشفرض گوشیهای نوکیا و آیفون را چی؟ یا حتی معروفترین آواهای خاطرات ایرانیان: تبلیغات صاایران، بوتان و مودم دایلآپ!
حدود سه سال قبل، همراه یک تیم خوب به طراحی یک بازی Endless به نام Bring Me Up مشغول بودیم. وقتی به مرحله صداگذاری رسیدیم، در ابتدا تصمیم به دریافت صداهای رایگان روی اینترنت گرفتیم. نتیجه باب میلمان نبود. بعد از کمی فکر شروع کردیم به گفتن آواهایی با دهان و هرکدام را با کامپیوتر کمی تغییر داده و روی بازی قرار دادیم. نتیجه بسیار رضایتبخشتر بود.
گرچه این بازی که در عرض دو هفته طراحی و پیادهسازی شده بود، طرفدار زیادی پیدا نکرد، ولی تجربه ساخت یک بازی و بخصوص صداگذاری آن، به قدری برای من جذاب بود که به یکی از موضوعات مورد علاقهام در دیزاین تبدیل شد.
با مقدمه بالا، احتمالا فهمیدهاید که مقاله امروز درباره دیزاین صداهاست. صداهایی که ما برای دمیدن روح و دادن جان به رابطهای کاربری و محصولاتمان از آنها استفاده میکنیم.
این مقاله از پایهایترین نکات آغاز کرده و با گنجاندن نمونههای مختلفی از صداهای Notificationها و شما را در مسیر یادگیری استفاده کاملا حرفهای از صداها در محصولاتتان یاری خواهد کرد.
پیش از شروع خواندن این مقاله عالی، توجه شما را به ویدئویی که در ادامه ارسال شدهست جلب میکنم که کار بسیار خوبی از مجله WIRED است، درباره رواشناسی صداها.
https://icons8.com/articles/ui-sounds/
(زمان حدودی مطالعه، ۱۲ دقیقه + تماشای ویدئوها)
#آموزش #صدا #رابط_کاربری
@Dexign فلسفه دیزاین
ــــــــــــــــــــ
blog.icons8.com
UI Sounds: Everything About User Interface Sounds
A sound can significantly improve the users’ experience and be useful where GIU can not. All that it takes - to put good sounds in the right places.
Forwarded from Iran Agile
🔴 تفاوت User Story و Task چیست؟
تفاوت میان داستان کاربری با تَسک چیست؟
داستان کاربری در بک لاگ محصول قرار میگیرد اما تَسک در طول جلسه برنامه ریزی، شناسایی شده و بخشی از بک لاگ اسپرینت هستند. این عبارت با اینکه تعریفی خوبی است اما مفيد نيست، مانند اینکه بگويم نمک چيزی است که در نمکدان وجود دارد و فلفل چيزی است که در فلفل خردکن! مطمئنا داستان ها در بکلاگ محصول و تَسک در بکلاگ اسپرینت يافت می شوند.
اما تفاوت اساسی بين اين دو چيست؟
داستان عموما چيزی است که بيش از يک نفر بر روی آن کار می کنند ولی تَسک فقط توسط يک نفر انجام می شود.
داستان کاربری معمولا قابليتی است که برای کاربر نهایی قابل مشاهده است و توسط تيمی شامل برنامه نويس، تستر شاید طراح رابط کاربری یا آناليزور و یا شايد طراح پايگاه داده و … توسعه داده می شود. به ندرت پيش می آید يک داستان کاربری تماما توسط يک فرد توسعه داده شود ( اگر زمانی چنين اتفاقی هم رخ دهد شخص چندين نقش را به تنهايی ايفا می کند)
از سوی ديگر يک تَسک، معمولا چيزی شبيه کد زدن … ، طراحی … ، ايجاد داده های تست برای …. ، اتوماسيون … و غيره است. تمام اين موارد چيزهايی هستند که بايد يک نفر آنها را انجام دهد.
شايد شما استدلال کنيد که برخی از آنها به صورت جفتی انجام می شوند و يا بايد انجام شوند، بپذيريد که اين يک تفاوت کوچک بين داستان کاربری و تَسک است. جفت شدن در واقع دو مغز با يک جفت دست هستند که بر روی يک نوع کار با هم مشارکت دارند. و اين با انواع کارهايی که در يک داستان کاربری معمولی رخ می دهد متفاوت است. برخی از وظايف به صورت جلسه هستند مثلا بازبینی يک طراحی توسط سه نفر از اعضای تيم، همانطور که گفته شد اين کار به عنوان يک وظيفه در نظر گرفته می شود تا يک داستان کاربری.
پس شايد بهترين تمايز همين باشد که داستان ها شامل انواع مختلفی از کارها هستند (نظير برنامه نويسی، تست، طراحی پايگاه داده ها، طراحی واسط کاربری، آناليز و …) در حاليکه وظايف به يک نوع کار محدود می شوند.
✅ https://goo.gl/EK3c96
@iranagile
تفاوت میان داستان کاربری با تَسک چیست؟
داستان کاربری در بک لاگ محصول قرار میگیرد اما تَسک در طول جلسه برنامه ریزی، شناسایی شده و بخشی از بک لاگ اسپرینت هستند. این عبارت با اینکه تعریفی خوبی است اما مفيد نيست، مانند اینکه بگويم نمک چيزی است که در نمکدان وجود دارد و فلفل چيزی است که در فلفل خردکن! مطمئنا داستان ها در بکلاگ محصول و تَسک در بکلاگ اسپرینت يافت می شوند.
اما تفاوت اساسی بين اين دو چيست؟
داستان عموما چيزی است که بيش از يک نفر بر روی آن کار می کنند ولی تَسک فقط توسط يک نفر انجام می شود.
داستان کاربری معمولا قابليتی است که برای کاربر نهایی قابل مشاهده است و توسط تيمی شامل برنامه نويس، تستر شاید طراح رابط کاربری یا آناليزور و یا شايد طراح پايگاه داده و … توسعه داده می شود. به ندرت پيش می آید يک داستان کاربری تماما توسط يک فرد توسعه داده شود ( اگر زمانی چنين اتفاقی هم رخ دهد شخص چندين نقش را به تنهايی ايفا می کند)
از سوی ديگر يک تَسک، معمولا چيزی شبيه کد زدن … ، طراحی … ، ايجاد داده های تست برای …. ، اتوماسيون … و غيره است. تمام اين موارد چيزهايی هستند که بايد يک نفر آنها را انجام دهد.
شايد شما استدلال کنيد که برخی از آنها به صورت جفتی انجام می شوند و يا بايد انجام شوند، بپذيريد که اين يک تفاوت کوچک بين داستان کاربری و تَسک است. جفت شدن در واقع دو مغز با يک جفت دست هستند که بر روی يک نوع کار با هم مشارکت دارند. و اين با انواع کارهايی که در يک داستان کاربری معمولی رخ می دهد متفاوت است. برخی از وظايف به صورت جلسه هستند مثلا بازبینی يک طراحی توسط سه نفر از اعضای تيم، همانطور که گفته شد اين کار به عنوان يک وظيفه در نظر گرفته می شود تا يک داستان کاربری.
پس شايد بهترين تمايز همين باشد که داستان ها شامل انواع مختلفی از کارها هستند (نظير برنامه نويسی، تست، طراحی پايگاه داده ها، طراحی واسط کاربری، آناليز و …) در حاليکه وظايف به يک نوع کار محدود می شوند.
✅ https://goo.gl/EK3c96
@iranagile
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. نرم افزاری برای آموزش امنیت به صورت واقعی!
#security
https://t.iss.one/SoftwarePhilosophy/1020
۲. توضیحات اسکات آلن در مورد مرتبسازی کدها
#refactoring #architecture #aspnet
https://t.iss.one/SoftwarePhilosophy/1022
https://t.iss.one/SoftwarePhilosophy/1023
۳. اگر «فکر» میکنید، یعنی طــــراح هستید!
#Design
https://t.iss.one/SoftwarePhilosophy/1024
۴. دیزاینهایی که کاربر را صدا میزنند (فلسفه دیزاین)
#Design
https://t.iss.one/SoftwarePhilosophy/1025
https://t.iss.one/SoftwarePhilosophy/1026
۵. تفاوت User Story و Task چیست؟ (Iran Agile)
https://t.iss.one/SoftwarePhilosophy/1027
ـــــــــــ
@SoftwarePhilosophy
۱. نرم افزاری برای آموزش امنیت به صورت واقعی!
#security
https://t.iss.one/SoftwarePhilosophy/1020
۲. توضیحات اسکات آلن در مورد مرتبسازی کدها
#refactoring #architecture #aspnet
https://t.iss.one/SoftwarePhilosophy/1022
https://t.iss.one/SoftwarePhilosophy/1023
۳. اگر «فکر» میکنید، یعنی طــــراح هستید!
#Design
https://t.iss.one/SoftwarePhilosophy/1024
۴. دیزاینهایی که کاربر را صدا میزنند (فلسفه دیزاین)
#Design
https://t.iss.one/SoftwarePhilosophy/1025
https://t.iss.one/SoftwarePhilosophy/1026
۵. تفاوت User Story و Task چیست؟ (Iran Agile)
https://t.iss.one/SoftwarePhilosophy/1027
ـــــــــــ
@SoftwarePhilosophy
Telegram
Software Philosophy
نرم افزاری برای آموزش امنیت به صورت واقعی! Web Goat یک پیاده سازی نرم افزار وب با آسیب پذیریهای امنیتی برای آموزش امنیت میباشد که توسط OWASP توسعه داده شده است. برای مثال کاربر با انجام حملهی SQL Injection بصورت واقعی به این نرم افزار و سرقت شماره کارتهای…
#پست_مجدد این پست تا به حال بیش از ۱۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
عنوان URLs are UI، عنوانی بسیار جذاب برای مقاله جدید scott hanselman است. نکته خیلی جالبی که بسیاری از برنامههای امروزی ندارند. او در این مقاله توضیح میدهد که خود URL ها به قسمتی از UI برنامه تبدیل شدهاند و خوانا بودن آن و قابل خواندن بودن آنها بسیار مهم است.
برای مثال لینک یک فایل در OneDrive شبیه
https://onedrive.live.com/?id=CD0633A7367371152C%21172&cid=CD06A73371152C
است. در حالیکه لینک یک فایل مشابه در DropBox شبیه
https://www.dropbox.com/home/Games
است.
در مقاله زیر توضیح داده شدهاست که برای مثال مدلی که در StackOverflow استفاده میشود چقدر خوب و خلاقانه است.
https://stackoverflow.com/users/1831530/mehrandvd
در این مدل هم از کد و هم از نام استفاده شده ولی قسمت نام بیاثر است و با حذف آن هنوز لینک کار میکند.
https://www.hanselman.com/blog/URLsAreUI.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/YHoU30e1jDD
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
برای مثال لینک یک فایل در OneDrive شبیه
https://onedrive.live.com/?id=CD0633A7367371152C%21172&cid=CD06A73371152C
است. در حالیکه لینک یک فایل مشابه در DropBox شبیه
https://www.dropbox.com/home/Games
است.
در مقاله زیر توضیح داده شدهاست که برای مثال مدلی که در StackOverflow استفاده میشود چقدر خوب و خلاقانه است.
https://stackoverflow.com/users/1831530/mehrandvd
در این مدل هم از کد و هم از نام استفاده شده ولی قسمت نام بیاثر است و با حذف آن هنوز لینک کار میکند.
https://www.hanselman.com/blog/URLsAreUI.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/YHoU30e1jDD
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
زبان JavaScript را با کارایی بالا و بدون خطاهای زمان اجرا تولید کنید.
زبانهای برنامه نویسی ML-family از جمله Haskell و Ocaml کامپایلرهایی دارند که تقریبا همهی خطاها را در زمان کامپایل شناسایی میکنند و امکان بروز خطا در محیط تولید را به صفر میرسانند. زبانهای ML-family برای back-end هستند و به دلیل سختی یادگیری و کاربری٬ چندان مورد توجه برنامهنویسان قرار نگرفتند. تلاشهای زیادی برای آوردن robustness زبانهای ML-family به برنامهنویسی front-end انجام شد که نتیجهی آن پروژههایی از جمله Fay و GHCJS هستند که به JavaScript کامپایل میشوند. اما همچنان به دلیل سختی یادگیری و کاربری٬ این پروژهها هم منزوی شدند. یادگیری JavaScript ساده است اما نگهداری پروژههای بزرگ JavaScript کابوس دهشتناکی است. زبانی با robustness زبانهای ML-family و کاربری بالای زبان JavaScript می تواند پاسخگوی نیاز برنامهنویسی front-end باشد. Elm با چنین نگرشی ایجاد شد. Elm زبان برنامه نویسی functional برای ایجاد برنامههای front-end است. Elm بهترینهای دو دنیا را برای ساخت راحتتر برنامه های robust در خود جای داده است. Richard Feldman در سخنرانی خود در کنفراس Goto 2017 به معرفی Elm پرداخته است.
https://www.youtube.com/watch?v=28aJOb1A34o
همچنین لینک زیر چگونگی کاربری Elmرا تشریح می کند.
https://guide.elm-lang.org/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/uASh30e4wRc
#شراره_لطفی (https://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
زبانهای برنامه نویسی ML-family از جمله Haskell و Ocaml کامپایلرهایی دارند که تقریبا همهی خطاها را در زمان کامپایل شناسایی میکنند و امکان بروز خطا در محیط تولید را به صفر میرسانند. زبانهای ML-family برای back-end هستند و به دلیل سختی یادگیری و کاربری٬ چندان مورد توجه برنامهنویسان قرار نگرفتند. تلاشهای زیادی برای آوردن robustness زبانهای ML-family به برنامهنویسی front-end انجام شد که نتیجهی آن پروژههایی از جمله Fay و GHCJS هستند که به JavaScript کامپایل میشوند. اما همچنان به دلیل سختی یادگیری و کاربری٬ این پروژهها هم منزوی شدند. یادگیری JavaScript ساده است اما نگهداری پروژههای بزرگ JavaScript کابوس دهشتناکی است. زبانی با robustness زبانهای ML-family و کاربری بالای زبان JavaScript می تواند پاسخگوی نیاز برنامهنویسی front-end باشد. Elm با چنین نگرشی ایجاد شد. Elm زبان برنامه نویسی functional برای ایجاد برنامههای front-end است. Elm بهترینهای دو دنیا را برای ساخت راحتتر برنامه های robust در خود جای داده است. Richard Feldman در سخنرانی خود در کنفراس Goto 2017 به معرفی Elm پرداخته است.
https://www.youtube.com/watch?v=28aJOb1A34o
همچنین لینک زیر چگونگی کاربری Elmرا تشریح می کند.
https://guide.elm-lang.org/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/uASh30e4wRc
#شراره_لطفی (https://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
YouTube
Introducing Elm to a JavaScript App • Richard Feldman • GOTO 2017
This presentation was recorded at GOTO Chicago 2017. #gotocon #gotochgo
https://gotochgo.com
Richard Feldman - Author of “Elm in Action” @rtfeldman
ABSTRACT
Have you wanted to try Elm on a JavaScript project, but rewriting the whole code base was out of…
https://gotochgo.com
Richard Feldman - Author of “Elm in Action” @rtfeldman
ABSTRACT
Have you wanted to try Elm on a JavaScript project, but rewriting the whole code base was out of…
Forwarded from فلسفه دیزاین
حاشیههایی شیرینتر از داستان
چند وقتیست که از کنفرانس اپل میگذرد. همان کنفرانسی که در آن iPhone X و برخی محصولات دیگرش را معرفی کرد.
مثل همیشه گمانهزنیهایی پیش از کنفرانس شده بود و همه کسانی که پیگیر بودند، میدانستند که باید منتظر چه چیزی باشند. خود اپل هم که انگار از این شایعات و حدسهای مردم لذت میبرد، با منتشر کردن عکسی از لوگوی کنفرانس، شرلوک درون مردم را قلقلک داد.
خلاصه کنفرانس برگزار شد و تغییراتی بزرگ و کوچک روی محصولات پیشین و نمونه جدید آنها معرفی شد. یکی از پرسروصداترین محصولات امسال اپل، iPhone X است. منظور من از سروصدا لزوما صحبتهای خوب درباره این دستگاه جدید نیست. این آیفون جدید، به سنسور تشخیص چهرهای (ساختاری مشابه دستگاههای Kinect) مجهز است که باعث شده طراحان اپل نتوانند صفحه نمایش دستگاه را بصورت لبه تا لبه (edge-to-edge) طراحی کنند. مردم در شبکههای اجتماعی، نام این قسمت را The Notch (به معنی فرورفتگی) نامیدند و شروع به ارائه ایدههای جالب، خندهدار و بعضا تحلیلهای مختلفی کردند.
مقاله امروز به بررسی حواشی و اتفاقات و صحبتهایی که درباره آیفون جدید در شبکههای اجتماعی شکل گرفت میپردازد و منابع و ایدههای خوبی را در طول مقاله معرفی میکند.
پیشنهاد میکنم این مقاله را از دست ندهید.
https://blog.prototypr.io/notch-crazy-iphone-x-mad-475f43d6ee26
(زمان حدودی مطالعه، ۱۰ دقیقه)
#بررسی #محصول #حواشی
@Dexign فلسفه دیزاین
ــــــــــــــــــ
چند وقتیست که از کنفرانس اپل میگذرد. همان کنفرانسی که در آن iPhone X و برخی محصولات دیگرش را معرفی کرد.
مثل همیشه گمانهزنیهایی پیش از کنفرانس شده بود و همه کسانی که پیگیر بودند، میدانستند که باید منتظر چه چیزی باشند. خود اپل هم که انگار از این شایعات و حدسهای مردم لذت میبرد، با منتشر کردن عکسی از لوگوی کنفرانس، شرلوک درون مردم را قلقلک داد.
خلاصه کنفرانس برگزار شد و تغییراتی بزرگ و کوچک روی محصولات پیشین و نمونه جدید آنها معرفی شد. یکی از پرسروصداترین محصولات امسال اپل، iPhone X است. منظور من از سروصدا لزوما صحبتهای خوب درباره این دستگاه جدید نیست. این آیفون جدید، به سنسور تشخیص چهرهای (ساختاری مشابه دستگاههای Kinect) مجهز است که باعث شده طراحان اپل نتوانند صفحه نمایش دستگاه را بصورت لبه تا لبه (edge-to-edge) طراحی کنند. مردم در شبکههای اجتماعی، نام این قسمت را The Notch (به معنی فرورفتگی) نامیدند و شروع به ارائه ایدههای جالب، خندهدار و بعضا تحلیلهای مختلفی کردند.
مقاله امروز به بررسی حواشی و اتفاقات و صحبتهایی که درباره آیفون جدید در شبکههای اجتماعی شکل گرفت میپردازد و منابع و ایدههای خوبی را در طول مقاله معرفی میکند.
پیشنهاد میکنم این مقاله را از دست ندهید.
https://blog.prototypr.io/notch-crazy-iphone-x-mad-475f43d6ee26
(زمان حدودی مطالعه، ۱۰ دقیقه)
#بررسی #محصول #حواشی
@Dexign فلسفه دیزاین
ــــــــــــــــــ
Medium
‘Notch’ crazy, iPhone X mad 📱🤡
What designers think of iPhone X
Forwarded from Iran Agile
🔴 واگذاری اختیارات به تیمهای خودسازمانده
معنی اين جمله که می گويد: « تيم های چابک خود سازمانده هستند» چيست؟ و اينکه اصطلاح درستی است؟ برخی از افراد می گويند تيم ها خود مديريت هستند. برای درک اينکه کدام يک از اين اصطلاحات مناسب تر است بياييد چهار سطح از خودمختاری را که تيم ها می توانند داشته باشند را در نظر بگيريد.
⏬ چهار شیوه توزيع اختیارت:
ريچارد هاکمن استاد دانشگاه هاروارد چهار سطح تخصيص اختيار و قدرت به تيم ها را مورد بررسی قرار داده است. بياييد نگاهی بياندازيم به چهار سطح واگذاری قدرت به تيم ها از منظر هاکمن با شروع از کمترين سطح.
1⃣ يک تيم با کمترين سطح اختيار توسط يک مدير هدايت می شود (Manager-led). اين گونه تيم ها برای انجام کارهای تخصيص يافته به آنها اختيار و قدرت دارند ولی بر روی فرآيندهايشان هيچ گونه قدرت و اختياری ندارند و فقط مدير بر اين فرآيندها مديريت دارد.
2⃣ سطح دوم از منظر هاکمن تيم های خود مديريت (self-managing) هستند. يعنی علاوه بر اختيار و قدرت در انجام وظايف می توانند فرآيندهايشان را نيز خود مديريت کنند. تيم خود مديريت می تواند تصميم بگيرد چگونه کار کند به عنوان مثال می تواند درباره استفاده و بکارگيری نگرش چابک تصميم گيری کند.
3⃣ با افزايش سطح اختيار ، با تيم های خود طراح (self-designing) مواجه می شويم. آنها می توانند کسانی که در تيم هستند را تعديل يا تغيير دهند. اين نوع از تيمها می توانند فردی را از تيم اخراج کنند، می توانند در مورد انتقال يا استخدام افراد ديگر در تيم و … تصميم گيری کنند. در برخی از موارد هم تيمهای خود طراح اختيار گزارش دادن به افراد مرتبط داخل تيم يا خارج تيم را دارند.
4⃣ آخرين نوع از تيم ها، و يکی از مختارترين آنها، تيم های خودمختار (self-governing) هستند. تيم های خودمختار علاوه بر ساير اختيارات، اختيار تغيير اهداف اصلی تيم را هم دارند. تيم های خودمختار می توانند تصميم بگيرند به جای يک محصول اندازه گيری صوتی يک بازی ويدئویی بسازند.
⏬ نوع تيم اختيارات
تيم های مدير محور فقط بر روی انجام وظايف محوله اختيار دارند.
تيم های خود مديريت يا خودسازمانده علاوه بر مورد بالا، اختيار تعيين چگونگی انجام شدن کار (فرآيندها) را نيز دارند.
تيم های خود طراح علاوه بر موارد بالا، در تعيين نفراتی که باید در تيم باشند و گاهی نيز بر روی گزارش دهی ها اختيار دارند
تيم های خودمختار حتی نسبت به تغيير اهداف اصلی تيم نيز مختار هستند
کجای اين سلسله مراتب برای خودسازماندهی مناسب است؟
در سلسله مراتب قدرت و اختيارات هاکمن، تيم های خودسازمانده (self-organizing) چابک در کلاس تيم های خود مديريت قرار می گيرند. تيم های خود سازمانده چابک کارهايشان را خود مديريت می کنند: کدام يک از افراد تيم بايد اين وظيفه را انجام دهد؟ و همچنين درباره چگونگی انجام آن کار هم خودشان مختار هستند: بايد با اسکرام شروع کنيم يا کانبان؟ اسپرينت ما بايد چقدر طول بکشد؟
تيم های چابک خود طراح و خودمختار نيستند، به عبارت ديگر تيم های خود سازمانده بر روی وظايف و فرآيندهايي که استفاده می کنند مختار هستند اما اختياری بر روی نفراتی که بايد در تيم باشند يا اهداف تيم ندارند.
تيم های چابک خود سازمانده هستند يا خود مديريت؟
هر کدام از اينها را می توانيد در نظر بگيريد. اما من اصطلاح خود سازمانده را به دو دليل ترجيح می دهم :
نخست اينکه، در اولين مقاله منتشر شده درباره چابک نويسندگان مقاله تاکوچی و نوناکا از اصطلاح خود سازمانده به عنوان يکی از شش ويژگی مورد نياز برای ايجاد يک فرآيند انعطاف پذير سريع نام برده اند.
دوم اينکه من ريشه های اصطلاح خود سازمانده را در نظريه آشوب يافتم که در فکرکردن درباره رفتار تيم مفيد است. گرد آمدن و ازدحام پرندگان در پرواز يک رفتار خود سازمانده است. يا يک کلونی مورچه، يک کندوی زنبور عسل و يا الگوی ماشين ها در بزرگراه. اين مثالها از خود سازماندهی در طبيعت، اغلب نمونه های مفيدی برای نشان دادن معنای خود سازماندهی تيم های چابک هستند.
مثلا من اغلب شهر سنجابهای زمینی را می بينم، مجموعه ای از تونل هايی که اين حيوانات کوچک آن را حفر کرده اند. اين موجودات تونل های خود را بر مبنای يک طرح جامع پيش بينی شده حفر نمی کنند. آنها حفر می کنند و اگر به صخره ای برخورد کردند اطراف آن را حفر می کنند. تيم کار خود را در يک جهت شروع میکند، اگر ثابت شود مسير نامعتبر است تيم در اطراف مانع تغیير مسير می دهد درست مانند سنجاب های زير زمينی.
https://goo.gl/6puZ9J
@iranagile
معنی اين جمله که می گويد: « تيم های چابک خود سازمانده هستند» چيست؟ و اينکه اصطلاح درستی است؟ برخی از افراد می گويند تيم ها خود مديريت هستند. برای درک اينکه کدام يک از اين اصطلاحات مناسب تر است بياييد چهار سطح از خودمختاری را که تيم ها می توانند داشته باشند را در نظر بگيريد.
⏬ چهار شیوه توزيع اختیارت:
ريچارد هاکمن استاد دانشگاه هاروارد چهار سطح تخصيص اختيار و قدرت به تيم ها را مورد بررسی قرار داده است. بياييد نگاهی بياندازيم به چهار سطح واگذاری قدرت به تيم ها از منظر هاکمن با شروع از کمترين سطح.
1⃣ يک تيم با کمترين سطح اختيار توسط يک مدير هدايت می شود (Manager-led). اين گونه تيم ها برای انجام کارهای تخصيص يافته به آنها اختيار و قدرت دارند ولی بر روی فرآيندهايشان هيچ گونه قدرت و اختياری ندارند و فقط مدير بر اين فرآيندها مديريت دارد.
2⃣ سطح دوم از منظر هاکمن تيم های خود مديريت (self-managing) هستند. يعنی علاوه بر اختيار و قدرت در انجام وظايف می توانند فرآيندهايشان را نيز خود مديريت کنند. تيم خود مديريت می تواند تصميم بگيرد چگونه کار کند به عنوان مثال می تواند درباره استفاده و بکارگيری نگرش چابک تصميم گيری کند.
3⃣ با افزايش سطح اختيار ، با تيم های خود طراح (self-designing) مواجه می شويم. آنها می توانند کسانی که در تيم هستند را تعديل يا تغيير دهند. اين نوع از تيمها می توانند فردی را از تيم اخراج کنند، می توانند در مورد انتقال يا استخدام افراد ديگر در تيم و … تصميم گيری کنند. در برخی از موارد هم تيمهای خود طراح اختيار گزارش دادن به افراد مرتبط داخل تيم يا خارج تيم را دارند.
4⃣ آخرين نوع از تيم ها، و يکی از مختارترين آنها، تيم های خودمختار (self-governing) هستند. تيم های خودمختار علاوه بر ساير اختيارات، اختيار تغيير اهداف اصلی تيم را هم دارند. تيم های خودمختار می توانند تصميم بگيرند به جای يک محصول اندازه گيری صوتی يک بازی ويدئویی بسازند.
⏬ نوع تيم اختيارات
تيم های مدير محور فقط بر روی انجام وظايف محوله اختيار دارند.
تيم های خود مديريت يا خودسازمانده علاوه بر مورد بالا، اختيار تعيين چگونگی انجام شدن کار (فرآيندها) را نيز دارند.
تيم های خود طراح علاوه بر موارد بالا، در تعيين نفراتی که باید در تيم باشند و گاهی نيز بر روی گزارش دهی ها اختيار دارند
تيم های خودمختار حتی نسبت به تغيير اهداف اصلی تيم نيز مختار هستند
کجای اين سلسله مراتب برای خودسازماندهی مناسب است؟
در سلسله مراتب قدرت و اختيارات هاکمن، تيم های خودسازمانده (self-organizing) چابک در کلاس تيم های خود مديريت قرار می گيرند. تيم های خود سازمانده چابک کارهايشان را خود مديريت می کنند: کدام يک از افراد تيم بايد اين وظيفه را انجام دهد؟ و همچنين درباره چگونگی انجام آن کار هم خودشان مختار هستند: بايد با اسکرام شروع کنيم يا کانبان؟ اسپرينت ما بايد چقدر طول بکشد؟
تيم های چابک خود طراح و خودمختار نيستند، به عبارت ديگر تيم های خود سازمانده بر روی وظايف و فرآيندهايي که استفاده می کنند مختار هستند اما اختياری بر روی نفراتی که بايد در تيم باشند يا اهداف تيم ندارند.
تيم های چابک خود سازمانده هستند يا خود مديريت؟
هر کدام از اينها را می توانيد در نظر بگيريد. اما من اصطلاح خود سازمانده را به دو دليل ترجيح می دهم :
نخست اينکه، در اولين مقاله منتشر شده درباره چابک نويسندگان مقاله تاکوچی و نوناکا از اصطلاح خود سازمانده به عنوان يکی از شش ويژگی مورد نياز برای ايجاد يک فرآيند انعطاف پذير سريع نام برده اند.
دوم اينکه من ريشه های اصطلاح خود سازمانده را در نظريه آشوب يافتم که در فکرکردن درباره رفتار تيم مفيد است. گرد آمدن و ازدحام پرندگان در پرواز يک رفتار خود سازمانده است. يا يک کلونی مورچه، يک کندوی زنبور عسل و يا الگوی ماشين ها در بزرگراه. اين مثالها از خود سازماندهی در طبيعت، اغلب نمونه های مفيدی برای نشان دادن معنای خود سازماندهی تيم های چابک هستند.
مثلا من اغلب شهر سنجابهای زمینی را می بينم، مجموعه ای از تونل هايی که اين حيوانات کوچک آن را حفر کرده اند. اين موجودات تونل های خود را بر مبنای يک طرح جامع پيش بينی شده حفر نمی کنند. آنها حفر می کنند و اگر به صخره ای برخورد کردند اطراف آن را حفر می کنند. تيم کار خود را در يک جهت شروع میکند، اگر ثابت شود مسير نامعتبر است تيم در اطراف مانع تغیير مسير می دهد درست مانند سنجاب های زير زمينی.
https://goo.gl/6puZ9J
@iranagile
فیسبوک علاوه بر توسعه React برای وب و موبایل قدم به حوزهی دیگری نیز نهاده است. با استفاده از React VR میتوان با استفاده از جاوا اسکریپت نرم افزارهای واقعیت مجازی تولیدی نمود.
https://facebook.github.io/react-vr
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/sjGB30gAX3w
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
https://facebook.github.io/react-vr
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/sjGB30gAX3w
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
امروزه در بسیاری از پروژهها از Web Sockets استفاده میشود. در این نوع ارتباط در کنار ایجاد ارتباطی از سرور به کلاینت که از آن برای ارسال پیامها استفاده میشود، ارتباطی از کلاینت به سرور نیز باز میشود که عموما مورد استفاده قرار نمیگیرد. ضمن اینکه با توجه به متفاوت بودن پروتکل Web Sockets با HTTP، بسیاری از مواردی که بر روی پروتکل HTTP تنظیم میکنیم (مانند CORS - Compression و ...) بر روی Web Sockets اعمال نمیشود. Server Sent Events در قیاس با Web Sockets گزینهای مناسبتر برای اکثریت پروژهها میباشد که کاملا بر اساس پروتکل HTTP ایجاد شده و سربار کمتری نیز دارد. لینک زیر حاوی توضیحی نسبتا مفصل از مزایایی است که Server Sent Events میتواند برای پروژه شما به ارمغان آورد.
https://docs.bit-framework.com/docs/design-backgrounds/server-sent-events-or-web-sockets.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/2nBc30ebM8o
#یاسر_مرادی (https://ow.ly/Ph6w30ebM21)
کانال تلگرام:
@SoftwarePhilosophy
___
https://docs.bit-framework.com/docs/design-backgrounds/server-sent-events-or-web-sockets.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/2nBc30ebM8o
#یاسر_مرادی (https://ow.ly/Ph6w30ebM21)
کانال تلگرام:
@SoftwarePhilosophy
___
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. استاندارد طراحی URL از لحاظ UX
#ux #webapi #architecture
https://t.iss.one/SoftwarePhilosophy/1030
۲. آشنایی با زبان Elm
#elm #javascript #haskel
https://t.iss.one/SoftwarePhilosophy/1032
https://t.iss.one/SoftwarePhilosophy/1033
۳. حاشیههایی شیرینتر از داستان (فلسفه دیزاین)
#design
https://t.iss.one/SoftwarePhilosophy/1034
۴. واگذاری اختیارات به تیمهای خودسازمانده (Iran Agile)
#agile
https://t.iss.one/SoftwarePhilosophy/1035
۵. استفاده از React VR و جاوا اسکریپت برای تولید نرم افزارهای واقعیت مجازی
#react #vr #javascript
https://t.iss.one/SoftwarePhilosophy/1036
۶. مزایای Server Sent Events برای پروژههای تحت وب
#dotnet #web
https://t.iss.one/SoftwarePhilosophy/1038
ـــــــــــ
@SoftwarePhilosophy
۱. استاندارد طراحی URL از لحاظ UX
#ux #webapi #architecture
https://t.iss.one/SoftwarePhilosophy/1030
۲. آشنایی با زبان Elm
#elm #javascript #haskel
https://t.iss.one/SoftwarePhilosophy/1032
https://t.iss.one/SoftwarePhilosophy/1033
۳. حاشیههایی شیرینتر از داستان (فلسفه دیزاین)
#design
https://t.iss.one/SoftwarePhilosophy/1034
۴. واگذاری اختیارات به تیمهای خودسازمانده (Iran Agile)
#agile
https://t.iss.one/SoftwarePhilosophy/1035
۵. استفاده از React VR و جاوا اسکریپت برای تولید نرم افزارهای واقعیت مجازی
#react #vr #javascript
https://t.iss.one/SoftwarePhilosophy/1036
۶. مزایای Server Sent Events برای پروژههای تحت وب
#dotnet #web
https://t.iss.one/SoftwarePhilosophy/1038
ـــــــــــ
@SoftwarePhilosophy
#پست_مجدد این پست تا به حال بیش از ۱۳۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
بررسی کدها و اجزای نرم افزار از نقطه نظر معماری و طراحی، یافتن وابستگی میان اجزای کد، پیدا کردن مشکلات در کد در زمان اجرا و خواندن کدهای دیگران یکی از مسایلی بوده که همیشه برنامه نویسان و طراحان سیستمها با آن روبرو هستند. یکی از قابلیتهای پنهان و بسیار قدرتمند Visual Studio که از نسخه ۲۰۱۵ ارائه شده است Code Map میباشد که با Visualize کردن باعث میشود کارهای گفته شده به سادگی بیشتر انجام پذیرد.
https://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B346
https://docs.microsoft.com/en-us/visualstudio/modeling/use-code-maps-to-debug-your-applications
https://msdn.microsoft.com/en-us/library/dd409453.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/Kjey30edWbn
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
https://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B346
https://docs.microsoft.com/en-us/visualstudio/modeling/use-code-maps-to-debug-your-applications
https://msdn.microsoft.com/en-us/library/dd409453.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/Kjey30edWbn
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
Channel 9
Understand Code with Code Maps
Code and debugger maps help you understand and navigate through code when troubleshooting and designing new functionality. Come and learn how code maps help you: understand the flow of code when debug