#myTechNotes #concurrency #DeepDive
Note 2.
Поели немецких колбас, запивая темным пивом, и увидели что такое немецкое рождество. Подарили всем подарков, получили свои. Посомтрели "Один дома", так как немцы "Иронию судьбы не смотрят". А на следующий денб, так и вообще, выпал снег. Волшебно!
Вроде бы все хорошо, тепло и спокойно. Но мне, как ни странно, начали лезть в голову мысли о том, что я не до конца понимаю что такие Concurrency. Крейзи, правда? В общем, вчерашний вечер потратил на то, чтобы лучше разобраться в этом всем.
Я не до конца понимал как работают thread-ы (Потоки/треды). Раньше было понимание, что треды исполняются как то параллельно, что и дает нам ускорение вычислений. Но что меня смутило, так это то, что Треды у нас находятся внутри одного процесса, и выполняются на одном процессоре. А раз так, то откуда мы получаем ускорение, если процессор не может выполнять более одной инструкции в один момент времени.
Как оказалось, у устройства процессов, тредов, и корутин очень много общего. ОС постоянно бегает по всем процессам и постепенно продвигает их вперед. Все происходит настолько быстро, что человеческому глазу ничего не видно. Через какое то время умные люди придумали использовать треды, чтобы не переключаться между тяжелыми процессами. Переключение между тредами происходит намного быстрее, так как часть контекста они разделюят друг с другом, памяти выделяется меньше, и подмены переменных происходит меньше. Корутины - эта та же самая идея, когда Runtime проверяет в цикле доступность отдельных процедур, продвигая их вперед. Это еще более мелкая абстракция, которая работает внутри одного треда.
Откуда же приходит ускорение и в каких случаях?
Я в очередной раз убедился в том, что Concurrency works best with I/O bound tasks. Если при определенной процедуре CPU ничего не делает (is Idle), а просто простаивает (например, спит, ждет ответа от запроса к сайту, или ждет когда подгрузятся данные), то ничего полезного не происходит. Таким образом, мы можем "попросить" программу пойти дальше, чтобы исполнить что-нибудь другое в программе (другую корутину/тред).
С другой стороны, в случае же с CPU Bound tasks, наш процессор работает на всю мощность и переключаться между контекстами Корутин огромного преимущества не дает.
Вышесказанное это очень упращенная модель, чтобы не усложнять мое понимание. Фактически я понимаю, что простой может быть по различным причинам и не обязательно при IO. Преимуществ у использования Тредов больше чем просто при IO. Однако, я не могу представить, что в тех бэкэнд приложениях, над которыми я буду работать мне придется расматривать что-то более сложное.
Я уверен, что я еще буду возвращаться к этой теме в будущем, с performance tests и более сложными use-cases. Также хочу посравнивать concurrency модели в Golang, Python, и Kotlin. Но, на пока, более чем достаточно.
Если тебе тоже интересно почитать на эту тему и не хочешь тратить много времени на поиск полезных ресурсов, то рекомендую след:
Очень крутой, простой, и короткий курс на Coursera:
- https://www.coursera.org/learn/golang-concurrency
И статьи
- https://www.reddit.com/r/golang/comments/ddc1j3/what_is_the_point_of_concurrency/?sort=top
- https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/
- https://medium.com/@ankur_anand/illustrated-tales-of-go-runtime-scheduler-74809ef6d19b
__Если у тебя есть чем поделиться, дополнить, поправить, пиши, смело!__
Note 2.
Поели немецких колбас, запивая темным пивом, и увидели что такое немецкое рождество. Подарили всем подарков, получили свои. Посомтрели "Один дома", так как немцы "Иронию судьбы не смотрят". А на следующий денб, так и вообще, выпал снег. Волшебно!
Вроде бы все хорошо, тепло и спокойно. Но мне, как ни странно, начали лезть в голову мысли о том, что я не до конца понимаю что такие Concurrency. Крейзи, правда? В общем, вчерашний вечер потратил на то, чтобы лучше разобраться в этом всем.
Я не до конца понимал как работают thread-ы (Потоки/треды). Раньше было понимание, что треды исполняются как то параллельно, что и дает нам ускорение вычислений. Но что меня смутило, так это то, что Треды у нас находятся внутри одного процесса, и выполняются на одном процессоре. А раз так, то откуда мы получаем ускорение, если процессор не может выполнять более одной инструкции в один момент времени.
Как оказалось, у устройства процессов, тредов, и корутин очень много общего. ОС постоянно бегает по всем процессам и постепенно продвигает их вперед. Все происходит настолько быстро, что человеческому глазу ничего не видно. Через какое то время умные люди придумали использовать треды, чтобы не переключаться между тяжелыми процессами. Переключение между тредами происходит намного быстрее, так как часть контекста они разделюят друг с другом, памяти выделяется меньше, и подмены переменных происходит меньше. Корутины - эта та же самая идея, когда Runtime проверяет в цикле доступность отдельных процедур, продвигая их вперед. Это еще более мелкая абстракция, которая работает внутри одного треда.
Откуда же приходит ускорение и в каких случаях?
Я в очередной раз убедился в том, что Concurrency works best with I/O bound tasks. Если при определенной процедуре CPU ничего не делает (is Idle), а просто простаивает (например, спит, ждет ответа от запроса к сайту, или ждет когда подгрузятся данные), то ничего полезного не происходит. Таким образом, мы можем "попросить" программу пойти дальше, чтобы исполнить что-нибудь другое в программе (другую корутину/тред).
С другой стороны, в случае же с CPU Bound tasks, наш процессор работает на всю мощность и переключаться между контекстами Корутин огромного преимущества не дает.
Вышесказанное это очень упращенная модель, чтобы не усложнять мое понимание. Фактически я понимаю, что простой может быть по различным причинам и не обязательно при IO. Преимуществ у использования Тредов больше чем просто при IO. Однако, я не могу представить, что в тех бэкэнд приложениях, над которыми я буду работать мне придется расматривать что-то более сложное.
Я уверен, что я еще буду возвращаться к этой теме в будущем, с performance tests и более сложными use-cases. Также хочу посравнивать concurrency модели в Golang, Python, и Kotlin. Но, на пока, более чем достаточно.
Если тебе тоже интересно почитать на эту тему и не хочешь тратить много времени на поиск полезных ресурсов, то рекомендую след:
Очень крутой, простой, и короткий курс на Coursera:
- https://www.coursera.org/learn/golang-concurrency
И статьи
- https://www.reddit.com/r/golang/comments/ddc1j3/what_is_the_point_of_concurrency/?sort=top
- https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/
- https://medium.com/@ankur_anand/illustrated-tales-of-go-runtime-scheduler-74809ef6d19b
__Если у тебя есть чем поделиться, дополнить, поправить, пиши, смело!__
Coursera
Concurrency in Go
Offered by University of California, Irvine. Learn how ... Enroll for free.
#distributed #systems
A Distributed Systems Reading List
Сохраняю на потом
https://dancres.github.io/Pages/
A Distributed Systems Reading List
Сохраняю на потом
https://dancres.github.io/Pages/
„Chillin‘“ at Amazon
#mock #interview #feedback Как обещал, даю отзыв по mock interview. Что было хорошо: - Прежде чем преступить к задачке, ты начал с уточняющих вопросов, спросил про input/output, написал пару тест кейсов, подумал об edge кейсах. Как ни странно, но эта стадия…
#mock #interview #feedback
Праздники праздниками, а social contributions - эт святое. Как обещал, даю отзыв по mock interview.
Disclaimer: все ниже сказанное не отражает мнение моего работодателя, а является моим личным мнением
Что понравилось:
- Прежде чем начать решать задачку, ты остановился на уточнении деталей, продумывании тест кейсов, и предложении подхода. Это, имхо, самый важный этап в собеседовании, чтобы достичь успеха.
- Во время всей встрече, ты проговаривал о чем ты думал и почему ты принимал то или иное решение.
- По окончанию решения, ты прогнал тест кейсы через свое решение, чтобы удостовериться, что решение работает
Что можно улучшить:
- Делай только то, что нужно: Когда ты хотел оптимизировать свое решение в самом конце, то возможно ты пытался сделать то, чего от тебя не требовали. Если бы ты знал, что объемы маленькие (скажем 1000 человек), то эту оптимизацию можно было бы проигнорировать. А в ином случае, на огромных данных, ты бы сразу понимал, предлагая решение, что его нужно улучшать. Совет: Поэтому, на этапе уточнения лучше всего проговорить заранее о потенциальных объемах данных. Понимая задачу, тебе будет легче подобрать правильное решение, не усложняя задачу.
- Всегда оценивай сложность алгоритмов Важно, на этапе прояснения деталей проговорить о сложности алгоритма, не дожидаясь вопроса от интервьюера. Это не просто покажет твою зрелость, но и даст тебе понимание, что твое решение вписывается в картину ожидаемого объема данных.
- Думай об edge-cases Во время продумывания тест кейсов, в дополнение к простым общим тест кейсам, подумай а об edge cases. Например, то, о чем ты подумал к концу собеседования, где у тебя один сотрудник рапортует другому: в одном path.
- Сразу пиши правильно (но без фанатизма) Например, выбор имен (dsf, children), в задаче об организационной структуре, мог бы быть проделан получше. (nitpick/для fresh-grad position это менее важно)
Резюме:
В целом, я заметил, что ты правльно понимаешь общие и базовые понятия структур данных и алгоритмов, постоянно проговариваешь о чем думаешь, и смог предложить + реализовать свое решение. Учитывая, что изначально объемы данных не были проговорены, то дальнейшая оценка решения будет зависеть от интервьюера: к этом либо можно прицепиться, либо повезет и собеседник проигнорирует.
Next steps:
- Подумай и потренеруй как ты подходишь к прояснению деталей: сделай для себя некий чек-лист того о чем ты хочешь спросить и что проверить.
- Учись называть переменные правильно (не для интервью, а для себя!)
Если думаешь, что это будет интересно кому-нибудь из твоих друзей, то можешь share.
https://www.youtube.com/watch?v=_370p0F98pI
Праздники праздниками, а social contributions - эт святое. Как обещал, даю отзыв по mock interview.
Disclaimer: все ниже сказанное не отражает мнение моего работодателя, а является моим личным мнением
Что понравилось:
- Прежде чем начать решать задачку, ты остановился на уточнении деталей, продумывании тест кейсов, и предложении подхода. Это, имхо, самый важный этап в собеседовании, чтобы достичь успеха.
- Во время всей встрече, ты проговаривал о чем ты думал и почему ты принимал то или иное решение.
- По окончанию решения, ты прогнал тест кейсы через свое решение, чтобы удостовериться, что решение работает
Что можно улучшить:
- Делай только то, что нужно: Когда ты хотел оптимизировать свое решение в самом конце, то возможно ты пытался сделать то, чего от тебя не требовали. Если бы ты знал, что объемы маленькие (скажем 1000 человек), то эту оптимизацию можно было бы проигнорировать. А в ином случае, на огромных данных, ты бы сразу понимал, предлагая решение, что его нужно улучшать. Совет: Поэтому, на этапе уточнения лучше всего проговорить заранее о потенциальных объемах данных. Понимая задачу, тебе будет легче подобрать правильное решение, не усложняя задачу.
- Всегда оценивай сложность алгоритмов Важно, на этапе прояснения деталей проговорить о сложности алгоритма, не дожидаясь вопроса от интервьюера. Это не просто покажет твою зрелость, но и даст тебе понимание, что твое решение вписывается в картину ожидаемого объема данных.
- Думай об edge-cases Во время продумывания тест кейсов, в дополнение к простым общим тест кейсам, подумай а об edge cases. Например, то, о чем ты подумал к концу собеседования, где у тебя один сотрудник рапортует другому: в одном path.
- Сразу пиши правильно (но без фанатизма) Например, выбор имен (dsf, children), в задаче об организационной структуре, мог бы быть проделан получше. (nitpick/для fresh-grad position это менее важно)
Резюме:
В целом, я заметил, что ты правльно понимаешь общие и базовые понятия структур данных и алгоритмов, постоянно проговариваешь о чем думаешь, и смог предложить + реализовать свое решение. Учитывая, что изначально объемы данных не были проговорены, то дальнейшая оценка решения будет зависеть от интервьюера: к этом либо можно прицепиться, либо повезет и собеседник проигнорирует.
Next steps:
- Подумай и потренеруй как ты подходишь к прояснению деталей: сделай для себя некий чек-лист того о чем ты хочешь спросить и что проверить.
- Учись называть переменные правильно (не для интервью, а для себя!)
Если думаешь, что это будет интересно кому-нибудь из твоих друзей, то можешь share.
https://www.youtube.com/watch?v=_370p0F98pI
Начинаю путаться в тэгах. Пиню для себя и других
Про жизнь в Амазон: #LifeAtAmazon
Architecture:
#systems #design #architecture #systems_design #db #distributed
Language specific:
#python #go
Other:
#ML, #myTechNotes, #DeepDive
About interviews:
Время от времени, преимущественно во время отпуска, провожу Mock интервью.
Все, связанное с интервью, выкладываю по тэгам: #interview #mock #systems_design
Если у тебя будет скоро интервью и тебе нужен Mock Interview, то можешь написать, мне. И если у меня будет получаться по времени, то сможем организовать. Имей в виду, что mock интервью я записываю на видео и выкладываю для других. Также рекомендую посмотреть предыдущие записи, чтобы не допускать примитивные ошибки: https://www.youtube.com/playlist?list=PL3tja-7IZ-wXHY-lvb32-zGnRJaS5yCkU
Про жизнь в Амазон: #LifeAtAmazon
Architecture:
#systems #design #architecture #systems_design #db #distributed
Language specific:
#python #go
Other:
#ML, #myTechNotes, #DeepDive
About interviews:
Время от времени, преимущественно во время отпуска, провожу Mock интервью.
Все, связанное с интервью, выкладываю по тэгам: #interview #mock #systems_design
Если у тебя будет скоро интервью и тебе нужен Mock Interview, то можешь написать, мне. И если у меня будет получаться по времени, то сможем организовать. Имей в виду, что mock интервью я записываю на видео и выкладываю для других. Также рекомендую посмотреть предыдущие записи, чтобы не допускать примитивные ошибки: https://www.youtube.com/playlist?list=PL3tja-7IZ-wXHY-lvb32-zGnRJaS5yCkU
YouTube
Mock Interviews
Share your videos with friends, family, and the world
„Chillin‘“ at Amazon pinned «Начинаю путаться в тэгах. Пиню для себя и других Про жизнь в Амазон: #LifeAtAmazon Architecture: #systems #design #architecture #systems_design #db #distributed Language specific: #python #go Other: #ML, #myTechNotes, #DeepDive About interviews: Время…»
В субботу, в 10 утра по Алматинскому времени, будет последний мок в этом сезоне! :)) Дальше праздники заканчиваются и я возврщаюсь к работе.
Ну а в целом, всех с Наступающих НГ!
Ну а в целом, всех с Наступающих НГ!
С новым годом, друзья!
Наш следующий Mock интервью начнется через 20 минут!
Topic: Technical Mock Interview #3 (Algorithms, Data Structures)
Time: Jan 2, 2021 10:00 AM Amsterdam, Berlin, Rome, Stockholm, Vienna
Join Zoom Meeting
https://us05web.zoom.us/j/83992975676?pwd=a3FXbHRiR014eGFRVitrVnNBZUQ1UT09
Meeting ID: 839 9297 5676
Passcode: FRwB0q
Наш следующий Mock интервью начнется через 20 минут!
Topic: Technical Mock Interview #3 (Algorithms, Data Structures)
Time: Jan 2, 2021 10:00 AM Amsterdam, Berlin, Rome, Stockholm, Vienna
Join Zoom Meeting
https://us05web.zoom.us/j/83992975676?pwd=a3FXbHRiR014eGFRVitrVnNBZUQ1UT09
Meeting ID: 839 9297 5676
Passcode: FRwB0q
Zoom Video
Join our Cloud HD Video Meeting
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference room solution…
#mock #interview #feedback
Вчера утром была последняя, за мой заканчивающийся отпуск, сессия с mock interview. Участие в mock interview, уверен, уже очень полезно для собеседника. Но, чтобы принести чуть больше пользы тем кто ко мне обращается, я, как обычно, делюсь письменным отзывом с детальной аналитикой.
Disclaimer: все ниже сказанное не отражает мнение моего работодателя, а является моим личным мнением
Видеозапись mock interview: https://www.youtube.com/watch?v=y8G9vLm4gEI
Решение кандидата: https://pastebin.com/yzvSVD57
Что понравилось:
- У тебя есть базовый материал, ты понимаешь принципы оценки производительности своего алгоритма, и можешь продумывать code flow
- Предложил простое и посложнее решение и попробовал реализовать
Что улучшить:
- Не спеши!: Не спеши с решением пока не изучил задание полностью и не уделил достаточно времени на продумывание тестовых кейсов. Твой алгоритм будет работать немного криво если в данных присутствуют отрицательные числа. Т.е. точно также как ты допустил, что в данных может быть
- По окончанию написания софта, очень важно его тестировать: Не спеши говорить, что ты закончил, пока не удостоверишься, что твое решение правильное. В идеале когда ты говоришь, что ты дорешал, то ты должен быть уверен, что твое решение верно. В твоем случае, ты провел тестирование своего решения только после просьбы собеседника и, к общему сожалению, в процессе ты обнаружил что решение имеет баги
- Оценка решения на сложность была не достаточно точной В конце интервью ты сказал, что твое решение не использует дополнительной памяти, так как пере-использует существующий список. Что будет если у тебя на вход приходят список чисел от 1 миллиона до 2х миллионов? В твоем решении ты расширяешь список, и тем самым задействуется больше памяти
- почитай про re-sizing array. Это не происходит бесплатно.
- nit-pick: Кстати, не до конца было ясно зачем нужно расширять список, когда можно просто игнорировать значения выше длины списка
- Поработай над читабельностью кода: например,
Резюме:
В общем и целом, у тебя есть база, но есть еще над чем работать. Главная проблема, на мой взгляд, это то, что ты спешишь решить задание. Это сказывается на качестве проверки корнер кейсов, имплементации решения, и выводах.
Next steps:
- Поработай над своим подходом: видно, что у тебя есть базовые знания, но из-за спешки ты допустил очень много ошибок. Если решаешь задачки на LeetCode, то обрати внимание на показатель Acceptance Rate, который, если не ошибаюсь, показывает как часто у тебя получается решить задачку с первой попытки так, что все тейст кейсы проходят успешно.
- Потренируй свой навык объяснения того что ты делаешь (и почему!). Лучше всего, имхо, это делать на популярных алгоритмах (сортировки, поиска и тд), либо на задачах (leetcode, hackerrank alike).
- (без фанатизма) Учись писать читабельный код: используй понянтые для читающего названия, добавляй комментарии, если это улучшает читабельность кода
__________
share if you think it can be useful for your friends
Мой телеграм: https://t.me/webapparch
Вчера утром была последняя, за мой заканчивающийся отпуск, сессия с mock interview. Участие в mock interview, уверен, уже очень полезно для собеседника. Но, чтобы принести чуть больше пользы тем кто ко мне обращается, я, как обычно, делюсь письменным отзывом с детальной аналитикой.
Disclaimer: все ниже сказанное не отражает мнение моего работодателя, а является моим личным мнением
Видеозапись mock interview: https://www.youtube.com/watch?v=y8G9vLm4gEI
Решение кандидата: https://pastebin.com/yzvSVD57
Что понравилось:
- У тебя есть базовый материал, ты понимаешь принципы оценки производительности своего алгоритма, и можешь продумывать code flow
- Предложил простое и посложнее решение и попробовал реализовать
Что улучшить:
- Не спеши!: Не спеши с решением пока не изучил задание полностью и не уделил достаточно времени на продумывание тестовых кейсов. Твой алгоритм будет работать немного криво если в данных присутствуют отрицательные числа. Т.е. точно также как ты допустил, что в данных может быть
0, точно также может быть и -1. Если бы ты подумала об этих случаях, то мог бы оценить свое предложение на правильностью- По окончанию написания софта, очень важно его тестировать: Не спеши говорить, что ты закончил, пока не удостоверишься, что твое решение правильное. В идеале когда ты говоришь, что ты дорешал, то ты должен быть уверен, что твое решение верно. В твоем случае, ты провел тестирование своего решения только после просьбы собеседника и, к общему сожалению, в процессе ты обнаружил что решение имеет баги
- Оценка решения на сложность была не достаточно точной В конце интервью ты сказал, что твое решение не использует дополнительной памяти, так как пере-использует существующий список. Что будет если у тебя на вход приходят список чисел от 1 миллиона до 2х миллионов? В твоем решении ты расширяешь список, и тем самым задействуется больше памяти
- почитай про re-sizing array. Это не происходит бесплатно.
- nit-pick: Кстати, не до конца было ясно зачем нужно расширять список, когда можно просто игнорировать значения выше длины списка
- Поработай над читабельностью кода: например,
a[a[1]] и a[1] читается не очень комфортно. Не стесняйся добавлять комментарии, выносить в отдельные функцииРезюме:
В общем и целом, у тебя есть база, но есть еще над чем работать. Главная проблема, на мой взгляд, это то, что ты спешишь решить задание. Это сказывается на качестве проверки корнер кейсов, имплементации решения, и выводах.
Next steps:
- Поработай над своим подходом: видно, что у тебя есть базовые знания, но из-за спешки ты допустил очень много ошибок. Если решаешь задачки на LeetCode, то обрати внимание на показатель Acceptance Rate, который, если не ошибаюсь, показывает как часто у тебя получается решить задачку с первой попытки так, что все тейст кейсы проходят успешно.
- Потренируй свой навык объяснения того что ты делаешь (и почему!). Лучше всего, имхо, это делать на популярных алгоритмах (сортировки, поиска и тд), либо на задачах (leetcode, hackerrank alike).
- (без фанатизма) Учись писать читабельный код: используй понянтые для читающего названия, добавляй комментарии, если это улучшает читабельность кода
__________
share if you think it can be useful for your friends
Мой телеграм: https://t.me/webapparch
YouTube
Mock Interview #3 Algorithms, Data Structures [ru]
#mock #interview #algorithms #technical #faang
My telegram channel: https://t.me/webapparch
My telegram channel: https://t.me/webapparch
#myTechNotes #aws #network #DeepDive
Note 3.
Продолжаю копать тему сетей, чтобы не работать со всем этим как с black-box.
Поигрался с AWS VPC:
- Private Subnet для сервков с приложениями
- Public Subnets с bastion host, чтобы запрыгивать через ssh на серваки с приложениями
- NAT Gateway, чтобы позволить ходить из сервков с приложениями в интернет за обновлением софта
- Routers, чтобы поставить коммуникацию между Subnets
- Internet Gateway, чтобы можно было ходить в интернет,
И самое главное, накинул на это все несколько Network Access Control Lists Rules, дабы обезопасить доступ к тому или иному сервису.
Проблема:
Проблема наступила когда я пытался подключиться через ssh без открытия обратных ответов к ephemeral ports моей домашней машины. Вроде бы указал, чтобы TCP трафик на порт 22 ходил в обе стороны (т.е. Outbound, Inbound traffic). Но не тут-то было...
Learnings:
До 2021 я не особо задумывался как происходит подключение через ssh, https, etc, с точки зрения портов на машине клиента. Пришлось поразбираться и я обнаружил (сейчас уже конечно это кажется очевидным), что при отркытии TCP соединении клиент использует один из ephemeral портов, чтобы получать ответы от сервера. Это позволяет нам открывать сразу несколько соединений с сервером как для ssh (Порт 22) так и для http/https соединения (порты 80/443). Открыв ephemeral ports, все сразу завелось!)
Ссылки
Как всегда, делюсь ссылками, которые помогли мне понять все это простым языком. Если тебе интересно и не хочешь тратить время на поиски-и-происки, забирай!
В целом о TCP Ports:
- https://www.youtube.com/watch?v=mykX2YONRwE
О "Well-Known Ports":
- https://www.youtube.com/watch?v=RDotMcs0Erg
Об "Ephemeral Ports":
- https://www.reddit.com/r/aws/comments/cyzzyy/eli5_what_are_ephemeral_ports/
- https://www.whizlabs.com/blog/ephemeral-ports/
Также ниже прикрепляю свой рабочий черновик с диаграммой
Note 3.
Продолжаю копать тему сетей, чтобы не работать со всем этим как с black-box.
Поигрался с AWS VPC:
- Private Subnet для сервков с приложениями
- Public Subnets с bastion host, чтобы запрыгивать через ssh на серваки с приложениями
- NAT Gateway, чтобы позволить ходить из сервков с приложениями в интернет за обновлением софта
- Routers, чтобы поставить коммуникацию между Subnets
- Internet Gateway, чтобы можно было ходить в интернет,
И самое главное, накинул на это все несколько Network Access Control Lists Rules, дабы обезопасить доступ к тому или иному сервису.
Проблема:
Проблема наступила когда я пытался подключиться через ssh без открытия обратных ответов к ephemeral ports моей домашней машины. Вроде бы указал, чтобы TCP трафик на порт 22 ходил в обе стороны (т.е. Outbound, Inbound traffic). Но не тут-то было...
Learnings:
До 2021 я не особо задумывался как происходит подключение через ssh, https, etc, с точки зрения портов на машине клиента. Пришлось поразбираться и я обнаружил (сейчас уже конечно это кажется очевидным), что при отркытии TCP соединении клиент использует один из ephemeral портов, чтобы получать ответы от сервера. Это позволяет нам открывать сразу несколько соединений с сервером как для ssh (Порт 22) так и для http/https соединения (порты 80/443). Открыв ephemeral ports, все сразу завелось!)
Ссылки
Как всегда, делюсь ссылками, которые помогли мне понять все это простым языком. Если тебе интересно и не хочешь тратить время на поиски-и-происки, забирай!
В целом о TCP Ports:
- https://www.youtube.com/watch?v=mykX2YONRwE
О "Well-Known Ports":
- https://www.youtube.com/watch?v=RDotMcs0Erg
Об "Ephemeral Ports":
- https://www.reddit.com/r/aws/comments/cyzzyy/eli5_what_are_ephemeral_ports/
- https://www.whizlabs.com/blog/ephemeral-ports/
Также ниже прикрепляю свой рабочий черновик с диаграммой
YouTube
What is a TCP port and how is it used during connections?
The transmission control protocol (TCP) provides an additional level of naming that helps organize data transfer between computers connected to the internet. In addition to the internet protocol (IP) address that identifies a computer, TCP adds two port numbers…
„Chillin‘“ at Amazon
#myTechNotes #concurrency #DeepDive Note 2. Поели немецких колбас, запивая темным пивом, и увидели что такое немецкое рождество. Подарили всем подарков, получили свои. Посомтрели "Один дома", так как немцы "Иронию судьбы не смотрят". А на следующий денб…
#systems #design #performance
Уау!
Пару недель назад разбирался с concurrency и прочими вещами. Вышел курс от MIT на тему оптимизации производительности ПО.
Сохраняю для себя, чтобы покопать тему еще глубже в следующий отпуск!
https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-172-performance-engineering-of-software-systems-fall-2018/lecture-videos/index.htm
Уау!
Пару недель назад разбирался с concurrency и прочими вещами. Вышел курс от MIT на тему оптимизации производительности ПО.
Сохраняю для себя, чтобы покопать тему еще глубже в следующий отпуск!
https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-172-performance-engineering-of-software-systems-fall-2018/lecture-videos/index.htm
#team
Время от времени читаю и смотрю что нибудь на тему культуры команд, так как большой фанат идеи построения правильной и динамичной атмосферы. Нашел очередное хорошее выступление, где спикер делится своим опытом как она меняла кульруры к лучшему.
Я всегда был за идею в Informal Leadership. Другими словами, чтобы что-то изменить в команде, тебе не нужно быть менеджером или тим лидом. Наоборот, чем раньше ты начнешь предпринимать попытки влияния на культуру команды в сторону улучшения, тем раньше ты станешь на шаг ближе к тому, чтобы стать более крутым инженером.
Когда будешь смотреть, попробуй провести параллель со своей командой, подумай можно ли что-нибудь изменить у вас и возможно в этом выступлении ты сможешь найти ответ на свои вопросы.
И да, крутая культура, точно того стоит!
https://www.youtube.com/watch?v=fIql6Kz4GIQ
Время от времени читаю и смотрю что нибудь на тему культуры команд, так как большой фанат идеи построения правильной и динамичной атмосферы. Нашел очередное хорошее выступление, где спикер делится своим опытом как она меняла кульруры к лучшему.
Я всегда был за идею в Informal Leadership. Другими словами, чтобы что-то изменить в команде, тебе не нужно быть менеджером или тим лидом. Наоборот, чем раньше ты начнешь предпринимать попытки влияния на культуру команды в сторону улучшения, тем раньше ты станешь на шаг ближе к тому, чтобы стать более крутым инженером.
Когда будешь смотреть, попробуй провести параллель со своей командой, подумай можно ли что-нибудь изменить у вас и возможно в этом выступлении ты сможешь найти ответ на свои вопросы.
И да, крутая культура, точно того стоит!
https://www.youtube.com/watch?v=fIql6Kz4GIQ
YouTube
How to Debug Your Team
Video with transcript included: http://bit.ly/38gqyHT
Lisa van Gelder tells stories about how she debugged teams at three companies - Stride, Bauer Xcel & Meetup, and the surprising and unintentional consequences of not giving teams what they…
Lisa van Gelder tells stories about how she debugged teams at three companies - Stride, Bauer Xcel & Meetup, and the surprising and unintentional consequences of not giving teams what they…
Forwarded from запуск завтра
Супер история о том, как Амазон чуть не умер и переехал с серверов Sun на Linux. Это — история зарождения Amazon Web Services — облака, на котором сегодня работает добрая половина интернета.
Рассказывает один из непосредственных участников.
Самые впечатляющие моменты:
❧ в 2000 лопнул пузырь доткомов — технические компании обесценились в сотни раз, на фондовом рынке кончились деньги и Amazon начал жечь собственные средства — 1 миллиард долларов в год; самой крупной статьей расходов были серверы — их делал Sun, они стоили дорого;
❧ можно было перекупить серверы Sun у компаний, обанкротившихся на пузыре доткомов, но техдир Амазона пошел ва-банк — решил переехать с Sun на обычное железо Hewlett Packard на Линуксе; ядру лунукса тогда было всего 6 лет;
❧ на время переезда они остановили ВСЮ продуктовую разработку! ВСЕ занимались только переездом. В бэклоге лежали сотни функций для увеличения продаж, но все ждали, пока закончится переезд;
❧ заморозка развития сервиса привела к падению продаж → пришлось повышать цены на товары → продажи упали ещё сильнее, запустилась «спираль смерти»;
❧ у Амазона оставалось буквально несколько кварталов до смерти, когда деньги на счету кончатся, но они успели и запустили всё нормально, стоимость масштабирования инфраструктуры упала на 80%;
❧ продажи — сезонный бизнес и Безос придумал, почему бы не сдавать простаивающие серверы в низкий сезон другим компаниям? На презентации он привел аналогию с электрической сетью — в 1900 годы каждый завод строил свою собственную электростанцию, почему бы не сделать «электрическую сеть» для IT? Плюс это круто сочеталось с его идеей разделить команды внутри компании, чтобы команды могли развиваться самостоятельно — каждая команда стала независимым API.
Ну а дальше вы знаете. Сегодня Амазон — это не только интернет-магазин, но и одна из крупнейших IT компаний планеты.
https://twitter.com/DanRose999/status/1347677573900242944
Рассказывает один из непосредственных участников.
Самые впечатляющие моменты:
❧ в 2000 лопнул пузырь доткомов — технические компании обесценились в сотни раз, на фондовом рынке кончились деньги и Amazon начал жечь собственные средства — 1 миллиард долларов в год; самой крупной статьей расходов были серверы — их делал Sun, они стоили дорого;
❧ можно было перекупить серверы Sun у компаний, обанкротившихся на пузыре доткомов, но техдир Амазона пошел ва-банк — решил переехать с Sun на обычное железо Hewlett Packard на Линуксе; ядру лунукса тогда было всего 6 лет;
❧ на время переезда они остановили ВСЮ продуктовую разработку! ВСЕ занимались только переездом. В бэклоге лежали сотни функций для увеличения продаж, но все ждали, пока закончится переезд;
❧ заморозка развития сервиса привела к падению продаж → пришлось повышать цены на товары → продажи упали ещё сильнее, запустилась «спираль смерти»;
❧ у Амазона оставалось буквально несколько кварталов до смерти, когда деньги на счету кончатся, но они успели и запустили всё нормально, стоимость масштабирования инфраструктуры упала на 80%;
❧ продажи — сезонный бизнес и Безос придумал, почему бы не сдавать простаивающие серверы в низкий сезон другим компаниям? На презентации он привел аналогию с электрической сетью — в 1900 годы каждый завод строил свою собственную электростанцию, почему бы не сделать «электрическую сеть» для IT? Плюс это круто сочеталось с его идеей разделить команды внутри компании, чтобы команды могли развиваться самостоятельно — каждая команда стала независимым API.
Ну а дальше вы знаете. Сегодня Амазон — это не только интернет-магазин, но и одна из крупнейших IT компаний планеты.
https://twitter.com/DanRose999/status/1347677573900242944
Прикольная статья про парня, который упрямо пытался найти уязвимость в Youtube и в итоге сделал это
https://bugs.xdavidhu.me/google/2021/01/11/stealing-your-private-videos-one-frame-at-a-time/
https://bugs.xdavidhu.me/google/2021/01/11/stealing-your-private-videos-one-frame-at-a-time/
bugs.xdavidhu.me
Stealing Your Private YouTube Videos, One Frame at a Time
David Schütz's bug bounty writeups
#security
Очень хороший доклад на тему анализа уязвимостей
https://www.youtube.com/watch?v=nRnqdfefAz4
Очень хороший доклад на тему анализа уязвимостей
https://www.youtube.com/watch?v=nRnqdfefAz4
YouTube
Security Vulnerabilities Decomposition
Video with transcript included: http://bit.ly/3sb2Xjz
Katy Anton looks at security vulnerabilities from a different angle, flipping the security from focusing on vulnerabilities (measured at the end) to focusing on the security controls which…
Katy Anton looks at security vulnerabilities from a different angle, flipping the security from focusing on vulnerabilities (measured at the end) to focusing on the security controls which…
Forwarded from ДевОпс Інженер 🇺🇦 (Oleg Mykolaichenko)
Что там случилось с Elasticsearch?
Супер кратко:
Elastic поменял лицензию для продуктов, и они перестали быть open source. Комьюнити это не понравилось.
Теперь вышел Amazon, у которого война с Elastic, и сказал - мы форкнем, и будем дальше развивать Elasticsearch + Kibana с ALv2 лицензией.
Итого, факты:
- Elastic announced moving Apache 2.0-licensed source code to be under Server Side Public License
- Elasticsearch 7.11 будет уже под SSPL, т.е. не open-source
- Elasticsearch 7.10.x, который еще ALv2 - будет получать секьюрити апдейты до May 11th, 2022
- AWS will step up to create and maintain a ALv2-licensed fork of open source Elasticsearch and Kibana
Кто бы мог подумать 🤔
https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch
Супер кратко:
Elastic поменял лицензию для продуктов, и они перестали быть open source. Комьюнити это не понравилось.
Теперь вышел Amazon, у которого война с Elastic, и сказал - мы форкнем, и будем дальше развивать Elasticsearch + Kibana с ALv2 лицензией.
Итого, факты:
- Elastic announced moving Apache 2.0-licensed source code to be under Server Side Public License
- Elasticsearch 7.11 будет уже под SSPL, т.е. не open-source
- Elasticsearch 7.10.x, который еще ALv2 - будет получать секьюрити апдейты до May 11th, 2022
- AWS will step up to create and maintain a ALv2-licensed fork of open source Elasticsearch and Kibana
Кто бы мог подумать 🤔
https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch
Amazon
Stepping up for a truly open source Elasticsearch | Amazon Web Services
Last week, Elastic announced they will change their software licensing strategy, and will not release new versions of Elasticsearch and Kibana under the Apache License, Version 2.0 (ALv2). Instead, new versions of the software will be offered under the Elastic…
A fantastic speaker and a very interesting talk about pure/impure functions and testability
https://www.youtube.com/watch?v=US8QG9I1XW0
https://www.youtube.com/watch?v=US8QG9I1XW0
YouTube
Functional architecture - The pits of success - Mark Seemann
Object-oriented architects and developers have, over the years, learned many hard lessons about successfully designing systems with object-oriented programming. This has led to a plethora of ‘best practices’ that are painfully passed on from older to younger…
Forwarded from Aigerim
Всем привет! Каждый раз когда читала success stories наших участников очень радовалась за каждого и думала когда же я тоже буду делиться с хорошей новостью с вами. Вот и наступил этот момент, получила оффер от Майкрософта 😊😊😊 Прежде хочу благодарит вас всех за все!!! А особенно хочу выразить огроменную благодарность @sergi_sema ты красавчик и крутой человек!!! Спасибо за такую классную группу!!!
Коротко о моем пути:
Google Tokyo
Когда получила письмо от HR Google Tokyo где спрашивали интересует ли меня работа в Google, тогда и я начила готовиться. Первый колл был с HR была обычная беседа обо мне и в конце согласились что процесс начнем через 2 недели. За 2 нед. только успела подготовиться по Algorithms & Data Structures. 1 раунд был с той же HR и в течении часа спрашивала вопросы именно по Algorithms & Data Structures и на след день написала что прохожу на тел.интервью, сразу попросила месяц чтобы подготовиться и месяц решала задачи литкода. На тел.интервью спросили хард задачу по графам, кстати задачу потом не нашла в интернете. И получила фэйл и как сама ожидала. Я прекрасна знала что не готова, но мне хотелось узнать формат, примерно какие вопросы спрашивают, и узнать себя также как буду вести себя в экстренных случаях.
Amazon Madrid
После Google стала решать задачи ежедневно, и пришлось совмещать основную фуллтайм работу с подготовкой. Было сложно как и всем, себя заставлять 🙂 И в апреле в линкедине увидела хайринг ивент Амазона и подавала через сайт без рефералов, через 2-3 дня ответили, прошла ОА. Вопросы ОА можете найти в литкоде в разделе discussion. Через месяц в мае был тел.интервью где 20мин спрашивают поведенческие вопросы, на 30мин задачу решать. После того как завершили часть behavioral questions, и интервьювер стал обьяснять задачу и прекрасно с ней я бы справилась если бы в тот момент мой интернет не подвел бы меня((( Пришлось перенести интервью на завтра и спросили dp задачу и там я и провалила, и поняла для себя что нужно больше решать задачи по dp. В ноябре обратно через сайт подавала на другую позицию и локацию, прошла ОА, потом HR попросила чтобы на след.неделе запланировать день на тел.интервью но я просила дать мне 2 недели, затем HR пропала. Но HR появилась неделю назад и вот назначили на 11.02.2021 тел.интервью.
Microsoft Prague
С Майкрософтом все как-то быстро получилось и до сих пор не верится что получила оффер. Подавала в начале этого года тоже через сайт без рефералов. Ответили быстро и попросили пройти ОА через кодилити(спрашивают 3 задачи). Сказали прошла на тел.интервью и назначили колл c HR. Но потом другой HR написал что у них через неделью хайринг ивент и спросили хочу ли я участвовать в нем. Хотя я к онсайту не была готова, т.к по system design и OOP design я ни разу готовилась. Но рискнула и согласилась, и пришлось готовиться неделью по system design и OOP design. Онсайт состоял из 4 раунда:
1 - раунд по Algorithms & Data Structures задача медуим + поведенческие вопросы
2 - раунд по OOP design, дали уже готовый дизайн и попросили рефакторить его + поведенческие вопросы и вопросы по ООР
3 - раунд system design + поведенческие вопросы
4- раунд поведенческие вопросы
Все интервьюверы были классные и дружелюбные, поддерживали как могли.
На след.день уже написали что фидбек отличный и уже готовы предложить оффер, а на этой неделе уже отправили детали оффера.
Ресурсы:
https://www.coursera.org/learn/algorithms-part1
https://www.coursera.org/learn/algorithms-part2
https://algs4.cs.princeton.edu/cheatsheet/
https://leetcode.com/problemset/all/
https://www.educative.io/courses/grokking-the-coding-interview
https://www.educative.io/courses/grokking-dynamic-programming-patterns-for-coding-interviews
Коротко о моем пути:
• Начинала год назад когда HR Google написала интересует ли меня работа в Google • 3 года опыт работы, являюсь Андроид Девелопером • Решила 333 задач(Easy 101, Medium 222, Hard 10) • ~20мок интервью с участниками этой группы • Провалила 2 тел.интервью(Google, Amazon) и не доходила до онсайтаGoogle Tokyo
Когда получила письмо от HR Google Tokyo где спрашивали интересует ли меня работа в Google, тогда и я начила готовиться. Первый колл был с HR была обычная беседа обо мне и в конце согласились что процесс начнем через 2 недели. За 2 нед. только успела подготовиться по Algorithms & Data Structures. 1 раунд был с той же HR и в течении часа спрашивала вопросы именно по Algorithms & Data Structures и на след день написала что прохожу на тел.интервью, сразу попросила месяц чтобы подготовиться и месяц решала задачи литкода. На тел.интервью спросили хард задачу по графам, кстати задачу потом не нашла в интернете. И получила фэйл и как сама ожидала. Я прекрасна знала что не готова, но мне хотелось узнать формат, примерно какие вопросы спрашивают, и узнать себя также как буду вести себя в экстренных случаях.
Amazon Madrid
После Google стала решать задачи ежедневно, и пришлось совмещать основную фуллтайм работу с подготовкой. Было сложно как и всем, себя заставлять 🙂 И в апреле в линкедине увидела хайринг ивент Амазона и подавала через сайт без рефералов, через 2-3 дня ответили, прошла ОА. Вопросы ОА можете найти в литкоде в разделе discussion. Через месяц в мае был тел.интервью где 20мин спрашивают поведенческие вопросы, на 30мин задачу решать. После того как завершили часть behavioral questions, и интервьювер стал обьяснять задачу и прекрасно с ней я бы справилась если бы в тот момент мой интернет не подвел бы меня((( Пришлось перенести интервью на завтра и спросили dp задачу и там я и провалила, и поняла для себя что нужно больше решать задачи по dp. В ноябре обратно через сайт подавала на другую позицию и локацию, прошла ОА, потом HR попросила чтобы на след.неделе запланировать день на тел.интервью но я просила дать мне 2 недели, затем HR пропала. Но HR появилась неделю назад и вот назначили на 11.02.2021 тел.интервью.
Microsoft Prague
С Майкрософтом все как-то быстро получилось и до сих пор не верится что получила оффер. Подавала в начале этого года тоже через сайт без рефералов. Ответили быстро и попросили пройти ОА через кодилити(спрашивают 3 задачи). Сказали прошла на тел.интервью и назначили колл c HR. Но потом другой HR написал что у них через неделью хайринг ивент и спросили хочу ли я участвовать в нем. Хотя я к онсайту не была готова, т.к по system design и OOP design я ни разу готовилась. Но рискнула и согласилась, и пришлось готовиться неделью по system design и OOP design. Онсайт состоял из 4 раунда:
1 - раунд по Algorithms & Data Structures задача медуим + поведенческие вопросы
2 - раунд по OOP design, дали уже готовый дизайн и попросили рефакторить его + поведенческие вопросы и вопросы по ООР
3 - раунд system design + поведенческие вопросы
4- раунд поведенческие вопросы
Все интервьюверы были классные и дружелюбные, поддерживали как могли.
На след.день уже написали что фидбек отличный и уже готовы предложить оффер, а на этой неделе уже отправили детали оффера.
Ресурсы:
• Algorithms & Data Structures: https://www.coursera.org/learn/algorithms-part1
https://www.coursera.org/learn/algorithms-part2
https://algs4.cs.princeton.edu/cheatsheet/
https://leetcode.com/problemset/all/
https://www.educative.io/courses/grokking-the-coding-interview
https://www.educative.io/courses/grokking-dynamic-programming-patterns-for-coding-interviews
Coursera
Algorithms, Part I
Learn the fundamentals of algorithms in this course from Princeton University. Explore essential topics like sorting, searching, and data structures using Java. Enroll for free.
Forwarded from Aigerim
Gracking the Coding Interview - Gayle Laakmann McDowell
https://www.educative.io/courses/grokking-the-system-design-interview
https://www.youtube.com/channel/UCw0uQHve23oMWgQcTTpgQsQ
https://www.youtube.com/channel/UCaO6VoaYJv4kS-TQO_M-N_g/featured
Learnt lessons:
Готова ответить на любые вопросы кроме ТС и конкретных задач на собеседованиях - все под NDA.
И мои коллеги в группе пока не распространяйте новости плз😂😂😂
• System Designhttps://www.educative.io/courses/grokking-the-system-design-interview
• Behavioral Questionshttps://www.youtube.com/channel/UCw0uQHve23oMWgQcTTpgQsQ
https://www.youtube.com/channel/UCaO6VoaYJv4kS-TQO_M-N_g/featured
Learnt lessons:
• Ничего не откладывайте на завтра, на следующий месяц, на след.год. • Всегда помните что вы никогда не будете на 100% готовы, поэтому начинайте уже подавать в компании. Даже если получите фэйл, то такой огроменнный опыт вам никто не даст, даже моки которые проводим мы между собой. Не ждите пока вы не решите 1000 задач в литкоде. • Найдите себе teammate, с которым вместе будете готовиться и контролировать друг-друга. Мы @Emil_dev вместе готовились, при фэйл подбодривали друг друга, и контролировали процесс друг-друга • В реальных интервью не создавайте атмосферу экзамена между учеником и учителем, а постарайтесь создавать атмосферу обычного рабочего процесса, где интервьювер является вашей коллегой, потому что они смотрят еще на вашу способность collabaration • Если у вас технические проблемы во время интервью, это ок, не переживайте))Готова ответить на любые вопросы кроме ТС и конкретных задач на собеседованиях - все под NDA.
И мои коллеги в группе пока не распространяйте новости плз😂😂😂
www.educative.io
Grokking System Design Interview: Patterns & Mock Interviews
A modern approach to System Design Interviews. One course to master distributed systems and scalable architecture patterns. Practice with mock interviews. Built by FAANG engineers.