Forwarded from Gopher Academy (𓄂👑𓆃)
📥 دریافت شده از: Vesal Behrouzi
-------------
داشتم میگفتم وقتی میرید به شرکت جدید به جای حل کردن مشکلاتی که وجود ندارند، اولویت ندارن یا ازتون خواسته نشده و... یه 6 ماهی آروم بشینید و فقط نگاه کنید تا فضا و اتمسفر دستتون بیاد، اولویتها رو بهتر درک کنید، ساختار شرکت و مشکلات رو بهتر بشناسید، بعد یواش یواش میتونید شروع کنید به انجام کارهایی که فرای انتظاراتی هستند که بابتش استخدام شدید، خلاصه در همین راستا از اتاق فرمان شرح انتظارات شغل Staff Engineer شرکت داکر رو هم برای ما فرستادن که جهت استحضار به پیوست ضمیمه شود.
➖➖➖➖➖➖➖➖
🕊 @gopher_academy
-------------
داشتم میگفتم وقتی میرید به شرکت جدید به جای حل کردن مشکلاتی که وجود ندارند، اولویت ندارن یا ازتون خواسته نشده و... یه 6 ماهی آروم بشینید و فقط نگاه کنید تا فضا و اتمسفر دستتون بیاد، اولویتها رو بهتر درک کنید، ساختار شرکت و مشکلات رو بهتر بشناسید، بعد یواش یواش میتونید شروع کنید به انجام کارهایی که فرای انتظاراتی هستند که بابتش استخدام شدید، خلاصه در همین راستا از اتاق فرمان شرح انتظارات شغل Staff Engineer شرکت داکر رو هم برای ما فرستادن که جهت استحضار به پیوست ضمیمه شود.
➖➖➖➖➖➖➖➖
🕊 @gopher_academy
MIT’s course on Software Construction sums up the reasons why: "Immutable types are safer from bugs, easier to understand, and more ready for change. Mutability makes it harder to understand what your program is doing, and much harder to enforce contracts"
https://web.mit.edu/6.031/www/fa20/classes/08-immutability/
https://web.mit.edu/6.031/www/fa20/classes/08-immutability/
Spotify Engineering recently open-sourced Voyager, an approximate nearest-neighbor (ANN) search library. Voyager is based on the hierarchical navigable small worlds (HNSW) algorithm and is 10 times faster than Spotify's previous ANN library, Annoy.
https://spotify.github.io/voyager/
https://spotify.github.io/voyager/
Voyager Documentation
🛰️ Voyager: Spotify's nearest-neighbor search library for Python and Java.
Spring Cloud Config is Spring’s client/server approach for storing and serving distributed configurations across multiple applications and environments. This configuration store is ideally versioned under Git version control and can be modified at application runtime
https://www.baeldung.com/spring-cloud-configuration
https://www.baeldung.com/spring-cloud-configuration
Baeldung on Kotlin
Quick Intro to Spring Cloud Configuration | Baeldung
A quick intro to using a git repository as a storage for our project configuration, using Spring Cloud.
Creating a Java off-heap in-memory database
https://blogs.oracle.com/javamagazine/post/creating-a-java-off-heap-in-memory-database
https://blogs.oracle.com/javamagazine/post/creating-a-java-off-heap-in-memory-database
Imagine a given range of numbers overlaid on a circle. We apply a hash function to balls and a separate hash function to bins to obtain numbers in that range that correspond to positions on that circle. We then start allocating balls in a specific order independent of their hash values (let’s say based on their ID). Then each ball is moved clockwise and is assigned to the first bin with spare capacity
https://blog.research.google/2017/04/consistent-hashing-with-bounded-loads.html
https://blog.research.google/2017/04/consistent-hashing-with-bounded-loads.html
research.google
Consistent Hashing with Bounded Loads
Posted by Vahab Mirrokni, Principal Scientist, Morteza Zadimoghaddam, Research Scientist, NYC Algorithms TeamRunning a large-scale web service, suc...
Forwarded from نوشتههای ترمینالی
خطا داریم؟ همینه که هست!
یه مثال دیدم که میگفت شما وقتی ماشینتون پنچر میشه صبر میکنید تا تعمیرکار بیاد درستش کنه، یا با همون چرخ های پنجر با سرعت کم ادامه میدین تا به مقصد برسید؟
به نظرم همین توی برنامهنویسی هم مصداق داره، وقتی برنامهمون به ارور میخوره چطوری مدیریتش میکنیم؟ حالا این ارور خیلی وقت ها exceptionه توی زبون های برنامه نویسی، ولی یکم سطح بالاتر ببینیم،
مثلا به یه سرویس خارجی درخواست دادیم و نیست، خب چیکار کنیم؟
یه فایل کانفیگ رو میخوایم لود کنیم ولی نیست.
دیتایی که از سمت کاربر اومده معتبر نیست.
در یک برنامه معمولی جوابِ (احتمالا) درست به خیلی از این سوالا اینه که خب کارکرد برنامه رو متوقف کن و بگو نمیتونم. برنامه کار نکنه تا دوباره با برطرف شدن مشکلات یکی از اول اجراش کنه،
ولی اگر برنامه ما قراره توی یکسری از محیطها اجرا بشه دیگه خبری از «من کار نمیکنم تا شرایط درست بشه» نیست. چه محیطهایی؟ محیطهایی که availability بالا مهمه مثلا سیستم های امبدد یا بکاند.
مثلا قراره ما مسیریابی یک هواپیما رو انجام بدیم و سیگنال GPS دریافت نمیکنیم، خب به هواپیما بگیم فعلا من کار نمیکنم؟! یعنی چی که کار نمیکنم، با سرعت زیاد داره میره :)))
یا مثلاً توی کلود اگر ارور بدیم و برنامه کرش کنه کنیم چی میشه؟ کوبرنتیز دوباره برنامه رو اجرا میکنه و دوباره با مشکل درگیریم!
پس در این شرایط نمیشه ارور داد و بیخیال شد، بلکه باید با همون چرخ پنچر ادامه داد، برای هر روش هم با خلاقیت خودمون یا با کمک روش های پیشنهاد شده باید یه پلن بی داشته باشیم،
پیاده سازی و تست خود برنامه در کنار اینکه هر قسمتی ممکنه کار نکنه و سناریوهای مختلفش، کار سختیه ولی هزینهی داشتن یه نرم افزار قابل اعتماده.
مثلا چه مشکلاتی؟
مثلاً اگه قراره کانفیگ فایل رو از بیرون لود کنیم, آمادگی نبودنش رو هم داشته باشیم، مثلا یه کانفیگ پیشفرض داشته باشیم (البته کانفیگ چون موقع اولین اجرای برنامه خودش رو نشون میده شاید نیازی هم نباشه)
مثلا اگر داده gps به ما نرسید، با کمک داده های قبلی که ذخیره کردیم و یا ترکیبش با سرعت و شتاب و ... مشکل رو موقتا و حتی نادقیق حل کنیم
یا مثلاً اگر به سرور خارجی درخواست میزنیم و نیست، آمادگی نبودنش رو داشته باشیم، اینجا یکسری پترن که تو صنعت استفاده میشه داریم
مثلا چه پترنهایی؟
+ دوباره درخواست بده: retry pattern
+ به یکی دیگه درخواست بده: fallback
+ اگر خرابه تا یه مدت بهش درخواست نده تا ارور الکی نگیری: circuit breaker
+ اگه سرور خارجی کنده، خیلی صبر نکن تا response time خودت هم بالا نره
+ اگر سرور خارجی دیتا قراره بهت بده، دیتای قبلی رو کش کن.
اینها در سطح کد بودن، در سطح معماری هم میشه از قبل روشهایی رو تدارک دید مثلاً خود دیتابیس رو چطوری High available کنیم، یا روشهایی که بیشتر تو سیستم های امبدد استفاده میشه مثل اینکه یه برنامه رو با چند تا پیاده سازی همزمان اجرا کنیم تا اگر یکیش خراب شد اون یکیها باشن!
منابع:
https://opensource.com/article/19/9/transient-faults-devops
https://www.jrebel.com/blog/microservices-resilience-patterns
https://learn.microsoft.com/en-us/azure/architecture/best-practices/transient-faults
https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/application-resiliency-patterns
یه مثال دیدم که میگفت شما وقتی ماشینتون پنچر میشه صبر میکنید تا تعمیرکار بیاد درستش کنه، یا با همون چرخ های پنجر با سرعت کم ادامه میدین تا به مقصد برسید؟
به نظرم همین توی برنامهنویسی هم مصداق داره، وقتی برنامهمون به ارور میخوره چطوری مدیریتش میکنیم؟ حالا این ارور خیلی وقت ها exceptionه توی زبون های برنامه نویسی، ولی یکم سطح بالاتر ببینیم،
مثلا به یه سرویس خارجی درخواست دادیم و نیست، خب چیکار کنیم؟
یه فایل کانفیگ رو میخوایم لود کنیم ولی نیست.
دیتایی که از سمت کاربر اومده معتبر نیست.
در یک برنامه معمولی جوابِ (احتمالا) درست به خیلی از این سوالا اینه که خب کارکرد برنامه رو متوقف کن و بگو نمیتونم. برنامه کار نکنه تا دوباره با برطرف شدن مشکلات یکی از اول اجراش کنه،
ولی اگر برنامه ما قراره توی یکسری از محیطها اجرا بشه دیگه خبری از «من کار نمیکنم تا شرایط درست بشه» نیست. چه محیطهایی؟ محیطهایی که availability بالا مهمه مثلا سیستم های امبدد یا بکاند.
مثلا قراره ما مسیریابی یک هواپیما رو انجام بدیم و سیگنال GPS دریافت نمیکنیم، خب به هواپیما بگیم فعلا من کار نمیکنم؟! یعنی چی که کار نمیکنم، با سرعت زیاد داره میره :)))
یا مثلاً توی کلود اگر ارور بدیم و برنامه کرش کنه کنیم چی میشه؟ کوبرنتیز دوباره برنامه رو اجرا میکنه و دوباره با مشکل درگیریم!
پس در این شرایط نمیشه ارور داد و بیخیال شد، بلکه باید با همون چرخ پنچر ادامه داد، برای هر روش هم با خلاقیت خودمون یا با کمک روش های پیشنهاد شده باید یه پلن بی داشته باشیم،
پیاده سازی و تست خود برنامه در کنار اینکه هر قسمتی ممکنه کار نکنه و سناریوهای مختلفش، کار سختیه ولی هزینهی داشتن یه نرم افزار قابل اعتماده.
مثلا چه مشکلاتی؟
مثلاً اگه قراره کانفیگ فایل رو از بیرون لود کنیم, آمادگی نبودنش رو هم داشته باشیم، مثلا یه کانفیگ پیشفرض داشته باشیم (البته کانفیگ چون موقع اولین اجرای برنامه خودش رو نشون میده شاید نیازی هم نباشه)
مثلا اگر داده gps به ما نرسید، با کمک داده های قبلی که ذخیره کردیم و یا ترکیبش با سرعت و شتاب و ... مشکل رو موقتا و حتی نادقیق حل کنیم
یا مثلاً اگر به سرور خارجی درخواست میزنیم و نیست، آمادگی نبودنش رو داشته باشیم، اینجا یکسری پترن که تو صنعت استفاده میشه داریم
مثلا چه پترنهایی؟
+ دوباره درخواست بده: retry pattern
+ به یکی دیگه درخواست بده: fallback
+ اگر خرابه تا یه مدت بهش درخواست نده تا ارور الکی نگیری: circuit breaker
+ اگه سرور خارجی کنده، خیلی صبر نکن تا response time خودت هم بالا نره
+ اگر سرور خارجی دیتا قراره بهت بده، دیتای قبلی رو کش کن.
اینها در سطح کد بودن، در سطح معماری هم میشه از قبل روشهایی رو تدارک دید مثلاً خود دیتابیس رو چطوری High available کنیم، یا روشهایی که بیشتر تو سیستم های امبدد استفاده میشه مثل اینکه یه برنامه رو با چند تا پیاده سازی همزمان اجرا کنیم تا اگر یکیش خراب شد اون یکیها باشن!
منابع:
https://opensource.com/article/19/9/transient-faults-devops
https://www.jrebel.com/blog/microservices-resilience-patterns
https://learn.microsoft.com/en-us/azure/architecture/best-practices/transient-faults
https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/application-resiliency-patterns
Opensource.com
3 ways to handle transient faults for DevOps
In electrical engineering, a transient fault is defined as an error condition that vanishes after the power is disconnected and restored.
👍1
All Things Clock, Time and Order in Distributed Systems: Physical Time in Depth
https://medium.com/geekculture/all-things-clock-time-and-order-in-distributed-systems-physical-time-in-depth-3c0a4389a838
https://medium.com/geekculture/all-things-clock-time-and-order-in-distributed-systems-physical-time-in-depth-3c0a4389a838
Medium
All Things Clock, Time and Order in Distributed Systems: Physical Time in Depth
Introduction
Forwarded from Gopher Academy (Bardia)
در مسیر تبدیل شدن به یک مهندس نرمافزار یکی از راه هایی که خیلی میتونه شمارو کمک کنه و مسیر رو براتون شفاف تر کنه، شنیدن پادکست هایی از جنس تجربس.
من این پایین لیستی از چندین پادکست خوب در زمینه مهندسی نرم افزار رو اوردم که میتونید بررسی کنید
- Software Engineering Daily
توی این پادکست خفن میزبان میاد و درخصوص چالش ها توی پروژه های بزرگ با مهندسین نرم افزار شرکت های بزرگ صحبت میکنه و تجربیات خوبی شیر میشه.
softwareengineeringdaily.com
- Software Engineering Radio
پادکست رادیوی مهندسی نرم افزار، یکی از اون پادکست های پرمحتواییه که آدم های خفن هر هفته درخصوص چالش های طراحی نرم افزار صحبت میکنند.
http://se-radio.net
- CaSE
پادکست Conversations about Software Engineering سعی کرده هر سه هفته یک اپیزود برای افرادی که علاقه مند به معماری و مهندسی نرم افزار هستند رو منتشر کنه.
پادکست های رلیز شده مصاحبه طور هستند و بنظرم جذابن.
case-podcast.org
- Changelog
پادکست Changelog هم واقعا باحاله، خیلی از زمینه های اپن سورس، توسعه وب و برنامه نویسی و.. رو توی اپیزود هاش ساپورت میکنه و تا الان نزدیک ۵۷۰ اپیزود ضبط شده رو قرار داده روی سایتش.
changelog.com
- The Cloudcast
اگه شماهم علاقه مند به Cloud, Serverless architecture, aws ,.. هستید احتمالا این پادکست از بقیه براتون جذاب تره و هر هفته داره اپیزود های جدیدی در زمینه کلاود به اشتراک میزاره.
https://thecloudcast.net
- CodeNewbie
این پادکست هم با هدف باحالی اومده، آدمای مختلف داستان رسیدنشون از صفر به پوزیشن های بالایی که الان دارن رو توی هر اپیزود میگن و میگن که چطوری از یک کورس ساده به شرکت های بزرگ نرم افزاری رسیدن.
http://codenewbie.org/podcast
- System Design
یکی از جذاب ترین پادکست ها برای افرادی که به سیستم دیزاین علاقه دارن، اینجا مصاحبه های سیستم دیزاین بصورت پادکست ضبط میشن و آدمای با تجربه چالش های سیستم دیزاین مختلف رو حل میکنند.
systemdesign.buzzsprout.com
- Soft Skills Engineering
این بار دیگه قرار نیست محتوای فنی و کد بشنوید، با این پادکست شما قراره مهم ترین سافت اسکیل هارو تقویت کنید، بنظرم از دستش ندید.
softskills.audio
- CoRecursive
این پادکست هم عناوین باحالی داره، آدم های بزرگی راجع به مسائل جذابی صحبت کردن، میتونید چک کنید.
corecursive.com
#DevTwitter | <Reza/>
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
من این پایین لیستی از چندین پادکست خوب در زمینه مهندسی نرم افزار رو اوردم که میتونید بررسی کنید
- Software Engineering Daily
توی این پادکست خفن میزبان میاد و درخصوص چالش ها توی پروژه های بزرگ با مهندسین نرم افزار شرکت های بزرگ صحبت میکنه و تجربیات خوبی شیر میشه.
softwareengineeringdaily.com
- Software Engineering Radio
پادکست رادیوی مهندسی نرم افزار، یکی از اون پادکست های پرمحتواییه که آدم های خفن هر هفته درخصوص چالش های طراحی نرم افزار صحبت میکنند.
http://se-radio.net
- CaSE
پادکست Conversations about Software Engineering سعی کرده هر سه هفته یک اپیزود برای افرادی که علاقه مند به معماری و مهندسی نرم افزار هستند رو منتشر کنه.
پادکست های رلیز شده مصاحبه طور هستند و بنظرم جذابن.
case-podcast.org
- Changelog
پادکست Changelog هم واقعا باحاله، خیلی از زمینه های اپن سورس، توسعه وب و برنامه نویسی و.. رو توی اپیزود هاش ساپورت میکنه و تا الان نزدیک ۵۷۰ اپیزود ضبط شده رو قرار داده روی سایتش.
changelog.com
- The Cloudcast
اگه شماهم علاقه مند به Cloud, Serverless architecture, aws ,.. هستید احتمالا این پادکست از بقیه براتون جذاب تره و هر هفته داره اپیزود های جدیدی در زمینه کلاود به اشتراک میزاره.
https://thecloudcast.net
- CodeNewbie
این پادکست هم با هدف باحالی اومده، آدمای مختلف داستان رسیدنشون از صفر به پوزیشن های بالایی که الان دارن رو توی هر اپیزود میگن و میگن که چطوری از یک کورس ساده به شرکت های بزرگ نرم افزاری رسیدن.
http://codenewbie.org/podcast
- System Design
یکی از جذاب ترین پادکست ها برای افرادی که به سیستم دیزاین علاقه دارن، اینجا مصاحبه های سیستم دیزاین بصورت پادکست ضبط میشن و آدمای با تجربه چالش های سیستم دیزاین مختلف رو حل میکنند.
systemdesign.buzzsprout.com
- Soft Skills Engineering
این بار دیگه قرار نیست محتوای فنی و کد بشنوید، با این پادکست شما قراره مهم ترین سافت اسکیل هارو تقویت کنید، بنظرم از دستش ندید.
softskills.audio
- CoRecursive
این پادکست هم عناوین باحالی داره، آدم های بزرگی راجع به مسائل جذابی صحبت کردن، میتونید چک کنید.
corecursive.com
#DevTwitter | <Reza/>
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers