پست‌های انتشارات آکادمی بله

Let's Go: Error Handling

حمید سجادی — Sat, 30 Oct 2021 21:41:58 +0330

چند وقت اخیر در بله، در پروژه‌هایی کار می‌کنم که با Golang توسعه داده شده‌اند. من قبل از این هیچ تجربه‌ای از Go نداشتم و احساس نیاز می‌کنم تا دانشم را درباره‌اش عمیق‌تر کنم و از این حالت Stackoverflowای که الان در آن هستم خارج شوم. برای اینکه به این مسئله نظم بدهم و بتوانم تمرکز بیشتری داشته باشم، تصمیم گرفتم که چند پست و مطلب در حین این پروسه و درباره‌ی نکته‌هایی که می‌خوانم و یاد می‌گیرم بنویسم. این متن هم به همین دلیل نوشته شده است.بعضی از کد‌ها و مثال‌ها را، که شاید بخواهید دقیق‌تر ببینید، در پلی‌گروند به اشتراک گذاشته‌ام. هرچند ممکن است آنجا ران نشوند (مثلاً io و http نیاز دارند)، ولی خب می‌توانید خودتان کپی و اجرایشان کنید.فهرست منابع و مقاله‌های اصلی هم در انتهای مطلب هست. اگر علاقه‌مند بودید، حتماً بخوانیدشان.توی این مطلب درباره‌ی ارور‌ها در گولنگ صحبت می‌کنیم که کلاً چه هستند و چطور می‌شود بهتر مدیریتشان (هندل) کرد تا کد تمیزتر و بدون تکراری داشته باشیم.چند فرق عمده‌ بین گولنگ با زبان‌های معروف دیگر وجود دارد که باعث می‌شود تا هرکس اول باهاش آشنا می‌شود کمی تعجب کند، خوب نتواند باهاش ارتباط بگیرد و با خودش فکر کند: «چرا؟» (مثل نداشتن جنریک)ولی وقتی به این تفاوت‌ها عادت کنی، متوجه می‌شوی که بی‌دلیل هم نیستند و خوبی‌هایی هم دارند. (به‌جز نبود جنریک) یکی از این‌ تفاوت‌ها نحوه‌ی کار با Errorها و مدیریت آن‌هاست.توی Go به‌جای اینکه خطاها مثل اکثر زبان‌های دیگر throw بشوند، تا شاید یک جایی (implicitly) catch بشوند، مثل یک متغیر ساده هستند که توابع می‌توانند آن‌ها را برگردانند و صدازننده‌ی تابع باید این مقدار را هم مثل باقی مقادیر تابع بررسی کند. همین مسئله باعث می‌شود تا توی کدی که با Go نوشته می‌شود پر از تکه‌کدهایی مثل این باشداوایل، این مسئله من را خیلی اذیت می‌کرد. احساس می‌کردم بی‌وقفه دارم یک کد boilerplate را تکرار می‌کنم. مثلاً یک تابع ممکن است این‌طوری بشود: _, err = fd.Write(p1[c:d]) if err != nil { return err } _, err = fd.Write(p2[e:f]) if err != nil { return err } _, err = fd.Write(p2[a:b]) if err != nil { return err }که خب مسلماً خیلی خوب نیست. به همین دلیل، یکی از آپشن‌هایی که برای اضافه شدن به ورژن‌های بعدی Go درباره‌اش بحث می‌شود همین مسئله‌ است که چطور می‌توانیم این مقدار boilerplate را کمتر کنیم. مثل این issue و این یکی issue که پیشنهادهایی برای تغییر syntax مدیریت ارور یا به‌اصطلاح sugar coat کردنش هستند.اما خیلی‌ها هم هستند که به نظرشان این نوع مدیریت خطا و سینتکس اصلاً بد نیست و خیلی هم خوب است، مثل ایشان و دوستانش. چرا؟ دلایل مختلفی دارد. اصلی‌ترین و اولین دلیلش شاید این است: همه‌چیز واضح‌ست! تا امضای یک تابع را ببینی، درجا متوجه می‌شوی که این تابع ممکن است مقدار درست را برنگرداند و به مشکل بخورد. پس حتماً اول ارور را بررسی می‌کنی. اگر کد تابع صدازننده‌اش را هم ببینی، خیلی سریع متوجه می‌شوی که اگر یک جای روندش خطایی پیش بیاید چطوری مدیریتش می‌کند. دلیل دیگری که می‌توان به آن اشاره کرد این است که یکی از فلسفه‌های اصلی گو این است که برای هر کاری فقط یک روش وجود داشته باشد تا کد‌ها شبیه هم بشوند (چه کسی بود صدا زد جاوااسکریپت؟). مثلاً برای همین است که یک مدل حلقه‌ی for در go داریم. با sugar coat کردن این سینتکس، به این هدف پشت شده است.به طور کلی نیز، این مقاله عمیق‌تر و دقیق‌تر مشکل‌هایی را که exception در زبان‌هایی مثل c++ و جاوا دارد گفته و توضیح داده است که چرا به نظرش روش گولنگ بهتر است. اگر علاقه‌مندید، حتماً بخوانید. خلاصه‌اش می‌شود اینکه در c++ که کلاً ما هیچ‌وقت به‌سادگی نمی‌توانستیم بفهمیم آیا یک تابع ممکن است خطا بدهد یا نه. طراحان جاوا این را هندل کردند و throw کردن ارور را به امضای تابع اضافه کردند، ولی باز هم مشکلاتی وجود دارد. مثلاً هر طرف را نگاه کنی، یک Exception دارد throw می‌شود. یعنی در عمل دیگر exception (به‌معنای استثنا در انگلیسی) نیست و به روتین برنامه‌نویسی تبدیل می‌شود. حالا کدام exception خیلی مهم و حیاتی و خطرناک است و کدام یکی صرفاً برای چک کردن یک حالت خاص است، خدا داند.این در کنار استثناهایی مثل RunTimeException که مثل دیگر خطاها نیازی نیست در امضای تابع تعریف بشود، یعنی شاید جاوا وضعیت را بهتر کرد، ولی باز هم مشکلاتی داردتوی این پست، اول کمی با هم می‌بینیم که کلاً ارورها چی هستند و چطوری‌اند. بعد کمی از best practiceهایی را که بهتر است موقع ساخت آن‌ها یا مواجهه باهاشان رعایت کنیم بررسی می‌کنیم. در انتها هم، سعی می‌کنیم درباره‌ی مشکل verbosity و repetitive بودنشان راه‌حل ارائه بدهیم.ارور در Goدر گولنگ، ارور در واقع یک interface بسیار ساده است.اینترفیس error در golangپرکاربردترین پیاده‌سازی از این اینترفیس هم احتمالاً مربوط به پکیج errors است که با استفاده از errors.New یک ارور جدید برای ما درست می‌کند. این کلاس یک پیاده‌سازی به نام errorString‌ از این اینترفیس دارد.به همین سادگی!روش دیگری که می‌شود ارور ساخت استفاده از fmt.Errorf است که مثل بقیه‌ی fmt.folanFها استرینگ فرمتینگ هم می‌کند و با متن داده‌شده به‌عنوان ورودی برایمان یک ارور می‌سازد.ساختن یک نوع ارور خاص هم به همین سادگی است. در واقع، به هر نوع تایپی می‌شود تابع Error را اضافه کرد و به‌عنوان ارور برگرداندش. این‌طوری تابع صدازننده هم می‌تواند با Type Assertion نوع ارور را بررسی کند و باتوجه‌به آن نوع تصمیم بگیرد. بیایید با یک مثال ببینیم چطوری می‌شود.اول می‌آییم یک استراکت جدید تعریف می‌کنیم و برایش تابع Error را (که مال اینترفیس error بود) به‌عنوان متد پیاده‌سازی می‌کنیم. دقت کنید که این ارور ما فیلدهای دیگری هم دارد. یعنی هر دیتای اضافی‌ای هم که بخواهیم می‌توانیم توی ارورمان ذخیره کنیم.type NegativeSqrtError struct { msg string value float64 } func (e *NegativeSqrtError) Error() string { return e.msg } func Sqrt(f float64) (float64, error) { if f < 0 { return 0, &NegativeSqrtError{msg: "math: sqrt negative error", value: f} } return 0, nil }در نهایت تابعی که دارد از یک کدی که این ارور را برمی‌گرداند استفاده می‌کند می‌تواند هم این نوع از ارور را به‌طور به‌خصوص هندل کند و هم از اطلاعات اضافه‌ای که توی تایپ ارورمان گذاشته‌ایم (اینجا value و msg) استفاده کند (این مثال را می‌توانید توی پلی‌گروند ببینید). res, err := Sqrt(-1) if err != nil { if negativeError, ok := err.(*NegativeSqrtError); ok { fmt.Printf("Oh no! error is of type NegativeSqrtError for value: %g - msg: %v", NegativeError.value, negativeError) } else { fmt.Printf("Oh no! unknown error - %v", err) } } else { fmt.Printf("result: %g", res) }خب حالا به‌طورکلی دیدیم ارور تو گولنگ چطوری است. برویم ببینیم چه پیشنهاد‌ها و best practice برای کار با ارورها وجود دارند.اصلا نترسنقل قول و سخن بزرگان مهمی در گولنگ وجود دارد که به همین نکته اشاره می‌کند:اصلا نترسگولنگ مفهوم و تابعی دارد به نام panic. وقتی تابع پنیک صدا زده بشود، مثل throw عمل می‌کند و روند اجرای عادی برنامه متوقف می‌شود و اگر جایی این پنیک recover نشود، برنامه کلاً متوقف می‌شود و یک پیغام خطای طولانی و ترسناک به همراه استک‌تریس برمی‌گرداند.از روش‌هایی که گاهی برای مدیریت خطا در پروژه‌ها دیده می‌شود همین پنیک کردن و بعد ریکاور کردنش است (اینکه چطور این اتفاق پیاده‌سازی می‌شود از حوصله‌ی این متن خارج است. اینجا می‌توانید راجع به آن بیشتر بخوانید).این را همین اول آوردم که دیگر هی توی دلتان نگویید این چرت‌وپرت‌ها چیست بابا. از پنیک و ریکاور می‌شود مثل try و catch استفاده کرد. اما سخت در اشتباهید! پنیک کردن توی گولنگ قرار نیست روش مدیریت خطا باشد (هرچند شاید عملاً ممکن باشد)، به چند دلیل:این را همین اول آوردم که دیگر هی توی دلتان نگویید این چرت‌وپرت‌ها چیست بابا. از پنیک و ریکاور می‌شود مثل try و catch استفاده کرد. اما سخت در اشتباهید! پنیک کردن توی گولنگ قرار نیست روش مدیریت خطا باشد (هرچند شاید عملاً ممکن باشد)، به چند دلیل:اصلاً panic اسمش رویش است. مال وقتی است که برنامه پنیک کرده و نمی‌داند چی‌کار کند. چاره‌ای ندارد دیگر! اروری را که ایجاد شده کلاً نمی‌شود هندل کرد. نه اینکه یک تابع low level و api پنیک کند.فرض کنید یک http api دارید و صدها گوروتین دارند جواب کاربرهایتان را می‌دهند، یکی‌شان به خطا می‌خورد، آیا باید پنیک کند و کل برنامه را با همه‌ی گو روتین‌هایش به فنا بدهد؟لابد توی جواب قبلی گفتید که خب من که panic خالی نمی‌کنم. recover هم می‌کنم. ولی خب توجه ندارید دیگر! خیلی از کدها اصلاً ابزار هستند برای پروژه‌های گنده‌تر، تضمینی نیست که کسی که ازشان استفاده می‌کند بداند پنیک می‌کنند و باید حواسش به ریکاور کردن هم باشد.در نهایت، پنیک و ریکاور شاید بعضی جاها جواب بدهد و مشکلات پیش‌گفته را نداشته باشد، ولی یک code smell است. کسان دیگری که بعداً بخواهند روی پروژه‌تان کار کنند ممکن است فکر کنند همه‌ی برنامه‌نویس‌ها استانداردهای درست کد زدن توی گولنگ را بلد هستند و حواسشان به پنیک‌هایی که شما نوشته‌اید نباشد و ناسزا نثارتان کنند.آمدنت بهر چه بودمشکل دیگری که ارورها توی گولنگ دارند این است که هیچ stack traceای را به‌خودی‌خود برنمی‌گردانند و این مسئله، اگر پیغام خطای خوبی تولید نشود، ممکن است دیباگ کد را سخت کند، ولی خب به‌سادگی و با استفاده از یک پکیج معروف و کوچک، حل می‌شود.حالا شاید بگویید چرا توی خود گولنگ این قابلیت نیست؟ که خب لازم ندیده‌اند. توی خود کتابخانه‌های گولنگ، استانداردی برای تولید پیغام خطا رعایت می‌شود که از همان پیغام می‌شود فهمید ارور مال چه تابعی با چه ورودی‌هایی است (این هم از همین best practiceهاست که بقیه هم رعایتش می‌کنند). مثلاً تابع rename را در پکیج os گولنگ ببینید. توی پیغام خطا هم اسم تابع هست، هم پارامترهای ورودی تابع و هم ارور مد نظر:func rename(oldname, newname string) error { e := windows.Rename(fixLongPath(oldname), fixLongPath(newname)) if e != nil { return &LinkError{"rename", oldname, newname, e} } return nil }در نهایت هم به‌عنوان برنامه‌نویس استفاده‌کننده‌ی نهایی از این کد، این پیغام خطا از یک استک‌تریس طولانی خواناتر و قابل‌فهم‌تر است و مشکل را سریع‌تر به شما اطلاع می‌دهد، اما موقعی که می‌خواهیم کد خودمان را دیباگ کنیم استک‌تریس اهمیت پیدا می‌کند.اینجاست که پکیج github.com/pkg/errors کمکمان می‌کند. اگر با این پکیج ارور را بسازیم، این ارور استک را توی خودش ذخیره می‌کند و می‌شود بعداً چاپش کرد. باز هم مثال:import "github.com/pkg/errors" // then err := errors.Errorf("New error with stack-trace") // or err := errors.New("New error with stack-trace") // print stack trace top two levels st := err.StackTrace() fmt.Printf("%+v", st[0:2]) گفتن نکته‌ی دیگری هم که خالی از لطف نیست این است که می‌توانید یک ارور را داخل یک ارور دیگر wrap کنید. قبل از ورژن ۱.۱۳ خود گولنگ این قابلیت را نداشت و با تابع errors.Wrap و errors.Wrapf باید این کار را می‌کردید، ولی بعد از اون با %w توی fmt.Errorf هم می‌توانید همین کار را بکنید.err1 := fmt.Errorf("new err 1") err2 := fmt.Errorf("err2 wrapped %w", err1) fmt.Printf("%v\n", err2) // outpus "err2 wrapped new err 1"بعد از wrap کردن هم با تابع Cause‌ می‌توانید ریشه‌ی اصلی و اولین اروری را که بقیه‌ی ارورهای بعد از آن wrapاش کرده‌اند ببینید. به همین دلیل است که بهتر است برای مقایسه‌ی دو تا ارور از تابع errors.Is به‌جای == استفاده کنید، چون این wrap شدن و ارورهای سطوح مختلف را هم با ارور مدنظر شما مقایسه می‌کند. البته wrap کردن با fmt.Errorf استک‌تریس را نگه نخواهد داشت. ولی اگر با پکیج github.com/pkg/errors این کار را بکنید استک‌تریس راه هم خواهید داشت.یا هندل کن یا نکنیک کار نه چندان خوشایندی که در ابتدا هنگام رو به رو شدن با ارور می‌کردم این بود که همیشه در تابع‌های سطح‌ پایین‌ترم نیز ارور را لاگ می‌کردم:if err != nil { log.Errorf("err at function: %v:",err) return err }حالا تو تابع صدا زننده این تابع هم، وقتی به ارور می‌خوردم دوباره همین‌کار رو می‌کردم. صدا زننده‌ی اون هم. صدا زننده‌ی صدا زننده‌ی اون هم و الخ. بعد در تابع صدا زننده‌ی این تابع سطح پایین نیز وقتی به ارور برمی‌خوردم دوباره همین‌ کار را می‌کردم. در صدا زننده‌ی این تابع هم همچنین، و صدا زننده‌ی صدا زننده‌ی این تابع، و ... .با این کار اتفاقی که می‌افتاد این بود که وقتی در لاگ‌ها به دنبال یک خطا می‌گشتم، برای یک ارور تعداد زیادی خط تقریبا یکسان و مشابه مربوط به آن وجود داشت که هم حجم فایل لاگ را الکی چند برابر می‌کند و هم پیدا کردن مکان وقوع خطا را سخت می‌کند. مسلما روش درستی برای مدیریت و لاگ کردن خطا نیست. پس چه کار می‌شود کرد؟ من برای خودم، با کمک آقای Cheney، یک اصل گذاشتم: یا با ارور یک کاری بکن. یا هیچ کاری نکن و فقط برش گردان. یک کاری کردن هم می‌تواند هر کاری باشد. لاگ کردن، مدیریت کردن، پنیک کردن، ثبت کردن در دیتابیس یا هر کار دیگری. برای این که بفهمیم منشا اصلی ارور نیز کجا بوده است می‌توانیم همانطور که قبلا اشاره کردیم، در اولین برخورد با خطا، توسط کتابخانه‌ی github.com/pkg/errors و تابع Wrap یا Wrapf آن، ارور را به همراه استک‌تریس آن ثبت کنیم و در نهایت هنگامی که قرار است تابع را مدیریت و یا لاگ کنیم می‌توانیم توسط تابع StackTrace() منشا اصلی آن را پیدا کنیم:if err, ok := err.(stackTracer); ok { for _, f := range err.StackTrace() { fmt.Printf("%+s:%d\n", f, f) } }البته با استفاده از %+v در استرینگ فرمترها نیز می‌توان استک‌تریس را چاپ کرد (به کاراکتر + دقت کنید. بدون این کاراکتر تنها متن پیغام چاپ خواهد شد):if err != nil { fmt.Printf("error details and stacktrace: %+v", err) }با این توضیحات به طور کلی در مواجه با یک ارور، با توجه به این که کجا این ارور را دیده‌ایم، باید یکی از سه کار زیر را بکنیم: اگر ارور از کتابخانه‌ای غیر از سورس‌کد اصلی خود ماست، آن را wrap می‌کنیم و تا به همراه استک‌تریسش returnاش کنیم اگر ارور نیز توسط کد خود ما تولید می‌شود، در هنگام ساختش نیز استک‌تریس را به همراه آن ذخیره می‌کنیم.اگر در تابع‌های سطح بالا که اینترفیس نهایی کد هستند و دیگر قرار نیست خطایی را به تابع سطح بالاتری برگردانند و باید مدیریتش کنند به یک ارور برخوردیم، همانطور که واضح است، مدیریتش می‌کنیم. باز مدیریت کردن می‌تواند شامل عملیات‌های مختلفی باشد یا تنها شامل لاگ کردن خطا باشد.هر جایی بین این دو وضعیت، ارور را فقط return می‌کنیم. حتی نیازی به لاگ کردن نیز نیست. چون مطمئنیم نهایتا در جایی به همراه استک‌تریس آن لاگ خواهد شد.خشک‌تر و خشک‌تراولین چیزی که برایم توی گولنگ عجیب و کمی اذیت‌کننده بود این حجم عظیم if err != nil توی کد بود و که هرچند خط یک بار باید یک تکه کد تقریباً مشابه را تکرار کرد. هرچند الان بهش عادت کرده‌ام و به نظرم اگر نقطه‌ی قوت نباشد، اصلاً نقطه‌‌ضعف نیست و به نظرم نکته‌ی مثبتی است که ارورها همیشه این‌قدر جلوی چشم هستند، ولی اگر جایی بخواهیم ارور را لاگ هم بکنیم یا پراسس اضافه‌تری رویش انجام بدهیم، واقعاً سخت و اذیت‌کننده می‌شود. تازه کدمان هم از خشکی (DRY - Don't Repeat Yourself) درمی‌آید.برای اینکه ببینیم برای این کار چه کار‌هایی می‌شود کرد، بگذارید با دو تا مثال برویم جلو. مثالی را که اول متن زدیم در نظر بگیرید:_, err = fd.Write(p0[a:b]) if err != nil { return err } _, err = fd.Write(p1[c:d]) if err != nil { return err } _, err = fd.Write(p2[e:f]) if err != nil { return err }(شاید بگویید کی این اتفاق می‌افتد و کد این‌طوری خواهیم داشت که خب جواب این است که در ۹۹ درصد مواقع حق با شماست. ولی وقتی بخواهید با ioها به‌صورت low level کار کنید، احتمالاً بهش برمی‌خورید.)کاری که می‌شود این‌جور مواقع کرد این است که یک wrapper برای تابعمان بنویسیم که قبل صدا زدن خودش چک کند که اگر در مراحل قبلی صدا زدن ارور خوردیم، کاری نکند. برای همین تابع write می‌شود مثل مثال زیر:type errWriter struct { io.Writer err error } func (e *errWriter) Write(buf []byte) (int, error) { if e.err != nil { return 0, e.err } var n int n, e.err = e.Writer.Write(buf) return n, nil }اینجا دارد چه اتفاقی می‌افتد؟ errWriter ما یک متغیر از نوع error را توی خودش نگه می‌دارد. این متغیر کمک می‌کند تا برنامه‌ی ما یادش بماند آیا تا الان به ارور خورده‌ام یا نه. اگر به ارور نخورده‌ام که کارم را ادامه بدهم و تابعم را به‌صورت عادی صدا بزنم، ولی اگر به ارور خوردم، دیگر کاری نکنم و جای صدا زدن تابع ارورم را برگردانم:ew := &errWriter{w: fd} ew.write(p0[a:b]) ew.write(p1[c:d]) ew.write(p2[e:f]) if ew.err != nil { // handle the error }یک سرویس HTTP API مثال خوب دیگری از این است که چطور با wrapperها می‌توانیم ارور هندلینگ را بهتر و خشک‌تر کنیم. وقتی ما یک API می‌نویسیم، می‌خواهیم هر وقت به اروری خوردیم که نشد کاری‌اش کنیم، یک ارور مشخص به کاربر برگردانیم. مثلاً اگر رکوردی پیدا نشد، ۴۰۴ برگردانیم. اگر دسترسی نداشت، ۴۰۳ برگردانیم یا در حالت کلی هم می‌خواهیم خطای 5xx برگردانیم. کنار این، می‌خواهیم خطا را لاگ هم بکنیم. مثلاً این کد را در نظر بگیرید( کد تو پلی‌گروند):func main() { http.HandleFunc("/", HelloWorld) http.ListenAndServe(":8080", nil) } func HelloWorld(w http.ResponseWriter, r *http.Request) { user, err := getUser(r.URL.Path[1:]) if err != nil { if errors.Is(err, ErrNotFound) { // log something for example http.Error(w, err.Error(), 404) return } } _, err = fmt.Fprintf(w, "Hello, %s!", user.Name) if err != nil { if errors.Is(err, ErrNotFound) { // log something else http.Error(w, err.Error(), 500) return } } } حالا فکر کنید همین یک مسیر و route نیست و ده‌ها درخواست مختلف هست که هرکدام هم تابع‌های مختلفی را صدا می‌زنند و امکان چندین مدل ارور در آن‌ها وجود دارد. مسلماً این روش درستی نیست.کار ساده‌ای که می‌توانیم بکنیم این است که ارور را توی این توابع هندلرمون، مدیریت نکنیم و فقط برگردانیمش. این‌طوری:func HelloWorld(w http.ResponseWriter, r *http.Request) error { user, err := getUser(r.URL.Path[1:]) if err != nil { return err } _, err = fmt.Fprintf(w, "Hello, %s!", user.Name) if err != nil { return err } }و بعد یک wrapper می‌نویسیم که این تابع را به‌عنوان ورودی بگیرد و یک تابع که بشود به‌عنوان ورودی به http.HandleFunc داد برگرداند. اون وسط هم ارور را هندل کند. چطوری؟ این‌طوری (کد تو پلی‌گروند):type HandlerFuncWithError func(http.ResponseWriter, *http.Request) error type HandlerFunc func(http.ResponseWriter, *http.Request) func ErrWrapper(cb HandlerFuncWithError) HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { if err := cb(w, r); err != nil { // log the error if errors.Is(err, ErrNotFound) { http.Error(w, err.Error(), 404) return } http.Error(w, err.Error(), 500) return } } }حالا دیگر هر تابع هندلری که می‌نویسید فقط باید error را برگرداند و هندلرها هم این‌طوری به پکیج http داده بشوند:http.HandleFunc("/", ErrWrapper(HelloWorld))زیباست. نه؟ در نهایت، بسته به موقعیت و ساختار کد، راهکار‌های مختلفی برای مدیریت ارورها می‌توان در نظر گرفت. هر کاری که حس می‌کنید توی کدتان بهتر و خشک‌تر و تمیزتر است بکنید، فقط نترسید و ارور‌ها را هم دور نریزید. :)منابع:The Go Blog - Error Handling and GoGabriel Tanner - Error handling in GolangDave Cheney - Why Go Gets Exceptions RightDave Cheney - Don’t just check errors, handle them gracefully

ریاضیات برای یادگیری ماشین (جبر خطی قسمت دوم)

Mohsen Shahverdi — Tue, 26 Oct 2021 11:57:52 +0330

