👌 چهار روش برای نابود کردن یک تیم چابک توسط یک مدیر/مالک محصول

1. عدم تمرکز یا چشم انداز

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

2. ارتباطات ضعیف پیرامون اهداف و نتایج

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

3. عدم داشتن اختیارات در زمینه اولویت بندی بک لاگ محصول

"آنچه" تیم روی آن کار می کند، مسئولیت PO است. بدون داشنن سطح مناسبی از اختیارات در حوزه تصمیم گیری، تیم در یک چرخه ثابت گرفتن تأییدها یا چرخه ثابت کار مجدد، قرار خواهد گرفت و شاهد پیشرفت چشمگیر نخواهیم بود.

4- عدم احترام به تیم

عبارات زیر را در نظر بگیرید:
کسی به من اهمیت نمی دهد.
شما به اندازه کافی کار نمی کنید.
چطوری میتونه اینقدر طول بکشه؟
شما بچه ها متعهد نیستید که این محصول را موفق کنید.
گفته های فوق نتیجه ناامیدی است که احتمالاً ناشی از عدم درک پیچیدگی های اجرا است. اگر شما یک PO هستید و هر یک از این گفته ها یا موارد مشابه، از دهان شما خارج شده اند - لطفاً این کار را نکنید. اظهاراتی چنین کلی و مبهم که تلقین میکند "تیم اهمیتی به کار نمی دهد"، هرگز و هرگز مولد نیست.

متن کامل
https://medium.com/serious-scrum/4-ways-a-product-owner-can-destroy-a-scrum-team-e6e5cff59eac

@iranagile

آموزش آپلود کردن فایل در ASP NET Core

در این ویدیو تمامی مراحل آپلود کردن فایل در ASP NET Core آموزش داده میشود. فایل با IFormFile از مرورگر کاربر دریافت میشود و در فولدر سرور کپی میشود. در ادامه با محدود کردن دسترسی به فایل آشنا میشوید.

https://codehaks.com/go/eoz

✅ کتابخانه اعتبارسنجی FoolProof برای ASP.NET Core

خیلی وقتا لازم میشه یه سری اعتبارسنجی روی مقادیر ورودی کاربر داشته باشیم. مثلا مقدارش کمتر یا بیشتر از فلان مقدار نباشه و ... تو این شرایط معمولا خودمون میایم و یه Attribute Validation سفارشی ایجاد میکنیم (که تازه اعتبار سنجی سمت کلاینت با jQuery رو هم نداره و فقط سمت سرور چک میشه) ولی الان میخوام یه کتابخونه رو معرفی کنیم که کارتون رو خیلی راحت میکنه.

🔸کتابخانه FoolProof.Core تعداد زیادی Attribute برای اعتبار سنجی مقادیر کاربر داره که همگی علاوه بر Server-side از Client-side Validation هم پشتیبانی میکنن. نسخه قدیمی آن (foolproof) برای ASPNET MVC سابق است.
(آموزش استفاده از آن در سایت dotnettips) ولی این نسخه از ASPNET Core پیشتیبانی میکنه

🔹لیست Attribute های پشتیبانی شده:
✔️ Is
✔️ EqualTo
✔️ NotEqualTo
✔️ GreaterThan
✔️ LessThan
✔️ GreaterThanOrEqualTo
✔️ LessThanOrEqualTo
✔️ Improved required validators:
✔️ RequiredIf
✔️ RequiredIfNot
✔️ RequiredIfTrue
✔️ RequiredIfFalse
✔️ RequiredIfEmpty
✔️ RequiredIfNotEmpty
✔️ RequiredIfRegExMatch
✔️ RequiredIfNotRegExMatch
✔️ In
✔️ NotIn

🔰لینک پکیچ Nuget و مخزن گیتهاب
https://www.nuget.org/packages/FoolProof.Core/
https://github.com/rpgkaiser/FoolProof.Core

