کانال عباس اویسی

یکی از نکاتی که دارم یاد میگیرم اینه وقتی قرار هست یه تیم خوب فنی درست کنیم تا به هدفی که تعیین کردیم برسیم اینه که نباید سعی کنیم به بهترین چیزهایی که از جاهای دیگه دیدیم فکرکنیم. اگر بخوام دقیقتر بگم خیلی مهمه تعریف کنیم تیم خوب با توجه به زمینه و مدل هدف و مرحله‌ای که داخلش هستیم چیه. من با توجه به علاقه شخصی خیلی از کنفرانس‌ها از اینکه شرکت‌های دیگه چیکار میکنن رو نگاه میکنم یا کتاب‌هایی مثل Software Engineering at Google رو خوندم. پس وقتی شروع به بهبود تیم کردم با این دید شروع کردم باید فرایند‌های دقیقی تعریف کنیم تا همه مراحل نرم‌افزار‌رو به دقت داشته باشیم، با یوزر استوری که داریم یه سری چک‌لیست رو داشته باشه یا برای همه چی دیزاین خیلی کاملی داشته باشیم یا دولوپرها جزییات خیلی دقیقی رو بدونن بعد روی تیکت کار کنن یا تیم QA با استاندارد بالایی نذارن کوچکترین چیزی رد بشه و تیکت رو ریجکت کنن. و همه اینا از نظرم همین الانم خوبه. دلیلشم اینه خیلی از چیزهایی که درست کردم از همه اون چیزهایی که بود که توی کنفرانس‌ها دیدم، توی کتاب‌ها خوندم و دوستام که توی شرکت‌های بزرگی که کار میکردن باهام به اشتراک گذاشتن. ولی یه نکته مهم اینه ما چه تیم خوبی میخوایم بسازیم؟! ایا هدفمون اینه که دیجیکالا بسازیم یا کافه بازارو؟ یا حتی شرکت‌های مثل گوگل؟ اینجا بنظرم یه مشکلی هست، اونم اینکه یه کجفهمی هست بین اینکه بخوای درنهایت به یه شرکتی مثل دیجیکالا، کافه‌بازار یا گوگل بسازی به این معنا نیست باید در زمان حال حاضر ببینی اون شرکت‌ها چیکار میکنن. و چطوری تیم‌هارو ساختن و مدیریت میکنن. چون این دو تا ربطی بهم ندارن. در نتیجه اینکه الان ساختار کافه بازار چیه؟ پروداکت منیجیرشون چیکار میکنه. دولوپرش چیکار‌میکنه. چه نقش‌هایی برای هرکاری دارن لزوما اجرا کردنشون برای هرتیمی اونارو به خروجی نهایی و کافه بازار الان نمیرسونه. و اینجا مهمترین نکته اینه بررسی کنیم اگرم الگو میخوایم بگیریم ببینیم اینا از اول که شروع کردن و به اینجا رسیدن چیکار کردن. اینجاس که الگوهای ذهنی به چالش کشیده میشه پس ذهنیت افراد توی تیم اینه باید اگر شرکت x الان اینجوری کار میکنه ما هم اونجوری کار‌کنیم؟ اگر شرکت x ده تا پروداکت منیجر داره، ۳۰ تا دولوپر و یه تیم کامل infra ما هم اگر بخوایم موفق بشیم همه اینارو باید داشته باشیم؟ اگر هرکی دقیقا توی شرکت x محدوده مشخصی داره و فقط باید روی اون فوکوس کنه ما هم باید همینکارو بکنیم؟ ایا اگر برای experiment فیچرها شرکت x از روش پیچیده y استفاده میکنه ما هم یا اون مدل رو باید داشته باشیم یا اگر نداشته باشیم موفق نمیشیم؟ بنظر مهمترین نکته اینه هرشرکت موفق با ساختاری که الان داره، درحال مشکلاتی هست که الان داره. پس خیلی مهم هست اگر میخوایم از چیزی الگو بگیریم یه تاریخچه‌ای از اون شرکت‌ها بدونیم و بریم توی اون نقطه که اونا داشتن مشکلات شبیه مارو حل میکردن ازشون الگو بگیریم. وگرنه درگیر حل مشکلاتی میشید که الان مشکل شما نیست، ساده‌ترین و بدیهی‌ترینش درگیر مثلا حل این مشکل میشید که اگر ۱۰۰۰۰ یوزر از فیچر x استفاده کنن نتیجه چی میشه، درصورتی که شاید اصن فیچر x رو ۱۰ نفر هم استفاده نکنن. پس خیلی مهمه بدونیم توی چه مرحله‌ای هستیم، میخوایم به چی برسیم. شاید من عباس اویسی اگر با همه اون تجربه از دیدن کنفرانس‌های مختلف، خوندن کتابهای کار تیمی، معماریهای مختلف بتونم توی دیجیکالا و کافه بازار و گوگل به عنوان نیروی فنی بسیار پیشرفت کنم و حتی لید فنی ۵۰ نفر اونجا بشم، چون نمیتونم درک نمیکنم این فیچر درنهایت چه کمکی به رشد درامد میکنه یا نتونم یه دیزاین ساده برای حل یه مشکل طراحی کنم و فقط منتظر باشم یه دیزاینر یه دیزاین کامل و پرفکت بهم بده، نتونتم حتی به تیم ۵ نفره رو توی یه شرکت دیگه مدیریت کنم. این به معنای لزوما عدم شایستگی نیست. این به معنای این هست که من توی جای اشتباهی هستم و نتونستم خودمو با شرایط وقف بدم. نتیجه اینکه خیلی مهم هست که تشخیص بدید توی چه مرحله هستید و هدفتون چیه، فرایندها و ساختارهارو باید براین اساس اون درست کنید و خیلی مهم میشه‌ که شما میخواید استخدام کنید، قرار هست کسی که استخدام کنید بهترین فرد تکنیکال دنیا باشه ایا به برای این مرحله از شما مناسب هست؟ اهدافش با اهداف شما یکیه؟ پایان.