محسن شاهوردی کندریسلام تو این مقاله قصد داریم ادامه مقاله جبر خطی رو داشته باشیم. 2.4)فضاهای برداری (Vector Spaces):به دلیل بازتعریفی دستگاه معادلات خطی به شکل ماتریسی و برداری نیاز است ما فضاهای برداری را نیز بدانیم به همین دلیل این بخش در کتاب قرار داده شده است.2.4.1) گروه ها (groups): گروه ها نفش مهمی را در گرایشات علوم کامپیوتر همانند کدینگ (coding theory) , گرافیک کامپیوتری و رمزنگاری بازی میکند.اگر علاوه بر شروط بالا شرط زیر نیز برقرار باشد این گروه را یک گروه Abelian میگوییم.چند مثال برای گروه ها:2.4.2) فضاهای برداری‌(Vector Spaces): برای تعریف فضاهای برداری ما نیاز به تعریف گروه هایی داریم که در آنان دو عملگر به جای یک عملگر وجود دارد.فضا برداری: یک فضا برداری با مقادیر حقیقی به شکل زیر روی مجموعه تعریف میشود.دقت کنید که (?, +) یک گروه Abelian می باشد.توزیع پذیری‌:انجمنی برای عملگر بیرونی:عضو خنثی برای عملگر بیرونی:به اعضای x زیر مجموعه V بردار گفته میشود. برای مثال بردار صفر : 0 = [0,... , 0]روی بردار ها میتوان چندین گونه از عملگرها و عملیات ها را تعریف کرد برای مثال ضرب عنصر به عنصر, ضرب داخلی و خارجی که همگی به شکل ضرب ماتریسی هستند.در کتاب مثال هایی مطرح شده است که به دلیل شباهت به مثال های بخش ماتریس ها (2.2) به آنان پرداخته نخواهد شد.2.4.3) زیرفضا های برداری (Vector Subspaces): زیرفضاها در یادگیری ماشین بسیار اهمیت دارند به خصوص در فصل دهم کتاب نشان خواهیم داد چگونه با استفاده از زیرفضاها در کاهش ابعاد مسائل را حل خواهیم کرد.زیرفضای برداری: فضای برداری را در نظر بگیرید. آنگاه به U = (?,+,.) یک زیرفضای برداری برای V می گوییم اگر U نیز خود یک فضا برداری با دو عملگر + و . باشد (شروط یک فضا برداری روی آن نیز صادق باشد).دقت کنید که اگر ? زیر مجموعه ? باشد و V نیز یک فضا برداری باشد آنگاه U بسیاری از خواص موجود در V را به ارث خواهد برد.برخی از نکات مهم در مورد زیر فضای U :اگر ? تهی نباشد آنگاه 0 عضوی از ? است.2.5)استقلال خطی‌(Linear Independence): برای معرفی استقلال خطی ابتدا لازم است ترکیب خطی را معرفی کنیم.ترکیب خطی(linear combination): فضابرداری V و تعداد k بردار x1, ... , xk زیر مجموعه V را در نظر بگیرید. آنگاه هر v عضوی از V به شکلاستقلال خطی (Linear Independence): یک فضابرداری V بارا در نظر بگیرید. اگر یک ترکیب خطی وجود داشته باشد(به جز ترکیب خطی با تمامی ضرایب 0 که در بالا ذکر شد) که برقرار باشد مجموعه بردارهای x1, ... , xk مستقل خطی نیستند.اگر تنها یکی از بردارهای مجموعه بردارهای ما برابر با ترکیب خطی بقیه k - 1 بردار ما باشد مجموعه بردارها مستقل خطی نخواهند بود.مثال: 3 بردار زیر را در نظر بگیرید و استقلال خطی آنان را بررسی کنید.راه حل : برای حل باید جواب های معادله زیر را بیابیم.برای بدست آوردن جواب های معادله زیر باید آن را به شکل یک دستگاه معادله نوشته و سپس با روش های ذکر شده در قسمت 2.3 آن را حل کنیم.میتوان از سطر اول این نتیجه گیری را داشت که هیچ جواب دیگری جز 1 = 0, 2 = 0, 3 = 0 برای معادله فوق وجود ندارد.یک فضا برداری V با k بردار مستقل خطی b1, . . . , bk و m ترکیب خطی به شکل زیر:آنگاه ماتریس B را میتوان به شکل B=[b1, . . . , bk ]تعریف کرد که ستون های آن مستقل خطی هستند با برداری ها b1, . . . , bk که آنگاه میتوان به شکل زیر بازنویسی کردبرای یک حالت پیچیده تر, حال میخواهیم استقلال خطی x1, . . . , xmرا بررسی کنیم به همین منظور به شکل مرسوم به بررسی جواب های معادله زیر میپردازیم.سپسمعادله فوق نشان میدهد {x1, . . . , xm}مستقل خطی هستند اگر و تنها اگر بردارهای ستونی مستقل خطی باشند. از معادله فوق میتوان نتیجه گرفت که در فضابرداری V, با m ترکیب خطی و k بردار x1, . . . , xk وابسته خطی هستند اگر m > k.مثال: بردارهای b1, b2, b3, b4 که مستقل خطی هستند را در نظر بگیرید. و استقلال خطی x1, x2, x3, x4 را بر اساس دستگاه زیر بررسی کنید.برای حل این سوال ابتدا بر اساس ضرایب b1, b2, b3, b4بردارهای زیر را میسازیم.حال ماتریس A را مطابق با روابطی که قبل از مثال وجود داشت تشکیل میدهیم و تلاش به یافتن جواب های معادله میکنیم.که ماتریس به شکل زیر نتیجه میشودکه نشان میدهد میتوان x4= -7x1-15x2-18x3 را تشکیل داد به همین دلیل x1, x2, x3, x4 مستقل خطی نیستند.2.6)پایه و رتبه‌ (Basis and Rank): در این قسمت از کتاب به تعریف برخی دیگر از مفاهیم بر روی یک فضابرداری و ماتریس میپردازیم.2.6.1)مجموعه مولد و پایه(Generating Set and Basis): مجموعه مولد و اسپن(generating set and span): یک فضابرداری V = (?,+,.)و مجموعه بردارهای ? = {x1, . . . , xk} زیر مجموعه ? را در نظر بگیرید. اگر هر بردار ?را بتوان با یک ترکیب خطی از x1, . . . , xk ایجاد کرد آنگاه ما به مجموعه ? مجموعه مولد برای فضابرداری ? و به تمامی ترکیب های خطی مجموعه ? اسپن آن مجموعه میگوییم.اگر اسپن مجموعه ? برابر با فضابرداری V باشد میتوانیم بنویسیم : V = span[?] or V = span[x1, . . . , xk]پایه(Basis): فضابرداری V=(?,+,.) و ? زیر مجموعه ? را در نظر بگیرید. یک مجموعه مولد ? را کمینه(minimal) مینامیم اگر هیچ مجموعه کوچکتری وجود نداشته باشد کهکه اسپن آن برابر V باشد. حال به هر مجموعه مولد مستقل خطی ای که minimal نیز باشد یک پایه بر V میگوییم (در واقع یک پایه یک مجموعه مدل کمینه است در حالی که بزرگترین مجموعه مستقل خطی از یک فضابرداری است).فضابرداری V=(?,+,.) , ? زیرمجموعه ?و ? مخالف ∅ را در نظر بگیرید. تمامی گزاره های زیر با هم برابرند:? یک پایه برای V است.? یک مجموعه مولد کمینه است.? یک بزرگترین مجموعه مستقل خطی از بردارها بر روی V است که با افزودن هر بردار دیگری این مجموعه وابسته خطی خواهد بود.هر بردار x عضوی ازV یک ترکیب خطی از بردارهای ? است و هر ترکیب خطی از آن یکتاست.مثال: بردارهای یکه فضابرداری R3یک پایه برای آن است.برخی دیگر از پایه ها برای فضای R3:در این کتاب ما تنها فضابرداری های با ابعاد محدود را مورد مطالعه قرار میدهیم که در این فضاها ابعاد فضای V برابر است با تعداد بردارهای مجموعه پایه V. اگر U زیرمجموعهV یک زیرفضا برای V باشد آنگاه dim(U) کوچکتر مساوی dim(V) و dim(U) = dim(V) خواهد بود اگر و تنها اگر U = V باشد.دقت کنید که ابعاد یک بردار از فضا ارتباطی به اعضای یک بردار ندارد. برای مثال V = span([0 1])یک فضای یک بعدی را نمایش میدهد درحالیکه بردار پایه آن دو عنصر دارد.2.6.2)رتبه (Rank): به تعداد ستون های مستقل خطی ماتریس A عضو Rmn که برابر با تعداد سطرهای مستقل خطی آن است رتبه ماتریس گفته میشود که به شکل rk(A)گفته میشود.2.7)نگاشت خطی(Linear Mapping):تا به اینجا ما بردارها را تعریف کرده ایم به طوری که قابلیت جمع شدن با یکدیگر و ضرب در یک اسکالر را دارند. یک نگاشت حفظ میکند ساختار فضابرداری را اگر:نگاشت خطی(linear mapping): برای هر فضابرداری V و W, یک نگاشت همانند را خطی می نامیم اگر: یک نگاشت را در نظر بگیرید که V و W میتواند مجموعه هایی دلخواه باشند آنگاه به نگاشتیک به یک (Injective): اگر2.7.1) نمایش ماتریس ترکیب خطی(Matrix Representation of Linear Algebra): هر فضابرداری n بعدی یکریخت است(براساس یک قضیه در کتاب). حال بردارهای پایه {b1, . . . , bn}را برای یک فضابرداری n بعدی در نظر بگیرید و دقت کنید که ترتیب این بردارها مهم باشد و آنان را به شکل B = (b1, . . . , bn) بنویسیم آنگاه به دسته n تایی مانند B یک بردار پایه ترتیبی میگوییم.مختصات(Coordinates): فضابرداری V و مجموعه پایه ترتیبی B = (b1, . . . , bn) روی فضابرداری V در نظر بگیرید. به ازای هر x عضو V ما میتوانیم با یک ترکیب خطی مشابه زیر نمایش دهیم:حال به مجموعه ضرایب بالا مختصات x هستند بر روی بردارهای پایه B ویک بردار مختصات یا نمایش مختصاتی از x است بر روی بردارهای پایه B.ماتریس انتقال (Transformation Matrix): فضابرداری های V و W را در نظر بگیرید با بردار های پایه B = (b1, . . . , bn) و C = (c1, . . . , cn)و یک نگاشت خطی از V به W برای j های روی {1, . . . , n}در واقع نگاشت بالا یکتاست بر روی C. اکنون ماتریس m*n تعریف میکنیم (A) که هر درایه آن به شکل زیر است:که به ماتریس بالا ماتریس انتقال گفته میشود.چند مثال دیگر از نحوه کارکرد ماتریس انتقال در تصویر زیر میبینیم که به ترتیب شکل b برای ماتریس انتقال A1, شکل c برای ماتریس انتقال A2و همینطور شکل d برای ماتریس انتقالA3 هستند.2.7.2)تغییر پایه (Basis Change): فرض کنیم نگاشت خطی از V به W بر روی V و W موجود است با بردارهای پایه B و C و حال ما میخواهیم بردارهای پایه را تغییر دهیم و سپس ماتریس انتقال را از روی ماتریس انتقال فعلی محاسبه کنیم.که اثبات میشود (کتاب صفحه 60) ماتریس انتقال جدید از رابطه زیر بدست می آید؛که ماتریس S عضو Rnn یک ماتریس انتقال یک idv بر حسب بردار پایه جدید B بر روی B و همینطور T عضو Rmm برای C.برای اثبات میتوان به کتاب مراجعه کرد.2.7.3) تصویر و هسته (Image and Kernel): روی نگاشت V به W هسته یا فضای پوچی را به شکل زیر تعریف میکنیم:تصویر یا برد (image or range) نیز به شکل زیر تعریف میشود:قضیه رتبه و فضای پوچی(Rank-Nullity Theorem): برای هر فضای حالت V و W و نگاشت خطی رابطه زیر برقرار است :این قضیه یکی از مهم ترین قضایا در جبر خطی میباشد اما اثبات آن در قالب این مقاله جا نمی گیرد و علاقمندان میتوانند در کتاب جبر خطی نوشته شلدون اکسلر فصل 3 قضیه 22 اثبات آن را بیابند.2.8)فضای آفین(Affine Spaces):ما از نزدیک فضاهایی را که از مبدا جابجا می شوند ، خواهیم دید ، یعنی فضاهایی که دیگر زیر فضایی برداری نیستند. علاوه بر این ، ما مختصراً در مورد خصوصیات نگاشت بین این فضاهای وابسته ، که شبیه نگاشت های خطی است ، بحث خواهیم کرد.2.8.1)زیر فضاهای آفین(Affine Subspaces): اگر V یک فضای برداری باشد و x0 عضوV باشد و U زیر مجموعه V یک زیر فضا باشد آنگاه :که به آن زیرفضای آفین روی V میگویند و U را مسیر یا فضای مسیر میگویند.به پایان مباحث جبرخطی از کتاب ریاضیات برای یادگیری ماشین رسیدیم. اگر این نوشته برایتان جذاب بود و خواستار ادامه نگارش چنین مطالبی هستند حتما بهم بگید.باتشکر.

کپی‌رایتینگ یا کانتنت مارکتینگ؟

zeynabmirfeyzi — Wed, 13 Oct 2021 10:13:54 +0330

چند وقت پیش در دوره‌ای ثبت‌نام کردم که آزمون ورودی داشت. یکی از سؤال‌های آزمون این بود: «تفاوت کانتنت مارکتینگ و کپی‌رایتینگ چیست؟» در دلم گفتم: «خوب معلوم است دیگر!» و تند تند جواب را در دو خط نوشتم.حدود دو هفته بعد با یکی از دوستانم صحبت می‌کردم که چند وقتی بود برای عنوان شغلی «کپی‌رایتر» در جست‌وجوی کار ثابت بود. با شک و تردید می‌گفت: « یا ما نمی‌دونیم کپی‌رایتینگ چیه یا واقعاًااا نمی‌دونیم کپی‌رایتینگ چیه. کارهایی که توی شرح شغلی کپی‌رایتر آوردن کار مدیر محتوا یا مدیر کانتنت مارکتینگه! کارفرماها هم قبول ندارن که!»و این‌ چنین شد که با خودم فکر کردم: «نکند ما واقعاً درک اشتباهی از این دو تعریف داریم. شاید من هم اشتباه می‌کنم!» چند ساعتی در منابع و سایت‌های معتبر مثل copy blogge ، forbes و cmi چرخ زدم تا ببینم اهل فن چه تفاوت‌هایی برای این دو مفهوم قائل هستند. این مقاله برداشت من از مفاهیمی است که در این منابع معتبر خوانده‌ام.کپی‌رایتینگ یا کانتنت مارکتینگ؟ابتدا معنا را پیدا کنیمقبل از اینکه ادامۀ متن را بخوانید، چند ثانیه با خودتان فکر کنید. شما چه تفاوت‌هایی بین این دو موضوع می‌بینید؟ اصلاً شاید به‌نظرتان یکی باشند. تعریف‌تان را یادداشت کنید تا بعداً راجع به آن صحبت کنیم. من هم چند ثانیه سکوت می‌کنم تا شما با آرامش فکر کنید.............برای اینکه تفاوت این دو موضوع را مشخص کنیم، خوب است اول تعریفی از هرکدام ارائه دهیم:در کانتنت مارکتینگ (content marketing) یا بازاریابی محتوایی، ما محتوایی رایگان و کاربردی برای جذب مخاطب تولید می‌کنیم. هدف ما این است که این مخاطب را به مشتری‌ای تبدیل کنیم که بارها و بارها از ما خرید کند. پست‌های بلاگ، ای‌بوک‌ها، مقاله‌های آموزشی، ویدئوها و پادکست‌ها نمونه‌های محتوایی هستند که برای رسیدن به اهداف بازاریابی محتوایی تهیه می‌شوند.کپی‌رایتینگ (copywriting) نوشتن متن‌های تبلیغاتی و درخواست انجام یک کار (action) خاص از سمت کاربر است؛ ، مثلاً خرید، عضویت، ثبت‌ نام در خبرنامۀ ایمیلی و... . متن‌های تبلیغاتی، شعارها و متن بیلبوردها، کپشن‌های شبکه‌های اجتماعی، محتوای صفحات فروش، پیامک، نوتیفیکشن‌ها و لندینگ‌پیج‌ها نمونه‌های محتوایی هستند که یک کپی‌ رایتر می‌نویسد.پس دقیقاً تفاوت این دو مفهوم کجاست؟این دو موضوع از چند نظر با هم متفاوت هستند:۱. هدفهدف کپی‌رایتینگ تشویق مشتری یا کاربر به انجام دادن یک کار (action) خاص است؛ خرید، ثبت‌ نام، عضویت. در کانتنت مارکتینگ هدف آموزش و آگاه کردن مخاطب است، نه الزاماً خرید. به قول یوسف فراهانی، کپی‌رایتر در زمین برند و سازمان سینه می‌زند، اما کانتنت مارکتر در زمین مشتری.فرض کنید شما سایتی برای فروش کالای دیجیتال دارید. در بخش بلاگ، محتواهایی آموزشی مثل مقایسۀ گجت‌ها، اخبار جدید و به‌‌روزرسانی امکانات جدید این کالاها را پوشش می‌دهید، یا ویدئوهای جذاب برای آن‌باکسینگ و معرفی محصولات جدید آماده می‌کنید. در این بخش شما کاملاً در حال بازاریابی محتوا هستید و هدف شما افزایش دانش مخاطب است.در همین سایت، صفحات لندینگ، که برای جشنواره‌ها یا فروش کالای خاصی طراحی می‌شود، محتوای تبلیغاتی لازم دارد. هدف شما در این صفحه فروش است، نه آموزش. پس محتوای این صفحه محتوایی کاملاً تبلیغاتی است که یک کپی‌رایتر باید بنویسد.۲. مهارت‌کانتنت مارکتر باید چنل‌های مختلف ارتباط با کاربر را به‌خوبی بشناسد. پس، مهارت‌هایی که ممکن است در شرح شغلی یک کانتنت مارکتر ببینیم شامل این‌هاست: مهارت در نوشتن و داستان‌ سرایی؛ آشنایی با سئو ( حداقل سئو محتوایی و کیورد ریسرچ)؛ آشنایی با ابزارهای رصد سایت (گوگل آنالیتیکس و سرچ کنسول تا حدی)؛ مهارت برنامه‌ریزی و مدیریت پروژه (آشنایی با ترلو یا ابزارهای مشابه)؛ آشنایی با روش‌های مختلف تولید محتوا ( متن، تصویر، ویدئو و حتی صوت. لازم نیست به همه مسلط باشید، اما روش درست استفاده از هرکدام را بدانید)؛ تسلط کامل به استفاده از چنل‌های انتشار محتوا؛ تسلط کامل به انواع روش جذب مخاطب.کپی‌رایتر قرار است محتواهایی بنویسد که برای برند ورودی‌های مشخص داشته باشد. پس، مهارت‌های زیر ممکن است در شرح شغلی یک کپی‌رایتر نوشته شود: تسلط عالی به نوشتن، داشتن دایرۀ لغات قوی و آشنایی کامل با ویرایش؛ خلاق و ایده‌پرداز؛ -تسلط به مفاهیم برند و روش‌های ارتباط برند با مخاطب؛ تسلط کامل به تبلیغ‌ نویسی و تیتر نویسی؛ آشنایی با تجربۀ کاربری و مخاطب‌شناسی؛ تسلط کامل به انواع روش جذب مخاطب.۳. حجم محتواهامحتواهایی که برای کانتت مارکتینگ تولید می‌شوند، آموزشی هستند و عجیب نیست اگر ویدئویی آموزشی ۳۰ دقیقه یا مقاله‌ای آموزشی ۲۰۰۰ کلمه باشد. چرا؟ چون مخاطب حاضر است برای یادگیری خودش ۲۰ دقیقه پای ویدئویی خوب بنشیند، اما به‌نظرتان حاضر است ۲۰ دقیقه صرفاً به تبلیغات شما گوش کند؟ قطعاً نه!! به همین دلیل، متن‌ها و تیزرهای تبلیغاتی باید خیلی کوتاه باشند. عبارت‌های چند کلمه‌ای و تیزرهای ۳۰ثانیه‌ای، نهایتِ فرصت کپی‌رایترها برای رسیدن به هدف است. ۴. احساساتمحتواهای کپی‌رایتینگی به‌ شدت احساسات مخاطب را درگیر می‌کنند. نتیجۀ تحقیق آقای Gerald Zaltman از استادان دانشگاه هاروارد نشان می‌دهد که از هر ۱۰ خرید، ۹ تا کاملاً احساسی هستند. افراد ترس از دست دادن (FOMO) دارند و احساس می‌کنند اگر تخفیف یا جشنواره‌ای را از دست بدهند، بازنده هستند. کپی‌رایتر کسی است که باید احساسات مخاطب را کاملاً درگیر کند.اما محتواهای آموزشی که کانتنت مارکترها آن را آماده می‌کنند، محتواهای کاملاً منطقی و آموزشی هستند و کم‍تر احساسات مخاطب را درگیر می‌کنند.محتوای بدون کپی‌رایتینگ، هدر دادن محتواستشاید پست‌های بلاگ خیلی خوبی داشته باشید که به‌نظر خودتان فوق‌العاده باشند، اما بازدید زیادی ندارند و برای مخاطب آن‌قدرها هم که جذاب نیستند. مشکل کار کجاست؟احتمالاً متن شما به کمی چاشنی کپی‌رایتینگ نیاز داشته باشد. من اسمش را می‌گذارم «بازبینیِ کپی‌رایتینگی». متن شما تیتر جذابی ندارد: حتماً می‌دانید که شما فقط ۵ ثانیه برای جذب مخاطب وقت دارید، پس حتماً داشتن عنوان جذاب از نکته‌های واجب برای جذب مخاطب است. اول باید توجه مخاطب را جلب کنید تا بیاید و بقیۀ مقاله‌تان را بخواند .در کپی‌رایتینگ می‌گویند تیتر باید مگنتی باشد، یعنی مثل آهنربا حواس مخاطب را جذب کند. هم جذاب باشد، هم مزایا را بگوید و هم کنجکاوی مخاطب را قلقلک دهد. اکشن‌های خوبی از مخاطب نمی‌خواهید: پادکست خوبی درست کرده‌اید؟ ویدئوی مفیدی آماده‌ کرده‌اید؟ قبول! اما بالاخره باید افراد را به روشی تشویق کنید که بیایند روی دکمۀ «پخش ویدئو» کلیک کنند دیگر! همین‌طور که نمی‌شود وقتشان را بگذارند برای گوش دادن به صحبت‌های شما. اینجا کپی‌رایتینگ عصای دستتان می‌شود. با نوشتن تیترها و «کال تو اکشن‌»های جذاب (call to action) مخاطب را تشویق می‌کند تا پادکست را گوش دهند یا ویدئو را پخش کنند.البته معنایش این نیست که همه‌چیز کپی‌رایتینگ است، در واقع کپی‌رایتینگ به کمک کانتنت ‌مارکتینگ می‌آید و هر دو بخشی از فرآیند بازاریابی و مارکتینگ هستند.چرا این یادداشت را نوشتم؟برای ندیدن دوبارۀ این آگهی‌ها.آگهی شغلی کپی‌رایترگاهی بعضی چیزها به‌نظرمان خیلی واضح است و اصلاً نیازی نمی‌بینیم راجع به آن‌ها گفت‌وگو کنیم. به‌ نظر بسیاری از کارفرماها مدیر محتوا همان کسی است که برنامه و استراتژی می‌چیند، لندینگ پیج‌ها و محتواهای سوشال را آماده می‌کند، محتوای بلاگ می‌نویسد و...… . حتی خودِ کارشناسان محتوا و کپی‌رایترها هم گاهی تفاوت دقیقی بین این دو موقعیت شغلی قائل نیستند.به‌نظرم الان وقت مناسبی است که برگردید و تفاوت‌هایی را که ابتدای متن نوشتید یک بار دیگر ببینید. اگر دوست دارید در یکی از این حوزه‌ها کاملاً عمیق شوید، با آگاهی کامل فیلد محبوب‌تان را انتخاب کنید.اگر شما هم تجربه‌ای از این «به اشتباه گرفته‌ شدن» دارید، حتماً در کامنت برایمان بنویسید تا راجع به آن گفت‌وگو کنیم.

ریاضیات برای یادگیری ماشین (جبر خطی)

Mohsen Shahverdi — Sat, 09 Oct 2021 17:03:47 +0330