#FoolProof #Validation #اعتبارسنجی
__________________
@DotNetZoom

قانون فیتس

«زمان دستیابی به هدف، تابعی از فاصله و اندازه‌ی هدف است.»

این قانون در سال ۱۹۵۴ توسط روانشناسی به نام پائول فیتس مطرح شد. او با بررسی سیستم حرکتی انسان، نشان داد که زمان لازم برای حرکت به یک هدف، به مسافت آن بستگی؛ و با اندازه‌ی آن رابطه‌ی عکس دارد.
طبق قانون او به دلیل سبک-سنگین کردن کاربر بین دقت و سرعت، حرکات سریع و اهداف کوچک منجر به خطای بیشتری می‌شود.

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

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

https://bit.ly/dxgn615-1

https://bit.ly/dxgn615-2

و همینطور صفحه‌ی ویکیپدیای این قانون به راحتی از طریق لینک زیر قابل دسترسی است:

https://bit.ly/dxgn615wiki

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

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

#تجربه_کاربری #قانون_فیتس #طراحی_تعاملی #فاصله #اندازه

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

_____

🎯 اسکرام مسترها قرار است جریان ساز باشند نه اینکه در جریان غر زدن غوطه ور شوند

داستان از آنجا شروع شد که مدیران ارشد سازمان از تیمها درخواست دادند، که میخواهند سرعت (Velocity) تیم ها را در انتهای اسپرینت را ببیند، از نظر اجرایی این کار سختی برای ما نبود اما نگران عواقب آن بودیم.
تمام اسکرام مسترها جمع شدیم و در مورد این نگرانی صحبت کردیم، "پایه استوری پوینت هر تیم با تیم دیگر کاملا متفاوت هست، اگر قرار باشد، با این متر تیمها با هم مقایسه شوند، این عواقب بدی خواهد داشت، مثلا تیم با سرعت 40 به معنی دو برابر بودن سرعت ان نسبت به تیم با سرعت 20 نیست. زیرا آنها اصلا پایه پوینت متفاوتی دارند و ایجاد یک پایه مشترک شدنی نیست".
قرار شد این نگرانی را با مدیران ارشد در میان بگذاریم. آنها به ما قول دادند که چنین نیتی ندارند...

🔬 چند مدت بعد یکی از ذینفعان ما در جلسه گفت، "شما نمی خواهید برای سرعت تیمتون فکری کنید؟"
پرسیدیم : "چطور؟"
گفت:"تیم ایکس رو دیدم که سرعتشون دو برابر شما است..."

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

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

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

نکته مهم" قرار نیست شما همیشه با قوانین و روالهای سازمانی چنین کنید و برخی مواقع صحبت یا نشان دادن روش درست، میتواند کارساز باشد"

منبع
https://medium.com/serious-scrum/people-over-processes-but-scrum-master-over-organizational-rules-325a288e3656

❇️ نمونه معماری پیاده سازی شده با ASP.NET Core و Angular و DDD

Architecture with .NET Core 3.1, ASP.NET Core 3.1, Entity Framework Core 3.1, C#, Angular 9.1, Clean Code, SOLID, DDD, Code Analysis, Docker and more.

🔸Technologies
✔️ .NET Core 3.1
✔️ ASP.NET Core 3.1
✔️ Entity Framework Core 3.1
✔️ C# 8.0
✔️ Angular 9.1
✔️ Typenoscript
✔️ JWT
✔️ FluentValidation
✔️ Scrutor
✔️ Serilog
✔️ Docker
✔️ Azure DevOps
✔️ ...
🔹Practices
✔️ Clean Code
✔️ SOLID Principles
✔️ DDD (Domain-Driven Design)
✔️ Unit of Work Pattern
✔️ Repository Pattern
✔️ ...

https://github.com/rafaelfgx/Architecture
________________
@DotNetZoom

قانون کاراییِ زیبایی