سلاممم دوباره. ما آگهی استخدام جدیدمون رو برای جذب نیروی سنیور Golang منتشر کردیم. اگر خودتون یا دوستاتون سنیور Golang هستید و دوست دارید با ما همکاری کنید (شرکتمون Fedshi هست)، لطفا رزومتون رو توی jobinja برامون ارسال کنید. توی پیام قبلی میتونید valueهایی که برامون مهمه رو بخونید. این valueها برامون فقط یه لیست جذاب نیست که بخوایم در آینده بهش برسیم و سعی میکنیم هر روز براساس همین‌ها value تصمیم بگیریم یا عمل کنیم. فرآیند مصاحبه و کلا مکالمه توی شرکت به زبان انگلیسی هست، پس نیاز هست که بتونید به انگلیسی مکالمه کنید. اگر سوالی هست میتونید بهم پیام بدید تا بهتون جواب بدم. https://jobinja.ir/1357819

اگر دوست دارید به عنوان سنیور فرانت‌اند دولوپر به شرکت ما اضافه بشید، میتونید رزومه‌تون رو توی جاب‌اینجا بفرستید: https://jobinja.ir/companies/ice-global/jobs/AD04 برای اینکه بیشتر در مورد شرکت بدونید میتونید fedshi.com رو ببینید. شرکت اینجوری نیست که پروژه…

اگر دوست دارید به عنوان سنیور فرانت‌اند دولوپر به شرکت ما اضافه بشید، میتونید رزومه‌تون رو توی جاب‌اینجا بفرستید: https://jobinja.ir/companies/ice-global/jobs/AD04 برای اینکه بیشتر در مورد شرکت بدونید میتونید fedshi.com رو ببینید. شرکت اینجوری نیست که پروژه بگیره و انجام بده، یه محصول به اسم فدشی داریم که فقط روی اون کار میکنیم تا به mission و vision که برای آینده داریم برسیم. باید سطح زبانتون خوب باشه چون با توجه به اینکه شرکت بین‌المللی هست و از کشورهای مختلف نیرو داریم همه مکالمات و حتی مصاحبه به انگلیسی هست. تیم فنی بصورت کاملا ریموت کار میکنه و تیم بیزینس توی عراق هستن و حضوری کار میکنن.