محسن شاهوردی کندریاین مقاله مجموعۀ دوم از مقالات ریاضیات برای یادگیری ماشین است (فصل اول). در این مقاله، قصد داریم فصل دوم از کتاب Mathematics for Machine Learning را بررسی کنیم. فصل دوم کتاب به بررسی موضوعات دربارۀ جبر خطی می‌پردازد. در ادامه، عنوان‌های فصل دوم کتاب را می‌بینید و بعد از آن خلاصۀ فصل شروع می‌شود. چون در این فصل تعداد بسیار زیادی فرمول داریم و تایپ تمامی این فرمول‌ها زمان‌گیر است، من از این به بعد از تصاویر کتاب استفاده می‌کنم. امیدوارم این تغییر شما را در روند خواندن مقالات اذیت نکند.در ابتدا، برای فهم بهتر و داشتن دید وسیع‌تری به مباحث این فصل می‌توانید به شکل زیر نگاه کنید که دیدگاهی اولیه به مفاهیم فصل دوم، ارتباط آن‌ها با یکدیگر و ارتباطشان با فصل‌های بعدی ایجاد می‌کند.2.1) سیستم معادلات خطی (Systems of Linear Equations):سیستم معادلات خطی نقش بسیار گسترده و پررنگی در ریاضیات و به‌خصوص مباحث مرتبط به مدل‌سازی و یادگیری ماشین ایفا می‌کنند. به مجموعه‌ای از معادلات به‌شکل زیر یک دستگاه یا سیستم معادلات خطی گفته می‌شود.مجموعۀ جواب‌های معادله به هر مجموعۀ nعضوی مثل (x1, x2, . . . , xn) ∈ Rn گفته می‌شود که در معادلۀ بالا صدق کند.برای مثال مجموعۀ جواب (1، 1، 1) جواب دستگاه معادلۀ زیر است که اگر در مقادیر جای‌گذاری انجام دهید، هر سه معادله نتیجه می‌دهد.شهود حل دستگاه معادلات بالا به ازای (1، 1، 1) این‌گونه است که ۳ صفحۀ بالا در یک نقطه به مختصات (1,1,1) برخورد دارند. برای دو بعدی تصویر زیر کمک‌کننده است.باید دقت کنیم که جواب هر دستگاه معادلات خطی ممکن است یک صفحه، یک نقطه یا حتی یک مجموعۀ تهی باشد. برای مثال، در دستگاه مختصات دو بعدی دو خط با معادله عدد ثابت جوابی ندارند.2.2) ماتریس (matrix):ماتریس‌ها نقشی بسیار حیاتی در جبر خطی دارند و با استفاده از آن‌ها می‌توان بسیاری مسائل را ساده‌تر حل کرد و نوعی ابزار قدرتمند ریاضی هستند. ماتریس در واقع یک چندتایی (tuple) با K عضوی است که K = M * N است و N تعداد ستون‌ها و M تعداد سطرها را نشان می‌دهد و aij, i = 1, ... , m, j=1, ... , n است که به aij ها درایه گفته می‌شود. در زیر مثالی برای ماتریس آورده شده است.2.2.1) ضرب و جمع ماتریس (Matrix Addition and Multiplication): ما بر روی ماتریس‌ها به تعریف عملیات پایه‌ای همچون جمع و ضرب نیاز داریم. عملیات جمع بر روی ماتریس‌ها به‌شکل جمع درایه به درایه تعریف می‌شود. باید دقت کنید که هنگام جمع دو ماتریس با یکدیگر باید ابعاد هر دو ماتریس با هم برابر باشد، در غیر این‌صورت قادر به انجام عمل جمع نخواهیم بود. در شکل زیر جمع دو ماتریس نمایش داده شده است.ضرب دو ماتریس به‌شکل زیر تعریف می‌شود و باید دقت کنید که هنگام ضرب دو ماتریس باید ابعاد همسایه با هم برابر باشند. در ضرب زیرابعاد همسایه k است و چون در دو ماتریس A و B برابر است، ضرب این دو ماتریس ممکن است و ابعاد ماتریس نتیجه برابر با سطرهای ماتریس اول و ستون‌های ماتریس دوم خواهد بود، اما ضرب B در A را به‌دلیل مساوی نبودن n و m نمی‌توان تعریف کرد.مثالی از ضرب دو ماتریس برای نشان دادن اینکه AB ≠ BA برقرار است.ماتریس همانی (Identity Matrix): به ماتریس مربعی (n * n) گفته می‌شود که درایه‌های قطر اصلی آن ۱ و بقیۀ درایه‌ها صفر هستند.cij = 1 if i = j else 0تعریف برخی خاصیت‌های روابط ماتریسی:خاصیت انجمنی (associativity):خاصیت توزیع‌پذیری (Distributivity):ضرب ماتریس در ماتریس همانی:2.2.2) وارون ماتریس و ترانهاده (Inverse and Transpose):ماتریس وارون: ماتریس مربعی A ∈ R n * n را در نظر بگیرید. ماتریس B ∈ R n * n را ماتریس وارون A می‌نامیم، اگر AB = I = BA باشد و آن را به‌طور عمومی با A -1 نمایش می‌دهیم.باید دقت کنید وارون تنها برای ماتریس‌های مربعی تعریف می‌شود و همچنین هر ماتریس A مربعی‌ای نیز وارون ندارد که در آینده دراین‌باره بیشتر صحبت خواهیم کرد. اگر A ماتریسی باشد که وارون داشته باشد، به A ماتریس regular/invertible/nonsingular و در صورت نبود وارون به آن singular/non invertible گفته می‌شود.مثال: برای یک ماتریس ۲ * ۲ تلاش می‌کنیم که ماتریس وارون بیابیم.ماتریس A را به‌شکل زیر فرض کنید.سپس اگر ماتریس 'A به‌شکل زیر تعریف شود،ضرب این دو ماتریس برابر با ماتریس همانی خواهد شد، اگر یک ضریب اسکالر را نیز در نظر بگیریم.پس ماتریس وارون A برابر خواهد بود با:به ضریب ثابتی که در مخرج قرار دارد و در ماتریس بالا ضرب شده است دترمینان گفته می‌شود که در واقع یک نگاشت از درایه‌ها به یک اسکالر است که در فصل‌های آینده بیشتر دراین‌باره صحبت خواهیم کرد، اما باید دقت کنیم ماتریس A در صورتی وارون خواهد داشت که دترمینان آن برابر با صفر نباشد.ترانهاده (transpose): ماتریس A ∈ R m * n را در نظر بگیرید. ماتریس B ∈R n * m با درایه‌های bij = aji را ترانهادۀ ماتریس A می‌نامیم و به‌شکل AT= B نمایش می‌دهیم.برخی خواص وارون و ترانهادۀ ماتریس‌ها:ماتریس متقارن (symmetric matrix): ماتریس A متقارن است اگر A = AT برقرار باشد.اگر A معکوس‌پذیر باشد، آنگاه ترانهادۀ A نیز معکوس‌پذیر است.2.2.3) ضرب ماتریس در اسکالر (Multiplication by a Scalar): ما همچنین می‌توانیم یک عدد را در یک ماتریس ضرب کنیم که به‌شکل زیر تعریف می‌شود.خاصیت انجمنی (Associativity):خاصیت توزیع‌پذیری (distributivity):2.2.4) نمایش فشردۀ سیستم‌های معادلات خطی (Compact Representations of Systems of Linear Equations): از ماتریس‌ها می‌توانیم برای نمایش دستگاه‌های معادلۀ خطی استفاده کنیم. برای مثال، می‌توان دستگاه معادلات زیر را به‌شکل ماتریسی نمایش داد و سپس از خاصیت‌های موجود بر روی ماتریس‌ها استفاده کرد و دستگاه‌های معادلات خطی را حل کرد.شکل ماتریس دستگاه بالا.حال ما یک دستگاه معادلات خطی را به‌صورتAx = b نمایش دادیم که A ماتریس ضرایب است و x ماتریس مجهولات و b نیز ماتریس اعداد ثابت ماست. در قسمت بعدی فصل دو به برخی روش‌های حل دستگاه‌های معادلات خطی می‌رسیم و روش‌های مرسوم را توضیح می‌دهیم و با مثال حل می‌کنیم.2.3) حل سیستم معادلات خطی (Solving Systems of Linear Equations): همان‌گونه که در بخش قبلی مطرح شد، می‌توانیم دستگاه معادلات خطی را به‌صورت معادلۀ ماتریس بازتعریف کنیم. حال قصد داریم در این قسمت از کتاب به بررسی برخی از روشهای حل دستگاه معادلات خطی بپردازیم.2.3.1) جواب خاص و عمومی (Particular and General Solution): به‌طورکلی به جواب‌های معادلۀAx = b جواب خاص دستگاه گفته می‌شود و جواب عمومی یک معادله ترکیب جواب خاص و جواب‌های Ax = 0 است.برای مثال، قصد داریم برای معادلۀ زیر جواب خاص و عمومی را به دست آوریم.برای قسمت راست معادله، می‌توانیم بردار b را به‌شکل زیر بازنویسی کنیم.دقت کنید که در ضرب ماتریس سمت چپ معادله ستون اول ماتریس ضرایب در x1 ضرب می‌شود و ستون دوم در x2 ضرب می‌شود و چون برای x3 و x4 سمت راست معادله مقداری نداریم، می‌توان جواب خاص را به‌شکل[42, 8, 0, 0] نوشت. برای به دست آوردن جواب معادلۀAx = 0 باید ستون سوم ماتریس سمت چپ را در بردار مجهول‌ها ضرب کنیم و برای صفر کردن جواب معادله باید عنصر سوم را منهای یک عدد که معادل جمع باشد و ضریب x4 را نیز برابر صفر بگذاریم تا در این معادله حذف گردد.دقت کنید که در رابطۀ بالا هر ضریبی از 1 می‌تواند یک بردار صفر ایجاد کند. باید همین روال را برای x4 حال تکرار کنیم.همان‌طور که قبلاً گفتیم جواب عمومی برابر است با ترکیب جواب خاص و جواب‌های معادلۀAx = 0 که برای مثال بالا به‌شکل زیر خواهد بود.2.3.2) تغییرات ابتدایی (Elementary Transformations): از روش‌های حس سیستم‌های معادلات خطی است که با انجام چند نوع عملیات سعی در ساده کردن مسئله و حذف برخی متغیرها در معادلات است. در این روش ما مجاز هستیم از سه عمل زیر استفاده کنیم:جابه‌جایی دو معادله؛ضرب یک معادله در یک اسکالر؛جمع دو معادله با یکدیگر.مثال: برایa ∈ R تمامی جواب‌های دستگاه معادلات زیر را به دست آورید.در ابتدا یک ماتریس به‌شکل زیر تشکیل می‌دهیم که در سمت راست خط مقادیر b که سمت راست معادلات بالا هستند قرار می‌گیرد.سپس، سطر اول را با سطر سوم جابه‌جا می‌کنیم و به‌شکل زیر معادلات را در عددی ضرب و با هم جمع می‌کنیم.سپس نتایج به‌دست‌آمده را هماهنگ شکل زیر تغییرات را اعمال می‌کنیم.هنگامی که ماتریس به یک ماتریسی تبدیل شد که تمامی عناصر پایین‌تر از قطر اصلی صفر شد، عملیات ساده کردن را متوقف می‌کنیم.در دستگاه معادلات خطی بالاa = -1 می‌شود و سپس از سه معادلۀ بالا، جواب خاص دستگاه به‌شکل زیر نتیجه می‌شود.که جواب عمومی آن نیز به‌شکل زیر خواهد شد.2.3.3) روش منهای یک (The Minus-1 Trick): این روش به‌دلیل شباهت به روش قبلی بحث‌شده در این مقاله قرار نمی‌گیرد و علاقه‌مندان می‌توانند از روی کتاب این بخش را دنبال کنند.2.3.4) الگوریتم‌هایی برای حل یک سیستم معادلات خطی: در این قسمت به برخی مقالات در این حوزه اشاره شده است.the Richardson method, the Jacobi method, the Gauß-Seidel method, and the successive over-relaxation method, or Krylov subspace methods, such as conjugate gradients, generalized minimal residual, or biconjugate gradients.We refer to the books by Stoer and Burlirsch (2002), Strang (2003), and Liesen and Mehrmann (2015) for further details.همچنین در این بخش از کتاب دربارۀ روش شبه‌وارون (Moore-Penrose pseudo-inverse) نیز صحبت شده است. این روش به‌شکل زیر است:باید دقت شود اگر ماتریس A ماتریس مربعی نباشد، نمی‌توان وارون آن را محاسبه کرد، زیرا ماتریس وارون تنها برای ماتریس‌های مربعی تعریف می‌شود، به همین دلیل دو طرف معادله را در ترانهادۀ A ضرب می‌کنیم. آنگاه حاصل‌ضرب ترانهادۀ A در A یک ماتریس مربعی می‌شود که می‌توان وارون آن را محاسبه کرد (باید دقت کرد اگر دترمینان ضرب ماتریس در ترانهاده‌اش برابر صفر باشد، برخی روش‌های بازگشتی برای حل مسئله موجود است که در قالب این کتاب نمی‌گنجد، شاید در مقاله‌ای جدا برخی از روش‌های بازگشتی برای رفع این مشکل را بنویسم). روش شبه‌وارون در بسیاری از الگوریتم‌های یادگیری ماشین کاربرد دارد، زیرا معمولاً ما با ماتریس‌هایی از جنس نمونه‌ها و ویژگی‌ها طرف هستیم و این ماتریس‌ها غالباً مربعی نیستند و این روشی جاافتاده در بسیاری از الگوریتم‌های یادگیری ماشین همچون رگرسیون است.در این مقاله تا این قسمت از جبرخطی پرداخته شد و در مقاله بعدی قسمت های بعدی کتاب (فضاهای برداری، پایه و رتبه، مجموعه مولد، نگاشت خطی، ماتریس انتقال، تغییر پایه و ...) خواهیم پرداخت.

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

امید میراب زاده اردکانی — Mon, 02 Aug 2021 14:20:55 +0430

مقدمهمطابق گزارش‌های معتبر در خصوص فناوری‌های در حال ظهور و آینده‌دار (Trending Techs)، دستیارهای مبتنی بر هوش مصنوعی و چت‌بات‌ها از فناوری‌های کلیدی در حال ظهور هستند که بازار آن‌ها در سال‌های گذشته رشد چشمگیری را تجربه کرده است.مطابق «آمار چت‌بات‌ها: ۲۰۲۰ و فراتر»، که Andy Peart در لینکدین منتشر کرده است، گردش مالی هوش مصنوعی مکالمه‌ای رشد شایان توجهی را از سر می‌گذراند.مطلب منتشرشدۀ Andy Peart اشاره می‌کند که مطابق گزارش Markets and Markets، انتظار می‌رود که اندازۀ بازار جهانی هوش مصنوعی مکالمه‌ای از ۴.۲ میلیارد دلار آمریکا در سال ۲۰۱۹ میلادی تا ۱۵.۷ میلیارد دلار آمریکا در سال ۲۰۲۴ میلادی رشد کند، همچنین نرخ رشد مرکب سالیانۀ مورد انتظار برای آن ۳۰.۲ درصد است.دستیارهای مجازی هوشمند و چت‌بات‌ها دو دستۀ اصلی موجود در گزارش بازار هوش مصنوعی مکالمه‌ای هستند.نکتۀ درخور توجه این است که دستۀ چت‌بات‌ها بازار بزرگ‌تری را در طول بازۀ پیش‌بینی به خود اختصاص می‌دهد. آمارهای Research and States نشان می‌دهد که بازار چت‌بات‌ها در سال ۲۰۱۸ میلادی ۱.۲ میلیارد دلار ارزش داشته است، درحالی‌که انتظار می‌رود ارزش این بازار در سال ۲۰۲۴ میلادی به ۷.۵ میلیارد دلار برسد و در طول این مدت، رشد مرکب سالیانۀ ۳۴.۷۵ درصد را ثبت کند.عوامل عمده‌ای که موجب رشد بازار چت‌بات‌ها شده است شامل تقاضای فزاینده برای خدمات پشتیبانی مشتریان مبتنی بر هوش مصنوعی، استقرار اُمنی‌ـ‌چنل و هزینه‌های کاهش‌یافتۀ توسعۀ چت‌بات‌ها می‌شود.گزارش‌های متعدد از منابع مختلف نشان می‌دهد که استفاده از چت‌بات‌ها در صنایع مختلفی نظیر بانکداری، بیمه، خرده‌فروشی و حتی در کارهای اداری کارمندان یقه‌سفید رو به رشد بوده و موجب صرفه‌جویی‌های درخور توجهی شده است. در مجموع، داده‌های متعدد از منابع مختلف نشان می‌دهد که استفاده از چت‌بات‌ها و تعامل با آن‌ها رو به رشد است؛بااین‌حال، انتخاب پلتفرم توسعۀ مناسب برای ساخت چت‌بات‌ها تصمیمی کلیدی است.مطابق گزارش گارتنر، شانزده شرکت از بین شرکت‌هایی که در زمینۀ توسعۀ دستیارهای هوشمند یا زیرساخت توسعۀ آن‌ها فعالیت می‌کنند شاخص‌تر هستند. یکی از این شرکت‌ها Rasa است که مطابق گزارش CBInsights2021 در بین برترین استارتاپ‌های حوزۀ هوش مصنوعی در سال ۲۰۲۱ در زمینۀ پردازش زبان طبیعی و هوش مصنوعی مکالمه‌ای قرار دارد.در این مجموعه مطالب، به معرفی پلتفرم رسا و بررسی مفاهیم اساسی توسعۀ دستیار هوش مصنوعی مکالمه‌ای/ دستیارهای زمینه‌ای با استفاده از این پلتفرم می‌پردازیم. در واقع این مجموعه مطالب برداشتی از ویدئوهای آموزشی رساست که هدف آن معرفی این پلتفرم، برخی مفاهیم استفاده‌شده در رسا و همچنین اشاره به برخی جنبه‌های عملی توسعه با پلتفرم رساست. درعین‌حال، اگر به توسعۀ دستیار شخصی هوشمند بر بستر پلتفرم رسا مایل باشید، خواندن این مطالب شما را از مراجعه به مطالب آموزشی رسا بی‌نیاز نمی‌کند و توصیه می‌شود که برای توسعۀ چت‌بات به ویدئوهای آموزشی رسا در یوتیوب یا به کتابچۀ راهنمای جامع این شرکت مراجعه کنید.همان‌طور که در شکل ۱ مشاهده می‌شود، عالی‌ترین سطح توسعۀ دستیارهای هوش مصنوعی مکالمه‌ای در حال حاضر دستیارهای زمینه‌ای است.شکل ۱: سیر تحول هوش مصنوعی مکالمه‌ای در گذر زمان.مطابق آنچه در آموزش‌های رسا آمده، در حال حاضر هنوز هم، استاندارد غالب صنعت برای توسعۀ چت‌بات‌ها استفاده از FAQهاست (سطح ۲) که برای توسعۀ این چت‌بات‌ها از مجموعه‌ای از قوانین یا از ماشین وضعیت استفاده می‌شود. نکتۀ مثبت این رویکردها ساده کردن ساخت دستیارهاست، اما ازطرفی هم استفاده از این رویکردها برای ساخت چت‌بات‌ها بسیار مستعد خطاست.دستیارهای زمینه‌ای سعی می‌کنند عملکرد دستیار را به مکالمۀ طبیعی انسان‌ها شبیه‌تر کنند، یعنی همان‌طور که در مکالمه‌های انسان‌ها، زمینه بسیار حائز اهمیت است، این دستیارها هم، با توجه کردن به زمینه، مکالمه را پیش می‌برند، اگر به‌صورت غیرمنتظره، مسیر مکالمه تغییر کند، آن را درک می‌کنند و به‌طور متناسب به آن پاسخ می‌دهند.منظور از زمینه این است که توجه کنیم کاربر قبلاً چه چیزی گفته، چه زمانی آن را گفته، کجا و چطور گفته و... و از این اطلاعات برای مدیریت و پیشبرد مکالمه استفاده کنیم.اجزای پلتفرم رسا برای توسعۀ دستیارهای زمینه‌ایرسا مجموعه‌ای از ابزارهای یادگیری ماشین منبع‌باز است که به توسعه‌دهندگان امکان می‌دهد تا دستیارهای هوش مصنوعی زمینه‌ای را (متنی یا صوتی) توسعه دهند. پلتفرم رسا، برای ممکن کردن توسعۀ دستیارهای زمینه‌ای، رویکرد مبتنی بر یادگیری ماشین را جایگزین رویکردهای مبتنی بر قوانین یا ماشین‌های حالت کرده است.پلتفرم رسا با استفاده از ۳ (۲ + ۱) مؤلفۀ اساسی این قابلیت را در اختیار توسعه‌دهندگان قرار می‌دهد:NLU: نوعی ابزار پردازش زبان طبیعی منبع‌باز برای طبقه‌بندی اینتنت و استخراج انتیتی.این مؤلفه، به تعبیری، گوش سیستم شماست که کمک می‌کند دستیار شما متوجه شود چه چیزی گفته شده است.این مؤلفه ورودی کاربر را در قالب غیرساخت‌یافتۀ زبان انسان دریافت می‌کند و داده‌های ساخت‌یافته را در قالب اینتنت و انتیتی از آن استخراج می‌کند. اینتنت را می‌توان برچسب‌هایی در نظر گرفت که باتوجه‌به هدف کلی کاربر از پیامش، به هر ورودی کاربر نسبت داده می‌شود. انتیتی‌ها مجموعه اطلاعاتی هستند که دستیار ممکن است در هر زمینۀ خاص به آن نیاز داشته باشد.نمونه‌ای از استخراج اینتنت و انتیتی از مکالمۀ کاربر در شکل ۲ نشان داده شده است.شکل ۲: نمونۀ شناسایی اینتنت و استخراج انتیتی از مکالمۀ کاربر.نۀ شناسایی اینتنت و استخراج انتیتی از مکالمۀ کاربر.دستیار باید My name را از ورودی استخراج کند و آن را در طول مکالمه به خاطر بسپارد تا تعامل را طبیعی نگاه دارد. این کار از طریق تعلیم یک مدل NER به‌منظور شناسایی و استخراج انتیتی‌ها از پیام‌های غیرساخت‌یافتۀ کاربران انجام می‌شود.Core یا Dialogue Management: چارچوبی برای تصمیم‌گیری زمینه‌ای بر اساس یادگیری ماشین.وظیفۀ این مؤلفه در رسا مدیریت دیالوگ‌های کاربران است.این مؤلفه، به تعبیری، مغز سیستم شماست و بر اساس وضعیت (state)، به‌خصوص مکالمه و زمینه، پیش‌بینی می‌کند که چه پاسخی باید به کاربر داده شود.نمونۀ پیش‌بینی ماژول مدیریت دیالوگ از پاسخی که دستیار باید ارائه کند در شکل ۳ نشان داده شده است.شکل ۳: نمونۀ پیش‌بینی پاسخ (اقدام بعدی) دستیار بر اساس ورودی کاربر و زمینۀ مکالمه. مؤلفۀ Core این‌ها را از طریق مشاهدۀ الگوهایی از داده‌های مکالمه‌ای نمونه، که بین کاربر و دستیار انجام شده است و به آن‌ها story هم گفته می‌شود، یاد می‌گیرد.سؤالی که ممکن است ذهن شما را درگیر کرده باشد این است که مؤلفۀ Core، زمینۀ (context) را چطور حفظ می‌کند؟به‌طور خلاصه، مدل یادگیری ماشین نگاه می‌کند که مکالمه در حال حاضر دربارۀ چیست و همچنین به عقب نگاه می‌کند تا ببیند که پیش‌تر چه‌چیزی گفته شده است. علاوه بر این، ماژول مدیریت دیالوگ، جزئیات دیگری را نیز در نظر می‌گیرد. برای مثال، اطلاعاتی که مؤلفۀ NLU استخراج کرده است (چراکه برخی انتیتی‌‌ها که بعدتر از آن‌ها به‌عنوان slot استفاده می‌شود ممکن است روی چگونگی پیش‌بینی اقدام بعدی سیستم Dialogue Management به‌طور مستقیم تأثیر داشته باشند).Rasa Xمؤلفۀ Rasa X این قابلیت را ایجاد می‌کند که دستیار از مکالمه‌های جدید یاد بگیرد و در طول زمان عملکرد آن بهبود پیدا کند.عملکردهایی که Rasa X انجام می‌دهد تا دستیار در طول زمان بهبود پیدا کند در شکل ۴ نشان داده شده است.شکل ۴: عملکردهای Rasa X که بهبود دستیار در طول زمان را ممکن می‌کند. نحوۀ عملکرد انتها تا انتهای رسا در تعامل با کاربر و با استفاده از مؤلفه‌های سه‌گانه در شکل ۵ نشان داده شده است.شکل ۵: نحوۀ عملکرد انتها تا انتهای رسا در تعامل با کاربر و با استفاده از مؤلفه‌های سه‌گانۀ رسا. در مطالب بعدی به معرفی بیشتر اجزای NLU و Core و چگونگی عملکرد آن‌ها می‌پردازیم.منابعPeart, A. (2020, May 19). Chatbot Statistics: 2020 & Beyond. Linkedin. https://www.linkedin.com/pulse/chatbot-statistics-2020-beyond-andy-peart/, Last accessed July 2021.Meese M. (2021, April 8). CB Insights reveals 2021 cohort of 100 most-promising AI companies. TechRepublic. https://www.techrepublic.com/article/cb-insights-reveals-2021-cohort-of-100-most-promising-ai-companies/, Last accessed July 2021.Revang, M., Baker, V., Manusama, B., Mullen, A., and Lee, A. Market Guide for Conversational Platforms. Gartner. https://www.gartner.com/en/documents/3953723/market-guide-for-conversational-platforms, Last accessed July 2021.Rasa. (2019, October). Rasa Masterclass: Developing Contextual AI assistants with Rasa tools. https://www.youtube.com/playlist?app=desktop&amp;list=PL75e0qA87dlHQny7z43NduZHPo6qd-cRc, Last accessed July 2021.The Rasa Masterclass Handbook. 2019. The Rasa Masterclass Handbook; A Companion Guide to the Rasa Masterclass Video Series. Rasa Publication, 2019, https://cdn2.hubspot.net/hubfs/6711345/ebook-v3.pdf?__hstc=&amp;__hssc=&amp;hsCtaTracking=2cf912f3-4137-4338-829e-08bb4713f0f6%7Cda22eae5-512d-48fe-b46a-c74517f3d870.

کجا دانند حال ما (کاربران) سبکباران ساحل‌ها (طراحان خدمت)؟!

مصطفی رادمرد — Mon, 26 Jul 2021 09:20:13 +0430

