شرکت‌های مطرح از یک دیزاینر چه می‌خواهند؟

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

خیلی به این مساله فکر کردم که این شرکت‌ها چگونه افرادی را استخدام می‌کنند و از آن افراد چه می‌خواهند؟

همه ما می‌دانیم که «دیزاین» مدتهاست از تک‌کلمه‌ای بودن یا تک‌مفهمومی بودن خارج شده است. دیزاین در هر بخشی معنی خاص خودش را دارد، می‌توان فکر، زندگی، مسافرت و حتی روش انجام یک بازی را دیزاین کرد.

دیزاین خارج از بحث‌های رابط و تجربه کاربری زنده است و به هرگونه برنامه‌ریزی برای انجام کاری هم می‌توان آن را نسبت داد.

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

دقت به جزئیاتی که دیگران ممکن است آن‌ها را کوچک بشمارند، تفاوت شما نسبت به بقیه است.

فست‌کمپانی، مقاله‌ای منتشر کرده که در آن به مواردی که شرکت‌های بزرگ برای استخدام دیزاینرها در نظر می‌گیرند اشاره می‌کند.

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

این مقاله هرچند کوتاه است ولی شامل نکاتی می‌شود که ممکن است دید مخاطبان را نسبت به جهان‌بینی شرکت‌های بزرگ بازتر کند.

https://bit.ly/dxgn622

(زمان حدودی مطالعه: ۵ دقیقه)

نویسنده: آرش اصغری

#استخدام #دیزاین

@Dexign فلسفه دیزاین

_____

‏ریموت بودن برای ما یه انتخاب بوده نه یه اجبار!

امشب قراره در مورد تجربه یه شرکت ۵۰ نفره که ۴ ساله همه تیم‌هاش ریموتن صحبت کنم. بله، همه تیم‌های ما در ‎ملک‌رادار اعم از برنامه‌نویسی، مارکتینگ، فروش و حتی پشتیبانی کاملا ریموت و از شهرهای مختلف کار می‌کنن.

instagram.com/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy

_____

بیست سوالی که یک اسکرام مستر جدید از تیم خود باید بپرسد

https://age-of-product.com/20-questions-a-new-scrum-master-should-ask-her-team-to-get-up-to-speed/amp/

@iranagile

✅ مدیریت دیتابیس های SQLite با SQLiteStudio

برنامه SQLiteStudio یکی از بهترین و محبوب ترین برنامه های مدیریت دیتابیس های SQLite هست که به صورت رایگان و Cross-Platform وجود داره.
https://github.com/pawelsalawa/sqlitestudio

🔸برنامه محبوب دیگر SQLiteBrowser نام داره که این هم رایگان و Cross-Platform هست
https://sqlitebrowser.org/
https://github.com/sqlitebrowser/sqlitebrowser

🔹اگرم خیلی کم سروکارتون به SQLite میافته و صرفا یه ابزار آنلاین خوب واسه کار باهاش نیاز دارین سایت SQLiteOnline بهترینشه
https://sqliteonline.com/
__________________
@DotNetZoom

موفقیت در دیزاین به سبک اپل

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

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

اگر نیم نگاهی هم به شعار این شرکت "Think Different" داشته باشیم، می‌توان دریافت که رمز موفقیت آن در نحوه تفکر درباره محصول نهفته است. روند طراحی محصولات اپل درواقع شیوه تفکر در مورد آن است. شیوه‌ای که همه کارکنان اپل در پیش می‌گیرند تا محصولی در جهت تغییر دنیا طراحی کنند. این شیوه تفکر با متحول کردن نحوه مدیریت، همراه ساختن کارکنان، توجه ویژه به جزئیات، تاکید ویژه بر روی سادگی محصول و تمرکز بر روی طراحی باعث شد محصولاتی متفاوت تولید شوند و دنیای تکنولوژی را تحت تاثیر قرار داده و تغییر دهند.

برای اینکه با رمز و رازهای موفقیت اپل در تسخیر بازار و قلب طرفداران آن بیشتر آشنا شوید، پیشنهاد می‌کنیم مقاله زیر را مطالعه کنید:

https://bit.ly/dxgn625

(زمان حدودی مطالعه: ۱۰ دقیقه)

نویسنده: محمدرضا پناهی

#دیزاین #تفکر_طراحی #تجربه_کاربری
@Dexign فلسفه دیزاین