جلسه آبان ماه لاگ‌کت جلسه آینده لاگ‌کت سه‌شنبه ۲۹ آبان ساعت ۱۸:۰۰ تا ۲۰:۰۰ با حمایت «کافه بازار» برگزار خواهد شد. 🔸 ابزار Dexguard  توی این ارائه با عنوان «Dexguard در اندروید» شهاب عظیمی برامون درباره دکس‌گارد صحبت می‌کنه. دکس‌گارد یکی از قوی‌ترین ابزارهای موجود برای محافظت از اپلیکیشن‌های اندروید در برابر مهندسی معکوس و دستکاری هست. 🔸 کتابخانه Sqldelight  توی این ارائه کاوه محمدی برامون درباره «لایبرری Sqldelight» و نحوه استفاده ازش صحبت می‌کنه و ی مقایسه از این لایبرری با روم رو خواهیم داشت. Sqldelight ابزاری برای استفاده از دیتابیس SQL در اندروید هست. 🔸 آدرس محل برگزاری: تهران، خیابان میرداماد، نبش نلسون ماندلا، پلاک ۴۰۴، ساختمان میکاناتس، آمفی‌تئاتر برای این رویداد پخش زنده هم خواهیم داشت. ساختمان به تعداد کافی پارکینگ داره و در صورتی که با ماشین شخصی تشریف میارید، میتونید از پارکینگ ساختمان استفاده کنید. (ورودی پارکینگ در خیابان نلسون ماندلا هست) نزدیکترین ایستگاه مترو و BRT به ساختمان، ایستگاه میرداماد هست. لینک ثبت‌نام

جلسه مهر ماه لاگ‌کت جلسه آینده لاگ‌کت سه‌شنبه ۲۴ مهر ساعت ۱۸:۰۰ تا ۲۰:۰۰ در «ساختمان میکاناتس» با حمایت «کافه بازار» برگزار خواهد شد. در این ارائه با عنوان «GraphQL Api Services»، محسن موسوی در دو بخش، به معرفی ساختار GraphQL و مزایای اون نسبت به REST پراخته و در ادامه نحوه پیاده‌سازی و کاربردهای مختلف اون در اندروید رو ارائه میکنه. 🔸آدرس محل برگزاری: تهران – خیابان میرداماد، نبش نلسون ماندلا، پلاک ۴۰۴، ساختمان میکاناتس، آمفی‌تئاتر برای این رویداد پخش زنده هم خواهیم داشت. با توجه به محدودیت جا، لطفاً درصورتیکه حتماً در رویداد شرکت میکنید، بلیط حضوری رو تهیه کنید، در غیر اینصورت لطفاً بلیط آنلاین تهیه کنید. ساختمان به تعداد کافی پارکینگ داره و در صورتی که با ماشین شخصی تشریف میارید، میتونید از پارکینگ ساختمان استفاده کنید. (ورودی پارکینگ در خیابان نلسون ماندلا هست) نزدیکترین ایستگاه مترو به ساختمان، مترو میرداماد هست. برای شرکت در جلسه می‌توانید از طریق ایوند ثبت نام کنید (رایگان) 🔷 http://evand.com/events/logcat30

جلسه مرداد ماه لاگ‌کت جلسه آینده لاگ‌کت سه‌شنبه ۳۰ مرداد ساعت ۱۸:۰۰ تا ۲۰:۰۰ در «ساختمان میکاناتس» با حمایت «کافه بازار» برگزار خواهد شد. در ارائه اول با عنوان «انیمیشن‌» امیرحسین آقاجری در مورد مقدمات و پایه‌های انیمیشن در اندروید، از پشت پردش تا پیاده…

جلسه مرداد ماه لاگ‌کت جلسه آینده لاگ‌کت سه‌شنبه ۳۰ مرداد ساعت ۱۸:۰۰ تا ۲۰:۰۰ در «ساختمان میکاناتس» با حمایت «کافه بازار» برگزار خواهد شد. در ارائه اول با عنوان «انیمیشن‌» امیرحسین آقاجری در مورد مقدمات و پایه‌های انیمیشن در اندروید، از پشت پردش تا پیاده سازی انیمیشن‌های پیچیده با تمرکز بر روی پرفورمنس صحبت میکنه. امیرحسین برنده جایزه کانتست انیمیشن تلگرام هم هست و درباره نحوه پیاده‌سازی این انیمیشن هم توی ارائه برامون صحبت می‌کنه. در ارائه دوم با عنوان «معماری اپلیکیشن‌های تمام کامپوزی»  حمیدرضا شجراوی در مورد معماری اپلیکیشن‌های تمام کامپوزی و جزییاتشون صحبت می‌کنه. 🔸آدرس محل برگزاری: تهران – خیابان میرداماد، نبش نلسون ماندلا، پلاک ۴۰۴، ساختمان میکاناتس، آمفی‌تئاتر برای این رویداد پخش زنده هم خواهیم داشت. با توجه به محدودیت جا، لطفاً درصورتیکه حتماً در رویداد شرکت میکنید، بلیط حضوری رو تهیه کنید، در غیر اینصورت لطفاً بلیط آنلاین تهیه کنید. ساختمان به تعداد کافی پارکینگ داره و در صورتی که با ماشین شخصی تشریف میارید، میتونید از پارکینگ ساختمان استفاده کنید. (ورودی پارکینگ در خیابان نلسون ماندلا هست) نزدیکترین ایستگاه مترو به ساختمان، مترو میرداماد هست. برای شرکت در جلسه می‌توانید از طریق ایوند ثبت نام کنید (رایگان) 🔷 http://evand.com/events/logcat28

