به نظرتون اون پنج تا شرکت کدوم ها هستن؟
https://x.com/rasmio_com/status/1815677160985616476?t=0ny357fc0c5oKPjmxcwq4g&s=35

فکر میکنم اولین ترانه ای که در وصف فعالان موثر اکوسیستم نوآوری در ایران خوانده شده، همون ترانه ی "پوست شیر" با صدای عالیجناب ابی هست...
و اما تفسیر:
قلب تو قلب پرنده پوستت اما پوست شیر
زندون تن و رها کن ای پرنده پر بگیر
(شاعر در این بیت میگه میخوای کارآفرینی کنی قید زندگیتو بزن ببم جان)

اون ور جنگل تن سبز پشت دشت سر به دامن
اون ور روزای تاریک پشت نیم شبای روشن
( اینجا شاعر داره میگه با اینکه ایران خوش میگذره، ولی باید بگذری از این شمال و جوج و عرق، اونور همه اینا یه چیز مهم تر هست)

برای باور بودن جایی باید باشه شاید
برای لمس تن عشق کسی باید باشه باید
(خلاصه ش اینه که تو این مملکت کسی قدرتو نمیونه 😢)

که سر خستگیاتو به روی سینه بگیره
برای دلواپسی هات واسه سادگیت بمیره
( یعنی واسه یه فاند ریز نیاز نداری اونجا هی پاچه اینو بخوری پاچه اونو بخوری..)

اگه ادامه شو میخواین کامنت بگذارین 😁😎

مقاله جدید نوشتم داخل azibom.com میتونید بخونید درباره RPC و اینکه کلا چی هست

اگر فیدبکی هم داشتید دربارش بهم بگید، خوشحال میشم

https://azibom.com/remote-procedure-call-rpc-%d8%a7%d8%a8%d8%b2%d8%a7%d8%b1%db%8c-%d8%a8%d8%b1%d8%a7%db%8c-%d8%aa%d9%88%d8%b3%d8%b9%d9%87%d8%af%d9%87%d9%86%d8%af%da%af%d8%a7%d9%86-%d8%af%d8%b1-%d8%b3%db%8c/

@azibom
@azibomChannel

Azibom.com

#azibom_family

هیچ وقت امروز رو فراموش نخواهم کرد، روزی که دوباره متولد شدم.
تولدم مبارک

این داکیومنت بررسی دیزاین کردن یک سیستم شبیه اینستاگرام است برای معماران سیستم و توسعه دهندگان Backend
از صفحه ی آقای پوریا جهاندیده برداشتم در لینکدین به آدرس زیر:
https://www.linkedin.com/in/pouria-jahandideh/

خوندنش برای توسعه دهندگان و مهندسین نرم افزار میتونه خیلی خوب و جذاب و آموزنده باشه؛ البته که خودتون رو به پاسخ های پوریا محدود نکنید و به راه های بیشتر برای حل مشکلات هم فکر کنید.

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

1. فرصت رشد برای سازمان ها شاهراه حیاتی ماندگاری است
در صورتی که در سازمانی نقش مدیریتی دارید، برای نگهداشت و پیشرفت کارکنان می بایست برای آنها مکانیزم های رشد ساختار مندی را طراحی و پیاده سازی کنید. ساختار های رشد می بایست بر اساس Career Path و Job Profile پرسنل طراحی شود.
در صورتی که در بدنه مهندسی فعال هستید، از مدیران خود درخواست مسیر رشد و Career Path داشته باشید.

2. بیشتر سازمان ها در رشد پرسنل موفق عمل کرده‌اند ولی میزان رشد به قدر کافی نبود است.
به صورت کلی در Tech Company ها، رشد به دو دسته "رشد فنی" و به دست آوردن یک"جایگاه شغلی" متفاوت تقسیم می شود.
در صورتی که مدیر هستید، مسیر شغلی پرسنل را برای آنها شفاف کنید.
در صورتی که در بدنه مهندسی فعال هستید، با جلسات One-On-One موادم، مسیر رشد خود را با مدیرتان بررسی کنید و از وی در مورد قدم بعدی سوال کنید.

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

4. سازمان ها به افرادی که رشد پیدا کرده اند حقوق بهتری پرداخت کرده اند.
برای دریافت حقوق بهتر، نیازمند رشد و ماندگاری حداقل یکسال در سازمانتان هستید، مدیران بر روی افرادی سرمایه گذاری می کنند که ماندگاری آنها تا حدی تضمین شده باشد. این بدان معنی نیست که هر سازمانی ارزش ماندگاری بیشتر از 1 سال را دارد.

به صورت کلی دو برداشت زیر هم از این نظرسنجی برای من وجود داشت :
1. نظرسنجی های تخصصی در سطح سوشال مدیا، جذاب نیستند و به راحتی امکان جذب مخاطب را نداریم.
2. پرداختن به موضوعاتی همچون رشد در سطح کامیونیتی بسیار پر طرفدار هست و جای خالی آن حس می شود.

در نهایت در صورتی که در سازمانتان نیاز به برنامه ریزی برای رشد دارید(سطح سازمانی) با من در ارتباط باشید.
همچنین در صورتی که نیاز به Career Path دقیق برای خودتون دارید از طریق Adplist می تونید با من در ارتباط باشید تا با هم براتون برنامه ریزی کنیم.

@learning_with_m

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