به نام خدامی‌خواهم دقایقی از وقت ارزشمند شما را بگیرم و حرفی کلیشه‌ای بزنم. خلاصه‌اش این است: احساسات و دغدغه‌های کاربران را در طراحی خدمت و محصول‌تان در نظر بگیرید.درست است که حتماً تاکنون این نکته را شنیده‌اید، ولی شاید شنیدن داستانی واقعی از آن به کاربست بیشترش کمک کند. حالا داستان چیست؟چند شب پیش به مطب متخصص مغز و اعصاب مراجعه کردم. شرح خدمت خیلی ساده بود: ویزیت مراجع توسط متخصص. اما چند حاشیۀ داستان:ساعت هفت بعدازظهر در هوای گرم این روزها، خسته و فکری پس از یک روز کاری سخت به مطب رسیدم. متخصص مذکور فقط پول نقد قبول می‌کرد و حتی امکان کارت‌به‌کارت هم نبود. رفتم بیرون و از نزدیک‌ترین عابربانک مبلغ لازم را برداشتم و به مطب برگشتم.ارائۀ خدمات در مطب تقریباً شبیه نانوایی بود. فردی به نام رضا، که آنجا همه‌کار می‌کرد، نوبت‌دهی را هم اداره می‌کرد. به هیچ‌کس هم «نه» نمی‌گفت. سعی می‌کرد همه‌چیز را با هم پیش ببرد و البته همۀ مراجعان با هر شأن و منزلت و جنسیتی سعی می‌کردند از طریق رفاقت با رضا کارشان را سریع‌تر راه بیندازند. این داستان نه‌تنها شامل مراجعان داخل مطب که شامل مریض‌های گذشته نیز می‌شد. این بود که رضا یکسره مشغول تلفن همراهش بود تا تماس بیماران قبلی را نیز پاسخ‌گو باشد.نام هر مراجعی که می‌آمد به آخر فهرست اضافه می‌شد و منتظر می‌ماند تا نوبتش شود. ندیدم رضا به کسی بگوید امروز وقت‌ها تمام شده است و دیگر وقت ندهد.وسط معاینه‌ها، برخی مراجعان قبلی تلفنی مستقیم به اتاق دکتر زنگ می‌زدند و با او صحبت می‌کردند. برخی هم که قبلاً معاینه شده بودند و می‌خواستند نوار مغز یا MRI یا داروهای خریداری شده را به دکتر نشان دهند باز بدون نوبت با هماهنگی رضا وسط مریض‌ها وارد اتاق دکتر می‌شدند و کارشان را انجام می‌دادند.اگر محل انتظار شلوغ و پرمراجع می‌شد، رضا به چند نفر که آخر صف بودند می‌گفت: «دکتر از شلوغ بودن اینجا شاکی شده است.» آن‌ها را به پایین ساختمان می‌فرستاد و می‌گفت: «بروید بیرون منتظر باشید. هروقت نوبتتان شد، خودم می‌آیم و صدایتان می‌زنم.» من هم جزو کسانی بودم که با هدایت رضا به پارکینگ ساختمان رفتم و مدتی قدم زدم.ساعت نُه شده بود و هنوز به اینکه به‌زودی کارم تمام شود امیدی نداشتم. نگران محدودیت تردد بعد از ساعت ده شب بودم و در فکر بودم که آیا نوبت معاینۀ من زودتر فرا می‌رسد که بتوانم قبل از ده شب به خانه برسم؟ تا اینکه ساعت نُه‌ونیم شد و امیدم را به بازگشت قبل از ده شب کاملاً از دست دادم.خلاصه اینکه تقریباً از ساعت هفت تا ده شب گرسنه و تشنه و خسته برای پنج دقیقه ویزیت در چنین محیطی معطل بودم. فشار عصبی زیادی را تحمل کردم و تمام تلاشم را کردم تا آرامش خودم را حفظ کنم. ازجمله اینکه هرازگاهی نفس عمیق می‌کشیدم. :)آن شب دیدم که از کودک هفت‌ساله تا پیرزن هفتادساله، از کسی که با سر از اسب افتاده تا کسی که از اصل افتاده بود، همگی به همین وضع چند ساعتی در مطب معطل شدند.فردای آن روز، به این فکر می‌کردم که احساسات خدمت‌گیرندگان در فرایند ارائۀ خدمت چقدر مهم است و چقدر خوب است که خدمت‌دهنده خودش هرازگاهی در جایگاه خدمت‌گیرنده قرار گیرد و فرایند خدمت‌دهی را طی کند.یاد برخی تجربه‌ها و شنیده‌های قبلی افتادم. فکر کردم:تا پای گمرک مرزی چادر نزنی و خودت فرایندهای فَشَل و مفسده‌انگیز ترخیص کالا را طی نکنی،تا در راهروهای بیمه و مالیات پِی تعیین مبلغ و پیگیری شکایت نروی و در دوراهی‌های اخلاقی گیر نکنی،تا نیمه‌شب در اورژانس مستأصل دنبال طی کردن مراحل خرید و تأمین ملزومات درمانی نباشی که در نهایت کارآموز شیفت با بی‌حوصلگی به تو رسیدگی کند،تا به‌عنوان کارمند بانک پشت سامانۀ چک و امثالهم ننشینی و مشقت کار با آن و چند سیستم جورواجور دیگر را نچشی و زیر بار درخواست‌های مشتریان سرگیجه نگیری،تا برای گرفتن چند میلیون تومان تسهیلات در شعب بانک‌ها نگردی،حس کسی را که برایش خدمتی می‌سازی درک نمی‌کنی و نمی‌توانی ادعا کنی مشتری‌مدار شده‌ای.از زمانی به بعد، در طراحی خدمت و محصول و در ابزارهایی مانند بلوپرینت خدمت و سفر مشتری، دغدغه‌ها و احساس مشتری را هم دخیل کردند.یعنی خوب است که در هنگام طراحی بسنجیم که کاربر در هر مرحله چه احساسی دارد و چگونه می‌توانیم این احساس را بهتر کنیم. برای این منظور، حتی ابزارهای متمرکزی مانند «نقشۀ سفر احساسی» یا «نقشۀ همدلی» هم ارائه شده است.گفته می‌شود بیش از پنجاه درصد تجربۀ هر مشتری از عوامل احساسی ساخته می‌شود و کاربران غالباً ابتدا با احساس خود تصمیم می‌گیرند و سپس با منطق خود آن را توجیه می‌کنند.نکتۀ مهم در بررسی رفتار مشتریان این است که داده‌های خام معمولاً نشانی از احساسات مشتریان ندارند و اگر فقط از ابزارهای تحلیل داده‌های انبوهِ رفتار مشتریان استفاده کنیم، ممکن است برخی بینش‌های مهم راجع به احساسات مشتریان را طی فرایند استفاده از محصول یا خدمت از دست بدهیم. برای مثال، نارضایتی‌های احتمالی هنگام انجام تراکنش‌های موفق را متوجه نشویم.منشأ دغدغه‌ها و احساسات مشتری هم خیلی مواقع ممکن است متأثر از مسائلی خارج از خدمت یا محصول ما باشد. مثلاً فرض کنید خدمتی بابت سرمایه‌گذاری‌های کوچک طراحی می‌کنیم. کاربری داریم که:می‌خواهد چند میلیون پس‌انداز سه‌ماهه‌اش را جایی بگذارد و پولش را کم‌کم جمع کند تا یخچال فرسودۀ خانه را تعویض کند .قبلاً یک بار پولش را در مؤسسه‌ای مالی‌اعتباری گذاشته و از او کلاه‌برداری شده است.نگران وضعیت نرخ دلار است و نمی‌داند در ماه‌های آینده لوازم‌خانگی ارزان می‌شود یا قیمتش جهش پیدا می‌کند.برای اینکه یخچال مناسبی در خانه ندارد شرمسار خانواده است و از تصور اینکه یخچال جدیدی به خانه بیاورد دلش روشن می‌شود.و بسیاری دغدغه‌های دیگر که چنین فردی می‌تواند داشته باشد.فکر می‌کنید بدون در نظر گرفتن این دغدغه‌ها و احساسات می‌توان خدمتی متمایز و مشتری‌محور ارائه داد؟ بی‌شک در نظر گرفتن این نکته‌ها را می‌توان فرصتی ناب برای وفادارسازی مشتریان دانست و به ایده‌های جذابی برای بهبود حال مشتری رسید.در ارائۀ هر محصول و خدمت، «حس خوب» یا «بهتر کردن حال» از بهترین پیشنهادهای ارزشی‌ای است که می‌توان به مشتری‌ها ارائه کرد. پس چرا به آن توجه نکنیم؟

برت - BERT

Hesam Korki — Wed, 16 Jun 2021 13:20:31 +0430

برت چیست؟برت نوعی مدل زبانی (language model) برای حل چالش‌های به‌روز در زمینۀ پردازش زبان‌های طبیعی (NLP) است. این مدل حاصل مقاله‌ای از محققان گوگل است که اولین بار در سال ۲۰۱۸ به چاپ رسید و در سال ۲۰۱۹ بازبینی شد. نتایج به‌دست‌آمدۀ برت در معیار‌های پردازش و فهم زبان‌های طبیعی به‌قدری خوب بود که توجه زیادی به خود جلب کرد.نو‌آوری فنی کلیدی برت که آن را متمایز می‌سازد پیاده‌سازی آموزش دوطرفه روی معماری ترنسفورمر‌ها (نوعی معماری یادگیری عمیق با استفاده از مکانیزم توجه) برای مدل‌سازی زبان‌هاست. تلاش‌های قبل از این دنبالۀ متون را یا از چپ به راست یا از راست به چپ بررسی می‌کردند. نتایج مقالۀ برت نشان می‌دهد که رویکرد دوطرفه باعث می‌شود مدل طراحی‌شده ازنظر فهم زمینه (context) و جریان کلمات (flow)، در مقایسه با مدل‌های یک‌طرفه، زبان را عمیق‌تر درک کند. در این مقاله، تکنیکی با عنوان MLM یا Masked Language Model معرفی می‌شود که آموزش دوطرفه را ممکن می‌سازد.پیش‌زمینهچندین سال است که دانشمندان از مفهوم یادگیری انتقالی (Transfer Learning) در حوزۀ بینایی ماشین استفاده می‌کنند. یادگیری انتقالی به این معناست که شبکه‌ای عصبی را روی دادگان بسیار زیادی به‌صورت بدون نظارت برای انجام کار مشخصی آموزش دهید (مثل ImageNet). سپس از این مدل به‌عنوان لایه‌های پایه‌ای برای تنظیم دقیق (fine-tune) روی داده‌های محدود به کار خود استفاده کنید (Dog/Cat Classification).در سال‌های اخیر، محققان نشان داده‌اند که همین تکنیک در بسیاری از تسک‌های پردازش زبان طبیعی مفید واقع می‌شود. ترنسفورمر‌ها (Transformers)، که پیش از این به آن‌ها اشاره شد، در واقع تلاشی برای پیاده‌سازی این مفهوم در زمینۀ پردازش زبان‌های طبیعی هستند که از مکانیزم توجه (Attention Mechanism) بهره می‌برند.عملکرد برتبرت از مکانیزم توجه ترنسفورمر‌ها استفاده می‌کند که رابطۀ‌ بین کلمات را در زمینه‌های مختلف یاد می‌گیرد. در ساده‌ترین شکل خود، ترنسفورمر شامل دو مکانیزم جداست: یک کدگذار (Encoder) که متن ورودی را می‌خواند و یک کدگشا (Decoder) که پیش‌بینی محتمل را برای تسک مشخص‌شده بیان می‌کند. مثال استفاده از ترنسفورمر در تسک ترجمه‌ی ماشینی از آنجا که هدف برت ساختن نوعی مدل زبانی است که متون را می‌فهمد، تنها استفاده از لایه‌های کدگذار (Encoder) ضروری است.برعکس مدل‌های قبلی (RNNs و LSTM) که متن ورودی را به‌ترتیب از چپ به راست یا از راست به چپ می‌خواند، لایۀ کدگذار ترنسفورمر‌ها دنباله‌ای از کلمات ورودی را به‌صورت یکجا می‌خواند. این خصوصیت باعث می‌شود که مدل مدنظر زمینۀ (context)‌ یک کلمه را بر اساس کلمه‌های نزدیکش (چپ یا راست) یاد بگیرد.معماری برتدو اندازه برای مدل برت معرفی شده است:برت پایه (BERTBASE): متشکل از ۱۲ لایۀ کدگذار است. تعداد کل پارامتر‌های شبکه ۱۱۰ میلیون است.برت بزرگ (BERTLARGE): متشکل از ۲۴ لایۀ کدگذار که طبیعتاً تعداد پارامتر‌ها ۳۴۰ میلیون است و حجم بیشتری دارد. همچنین سرعت آموزش آن کمتر است، ولی نسبت به مدل پایه دقت بیشتر و عملکرد بهتری دارد.اندازه‌های مختلف مدل برتاین دو از دیگر جنبه‌ها نیز متفاوت هستند: برت پایه ۷۶۸ لایۀ پنهان (hidden layer) در شبکۀ خود دارد؛ این در حالی است که برت بزرگ ۱۰۲۴ لایۀ پنهان دارد.ورودی/خروجی برتبرای اینکه بتوان از برت در تسک‌های نهایی مختلف‌ (دسته‌بندی، پاسخ به پرسش، آنالیز احساسات و...) استفاده کرد، می‌توان ورودی را در شکل‌های مختلفی به مدل داد.نحوه دریافت ورودی توسط برتورودی مدل ممکن است یک دنباله شامل حداکثر ۵۱۲ توکن باشد‌ (این عدد را می‌شود تنظیم کرد) که با توکن [CLS] شروع می‌شود و دنباله‌ها با توکن [SEP] از هم جدا می‌شوند. هر المان خروجی یک بردار با اندازۀ لایه‌های پنهانی است که برای مدل پایه، بردار‌هایی به طول ۷۶۸ است. برای مثال، از این بردار می‌توان در ورودی یک شبکۀ یک‌لایه برای دسته‌بندی استفاده کرد.مثالی از خروجی برت برای تسک دسته‌بندیاگر دسته‌بندی شما بیشتر از دو حالت باشد (multi class classification)، تنها کافی است لایۀ softmax را طوری تغییر دهید که تعداد خروجی به‌ اندازۀ کلاس‌های مدنظر شما شود.

فریم‌ورک‌هارت گوگل(Google Heart Framework)

رویا خیرالهی — Fri, 14 May 2021 18:34:59 +0430

همه می‌دانند که طراحی تجربه‌کاربری داده‌محور بهتر از طراحی و توسعه تجربه‌کاربری احساسی است.درحال حاضر‌‌،ما بیش از هر زمان دیگری به داده‌ها دسترسی داریم،اما این کار مدیریت داده‌ها را آسان نمی‌کند.فقط شرکت‌های کوچک نیستند که با این مسئله روبه‌رو شده‌اند،حتی تیم‌های تحقیقاتی یوایکس گوگل هم با داده‌های رفتاری در مقیاس گسترده‌ای روبه‌رو شده‌اند.بنابراین،تیم‌های تحقیقاتی یوایکس گوگل،برای سنجش کیفیت تجربه‌کاربر،فریم‌ورک‌هارت گوگل(Google Heart Framework) را ارائه دادند که به اندازه‌گیری پیشرفت برای رسیدن به اهداف اصلی و تصمیم‌های مربوط به محصول کمک می‌کند.فریم‌ورک‌هارت(Heart Framework) روشی خوب برای اندازه‌گیری کیفیت تجربه‌کاربر برای به دست آوردن بینش عملی است.تجربه‌کاربر نه‌تنها باید به‌خوبی طراحی شود،بلکه باید به‌خوبی اندازه‌گیری شود.به‌صورت دقیق‌تر بررسی می‌کنیم که فریم‌ورک‌هارت گوگل(Google Heart Framework) چه‌طور به شما در اندازه‌گیری تجربه‌کاربر کمک خواهد کرد.این فریم‌ورک ایده‌ اصلی تیم تحقیقاتی یوایکس گوگل است که معیارهای مفید محصول را در پنج دسته قرار داده است.با قرار دادن این دسته‌ها کنار هم به مخفف Heart رسیده‌اند که یک نوعی ساختار جامع برای سازمان‌دهی داده‌های مربوط به تجربه‌کاربر است.فریم ورک هارت گوگل(Google Heart Framework) Happiness___H:میزان رضایت کاربر از محصول ونگرش را نشان می‌دهد.شما می‌توانید میزان رضایت را در مقیاس وسیع از طریق نظرسنجی‌های کاربر اندازه‌گیری کنید.نظرسنجی درون‌محصولی سطح رضایت را بیشتر از نظرسنجی از طریق ایمیل نشان می‌دهد.Engagement___E:میزان تعامل کاربر با محصول را در یک بازه زمانی مشخص اندازه‌گیری می‌کند.برخی متغیرهای خاص برای اندازه‌گیری عبارت‌اند از:میزان استفاده وسطح تعامل در طی یک دوره زمانی خاص،برخی نمونه‌ها شامل تعداد بازدیدها به ازای هر کار در مدت زمان خاص و... اما توجه کنید که معیارهای مناسب،بسته به جایگاه شما،متفاوت خواهد بود.Adoption___A: در بازه زمانی مشخص،محصول یا ویژگی به روز شده چه تعداد کاربر جدید می‌یابد.برای مثال وقتی ویژگی جدیدی به محصول اضافه می شود،شروع به سنجش تعداد کاربرانی می‌کنیم که در طی دو هفته از این ویژگی استفاده کرده‌اند. Retention___R:میزان بازگشت کاربران به محصول را اندازه‌گیری می‌کند،برای مثال تعداد کاربران فعال شمادر بازه زمانی مشخصی که در برخی زمان‌های دیگر هم حضور دارند ودر هنگام ارائه نسخه جدید معیار نگهداری بسیار مفید خواهد بود. Task success___T:این متغیر معیاری فنی به نظر می‌رسدزیرا شما زمان انجام کار یا میزان خطا را در آن کار خاص را اندازه‌گیری خواهید کرد.برای مثال زمان بارگذاری هر پست در اینستاگرام اندازه‌گیری می‌شود.معیارهای(Metrics) فریم ورک‌هارت(Heart Framework) برای طراحی کل محصول یا ویژگی‌های خاص اعمال می‌شود واین معیارها به تیم محصول کمک می‌کند تا معیارهای لازم را برای جمع آوری داده بداند.اکنون که همه‌ دسته‌بندی‌ها را در فریم ورک‌هارت گوگل(Google Heart Framework) دانستید، می‌خواهید یکی یا دوتایش را برای محصول خود انتخاب کنید.اما چگونه می‌توانید تصمیم بگیرید که کدام معیارها(Metrics) را اندازه بگیریدو کدام‌یک را حذف کنید؟همه‌چیز با هدف شروع می‌شود این یکی از فرایندهای GSM (اهداف،سیگنال‌ها،معیارها) است که شما باید شناسایی کنید.شناسایی اهداف تجربه‌کاربری هر محصول ممکن است پیچیده باشد،این فریم‌ورک ممکن است تیم را به‌سمت هدف مشترک متحد کند و اهداف پروژه را از اهداف محصول دور کند.برای مثال، همه می‌خواهند تعداد زیادی کاربر در اپلیکیشن داشته باشند،بااین‌حال آن‌ها باید تصمیم بگیرند که کدام معیار را می‌خواهند اندازه بگیرند؟تعامل یا کاربران جدید.مرحله بعد در فرایند GSM سیگنال است.اقداماتی که نشان می‌دهد هدفی برآورده شده است یا احساساتی که با موفقیت وشکست ارتباط دارد باید در اینجا ترسیم شود.مرحله آخر در فرایند GSM معیار(Metrics)است اینجاست که داده‌های بزرگ به آمار تبدیل می‌شود،سپس آن‌ها را با استانداردهای محصول مقایسه می‌کنیم.برای مثال، در یک فروشگاه اینترنتی نسبت تعداد کاربرانی که خرید می‌کنند به تعداد کل کاربرانی که از سایت بازدید کرده‌اند. اگر می‌خواهید طراحی محصول شما با داده‌های بزرگ پشتیبانی شود فریم‌ورک‌هارت گوگل (Google Heart Framework)پاسخگوی شماست.

نقش پژوهش کاربر در فرایند طراحی تجربه کاربری چیست؟

الهام محمدنژاد — Sun, 02 May 2021 14:38:43 +0430

نقش پژوهش کاربر در فرایند طراحی تجربه کاربری چیست؟اگر محصولی را طراحی کنیم که در آن نیاز کاربران هدف آن محصول در نظر گرفته نشده باشد یقیناً آن محصول با شکست مواجه می‌شود. پژوهش کاربر گام اول فرایند طراحی است زیرا اگر بدون پژوهش دست به طراحی بزنیم محصول ما براساس تجربه‌ها و فرضیه‌های خودمان بوجود آمده است که عینی نیست. فرایند تفکر طراحی ( شکل 1) که این روزها خیلی درباره‌اش می‌شنویم، یعنی اینکه محصولی که قرار است طراحی شود، از ابتدای فرایند دیزاین با کشف مسئله شروع شود، این " کشف مسئله " خروجی مهم فرایند پژوهش‌کاربر است. تولید محصول در فرایند دیزاین به تکامل می‌رسد، زیرا این چرخه تکرارپذیر است (به همین دلیل به آن فرایند گفته می‌شود) و ممکن است در هر مرحلۀ تولید محصول به تعریف مسئلۀ جدید برای بهبود محصول نیاز داشته باشیم. در ادامه ایده‌پردازی و پروتوتایپ و ارزیابی نتیجه را داریم و گاهی ممکن است بارها و بارها ایده‌های مختلف را با روش‌های ارزیابی محصولی آزمایش کنیم و به راه‌حل قابل قبولی برسیم که مسئلۀ کاربران را حل کند.شکل 1 -فرایند تفکر طراحیتحقیقات پژوهش کاربر یعنی روند درک و رفتار، نیازها و نگرش‌های کاربران با استفاده از روشهای مختلف مشاهده و جمع‌آوری بازخورد. پژوهش به ما نشان می‌دهد که در حال حاضر کاربران، چگونه در محصول رفتار می‌کنند و کجا با مشکل روبرو هستند و از همه مهمتر احساس آنها هنگام تعامل با محصول ما چیست. پژوهش کاربر درست یعنی استفاده از روش مناسب، در زمان مناسب در هنگام تولید یا بهبود محصول. بسته به نوع و روند تولید محصول نوع پژوهش هم فرق می‌کند ممکن است پژوهش ما از نوع کشف یا ارزیابی باشد که قطعا روش‌های متفاوتی دارند.سه قدم اصلی پژوهش کاربر این سه مورد است: مشاهده، درک و تجزیه و تحلیلمشاهده: کاربران خود را مشاهده کنید و مراقب سرنخ‌های کلامی و غیرکلامی درباره احساس آن‌ها باشید.درک: درک درستی از مدل ذهنی کاربر ایجاد کنید، کاربر حین استفاده از یک محصول خاص چه چیزی را پیش‌بینی می‌کند؟ با توجه به تجربه قبلی‌شان، آنها انتظار دارند که این محصول چگونه کار کند؟تجزیه و تحلیل: بینش‌هایی را که جمع‌آوری کردید، تجزیه و تحلیل کنید و سعی کنید الگوها را دسته‌بندی کنید و در نهایت این الگو‌ها، ایده‌های خوبی برای محصول و نحوۀ طراحی آن مطابق با مدل ذهنی کاربران به شما می‌دهند. یکی از روشهای تجزیه و تحلیل این داده‌ها، استفاده از نمودار همبستگی است.برخی از با ارزش‌ترین روش‌های پرکاربرد در تحقیق را بررسی می‌کنیم:1- گروه‌های کاربران یا گروه‌های متمرکز:مصاحبه‌های ساختاریافته‌ای هستند که به سرعت و با کمترین هزینه، تجربه‌ها، خواسته‌ها و نگرش‌های کاربران را نشان می‌دهند. همچنین می‌توان از این گروه‌های کاربری برای ایجاد ایده‌ها و انتظارات کاربران از محصول استفاده کرد."انجام تحقیقات مربوط به کاربر، به شما این امکان را می دهد در آنچه کاربران می گویند و می‌خواهند ، غوطه‌ور شوید و در عوض آنچه را که واقعاً نیاز دارند، کشف کنید. این کلیدی است برای اطمینان از اینکه محصولات و ویژگی‌های محصول شما واقعا مشکلات روزمرۀ مشتریان شما را حل کنند. اگر می‌خواهید یک محصول موفق و عادت‌آفرین ایجاد کنید ، تحقیقات کاربر ضروری است. "2- تست کاربردپذیری:تست کاربردپذیری به "ارزیابی محصول توسط آزمایش آن محصول با کاربران نماینده گفته می‌شود." در طی یک آزمون کاربردپذیری، از شرکت‌کنندگان خواسته می‌شود کارهای مشخصی را انجام دهند در حالی که یک یا چند ناظر تمام رفتار، احساسات و اعمال این کاربران مورد تست را حین استفاده از محصول تماشا یا ضبط کرده و سپس تحلیل می‌کنند. هدف اصلی این روش آزمایش تجربۀ کاربر، شناسایی مشکلات قابلیت استفاده، جمع‌آوری داده‌های کیفی و تعیین رضایت کلی شرکت‌کنندگان از محصول است. تست کاربردپذیری به شما کمک می‌کند مشکلات را قبل از توسعه شناسایی کنید زیرا هنگامی که مسائل قبل از توسعه شناسایی شوند، حل آنها معمولاً هزینۀ کمتری دارد. همچنین این تست تغییراتی را که برای بهبود رضایت و عملکرد کاربران ضروری است، نشان می‌دهد.3- مصاحبه با کاربران:روش شناخته شده تجربۀ کاربر، مصاحبه با کاربران است. مصاحبه یک روش تحقیق دربارۀ تجربه کاربر است که برای کشف نگرش‌ها، باورها و تجربیات کاربران (کاربران بالقوه) هر محصول استفاده می‌شود. مصاحبه‌ها معمولاً توسط یک مصاحبه‌کننده انجام می‌شود که ممکن است سی دقیقه تا یک ساعت با هر کاربر صحبت ‌کند. مصاحبه‌ را می‌توان حضوری، تلفنی یا از طریق پخش ویدئو انجام داد. در مصاحبه پرسیدن سوالات درست (هدایت کننده کاربر در جهت هدف مصاحبه) و مهارت مصاحبه کننده اهمیت زیادی دارد.4- نظرسنجی‌ یا پرسشنامه‌های آنلاین:نظرسنجی نوعی ابزار تحقیقاتی است که به طور معمول شامل مجموعه‌ای از سوالاتی است که برای کشف نگرش‌ها و نظرات کاربران دربارۀ یک موضوع مشخص استفاده می‌شود. نظرسنجی‌ها به طور آنلاین و در قالب‌های مختلف انجام می‌شود. داده‌های جمع‌آوری شده از نظرسنجی‌ها به طور خودکار دریافت می‌شود و ابزارهای نظرسنجی انتخاب شده معمولا تجزیه و تحلیل کلی هم ارائه می‌دهند. سپس داده‌های حاصل از آن برای مطالعۀ تجربه کاربر با هدف بهبود محصول استفاده ‌می‌شود. سایت‌هایی مثل پرس‌لاین، گوگل فرم و تایپ‌فرم برای نظرسنجی استفاده می‌شوند.5- پرسونای کاربران:پرسونا نمایندۀ گروهی از مخاطبین است که ما بعنوان کسب و کار می‌خواهیم از طریق سرویس و یا محصول، نیازها و خواسته‌های آنها را برآورده کنیم و یکی از خروجی های اصلی و مهم فرآیند پژوهش است. پرسونا ابزاری برای کمک به تصمیم‌گیری است. تصمیم پرسونا برای کسب و کار دارای اهمیت زیادی است و کمک می‌ کند تا تصمیمات اتخاذ شده در راستای اهداف کسب و کار و نیازهای کاربران باشد.حال که با روش‌های تحقیق کاربر آشنا شدیم، باید بدانیم که کدام روش برای پژوهش مورد نظر ما مناسب‌تر است؟ همه چیز به اهداف تحقیقاتی ما بستگی دارد.روش تحقیق به دو دسته تقسیم می‌شود:1- تحقیق رفتاری / نگرشی:تفاوت زیادی بین " آنچه مردم انجام می دهند" در مقابل " آنچه مردم می گویند" وجود دارد. از تحقیقات نگرشی برای درک یا اندازه‌گیری نگرش‌ها و باورها استفاده می‌شود، در حالی که از تحقیقات رفتاری برای سنجش رفتارها استفاده می‌شود. برای مثال، تست کاربردپذیری یک روش تحقیق رفتاری کاربر است که بر عملکرد کاربران متمرکز است. در مقابل، روش‌های تحقیق نگرشی مانند گروه‌های کاربر‌، مصاحبه‌ها و ایجاد پرسونا بر چگونگی تفکر مردم دربارۀ محصول متمرکز است.2- تحقیق کیفی/ کمی:هنگام انجام تحقیقات تجربه کاربری و انتخاب روش مناسب، درک تفاوت بین تحقیقات کمی و کیفی مهم است.تحقیقات کیفی دلایل یا انگیزه‌های این اقدامات را بررسی می‌کند. چرا کاربر به وب سایت شما وارد شده ولی عمل خاصی انجام نداده و رفته است؟ چه عاملی باعث شده است که مثلا "کاربر گزینه افزودن کالا در سبد خرید را زده و تا کنون ثبت سفارش نکرده؟" در حالی که داده های کمی ثابت هستند، داده‌های کیفی بیشتر توصیفی و باز هستند.تحقیقات کمی داده‌هایی قابل اندازه‌گیری را جمع‌آوری می‌‌کند که می‌توان آن‌ها را اندازه‌گیری کرد. این به شما ارقام مشخصی برای کار می‌دهد، مانند اینکه چند کاربر از طریق برنامه تجارت الکترونیکی شما محصولی را خریداری کرده‌اند یا چند درصد بازدیدکنندگان یک مورد را به لیست علاقه‌مندی خود اضافه کرده‌اند. "روش‌های کمی" به شما کمک می‌ کند تا تعداد مشخصی از کاربرانی را که از ویژگی‌های موجود در محصول استفاده می‌کنند، بدانید.تمایز بیشتر بین نحوۀ انجام مطالعات کیفی و کمی در زمینۀ جمع آوری داده‌ها است. مطالعاتی که ماهیت کیفی دارند، بر اساس مشاهدۀ مستقیم هستند. به عنوان مثال ، شما با مشاهدۀ مستقیم در عمل، داده‌هایی دربارۀ رفتار کاربران جمع خواهید کرد. مطالعات کمی این داده‌ها را به طور غیرمستقیم جمع می‌کند، به عنوان مثال از طریق یک نظرسنجی آنلاین. روش‌های تحقیقی کیفی(مثل گروههای متمرکز و یا مصاحبه‌ها)، به سوالاتی دربارۀ چرایی و چگونگی رفع مشکل و بهبود عمکرد محصول پاسخ می‌دهند در حالیکه روش‌های تحقیق کمی(مثل نظرسنجی‌های آنلاین) سوالات چند و چقدر را دربارۀ ویژگی‌های محصول و یا کاربران پاسخ می‌دهند.پس از انجام تحقیقات دربارۀ کاربر ، به مرحلۀ تجزیه‌ و تحلیل می‌ روید. اینجاست که می‌ توانید داده‌های خام جمع‌آوری‌ شده را به بینش ارزشمندی تبدیل کنید. هدف از تجزیه‌ و تحلیل تحقیق کاربر، تفسیر معنای داده‌‌ها است. سوالاتی مثل "چرا کاربر از محصول ما استفاده می‌کند؟" و یا "محصول ما کدام نیازهای کاربر را پاسخ می‌دهد؟" و "چگونه می‌توانید از داده‌های جمع‌آوری‌ شده برای آگاهی از روند طراحی استفاده کنید؟" در نهایت، می‌توان پاسخ این سؤال‌ها را به دست آورد.خروجی‌های پژوهش کاربر درباره شناخت کاربر و ارائه به تیم برای ادامه مسیر طراحی، سه مورد زیر است:1- پروفایل پرسوناهای اصلی کاربران هدف محصول.2- مسیر کاربری مخاطب(user journey map):مسیر کاربری مخاطب آن چیزی است که به ما کمک می‌کند گام به گام رفتار مخاطب را ببینیم و بدانیم در هر یک از گام‌ها چه احساسی دارد، به چه فکر می‌کند و چه تصمیمی می‌گیرد.3- صورت‌بندی مسئله (point of view):صورت بندی مسئه یعنی بتوانیم مسئله‌ای را که در ابتدا برای ما تعریف شده با تحقیقات و تحلیل‌ها، درست صورت‌بندی کنیم و مسئله ای درست را از درون آن کشف کنیم.