📹 Innovation Management course 🔸I listened to a podcast last week where the guest talked about innovation. He used the term "innovation management," which was new to me because I often use the term "innovation" but hadn't heard "innovation management" before.…

🔸خیلی وقت پیش توی Slack شرکتمون یه کانال درست کردم تا چیزهایی که بنظرم برای تیممون مفید هست و میتونه باعث پیشرفتمون بشه رو اونجا با بقیه به اشتراک بذارم. چون بنظرم احتمال داره اون چیزهایی که توی Slack شرکتمون نوشتم بکار بقیه هم بیاد، یه چندتا از پست‌هایی که…

توی تیممون نیاز به یه سینور پرداکت دیزاینر داریم، اگر کسی رو میشناسید که گزینه خوبی هست،‌ معرفی کنید. (ریموت هستیم و به لوکیشن آگهی توجه نکنید، شرکت توی کشور دیگه‌ای غیر از ترکیه هست) https://www.linkedin.com/jobs/view/3958022939

پس از مدت‌ها .... جلسه آینده لاگ‌کت سه‌شنبه ۱۲ تیر ساعت ۱۸:۰۰ تا ۲۰:۰۰ در «دانشگاه شریف» با حمایت «کافه بازار» برگزار خواهد شد. در ارائه اول با عنوان «بیس‌لاین پروفایل و نحوه استفاده» داوود حسینی در مورد رویکرد بیس لاین پروفایل برای سریعتر شدن برنامه صحبت…

پس از مدت‌ها .... جلسه آینده لاگ‌کت سه‌شنبه ۱۲ تیر ساعت ۱۸:۰۰ تا ۲۰:۰۰ در «دانشگاه شریف» با حمایت «کافه بازار» برگزار خواهد شد. در ارائه اول با عنوان «بیس‌لاین پروفایل و نحوه استفاده» داوود حسینی در مورد رویکرد بیس لاین پروفایل برای سریعتر شدن برنامه صحبت میکنه. میفهمیم چطوری کار میکنه، چطور اعمالش کنیم و چطور تستش کنیم. در ارائه دوم با عنوان «کاتلین مالتی پلتفرم: از رویا تا واقعیت» رضا معلمی در مورد آینده کاتلین مالتی پلتفرم و آیا اینکه واقعا ارزش وقت گذاشتن و سرمایه‌گذاری رو داره برامون میگه. 🔸آدرس محل برگزاری: تهران – خیابان آزادی – خیابان حبیب الهی – خیابان شهید قاسمی – ضلع شمال دانشگاه صنعتی شریف – نبش کوچه شهید تیموری – دانشکده مهندسی انرژی - سالن آمفی تئاتر دانشکده مهندسی انرژی برای شرکت در جلسه می‌توانید از طریق ایوند ثبت نام کنید (رایگان) 🔷 http://evand.com/events/logcat27

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

🔸This chapter covers how to use request identifiers to prevent duplicate requests, This pattern explores the idea of providing a unique identifier to each request that we want to ensure is serviced once and only once. Using this identifier, we can clearly see whether a current incoming request was already handled by the API service, and if so, can avoid acting on it again. We can use this pattern for critical APIs in WEB-API and ADMIN-API. ◀️عضویت @aoveissi

🔸This chapter covers how to consume data when the number of resources or the size of a single resource is simply too large for a single API response. It starts from basic intro and then talks about Page size (It should be exact or maximum) or Page token (How to define the page token format) and … We can use this pattern in our API too, e.g. it will solve our issues which we have in pagination of SavedProduct API. ◀️عضویت @aoveissi

📗API Design patterns for Pagination and Request deduplication 🔸Recently I found a book about API Design patterns, and I've read multiple chapters from different sections. I don’t recommend to read whole book because some chapters are boring or basic, but some chapters worth to read even if you implemented that pattern before. At least to start, I suggest to read “Pagination” and “Request duplication” chapters. This is a book that both Clients and Backend team can read it. I’ve attached PDF of these chapters to this message. 🔸 https://www.amazon.de/API-Design-Patterns-English-Geewax-ebook/dp/B098PF47RK ◀️عضویت @aoveissi