_

#پست_مجدد این پست تا به حال نزدیک به ۱۶۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

هر موقع از ویژگی های جدید سی شارپ 8 صحبت می‌شه عمدتا Nullable Reference Type ها بیشتر خودش رو نشون می‌ده.

به همین دلیل احتمالا (به نظر من) بزرگترین چالش در ارتقاء C # 8.0 باید توی همین ویژگی باشه .

وقتی از این ویژگی استفاده می‌کنیم یکی از دلایلی که باعث ایجاد چالش می‌شه استفاده از جنریک متدهاست.

وقتی ما از ویژگی Nullable Reference Type ها استفاده می‌کنیم، باید صراحتا بگیم که نوع ورودی و خروجی دقیقا چیه.

ولی این امر توی جنریک‌ها به این راحتی نیست؛ ما ورودی یا خروجیمون از نوع T ست که اصلا نمی‌دونیم چیه (حتی با اضافه کردن قیود به جنریک‌ها بازم دقیق متوجه نمی‌شیم!)

پس به نظر من این می‌تونه یک چالش خیلی بزرگ باشه .

〰️〰️〰️〰️〰️〰️〰️

⁉️خب حالا باید چه کار کنیم ؟

ماکروسافت برای برطرف کردن این مشکل یکسری اتربیوت ارائه کرده که لیست اکثر اون‌ها رو توی پست‌های قبلی معرفی شده.
با استفاده از این اتربیوت‌ها و البته دقت در استفاده صحیح می‌تونیم این چالش رو بر طرف کنیم.

تعدادی اکسنشن متد برای برنامه نویسی asynchronous و استفاده از Taask ها

متد WhenAll :
کار آن ترکیب تعدادی Task و اجرای آن‌هاست. تنها زمانی خاتمه می‌یابد که کلیه‌ی Taskهای معرفی شده به آن خاتمه یافته باشند. در اینجا هر Task کاری به Task دیگر ندارد و جداگانه انجام می‌شود.
همچنین اگر خطایی برای هر کدام از Task ها رخ دهد , در آخر اجرای همه تسک‌ها آن خطا نمایش داده می‌شود که معمولا از نوع Aggregate Exception است.

متد WhenAny :
زمانی که از چندین تسک استفاده می‌کنیم اگر بخواهیم هر کدام از Taskهای در حال پردازش که خاتمه یافت ، کل عملیات خاتمه یابد، از این متد استفاده می‌کنیم

var finishedTask = await Task.WhenAny(tasksList);
var result = await finishedTask;

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

متدهای Run و FromResult
زمانی استفاده می‌شود که می‌خواهم از Thread pool استفاده کنیم. Run وظیفه اختصاص Thread را دارد و از FromResult برای خروجی استفاده می شود.
همانند Thread.Sleep است با این تفاوت که در اینجا Thread جاری قفل می‌شود ولی در Task.Delay قفل نمی‌شود.

خروجی را بر می‌گرداند با این تفاوت که ادامه کار متوقف نمی‌شود.