تردینگ در اندروید1

محمد مهدی طریقت — Tue, 19 Jan 2021 12:33:25 +0330

به نام خداتردینگ در اندرویدبرای بحث تردینگ ابتدا در این مقاله سعی می‌کنیم مباحث اصلی تردینگ و main thread را توضیح دهیم و بعد در مقاله‌های بعدی، سراغ بست پرکتیس‌ها می‌رویم.mainThreadوقتی که اپلیکیشنی ران می‌شود، یک linux Process ایجاد می‌شود که به آن ترد اصلی نرم‌افزار یاmain thread می‌گوییم.تنها کار آن اجرای بلاک‌های مختلف استکه باید دقت کنیم فقط کارهای مربوط به ui را روی آن ترد انجام بدهیم.مِیْن ترد دوست دارد تسک‌هایش را در کمتر از شانزده میلی‌ثانیه انجام بدهد (شصت فریم بر ثانیه) تا کاربر احساس نکند لگ وجود دارد.دقیقاً زمانی که احساس می‌کنیم برنامه‌ای کند عمل می‌کند، به این دلیل است که صف این ترد این‌قدر شلوغ است و این‌قدر کارهای سنگین انجام می‌دهد که کارش بیشتر از این زمان (شانزده میلی‌ثانیه) طول می‌کشد.اگر این کندی به حدی زیاد بشود که تا بیش از پنج ثانیه طول بکشد، دیالوگی را نشان می‌دهد.Application Not Respondingو در اصطلاح می‌گوییم ANR رخ داده است.چه کارهایی را روی ترد اصلی انجام بدهیم؟{Ui object Create,Update,Destroy}انجام این فعالیت‌ها روی آبجکت‌های یوای , ترد امن (Thread safe) نیست،یعنی نمی‌توانیم این کدها را روی تردهای دیگر ران کنیم، کرش می‌کنیم یا ایرادهای دیگر به وجود می‌آید.چه کارهایی را روی ترد اصلی انجام ندهیم؟باید اصلی کلی را به خاطر بسپاریم و آن اینکه کارهای سنگین را روی ترد اصلی انجام ندهیم.این وظیفه‌ها را به تردهای دیگر بسپاریم.همین جا یک نکتۀ مهم وجود دارد:باید حتماً به تردها دیتای IMMUTABLE بدهیم و یک شیء را بین چند تا ترد به اشتراک نگذاریم ، چراکه ممکن است اتفاق‌های بدی بیفتد.ماندگاری ترد چطور باشد؟دو نوع ترد داریم:تردهای اول در نهایت فقط می‌خواهند روی یو ای اثر بگذارند.در اینجا اگر تا قبل از رسیدن جواب، ترد اکتیویتی از بین برود، لزومی ندارد ترد را بعد از بین رفتن اکتیویتی مربوط نگه داریم.از بین بردن این تردها معمولاً کار زجرآوری است و یادمان می‌رود، پس بهتر است از ابزارهایی مثل لایو دیتا استفاده کنیم، بدون اینکه دیگر نگران از بین رفتن این lifeCycle باشیم.برخی تردها هم کارهای دیگر می‌کنند که فرضاً برای ما کار مفیدی است. مثلاً دیتایی را کش می‌کنند یا دانلود می‌کنند. اینجا حتی اگر اکتیویتی بسته بشود، بهتر است این فعالیت ادامه پیدا کند و کارش را تمام کند. (البته باز هم به کسب‌وکار ما بستگی دارد.)اولویت‌بندی ترد THREAD PRIORITYمیزان اولویت تردها تا حد زیادی به lifeCycle و کسب‌وکار شما مربوط می‌شود.اما خوب است بدانیم اگر high Thread priority باشد،روی مِیْن ترد اثر می‌گذارد و به آن می‌گوییم: رندر ترد renderThreadو امکان دارد باعث افت فریم برنامه بشود.و اگر خیلی کم باشد، امکان دارد کار در اولویت خیلی پایینی انجام بشود و آن زمانی که بهش نیاز داریم، به دستمان نرسد.در اندروید، سیستم عامل ۹۵ درصد منبع دستگاه را اختصاص می‌دهد به foreground thread و فقط پنج درصد مربوط به background thread می‌شود.به‌طور معمول، اگر شما یک ترد را خودتان ایجاد کنید priority را از ترد والد ارث می‌برد، مگر اینکه شما آن را تغییر بدهید.setThreadPriorityاینجا می‌توانیم اولویت تردمان را مشخص کنیم.process.setThreadPriority-20 <= ThreadPriority <= 19کمترین اولویت 19 است و بیشترین اولویت -20برای راحتی thread یک اینترفیسی دارد برای ست کردن پرایرتی،Thread.priorityکه اینجا1 <= Priority <= 10به اصطلاح به این مقدار می‌گوییم: nice value.که در واقع مپی هست برای ست کردن process.setThreadPriorityترد مین normPrirority است و هر تردی که می‌سازیم، همچون والدش ترد مین است و به‌صورت دیفالت همین عدد پنج برایش تنظیم شده است.راه راحت‌ترراه راحت‌ترِ استفاده از ترد , استفاده از helper Classهاست.مثل coroutine برای کاتلین یا handler ، executorو... که ان‌شاءالله بعداً بیشتر راجع به این موارد هم توضیح می‌دهیم.چه مقدار ترد بسازیمکلاً ساخت ترد هزینۀ زیادی داردو باید توجه کرد که منابع ما هم محدود است. پس، بهتر است که تا جایی که می‌شود، کمتر ترد ایجاد کنیم.هر دیوایس می‌تواند تعداد محدودی ترد را هم‌زمان ران کند.از نگرانی‌های دیگری که برای تعداد زیادی ترد وجود دارد، این است که آن‌ها را آزاد نکنیم.این خودش عامل بدی می‌شود برای مموری لیک، چون هر ترد حداقل ۶۴ کیلو بایت رم مصرف می‌کند.(این‌ها را می‌توان با ابزاری مثل systrace آزمایش کرد و برنامه را در مقایسه با آن بهبود داد.)خیلی وقت‌ها برای اینکه تردی را اضافه نسازیم یا اینکه از یک ترد برای چند کار استفاده کنیم، باید از مفهومی به نام استخر تردها :) threadPool استفاده بکنیمکه این را هم می‌گذاریم برای مقالۀ بعدی ان‌شاءالله.ممنون از همراهی‌تان

نتیجه مهم‌تراست یا فرایند؟ گاهی تصمیم‌های خوب باعث شکست می‌شوند!

انیس‌ ناصری — Sun, 17 Jan 2021 19:13:05 +0330

فرایند یا نتیجه؟فرض کنید قرار است عملکرد سه جراح را ارزیابی کنید. برای شروع فرایند آزمایش، از هرکدام خواسته شده تا یک عمل سخت را پنج بار انجام دهند. در طی این سال‌ها، احتمال مرگ بر اثر این عمل بیست درصد بوده و ثابت مانده است. هیچ‌کس زیرِ دست جراح الف فوت نمی‌کند. زیرِ دست جراح ب یک بیمار از دست می‌رود و زیرِ دست جراج ج دو بیمار فوت می‌کنند. اگر مثل بقیۀ مردم فکر کنید، الف را بهترین، ب را در مقام دوم و ج را بدترین جراح در نظر می‌گیرید. بنابراین، شما هم قربانیِ خطای نتیجه شده‌اید! (با تلخیص از دوبلی: ۷۵)این چند خط را از کتاب هنر شفاف اندیشیدن از رولف دوبلی آورده‌ام تا بحث را با مثال روشن کنم. چرا ما همیشه کارها را با توجه به نتایجشان ارزیابی می‌کنیم و نه با توجه به فرایندها و اهداف؟چرا فکر می‌کنیم اگر نتیجۀ کاری درست از آب درآمده، لزوماً تصمیمی که گرفته‌ایم صحیح بوده است و دیگر هیچ فرایندی را بررسی نمی‌کنیم؟ یا اگر شکست می‌خوریم، همه را گردنِ تصمیم‌های اشتباه می‌اندازیم و برای همیشه، آن نگاه و آن نوع تصمیم‌گیری‌ها را دور می‌ریزیم؟مثلاً در مورد موضوع جراح‌ها می‌توان به روش‌های دیگری نیز موضوع را بررسی کرد، یعنی می‌توان این فرایندها را نیز بررسی کرد: چه عواملی در عمل جراحی مؤثر بوده، چه متغیرهای دیگری وجود داشته و... . باید بدانیم که «در کار یک جراح متوسط، احتمال اینکه کسی فوت نکند ۳۳ درصد است، احتمال اینکه یک نفر فوت کند ۴۱ درصد است و احتمال اینکه دو نفر فوت کنند ۳۰ درصد است. این یک محاسبۀ سادۀ احتمالات است. نکتۀ مهم این است: تفاوت زیادی بین احتمال کشته و دو مورد فوتی وجود ندارد. ارزیابی سه جراح فقط بر اساس نتایج، نه‌تنها سهل‌انگارانه که غیراخلاقی است.» (دوبلی: ۷۵)تأثیر تصمیم‌های خوب یا بدآیا تصمیمات خوب باعث شکست می‌شوند و تصمیمات بد باعث موفقیت؟چند بار بعد از پیش آمدن نتیجه‌ای بد این جمله را شنیده‌اید: «از اولش معلوم بود چی می‌شه، می‌شد نتیجه رو حدس زد»؟ شرط می‌بندم زیاد شنیده‌اید! اما داستان از این قرار است که به این سادگی‌ها هم نیست. واقعاً اگر راه جلوگیری از اشتباه کردن آن‌قدر مشخص است، چرا هنوز تصمیم‌هایی می‌گیریم که از آن‌ها پشیمان می‌شویم؟«شما نمی‌توانید آینده را پیش‌بینی کنید. بعضی اوقات حتی تصمیمات بد ممکن است به نتایج خوب منجر شود.» (پیتر بولین)پس ارتباط دادن تصمیمات به شکست‌ها و موفقیت‌ها لزوماً کار درستی نیست. همان‌طور که پیتر بولین می‌گوید: «گاهی تصمیمات بد ممکن است به نتایج خوبی منجر شود و برعکس.»توصیۀ سعدی شیرازی به تمرکز نکردن بر نتایجهشتصد سال پیش، سعدی شیرازی هم مثالی از تمرکز بر فرایندها برای ما آورده و ازمان خواسته است که نه بر نتایج که بر فرایندها تمرکز کنیم. حکایت زیر را بخوانید تا بعد از آن کمی به شرحش بپردازیم:«یکی را از ملوک پارس نگینی گران‌مایه بر انگشتری بود. باری به حکم تفرج با تنی چند خاصان به مصلای شیراز برون رفت. فرمود تا انگشتری را بر گنبد عضد نصب کردند تا هر که تیر از حلقۀ انگشتری بگذراند، خاتم او را باشد. اتفاقاً چهارصد حکم‌انداز که در خدمت او بودند جمله خطا کردند، مگر کودکی بر بام رباطی که به بازیچه تیر از هر طرفی می‌انداخت. باد صبا تیر او را به حلقۀ انگشتری در بگذرانید و خلعت و نعمت یافت و خاتم به وی ارزانی داشتند. پسر تیر و کمان را بسوخت. گفتند: چرا کردی؟ گفت: تا رونق نخستین بر جای ماند.گه بوَد کز حکیم روشن‌رای/ برنیاید درست تدبیریگاه باشد که کودکی نادان/به غلط بر هدف زند تیری» (گلستان سعدی، باب سوم)سعدی شیرین‌سخن حکایت می‌کند که یکی از ملوک پارس صاحب انگشتری با نگینی بسیار ارزشمند بود. روزی برای تفریح و سرگرمی با نزدیکان خود به مصلای شیراز می‌رود و دستور می‌دهد که نگین انگشتر را بر گنبد عضد (از بناهای دورۀ دیلمی) بگذاردند و شرطی می‌گذارد که اگر کسی بتواند تیر را از حلقۀ انگشتر بگذراند، نگین یا کل انگشتر از آنِ او می‌شود!اتفاقاً چهارصد حکم‌انداز (یعنی تیراندازهای ماهری که درست به هدف مقرر و تعیین‌شده می‌زنند) در خدمت پادشاه بودند. همه سعی کردند و هیچ‌کدام نتوانستند، الّا کودکی که بر بام کاروان‌سرایی برای بازی و سرگرمی از هر طرف تیری می‌انداخت. باد صبا موافق وزید و تیر او را از حلقه گذرانید. ملک همراه با خلعت و نعمت فراوان، انگشتر را به او هدیه داد. پسر تیر و کمان را سوزاند. همه گفتند که این چه کاری است که بعد از این قهرمانی می‌کنی؟ گفت: «برای اینکه رونق کارم ماندگار باشد.» سپس سعدی با دو بیت منظور خود را از حکایت توضیح می‌دهد. در این داستان، حکم‌انداز‌هایی که همه کار خود را بلد بودند، فرایندها را می‌دانستند و از روش درستی برای پرتاب تیر استفاده می‌کردند، نتوانستند تیر را وارد حلقه کنند، اما کودکی که به بازی چند تیر را به چپ و راست می‌انداخت، به‌دلیل همراهی باد صبا تیر را به هدف زد.مدل‌های ذهنی مدل‌های ذهنی: راه‌حلچگونگی نگاه شما به روش کار کردن چیزها در دنیای واقعی، مدل ذهنی نامیده می‌شود. این چارچوب تفکر شماست. اما وقتی در حال تصمیم‌گیری هستیم، اغلب به چارچوبِ خود فکر نمی‌کنیم و بلافاصله به بحث دربارۀ نتایج احتمالی می‌پردازیم.ما معمولاً می‌پرسیم: «اگر این تصمیم را بگیریم، نتیجه چه خواهد شد؟»این یک روش ناسازگار است، زیرا در آن تنها به نتیجه فکر کرده‌ایم. اما آیا در نظر گرفته‌ایم که از چارچوب‌های خاص تفکر (مدل‌های ذهنی) برای تصمیم‌گیری خود استفاده کنیم؟خیلی اوقات، ما از فرایند پرواز می‌کنیم و بر زمین تصمیم‌گیری فرود می‌آییم. شاید به‌دلیل کمبود وقت، منابع و دانش باشد. ما هرگز نمی‌توانیم آینده را پیش‌بینی کنیم یا همۀ مدل‌های ذهنی موجود را بشناسیم، اما می‌توانیم تصمیمی بگیریم که پشیمان نشویم. فقط با تمرکز روی فرایند تفکر، همیشه می‌توان گفت که کار درستی انجام داده‌ایم و این تنها راه مطمئن برای جلوگیری از پشیمانی است، فارغ از آنکه نتیجه چه باشد.منابعhttps://medium.com/darius-foroux/stop-trying-to-make-good-decisions-368abeafb873دوبلی، رولف (۱۳۹۴)، هنر شفاف اندیشیدن، ترجمۀ عادل فردوسی‌پور و دیگران، تهران: چشمه.سعدی شیرازی، گلستان سعدی.

معرفی و بررسی ۳ ابزار کد باز مناسب تحلیل و هوش تجاری

امید میراب زاده اردکانی — Tue, 22 Dec 2020 11:59:50 +0330