شاید مثال نه زیاد درست و نه زیاد غلط «عقل مردم به چشمشان است» را شنیده باشید. امروز به بررسی همین موضوع می‌پردازیم.

اثر کارایی زیبایی در واقع یکی از قوانین اصلی تجربه‌ی کاربری است که به طور صریح می‌گوید:
«کاربران غالباً طراحی زیبا و جذاب را به عنوان دیزاین کاراتر درک می‌کنند.»

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

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

در ۲ مقاله‌ی زیر به بررسی این موارد و نیز چگونگی تست کاربر هنگامی که قاضی او فقط چشمانش هستند می‌پردازیم.

https://bit.ly/dxgn619-1

https://bit.ly/dxgn619-2

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

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

#تجربه_کاربری #قانون_کارایی_زیبایی #زیبایی_بصری #کاربردپذیری

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

_____

💪 استرس و فشار همیشه وجود دارد، چگونه یک تیم تاب آور درست کنیم؟

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

ادامه مقاله 👇👇👇

https://academy.nobl.io/team-resilience/

@iranagile

✅ معرفی Design Pattern ها به همراه مثال در زبان های مختلف

یکی از بهترین سایت هایی که میشه به عنوان مرجع برای #DesignPattern ها بهش نگاه کرد سایت زیر هست.

این سایت خیلی روون و ساده الگو های برنامه نویسی رو توضیح داده، براشون مثال زده و توی زبان های مختلفی از جمله #C و JavaScript و Java و Python و ... پیاده سازیشون کرده

1️⃣ https://refactoring.guru/design-patterns/catalog
2️⃣ https://www.dofactory.com/net/design-patterns

🔰2تا ریپوی زیر هم پیاده سازی ایی از این دیزاین پترن ها در سی شارپ هست
1️⃣ https://github.com/exceptionnotfound/DesignPatterns
2️⃣ https://github.com/HamidMosalla/CSharpDesignPatterns
_____________________
@DotNetZoom

قانون ۲۰-۸۰ یا اصل پارتو

«۸۰ درصد رخدادها از ۲۰ درصد دلایل به‌وجود می‌آید.»

ویلفردو پارتو اقتصاددان ایتالیایی در سال ۱۹۰۶ دریافت که ۸۰ درصد زمین‌های ایتالیا در دست ۲۰ درصد مردم آن کشور است؛ همچنین پارتو دریافته بود که ۸۰ درصد نخودفرنگی‌های باغچه‌اش در ۲۰ درصد غلاف‌های نخودفرنگی قرار دارند.

اصل ۲۰-۸۰ در تصمیم‌گیری‌های سریع مدیریتی و نیز تجربه‌ی کاربری بسیار کارساز است. شما باید بیشترین تلاش را روی مناطقی متمرکز کنید که بیشترین مزیت را برای اکثر کاربران به همراه داشته باشد.

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

https://bit.ly/dxgn620

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

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

#تجربه_کاربری #اصل_پارتو #قانون_۲۰_۸۰ #بهره_وری

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

_____

سی شارپ 9 و بهبود pattern matching:

یکی از برتری های ویژوال بیسک نسبت به سی شارپ, موضوع pattern matching بود (البته قبل از سی شارپ 8).
از سی شارپ 8 به بعد ماکروسافت تمهیدات خاصی در جهت بهبود pattern matching در سی شارپ در نظر گرفت.👇👇

یکی از جالب ترین (و جذاب ترین) این موارد, بهبود در جملات شرطی است که در سی شارپ 9 به آن پرداخته شده است.

if(s is not string)
// is way more easier to read than
if(!(s is string))

خواندن عبارت ابتدایی بسیار آسان تر از عبارت دوم است.

Person p = new Person();
var a = p.Weight switch
{
  < 150 => "light"
  >= 150 and < 200 => "normal"
  not null => "unknown"
  null => "error"
};

و هچنین نوشتن این عبارات باعث زیباتر و خواناتر شدن کد می‌شود.