📑 The Practical Architecture Guide 🔸This is a multi-part article about Architecture guide. It doesn't talk about different architectural styles and architectures and only focuses on defending a process so that all teams by following it can find the best architecture for themselves. The article explains why teams need architecture meetings, how teams should prepare an Architecture roadmap, how they can have effective decision-making meetings, and … 🔸I think the article is very helpful and we can use its points in our company and also in refactoring our architecture of Clients and Backend. The article is a summary of the Practical Software Architecture mini-book but I couldn’t find a free version of the book, so I only read the article. 🔗 https://thepracticaldeveloper.com/practical-software-architecture/software-architecture-issues-and-solutions ◀️عضویت @aoveissi

📑 Second part of The New Methodology - Martin Fowler 🔸One of the key elements is that of accepting the process rather than the imposition of a process. Often software processes are imposed by management figures. As such they are often resisted, particularly when the management figures have had a significant amount of time away from active development. Accepting a process requires commitment, and as such needs the active involvement of all the team. 🔸The key to iterative development is to frequently produce working versions of the final system that have a subset of the required features. These working systems are short on functionality, but should otherwise be faithful to the demands of the final system. They should be fully integrated and as carefully tested as a final delivery. The point of this is that there is nothing like a tested, integrated system for bringing a forceful dose of reality into any project. Documents can hide all sorts of flaws. Untested code can hide plenty of flaws. But when people actually sit in front of a system and work with it, then flaws become truly apparent: both in terms of bugs and in terms of misunderstood requirements. 🔸"A late change in requirements is a competitive advantage". I think most people have noticed that it's very difficult for business people to really understand what they need from software in the beginning. Often we see that people learn during the process what elements are valuable and which ones aren't. Often the most valuable features aren't at all obvious until customer have had a chance to play with the software. 🔸[Even process itself should be adaptive (Importance of Retro meeting) ] However there's another angle to adaptivity: that of the process changing over time. A project that begins using an adaptive process won't have the same process a year later. Over time, the team will find what works for them, and alter the process to fit. The first part of self-adaptivity is regular reviews of the process. Usually you do these with every iteration. ◀️عضویت @aoveissi

📑 The New Methodology - Martin Fowler 🔸I follow some agilists on Twitter and yesterday one of them recommended everyone to read "The New Methodology" Martin Fowler's novella-length post from 15 years ago. So I read it and suggest you read it too. It helps everyone know what Agile is and why we use it in software development. In this thread, I will send multiple quotes from the article that I like them (text in brackets is mine to explain context of quote). If you want, you can share yours too😃 🔗 https://martinfowler.com/articles/newMethodology.html Important parts from my perspective: 🔸The software is written without much of an underlying plan, and the design of the system is cobbled together from many short term decisions. This actually works pretty well as the system is small, but as the system grows it becomes increasingly difficult to add new features to the system. …………… A typical sign of such a system is a long test phase after the system is "feature complete". Such a long test phase plays havoc with schedules as testing and debugging is impossible to schedule. 🔸[The Unpredictability of Requirements] The developers come to me and say "the problem with this project is that the requirements are always changing". The thing I find surprising about this situation is that anyone is surprised by it. In building business software requirements changes are the norm, the question is what we do about it. 🔸[Why requirement can’t be fixed 1] It's very difficult to see what value a software feature has until you use it for real. Only when you use an early version of some software do you really begin to understand what features are valuable and what parts are not. 🔸[Why requirement can’t be fixed 2] In today's economy the fundamental business forces are changing the value of software features too rapidly. What might be a good set of requirements now, is not a good set in six months time. 🔸[Why is estimation hard?] Estimation is hard for many reasons. Part of it is that software development is a design activity, and thus hard to plan and cost. Part of it is that the basic materials keep changing rapidly. Part of it is that so much depends on which individual people are involved, and individuals are hard to predict and quantify. 🔸[Because software development isn’t predictable, Does it mean we shouldn’t do anything?] So if you are in a situation that isn't predictable you can't use a predictive methodology. That's a hard blow. It means that many of the models for controlling projects, many of the models for the whole customer relationship, just aren't true any more. …. However letting go of predictability doesn't mean you have to revert to uncontrollable chaos. Instead you need a process that can give you control over an unpredictability. That's what adaptivity is all about. 🔸[Agile methods are people-oriented rather than process-oriented] Executing an adaptive process is not easy. In particular it requires a very effective team of developers. The team needs to be effective both in the quality of the individuals, and in the way the team blends together. There's also an interesting synergy: not just does adaptivity require a strong team, most good developers prefer an adaptive process. "More to come in Part 2." ◀️عضویت @aoveissi