مقدمه (هدف)از ابزارهای پُراهمیت در مسیر داده‌محور شدن سازمان‌ها، ابزارهای موسوم به تحلیل و هوش تجاری (Analytics and BI Tools) است. انتظارات اولیه از ابزارهای تحلیل و هوش تجاری و قابلیت‌های آن‌ها را می‌توان در قالب موارد زیر دسته‌بندی کرد:۱. توانایی اتصال به منابع داده‌ای مختلف؛۲. توانایی تغییر داده‌ها پس از دریافت از منبع داده؛۳. توانایی بصری‌سازی داده‌ها؛۴. توانایی ارسال هشدارها و رخدادها؛۵. امکان مدیریت سطح دسترسی؛۶. توانمندسازی همۀ اعضای سازمان در تحلیل داده‌ها بدون نیاز به دانش تخصصی.به تعبیری هدف اصلی به‌کارگیری این ابزارها در سازمان‌ها را می‌توان «توانمندسازی همۀ اعضای سازمان در پاسخ‌گویی به پرسش‌های کسب‌وکاری از طریق داده‌ها و یادگیری از داده‌های سازمان» دانست.برای انتخاب ابزارهای تحلیل و هوش تجاری، معیارهای مختلفی پیشنهاد شده است که در ادامه و در بخشی مجزا به معیارهای انتخاب ابزارهای تحلیل و هوش تجاری می‌پردازیم.چرا ابزارهای کد باز؟یکی از تصمیم‌های اساسی در زمینۀ انتخاب ابزار مناسب، تصمیم دربارۀ کد باز بودن یا اختصاصی‌بودن نرم‌افزار است. در هر دو حوزه نیز نرم‌افزارهای شناخته‌شده‌ای به‌عنوان گزینه‌های درخور توجه وجود دارد.از جمله ابزارهای اختصاصی تحلیل و هوش تجاری که در قالب مدل نرم‌افزار به‌عنوان خدمت (SaaS) ارائه می‌شود، می‌توان به نمونه‌های زیر اشاره کرد:Microsoft Power BITableau CloudQlik Sense CloudIBM Watson AnalyticsTIBCO SpotfireDomo.comبرای انتخاب از بین ابزارهای اختصاصی، معمولاً گزارش‌های تجاری نظیر گزارش Magic Quadrant گارتنر به‌عنوان راهنمایی اولیه و مناسب، در دسترس است و می‌توان برای انتخاب ابزار باتوجه‌به معیارهای مدنظر، از این گزارش‌ها استفاده کرد.از جمله ابزارهای کد باز تحلیل و هوش تجاری که به‌صورت رایگان ارائه می‌شود، می‌توان به نمونه‌های زیر اشاره کرد:MetabaseRedashApache Superset (formerly was Caravel)GrafanaKibanaاین مستند با این فرض نگاشته شده که سیاست ما، استفاده از ابزارهای کد باز تحلیل و هوش تجاری است و سه نمونه از ابزارهای کد باز بررسی و مقایسه شده است.از جمله مزایای استفاده از ابزارهای کد باز، امکان تخصیص تیم مستقل درون سازمان برای توسعۀ ابزار و شخصی‌سازی آن باتوجه‌به نیازهای کسب‌وکاری خاص سازمان است. همچنین هزینۀ تعبیۀ این ابزارها در نرم‌افزارهای بومی سازمان و شخصی‌سازی آن‌ها به‌نسبت نرم‌افزارهای اختصاصی کمتر است.گزینه‌های شناسایی‌شدهمهم‌ترین نرم‌افزارهای تحلیل و هوش تجاری کد باز شناسایی‌شده شامل نمونه‌های زیر است:MetabaseRedashApache Superset (formerly was Caravel)GrafanaKibanaگزینه‌های انتخاب‌شدهانتخاب گزینه‌های اولیه برای بررسی بیشتر می‌تواند باتوجه‌به نیازهای سازمان، قابلیت‌های ابزار، تجربۀ قبلی در زمینۀ استفاده از این ابزارها در سازمان، میزان بلوغ و چشم‌انداز توسعۀ آتی ابزارها انجام شود. بر این اساس، در مرحلۀ اول، ابزارهای Metabase، Redash، Apache SuperSetو Grafana به‌عنوان گزینه‌های بررسی بیشتر انتخاب شد.معیارهای ارزیابیمعیارهای کلی که در این بررسی برای تصمیم‌گیری دربارۀ انتخاب ابزار، برگزیده شده، عبارت‌اند از:۱. سهولت نصب، راه‌اندازی و نگهداری؛۲. مشتریان استفاده‌کننده از ابزار با توجه ویژه به صنعت و اندازۀ کسب‌وکار آن‌ها؛۳. چشم‌انداز توسعه و میزان فعال‌بودن جامعۀ توسعه‌دهندۀ ابزار؛۴. پشتیبانی (در دسترس بودن مستندات و میزان فعال‌بودن جامعه در پاسخ‌گویی به اشکال‌های احتمالی)؛۵. طرح‌های رایگان و پولی استفاده از ابزار و قابلیت‌های هریک از طرح‌ها؛۶. میزان دانش فنی ضروری برای کار با ابزار و یادگیری از داده‌ها؛۷. تنوع امکان ارتباط با سایر زیرساخت‌ها و سیستم‌های سازمان؛۸. تنوع نمودارها و قابلیت‌های بصری‌سازی؛۹. امکان به‌کارگیری خروجی گزارش‌ها در ابزارهای بومی سازمان.همچنین برای همۀ ابزارها، نکته‌های زیر نیز حائز اهمیت است که با توجه به زمینه سازمانی می‌تواند مدنظر قرار بگیرد.۱. چه کسانی در سازمان از ابزار استفاده می‌کنند؟۲. اقلامی که تحویل داده می‌شوند، چه چیزهایی هستند؟۳. اندازۀ داده‌ها و مقیاس‌پذیری آن چیست؟۴. آیا این ابزار در یک فرایند موجود قرار می‌گیرد یا جزو اصلی فرایند جدیدی است؟در ادامه ابزارها را بررسی می‌کنیم و در نهایت، آن‌ها را بر اساس نُه معیار اول معرفی‌شده در این بخش مقایسه می‌کنیم.متابیس«متابیس» ابزار کد باز تحلیل و هوش تجاری است که رسالت اصلی خود را توانمندسازی همۀ افراد شرکت برای یادگیری از داده‌ها معرفی می‌کند.نصب ابزار از طریق داکر و یا فایل جاوا ممکن است و به‌راحتی انجام می‌شود.ابزار را در کمتر از پنج دقیقه به‌راحتی و با حداقل دانش فنی می‌توان نصب و راه‌اندازی کرد.متابیس به‌راحتی به منابع دادۀ متنوعی متصل می‌شود. البته تنوع منابع داده‌ای آن نسبت به «ری‌دش» و «سوپرست» محدود است.منابع داده‌ای متابیسمهم‌ترین تمایز این برنامه را می‌توان در سهولت راه‌اندازی و نگهداری، عدم نیاز به داشتن دانش فنی برای یادگیری از داده‌ها و تجربۀ کاربری مناسب آن دانست؛ ذکر این نکته ضروری است که به‌رغم زیبایی و سهولت و تجربۀ کاربری مناسب، تنوع نمودارها زیاد نیست.مستندات متابیس کاربران را در زمینۀ مراحل مختلف راه‌اندازی و ساخت داشبورد با استفاده از ابزار، به‌خوبی راهنمایی می‌کند. همچنین فعالیت در سایت‌های راهنما برای پاسخ‌گویی به اشکال‌های کاربران شایان توجه است.چشم‌انداز توسعۀ آتی متابیس، در سایت گیت‌هاب و در یکی از ارائه‌های این شرکت به‌صورت نکته‌های زیر ذکر شده است:امکان جوین بین جدول‌های مختلف؛استفاده از چندین سری در سازندۀ کوئری؛ایجاد بهبودهایی در ابعاد؛ماژولار کردن ارائه‌دهندگان SSO؛قابلیت ایجاد اسنیپت‌های SQL؛قابلیت کش‌کردن پیش‌بینانه؛پشتیبانی بیشتر از جوین‌ها و کار روی سازندۀ کوئری جدید.Instance Serialization؛Reduced Memory Footprint؛اطلاعات مربوط به فعال‌بودن توسعۀ متابیس روی گیت‌هاب در شکل زیر نمایش داده شده است.متابیس در دو حالت ابری و نصب روی سرور اختصاصی ارائه شده سرویس ابری آن در سه طرح مختلف و سرویس نصب اختصاصی آن در دو طرح مختلف ارائه شده است که می‌توان این طرح‌ها را در دو شکل زیر مشاهده کرد:طرح های ابری متابیسطرح های نصب روی سرور اختصاصی متابیسدر طرح‌های پولی، امکانات پشتیبانی مناسبی از جمله تخصیص کارشناس پشتیبانی اختصاصی و پاسخ‌گویی در زمان کوتاه ارائه می‌شود.از تمایزهای این محصول که کمتر در محصولات مشابه وجود دارد، قابلیتی به نام X-Ray است که داده‌های بازنمایی‌شده در داشبوردها را از مناظر جدیدی بررسی می‌کند و امکان یادگیری را روی داده‌های بازنمایی‌شده که نسبت به روند نرمال متمایز هستند، ایجاد می‌کند.متابیس امکان بازنمایی داده‌های مربوط به چند منبع دادۀ مختلف (در پایگاه داده‌های مختلف) در قالب تنها یک داشبورد را فراهم می‌کند.منطق ساخت گزارش‌ها ساده است و کاربران به‌راحتی می‌توانند گزارش‌های خود را در قالب سؤال‌هایی ایجاد کنند، در قالب مجموعه‌ها ذخیره نمایند و از طریق داشبوردها بازنمایی کنند. همچنین، می‌توان سطوح دسترسی را در سطح مجموعه‌ها مدیریت کرد.کاربران حرفه‌ای می‌توانند از طریق سازندۀ کوئری سؤال‌های مدنظر خود را ایجاد کنند یا سؤال‌های ایجادشده از طریق رابط کاربری را ویرایش کنند.ری‌دش«ری‌دش» یکی دیگر از ابزارهای شناخته‌شده و معتبر کد باز تحلیل و هوش تجاری است. رسالت ری‌دش کمک به کاربران برای درک بهتر داده‌هایشان است.باتوجه‌به اینکه راه‌اندازی ابزار ری‌دش وابستگی‌هایی به Redis، Node js، PostgreSQL و NginX دارد، صرفاً دریافت فایل داکر آماده از داکر هاب برای استفاده از ابزار کفایت نمی‌کند. برای این منظور، راهنمای نصب و راه‌اندازی ابزار در دو سطح برای توسعه‌دهندگان در دسترس قرار گرفته است. اطلاعات کامل راهنمای نصب و راه‌اندازی ری‌دش را می‌توانید در مسیر https://redash.io/help/open-source/dev-guide مشاهده کنید.برای راه‌اندازی ری‌دش از دستورالعمل‌های ارائه‌شده در سایت استفاده شد که مطابق راهنمای سایت راه‌اندازی موفق انجام نشد و اطلاعات موجود در سایت صحیح نبود. راهنماهای موجود در اینترنت نیز برای رفع مشکل کافی نیست و به‌نظر می‌رسد که راه‌اندازی و نگهداری (به‌ویژه در مراحل به‌روزرسانی) نیازمند تخصص و زمان بیشتری نسبت به ابزار متابیس است.ری‌دش به‌راحتی به منابع داده متنوعی متصل می‌شود. تنوع منابع داده‌ای آن نسبت به متابیس بسیار بیشتر و درخور توجه است؛ از جمله اتصال‌های شایان توجه ری‌دش که در متابیس موجود نیست،‌ امکان اتصال به کاساندرا، گرین پلام و هایوْ است. همچنین امکان یکپارچه‌سازی با Google Spreadsheets، JIRA،‌JSON و Python از جمله قابلیت‌های درخور توجهی است که در متابیس موجود نیست.برای کار با ری‌دش و ساخت داشبوردها، لازم است تا کاربر دانش کوئری‌نویسی مناسبی داشته باشد و از این منظر شاید نتوان آن را در زمرۀ ابزارهای Self Service BI ایده‌آل برای کاربران عادی سازمان به‌حساب آورد.مهم‌ترین نقطۀ تمایز این برنامه را می‌توان در تنوع اتصالات و تنوع نمودارها دانست. برای مثال امکان رسم نمودار Cohort برای بررسی نگهداشت کاربران از قابلیت‌های شایان توجه ابزار ری‌دش است.همچنین قابلیت‌های در دسترس کاربر برای نمودارهای موجود روی داشبورد نیز بیشتر از متابیس است.یکی از قابلیت‌های کاربردی دیگر این ابزار، امکان دسترسی به گزارش‌های ایجادشده از طریق api است.در مقایسه با متابیس، سهولت راه‌اندازی و نگهداری ری‌دش کمتر است و برای راه‌اندازی و توسعۀ داشبوردها روی ابزار،‌ دانش فنی لازم است. ذکر این نکته لازم است که در زمینۀ زیبایی و تجربۀ کاربری متابیس کاربرپسندتر از ری‌دش است.مستندات ری‌دش در زمینۀ مراحل مختلف راه‌اندازی و ساخت داشبورد با استفاده از ابزار، موجود است؛ اما به‌نظر می‌رسد که سازنده سرمایه‌گذاری مناسبی در این حوزه انجام نداده است. مستندات و راهنماهای کاربری متابیس در این زمینه برتر از ری‌دش به‌نظر می‌رسد.اطلاعات چشم‌انداز توسعۀ آتی ری‌دش، در سایت سازنده و در گیت‌هاب در دسترس نیست.اطلاعات مربوط به فعال‌بودن توسعۀ ری‌دش روی گیت‌هاب در شکل زیر نمایش داده شده است.باتوجه‌به بررسی میزان فعالیت یک‌ماهه روی سایت گیت‌هاب و همچنین مقایسۀ سایت https://stackshare.io/stackups/superset-vs-redash-vs-metabase از سه محصول مدنظر، میزان فعالیت و جامعۀ کاربران فعال متابیس بیشتر از ری‌دش و سوپرست است.ری‌دش در سه سطح آغازگر، حرفه‌ای و کسب‌وکار قیمت‌گذاری و ارائه می‌شود.قیمت‌گذاری طرح‌های مختلف ری‌دشدر طرح کسب‌وکار قابلیت‌ها مشابه قابلیت‌های طرح نصب اختصاصی بنگاهی متابیس است. از نظر مالی به‌نظر می‌رسد که طرح کسب‌وکار ری‌دش هزینۀ کمتری در یک سال ایجاد می‌کند.ری‌دش امکان بازنمایی داده‌های مربوط به چند منبع داده مختلف (در پایگاه داده‌های مختلف) در قالب تنها یک داشبورد را فراهم می‌کند.منطق ساخت گزارش‌ها به‌نسبت ساده است و کاربران به‌راحتی می‌توانند گزارش‌های خود را در قالب کوئری‌هایی ایجاد کرده، آن‌ها را روی داشبوردها نمایش دهند.سوپرست«سوپرست» از دیگر ابزارهای شناخته‌شده و معتبر کد باز تحلیل و هوش تجاری است. این ابزار ابتدا با نام Panoramix و سپس Caravel به‌عنوان پلتفرم اکتشاف داده (data exploration) توسعه داده شده است و در حال حاضر به‌عنوان نوعی ابزار تحت وب هوش تجاری مدرن و در سطح بنگاه (enterprise-ready) توسط کمپانی Apache پشتیبانی می‌شود. در حال حاضر Apache Superset به‌عنوان یکی از پروژه‌های تحت شتاب‌دهی بنیاد آپاچی است و در صورت تأیید برخی پارامترها، به‌عنوان یکی از پروژه‌های بنیاد نرم‌افزاری آپاچی (ASF) پذیرفته می‌شود.رسالت سوپرست از ابتدا کمک به کاربران برای درک بهتر داده‌هایشان و اکتشاف داده‌ها بوده است. در ابتدا Caravel به‌عنوان پلتفرم اکتشاف داده‌ها و ساخت داشبوردها درون airbnb توسعه داده شده است و پس از آن کد آن به‌صورت باز منتشر شده است.راه‌اندازی ابزار سوپرست وابستگی‌هایی به PostgreSQL و Redis دارد. برای نصب و راه‌اندازی سوپرست به دانش تخصصی حداقلی کار با لینوکس نیاز دارید. اطلاعات کامل راهنمای نصب و راه‌اندازی سوپرست را می‌توانید در مسیر https://superset.incubator.apache.org/installation.html مشاهده کنید.سوپرست به‌راحتی به منابع داده متنوعی متصل می‌شود. تنوع منابع داده‌ای آن نسبت به متابیس بیشتر و درخور توجه است. سوپرست به‌صورت پیش‌فرض، به‌جز اتصال به Sqlite که بخشی از کتابخانۀ استاندارد پایتون است،‌ قابلیت اتصال به سایر پایگاه‌های داده‌ای را در خود ندارد؛ برای این منظور لازم است تا پکیج‌های ضروری مدنظر نصب شود. امکان اتصال به پایگاه‌های داده‌ای مختلفی که SQL Alchemy را پشتیبانی می‌کنند، وجود دارد.برای کار با سوپرست و ساخت داشبوردها، لازم است تا کاربر دانش نسبی کوئری‌نویسی داشته باشد و از این منظر شاید نتوان آن را در زمرۀ ابزارهای Self Service BI ایده‌آل برای کاربران عادی سازمان به‌حساب آورد.از ویژگی‌های کلیدی و بسیار مهم سوپرست انجام تنظیمات مربوط به کش برای بارگذاری داشبوردهاست.از دیگر تمایزهای مهم این ابزار می‌توان تنوع اتصالات و تنوع نمودارها را ذکر کرد. برای مثال امکان رسم نمودارهای Sankey و Sunburst از قابلیت‌های متمایز ابزار سوپرست است.همچنین قابلیت‌های در دسترس کاربر برای نمودارهای موجود روی داشبورد نیز بیشتر از متابیس است.یکی از قابلیت‌های کاربردی این ابزار، امکان خروجی گرفتن از نمودارها در قالب‌های json و csv است.در مقایسه با متابیس سهولت راه‌اندازی و نگهداری سوپرست اندکی کمتر است و برای راه‌اندازی و توسعۀ داشبوردها روی ابزار،‌ دانش فنی نسبی لازم است.برای برخی از نیازها، نیازمند شخصی‌سازی و سفارشی‌سازی سوپرست خواهید بود که با زبان پایتون انجام می‌شود.مستندات سوپرست در زمینۀ مراحل مختلف راه‌اندازی و ساخت داشبورد با استفاده از ابزار، موجود است. از نقاط قوت بالقوۀ سوپرست، سرمایه‌گذاری بنیاد نرم‌افزاری آپاچی روی ابزار است؛ به‌گونه‌ای که در حال حاضر کتابی با موضوع معرفی سوپرست در سایت انتشارات PacktPub در دسترس است که بخش‌هایی از آن را می‌توان به‌رایگان مطالعه کرد.اطلاعات چشم‌انداز توسعۀ آتی سوپرست، در سایت سازنده در دسترس نیست.اطلاعات مربوط به فعال‌بودن توسعۀ سوپرست روی گیت‌هاب در شکل زیر نمایش داده شده است.سوپرست امکان بازنمایی داده‌های مربوط به چند منبع دادۀ مختلف (در پایگاه داده‌های مختلف) در قالب تنها یک داشبورد را فراهم می‌کند.منطق ساخت گزارش‌ها ساده است و کاربران به‌راحتی می‌توانند گزارش‌های خود را در قالب کوئری‌هایی ایجاد کنند و آن‌ها را روی داشبوردها نمایش دهند.مقایسهمقایسۀ متابیس، ری‌دش و سوپرست باتوجه‌به معیارهای معرفی‌شده در بخش معیارهای ارزیابی، در قالب جدول زیر ارائه می‌شود.مقایسه ابزارهای متابیس، ری‌دش و سوپرستنتیجه‌گیریتصمیم‌گیری دربارۀ انتخاب ابزار باتوجه‌به اطلاعات ارائه‌شده نیازمند بحث باتوجه‌به نیازهای ویژه، منابع و محدودیت‌های سازمان است.

کدِ بیات

Hossein Ansari — Sat, 12 Dec 2020 08:20:18 +0330

بالغ-بالغ یا کودک-والد؟آیا روان‌شناسی به کار برنامه‌نویسی هم می‌آید؟ من که نان خانه‌ام را همین‌جور به دست می‌آوردم. باری چندی پیش نشستیم و یکی دو قصه تعریف کردیم و دو سه فحش به عدم درک کار تیمی دادیم و قول دادیم که شبی دیگر بیاییم و از الگوهای فنی برای کمک به رابطه‌های بالغ-بالغ بگوییم.حالا آمدیم که درباره «کدِ بیات» حرف بزنیم. کد ِبیات چیست؟ کدی که از زمان «بهترین تاریخ مصرف‌»ش گذشته باشد. یعنی بیش‌تر از ۲۴ ساعت از زمان نوشته شدنش توسط برنامه‌نویس گذشته باشد و هنوز در برنچ اصلی Master ادغام نشده باشد!کد بیات بخشی از چرخه است. یک گام بعدش «مستر بیات» است. Master بیات چیست؟ برنچ اصلی که ۲۴ ساعت از آخرین تغییرش گذشته باشد و هنوز آرتیفکت بیلدشده‌ش در جایی پابلیش نشده باشد!و در آخر «نسخه‌ بیات» را داریم. نسخه‌ای که ۲۴ ساعت از ساخت آرتیفیکت و احتمالا دیپلوی شدنش گذشته است ولی به مشتریان و کاربران «دلیور» نشده باشد.همه‌ این‌ها در همان چرخه توسعه محصول Lean هستند. ‌می‌خواهیم بدانیم به قول خارجی‌ها From Idea to Cash چقدر طول می‌کشد؟ چقدر تند تند می‌توانیم چرخه Build-Measure-Learn را طی کنیم؟خب از قصه دور نشویم. «کد بیات» چیست و چرا؟ در پست پیش درباره قصه‌ی «مدل برنچینگ گیت‌هاب طور» صحبت کرده بودیم. این که چقدر «نسخه دادن»‌ را خون‌بار می‌کند.گفتیم که بعضاً ناگزیریم که همین مدل را پیش برویم. اما اگر یک «تیم» کوچک و چابک هستیم راه‌های به‌تری برای رستگاری وجود دارد.یک پترن خوب و توصیه‌شده این است: «Trunk Based Development». یا به طور خلاصه T‌BD.حرف حساب تی‌بی‌دی چیست؟ «فساد کد بیات بدترین فساد ممکن است. هزینه‌ش برای تیم خیلی بیش‌تر از هر چیز دیگر است. هر کدام از اعضای تیم که کدی برای خودش نوشت باید در سریع‌ترین زمان ممکن آن‌ها را در برنچ اصلی ادغام کند. یعنی ترجیحن زیر دو ساعت این کار را بکند. و تلاشش را بکند که هیچ Long Lived Branchی با عمر بیش‌تر از یک روز نداشته باشد.در تیم‌های کوچک دو سه نفره حتی می‌شود هیچ برنچی نداشت و همه چیز را به سادگی در همان برنچ اصلی نوشت. در تیم‌های بزرگ‌تر حالا اشکالی ندارد Short Lived Branch با عمر چند ساعت داشته باشیم»عوض کردن چرخ‌های ماشین در حال حرکتاین کار طبعاً هزینه‌هایی دارد. اما مدعا این است که در نهایت هزینه‌ش برای تیم کم‌تر است. و سود خوبی نصیب تیم می‌کند. مهم‌ترین مزایا چیستند؟ما همیشه یک ماشین در حال حرکت داریم! یعنی هر لحظه که بخواهیم می‌توانیم از برنچ اصلی یک نسخه بدهیم. لازم نیست ماشین توسعه‌ی کد را متوقف کنیم و درگیر کانفلیکت‌های سینتکسی گیت و ناسازگاری‌های بعدش در هنگام مرج‌های بزرگ شویم.اگر دعوایی بین کدهای اعضای تیم وجود دارد خیلی سریع آشکار می‌شود. این شاید مهم‌ترین مزیت این کار باشد! Fail Fast, Fail Often. لازم نیست دو هفته کد بنویسیم و بعد بفهمیم یکی همان حین معماری آن کلاسی که ازش استفاده می‌کردیم را عوض کرده است!امنیت روانی کاذب و اشتباه اعضای تیم را ازشان می‌گیرد. نمی‌توانند به غار تنهایی‌شان بروند و بگویند وظیفه‌ی ما نوشتن همین تسک خاص است. و مسئولیت درست کردن نسخه و انتشارش با بقیه و مدیر تیم و مدیر محصول و این‌هاست. این رفتار کودک-والد را کنار می‌گذارند و مسئولیت مشترک محصول را به عهده می‌گیرند و بالغ-بالغ رفتار می‌کنند.خب مخاطب این نوشته‌ها لزومن فقط برنامه‌نویسان نیستند. اتفاقاً من برای مدیران تیم و مدیران محصول می‌نویسم.این‌‌ها را اگر به برنامه‌نویسان خودتان بگویید یحتمل فحش‌های قابل پیش‌بینی می‌دهند. که این ادغام زود کدهای نیمه‌تمام هزار تا باگ درست می‌کند و کیفیت کد را کاهش می‌دهد و اصلاً مانع رلیز می‌شود.منتها یک سری راه‌کار فنی ساده برای پیمایش درست و کم‌هزینه‌ این مسیر وجود دارد که در پست‌های بعد درباره‌ش صحبت می‌کنیم. می‌گوییم که چطور کدهای نیمه‌کاره را در برنچ اصلی ادغام کنیم. از روی برنچ اصلی نسخه بدهیم ولی کاربران را اذیت نکنیم!

جلسه پست‌مرتم چیست؟

محمد اژدری — Tue, 08 Dec 2020 12:03:45 +0330

در ادامه قسمت قبل، در این نوشته، فصل Postmortem Culture: Learning from Failure را خلاصه و بررسی می‌کنیم.هزینۀ خطا/شکست، یادگیری است!در شرکت‌ها یا سازمان‌ها ممکن است به دلایل مختلف، خطاها و شکست‌هایی رخ بدهد.اما نکتۀ مهم، چگونگی مواجه شدن با این خطاهاست. اینکه آن‌ها را درست کنیم و رهایشان کنیم یا اینکه هر چه می‌توانیم از آن‌ها یاد بگیریم تا جلوی دوباره رخ دادنشان یا حتی رخ دادن خطاهای دیگر را بگیریم.جناب گوگل از این خطاها به‌عنوان incident یاد می‌کند و می‌گوید وقتی حادثه‌ای رخ می‌دهد، ابتدا افراد مربوط به سرویس یا سیستم، آن را به حالت قبلی بدون خطا برمی‌گردانند و سپس، جلسه‌ای با عنوان «پست‌مرتم» تشکیل می‌شود که افراد ذی‌نفع آن سرویس در آن حضور دارند تا دلایل اصلی حادثه،‌ کارهایی که انجام شده تا درست شود و... مشخص و مکتوب شود.با انگشت نشان دادن ممنوع!نکتۀ مهم این است که این جلسه‌ها به‌عنوان یک فرهنگ در گوگل به blame-free postmortem culture معروف است. یعنی کسی حق ندارد دیگران را سرزنش کند یا فرد خاصی را به‌عنوان مسبب خطا نشان دهد؛ بلکه همه به‌دنبال روال غلطی هستند که باعث این اتفاق شده است تا آن را درست کرده، از تکرار مجدد آن جلوگیری کنند.اینجا دو جمله از یک فرد دخیل با سیستم را می‌نویسم و با هم مقایسه می‌کنم:این سیستم بک‌اند واقعاً افتضاح است! در چند هفتۀ گذشته بارها پایین آمده است و اگر اوضاع این‌‌گونه پیش برود، خودم آن را از اول می‌نویسم...در چند هفتۀ اخیر، چند بار سیستم بک‌اند پایین آمده است. شاید بازنویسی این سیستم کمک کند که از این اتفاق‌ها جلوگیری شود. اگر این کار را بکنیم، on-callهای بعدی نیز خوش‌حال خواهند بود. :)تفاوت دو جملۀ بالا کاملاً ملموس است. مشخص است که هرکدام چه جو منفی و مثبتی را ایجاد می‌کند. اصلاً اینکه این جلسات blame-free باشند، خودش چالش است و به تمرین بسیار نیاز دارد.ابتدا کمی جزئی‌تر می‌گوییم که چه زمانی incident رخ داده است؟از اتفاق‌های زیر به‌عنوان incident یاد می‌شود:هر اتفاقی که کاربر احساسش کند!‌ چه پایین آمدن سیستم و چه تجاوز کردن یک متریک مانند latency از یک مقدار معین؛اگر داده‌ای از دست برود؛اگر کسی که on-call است، مجبور شود مداخله کند؛یک زمان خاص که برخی آستانه‌ها رد شده باشند؛کشف حادثۀ دستی (یعنی خطای مانیتورینگ).این موارد کاملاً کلی هستند و شاید حتی برای یک سازمان یکی از این‌ها مهم نباشد و به‌جای آن مورد دیگری مطرح شود. نکته در ماهیت این موارد نیست؛‌ بلکه در وجود آن‌هاست. یعنی حتماً باید از قبل برای یک سرویس مشخص باشد که اگر چه اتفاقی بیفتد، یک incident تلقی می‌شود و باید برایش جلسۀ پست‌مرتم برگزار شود.خود گوگل فرهنگ‌های جذابی برای این جلسات پست‌مرتم دارد:انتخاب پست‌مرتم ماه و تقدیر از آن؛گروه‌های پست‌مرتم‌خوانی که بحث‌های مربوط به این جلسات در آنجا رخ می‌دهد.در ادامه، به ساختار و مناسک جلسه‌های پست‌مرتم می‌پردازیم:یک Template از داکیومنت را با هم بررسی می‌کنیم:ـ تاریخ وقوع؛ـ نویسندگان؛ـ وضعیت فعلی: وضعیتی که سرویس در حال حاضر در آن قرار دارد؛ـ خلاصۀ حادثه؛ـ تأثیر حادثۀ مزبور: مثلاً n کاربر نتوانستند از ما سرویس بگیرند؛ـ دلایل ریشه‌ای: چه چیزهایی باعث این حادثه شد. نکتۀ مهم این است که این دلایل باید قابلیت ایجاد مجدد را داشته باشند؛ـ چگونگی اطلاع: مثلا سرویس Alerting بالا رفتن Latency را هشدار داد و مهندس on-call وارد عمل شد؛ـ ابعاد حادثه: اینکه حادثه در چه حدی بزرگ یا کوچک بوده است؛ـ کارهایی که باید انجام شود: برای اینکه این حادثه یا حوادث مشابه آن دیگر تکرار نشود، چه کسی چه کاری را انجام دهد (کارهای مختلف به افراد مختلف اساین می‌شوند).ـ درس‌هایی که آموختیم:در این قسمت باید به این سؤالات جواب داده شود:ـ نقاط قوتمان کجا بود؟ـ کجا ضعف داشتیم؟ـ کجا خوش‌شانس بودیم؟و در نهایت، یک تایم‌لاین با تاریخ و ساعت از کل اتفاق شرح داده می‌شود.شاید این جلسات در بسیاری از سازمان‌ها نه به‌عنوان پست‌مرتم، بلکه با عنوان‌های دیگر برگزار شوند.ـ حالا سؤال این است که آیا همۀ این مناسک باید انجام شوند؟به قول یکی از دوستان، بودن همین کارهای مشخص، باعث نظم و پیگیری بیشتر این جلسه‌ها می‌شود و در نهایت هم، تأثیر آن‌ها را بیشتر می‌کند.برای تجربه بیشتر، می‌توان نمونه جلسات پروژ‌ه‌های متن‌باز دنیا را بررسی کرد. مانند این مثال از پروژه گیت‌لب:https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/4113خب، این بخش هم تمام شد و در بخش بعدی به سراغ فصل Monitoring Distributed Systems می‌رویم ان‌شاءالله.

ماجرای کوبرنتیز و اعلام عدم پشتیبانی از Docker از نسخه بعد!

Behnam Alizadeh — Thu, 03 Dec 2020 16:25:35 +0330