برای اطلاع از دیگر ویژگی های سی شارپ 9 می توانید از این لینک استفاده کنید.

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

https://blog.miguelbernard.com/c-9-0-improved-pattern-matching/

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

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

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

___

✂️جنبش #NoEstimates هیاهویی برای هیچ

این روزها هیاهوی جنبش #NoEstimates بیشتر و بیشتر می شود. من می خواستم دلیل آن را بفهمم، بنابراین تیم من 3 ماه آن را آزمایش کرد. بعد از کار با آن به مدت یک فصل، من اعتقاد ندارم که تغییر بازی همانطور که طرفداران #NoEstimates سعی دارند ما باور کنیم، واقعا بوده است.

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

قبل از اینکه درباره مزایا و مضرات #NoEstimates بحث کنیم، اجازه دهید ابتدا استدلال مربوط به جنبش را مورد بحث قرار دهیم.

👈 چرا #NoEstimates؟

جنبش #NoEstimates ادعا می کند که ما بخاطر این سه دلیل نباید تخمین بزنیم:

💢 تخمین دقیق غیرممکن است.

💢 تخمین‌ها می‌ توانند فشار غیرضروری و غیرمولدی به تیم شما وارد کنند.

💢 اساسا فعالیتی با عنوان تخمین یک اتلاف است، بنابراین بهتر است تا آنجا که ممکن است وقت کمتری برای آن صرف کنید.

اما داستان واقعی چیست؟ ادامه در لینک زیر مطالعه کنید 👇👇👇

https://medium.com/serious-scrum/the-noestimates-movement-is-a-pointless-infatuation-c64d9329d39


@iranagile

آشنایی با Docker

داکر ابزاری برای توزیع و اجرای نرم افزار است که مشکل سازگاری با سیستم عامل های مختلف را حل میکند. این ابزار امروزه همه جا مورد استفاده قرار میگیرد و خوب است به عنوان توسعه دهنده ی نرم افزار درباره آن بیشتر بدانید. در این ویدیو به معرفی داکر می پردازیم و در ادامه از Docker در یک پروژه ASP NET Core استفاده می کنیم.

https://cutt.ly/ortrfXx

آشنایی با Docker - قسمت دوم

در این ویدیو با استفاده از Docker دیتابیس Redis رو نصب و اجرا می کنیم
سپس از پروژه ASP NET Core یک Image داکر تهیه می کنیم.

https://tinyurl.com/cdhk-docker2

❇️ ابزار های کاربردی برای یک Web Developer
#جعبه_ابزار

این ریپازیتوری، بهترین ابزار های کاربردی ایی که معمولا یه برنامه نویس وب لازمش میشه رو به همراه دسته بندی های زیر لیست کرده.

🔹Image Compressor
🔸Javanoscript Minifer
🔹CSS Minifier
🔸JavaScript Beautifier
🔹Unminify HTML, CSS and JS
🔸Unminify/Formating JSON - Check/Validating JSON
🔹Browse JSON in TreeView
🔸Regex (Regular Expression) Tester and Highlighting
🔹Unicode Converter
🔸Url Decoder/Encoder
🔹Converter Toolbox
🔸Hash Text and File
🔹Web Developer Toolbox
🔸Check Domain and Whois
🔹IP to Location
🔸Website Traffic Statistics
🔹SEO Checker
🔸Rank Checker
🔹Analytics & Tracking
🔸Speed Checker and Performance Optimization
🔹Webiste Monitoring / Uptime Checker
🔸Text Compare / Difference Checker
🔹Port Checker
🔸DNS Checker
🔹DNS Lookup
🔸SSL/TLS Checker
🔹Security Checker
🔰آدرس ریپازیتوری گیتهاب
https://github.com/mjebrahimi/Awesome-Tools-For-WebDevelopers
____________________
@DotNetZoom

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

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

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

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

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

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

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

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

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

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

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 فلسفه دیزاین

_

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