قوانین برای اطاعت احمقان و راهنمایی خردمندان است.
خوانده شده در کتاب #Building_Microservices

داشتم https://www.12factor.net رو میخوندم، نگاه کردم و دیدم سرویس هایی که خودم نوشتم همه موارد رو داشتن، به جز یک مورد، و این خیلی برام جذاب بود. فکر نمیکردم انقدر مسیر رو درست رفته باشم تا حالا

Playing by the rules is important when it comes to response codes, too. If your circuit breakers rely on HTTP codes, and one service decides to send back 2XX codes for errors, or confuses 4XX codes with 5XX codes, then these safety measures can fall apart. Similar concerns would apply even if you’re not using HTTP; knowing the difference between a request that was OK and processed correctly, a request that was bad and thus prevented the service from doing anything with it, and a request that might be OK but we can’t tell because the server was down is key to ensuring we can fail fast and track down issues. If our services play fast and loose with these rules, we end up with a more vulnerable system.

نکته ش همون شوخی معروفیه که بین فرانت اند کارها و بکند کارها رایجه:
"عملیات با موفقیت با شکست مواجه شد!"
اصلا چرا ما لجاجت داریم که همیشه 200 برگردونیم ؟ پس کی میخوایم این RESTful بدبخت رو جدی بگیریم ؟
در مورد استفاده نکردن از PUT و PATCH هم که چیزی نگم بهتره :))
✅توضیح جدی:
مسئله ی مهمی که کتاب در این بخش داره توضیح میده مسئله ی Architectural Safety هست، خوب ما از مکانیزم های مختلفی برای مانیتورینگ استفاده میکنیم، اگه قرار باشه این Status ها قابل اعتماد نباشن، کل اون ماجرا به فنا میره که هیچ .... ارتباط بین سرویس هامون هم نمیشه دیگه بهش اعتماد داشت.
پس اگر از این Status ها درست و به جا استفاده کنیم اینطوری احتمال شکنندگی سیستم رو کاهش دادیم :)
در کل ماجرای Status ها در این بخش مثال هست و مثال خوبی هم هست، ولی مسئله فقط به اینجا ختم نمیشه، پارامترهای دیگه ای هم هست که سر فرصت شاید نشستیم با هم در مورد جلوگیری از شکنندگی سیستم ها راهکارهاش گپ زدیم.

فصل دوم کتاب #Building_Microservices

Sometimes, the group may make decisions with which the architect disagrees. At this point, what is the architect to do? Having been in this position before, I can tell you this is one of the most challenging situations to face. Often, I take the approach that I should go with the group decision. I take the view that I’ve done my best to convince people, but ultimately I wasn’t convincing enough. The group is often much wiser than the individual, and I’ve been proven wrong more than once! And imagine how disempowering it can be for a group to have been given space to come up with a decision, and then ultimately be ignored. But sometimes I have overruled the group. But why, and when? How do you pick the lines?
Think about teaching children to ride a bike. You can’t ride it for them. You watch them wobble, but if you stepped in every time it looked like they might fall off, then they’d never learn, and in any case they fall off far less than you think they will! But if you see them about to veer into traffic, or into a nearby duck pond, then you have to step in.
Likewise, as an architect, you need to have a firm grasp of when, figuratively, your team is steering into a duck pond. You also need to be aware that even if you know you are right and overrule the team, this can undermine your position and also make the team feel that they don’t have a say. Sometimes the right thing is to go along with a decision you don’t agree with. Knowing when to do this and when not to is tough, but is sometimes vital.

#Building_Microservices

کجا Scale کنیم ؟

سه شنبه ساعت 21:30 با مهندس نبی کرمپور

Tuesday, July 30 · 9:30 – 11:00pm
Time zone: Asia/Tehran
Google Meet joining info
Video call link: https://meet.google.com/euw-dohs-nmu

کانال تلگرامی کاریابی وبینارفارسی
https://t.iss.one/webinar_farsi

کانال تلگرام نبی کرمپور
https://t.iss.one/thisisnabi_dev

نت افتضاحه برای شما هم؟ برای من همراه اول و مبین نت به حد مرگ رسیدن...

آقا این سرویس های ایرانی مثل شکن و 403online، نمیشه ازشون به عنوان http , https proxy استفاده کرد؟

یک هفته ست که از 5 هزار فالور در لینکدین رد شدم :)
هر صبح مثل بچه گربه نگاه میکردم ببینم شد یا نشد ؟
شاید نسبت به خیلی از بچه ها من فالورهای کمتری دارم، ولی عمق روابطم با دوستانم فکر میکنم بیشتره :)
اگه هنوز تو لینکدین با هم رفیق نیستم شاید الان وقتش باشه :
https://www.linkedin.com/in/merkousha/

#مسعودبیگی

صبح روز تعطیل رو با خاطرات مدرسه شروع کنید 😂

be aware of the perils of shared code. In our desire to create reusable code, we can introduce sources of coupling between services. At least one organization I spoke to is so worried about this that it actually copies its service template code manually into each service. This means that an upgrade to the core service template takes longer to be applied across its system, but this is less concerning to it than the danger of coupling. Other teams I have spoken to have simply treated the service template as a shared binary dependency, although they have to be very diligent in not letting the tendency for DRY (don’t repeat yourself) result in an overly coupled system!

#Building_Microservices