از دیروز ۲ دسامبر خبری اومده که باعث تعجب خیلی‌ها توی توئیتر و لینکدین شده. خبر اینه:Kubernetes is deprecating Docker as a container runtime after v1.20برداشت‌های ناقص از این خبر باعث شده خیلی‌ها نگران وضعیت سرویس‌هاشون بشن. سعی کردم تو این متن مختصر و شفاف توضیح بدم دقیقا چه اتفاقی قراره بیافته. در کل خیلی جای نگرانی نیست :)دعوا سر چیه؟ :)- سوال اساسی: ما همچنان میتونیم سرویس هامون رو با Dockerfile بسازیم و از ایمیج هاش تو کوبر استفاده کنیم؟بله همچنان می‌تونیم و در آینده نیز مشکلی نیست :) پس داستان چیه؟برای پاسخ مشروح به ادامه متن توجه بفرمایید :)۱- موضوع از اینجا شروع میشه، «CRI چیه؟» (داخل پرانتز بگم کل دعوا سر همین CRIعه)کوبر برای بخش‌های مختلف خودش مثل «مدیریت شبکه» یا «مدیریت کانتینرها» نمیاد خودش همه چی رو پیاده‌سازی کنه، به‌جاش چیکار می‌کنه؟ میاد یه سری استاندارد تعریف می‌کنه و هر شخص مستقلی می‌تونه پیاده‌سازی خودش رو برای اون استاندارد داشته باشه و توی کوبر استفاده کنه. مثلا برای شبکه کوبر CNI یا Container Network Interface رو تعریف میکنه و کلی ملت میان پیاده‌سازی های مختلف رو بر اساس این CNI انجام می‌دن مثل calico flannel، و هرکسی بین گزینه‌های موجود یکی رو برای کلاسترش انتخاب میکنه.برای اجرای کانتینر هم داستان همینه، کوبر اومده CRI یا Container Runtime Interface رو مشخص کرده و بقیه میان پیاده‌سازی می‌کنن. الان چندتا گزینه برای مدیریت اجرای کانتینر توی محیط کوبر وجود داره که سه تا از معروف‌ترین‌شون ایناست:Dockercontainerd CRI-Oانواع CR هایی که CNCF معرفی کرده۲- این سه تا چیکار میکنن؟این سرویس‌ها مسئول اجرای کانتینر توی کلاستر کوبر هستن. یعنی وقتی دولوپر کدش رو زد و ایمیج دلخواهش رو ساخت، یکی تو کوبر باید باشه بره این ایمیج‌ها رو pull کنه و از روش کانتینر بسازه، پراسسش رو اجرا کنه و کلی کارهای جذاب دیگه :)، توی کلاستر کوبر این وظایف با kubelet هست اما kubelet توی لایه‌های پایین‌تر از پیاده سازی‌های مختلف که طبق CRI هستن استفاده می‌کنه مثل docker، containerd و cri-o.۳- الان دقیقا کوبر چیو میخواد دپریکیت کنه؟کوبر میگه من از نسخه 1.23 به بعد دیگه Docker رو به عنوان CRI قبول ندارم! و پیشنهاد کرده برید از اون دوتای دیگه استفاده کنین.از نسخه 1.20 وقتی kubelet میاد بالا اگه CRI استفاده شده داکر باشه یه deprecation warning میده اما همچنان اجازه میده داکر اجرا بشه. از نسخه 1.23 یعنی اواخر 2021 دیگه کلا اجازه‌ی اجراشم نمیده.۴- مشکل کوبر با داکر چیه؟داکر یه چیز خیلی خوبه و کلی کارها رو راحت کرده. همچنان هم تا سال‌ها قطعا یکی از پرکاربردترین تکنولوژی‌ها توی استک IT خواهد بود.داکر مجموعه‌ای از امکانات رو کنار هم جمع کرده و بصورت کاملا user friendly و stable در اختیار کاربرا گذاشته، یکی از این امکانات همون containerd خودمونه :) یعنی داکر خودش برای مدیریت کانتینرها از containerd استفاده میکنه. داکر کلی چیز میز جذاب و مفید دیگه رو با یه UX فوق‌العاده کنار هم جمع کرده، توسعه و دپلوی رو راحت کرده و خلاصه دنیا رو راحت کرده اما برای انسان ها نه کوبرنتیز!«داکر اساسا برای اینکه CRI خوبی درون کوبر باشه طراحی نشده!» با اینکه خودش از containerd استفاده میکنه اما وقتی کوبر میخواد از داکر استفاده کنه یه سری مشکلاتی داره که کوبری‌ها مجبور شدن برن یه سرویس دیگه به اسم Dockershim بنویسن و به kubelet اضافه کنن تا بتونن از داکر استفاده کنن :|الان کوبر میگه خب چه کاریه! من برای استفاده از containerd باید لقمه رو دور سرم بچرخونم و یه سرویس دیگه بنویسم که خودش پیچیدگی رو زیاد میکنه و خطر ناپایداری برای کل سیستم داره. لذا تصمیم گرفته دیگه Docker رو به عنوان CRI نپذیره.یعنی CRI اگه داکر باشه روند اجرا اینجوری میشه:kubelet -> dockershim -> docker -> containerdدر صورتیکه داکر نباشه روند اجرای cri توی کلاستر کوبر اینجوری میشه:kubelet -> containerdدر واقع اصل داستان اینه:«کوبر میخواد dockershim رو از توی kubelet حذف کنه. این یعنی دیگه داکر نمیتونه به عنوان CRI توی کوبر استفاده بشه.»(حدودا دو ماهه این قضیه باز شده و الان دیگه اعلام رسمی شده که از نسخه 1.23 این اتفاق می افته)۵- برگردیم به سوال اساسی: ما همچنان میتونیم سرویس هامون رو با Dockerfile بسازیم و از ایمیج هاش تو کوبر استفاده کنیم؟ بله. چرا؟ایمیج‌هایی که داکر می‌سازه اینجوری نیست که Docker-specific باشه و فقط خودش بفهمه چی ساخته. ایمیج‌های داکر منطبق با ساختار OCI (Open Container Initiative) image هستن، و این ساختار رو اون دوتا یعنی containerd و CRI-O هم پشتیبانی می‌کنن. لذا همچنان میشه مثل قبل کد زد و با Dockerfile ایمیج ساخت و تو کوبر اجراش کرد. دوشواری نداره.۶- یعنی کلا آب از آب تکون نمیخوره؟ مگه میشه :/با تغییر CRI -که سال‌هاست تو اغلب کلاسترها Docker هست- حتما یه سری مشکلاتی رخ میده ولی خیلی حاد نیستن. مثلا اگه کسی برای Docker in Docker توی کوبرش مستقیم از var/run/docker.sock/ استفاده کرده باشه قاعدتا به مشکل میخوره و باید بره سراغ سولوشن‌های دیگه‌ای مثل kaniko, img یا buildah.امیدوارم مطلب مفیدی بوده باشه و از خوندنش لذت برده باشیداگه مطلب رو دوست داشتید ❤️ کنید و نظرتون رو کامنت کنید. ری اکشن شما مزید ابتهاج خاطر نویسنده و دیگر خوانندگان است :)منبع اصلی:Do not Panic: Kubernetes and Docker

Site Reliability Engineering

محمد اژدری — Sat, 21 Nov 2020 18:48:51 +0330

ما در تیم سعدی، از تیم‌های قسمت پیام‌رسانی «بله»، جلسات همخوانی کتاب Site Reliability Engineering را برگزار می‌کنیم. اینجا خلاصۀ مطالبی را که می‌خوانیم و یاد می‌گیریم، به‌مرور می‌نویسم.این کتاب را گوگل منتشر کرده است و می‌توان آن را به‌صورت رایگان در لینک بالا مطالعه کرد.(برای اختصار، SRE را هم به‌جای Site Reliability Engineering و هم Site Reliability Engineer به کار می‌بریم. اینکه کجا کدام است، به نظر واضح خواهد بود.)کتاب به‌صورت کلی دربارۀ SRE حرف می‌زند؛ ولی لزوماً به شرح یک عنوان شغلی نمی‌پردازد و شامل توضیح فرهنگ‌های سازمانی و کاری است که نهایتاً هدفش رسیدن به یک سیستم پایدار و مطمئن است.در این قسمت، به خلاصه بخش Introduction کتاب می‌پردازیم.متن را با این سؤال آغاز می‌کنیم: SRE کیست؟در یک جمله، فردی است که از صفر (تولد) تا صد (انتشار و نگهداری) یک نرم‌افزار حضور و نقش دارد. اسم این شغل زیاد واضح نیست و ممکن است افرادی که در این قسمت کار می‌کنند، واقعاً ندانند که کار و رسالتشان دقیقاً چیست.اما حالا کمی جزئی‌تر به بررسی کلمات این موقعیت شغلی می‌پردازیم:اول Engineer:‌ این اشخاص مهندس هستند و طبعاً مهارت‌های یک Computer Engineer و Computer scientist را دارند. یعنی توسعه و طراحی سرویس‌ها جزو کارهایشان است، یا توسعۀ ابزارهایی کمکی برای سایر مهندسان، ازجمله: لودبالانسینگ، بک‌آپ‌گیری و ... .دوم Reliability: مهم‌ترین ویژگی هر محصول، این است که بتوان به آن اعتماد کرد و اگر این ویژگی را نداشته باشد، عملاً به درد نمی‌خورد و موفق هم نمی‌شود. بنابراین، SREها بر این موضوع تمرکز ویژه‌ای دارند و به نوعی اصلی‌ترین و اولویت‌دارترین وظیفۀ خودشان را حفظ reliability سرویس می‌دانند و اگر به این هدف مهم رسیدند، سراغ کارهای دیگر می‌روند.سوم Site: منظور از این کلمه در واقع Service است و دلیل انتخاب این اسم برایش، این است که در اوایل هدف فقط سایت سرچ google.com بوده است؛ به همین دلیل، این اسم مانده است و تغییرش هم نداده‌اند! :) نهایتاً منظور از سرویس همان نرم‌افزارهایی است که در یک سازمان در حال اجرا هستند، مثلاً در گوگل، یوتیوب، م‍پ و... .حالا این سؤال پیش می‌آید که آیا همیشه و در همۀ شرکت‌ها این موقعیت شغلی وجود دارد و باید وجود داشته باشد؟ جواب خیر است. زیرا با توجه به حجم کار و عمر شرکت، ممکن است اصلاً چنین پوزیشنی (position) به‌طور خاص وجود نداشته باشد؛ اما همیشه افرادی هستند که این کارها را انجام می‌دهند و اگر برای آن‌ها اسم بگذاریم و کمی منظمشان کنیم، می‌شوند SRE.از رسالت‌های اصلی این افراد، حذف کردن پروسه‌های انسانی از کارهاست. آن‌ها تا جایی که می‌توانند، همه‌چیز را خودکار می‌کنند و به دست برنامه‌های کامپیوتری می‌سپارند. دلیلش هم مشخص است. یک انسان هرچقدر هم حرفه‌ای باشد، اشتباه می‌کند و ممکن است همین اشتباهش پیامدهای بدی را به همراه داشته باشد.داستان مارگارتدر زمینۀ خودکار‌ کردن، کتاب یک داستان واقعی را از ناسا تعریف می‌کند.فردی به نام مارگارت در ناسا مهندس بوده و کار می‌کرده است. یک روز بچۀ خردسالش را با خودش به سر کار می‌برد. آن زمان در سفینه‌های ارسال فضانوردان به فضا، دکمه‌ای وجود داشت که همۀ اطلاعات برگشت را پاک می‌کرد و برگرداندن آن‌ها به مدارک بخصوصی نیاز داشت.این بچه به‌صورت اتفاقی آن دکمه را در سفینه‌ای که در حال ساخت بوده، می‌زند و این اطلاعات پاک می‌شود. همان‌جا زنگ خطری برای مارگارت به صدا درمی‌آید که مبادا در یک سفر واقعی، این اتفاق بیفتد و فضانوردی که سوار سفینه است، اشتباهی آن دکمه را بزند! بعد این ایده را مطرح می‌کند که این دکمه از دید و دسترس فضانوردان خارج شود تا آن‌ها مرتکب این خطا نشوند؛اما با این ایدۀ مارگارت مخالفت می‌شود. به این دلیل که می‌گویند: «فضانوردان ما آن‌قدر حرفه‌ای هستند که بدانند نباید این دکمه را بزنند!» نهایتاً با اصرارهای وی، یک داکیومنت (document) اضافه می‌شود مبنی بر اینکه اگر به هر دلیلی این دکمه فشار داده شد، برای برگرداندن اطلاعات چه اقداماتی لازم است.نهایتاً در اولین سفری که با این سفینه انجام می‌شود، یکی از همین فضانوردان حرفه‌ای (!)‌ این دکمه را به‌اشتباه فشار می‌دهد و اطلاعات برگشت پاک می‌شود. آن‌ها با مراجعه به همان داکیومنت می‌توانند این خطر را دفع کنند و به زمین برگردند.نتیجۀ داستان واضح است!انسان هرچقدر هم که حرفه‌ای باشد، جایزالخطاست و کسی هم حق ندارد سرزنشش کند. چیزی که برای جلوگیری از این خطا لازم است، از بین بردن نقش انسان در برخی کارهای تکراری است که به هیچ خلاقیت خاصی نیاز ندارند.روش SysAdmin در مدیریت نرم‌افزاراول باید به این سؤال جواب بدهیم که sysAdmin کیست؟ کسانی که کامپوننت‌های مختلف نرم‌افزار را به هم ملحق می‌کنند و نهایتاً سیستم را اجرا می‌کنند.کارهای این افراد بیشتر در زمینۀ راه‌اندازی سیستم است و پاسخ‌ دادن به آپدیت‌هایی که از تیم‌های توسعه می‌آید و خطاهایی که رخ می‌دهد.هرچقدر که لود و استفاده از نرم‌افزار زیاد شود، باید sysAdminهای بیشتری استخدام شوند؛ چراکه لزوماً توسعه‌دهندگان نرم‌افزار، توانایی انجام و دسترسی به تسک‌های این افراد را ندارند و این جایگاه، نیازمند برخی مهارت‌های خاص است.این شیوه همانند همه‌چیز در دنیا، مزایا و معایبی دارد:مزیت‌هامزیتی که این شیوه دارد، جاافتاده شدن آن است. یعنی در دنیای متن‌باز امروزی، برای اکثر کارهای این جایگاه، ابزار خیلی مفیدی توسعه داده شده است و احتمالاً همه‌چیز را می‌توان خیلی سرراست کنار هم چید و به راه انداخت.معایبمعایب این روش را می‌توان در دو روش مستقیم و غیرمستقیم تقسیم‌بندی کرد:مستقیم: همان‌طور که اشاره شد، با اضافه شدن لود و استفاده از سیستم، لازم است افراد بیشتری برای سازمان در این جایگاه استخدام شوند که خب، هزینه ایجاد می‌شود.غیر مسقیم: این مشکل که شاید خیلی ظریف و اتفاقاً خیلی مهم‌تر از مشکل مستقیم است، تعارض منافع تیم توسعه و دوآپس است.تیم عملیات همیشه می‌خواهد یک سیستم پایدار و مطمئن داشته باشد؛ ولی تیم توسعه از طرف دیگر، در تلاش برای توسعه و انتشار نسخه‌های پی‌درپی در محیط عملیاتی است. انتشار و به‌روزرسانی ذاتاً پایداری سیستم را کمتر می‌کند.این عین جملۀ کتاب دربارۀ این تعارض منافع است:We want to launch anything, any time, without hindrance "versus" We won’t want to ever change anything in the system once it works.بنابراین تیم عملیات در برابر این تغییرات مقاومت می‌کنند. مثلاً شرایطی را وضع می‌کنند که قبل از هر انتشار باید انجام شود و... .اما رویکرد SRE این موضوع را تا حد زیادی حل می‌کند. چگونه؟همان‌طور که گفتیم، یک SRE در واقع کسی است که هم مهارت‌های Dev-Opsی و هم مهارت‌های مهندسی دارد و هم در توسعه و هم در نگهداری نرم‌افزار نقش دارد؛ اما گوگل می‌گوید این دو به‌طور مساوی انجام می‌شود. یعنی یک SRE، پنجاه درصد وقت خود را برای کارهای عملیاتی و بقیه را برای توسعۀ نرم‌افزار می‌گذارد.یعنی اگر کارهای عملیاتی به‌قدری زیاد شد که این پنجاه درصد را رد کرد، آن کارها به توسعه‌دهنده‌ها اساین (assign) می‌شود و همین باعث می‌شود که آن‌ها هم با این‌جور کارها درگیر شوند و همین تعارض در ذهنشان کم‌رنگ‌تر بشود.یک مزیت این روش تولید یک سرویس پایدار است، چون کسی که تفکر و مهارت عملیاتی دارد، در توسعۀ آن نقش داشته است.برخی استانداردها را این‌گونه بیان می‌کند که وقتی یک SRE، هشت تا دوازده ساعت on-call است، حداکثر دو و حداقل یک ایونت برایش اساین شود.حالا ایونت (event) چیست؟ منظور خطایی است که رخ می‌دهد یا اتفاقی غیرعادی است که می‌افتد و باید با در نظر گرفتن اولویت‌ها درست شود. مثلاً یک سرویس داون (down) می‌شود یا لیتنسی (latency) یک سرویس افزایش پیدا می‌کند و... .حالا بعد از دریافت این ایونت (event)، آن شخص موظف است پس از رفع آن، جلسۀ پست‌مرتمی (postmortem) برایش تشکیل دهد و مکتوبش کند.در چه شرایطی جلسه پست‌مرتم برگزار می‌شود؟وقتی اتقاق بدی می‌افتد! حالا چه این اتفاق را سیستم آلرت، هشدار داده باشد چه انسانی فهمیده باشد. اتفاقاً این دومی خیلی مهم‌تر است؛ زیرا این اتفاق گپی در سیستم نظارت و هشدار شما را نشان می‌دهد که آن هم باید پیدا شود.فرهنگ خوبی در گوگل وجود دارد که وقتی اتفاقی می‌افتد، کسی دنبال مقصر آن نیست؛ بلکه جلسه‌ای تشکیل می‌شود که افراد ذی‌نفع آن محصول یا سرویس در آن حضور دارند و دلیل ریشه‌ای آن پیدا و مطرح می‌شود و کارهایی به افراد مربوط اساین می‌شود که دیگر این اتفاق نیفتد.اصطلاح قشنگی که گوگل برای این فرهنگ به کار می‌برد، blame-free postmortem culture است.یعنی قرار نیست کسی سرزنش شود و اصلاً کسی هم حق ندارد یکی را با انگشت نشان دهد که فلانی مسبب این اتفاق شد؛ بلکه باید دنبال درست کردن ساختاری باشد که از تکرارش جلوگیری شود.یک فصل از کتاب به پست‌مرتم اشاره می‌کند که ان‌شاءالله در نوشتۀ‌ بعدی به آن خواهم پرداخت.حالا آن‌قدر گفتیم، ولی خود گوگل اعتراف می‌کند که چون تفکر SRE تفکر جدیدی است، هنوز قابلیت توسعۀ فرهنگی و فنی دارد و اتفاقاً این کار در حال انجام شدن است! اینکه این افراد چه مهارت‌هایی داشته باشند، چگونه جذب بشوند و چگونه با سایر افراد شرکت رابطه داشته باشند، چالش‌هایی است که یک سازمان دارای این فرهنگ با آن روبه‌روست.در همین فرهنگ رابطۀ تیم عملیات و توسعه، گوگل در این تفکر یک فرهنگ قشنگ دیگر هم دارد و آن بودجۀ ارور است. یعنی اگر در دسترس بودن یک متریک برای سرویس تعریف شود، لزوماً هدف آن را ۱۰۰ نمی‌گذارند و مقداری از آن‌را، مثلاً ۰.۰۱ به‌عنوان بودجه‌ای در نظر می‌گیرند که تیم توسعه حق دارد در سیستم خطا ایجاد کند و این در دسترس بودن را پایین بیاورد.اما حالا چرا هدف ۱۰۰ نیست؟ خود گوگل که سرویس‌های همیشه پایداری دارد، می‌گوید که وقتی اینترنت و شبکه و همه راه‌هایی که کاربر شما باید طی کند تا به سرویس شما برسد، ۱۰۰ نیست بلکه خیلی کمتر است، ۱۰۰ بودن شما را کسی متوجه نمی‌شود!این بودجه در یک محصول با مشورت مدیر محصول و بر اساس لاجیک و بیزینس آن و اینکه کاربر در چه حالتی خوش‌حال است، تعریف می‌شود.این خلاصه اینجا پایان می‌یابد و امیدوارم برایتان مفید باشد.امیدوارم در نوشتۀ بعدی سراغ جلسۀ پست‌مرتم بروم و این فصل از کتاب را برایتان خلاصه کنم.

اگر برنامه‌نویس هستید، این ۱۰ پیج را دنبال کنید!

پریا اطمینان مقدم | paria-etminan | Paria Etminan Moghadam@ — Mon, 19 Oct 2020 12:58:50 +0330

https://www.youtube.com/watch?v=IY7EsTnUSxY «هرکسی باید برنامه‌نویسی یاد بگیرد؛ زیرا طرز درست فکر کردن را به شما یاد می‌دهد!»این را من نمی‌گویم بلکه خدابیامرز استیو جابز در یکی از مصاحبه‌هایش می‌گوید. من فقط این حرف را با جان‌ودل حس کردم. وقتی برنامه‌نویسی یاد می‌گیرید (فرقی ندارد چه زبانی) مغر به‌طور خودکار یاد می‌گیرد از زوایای مختلف یک مسئله را بررسی کند.کمی از نیمهٔ احساسی مغر فاصله می‌گیرید و صورت‌مسئله را همچون یک مکعب روبیک بررسی می‌کنید.اما مکعب‌های روبیک روزبه‌روز پیچیده‌تر می‌شوند، بُعدهای مختلفی به خود می‌گیرند، گاهی اوقات از آن شکل سنتی خود فاصله می‌گیرند و چالشی را پیش روی شما می‌گذارند.برنامه‌نویسی عجیب با این مفاهیم گره‌خورده است، ناگهان باگی از ناکجاآباد پیدا می‌شود که آموخته‌های شما راه‌حلی برایش پیدا نمی‌کند؛ پس باید به دنبال منابعی بگردید که دانش‌تان را به‌روز نگه دارد!‍بعضی از این منابع را می‌توانید به‌راحتی در لینکدین بیابید. در ادامه با افرادی آشنا می‌شوید که از پس فیلترهای مختلفی از جمله تیم محتوا و برنامه‌نویسی خود لینکدین عبور کردند تا اسمشان در لیستی با نام LinkedIn Top Voices 2019 قرار گیرد.Chip Huyenچیپ هوین در صفحهٔ لینکدینش دربارهٔ چه موضوعاتی صحبت می‌کند؟چیپ معمولاً به شرکت‌ها کمک می‌کند تا تحقیقات مربوط به هوش مصنوعی را به تولید برسانند.پست‌های چیپ بیشتر به جنبه‌های مهندسی کامپیوتر به‌ویژه نکات پایتون، اشکال‌زدایی و زبان ماشین می‌پردازد.صفحهٔ لینکدین Chip HuyenVictor Renteaویکتور رنتا در صفحهٔ لینکدینش دربارهٔ چه موضوعاتی صحبت می‌کند؟او می‌گوید: «هدف اصلی که دارد، تغییر طرز تفکر توسعه‌دهندگان نرم‌افزار است.»محتواهای ویکتور شامل کتاب‌ها، کاریکاتورها و تجربه‌هایی‌ست که با عنوان نقل‌قول از آن‌ها یاد می‌کند. مبحثی که او بیشتر به آن می‌پردازد، زبان کوتلین است.صفحهٔ لینکدین Victor RenteaMartha Sharpeمارتا شارپ در لینکدین از سفر خود به‌عنوان یک توسعه‌دهندهٔ وب با شما سخن می‌گوید. مارتا اکثر مطالبی را که در صفحهٔ خود منتشر می‌کند، خودآموز یاد گرفته و بارها آن‌ها را آزمایش کرده است. مارتا در صفحهٔ لینکدین خود بیشتر به زبان جاوا اسکریپت می‌پردازد.صفحهٔ لینکدین Martha SharpeRobert Sweeneyرابرت سوئینی تجربهٔ کار با شرکت‌هایی همچون نتفلیکس و ماکروسافت را دارد و داستان‌هایی را از همین تجربه‌ها با شما به اشتراک می‌گذارد.بیشترین موضوعی که رابرت در صفحهٔ لینکدین خود به آن‌ها می‌پردازد، شامل مبحث PTO در مقابل DTO است.صفحهٔ لینکدین Robert SweeneyParul Pandeyاگر شما به مباحث بیگ دیتا علاقه دارید، قطعاً پست‌های پارول پندی برای شما منابع با‌ارزشی محسوب می‌شوند.اکثر پست‌های پارول شامل مباحثی مانند کتابخانهٔ Pandas Python و TensorFlow است. در کنار این موضوعات، با دنبال کردن پاول می‌توانید به موضوعات دیگری مانند هوش مصنوعی و زبان ماشین نیز بپردازید.صفحهٔ لینکدین Parul PandeyMark Moeykensمارک مویکنز در لینکدین با شما از توسعهٔ اپلیکیشن‌های تلفن همراه سخن می‌گوید و عمدهٔ پست‌هایش آموزشی‌ست.مارک با تا‌ٔکید بر IOS و Swift نکات آموزشی مهمی در مورد نحوهٔ سازماندهی، بهینه‌سازی کدها و به‌روزرسانی به اشتراک می‌گذارد.صفحهٔ لینکدین Mark MoeykensPatrick Shyuپاتریک شیو به‌عنوان یکی از رهبرهای سابق گوگل، به سراغ مبحثی رفته است که سؤال برنامه‌نویسان فراوانی‌ست!اکثر محتواهای پاتریک در قالب ویدئوهای طنز و با موضوع درآمد قشر زحمت‌کش برنامه‌نویس است!صفحهٔ لینکدین Patrick ShyuNate Ebelنیت ایبل، به‌عنوان یک توسعه‌دهندهٔ اپلیکیشن‌های تلفن همراه و به‌ویژه اپلیکیشن‌های اندروید، دائم از به‌روزرسانی‌ها و اتفاقاتی که در حین این تغییرات اتفاق افتاده است، با شما سخن می‌گوید و با بردباری پاسخ پرسش‌های شما را می‌دهد.موضوعاتی که نیل بیشتر به آن‌ها می‌پردازد شامل Kotlin ،JSON و Jetpack می‌شود.صفحهٔ لینکدین Nate EbelKathleen Vignosکاتلین ویگنوس به‌عنوان یکی از مهندس‌های فناوری توئیتر، دربارهٔ موضوعی تحت عنوان the hard transition با شما در صفحهٔ لینکدینش سخن می‌گوید.(توضیحات کم من رو در این بخش به بزرگی خودتان ببخشید، اندک اطلاعاتی در این زمینه دارم)صفحهٔ لینکدین Kathleen VignosNatsai Ndebeleناتسای ندبله یکی از تأثیرگذارترین زنان آفریقایی تباری است که تمام سعی خود را می‌کند تا راهی را برای همتایان خود بسازد.صفحهٔ لینکدین Natsai Ndebeleشاید نفر بعدی لیست LinkedIn Top Voices 2020 شما باشید!با فعالیت مستمر در لینکدین می‌توانید از نام خود یک برند بسازید؛ پس لینکدین خود را فعال نگه‌دارید.شاید با این کار نفر بعدی لیست LinkedIn Top Voices شما باشید.

کاش کسی جایی مسئله‌ام را درک کرده باشد؛ آنگاه راهکارش را دوست خواهم داشت!

مصطفی رادمرد — Tue, 06 Oct 2020 16:43:06 +0330