برای ایجاد یک اکستنشن متد دلخواه میتوانید از این (https://stackoverflow.com/questions/55594672/how-to-create-a-generic-extension-method-for-async-methods) آموزش استفاده کنید.

https://docs.microsoft.com/en-us/dotnet/csharp/nullable-attributes#specify-post-conditions-maybenull-and-notnull

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

#حامد_حاجیلو (http://bit.ly/2IVjfYD)

کانال تلگرام:
@SoftwarePhilosophy

___

دو اشتباهی که مدیر محصول‌ها انجام می‌دهند

شماره 1: مدیران محصول به جای اینکه به فکر مشکل/نیاز باشند، به راه حل فکر می‌کنند. وظیفه اصلی مدیر محصول کشف مشکلی است که ارزش حل شدن دارد.

شماره 2: عدم تعیین نتیجه و برآیند، قبل از انجام کار

متن کامل 👇👇👇
https://medium.com/@productmind/two-common-mistakes-product-managers-make-and-how-to-avoid-them-f3aef0bb4da5

@iranagile

❇️ کج فهمی های yield در سی شارپ❗️

کلمه کلیدی yield معمولا به اشتباه توی برنامه نویسای سی شارپ جا افتاده
اکثرا فکر میکنن که صرفا یه سینتکس راحت تر به جای پر کردن یه List و return کردن اون هست در صورتی که اصل ماجرا چیز دیگس!

🔸شاید تعجب کنین از شنیدن اینکه متدی که داخلش از yield return استفاده شده باشه مادامی که به دستورات اجرا کننده مانند foreach یا ToList یا FirstOrDefault و... نرسه، بدنه اش اجرا نمیشه (مشابه IQuerable) زمانی هم که اجرا میشه فقط به تعداد لازم گردش میکنه.
تصویر زیر پست رو ببینین تا کامل متوجه بشین

🔹در واقع قابلیت yield return به شما امکان به تعویق انداختن (deferred execution) کد های Iteration رو میده تا به جای اینکه Iteration در لحظه فراخوانی متد و به تعداد کامل انجام بشه در "زمان لازم" و به "تعداد لازم" گردش انجام بشه.
این کار باعث میشه Memory Allocation کمتری داشته باشین چرا که تعداد کمتری Iteration انجام میشه و زمانش هم به تعویق میافته.

🔰جهت مطالعه بیشتر لینک های زیر رو دنبال کنین
https://www.dotnettips.info/post/984
https://www.dotnettips.info/post/985
https://www.kenneth-truyers.net/2016/05/12/yield-return-in-c/
https://docs.microsoft.com/en-us/dotnet/csharp/iterators
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/yield
_______________
@DotNetZoom

راهنمای دم‌دستی طراحی UI برای غیر دیزاینرها

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

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

در این مقاله، نویسنده به طور خلاصه به بیان مهم‌ترین اصول طراحی UI پرداخته است که رعایت آن‌ها می‌تواند طرح شما را از یک طرح خام و نه چندان جذاب به یک طراح نسبتا خوب و قابل قبول تبدیل کند. پس اگر شما هم می‌خواهید با این اصول و قواعد کلی آشنا شوید، پیشنهاد می‌کنیم مقاله زیر را مطالعه کنید:

https://bit.ly/dxgn626

(زمان حدودی مطالعه: 10 دقیقه)

نویسنده: محمدرضا پناهی

#دیزاین #رابط_کاربری

@Dexign فلسفه دیزاین

_____

👈 چرا باید ستون "تست" را در برد تیم های چابک حذف کنیم؟

🎯 اکثر تیم های چابک از بردهای فیزیکی/دیجیتال برای حداکثری سازی شفافیت استفاده می کنند. معمولا در این تابلو ستون های متفاوتی وجود دارد، که یکی از آنها ستون مربوط به "تست" است، که اقلامی که باید تست شوند، را نشان میدهد.
اما چرا اساسا این ایده اضافه کردن ستون تست میتواند به یک معضل خطرناک تبدیل شود؟ و حذف این ستون آیا این به معنی بی ارزش بودن، جایگاه تست در تیم های چابک است؟

متن کامل را در لینک زیر مطالعه کنید
👇👇👇

https://www.jitgo.uk/in-test-column/

@iranagile

آشنایی با قابلیت های Blazor

در این ویدیو یک اپ CRUD پیاده شده با Blazor در حالت Server-side را بررسی می کنیم.

https://youtu.be/Px9WedDTjQg

#Interface #Pattern #DI

❇️از اینترفیس ها بیش از حد استفاده نکنید!

یکی از نشانه های برنامه نویسانِ بزرگ و حرفه ای، استفاده ی به جا، مناسب و به دور از اغراق، از مفاهیم و الگوهای برنامه نویسی است. هدف همه ی ما، داشتن کدی تمیز و خوانا، با قابلیت نگهداری بالا و امکانِ استفاده ی مجدد است .
خوشبختانه اینترفیس ها (Interface)، تحققِ بسیاری از این موارد را برایمان ممکن کرده اند. مخصوصا وقتی صحبت از تزریق وابستگی ها (Dependency Injection) و یا انجام آزمون های واحد (Unit Testing) به میان می آید، بدون کوچکترین تعلل به سراغ تعریف اینترفیس به ازای تک تک کلاس ها می رویم. اما آیا واقعا در تمامی موارد و سناریوها نیاز به تعریف این اینترفیس ها داریم؟!

اگر شما هم از آن دسته از برنامه نویسانی هستید، که عادت به تعریف اینترفیس ها و پیچیده کردنِ روال، بدون در نظر گرفتن و ارزیابیِ شرایطِ موجود را دارید، مطالعه ی مقاله ی زیر شاید موجب تجدید نظر در این دیدگاه شود:

http://blog.hovland.xyz/2017-04-22-stop-overusing-interfaces/

_______
@DotNetZoom

قانون اوج و پایان

«کاربران، یک تجربه را بیشتر بر اساس حسی که در اوج و پایان آن دارند قضاوت می‌کنند، و برآوردی را از همه‌ی لحظات آن تجربه ندارند.»

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

یک مطالعه در سال ۱۹۹۳ با نام When More Pain Is Preferred to Less: Adding a Better End انجام شد. شرکت کنندگان در معرض دو حالت متفاوت از یک تجربه‌ی ناخوشایند قرار گرفتند. به صورت زیر این آزمون برگزار شد:

۱. از داوطلبان خواسته شد که دست خود را به مدت ۶۰ ثانیه در آب ۱۴ سانتی‌گراد فرو ببرند.
۲. در نوبت دوم از آن‌ها خواسته شد که این‌بار به مدت ۶۰ ثانیه در همان آب ۱۴ سانتی‌گراد دست خود را فرو ببرند به اضافه‌ی ۳۰ ثانیه‌ی دیگر که دمای آب به ۱۵ درجه افزایش پیدا می‌کند.
۳. و در نوبت سوم، قدرت انتخاب تکرار آزمایش بین نوبت اول یا دوم به آن‌ها داده شد.

برخلاف انتظار، داوطلبان بیشتری نوبت دوم را برای تکرار آزمایش انتخاب کردند. نوبتی که ۳۰ ثانیه بیشتر از نوبت اول شرایط ناخوشایند را تجربه می‌کردند.

دانیل کانمن روانشناس آمریکایی-اسرائیلی به این نتیجه رسید که افراد، آزمون طولانی‌تر را به این دلیل انتخاب کردند که خاطره‌ی بهتری نسبت به آزمون نوبت اول برای آن‌ها به جا گذاشت. یا درواقع از آزمون طولانی‌ترکمتر بیزار بوده‌اند.

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

https://bit.ly/dxgn628-1

https://bit.ly/dxgn628-2

(زمان حدودی مطالعه‌ی مقاله‌‌ی اول: ۲۷ دقیقه، مقاله‌ی دوم: ۱۳ دقیقه )

نویسنده: حسین میرزاده

#تجربه_کاربری #قانون_اوج_پایان #روانشناسی #تعصب_شناختی

@Dexign فلسفه دیزاین

_____

🧩 خطای شناختی Fundamental Attribution Error (FAE) چیست؟

به دفعات بی شماری که به شخصی در محل کار خود برچسب زده اید ، "تنبل ، خسته کننده ، بی‌کفایت ، احمق، مغرض، بی پروا، بی ادب ..." فکر کنید.

همین برچسب‌ها باعث می‌شود که ما در ارتباط با آنها به مشکل بخوریم. مغز ما در برچسب زدن به دیگران بسیار سریع عمل می‌کند، و با دیدن کمترین شواهد این برچسب زده می شود که در اصطلاح خطای شناختی Fundamental Attribution Error (FAE) گفته می شود.

اما چگونه باید از این تله شناختی فرار کرد؟

https://www.techtello.com/fundamental-attribution-error/

@iranagile

#SqlServer, #Storage
❇ذخیره‌سازی فایل در دیتابیس
با چه روشی انجام شود؟
varbinary?
file table?
...
حجم اطلاعات زیاد هستش
روش بهینه برای ذخیره‌سازی چه روشی ست؟
برای نگهداری دادهای LOB یعنی CLOB ها و BLOB ها روش‌های مختلفی وجود داره.
تعریف BLOB: مخفف Binary Large Object هست مانند Image
تعریف CLOB: مخفف Character Large Obeject هست مانند Text
اولین روش این هستش که ما مستقیماً داده رو در خود SQL در قالب یک فیلد از نوع VarBinary- XML-Nvarchar(MAX) و... ذخیره کنیم. اولین قوت این روش این هستش که کنترل مواردی مانند امنیت، جستجو، پشتیبانی Backup، عملیات مربوط به تراکنش و لغو آن و ... بر عهده خود SQL می‌باشد
اما نقاط ضعف این روش:
افزایش حجم LOGT - محدودیت حجم ۲ گیگابایت - وجود Fragmentation - استفاده زیاد از Buffer pool و Ram سیستم و ...
یکی از روش‌های رایج دیگر نگهداری فایل، خارج از دیتابیس می‌باشد. که معمولاً اصل فایل (مثلاً تصویر) رو در یک پوشه خاص ذخیره می‌کنند و آدرس اون رو در یک فیلد از نوع Varchar یا Nvarchat نگهداری می‌کنند. در این روش کاهش Fragmentation - عدم استفاده از Buffer Pool - افزایش حجم ذخیره‌سازی به اندازه دیسک و ... جزو مزیت‌ها می‌باشد
نقاط ضعف این روش:
در این روش SQL هیچ کنترلی روی این فایل نداره. مثلاً در زمان بک آپ گیری از دیتابیس، از این پوشه بک آپی گرفته نمی شه و کنترل مواردی مانند امنیت و تراکنش‌ها بر عهده SQL نمی‌باشد. به دلیل درگیری بین SQL و NTFS، دارای کد نویسی پیچیده می‌باشد و ....
و
اما یکی از روش‌های بسیار مناسب Filestream می‌باشد که از نسخه 2008 ارائه شد و مزیت‌های دو روش اشاره شده دارا می‌باشد. راه‌اندازی FileStream نیازمند تنظیمات سطح سرور و سطح Instance می‌باشد.
در ادامه به یک سؤال مهم جواب می‌دهیم:
چه زمانی برای ذخیره‌سازی اطلاعات از Filestream استفاده کنیم؟؟
پاسخ:
در تئوری گفته شده است که برای داده‌های با حجم بیش از یک مگابایت اما در عمل برای داده‌های با حجم بیش از ۲۵۶KB و برای داده‌های با حجم کمتر از ۲۵۶KB نوع Nvarchar (MAX) مناسب‌تر می‌باشد.

و اما ساختار دیگری که می‌توان از آن برای نگهداری فایل‌ها استفاده کرد File Table می‌باشد که از نسخه ۲۰۱۲ معرفی شد. در واقع متوان به این صورت گفت که File Table از همکاری بین File Stream و نوع داده‌ای Hierachy ایجاد شده است. در واقع با ایجاد FileTable ارتباط بین SQL, Ntfs رو برقرار کرده‌ایم. به این معنا که با حذف فایل از SQL، اطلاعات این فایل از NTFS نیز حذف می‌شود و با تغییر محل فایل در SQL، این تغییر مکان در NTFS نیز اعمال می‌شود.

محسن بندامیر
@Mohsen_Bandamir

کانال تخصصی SqlServer
@SQLSERVER_professional

✅ آشنایی با قابلیت FileStream اس کیوال سرور
http://www.dotnettips.info/post/331/
http://www.dotnettips.info/post/332/
http://www.dotnettips.info/post/333/

___
@DotNetZoom

نقش چکش بصری در طراحی برند

ثابت شده است که در ذهن انسانها، تصاویر نسبت به متن نوشتاری و یا صوتی بار احساسی بسیار بیشتری دارند و این احساسات است که باعث تشکیل پیوند میان ذهن و تصویر می‌شوند. پس بهترین راه ورود به ذهن مخاطبین استفاده از محتوای بصری است.

ایده محتوای بصری اولین بار توسط لورا ریس در کتابی به نام "چکش بصری" ارائه شده است که مبتنی بر دو اصطلاح «میخ» و «چکش» است. اصطلاح «میخ» معمولا برای توصیف ایده که قرار است در ذهن مخاطب ثبت گردد به کار می‌رود و «چکش» عاملی است که قرار است باعث ثبت ایده در ذهن مشتری گردد. این همراهی میخ و چکش بصری است که می‌تواند باعث تاثیرگزاری برند در ذهن کاربران گردد. به عبارت دیگر این تصویر است که مفهوم کلامی برند را در ذهن مخاطب تقویت می‌کند.

برای درک بهتر این مفهوم برند کوکاکولا را در نظر بگیرید. این شرکت بیش از ۱۰۰ سال قدمت دارد و در طی این سال ها بارها شعار خود را تغییر داده است. به نظر شما بیشتر مردم امریکا چه چیزی را از تبلیغات کوکاکولا به خاطر دارند؟ واژه‌ها؟ خیر! بیشتر مردم تصویر بطری کمر باریک کوکاکولا را به خاطر سپرده‌اند. پس بطری کوکاکولا فقط یک بطری نیست. چکش بصری است که مفاهیمی را در ذهن مخاطب میخ کرده‌است!
استفاده از ستارگان و افراد مشهور در تبلیغات می‌تواند یکی از راه‌های ایجاد یک چکش بصری باشد. استفاده از حیوانات هم گاها چکش‌های بصری قدرتمندی می‌سازد مانند پرنده کوچک آبی رنگ توییتر که چکش بصری برندی است که در کوتاه مدت توانست شهرت جهانی کسب کند.

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

https://bit.ly/dxgn632

لینک کتاب:

https://bit.ly/dxgn632Book

(زمان مورد نیاز برای مطالعه: ۸ دقیقه)

نویسنده: نیما‌ حکیم‌رابط

#طراحی‌هویت‌بصری #برند #محتوای‌بصری

@Dexign فلسفه دیزاین

_____

A good product manager is the CEO of the product.

چقدر با این جمله، Ben Horowitz موافق هستید؟ آیا میتوان گفت که یک مدیرمحصول مصداق مدیرعامل محصول هست؟

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

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

چندین متخصص حوزه محصول در این خصوص نظرات خودشان را یک جا جمع کردند، که میتوانید در لینک زیر مطالعه کنید 👇👇👇

https://jeffgothelf.com/blog/are-product-managers-really-the-ceos-of-their-product-5-product-leaders-weigh-in/

@iranagile

استفاده از versioning در ASP.NET Core

در پروژه‌های کوچک که معمولا فقط یک برنامه (کلاینت) از Api ما استفاده می‌کند، در صورتی که بخواهیم تغییری در ورودی و خروجی‌ها یا آدرس Api بدهیم به راحتی می‌توانیم نسخه کلاینت (اپلیکیشن اندرویدی, سایت و ... ) را هم به روزرسانی کنیم.

اما زمانی که پروژه‌های کلاینت بیشتر از یکی است و آپدیت کردن همه موارد به صورت همزمان مقدور نیست ناچاریم یکی از راه های زیر را استفاده کنیم:

- بی‌خیال تغییرات شویم، چون عملا اپلیکیشنی که نتوانستیم آپدیت کنیم از کار خواهد افتاد و نمی‌تواند از Api تغییر کرده استفاده کند.
-یک متد جدید بنویسیم و اپ‌هایی که می‌توانند خودشان را آپدیت کنند از متد جدید استفاده کنند و مواردی هم که نتوانسته‌اند خود را آپدیت کنند از متد قبل استفاده کنند.
- گزینه (احتمالا) آخری که وجود دارد versioning است:

شما با versioning می‌توانید معضلی که در بالا به آن اشاره شد را برطرف کنید و Api های خود را استاندارد کنید و این اجازه را به اپ‌هایی که از Api شما استفاده می‌کنند بدهید تا بتوانند از هر ورژنی که می‌خواهند استفاده کنند.

اطلاعات کامل‌تر را می‌توانید در لینک زیر مطالعه نمایید:

https://dotnetthoughts.net/restful-web-api-versioning-with-asp-net-core/


⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

#حامد_حاجیلو (http://bit.ly/2IVjfYD)

کانال تلگرام:
@SoftwarePhilosophy

________

#Technical_Debt #Software_Engineering #معرفی_سایت

❇بدهی فنی (Technical Debt) چیست؟
بدهی فنی یکی از موارد کلیدی در موفقیت تجاری نرم‌افزارهای توسعه‌داده‌شده است. این اصطلاح توسط وارد کانیگهام در سال ۱۹۹۲ ابداع شد. او چنین چیزی گفت: «انتشار اولین کد مثل بدهکار شدن است. کمی بدهی، سرعت توسعه را بهبود می‌بخشد؛ به شرطی که در اولین فرصت با بازنویسی کد، تسویه شود... خطر زمانی رخ می‌دهد که تسویه نشود. هر دقیقه که صرف کد نامطلوب شود به عنوان بهره تلقی می‌شود. تمامی یک سازمان مهندسی می‌تواند تحت بار بدهی این کد نامستحکم، به حالت توقف کشانده شود.»

🔸تشبیه بدهی فنی ارتباط نزدیکی با بدهی مالی دارد و مربوط به انتشار سریع یک چیز و در نتیجه بدهکار شدن است. بعداً باید این بدهی را با بهبود کیفیت، تسویه کنید و اگر این کار را نکنید مجبور به پرداخت نرخ بهره هستید چون بهره‌وری شما کاهش پیدا می‌کند و توسعه‌تان کند می‌شود.

🔹دلایل بدهی فنی:
- فشار زمانی
- استفاده از یک فناوری جدید برای نخستین بار بدون درک درست از آن
- طراحی اشتباه به دلیل نداشتن شناخت صحیح از نیازمندی های حوزه ی کسب وکار
- پوسیدگی نرم‌افزار

🔸اما بدهی فنی همیشه بد نیست. در واقع بدهی فنی یک راهبرد است. چون می‌توانیم با بدهکار شدن به سرعت به هدف کسب و کار برسیم. بهتر است چیزی را سریع بنویسید و به کاربر برسانید و ببینید که آیا برای کسی مفید است؟ اگر برای کسی مفید است آن وقت است که بدهی فنی را پرداخت می‌کنیم. اگر کد بی‌نقصی برای عملکردی که نمی‌دانیم مفید است یا نه بنویسیم هدر دادن زمان است.

🔹این ها بخشی از صحبت های سوِن یوهان و ابرهارد ولف در مورد بدهی فنی از مجموعه پادکست های صوتی سایت SE Radio است که توسط سایت http://se-topics.ir/ به خوبی ترجمه و در اختیار توسعه دهندگان فارسی زبان قرار داده شده است.
این سایت از جمله سایت های خوب فارسی در حوزه ی مهندسی نرم افزار است و به تهیه ترجمه از پادکست‌های صوتی و تصویری از افراد خبره در این حوزه می پردازد. همچنین در صورت تمایل می توانید به جمع مترجمان این سایت بپیوندید و در ترجمه ی پادکست ها با این سایت همکاری داشته باشید تا مقاله تان با ذکر نام خودتان بر روی سایت قرار گیرد.

🔰متن کامل مقاله:
http://se-topics.ir/topicview?id=54

🔰مطالعه ی بیشتر در مورد بدهی فنی:
https://www.infoq.com/articles/managing-technical-debt


_______
@DotNetZoom

قانون تسلر (حفظ پیچیدگی)

«برای هر سیستم میزان پیچیدگی خاصی وجود دارد كه نمی‌تواند كاهش یابد.»

لَری تِسلر (Larry Tesler) دانشمند آمریکایی‌ای بود که در حوزه‌‌ی روابط و اثر متقابل کامپیوتر و انسان کار می‌کرد. او خالق اینتراکشن ماندگار (Cut & paste) است.
در سال ۱۹۸۰ زمانی که مشغول به کار در Xerox park بود، متوجه شد که نحوه‌ی تعامل کاربران با برنامه‌ها دقیقاً به اندازه‌ی خود برنامه مهم است. او در مصاحبه‌ی معروف خود با Dan Saffer بیان می‌کند که در بیشتر موارد، یک مهندس باید یک هفته‌ی اضافه را صرف کاهش پیچیدگی یک برنامه کند تا باعث نشود میلیون‌ها کاربر یک دقیقه اضافه را صرف استفاده از برنامه کنند فقط به این دلیل که برنامه، پیچیدگی اضافه‌ای دارد.
با این‌حال Bruce Tognazzini دیزاینر آمریکایی و شریک آقای دان نورمن در Nielsen Norman Group این موضوع را مطرح می‌کند که افراد در برابر کاهش میزان پیچیدگی در زندگی خود مقاومت می‌کنند. بنابراین، هنگامی که یک برنامه ساده می‌شود، کاربران تلاش می‌کنند که کارها را پیچیده‌تر کنند.

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

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

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

https://bit.ly/dxgn634-1

https://bit.ly/dxgn634-2

https://bit.ly/dxgn634-3

https://bit.ly/dxgn634-4

(زمان حدودی مطالعه‌ی مقاله‌‌ی اول: ۵ دقیقه،
مقاله‌ی دوم: ۸ دقیقه،
مقاله‌ی سوم: ۶ دقیقه
و مقاله‌ی چهارم: ۱۸ دقیقه)

نویسنده: حسین میرزاده

#تجربه_کاربری #قانون_تسلر #قانون_حفظ_پیچیدگی #سادگی

@Dexign فلسفه دیزاین

_____