به نام خدانقل‌قولی منتسب به آلبرت اینشتین هست که احتمالاً شنیده‌اید: «اگر یک ساعت وقت داشته باشم تا کرۀ زمین را نجات بدهم، ۵۵ دقیقه از وقتم را صرف تعریف مسئله می‌کنم و پنج دقیقه را صرف حل آن.» گرچه به صحت انتساب آن به اینشتین اطمینانی نیست، ولی نمی‌توان انکار کرد که در بسیاری مواقع اگر مسئله به‌درستی طرح شود، اولاً راهکارِ مناسب‌تر یافت می‌شود، ثانیاً سریع‌تر و کم‌هزینه‌تر به‌دست می‌آید.نکتۀ جدیدی نداشت، درست است؟ اما تقریباً در همۀ شرکت‌های نرم‌افزاری‌ای که دیده‌ام، در برخی مراحل توسعه یا ترویج محصول، همین نکتۀ ساده نادیده گرفته می‌شود. به‌خصوص در طراحی محصول، در عین اینکه باور داریم مشتری‌مدار هستیم و باید نیاز مشتریان را برآورده کنیم، بارها و بارها پیش می‌آید که ناخودآگاه خودمان را دانای قطعی مسئله و راهکار می‌دانیم؛ گویی مسئلۀ مشتری و راهکار مطلوب او را بهتر از خودش می‌دانیم، از تعریف مسئله عبور می‌کنیم و سریع به سراغ پیاده‌سازی راهکاری می‌رویم که آن را بسیار کاربردی، ضروری، خلاقانه یا باحال می‌دانیم.قسمت عمده‌ای از ادبیات چابکی، تحول دیجیتال، تفکر طراحی و مفاهیم مشابه، تغییر همین مدل ذهنی است که آقا یا خانم‌جان، ما نمی‌دانیم! و حتی نمی‌دانیم که نمی‌دانیم! باید پیش‌فرض‌ها را کنار بگذاریم و با آزمایش و یادگیری مستمر و انباشت شناخت از مشتری، قدم‌به‌قدم جلو برویم.همان‌طور که می‌دانید، طراحی محصول صرفاً به معنای زیباتر کردن محصول نیست؛ بلکه فرایند شناخت مسئله و ارائۀ راه‌حل‌های مرتبط با مسئله است. ما به‌وسیلۀ طراحی، مشکلِ مشتری را حل می‌کنیم. پر واضح است که برای این کار لازم است در ابتدا مسئله و مشکل را از دیدگاه مشتری شناسایی و درک کنیم. همان‌طور که فرایند طراحی را تکرارپذیر می‌دانیم، مرحله تحقیق و پژوهش کاربر هم تکرارپذیر است.شاید درزمینۀ تحقیق کاربری، نویسندگان زبردست الگوی خوبی برای ما توسعه‌دهندگان محصولات دیجیتال باشند. اخیراً مطلبی دربارۀ «آنا گاوالدا»، داستان‌نویس مشهور فرانسوی، می‌خواندم. فکر کردم چقدر محقق کاربری (user researcher) خوبی است! نویسنده‌های خوب بالقوه طراحان خوبی هستند، به‌دلیل دقت در مشاهدۀ رفتار مشتری، همدلی با او، شناخت نقاط درد او و درک احساساتش.گفته می‌شود وقتی گاوالدا می‌خواسته دربارۀ یک راننده‌کامیون ترانزیتی بنویسد، سراغ پمپ‌بنزین و تعمیرگاه می‌رفته، آن‌ها را زیرنظر می‌گرفته، با آن‌ها صحبت می‌کرده، دربارۀ جزئیات کوچک ازشان سؤال‌های مختلفی می‌کرده و از نکته‌هایی که می‌فهمیده، یادداشت برمی‌داشته است.آنا گاوالداخود گاوالدا می‌گوید: «با آدم‌ها برخورد می‌کنم. آن‌ها را نگاه می‌کنم. از آن‌ها می‌پرسم صبح‌ها چه ساعتی از خواب بیدار می‌شوند، برای زندگی‌شان چه می‌کنند و مثلاً دسر چه دوست دارند. بعد به آن‌ها فکر می‌کنم. تمام‌مدت فکر می‌کنم. از نو به چهره‌شان، دست‌هاشان حتی به رنگ جوراب‌هایشان دقیق می‌شوم. ساعت‌ها نه، سال‌ها به آن‌ها فکر می‌کنم و سپس روزی، می‌کوشم درباره‌شان بنویسم.»عالی نیست که این‌گونه برای خلق محصولش، ابتدا تحقیق میدانی می‌کرده است؟! آیا رواست که ما در خلق محصولات پرطمطراقمان، این‌گونه نباشیم؟! پس از همین امروز آنا گاوالدای محصول خود باشیم!راستی، اگر به خواندن چند روایت کوتاه و دقیق از زندگی عاطفی آدم‌ها با قلمی لطیف علاقه‌مند هستید، توصیه می‌کنم کتاب‌های کاش کسی جایی منتظرم باشد و دوستش داشتم را از دست ندهید.

برای به‌دست آوردن سهم بازار، ارزان قیمت‌گذاری کنیم یا برای ایجاد برندی ممتاز، گران قیمت‌گذاری کنیم؟

amirmashayekhi — Sat, 20 Jun 2020 23:04:25 +0430

به نام خداپاسخ این سؤال بسته به استراتژی قیمت‌گذاری هر کسب‌و‌کار متفاوت است.اما استراتژی قیمت‌گذاری چیست؟ به بیان ساده، برنامۀ درآمدزایی کوتاه‌مدت و بلندمدت شماست. استراتژی قیمت‌گذاری منطقی در بهترین حالت باید نیت شفاف، اهداف قابل سنجش و چارچوب زمانی برای اجرا داشته باشد.حال چطور می‌توان چنین استراتژی قیمت‌گذاری‌ای را تدوین کرد؟چهار عنصر سازنده استراتژی قیمت‌گذاری:1. تعیین اهداف روشنبدون اهداف روشن، استراتژی قیمت‌گذاری مؤثری وجود نخواهد داشت. هدف روشن و برجسته از پیش‌نیازهاست، چرا‌که اهداف متفاوت با اولویت یکسان ممکن است به استراتژی‌ها و اقدام‌های متناقضی منجر شوند. برای مثال وقتی بیشینه شدن سهم بازار به‌عنوان هدف قرار می‌گیرد، متفاوت است با زمانی که هدف، بیشینه کردن سود کلی است.حال باید دید کدام اهداف برای محصول جدید بیشترین اهمیت را دارند. درآمد؟ سهم بازار؟ سود کلی؟ حاشیۀ سود؟ ارزش طول عمر مشتری؟ میانگین درآمد به‌ازای هر واحد؟ یا مسئله‌ای دیگر؟ نکتۀ درخور توجه این است که در هر صورت همه را نمی‌توان همزمان بیشینه کرد! هنگام تعیین اهداف باید بده‌بستان‌های منطقی و زیادی انجام شود.به خاطر داشته باشید در این قسمت انتخاب تنها یک هدف شفاف از بین چند هدف مدنظر نیست، بلکه به نوعی ایجاد اولویتی منطقی با بده‌بستان‌هایی بر سر اهداف مدنظر است.مثلا در نمودار پایین که از مدیران ارشد یک شرکت خارجی خواسته شده با دادن امتیاز به هر هدف اولویت آن را مشخص کنند، میزان اختلاف و چالش هم‌تراز کردن آن به وضوح مشخص است.چالش اولویت‌بندی اهداف از سوی مدیران سازمان۲. انتخاب رویکرد مناسب قیمت‌گذاریبده‌بستان برای اهداف ضروری است، اما کافی نیست. اهداف و رویکرد قیمت‌گذاری باید هم‌راستا باشند. در مجموع سه رویکرد استراتژی قیمت‌گذاری به‌طور خلاصه توضیح داده شده است.بیشینه‌سازی (Maximization) : این استراتژی با رویکرد بیشینه‌سازی هدف (مثلا درآمد یا سود) در کوتاه‌مدت انجام می‌شود. در این استراتژی قیمت بهینه یعنی نقطه‌ای در منحنی کشش قیمت(در ادامه درباره این منحنی و نحوه ایجاد آن صحبت می‌کنیم) که در آن سود یا درآمد به مقدار بیشینه می‌رسد و به‌عنوان قیمت نهایی برای دوره‌ای کوتاه‌مدت مشخص می‌شود. معمولاً زمانی استراتژی بیشینه‌ساز انتخاب می‌شود که در تمایل مشتریان به پرداخت، اختلاف فاحشی دیده نشود. یا در مواقعی که ارزش ندارد برای دست‌یابی سریع به سهم بازار، درآمد یا سود کاهش یابد. به‌عبارت‌دیگر برای این شرکت‌ها قیمت کوتاه‌مدت بهینه با قیمت بلندمدت بهینه تفاوت چندانی ندارد.نفوذ (Penetration) : با این استراتژی، محصول به‌صورت آگاهانه کمتر از استراتژی بیشینه‌ساز قیمت‌گذاری می‌شود تا به‌سرعت سهم بیشتری از بازار را به‌دست آورد. این رویکرد در برخی بازارها به‌ویژه بازارهایی که اثر شبکه‌ای در آن‌ها غالب است یا بازارهایی که مشتریان به اولین برندی که انتخاب می‌کنند وفادار می‌مانند، بسیار اهمیت دارد. در این گونه بازارها شانس افزایش طول عمر مشتری از طریق فروش‌ها و بیش‌فروش‌های آتی وجود خواهد داشت. استراتژی نفوذ زمانی کارآمد است که قیمت‌ها در آینده و با چشم‌انداز معینی افزایش یابد.رویه‌گیری (Skimming) : این رویکرد ابتدا به مشتریانی با تمایل پرداخت بیشتر (پذیرندگان زودهنگام) خدمات ارائه می‌کند و در طول زمان به‌صورت قاعده‌مند قیمت‌ها کاهش می‌یابد و دیگر مشتریان (با تمایل پرداخت کمتر) جذب می‌شوند. قیمت اولیه در این رویکرد از قیمت رویکرد بیشینه‌ساز بیشتر است. این رویکرد به‌ویژه زمانی مناسب است که مشتریان زیادی حاضر باشند در ابتدا قیمتی بیشتر از دیگران برای محصول بپردازند.۳. تدوین اصول تعیین قیمتتصمیم‌گیری دربارۀ اصول تعیین قیمت، اجازه نمی‌دهد استراتژی قیمت‌گذاری از مسیر درست خارج شود و از واکنش‌های ناخودآگاه پس از عرضۀ محصول پیشگیری می‌کند. برای اصول تعیین قیمت باید پنج بخش عملیاتی در نظر گرفته شود:مدل درآمدزایی (نحوه دریافت هزینه مهم‌تر از قیمت است!) :به طور خلاصه مشتری چگونه هزینه محصول یا خدمت جدید را پرداخت کند. در واقع تبیین مدل درآمدزایی مطلوب می‌تواند به محصول و قیمتی که برای آن تعیین می‌شود، اهمیت داشته باشد که در موفقیت یا شکست محصول جدید بسیار تاثیرگذار است. از جمله موفق‌ترین مدل‌های اثبات‌شده می‌توان به مدل حق‌اشتراک، قیمت‌گذاری پویا، مزایده، فریمیوم و بسیاری از مدل‌های دیگر اشاره کرد. کدام مدل یا مدل های درآمدزایی برای محصول جدید مناسب است؟ آیا برای همۀ دسته‌های مشتریان مدل درآمدزایی یکسان است؟ مدل انتخاب‌شده در طول چرخۀ عمر محصول تغییر می‌کند؟تمایز قیمت: آیا قیمت قراراست متمایز ارائه شود. اگر اینطور است، عوامل متمایز‌کنندۀ قیمت چیست؟ مثلا همۀ قیمت‌ها در همۀ بخش‌ها در محدودۀ حداکثر بیست‌درصدی میانگین قیمت‌های رقبا ارائه می‌شوند.کف قیمت: درنظر گرفتن قیمتی برای محصول که قیمتی کمتر از آن هرگز توجیهی ندارد و علی‌القاعده کمتر از آن قیمت‌گذاری نمی‌شود.انتهای قیمت: به این معنی که انتهای قیمت‌ها برای محصول چطور تمام می‌شوند؟ برای نمونه رایج‌ترین روش‌های نوشتن انتهای قیمت ۰.۹۵، ۰.۹۹ و ۰.۵ هستند (مثلا برای عدد ۳۰، نمونه‌های ۲۹.۵، ۲۹.۹۹ و ۲۹.۹۵) که البته در بازارهای B2B بهتر است از اعداد کامل استفاده شود.افزایش قیمت: آیا قرار است قیمت با گذشت زمان افزایش یابد؟ اگر بله، چقدر و در چه دوره‌های زمانی؟۴. تدوین اصولی برای واکنشعلاوه بر قیمت عرضۀ محصول، باید دربارۀ واکنش‌های خود پس از ورود محصول به بازار هم برنامه‌ریزی کرد. برنامه‌ریزی برای واکنش‌ها تا حد زیادی شبیه شطرنج بازی کردن و در نظر داشتن چند حرکت بعد است.دو نوع واکنش قیمتی وجود دارد:واکنش بر نحوۀ رفتار مشتریان(Promotional Reactions) : در این قسمت باید مشخص شود که آیا قرار است محصول ترویج شود یا خیر؟ اگر بله، مشتریان ترویج‌کنند یا سازمان؟ چگونه، چه افرادی و در چه زمانی مخاطب این ترویج‌ها هستند؟ هزینۀ ترویج طی زمان چقدر تخمین زده می‌شود؟ این باعث میشود تصویری که از محصول یا شرکت ارائه می‌کنید، در ذهن مخاطب نقش ببندد. مثلاً اپل برای استراتژی برند گران قیمت برای ترویج‌ها هزینۀ آن‌چنانی نمی‌کند در‌حالی‌که والمارت برای ارائۀ محصول ارزان‌قیمت هزینه می‌کند.واکنش بر نحوه رفتار رقبا (Competitive Reactions): پیش‌بینی اقدام‌های رقبا پیش از واکنش از دستاوردهای این کار به‌حساب می‌آید. در این راستا و پیش از عرضۀ محصول پاسخ به پرسش هایی از این دست می‌تواند کارآمد باشد:۱. رقبا احتمالا چگونه واکنش نشان میدهند و چرا اینگونه واکنش نشان میدهند؟۲. آیا رقبا احتمالا فقط یکبار واکنش نشان میدهند؟۳. اگر قیمتمان را با قیمت رقیب مطابقت دهیم، چه اثری روی درآمد و سود خواهد گذاشت؟۴. در برابر واکنش‌هایمان چه واکنش‌های متقابل‌گونه ای را انتظار داریم؟بهینه‌سازی قیمت و کشش قیمت (Price elasticity)بعد از تنظیم و تدوین سند استراتژِی قیمت‌گذاری، مهمترین چالش پیش رو تعیین قیمت بهینه است. مهمترین مؤلفه در بهینه‌سازی قیمت، منحنی کشش قیمت است. این منحنی نشان میدهد که وقتی قیمت را کم و زیاد میکنید، حجم تقاضا چقدر کاهش و افزایش میابد. رابطۀ کشش قیمت چنین است:E(p) = ⧍Q ⁄ ⧍Pکه در این رابطه Q⧍ بیانگر درصد تغییر تقاضا و P⧍ بیانگر درصد تغییر قیمت است.منحنی کشش قیمتهر چه منحنی شیب‌دار‌تر باشد، با افزایش قیمت‌ها حجم تقاضا بیشتر کاهش می‌یابد. برای مثال، اگر قیمت ۵ درصد افزایش پیدا کند، حجم فروش ۱۰ درصد کاهش می‌یابد. در این حالت کشش قیمت برابر ۲ بوده و شیب منحنی زیاد است. ماداوان رامانوجام در کتاب درآمدزایی از نوآوری معتقد است همۀ محصولات (از رولزرویس گرفته تا آدامس بسته‌ای) منحنی کشش قیمت دارند و اگر از آن برای قیمت‌گذاری محصول استفاده نشود، قیمت بهینه برای محصول هیچگاه مشخص نخواهد شد. جدول زیر بازۀ کشش قیمت در صنعت‌های مختلف را نشان می‌دهد (برای خدمات نرم‌افزاری بین ۲- تا ۱.۲- مشخص شده است).بازه کشش قیمت در صنعت‌های مختلف

ایده عالی مستدام! راهکارهایی برای ماندگارکردن ایده شما

انیس‌ ناصری — Sat, 13 Jun 2020 12:36:40 +0430

ایده عالی مستدامچرا بعضی ایده‌ها ماندگار می‌شوند و بعضی بی‌آنکه توجهی را به خود جلب کنند، می‌میرند؟ برایتان پیش آمده بخواهید کسی را متقاعد کنید ولی نتوانید؟ یا اینکه ایدۀ خوبی داشته باشید؛ ولی نتوانید تأثیرگذار باشید؟ پس لازم است توصیه‌های جیپ و دن هیث را بخوانید. برادران هیث در کتاب Made to Stick: Why Some Ideas Survive and Others Die یعنی همان ایده عالی مستدام شش اصل ماندگارکردن ایده‌ها را به ما یاد می‌دهند.شش اصلی که به‌صورتی خیلی ساده و موجز در یک کلمه SUCCESs خلاصه شده‌اند، به‌ترتیب سرواژه‌های کلمه‌های زیر محسوب می‌شوند:‌Simple (ساده): هستۀ اصلی هر ایده را پیدا کنید.Unexpected (غیرمنتظره): مخاطبان را با عنصری غیرمنتظره غافل‌گیر کنید.Concrete (ملموس): مطمئن شوید ایدۀ شما فهمیدنی و به‌یادآوردنی است. از مفاهیم دور از ذهن مخاطبانتان استفاده نکنید.Credible (معتبر): ایدۀ خود را باورپذیر جلوه دهید.Emotional (احساسی): به مردم کمک کنید تا اهمیت ایدۀ شما را درک کنند و احساسشان درگیر شود.Storie (داستانی): مخاطبانتان را از طریق داستان به ایده‌تان علاقه‌مند کنید.حال، هرکدام از این شش اصل برادران هیث در کتاب ایده عالی مستدام را توضیح می‌دهیم.ساده۱. سادهساده‌بودن به‌معنی کوتاه‌بودن نیست. البته که ایجاز به سادگی کمک می‌کند؛ اما نکتۀ اصلی، پیداکردن هستۀ اصلی ایده‌تان است. اضافات ایده را حذف کنید و مهم‌ترین بخش آن را برجسته کنید. انسان‌ها در مواجهه با انتخاب‌های زیاد دچار سردرگمی می‌شوند و پیام‌های پراکنده‌ای را به ذهن می‌سپارند. در واقع هدایتی از سمت شما اتفاق نمی‌افتد. بعد از پیداکردن ایدۀ اصلی، می‌توانیم به کوتاه‌کردن آن فکر کنیم. پیام‌‌های ساده معمولاً کوتاه‌ترند. مثلاً ما می‌دانیم که جمله‌ها بهتر از پاراگراف‌ها هستند و کلمات آسان بهتر از کلمات سخت.چگونه با سادگی مؤثر باشید؟۱.۱. از ضرب‌المثل‌‌ها استفاده کنید: آن‌ها ساده و کوتاه‌اند. مردم استفاده‌شان می‌کنند و برایشان آشنا هستند. در واقع فشردۀ موقعیت‌هایی‌اند که شاید توضیحشان زمان زیادی طول بکشد؛ اما ضرب‌المثل‌ها در زمان کوتاهی آن‌ها را شرح می‌دهند، مثلاً یک تیر و دو نشان، یا نرود میخ آهنین در سنگ. سروانتس در تعریف ضرب‌المثل می‌گوید:«جملاتی‌ کوتاه، حاصل از تجربیاتی طولانی!»۲.۱. پرچم‌های حافظه را برافرازید: از چیزهایی استفاده کنید که قبلاً در ذهن مخاطبان وجود دارند. برای اینکه بتوانید ایده‌ای ماندگار را در قالب پیامی کوتاه و ساده بسازید، باید روی زمین حافظۀ مخاطبان خود بازی کنید و پرچم‌هایشان را به حرکت دربیاورید!۳.۱. از تمثیل بهره ببرید: از داستان‌ها و تمثیل برای ساده‌تر‌شدن ایده‌تان استفاده کنید.۴.۱. اسامی، اسامی، اسامی را فراموش نکنید: اگر می‌توانید از اسم‌های اشخاص و مکان‌ها استفاده کنید. پیام شما صمیمانه‌تر می‌شود و ارتباط بیشتری با مخاطبان برقرار خواهید کرد. مخصوصاً اگر این اسامی برای مخاطبان شما آشنا باشد.۵.۱. اگر سه چیز بگویید، هیچ نگفته‌اید: بین پیام‌های خود یک پیام مهم را انتخاب کنید و روی آن متمرکز شوید.غیرمنتظره۲. غیرمنتظرهـ چطور توجه مخاطبان را جلب کنید؟ـ چگونه توجه‌شان را نگه دارید؟دو سؤال بالا از سؤال‌های مهمی هستند که بعد از رعایت اصل سادگی باید به آن‌ها جواب دهیم تا ایده‌های ماندگارتری داشته باشیم. مغز ما به‌گونه‌ای طراحی شده است که کاملاً از تغییرات آگاه‌ باشد؛ بنابراین اساسی‌ترین راه برای جلب‌توجه دیگران، این است که الگویی را بشکنید! شکستن الگوها، نگاه‌ها را به‌سوی شما برمی‌گرداند؛ اما این تمام راه نیست. غافل‌گیری، توجه مخاطبان را جلب می‌کند؛ اما برای نگه‌داشتن توجه باید در مخاطبان علاقه ایجاد کنید.چگونه با غیرمنتظره‌بودن مؤثر باشیم؟۱.۲. ماشین حدس مخاطبان را از کار بیندازید: جوری رفتار کنید که مردم فکر کنند همه‌چیز قرار است همان‌طور پیش برود که عادت دارند؛ اما ناگهان تمامی الگوها را بشکنید و عادت‌ها را عوض کنید. ماشین‌های گمانه‌زنی را از کار بیندازید. آن‌ها را غافل‌گیر کنید. این چیزی است که به یادشان می‌ماند.۲.۲. از معما و راز استفاده کنید: با خلق معما و طرح رمز و رازهایی، مخاطبان را علاقه‌مند کنید. می‌توانید بعد از غافل‌گیرکردن با ایجاد معما آن‌ها را علاقه‌مند کنید یا از ابتدا از این روش بهره ببرید. ندانستن درد دارد. شما با ایجاد شکاف دانشی در ذهن مخاطبان آن‌ها را ترغیب می‌کنید که دربارۀ مطلبی بیشتر بدانند، مانند ایجاد خارشی ذهنی.۳. ملموسبه بیان نویسندگان کتاب (برادران هیث) از میان شش اصل ماندگاری ایده، ملموس‌بودن ساده‌ترین آن‌هاست. سعی کنید به‌جای استفاده از مفاهیم انتزاعی و پیچیده، از موضوع‌ها و داستان‌های ملموس استفاده کنید. برادران هیث، اصل ملموس‌بودن را با داستانی از ازوپ، نویسندۀ یونانی، به نام «روباه و انگور» توضیح می‌دهند. ازوپ برای شرح مفهومی پیچیده از داستانی ملموس استفاده می‌کند.چگونه با ملموس‌بودن مؤثر باشیم؟۱.۳. داستان بگویید: از روش ازوپ استفاده کنید. برای ساده‌ و ملموس‌کردن موضوع و مفهوم ذهنی‌تان داستان‌های جذاب تعریف کنید.۲.۳. افراد آشنا را در داستان خود قرار دهید: اگر می‌توانید از آدم‌های نام‌آشنا در داستان‌های خود استفاده کنید.۳.۳. موضوع خود را واقعی و کاربردی کنید.معتبر۴. معتبرتا اینجا فرض کنید ایده‌های ساده، غیرمنتظره و ملموس آفریدید؛ اما چطور ایده‌هایتان را معتبر جلوه می‌دهید؟ طوری که مخاطبان بعد از درک و غافل‌گیری، شما را باور کنند. برادران هیث چند راه پیش روی ما می‌گذارند: دادن آمار مطمئن، استفاده از قدرت جزئیات، آزمون سیناترا.چگونه با معتبرکردن مؤثر باشیم؟۱.۴. آمار مطمئن بدهید: دربارۀ مسائلی که دسترسی دارید، آمار ملموس و قابل‌اعتماد ارائه دهید.۲.۴. از قدرت جزئیات استفاده کنید: هنگامی که ایده یا داستانی را روایت می‌کنید، از جزئیات بهره ببرید؛ مثلاً نام مکان‌ها و اشخاص را ذکر کنید تا باورپذیرتر به نظر آید.۳.۴. آزمون سیناترا: فرانک سیناترا خوانندۀ مشهور در آهنگ «نیویورک نیویورک» دربارۀ این شهر می‌خواند: «If I can make it there. I'll make it anywhere» یعنی اگر اینجا در نیویورک دوام بیاورم، هرجای دیگری هم می‌توانم. این اصل به‌نوعی بیان می‌کند که اگر بتوانم این آزمون سخت را پشت سر بگذارم، بقیۀ مراحل راحت خواهد بود. در مثال دیگر تصور کنید شرکتی پستی که در حوزۀ جهانی بسته‌های پستی مردم را در امنیت و سرعت جابه‌جا کرده‌است، بخواهد در حوزۀ داخلی این کار را انجام دهد. می‌تواند بگوید من آزمون سخت‌تر را پشت سر گذاشته‌ام و در حوزۀ جهانی که پیچیده‌تر و بزرگ‌تر و ناامن‌تر است، بسته‌ها را در صحت و سلامت به دست صاحبانشان رسانده‌ام، پس در حوزۀ داخلی صدالبته موفقم، مرا باور کنید!احساسی۵. احساسیبه گفتۀ کتاب احساسی‌بودنِ پیام و ایده به‌معنای فشردن دکمۀ احساسات دیگران مثل فیلم یا داستانی احساساتی و گریه‌آور نیست؛ بلکه هدف از احساسی‌کردن پیام‌ها این است که دیگران به آن اهمیت دهند. احساسات باعث برانگیخته‌شدن افراد برای اقدام می‌شود (با تلخیص ص ۲۴۷). از روش‌هایی که برادران هیث به ما معرفی می‌کنند، اثر مادر ترزاست.چگونه با احساسی‌کردن مؤثر باشیم؟اثر مادر ترزا: مادر ترزا زمانی گفت: «اگر من به عموم نگاه کنم، اقدامی نمی‌کنم؛ اما اگر به یک نفر نگاه کنم، اقدام می‌کنم.» در اثر مادر ترزا چنین مطرح شده است که برای مردم وقتی دربارۀ شخصی صحبت می‌شود بیشتر تحت تأثیر قرار می‌گیرند و تمایل به عمل دارند تا اینکه مثلاً به‌طورکلی دربارۀ مردم محروم آفریقا دعوت به کمک شوند.۶. داستانیداستان‌ها به شما کمک می‌کنند تا در برابر موقعیت‌ها تمرین ذهنی داشته باشید. در واقع زمانی که فرد داستانی دربارۀ ایدۀ شما بشنود، در موقعیت واقعی بهتر می‌تواند تصمیم بگیرد. شبیه‌سازی ذهنی موجب مدیریت بهتر احساسات شما می‌شود. پس با گفتن داستان می‌توانید موقعیت‌هایی را در ذهن مخاطبان خود شبیه‌سازی کنید و در کنار پنج اصل قبلی، ایدۀ خود را برایشان ماندگار سازید!به امید ایده‌هایی ماندگار و ماندگارتر!