в перспективе буду сравнивать выгодность еботеки против ренты, усмотрение инфляции и тд
на сегодня отстрелялса, пойду ебланить
Это че, сразу с tkinter пошел ковырятся? А как же sys argvar'ы с командной строкой?
Ипотека под 1%? Сразу видно учебник из недружественных государств, кек.
Как хобби или на галеры хочешь?
> Это че, сразу с tkinter пошел ковырятся? А как же sys argvar'ы с командной строкой?
надоело в консольку пялится, потом интерфейс может быть удобнее - скоро будет больше входных параметров + вывод можно сделать красивее при желании
> Ипотека под 1%? Сразу видно учебник из недружественных государств, кек.
лол
>>03627
> Как хобби или на галеры хочешь?
посмотрим, пока о галерах не думаю
выбешивает костыль с нулями - надо разобраться как правильно форматировать йсон
к сожалению нет братишка (100.01 -> 100.001)
надо чётко указывать конец строки
похоже что json форматирование лютый геморрой в пестухоне
https://stackoverflow.com/questions/1447287/format-floats-with-standard-json-module
наследование от floatов, пиздец
точнячок
тогда можно регуляркой ебануть
import re
re.sub(r'\.0([^\d]|$)', '.00', string)
Хотя конечно на этапе вката в регулярки лезть может быть дизморально
ещё можно добавить инфляцию, но чёто лень - есть идея для следующего более интересного проектика связанного c ШАХМОТАМИ
да, проворонил там
> 1. Роберт Мартин "Чистый код"
да можно подчистить список параметров, отделить форматирование, может разделить формулы для ренты/еботеки но лень
> 2. pep 8 python
хз вроде стоит, vscode автоматом форматирует по сохранению.
у тебя как?
> да можно подчистить список параметров, отделить форматирование, может разделить формулы для ренты/еботеки
нет
>хз вроде стоит, vscode автоматом форматирует по сохранению.
у тебя как?
это стандарт
добавить напротив имени оппонента кнопку - при нажатии показывается окно с инфой об оппоненте:
- любимые дебюты
- длины игр
- манера игры - сливать при первой ошибке или гонять голого короля до усрачки
- и прочая статистика
бекенд разумеется на петухониссимо + flask
личес апишка: https://lichess.org/api
как делать расширения для хрома потом нагуглю
Усидчивость и упорство, расположенность к ментальным усилиям.
Учить как все: попеременно практика (играешь ~100 партий) и читаешь теорию.
периодически поигрываю но я не оч силён
но так шахматы люблю, да
мой акк https://lichess.org/@/AJIKOIIIAXMATbI
>>04061
развивают мощный пердак и потовыделение - особенно когда кончается время в ладейнике
играй в своё удольствие братишка
ты только одну рандомную страницу прочитал? закрыл книгу и пошел смотреть аниме? конечно, тебе же лучше знать, чем ему.
зачем тебе вообше бекенд тут нжуен, тем более фласк? тут обычный запрос с background.js делается (или даже с самого content.js можно), в manifest.json дай пермишон на домен. хотя в 3 манифесте могли как-то поменять пермишоны на домены (мож другое место переместили, чекни миграцию).
тут на 50 строчек кода. твоя задача, что ты вообще имеешь нулевое предстваление о том, как это всё происходит, зачем тебе вообще нужны различные технологии и как их применять. повторяю, прочитай ~5-7 книжек для начала на общие темы (не конкретные технологии). тебе так проще самому будет ориентироваться
Нет, я прочитал статью на лурке и немножко кринжанул с этого. Ещё больше кринжанул с пикрила, кстати. Замечательный, чистый код.
>не ознакомился с трудом
>критирует труд, поскольку на сайте назвали бякой
своё мнение имей. хотя к кому я обращаюсь.
любые (желательно попроще, где написано не академическим языком, а популярно. для обычных работяг будет лучше), отвечающие на вопросы:
1. как устроен компьютер?
2. как работает опреационная система (приложения на ней и пр.)?
3. что такое Интернет (и как по нему передаются данные)?
4. что такое данные (октет, машинное слово, тетрада, бит и пр. в общем, информатика), как и где хранятся?
5. что такое язык программирования, почему бывают разные и как написать свой?
6. как писать легочитаемый, поддерживаемый и расширяемый код?
это прям вообще "детские" вопросы. лучше сперва заняться поиском ответов на них, чем безраздумно прыгать на разные технологии (типа фласка, который тут вообще не к месту) и с пустой головой, сам не понимая каким образом и что ты хочешь сделать по итогу, заниматься онанизмом.
если ты найдешь ответы хоятб на эти 6 вопросов, приложение на фласке (как и на любой доругой технологии) напишешь за 15 минут по документации, сэкономив кучу времени. ты поймешь, что всё намного проще, чем тебе сейчас это кажется
первый - инженер по образованию, занимающийся более 40-ка лет разработкой ПО (дальше не буду перечилсять регалии). второй - вчерашний школьник-анимешник. ты понимаешь, что это две разные величины? знаю, тебе будет нелегко, но асбтрогируйся от свой личности и ответь объективно
> > критирует труд, поскольку на сайте назвали бякой
Ну начнём с того, что я прямо указал на то, что мне не нравится, а не просто на сайт, где я это нашёл.
>>04116
> первый - инженер по образованию, занимающийся более 40-ка лет разработкой ПО
Занимающийся обучением тому, как разрабатывать по, это разные вещи. Не нашёл ни одной программы, которую он написал (может, плохо искал)
> второй - вчерашний школьник-анимешник
Честно говоря, я не знаю, где ты это нашёл, но, судя по всему, для тебя все, кроме, Роберта Мартинса - вчерашние школьники-анимешники.
> знаю, тебе будет нелегко, но асбтрогируйся от свой личности и ответь объективно
Не знаю, зачем мне АБСТРОГИРОВАТЬСЯ от свой личности, ведь я уже ответил объективно, прикрепив ЕГО кусок кода.
>Ну начнём с того, что я прямо указал на то, что мне не нравится, а не просто на сайт, где я это нашёл.
тяжело с людьми, которые н понимают с ервого раза. что ж, идём по кругу - goto: ты_только_одну_рандомную_страницу_прочитал
>Занимающийся обучением тому, как разрабатывать по,
ложь
>для тебя все, кроме, Роберта Мартинса
это не мой кумир. даже в тысячу наиболее уважаемых людей не входит. просто факты, которые юный нигилст принять не способен (это пройдет, когда повзрослеешь)
>Не знаю, зачем мне АБСТРОГИРОВАТЬСЯ от свой личности, ведь я уже ответил объективно, прикрепив ЕГО кусок кода
ты учишь отца заниматься сексом
Кстати я только что заметил, что ты призвал меня абстрагироваться от личности, при этом апеллируя к личности Роберта Мартина. Наверное ты просто пошутил.
>
Кхм, случайно отправил, похуй.
> тяжело с людьми, которые н понимают с ервого раза. что ж, идём по кругу - goto: ты_только_одну_рандомную_страницу_прочитал
Тчжнло с льжми еитоые не уиеюь прсать
Только что прочитал рандомную страницу и указал в своих постах то, что меня не устраивает в источнике. По-моему, так звучит достаточно логично. Видишь? Достаточно просто уметь читать.
> Ложь
Ну тогда у тебя наверное есть пруфы? Да ведь..?
> ты учишь отца заниматься сексом
А ты используешь ошибочный аргумент, гласящий о том, что зарекомендовавшая себя личность никогда не может ошибаться, но ведь может, я даже прямо написал, в чем.
> зачем тебе вообше бекенд тут нжуен
несколько причин
- удобнее разработка - гораздо проще ковырнуть хтмл на сервере и задеплоить чем просить тысяч пользователей скачать апдейт клиента.
- конфигурацию и конфиденциальные данные типа api ключей и тд можно хранить только на сервере
- проще переиспользовать для других шахматных сайтов - chess.com, chess24 и тд
- меньше нагрузки на клиентские девайсы (нам каждый раз нужно будет скачать до 100 игр оппонента и обработать их)
- и прочая залупа типа отслеживания пользователей, аналитики и тд. это всё проще с сервером
поэтому сервак абсолютно необходим братишка. "Малаца", грит дядя Боб, "сервер збс".
> тут на 50 строчек кода. твоя задача, что ты вообще имеешь нулевое предстваление о том, как это всё происходит, зачем тебе вообще нужны различные технологии и как их применять. повторяю, прочитай ~5-7 книжек для начала на общие темы (не конкретные технологии). тебе так проще самому будет ориентироваться
держи в курсе братан
>Кстати я только что заметил, что ты призвал меня абстрагироваться от личности, при этом апеллируя к личности Роберта Мартина
ложь
>только что прочитал рандомную страницу и указал в своих постах то, что меня не устраивает в источнике.
ложь
>А ты используешь ошибочный аргумент, гласящий о том, что зарекомендовавшая себя личность никогда не может ошибаться
ложь
а вы стоите друг друга с этим подростком) ты не его папа?
>несколько причин
с каждой в голос
>держи в курсе братан
:facepalm
>чувак, не читавший книгу (даже не понимающий конекст примера), пишит по ней кртику а-ля Белинский
>чувак, не создавший ни одного расширения (даже не знает как их делать), рассуждает о том, как удобнее
два сапога пара
Сделал на Паскале и с нормальными функциями...
>>04116
Регалии — не аргумент, иначе ты сам-то кто такой, что по проектам, что по вкладу в разработку твоего языка программирования? Отец хуев :)
Я эту книгу видел у друга печатную и открывал наугад в месте, где автор не любит аргументы-флаги по причине нинужно, порвался, закрыл и принялся дискутировать на эту тему с другом, куда больше пользы. Я их тоже не люблю, но что они НИНУЖНЫ — бред же.
В моей реализации длинных чисел сложение и вычитание выполняются совершенно по-разному на самом низком уровне (в столбик) и на самом высоком (operator + vs. operator -), но во всём, что между ними, они полностью аналогичны с точностью до операции, поэтому вместо двух параллельных иерархий вызовов, для сложения и вычитания (а автор предлагает именно это), лучше иметь одну с дополнительным флагом isAdd, пробрасываемым вниз и ветвление по которому if (isAdd) slozhit’_v_stolbik else vychest’_v_stolbik происходит в самом низу.
Во Free Pascal есть место, кажется, с шестью булевскими флагами подряд, связанное с поиском перегрузок функций и его тонкостями вроде «явно задан модуль, поэтому не искать в других модулях, а в остальном как обычно», «на самом деле это аксессор свойства и его видимость проверена по видимости свойства, видимость аксессора не проверять».
В Dungeon Crawl Stone Soup бывают чуть ли не десятки флагов-аргументов, когда поведение атаки зависит от обстоятельств, «а мы по-настоящему атакуем или понарошку, просто чтобы посмотреть, кого заденет», «а это планируется как вредное или полезное действие», «согласился ли пользователь потенциально навредить самому себе».
Вот я не люблю много (>1) флагов подряд как в последних двух случаях, предпочитая (битовые) множества, к тому же лучше читаемые: attack(whom, false, true, true) vs. attack(whom, ATTACK_UNSEEN | ATTACK_TRACE). С другой стороны, они сложнее формируются условно: ATTACK_TRACE по условию cond добавить сложнее, чем написать attack(whom, false, true, cond). Но автор говорит про нинужность, вредность и идеологическую неверность флагов как таковых, то есть в программировании он полный лох и регалиями может подтереться.
Сделал на Паскале и с нормальными функциями...
>>04116
Регалии — не аргумент, иначе ты сам-то кто такой, что по проектам, что по вкладу в разработку твоего языка программирования? Отец хуев :)
Я эту книгу видел у друга печатную и открывал наугад в месте, где автор не любит аргументы-флаги по причине нинужно, порвался, закрыл и принялся дискутировать на эту тему с другом, куда больше пользы. Я их тоже не люблю, но что они НИНУЖНЫ — бред же.
В моей реализации длинных чисел сложение и вычитание выполняются совершенно по-разному на самом низком уровне (в столбик) и на самом высоком (operator + vs. operator -), но во всём, что между ними, они полностью аналогичны с точностью до операции, поэтому вместо двух параллельных иерархий вызовов, для сложения и вычитания (а автор предлагает именно это), лучше иметь одну с дополнительным флагом isAdd, пробрасываемым вниз и ветвление по которому if (isAdd) slozhit’_v_stolbik else vychest’_v_stolbik происходит в самом низу.
Во Free Pascal есть место, кажется, с шестью булевскими флагами подряд, связанное с поиском перегрузок функций и его тонкостями вроде «явно задан модуль, поэтому не искать в других модулях, а в остальном как обычно», «на самом деле это аксессор свойства и его видимость проверена по видимости свойства, видимость аксессора не проверять».
В Dungeon Crawl Stone Soup бывают чуть ли не десятки флагов-аргументов, когда поведение атаки зависит от обстоятельств, «а мы по-настоящему атакуем или понарошку, просто чтобы посмотреть, кого заденет», «а это планируется как вредное или полезное действие», «согласился ли пользователь потенциально навредить самому себе».
Вот я не люблю много (>1) флагов подряд как в последних двух случаях, предпочитая (битовые) множества, к тому же лучше читаемые: attack(whom, false, true, true) vs. attack(whom, ATTACK_UNSEEN | ATTACK_TRACE). С другой стороны, они сложнее формируются условно: ATTACK_TRACE по условию cond добавить сложнее, чем написать attack(whom, false, true, cond). Но автор говорит про нинужность, вредность и идеологическую неверность флагов как таковых, то есть в программировании он полный лох и регалиями может подтереться.
осталась генерация инфы и собственно расширение
спешите видеть - дядя Боб попался за баловством с бульскими флагами!
https://github.com/unclebob/fitnesse/tree/master/src/fitnesse
генерация инфы об оппоненте готова - осталось только разобраться с расширением и тогда я буду непобедим
весь мозг блядь выебал пока разобрался как вызвать апишку через бекраунд скрипт
в итоге это нахуй не понадобилось, просто ебашу window.open(...)
>весь мозг блядь выебал пока разобрался как вызвать апишку через бекраунд скрипт
ну не дегенерат разве? это 15 секунд делается, там всё написано. вот результат обучения по верхушкам. ещё один кривожопый "программист', коих уе сотни миллионов
прошёлся тебе 15 сек по верхушкам струёй пахучей утренней мочи, дружище
утираться будешь или так норм?
надо было становиться шахматистом, а не эти поганые закорючки разглядывать
ладно, нужно налечь на личес литкод
ща зарегаюсь и буду решать унизительные олимпиадки для пятиклассников, залупа типа физбаза больше всего решает на интервью
потом шиз из /зк подкинул идейку для следующего пета - что то вроде аггрегатора/анализа вакансий с местных рекрутёрских сайтов, с графиками/статистикой и прочим
как я раньше до этого не додумалса, будет смешно если этот пет поможет мне найти работу
это уже будет приложение по-крупнее, с более серьёзной мордой и кишками. если ничего лучше не придумаю то начну в ближайшие дни
немного развил тему следующего пета
пока имею следующее:
- веб морда/админовка на свелте, давно хочу потрогать
- бекенд разумеется на пестухандриссимо + фласк. настраиваются источники вакансий, периодически поллятся - интересные вакансии отсылаются мне прямо в телеграм + видны в веб морде. алсо можно прихуярить всякую статистику и прочие удобства
- телеграм бот
потом смотрел сайты вакансий на предмет апишек, тут всё печально
- reed, апи уберубогое, нельза даже фильтровать по датам - придётся фетчить до 1-2000 вакансий и фильтровать самому на сервере. но зато простое и работает - подёргал в постмане, для начала пожалуй хватит
- гугл алсо аггрегирует вакансии и предоставляет апишку, но доступ анально привязан к гугл клауд аккаунту, а хоститься всё-таки склоняюсь на амазоне
- eщё места где апи нет вообще, либо платное. скрейпить/парсить хтмл не собираюсь, это лютый геморрой.
- есть вариант емейл подписки - вместо поллинга апихи мы на сервере просто проверяем ящик
начал код, дергаю апишку вакух, делаю до ~10 запросов подряд потому что не дают фильтровать по датам - приходится всё скачивать и фильтровать самому
однако, похоже что результаты приходят в порядке релевантности - внизу всегда мусор, может зря ругаюсь
пока накинул @cached(cache=TTLCache(maxsize=1024, ttl=3600)) шоб не забанили по айпи лол
сделал оче простую страничку - пока вакансии просто показываются в списке.
надо вкурить как делать hot-reload - заебало компилировать весь солюшен вручную, и при этом не слишком жидко обосрашись с CORS
дальнейший план:
- конфигурация/критерии поиска дожны настраиваться на веб страничке
- помечать понравившиеся/удалять говно - что то типа тиндера, но для вакух
- интеграция с телеграмом
водянистый обосрамус с hot-reload ещё до CORS - свелте толком не поддерживает прокси дев-сервер
короче просто поставил npm-watch и по изменениям файлов пересобираю продакшен билд и копирую в папку static - так хоть запястье не отвалится
алсо появилась идея авто-подсчитывать длину онлайн-митингов - например в гугл-митс, поллить количество участников, потом помножить на потраченное время, результат высрать в слак/другой публичный чатик - чтобы постыдить менеджеров, продактоунеров и прочих любителей попиздеть
На позицию джунишки-шалунишки сможешь сесть точно
На первых собесах обосрут, ткнут носом в то, что ты совсем не знаешь, закроешь пробелы и велком ту айти, маня!
Готовь туза, ебать тебя будем клавиатурой
Зачем этот пердолинг, если для svelte есть vite плагин https://vitejs.dev/guide/#trying-vite-online и там в том числе hmr есть
спасибо, братан
может я не так объяснил - у меня стоит rollup и hot-reload работает, мне только нужно настроить прокси что бы пикрелейтед обращался к моей питухон-апишке, а не 404-бся об свелтовский дев-сервер
я пробовал этот плагин, но он обосрался или я
https://www.npmjs.com/package/rollup-plugin-dev
если это изи из коробки делается на vite, то конечно попробуем потом vite братишка
> Пиздуй работу искать
как раз об этом пет проект
> Готовь туза, ебать тебя будем клавиатурой
кек мой развороченный пердак вайтишными клавиатурами не запугаешь братан
https://stackoverflow.com/questions/64677212/how-to-configure-proxy-in-vite
что-то такое. потом поковыряю
поковырял страничку, добавил залупку для настроек
добавил формочку с юзер инфой - она теперь сохраняется в постгресе. фид вакансий строится по сохранённым ключевым словам.
питухон апишка теперь:
GET /api/feed
GET /api/user
PUT /api/user
немножко поебался со state-management в svelte но похуй, со всем разобрался сам яж не мудак блядь
нужно будет добавить авторизацию и landing page, иначе нихуя не production-ready
запишу несколько мыслей на эту тему
> по 400 кандидатов на вакансию джуна
во первых, на этом уровне кандидаты не подаются на одну вакансию, а сразу на многие
если у нас условно 1000 кандидатов и 1000 вакансий, на одну вакансию может прийти до 1000 резюме - при этом работы хватит на всех.
алсо на энтри левел позиции будет подаваться намного больше некомпетентного мусора - из тех 400 резюме 350 отправляются в корзину - и это одни и те же 350 долбоёбов подающихся на всё подряд по кругу
> по 10 кандидатов на вакансию сеньёра
тоже самое
ещё нюанс, сеньёр может проходить нескоько собеседований ежегодно уже имея комфортную работку. далеко не каждому соискателю в этом случае действительно нужна работа
и если сеньёр меняет работу - она освобождается для другого разработчика
> тысячи выпускников
ну не знаю братишка, рост зарплат говорит о том что число вакансий растёт всё таки быстрее
> финансовые пузыри, great reset etc
мне это кажется более интересным аргументом против айти
печатанье денег/убернизкие процентные ставки в течении десятилетий порождают зомби предприятия которые умрут как только ставки начинают расти
эта безработица коснётся всех, не только айтишников. мне действительно кажется что в будущем значительной части кнопкодавов будет нечего делать из-за фундаментальных изменений в экономике а так же демографии
>во первых, на этом уровне кандидаты не подаются на одну вакансию, а сразу на многие
Пруфай. А ещё сравни число резюме и число вакансий джуна
>если у нас условно 1000 кандидатов и 1000 вакансий, на одну вакансию может прийти до 1000 резюме - при этом работы хватит на всех.
У нас условно 50000 кандидатов, вася
https://techcrunch.com/2022/05/27/tech-layoffs-top-15k-employees-in-a-brutal-may/
https://www.fastcompany.com/90752601/tech-layoffs-loom-as-more-companies-announce-big-cuts-to-their-workforces
https://www.npr.org/2022/05/16/1099244586/in-silicon-valley-startups-are-laying-off-staff-as-investors-pull-back-from-big-
Пизда зарплатам ебаным
>> на этом уровне кандидаты не подаются на одну вакансию, а сразу на многие
> Пруфай
это и так очевидно, дружище. начинающие подаются на всё подряд ради опыта прохождения собеседований и закрытия пробелов
ты хоть раз искал работу?
> сравни число резюме и число вакансий джуна
> У нас условно 50000 кандидатов
>> алсо на энтри левел позиции будет подаваться намного больше некомпетентного мусора
QED
>это и так очевидно
Если тебе очевидно - пруфай.
Во-вторых, повторюсь
> сравни число резюме и число вакансий джуна
Намек понятен?
>> алсо на энтри левел позиции будет подаваться намного больше некомпетентного мусора
Пруфай, что некомпентного мусора. Надеюсь ты не просто снихуя спизданул, а имеешь некую методику оценки компетентности.
окей, смотри:
доказательство от противного, братан:
- допустим все 50 миллионов кандидатов хорошие качественные джуны которых стоит нанять
- тогда компании их быстро нанимают и зарплаты джунов быстро падают до уровня дворника
- но в реальности у джунов высокие зарплаты
- из этого следует, что кандидаты некачественны
ЧТД QED ИТТ
>и зарплаты джунов быстро падают до уровня дворника
https://hh.ru/vacancy/55289885
https://hh.ru/vacancy/66201847
https://hh.ru/vacancy/55422843
https://hh.ru/vacancy/66123336
добавил POST /api/feed для загрузки вакансий
добавил таблицу для вакансий
добавил репозиторий для вакансий
алсо на днях допёр что моя поделка будет так же работать и с тредами двача
прикреплю апишку для этого итт тредика в итт:
https://2ch.hk/makaba/mobile.fcgi?task=get_thread&board=dr&thread=603536&num=603536 (М)
скоро пора деплоится в продакшен, а значит пора думать как устроить периодическую подгрузку постов.
пока смотрю на отказоусточивую exactly-once схему EventBridge -> SQS -> ZBS App (скорее всего хостится будем на лямде).
https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule-schedule.html
значит POST /api/feed оставим для чисто для админки, добавим потом хендлер для SQS сообщений
- добавил скрытие вакух
- добавил залупку для рефреша вакух
- добавил апишку для скрытия и рефреша вакух
апишка:
GET /
GET /api/user
PUT /api/user
GET /api/feed
POST /api/feed
DELETE /api/feed
ну и по мелочи конечно же поебался с сериализацией енумов, почему блядь в жс это так просто и так сложно в других яп
по pgAdmin уже уверенно шлёпаю мышкой, цсс люто заебал хорошо хоть hot-reload есть
со спокойной душой иду ебланить
зависит от проигрыша, братишка. от ИРЛ проигрышей не бомбит, а вот от Личеса частенько, поэтому стараюсь онлайн игру ограничивать.
иногда после тупой ошибки в ярости удаляю аккаунт, а другой раз с интересом смотрю анализ и учусь на обосрамсе.
игры как на пике больше всего выбешивают - вроде отлично начал а потом хуяк и пизда
Чаще всего нет. Анализирую проигрыши и в 90% я играл плохо, а не противник хорошо, а значит я всё могу исправить.
ладно собрались - пошёл хуярить
какие дебюты любишь?
алсо солю пользовательские пароли, совсем как ## трипы
исправил базу, щас есть возможность иметь многих пользователей, и у каждого свои подписки
короче заебался пиздец, спать буду ок
осталось только задеплоить сервис куда-нибудь на облачко, шоб сканировал интернеты на предмет новых вакух денно и нощно и без моего участия
тут есть несколько вариантов:
- самый модный: уже описывал сверху. RDS (free-tier) для базы, EventBridge для крона, API Gateway + Lambda для питухон апишки, это должно стоить может доллар в месяц (кстати амазон прощают маленькие счета - им снять 20 центов с карточки дороже чем просто забить, кек)
- самый свитерный: у меня под столом пылится старая пека, можно просто задеплоить на неё, всё готово и уже стоит убунта с докерами, но минус в шуме и плате за электро
- самый скучный: просто развернуть docker-compose на EC2 фри тир, это будет бесплатно
Data Scientitом в UK хочешь стать? ЗПшки маленькие чот. И вангую русачка че возьмут сейчас по политике.
> ЗПшки маленькие чот
щас кризис, дружище. хорошо хоть вообще работа есть, кек
> Data Scientitом
да не, скорее обычным мидл+ бекендером
нужно сузить критерии поиска
> И вангую русачка че возьмут сейчас по политике.
по бумажкам не русачок + давно тут
Успехов, братишка.
Так что-то не понял, от какого апи ты в итоге питаешься? нашел в итоге сайт с вакансиями с норм апи или намутил хитрый парсер?
нашёл норм апи reed.co.uk
алсо пускаю слюни на это:
https://cloud.google.com/solutions/talent-solution
добавил локальный крон
чесал репу - оказывается фласк в дебаг моде загружает приложение дважды
блядь, ёбаный стыд. опуская подробности - снёс нахуй поганый фласк, тьфу блядь.
взял фастапи вместо фласка - более/менее настроил всю миддлварь + переделел аутентикацию. пока полёт нормальный конечно же вдоволь поебался с джейсон сериализацией
убогим питоновским говнофреймворкам ещё очень долго до божественного Экспресса
щас наверно до понедельника буду отдыхать
на след неделю план:
- разобраться с requirements.txt и наконец закинуть залупку в облачко
- может упростить регистрацию новых юзеров - подруга проявила интерес к этой хуйне кек
- добавить новых источников данных/апишек - аренда квартир, фондовые рыночки, новостные сайты
- может всё-таки посмотреть на парсеры (BeautifulSoup) - это гемор но зато здорово развяжет руки
- придётся писать всякие костыли для сбора логов с клаудвотч
такая вот хуйня, дорогой дневничок
задеплоил по схеме на говнопике - вроде там и так всё понятно
настроил всё, как мне кажется, весьма чрезжопно. но старался максимально огородить апишку, настроил рейт лимит от мамкиных хацкеро-ддосеров да кому я нахуй нужен, лол, аутентикацию для крона, крепкий пароль для базы, етц
буду следить за биллингом, но вроде стоимость должна быть околонулевая лол завтра охуею
было несколько курьёзов, опишу самый припекательный
для интеграции докер контейнера с лямбдой нужна простенькая мелкая либа "Mangum" которая просто преображает один джейсон объект в другой
есть ещё и другая либа с похожим названием "Magnum" - она оче долго собирается и весит с вместе с зависимостями около 10 гигабайт
как ты думаешь, дорогой дневничок, на установку какой, сука, либы я убил почти полтора часа? какого блядь хуя эти питонодауны выбрали такое ебанное название
алсо лютый геморрой и раздудый докер-образ из-за psycopg2
алсо долбоёбы из aws всё ещё используют 3.9й питухон в своих докер-образах. пришлось искать все "|" и заменять на Optional[..]
ладно
но из хорошего на будущее - OpenSearch теперь имеет фри тир, надо попытаться сделать с ним логи
написал утилитку для вывода логов в консолечку. поблевал от asyncio.
алсо парад ебанутых имён продолжается - сдкшка у питуходаунов называется "boto3" блядь. "на держи aws-sdk" - "нет я с БОТО-ТРИ братан"
бототри, мангум, КрасивыйСуп, ебанутые, кек
поблевал от asyncio. взял ThreadPoolExecutor и распараллелил вызовы апишки вакух (5 вызовов всего). задержка упала с 3 сек до где-то 700мс - збс
алсо шлю все оповещения в одном телеграм сообщении, а не каждое отдельно
потом пытался ужать докер образ. psycopg2 тянет где-то 200МБ зависимостей, думал заменю-ка её на SQLAlchemy - хуй там, алхимия использует psycopg2 внутрях.
вообще думаю дропнуть нахуй поганый sql и взять nosql dynamodb, я динаму отлично знаю, будет тру серверлесс солюшен, а эскюэль уже достаточно поматросил, заебало, оверкил для меня
нашёл интересную вещь - но анально огорожена https://newsapi.org/
короче надо смотреть в сторону новых апишек, парсеров и функционала, мне нужно пистодрон учить а я всё в какой то хуите колупаюсь
https://www.youtube.com/watch?v=ySNSY7iiBDY
с хтмл парсерами мне больше не нужны апишки - можно сдирать инфу прямо с сайтов, бесплатно, без регистраций и без апи-ключей
но с другой стороны парсеры более геморойны в обслуживании и могут ломаться если фронтенд-макака на другом конце обосрётся
что толстый Пихон делает с девками
супец хороший, вкусный - нахуярил хтмл парсеров для новостных сайтов и бложиков. потом (может воскресенье) добавлю ещё - у меня целый список
https://www.crummy.com/software/BeautifulSoup/bs4/doc/
по идее я больше не должен даже заходить на эти сайты, всё уже автоматически приходит на мобилку
подводя итоги, из списка >>08774 не сделал только регистрацию, да и хуй с ней - юзеров можно добавить напрямую в таблицу в pgAdmin, вообще поебать
начал приходить биллинг - ожидаемо всё пока что по нулям
сервис работает стабильно, хуй знает что тут сказать всё збс ёба нах
тока вакухо-апишка иногда капризничает как сучка, может стоит увеличить таймаут до 5 сек
в основном для новостных бложиков которые вечно забываю проверить + сайт с квартирами
столкнулся с некоторыми трудностями:
- мои сервера в штатах - поэтому некоторые выдают американскую версию сайта вместо европейской. пока нашёл простой способ обойти, но в будущем возможно переедем в eu-west-2. может сделаю одновременно с миграцией на динаму
- несколько бложиков + ютуб тоже требовали енаблед джаваскрипт - значит фетчить их нужно с headless браузером типа gecko/chromium, а это опять ебля с бинарными зависимостями и раздув докер-образа
- с ютубом отдельный геморрой про 'Accept all cookies' + ёбанная GDPR-мракодрисня - этим точно заниматься не буду
след шаги:
- скрипт для быстрого деплоя нового кода, шоб прям одной командой всё делал
- (мэйби) переезд в евро-регион и (абсолютли) дроп sql в пользу динамы
- может алсоу дроп веб-морды и полный переход на телеграм бот апишку для всех юзкейсов
как видишь, дорогой дневничок, задачки скучные, инфраструктурные, писюкон мы с ними сильно не качнём. пока совершенно нет идей насчёт нового функционала (кроме ещё большего числа злоебучих парсеров)
а значит пора заниматься поисками дополнительных проектиков - этот не бросаю нет-нет но фаза активной разработки подходит к концу
деплой скрипт сделал
попытался добавить парсер фондового рыночка, но глаза охуели от дрисни на пике. ну его нахуй - потом сделаю
миграцию делать лень пиздец - и так всё заебись работает
вообщем пока наслаждаюсь жизнью самого осведомлённого человека и лениво почитиваю телеграмчик
новые идеи пока неоч:
- хуитка для подсчёта длины стендапов - скорее повод подёргать гугло-апи чем полезный проект
- хуитка для вычисления идей для пет проектов
- может поколупаться с дата ссаенс либами
5x + 2 = 4 это для начала реши, идиотiк или хотя бы это 2a(a - 2)x = a - 2 это как раз 7 класс алгебры.. то есть это любой семиклассник решит, твой удел неделями делать парсеры и называть это проектом. лол
О, ты тип математик? Видел >>608975 → >>609130 →? Меня привело в восторг, что простоту 32/64-битного числа можно определить детерминированно за 3/7 раундов вероятностного в общем случае алгоритма.
О, ты тип Пидорура?
> тривиальная теория чисел
> алгебра 7 класс
> 5x + 2 = 4
маняматика уровня /dr
Да не знал ты про это (возможность быстрого и детерминированного теста машинных целых на магических наборах оснований), не ври. :’-(
окей добавим в беклог:
- контроль частоты оповещений, задаётся из уеб-морды
- миграция региона и дроп sql
алсо заметил забавный женский момент из этого тюториала
вместо того чтоб нормально изучить BeautifulSoup и как достать айдишечку элемента, писечка делает шорткат и лезет создавать какие-то костыли из регексов - типикал воман кодинг кек
сделал плюс-минус 3 проекта, пробовал tkinter и svelte. два сервиса на фласке и fastAPI. последний в итоге задеплоили на AWS и уже приносит какую-то пользу. алсо куча интеграций со сторонними сервисами - личесс, телеграм и всякие html парсеры
дневник алсо помог с самоконтролем и уменьшил распиздяйство - люди же смотрят есть хороший пинок под зад
на след месяц план продолжать ебашить, нельзя расслаблятся, нельзя обрастать умственным жирком
цель продолжать хотя бы 30-60 мин в день уделять на прогу, даже если лень пиздец отмучься пол-часа братишка и нахуй иди
окей, щас значит решил вернуться к истокам и вновь поковырять desktop. начал делать игрушку-арканоид на tkinter canvas + pillow
идея полное днище но я ничего полезного не придумал где много кода и практики но при этом мало json-дрочева
такие вот дела любимый дневничок.
1440x1440, 0:07
спать
https://m.youtube.com/watch?v=oNalXg67XEE
тут про события и наблюдателя. для арканоида надо будет поставить какую нибудь евент либу, хочу чтоб игра была изи настраиваема и каждому объекту можно было бы присвоить своё поведение
тут алсо про замыкания и functools.partial(f, arg1=.....)
https://m.youtube.com/watch?v=ph2HjBQuI8Y
канал отличный и мужик приятный, надо только ставить скорость на 1.50
ещё збс ресурсец с типсами
блядь хуй знает кто придумал что пеходрон простой ЯП для изучения, столько ёбаных фич и особенностей типа __этойХуйни__, аргс/кваргс, global, Protocol и тд
количество ебучих PEPсов тоже намекает
https://peps.python.org/
может я не туда учу?
будем думать
ладно, щас продолжу пердолить арканоид
ткинтер таки говно ебаное
ладно, значит как обещал каждый объект обладает настраиваемым поведением по принципу composition over inheritance и тд и тп
нужно добавить побольше фич, думаю вечер другой ещё можно посидеть, потом брошу нахуй
неплохая практика питона но код бесполезный абсолютно, надо опять что-то с телеграмом придумать
окей, сегодня по расписанию продолжается пердолинг 2д кругов в ткинтере
больше нет сил смотреть на это говно, продолжим завтра
к обеду послал всё нахуй и пошёл загорать в парк
потом отстрелялся на паре митингов, полистал говнокод джунов, получил свои 400к/нс и щас пишу в тебя, дорогой дновничок
солнце ещё высоко, а значит хорош пиздеть пора включать музычку и допедаливать говноподелку на ткинтере
расширяемый энтерпрайз-арканоид
игра на изиче настраивается из main, кaждому объекту присваеваешь список поведений, хочешь чтоб вращался - добавляй Rotates() и тд
поведения используют либу evento для общения с игрой и друг с другом
Сколько времени тебе нужно на создание нейросетки, которая будет генерить осмысленные тексты на заданные темы и постить их ИТТ?
Сколько времени нужно, чтобы создать нейронку, которая будет генерировать осмысленные тексты на заданные темы и публиковать их? Следует спросить: «Сколько времени вам нужно ждать, прежде чем вы добавите в корпус текстов, опубликованных в журналах, статьи, которые были опубликованы с течением времени?» или «Сколько времени вам нужно подождать, прежде чем вы добавите в корпус текстов опубликованные статьи?» в сообщениях общественного мнения, которые публиковались с течением времени?» Мы хотим избежать такого короткого ответа «Я не уверен...».
В конце концов, мы надеемся, что приведенный выше алгоритм сможет обнаружить наиболее важные тексты и идентифицировать наиболее важный контент из любого из различных типов текстов, опубликованных во всех публикациях, которые мы скоро опубликуем на OpenBazaar. Поскольку у нас есть много примеров алгоритмов, которые мы использовали в нашей книге, чтобы дать вам лучшее представление об алгоритме, необходимо охватить конкретные алгоритмы, которые вы будете использовать для классификации этих текстов в OpenBazaar, включая типы статей, которые вы будут публиковаться на OpenBazaar, сколько времени вам нужно будет потратить на их обновление, размер корпуса текстов для анализа и сколько вам нужно будет загрузить на OpenBazaar. Кроме того, мы также планируем интегрировать OpenBazaar в другие языки, включая Python и R, чтобы вся информация, которую мы собираем онлайн в книге, могла использоваться для вашего чтения, а также в учебных целях.
буду писать консольный поисковик имиджборд - по заданному списку досок и паттернов найти подходящие трендели
вроде что-то уже начал
алсо гугл предлагает решить тестовое, кек уже нигде не спрятаться от ебучих рекрутёров
сегодня вялый день, но я заставил себя пол-часа позаниматься
сделал парсинг аргсов + начал определять интерфейсики сёрч-залупки
тоже самое на работе - минимум продуктива, проебал 6 часов за собраниями, пиздежом в чатике и чтением новостей под хрючево
сел на пол-часика, просидел 2
поебался с макакиным рейт лимитером, алсо примеры апишки стухли
ладно ещё немного подправить и будет юзабельно
великовозрастный прокрастинатор ковыряет пестухон
Пропущено 121 постов, 65 с картинками.
Аноним 06/09/22 Втр 00:15:59
№
628930
image.png 13Кб, 1592x121
1592x121
image.png 289Кб, 3021x874
3021x874
пришла пора размять пальцы
буду писать консольный поисковик имиджборд - по заданному списку досок и паттернов найти подходящие трендели
вроде что-то уже начал
алсо гугл предлагает решить тестовое, кек уже нигде не спрятаться от ебучих рекрутёров
>>28947
Аноним 06/09/22 Втр 08:09:45
№
628947
>>28930
Я решал это, но мне не перезвонили.
>>29042
Аноним 06/09/22 Втр 16:21:21
№
629042
>>28947
не умеешь ПРОДАВАТЬ СЕБЯ, братишка
Аноним 06/09/22 Втр 23:02:30
№
629157
великовозрастный прокрастинатор ковыряет пестухон
Пропущено 121 постов, 65 с картинками.
Аноним 06/09/22 Втр 00:15:59
№
628930
image.png 13Кб, 1592x121
1592x121
image.png 289Кб, 3021x874
3021x874
пришла пора размять пальцы
буду писать консольный поисковик имиджборд - по заданному списку досок и паттернов найти подходящие трендели
вроде что-то уже начал
алсо гугл предлагает решить тестовое, кек уже нигде не спрятаться от ебучих рекрутёров
>>28947
Аноним 06/09/22 Втр 08:09:45
№
628947
>>28930
Я решал это, но мне не перезвонили.
>>29042
Аноним 06/09/22 Втр 16:21:21
№
629042
>>28947
не умеешь ПРОДАВАТЬ СЕБЯ, братишка
Аноним 06/09/22 Втр 23:02:30
№
629157
улучшил поиск - теперь результаты сортируются по релевантности
дваче-поисковик - стратегическое преимущество над остальными двачерами
некст думаю раздуплить ткинтер и прихуярить гуй - с прогрес-баром и прочими ништяками
есть несколько мелких моментов, но в целом юзабельно
алсо чёт расхотелось делать гуй, нахуй он нужен если консолька збс
стоит добавить кеширование тренделей чтоб не скачивать все посты каждый запрос
алсо хочу OR паттерны в поиске
- OR паттерны
- кешинг тренделей
- багфиксы
в начале сессии юзер настраивает параметры - TTL кеша, кол-во тредов для скачивания с каталога, длина превьюшек и задержка в секундах чтоб ублажить макакин рейт-лимитер
щас думаю добавить форчан
гуй всё еще не нужен
https://habr.com/ru/company/habr_career/blog/687126/
На протяжении четырёх исследований топ-5 специализаций, которые компании ищут чаще всего, не меняется. В августе самыми востребованными на Хабр Карьере остались бэкендеры — 797 вакансий. За ними с большим отрывом, но тоже в топе — системные аналитики — 281 вакансия. Для фронтендеров в августе опубликовали 274 вакансии, а для разработчиков мобильных приложений и девопс-инженеров — 253 и 229 вакансий соответственно.
Больше половины вакансий в августе было для middle-специалистов — 1733 вакансии. Треть вакансий — для сеньоров — 1064. У лидов спад уже ощутимее — для них в августе было 311 вакансий, а для джунов — 101. Стажёры могли откликнуться в августе на 15 вакансий, в которых указали квалификацию.
привет дружище, в старом тренделе был, если вкратце:
- мне 30 лет
- это бложик о кодинге, богатого внутреннего мира по минимуму
- кодинг с 16
- живу в бритахе с 16
- на работе воротит от скрамо-дрисни и приевшихся говнопроектов
- поэтому иногда для души пилю мелкие более-менее полезные поделки как мне нравится
- отчитываюсь итт чтоб доводить до конца
Спасибо, я так понял ты сейчас не в IT сфере, а кодинга для души? Можешь сказать, есть ли смысл мне сейчас начать изучать питона, или это путь вникуда?
Как попал в Англию изначально inb4 родители вывезли? Сложно было акклиматизироваться, нашел друзей? Как дела с тян?
Правда, что большинство англичанок страшные или откровенно уродливые, а те, что нет - с заоблачным чсв, самомнением и требованиями к партнеру?
я в ит
если загорелся делом и кайф заниматься - то конечно есть смысл
>>30125
про страшных англичанок это больше мемчик с форчана, кругом навалом стройных ухоженных женщин с красивыми зубами.
a про чсв уже правда кривят ебалом когда узнают что я иммигрант кек, фемпропаганда льётся из каждой щели, мужчина считается врагом/угнетателем с которым нужно "воевать".
есть тян - такая же иммигрантка
> Сложно было акклиматизироваться, нашел друзей?
не сложно, все очень гостеприимны
друзей из местных нет, но это только из-за моего нелюдимого характера
>если загорелся делом и кайф заниматься
Да, но как актуален это ЯП и какие сложности возникнут с трудоустройством если мне уже 28?
очень актуален как вторичный яп, для скриптов и прототипов
пилить большой ентерпраиз солюшен на питухоне - такое себе занятие, но средних размеров сервисов я повидал, в основном на джанге & GCP
если ты только начинаешь то хороший выбор братишка
> какие сложности возникнут с трудоустройством если мне уже 28?
эйджизм, зумеры сеньёры могут немного выёбываться, с этим придётся смириться
пытайся подать возраст как преимущество
Спасибо за ответ. Что насчёт пет проектов, парсер подойдёт? На собесе об этом будут ведь спрашивать.
лучший пет проект - двачепоисковик братан
сегодня ещё правил баги + добавил подсветку ключевых слов
хорошо бы запилитыпаттерны типа "-во", "сло-", "сл-во" и тд
добавил '-' паттерны для поиска
теперь можно найти все упоминания слова начинающегося/оканчивающегося на Х, либо, например, найти всех дрочеров/инцелов dr
алсо как бонус начали работать ссылки (например найти все onlyfans на дроч-досках)
Сам вкатываюсь, но фулстер через рубирельсы.
алсо писал тесты и рефакторил г-код
некст план скорее-всего обернуть всё это дело в сервис и забахать очередного телеграм бота
>>30341
спасибо братан, успехов
в этот раз с докером не пердолился - зависимостей минимум и я просто залил .зип с сорцами
несколько нюансов по сравнению с консольной версией:
- форматирование текста в телеграме оче ограничено, спасибо хоть есть <code> тег
- в вебхуках стоит таймаут - если бот тормозит то телеграм начинает меня дудосить. это больше касается двача ибо треды скачиваются оче медленно. форчан по сравнению с сосакой просто летает.
- пришлось уменьшить кол-во скачиваемых тредов на дваче до 40 (на форчане 200 скачиваются за пару секунд блядь). в ближайшем будущем скорее всего придётся подсоединить базу и сохранять pending jobs шоб ботинок мог ответить телеграму вовремя либо просто убрать сосаку
алсо хочу добавить сохранение частых запросов, например пет проекты анонов из /g/ и /pr/
если например каталог из 120 тредов разделить на 10-15 частей, то вместо 45 сек на скачивание должно уйти секунд 5-7
плюсы:
- downloader апишку можно будет переиспользовать в других петах где нужно скачать много ссылок сразу
- на базу пока можно забить
минусы:
- всёравно пердолинг
- трафик на борду
- стоимость?
решил часик покодить, лучше б продолжал отдыхать, кек. аж давление поднялось. аневризм заработаю с этой ебучей профессией
короче дропаю нахуй эту идею - то авс дрищет 413 (PAYLOAD TOO LARGE) то макака дрищет 429 (TOO MANY REQUESTS)
буду продолжать скачивать все тредики одной лямбдой
некст тогда добавить базу, сохранять таймстампы что бы вовремя ответить телеграму + добавить тг команд для сохранения запросов, будет збс
и тогда пет готов, осталось день-два
если вдруг ты макака-девелопер и нашёл меня из логов, то знай что я люблю по ночам тебе псссссссссс на личико
утро вечера мудреней - оказывается все повторы содержат идентичные сообщения и даты в них не меняются - поэтому дупликаты можно изи детектить сравнивая time.time() с date.
Айтишники Кремниевой долины сошли с ума: как набирает популярность процедура удлинения ног
https://habr.com/ru/company/getmatch/blog/689150/
Ну, крепко держитесь за стул! Потому что у гиков есть новое развлечение. Они платят кучу денег, чтобы хирургически удлинить себе ноги. Это не шутка: GQ пишет, что мужчины из Google, Amazon и других корпораций массово решаются на болезненную операцию, чтобы увеличить свой рост.
Такие операции стоят от $75 000 до $125 000, их делают популярные клиники в Лас-Вегасе и Сакраменто. Человеку ломают ноги и вставляют специальные стальные механизмы, которые со временем удлиняют кости до 15 см. Всё это время желательно поменьше двигаться, так что удалёнка пришлась очень кстати.
Айтишников предупреждают о возможных побочных эффектах и том, что это может выглядеть нелепо, ведь остальное тело в пропорциях не увеличивается. По сути, человек становится похож на кузнечика. Но они сотнями идут на это, потому что стигматизация низких мужчин в обществе всё ещё очень сильна. А чего не сделаешь ради красоты!
Один из пациентов, Джон, вспоминает первый раз, когда понял, что на самом деле стал высоким человеком. Он встал над туалетом, чтобы пописать, но траектория его струи пошла куда-то не туда. «Оно пошло повсюду!» — Рассказывает он. — «Я и не думал, что поход в туалет может быть таким опасным! Я привык к тому, что всё прямо тут, рядом. Что не надо прицеливаться. Теперь я должен приспособиться к этим лишним десяти сантиметрам».
Несмотря на такое страшное испытание, Джон говорит, после операции его жизнь улучшилась. Теперь ему нравится быть на публике. «Люди просто смотрят на тебя по-другому, когда ты высокий. Я не вру, это правда так. Я уже получаю гораздо больше оценивающих взглядов в спортзале».
.... Хрупкое эго Чада окончательно разбила более высокая женщина (175 см), с которой он встречался. Они шли по улице вместе, держась за руки, когда кто-то, проходя мимо, неодобрительно посмотрел на них. И она бросила его руку. «И я был такой: «Ясно, ты хочешь так? Если думаешь, что можешь идти с кем-то лучше, ну так иди тогда на все четыре стороны. Увидимся позже»». В декабре Чад сделал процедуру, и теперь он тоже 175 сантиметров.
Айтишники Кремниевой долины сошли с ума: как набирает популярность процедура удлинения ног
https://habr.com/ru/company/getmatch/blog/689150/
Ну, крепко держитесь за стул! Потому что у гиков есть новое развлечение. Они платят кучу денег, чтобы хирургически удлинить себе ноги. Это не шутка: GQ пишет, что мужчины из Google, Amazon и других корпораций массово решаются на болезненную операцию, чтобы увеличить свой рост.
Такие операции стоят от $75 000 до $125 000, их делают популярные клиники в Лас-Вегасе и Сакраменто. Человеку ломают ноги и вставляют специальные стальные механизмы, которые со временем удлиняют кости до 15 см. Всё это время желательно поменьше двигаться, так что удалёнка пришлась очень кстати.
Айтишников предупреждают о возможных побочных эффектах и том, что это может выглядеть нелепо, ведь остальное тело в пропорциях не увеличивается. По сути, человек становится похож на кузнечика. Но они сотнями идут на это, потому что стигматизация низких мужчин в обществе всё ещё очень сильна. А чего не сделаешь ради красоты!
Один из пациентов, Джон, вспоминает первый раз, когда понял, что на самом деле стал высоким человеком. Он встал над туалетом, чтобы пописать, но траектория его струи пошла куда-то не туда. «Оно пошло повсюду!» — Рассказывает он. — «Я и не думал, что поход в туалет может быть таким опасным! Я привык к тому, что всё прямо тут, рядом. Что не надо прицеливаться. Теперь я должен приспособиться к этим лишним десяти сантиметрам».
Несмотря на такое страшное испытание, Джон говорит, после операции его жизнь улучшилась. Теперь ему нравится быть на публике. «Люди просто смотрят на тебя по-другому, когда ты высокий. Я не вру, это правда так. Я уже получаю гораздо больше оценивающих взглядов в спортзале».
.... Хрупкое эго Чада окончательно разбила более высокая женщина (175 см), с которой он встречался. Они шли по улице вместе, держась за руки, когда кто-то, проходя мимо, неодобрительно посмотрел на них. И она бросила его руку. «И я был такой: «Ясно, ты хочешь так? Если думаешь, что можешь идти с кем-то лучше, ну так иди тогда на все четыре стороны. Увидимся позже»». В декабре Чад сделал процедуру, и теперь он тоже 175 сантиметров.
хрупче только его косточки кек
начал с устранения ТЕСНОЙ СВЯЗНОСТИ между алгоримом поиска и апишками борд
потом выделив ОРКЕСТРАЦИЮ И/О в СЕРВИСНЫЙ СЛОЙ я обрёл ТОНКИЙ КОНТРОЛЛЕР
жаль что первая консольная версия пока не вписывается в СЕРВИСНЫЙ СЛОЙ, скорее всего предстоит ещё один раунд РЕФАКТОРИНГА
> testeczky <
>testeczky<
><
<>
<testeczky ></testeczky >
<testeczky />
сегодня заказал книжку по сисдизайну. халявный пдф скачать на либрусеке к сожалению не нашёл
это недавно вышедшая вторая часть. первую читал года 2 назад - зашло ок но перечитывать не охота, примеры во второй с виду интересней
в ней рассматриваются интервьюшные задачи уровня "зделой пейсбук за 20 минут" - от тебя требуется уточнить требования, нарисовать схему на доске, попиздеть, указать на возможные УЗКИЕ МЕСТА, и тд
тема не тривиальна, с хуетой уровня "почему круги люкные" или олимпиадко-литкодопарашей ещё можно на ходу разобраться, в сисдизайне же нужна практика
плюс это интересно если я захочу мутировать в какого нибудь солюшн архитектора
рефакторинг поисковика >>31442 продолжать пока влом, но надо выделить часик как-нибудь
чувствую что устал, то кисти рук болят, то глазы слезятся, то башка едет - раздражительность на грани с паникой
10 лет назад мог педалить с утра до поздней ночи, щас ломаюсь к вечеру. a что будет через ещё 10 лет?
такие дела, милый дноъочка
большинство ресурсов по подготовке к интервью - говно, ибо ориенторивано на вкатунцов с ударением на тривиальный кодинг, алгодроч, структуры данных и литкоднище
обычно проходит несколько месяцев прежде чем будет виден вклад нового кандидата на работе, в то время как на интервью есть только 3-6 часов. поэтому появились эти прокси-метрики типа алго-дроча используя которые можно отфильтровать плохих кандидатов.
упор на именно на отфильтровку долбоёбов - компании выгоднее отказаться от хорошего кандидата который не сумел себя продать чем нанять ублюдка который обойдётся в тысячи денег, времени, говнокода и подсадит мораль команды
для сеньёрных и мидловых позиций алго-дроч занимает относительно малую часть процесса, начинают преобладать сисдизайн задачи и софт-скил вопросы типа "расскажите как вы менторили джунов"
короче интервьюшка состоит из 3х частей - на первом уровне алгодроч что бы отсеять слюнявых дебилов не умеющих кодить, потом сисдизайн что бы оценить уровень сеньёрства и умение архитектурить, и потом софт-скилс вопросы про разные рабочие моменты
алсо, сисдизайн в не малой степени является софт-скилом, во время решения задачи демонстрируется умение общатся, уточнять требования, находить компромиссы, работать в команде.
тут он начинает примерять парики своей чернокожей жены и показывать примеры хороших/плохих ответов на вопрос "расскажите о случае когда у вас были разногласия с командой". стоит составить список из 20-30 подобных вопросов и сочинить приукрашенный ответ на каждый
в конце он рекомендует тратить процентов 20% времени на алгодроч, 40% на сисдизайн, 40% на софтскиллс/лидершип
> стоит составить список из 20-30 подобных вопросов и сочинить приукрашенный ответ на каждый
Action-oriented behavioral interview question examples
1. Describe a situation when you did much more than was expected from you to get the project done. Were your efforts recognized? By whom and how? How did that make you feel?
2. Tell me about a time when you took ownership of a project. Why did you do this? What was the result of you taking the challenge? What could have happened if you did not take ownership?
3. Think about an instance in which you came up with a project idea that was implemented primarily because of your efforts. What was it about? What was its outcome? What was your role?
4. Describe a time when you made a suggestion to improve something on the project that you were working on.
5. Give me an example of the project or initiative that you started on your own. It can be a non-business one. What prompted you to get started?
Behavioral interview questions examples showing ability to adapt
6. Describe a situation in which you met a major obstacle in order to complete a project. How did you deal with it? What steps did you take?
7. Tell me about a time you had to work on several projects at once. How did you handle that?
8. Describe a situation in which you have experienced a significant project change that you weren’t expecting. What was it? How did that impact you, and how did you adapt to this change? How did you remain productive throughout the project?
9. Describe a situation in which you had to adjust to changes over which you had no control. How did you do this?
Communication skills: behavioral interview question examples
10. I’d be interested in hearing about a miscommunication you had with your supervisor. How did you solve it? What was the reason for that? How did you deal with that situation?
11. Tell me about an instance when you had to communicate a really bad piece of news to your supervisor or team members. How did you handle it? What was the outcome?
12. Provide an example of a time when you didn’t agree with other programmers. Did you stand up for something that you believed was right?
13. Tell me about a time when you had to present a complex programming problem to a person that didn’t understand technical jargon. How did you ensure that the other person understood you?
14. Describe a situation in which you felt you had not communicated well enough. What did you do? How did you handle it?
15. Tell me about a situation that you had to speak up and be assertive in order to get a point across that was important for you.
Conflict management behavioral interview questions
16. Tell me about a time when you had a disagreement with another programmer. How did you handle the situation? Were you able to reach a mutually beneficial resolution to that conflict? If not, why were you and your co-worker unable to reach a mutually beneficial resolution? If you knew then what you know now, what would you have done differently to either prevent the conflict, or to resolve it?
17. Tell me about a time when you had to work with a difficult person to accomplish a goal. What was the biggest challenge? How did you handle it?
18. Has there been a time on a project when you disagreed with someone? What did you do about it?
19. Tell me about when you had to deal with conflict within your team. How was the conflict solved? How did you handle that? How would you deal with it now?
Creativity behavioral interview questions
20. Give me an example of a time you had to take a creative and unusual approach to solve a coding problem. How did this idea come to your mind? Why do you think it was unusual?
Decision making behavioral interview questions
21. Give me an example of a time when you were faced with a complex project related matter and you could not decide on the best way to deal with it. What did you do? How did you go about making the decision – lead me through your decision process? If you could make the decision once again, would you change anything
22. Think about an instance in which you made a decision at work that was unpopular. How did you handle it?
23. Give me an example of a project that completely failed. Why do you think it was a failure? Could there be anything done differently in order to turn it into success?
24. Describe a situation in which you worked diligently on a project and it did not produce the desired results. Why didn’t you get the desired results? What did you learn from the experience?
25. Think about a situation when you made a poor decision or did something that just didn’t turn outright. What happened?
Goal orientated behavioral interview questions
26. Provide an example of an important project goal you reached and how you achieved it.
27. Think about an instance in which you worked on and achieved multiple project goals.
28. Describe a circumstance when you were not able to achieve a project goal that was set by your supervisor. How did you handle this situation? What was the outcome?
29. Think about an instance in which you had to depend on others to help you achieve a project goal. How did you feel?
Influence/persuasion behavioral interview questions
30. Tell me about a recent situation at work in which you were able to convince management to accept one of your ideas.
31. Describe a situation in which you experienced difficulty in getting others to accept your ideas? What was your approach? How did this work? Were you able to successfully persuade someone to see things your way?
32. Have you ever had to “sell” an idea to your project team? How did you do it? Did they “buy” it?
Planning, priority setting, time management behavioral interview questions
33. Tell me about a situation when you were responsible for project planning. Did everything go according to your plan? If not, then why and what kind of counteractions did you have to take?
34. Tell me about a situation when you were responsible for project planning. Did everything go according to your plan? If not, then why and what kind of counteractions did you have to take?
Problem-solving behavioral interview questions
35. Tell me about a situation when you made a mistake at work. What happened exactly and how did you deal with it? What steps did you take to improve the situation?
36. What is the biggest problem you have faced on projects so far and how did you solve it? What made the problem difficult to resolve? What was the result? Would you do anything differently now?
37. Give me an example of a time when you noticed a small problem before it turned into a major one. Did you take the initiative to correct it? What kind of preventive measure did you undertake?
38. Walk me through a difficult/complex problem/project you encountered. How did you decide what to do first? What information did you need? What obstacles did you face? Which ones were you able to overcome? Did you have to ask for help?
Teamwork behavioral interview questions
39. Tell me about a time when you worked with someone who was not completing his or her share of the work. How did you handle the situation? Did you discuss your concern with your coworker? With your manager? If yes, how did your coworker respond to your concern? What was your manager’s response?
40. Describe a situation where you had to work in a team that didn’t get on very well. What happened? What did you do and what role did you take? How did the situation evolve?
41. Describe a team experience you found disappointing. What would you have done differently to prevent this?
42. Give me an example of working cooperatively as a team member to accomplish an important goal. What was the objective? To what extent did you interact with other project members?
43. Tell me about the most difficult situation you have had when leading a team. What happened and how did you handle it? Were you successful? What was the most important thing you did?
Working under pressure behavioral interview questions
44. Describe a situation when you worked effectively under pressure. How did you feel when working under pressure? What was going on, and how did you get through it?
45. Tell me about a situation when you had problems working under pressure. How did you handle that situation? Did you decide to ask for support? How and when did you ask for help?
46. Give me a recent example of a stressful situation on the job. What happened? How did you handle it?
> стоит составить список из 20-30 подобных вопросов и сочинить приукрашенный ответ на каждый
Action-oriented behavioral interview question examples
1. Describe a situation when you did much more than was expected from you to get the project done. Were your efforts recognized? By whom and how? How did that make you feel?
2. Tell me about a time when you took ownership of a project. Why did you do this? What was the result of you taking the challenge? What could have happened if you did not take ownership?
3. Think about an instance in which you came up with a project idea that was implemented primarily because of your efforts. What was it about? What was its outcome? What was your role?
4. Describe a time when you made a suggestion to improve something on the project that you were working on.
5. Give me an example of the project or initiative that you started on your own. It can be a non-business one. What prompted you to get started?
Behavioral interview questions examples showing ability to adapt
6. Describe a situation in which you met a major obstacle in order to complete a project. How did you deal with it? What steps did you take?
7. Tell me about a time you had to work on several projects at once. How did you handle that?
8. Describe a situation in which you have experienced a significant project change that you weren’t expecting. What was it? How did that impact you, and how did you adapt to this change? How did you remain productive throughout the project?
9. Describe a situation in which you had to adjust to changes over which you had no control. How did you do this?
Communication skills: behavioral interview question examples
10. I’d be interested in hearing about a miscommunication you had with your supervisor. How did you solve it? What was the reason for that? How did you deal with that situation?
11. Tell me about an instance when you had to communicate a really bad piece of news to your supervisor or team members. How did you handle it? What was the outcome?
12. Provide an example of a time when you didn’t agree with other programmers. Did you stand up for something that you believed was right?
13. Tell me about a time when you had to present a complex programming problem to a person that didn’t understand technical jargon. How did you ensure that the other person understood you?
14. Describe a situation in which you felt you had not communicated well enough. What did you do? How did you handle it?
15. Tell me about a situation that you had to speak up and be assertive in order to get a point across that was important for you.
Conflict management behavioral interview questions
16. Tell me about a time when you had a disagreement with another programmer. How did you handle the situation? Were you able to reach a mutually beneficial resolution to that conflict? If not, why were you and your co-worker unable to reach a mutually beneficial resolution? If you knew then what you know now, what would you have done differently to either prevent the conflict, or to resolve it?
17. Tell me about a time when you had to work with a difficult person to accomplish a goal. What was the biggest challenge? How did you handle it?
18. Has there been a time on a project when you disagreed with someone? What did you do about it?
19. Tell me about when you had to deal with conflict within your team. How was the conflict solved? How did you handle that? How would you deal with it now?
Creativity behavioral interview questions
20. Give me an example of a time you had to take a creative and unusual approach to solve a coding problem. How did this idea come to your mind? Why do you think it was unusual?
Decision making behavioral interview questions
21. Give me an example of a time when you were faced with a complex project related matter and you could not decide on the best way to deal with it. What did you do? How did you go about making the decision – lead me through your decision process? If you could make the decision once again, would you change anything
22. Think about an instance in which you made a decision at work that was unpopular. How did you handle it?
23. Give me an example of a project that completely failed. Why do you think it was a failure? Could there be anything done differently in order to turn it into success?
24. Describe a situation in which you worked diligently on a project and it did not produce the desired results. Why didn’t you get the desired results? What did you learn from the experience?
25. Think about a situation when you made a poor decision or did something that just didn’t turn outright. What happened?
Goal orientated behavioral interview questions
26. Provide an example of an important project goal you reached and how you achieved it.
27. Think about an instance in which you worked on and achieved multiple project goals.
28. Describe a circumstance when you were not able to achieve a project goal that was set by your supervisor. How did you handle this situation? What was the outcome?
29. Think about an instance in which you had to depend on others to help you achieve a project goal. How did you feel?
Influence/persuasion behavioral interview questions
30. Tell me about a recent situation at work in which you were able to convince management to accept one of your ideas.
31. Describe a situation in which you experienced difficulty in getting others to accept your ideas? What was your approach? How did this work? Were you able to successfully persuade someone to see things your way?
32. Have you ever had to “sell” an idea to your project team? How did you do it? Did they “buy” it?
Planning, priority setting, time management behavioral interview questions
33. Tell me about a situation when you were responsible for project planning. Did everything go according to your plan? If not, then why and what kind of counteractions did you have to take?
34. Tell me about a situation when you were responsible for project planning. Did everything go according to your plan? If not, then why and what kind of counteractions did you have to take?
Problem-solving behavioral interview questions
35. Tell me about a situation when you made a mistake at work. What happened exactly and how did you deal with it? What steps did you take to improve the situation?
36. What is the biggest problem you have faced on projects so far and how did you solve it? What made the problem difficult to resolve? What was the result? Would you do anything differently now?
37. Give me an example of a time when you noticed a small problem before it turned into a major one. Did you take the initiative to correct it? What kind of preventive measure did you undertake?
38. Walk me through a difficult/complex problem/project you encountered. How did you decide what to do first? What information did you need? What obstacles did you face? Which ones were you able to overcome? Did you have to ask for help?
Teamwork behavioral interview questions
39. Tell me about a time when you worked with someone who was not completing his or her share of the work. How did you handle the situation? Did you discuss your concern with your coworker? With your manager? If yes, how did your coworker respond to your concern? What was your manager’s response?
40. Describe a situation where you had to work in a team that didn’t get on very well. What happened? What did you do and what role did you take? How did the situation evolve?
41. Describe a team experience you found disappointing. What would you have done differently to prevent this?
42. Give me an example of working cooperatively as a team member to accomplish an important goal. What was the objective? To what extent did you interact with other project members?
43. Tell me about the most difficult situation you have had when leading a team. What happened and how did you handle it? Were you successful? What was the most important thing you did?
Working under pressure behavioral interview questions
44. Describe a situation when you worked effectively under pressure. How did you feel when working under pressure? What was going on, and how did you get through it?
45. Tell me about a situation when you had problems working under pressure. How did you handle that situation? Did you decide to ask for support? How and when did you ask for help?
46. Give me a recent example of a stressful situation on the job. What happened? How did you handle it?
глава 1
задача:
по координатам пользователя и заданному радиусу вывести на карте все близлежащие объекты - жральни, сральни, бордели, музеи, театры и прочее
функциональные требования:
- юзер задаёт радиус до 20км (инкрементами по 500м)
- владельцы объектов сами добавляют о себе инфу (добавленные объекты смогут появляться на карте со следующего дня)
- юзер может кликнуть на объект на карте и получить детальную инфу о нём
нефункциональные требования:
- низкий пинг
- приватность (не слить местоположение юзеров)
- высокая надёжность и маштабируемость
прикинем нагрузку на сервис:
давай допустим 100 миллионов пользователей в день и 200 миллионов объектов, по 5 запросов в день от пользователя
получим 5000 запросов в секунду. а чо по час-пику?
окей, начнём решение с апишки:
GET /v1/search/nearby
аргументы - долгота и широта юзера, радиус
результат - джейсончик со списком близлежащих объектов
GET/POST/PUT/DELETE /v1/businesses/:id?
апишка для добавления/изменения/удаления объектов
модель данных:
объекты меняются редко, поэтому соотношение чтения/записи будет оче высоким. имеет смысл иметь несколько рид-онли копий базы только для чтения
табличка для объектов: тут всё просто, храним business_id, адрес, координаты, и тд
географический индекс: для эффективного отображения местоположения юзера в список близких объектов
выбираем алгоритм для вычисления близлежащих объектов:
- наивный поиск перебором. просто проходим по всему списку (200,000,000) объектов и фильтруем ближайшие.
неэффективно даже если индексировать широту и долготу до усрачки - всё равно получается пересечение двух огромных множеств 5000 раз в сек
- геохэш, разбиваем весь мир на кусочки, придаём каждому последовательность битов и кодируем в base64 (второй пик)
чем ближе кусочки, тем больше будет совпадать префикс хеша
есть крайние случаи когда префиксы различаются для соседей - поэтому нужно читать все примыкающие кусочки
- Google S2. самый выёбистый алгоритм, используется тиндером и конечно гугл мапсом.
приображает 2Д пространство в 1Д линию (кривая Гильберта) хорошо сохраняя истинную дистанцию между объектами
для 40 минутного интервью слишкам сложна, поэтому не рекомендуют
победитель - геохеш
теперь маштабируем базу данных:
все 200 миллионов объектов не поместятся в одну базу - будем шардировать по айдишке
для гео-индекса у нас 2 варианта:
- храним геохеш вместе со списком айдишек объектов в одной строке
- либо делаем композитный ключ из геохеша и айдишки
композитный ключ лучше - проще операции над объектами + ненадо локать строку
гео-индекс может уместится на одной машинке - с шардингом не спешить
делаем несколько реплик что бы справится с 5к запросов
кеширование:
будем кешировать объекты по ключу геохеша - хорошо поможет в час пик
можно подумать когда инвалидировать кеш либо просто весить таймер на каждый ключ - для этой задачи немедленная согласованность не нужна
боремся с пингом:
read-only компоненты системы задеплоим сразу в несколько регионов земного диска - юзер будет обращатся к ближайшему
глава 1
задача:
по координатам пользователя и заданному радиусу вывести на карте все близлежащие объекты - жральни, сральни, бордели, музеи, театры и прочее
функциональные требования:
- юзер задаёт радиус до 20км (инкрементами по 500м)
- владельцы объектов сами добавляют о себе инфу (добавленные объекты смогут появляться на карте со следующего дня)
- юзер может кликнуть на объект на карте и получить детальную инфу о нём
нефункциональные требования:
- низкий пинг
- приватность (не слить местоположение юзеров)
- высокая надёжность и маштабируемость
прикинем нагрузку на сервис:
давай допустим 100 миллионов пользователей в день и 200 миллионов объектов, по 5 запросов в день от пользователя
получим 5000 запросов в секунду. а чо по час-пику?
окей, начнём решение с апишки:
GET /v1/search/nearby
аргументы - долгота и широта юзера, радиус
результат - джейсончик со списком близлежащих объектов
GET/POST/PUT/DELETE /v1/businesses/:id?
апишка для добавления/изменения/удаления объектов
модель данных:
объекты меняются редко, поэтому соотношение чтения/записи будет оче высоким. имеет смысл иметь несколько рид-онли копий базы только для чтения
табличка для объектов: тут всё просто, храним business_id, адрес, координаты, и тд
географический индекс: для эффективного отображения местоположения юзера в список близких объектов
выбираем алгоритм для вычисления близлежащих объектов:
- наивный поиск перебором. просто проходим по всему списку (200,000,000) объектов и фильтруем ближайшие.
неэффективно даже если индексировать широту и долготу до усрачки - всё равно получается пересечение двух огромных множеств 5000 раз в сек
- геохэш, разбиваем весь мир на кусочки, придаём каждому последовательность битов и кодируем в base64 (второй пик)
чем ближе кусочки, тем больше будет совпадать префикс хеша
есть крайние случаи когда префиксы различаются для соседей - поэтому нужно читать все примыкающие кусочки
- Google S2. самый выёбистый алгоритм, используется тиндером и конечно гугл мапсом.
приображает 2Д пространство в 1Д линию (кривая Гильберта) хорошо сохраняя истинную дистанцию между объектами
для 40 минутного интервью слишкам сложна, поэтому не рекомендуют
победитель - геохеш
теперь маштабируем базу данных:
все 200 миллионов объектов не поместятся в одну базу - будем шардировать по айдишке
для гео-индекса у нас 2 варианта:
- храним геохеш вместе со списком айдишек объектов в одной строке
- либо делаем композитный ключ из геохеша и айдишки
композитный ключ лучше - проще операции над объектами + ненадо локать строку
гео-индекс может уместится на одной машинке - с шардингом не спешить
делаем несколько реплик что бы справится с 5к запросов
кеширование:
будем кешировать объекты по ключу геохеша - хорошо поможет в час пик
можно подумать когда инвалидировать кеш либо просто весить таймер на каждый ключ - для этой задачи немедленная согласованность не нужна
боремся с пингом:
read-only компоненты системы задеплоим сразу в несколько регионов земного диска - юзер будет обращатся к ближайшему
>кривая Гильберта
О, я её делал в >>569313 → для произвольного размера (против квадрата со стороной-степенью двойки; украв алгоритм из lutanho.net/pic2html/draw_sfc.html), я делал :3.
точняк братан, она самая
задача: спроектируйте бекенд для фичи наподобие фейсбуковского "nearby friends".
функциональные требования:
- в списке показываются друзья + расстояние до каждого
- расстояния обновляются в реальном времени
- если друг слишком далеко или неактивен, он убирается из списка
нефункциональные требования:
- низкий пинг (это всегда требуется кек)
- надёжность и консистентность не так важны, не беда если апдейты иногда теряются
прикидываем трафик:
- допустим 100 миллионов пользователей, из них 10 миллионов пользуются фичей в любое время дня
- допустим у каждого пользователя 400 друзей
- допустим клиент шлёт своё местоположение каждые 30 сек, апдейты от друзей приходят сразу
- получаем 10мил / 30 = ~300к запросов в секунду на апдейт локейшенов
- алсо получаем ~300к 400 10% = ~14 миллионов исходящих апдейтов от друзей в секунду
- по моим подсчётам выйдет 0.5-2кб/сек трафика на одного клиента
общий дизайн решения/бекенда (пик 2)
- P2P решение авторы сразу отбрасывают, мол у мобилок нестабильное соединение + приложение будет жечь аккумулаторы
- бекенд будет поддерживать двусторонние соединения (вебсокеты)
- устанавливаем сокетное соединение к конкретному серверу
- каждые 30 сек шлём свое местоположение
- местоположения юзеров будем хранить в редисе с TTL (изи автоудаление по инактивности)
- редис pub/sub реагирует на апдейт и оповещает каждого подписчика-сервера
- сервер решает слать или не слать апдейт локации друга (если друг слишком далеко - игнорим)
апишка и модель данных:
тут сложности минимально. несколько очевидных типов вебсокет сообщений + кеш где храним локацию юзеров
кеш вместо БД, потому что без БД вполне можно обойтись и нас не волнует если кеш упадёт - новый быстро прогреется
маштабирование:
- вебсокетные сервера обладают состоянием, если один умрёт то части юзеров придётся реконнектиться
- алсо перед тем как заапдейтить сервер, его надо пометить в балансировщике что новые соединения больше не принимаются
- серверов нужно приличное количество что бы поддерживать наши 10 миллионов одновременных соединений
- редис pub/sub кластер: для 14 миллионов апдейтов в секунду авторы прикинули 140 машин.
- pub/sub каналы и подписки распределяются на эти 140 машин (ключ канала - айдишка юзера)
альтернативы редису:
авторы алсо предлагают переписать систему на замечательном яп для рапределённых систем - Эрланге
это упростит архитектуру и позволит выбросить редисы - вся логика оповещений будет жить на вебсокет-серверах
однако, хороших эрланг-программистов на рынке мало - к этому нужно отнестись с пониманием
задача: спроектируйте бекенд для фичи наподобие фейсбуковского "nearby friends".
функциональные требования:
- в списке показываются друзья + расстояние до каждого
- расстояния обновляются в реальном времени
- если друг слишком далеко или неактивен, он убирается из списка
нефункциональные требования:
- низкий пинг (это всегда требуется кек)
- надёжность и консистентность не так важны, не беда если апдейты иногда теряются
прикидываем трафик:
- допустим 100 миллионов пользователей, из них 10 миллионов пользуются фичей в любое время дня
- допустим у каждого пользователя 400 друзей
- допустим клиент шлёт своё местоположение каждые 30 сек, апдейты от друзей приходят сразу
- получаем 10мил / 30 = ~300к запросов в секунду на апдейт локейшенов
- алсо получаем ~300к 400 10% = ~14 миллионов исходящих апдейтов от друзей в секунду
- по моим подсчётам выйдет 0.5-2кб/сек трафика на одного клиента
общий дизайн решения/бекенда (пик 2)
- P2P решение авторы сразу отбрасывают, мол у мобилок нестабильное соединение + приложение будет жечь аккумулаторы
- бекенд будет поддерживать двусторонние соединения (вебсокеты)
- устанавливаем сокетное соединение к конкретному серверу
- каждые 30 сек шлём свое местоположение
- местоположения юзеров будем хранить в редисе с TTL (изи автоудаление по инактивности)
- редис pub/sub реагирует на апдейт и оповещает каждого подписчика-сервера
- сервер решает слать или не слать апдейт локации друга (если друг слишком далеко - игнорим)
апишка и модель данных:
тут сложности минимально. несколько очевидных типов вебсокет сообщений + кеш где храним локацию юзеров
кеш вместо БД, потому что без БД вполне можно обойтись и нас не волнует если кеш упадёт - новый быстро прогреется
маштабирование:
- вебсокетные сервера обладают состоянием, если один умрёт то части юзеров придётся реконнектиться
- алсо перед тем как заапдейтить сервер, его надо пометить в балансировщике что новые соединения больше не принимаются
- серверов нужно приличное количество что бы поддерживать наши 10 миллионов одновременных соединений
- редис pub/sub кластер: для 14 миллионов апдейтов в секунду авторы прикинули 140 машин.
- pub/sub каналы и подписки распределяются на эти 140 машин (ключ канала - айдишка юзера)
альтернативы редису:
авторы алсо предлагают переписать систему на замечательном яп для рапределённых систем - Эрланге
это упростит архитектуру и позволит выбросить редисы - вся логика оповещений будет жить на вебсокет-серверах
однако, хороших эрланг-программистов на рынке мало - к этому нужно отнестись с пониманием
задачки о картах и координатах уже подзаебали, поэтому скипаю и перехожу к четвёртой про очереди сообщений
алсо прочитав в прошлой главе об эрланге и эликсире, воодушевился пощупать эту замечательную технологию - может после сисдизайна. пик стронгли релкйтед
задача:
спроектируйте распределённую очередь сообщений
функциональные требования:
- производитель посылает сообщения в очередь, потребитель их оттуда достаёт
- сообщения могут быть прочитаны несколько раз
- размер сообщений - килобайты
- у очереди может быть несколько потребителей разных типов
- потребители читают сообщения в том порядке в котором они были добавлены
- потребители читают сообщения с удобной для них скоростью не мешая другим потребителям
- настраиваемая семантика доставки - минимум один раз, максимум один раз, ровно один раз
- сообщения сохраняются в очереди на определённое время (дефаулт 7 дней)
нефункциональные требования:
- настраиваемая пропускная способность против низкой задержки
- маштабируемость
- нельзя проёбывать сообщения - иначе пизда
модели обмена сообщений:
- point-to-point, сообщение читается одним и только одним потребителем. как только потребитель подтверждает доставку, сообщение удаляется из очереди
- publish-subscribe, сообщение может быть прочитано несколько раз несколькими разными потребителями. сообщения хранятся в диске определённое количество дней
для нашей задачки больше подходит второе
топики, шарды, брокеры:
разные типы сообщений будут делится на топики. потребители могут подписыватся на интересующие их топики
сообщений может быть очень много - что бы все уместились мы разделим топик на части (шарды) и распределяем сообщения равномерно между ними
шарды алсо равномерно распределены между серверами нашей очереди - брокерами.
сообщения шардятся по ключу (напр айдишка юзера) и отправляются в соответвующий брокер в порядке добавления
теперь подробности
хранение данных:
очередь должна поддерживать одновременно чтение и запись в большом объёме, без изменений/удалений. обычная БД тут не подойдёт
будем использовать лог-файлы на диске и писать прямо в них - добавляя сообщения в конец файла.
последовательные чтение и запись в дисках очень быстры - это даст нам необходимую производительность
чтоб файлы не росли слишком большими, будем делить их на сегменты. один сегмент всегда активен, новые сообщения добавляются в конец сегмента
тут авторы приводят аргументы в пользу старых вращающихся дисков, мол скорость последовательного доступа у них збс, дешёво и сердито, ну ок чо мне поебать
структура сообщений в логах:
два главных поля - это ключ (для шардинга и вообще) и значение
остальные поля - топик, айдишка шарда, оффсеты, размер, срс и тд добавляются очередью после получения
батчинг:
что бы избежать I/O налога, сообщения батчатся (группируются в одну операцию) при посылании, получении и хранении. батчинг критичен для перформанса системы
система может казаться более отзывчивой при маленьком размере батча, но пропускная способность пострадает. тут нужно находить правильный трейдофф.
потребительская апишка:
тут мы взвешиваем push vs pull для нашей очереди
у push потребители быстрее поймают новое сообщение, но можно случайно заддосить потребителей
у pull потребители контролируют скорость потребления и скейлятся как им надо. лишние поллы если очередь пустая, но это более-менее решается лонг-поллингом
pull выигрывает
метаданные:
у нас будет небольшой сервис для хранения конфигов и технических деталей очереди. авторы предлагают ZooKeeper
репликация:
что бы обеспечить высокую доступность, наши шарды будут реплицированны - несколько копий шарда расбросаны по разным машинам на случай поломок
следуем leader/follower семантике, производители шлют сообщения лидерам, которые потом копируются на фолловеров.
нам не нужно ждать полной синхронизации между лидером и фолловерами. как только какое-то настраиваемое число фолловеров сохранило новое сообщение, мы сообщаем производителю об успешной записи (оставшиеся фолловеры получат это сообщение асинхронно)
тут авторы прикидывают кол-во фолловеров которые обязательно должны синхронизироваться при каждой записи.
- если все, то доставка супер надёжна, но записи занимают больше времени, особенно если одна машинка тормозит
- если ноль, то сообщение может быть проёбано если лидер-машина сломаетса, но записи в очередь будут быстрее со стороны производителя
- число между нулём и всеми - оптимальный баланс между скоростью и надёжностью. копия сообщения в нескольких местах + мы не ждём самых тормознутых машин
семантика доставки сообщений:
- максимум один раз (не больше одного раза - КО). чревато потерей сообщений но изи реализуется и эффективно
- минимум один раз (не менее одного раза - КО). самая популярная схема, сообщения никогда не теряются, но могут быть доставлены повторно. все серьёзные приложения в любом случае проектируются с идемпотентностью. cloud native = idempotence
- ровно один раз - крайне сложна в реализации, но приятно пользоваться когда есть такие гарантии
(выбранная семантика имеет силу как со стороны потребителя, так и со стороны производителя)
задача:
спроектируйте распределённую очередь сообщений
функциональные требования:
- производитель посылает сообщения в очередь, потребитель их оттуда достаёт
- сообщения могут быть прочитаны несколько раз
- размер сообщений - килобайты
- у очереди может быть несколько потребителей разных типов
- потребители читают сообщения в том порядке в котором они были добавлены
- потребители читают сообщения с удобной для них скоростью не мешая другим потребителям
- настраиваемая семантика доставки - минимум один раз, максимум один раз, ровно один раз
- сообщения сохраняются в очереди на определённое время (дефаулт 7 дней)
нефункциональные требования:
- настраиваемая пропускная способность против низкой задержки
- маштабируемость
- нельзя проёбывать сообщения - иначе пизда
модели обмена сообщений:
- point-to-point, сообщение читается одним и только одним потребителем. как только потребитель подтверждает доставку, сообщение удаляется из очереди
- publish-subscribe, сообщение может быть прочитано несколько раз несколькими разными потребителями. сообщения хранятся в диске определённое количество дней
для нашей задачки больше подходит второе
топики, шарды, брокеры:
разные типы сообщений будут делится на топики. потребители могут подписыватся на интересующие их топики
сообщений может быть очень много - что бы все уместились мы разделим топик на части (шарды) и распределяем сообщения равномерно между ними
шарды алсо равномерно распределены между серверами нашей очереди - брокерами.
сообщения шардятся по ключу (напр айдишка юзера) и отправляются в соответвующий брокер в порядке добавления
теперь подробности
хранение данных:
очередь должна поддерживать одновременно чтение и запись в большом объёме, без изменений/удалений. обычная БД тут не подойдёт
будем использовать лог-файлы на диске и писать прямо в них - добавляя сообщения в конец файла.
последовательные чтение и запись в дисках очень быстры - это даст нам необходимую производительность
чтоб файлы не росли слишком большими, будем делить их на сегменты. один сегмент всегда активен, новые сообщения добавляются в конец сегмента
тут авторы приводят аргументы в пользу старых вращающихся дисков, мол скорость последовательного доступа у них збс, дешёво и сердито, ну ок чо мне поебать
структура сообщений в логах:
два главных поля - это ключ (для шардинга и вообще) и значение
остальные поля - топик, айдишка шарда, оффсеты, размер, срс и тд добавляются очередью после получения
батчинг:
что бы избежать I/O налога, сообщения батчатся (группируются в одну операцию) при посылании, получении и хранении. батчинг критичен для перформанса системы
система может казаться более отзывчивой при маленьком размере батча, но пропускная способность пострадает. тут нужно находить правильный трейдофф.
потребительская апишка:
тут мы взвешиваем push vs pull для нашей очереди
у push потребители быстрее поймают новое сообщение, но можно случайно заддосить потребителей
у pull потребители контролируют скорость потребления и скейлятся как им надо. лишние поллы если очередь пустая, но это более-менее решается лонг-поллингом
pull выигрывает
метаданные:
у нас будет небольшой сервис для хранения конфигов и технических деталей очереди. авторы предлагают ZooKeeper
репликация:
что бы обеспечить высокую доступность, наши шарды будут реплицированны - несколько копий шарда расбросаны по разным машинам на случай поломок
следуем leader/follower семантике, производители шлют сообщения лидерам, которые потом копируются на фолловеров.
нам не нужно ждать полной синхронизации между лидером и фолловерами. как только какое-то настраиваемое число фолловеров сохранило новое сообщение, мы сообщаем производителю об успешной записи (оставшиеся фолловеры получат это сообщение асинхронно)
тут авторы прикидывают кол-во фолловеров которые обязательно должны синхронизироваться при каждой записи.
- если все, то доставка супер надёжна, но записи занимают больше времени, особенно если одна машинка тормозит
- если ноль, то сообщение может быть проёбано если лидер-машина сломаетса, но записи в очередь будут быстрее со стороны производителя
- число между нулём и всеми - оптимальный баланс между скоростью и надёжностью. копия сообщения в нескольких местах + мы не ждём самых тормознутых машин
семантика доставки сообщений:
- максимум один раз (не больше одного раза - КО). чревато потерей сообщений но изи реализуется и эффективно
- минимум один раз (не менее одного раза - КО). самая популярная схема, сообщения никогда не теряются, но могут быть доставлены повторно. все серьёзные приложения в любом случае проектируются с идемпотентностью. cloud native = idempotence
- ровно один раз - крайне сложна в реализации, но приятно пользоваться когда есть такие гарантии
(выбранная семантика имеет силу как со стороны потребителя, так и со стороны производителя)
видос о мини-культуре "overemployed" где вместо карьерного роста анальники растут в ширину - работая сразу на нескольких кодинг работах
это стало возможно с массовым приходом удалёнки
для себя вижу несколько жирных плюсов, текущая работа в среднем занимает 2-4 часа в день и в принципе я бы смог удвоить зарплатку и вытянуть ещё одну такую же должность
алсо оверемплоймент позволит немного остудить рыночек и восполнить нехватку айтишников
несколько нюансов:
- задачи на работах выполнять по-минимуму что бы экономить время, нужно быть готовым к увольнению в любой момент и жирному severance package кек
- стоит брать работку "ниже себя". например если вы сеньёр, то прикинуться джуном или миддлом дабы меньше напрягаться
- кекный момент - отмазки от собраний если они конфликтуют по времени дня https://overemployed.com/manage-conflicting-meetings/
задача:
спроектируйте систему мониторинга метрик
функциональные требования:
- поддержка разных метрик - нагрузка процессора, кол-во запросов, использованная память, кол-во транзакций, и тд
- поддержка до 100 метрик с узла и до 10 миллионов метрик в секунду
- метрики хранятся 1 год
- в сыром виде (посекундно) 7 дней, потом до 30 дней сворачиваем поминутно, потом почасово до года (экономия места)
- красивые графики и анальные алерты по ночам
нефункциональные требования:
- стандартный набор баззвордов
- логи нас не интересуют
- трейсинг запросов нас не интересует
компоненты системы:
- сбор метрик внутри узла (проц, память, и тд)
- передача этих метрик из узла в систему мониторинга (push vs pull)
- организация и хранение этих метрик внутри системы (будет спец база данных для временных рядов)
- предупреждения/алерты если система задетектила проблему (напр узел отвалился или платежи прекратились)
- визуализация в красивых графиках (пик 2)
модель данных:
короче временной ряд - имя метрики, значение, теги и время
пример:
metric_name: cpu.load
labels: host:i611,env:prod
timestamp: 1614809865
value: 0.81
паттерны доступа:
- очень много записей в БД, просто ебанутое количество
- а чтения относительно мало, это либо подсистема алёртов гоняет автоматические запросы каждую минуту, либо оператор смотрит на графики
- алсо паттерны чтения очень не равномерны
хранение данных:
тут главное показать понимание существования баз данных специфично для временных рядов
есть InfluxDB, алсо есть AWS Timestream и например Prometheus
подробности особо не нужны
общий дизайн пик 3
теперь больше подробностей:
сбор метрик (push vs pull):
для нас допустимо иногда терять точки данных
две модели для сбора, push & pull, однозначно лучшей нет, у каждной свои плюсы/минусы, всё зависит от ситуации и иногда нужно реализовать обе
pull: коллектор метрик обходит каждый узел и собирает метрики с каждого (например каждый узел реализует /metrics хттп ендпойнт)
push: каждый узел сам самостоятельно высылает метрики коллектору (на каждом узле работает агент сбора метрик отдельно от приложения)
маштабирование трансмиссии метрик в систему:
между коллектором и БД авторы предлагают вставить Кафку - будет служить как буфер между сборкой и хранением и позволит подгружать данные более равномерно + потребители очереди смогут обработать метрики перед записью
алсо даунтайм БД не прекратит сбор метрик - они могут хранится в кафке несколько дней
админить кафку лютейший гемор - если интервьюер возбухнёт, то есть (менее надёжные но проще) альтернативы для этого специфичного кейса
несколько нюансов с БД:
- огромное количество хранимых метрик, упомянуть компрессию и даунсемплинг (переход от секунд к минутам, потом к часам)
- старые данные переводить в холодное хранилище
сервис запросов:
апишка перед базой чтоб не привязывать алерты и визуализацию к конкретной базе
сюда можно добавить кеш
алерты:
сервис алертов будет периодически посылать запросы в бд и поднимать тревогу если найдёт аномальность
визуализация:
готовый сервис типа графаны
задача:
спроектируйте систему мониторинга метрик
функциональные требования:
- поддержка разных метрик - нагрузка процессора, кол-во запросов, использованная память, кол-во транзакций, и тд
- поддержка до 100 метрик с узла и до 10 миллионов метрик в секунду
- метрики хранятся 1 год
- в сыром виде (посекундно) 7 дней, потом до 30 дней сворачиваем поминутно, потом почасово до года (экономия места)
- красивые графики и анальные алерты по ночам
нефункциональные требования:
- стандартный набор баззвордов
- логи нас не интересуют
- трейсинг запросов нас не интересует
компоненты системы:
- сбор метрик внутри узла (проц, память, и тд)
- передача этих метрик из узла в систему мониторинга (push vs pull)
- организация и хранение этих метрик внутри системы (будет спец база данных для временных рядов)
- предупреждения/алерты если система задетектила проблему (напр узел отвалился или платежи прекратились)
- визуализация в красивых графиках (пик 2)
модель данных:
короче временной ряд - имя метрики, значение, теги и время
пример:
metric_name: cpu.load
labels: host:i611,env:prod
timestamp: 1614809865
value: 0.81
паттерны доступа:
- очень много записей в БД, просто ебанутое количество
- а чтения относительно мало, это либо подсистема алёртов гоняет автоматические запросы каждую минуту, либо оператор смотрит на графики
- алсо паттерны чтения очень не равномерны
хранение данных:
тут главное показать понимание существования баз данных специфично для временных рядов
есть InfluxDB, алсо есть AWS Timestream и например Prometheus
подробности особо не нужны
общий дизайн пик 3
теперь больше подробностей:
сбор метрик (push vs pull):
для нас допустимо иногда терять точки данных
две модели для сбора, push & pull, однозначно лучшей нет, у каждной свои плюсы/минусы, всё зависит от ситуации и иногда нужно реализовать обе
pull: коллектор метрик обходит каждый узел и собирает метрики с каждого (например каждый узел реализует /metrics хттп ендпойнт)
push: каждый узел сам самостоятельно высылает метрики коллектору (на каждом узле работает агент сбора метрик отдельно от приложения)
маштабирование трансмиссии метрик в систему:
между коллектором и БД авторы предлагают вставить Кафку - будет служить как буфер между сборкой и хранением и позволит подгружать данные более равномерно + потребители очереди смогут обработать метрики перед записью
алсо даунтайм БД не прекратит сбор метрик - они могут хранится в кафке несколько дней
админить кафку лютейший гемор - если интервьюер возбухнёт, то есть (менее надёжные но проще) альтернативы для этого специфичного кейса
несколько нюансов с БД:
- огромное количество хранимых метрик, упомянуть компрессию и даунсемплинг (переход от секунд к минутам, потом к часам)
- старые данные переводить в холодное хранилище
сервис запросов:
апишка перед базой чтоб не привязывать алерты и визуализацию к конкретной базе
сюда можно добавить кеш
алерты:
сервис алертов будет периодически посылать запросы в бд и поднимать тревогу если найдёт аномальность
визуализация:
готовый сервис типа графаны
эликсир это функциональный яп с сильной динамической типизацией исполняющийся на виртуальной машине Эрланга - BEAM
сильные стороны эрланга проявляются при программировании распределённых систем/серверов, тут это говно мамонта даёт за щеку всем, от джявы/крестов и goвна до ноды и питухона
киллер фича имхо в том что эрланг программа может быть распределена на несколько серверов и внутренние процессы могут общатся между собой как будто они на одном узле
эту программу можно алсо заапдейтить без даунтайма, процессы можно скейлить/авто рестартить - короче как кубер но только на уровне кода, это пиздос как круто
есть алсо продвинутая система макросов как в лиспе (в книге правда макросы детально не рассматриваются)
теперь о неприятных моментах в синтаксисе:
- злоебучие do ... end как в раби. ладно хоть вскод их сам вставляет
- и плагин в вскоде так себе
- неправильные скобки для кортежей - { ... }
- pipe |> оператор подтавляет значение в первый аргумент - нужно в последний, так во всех других яп
- перед вызовом лямбд нужно ставить точку - нахуя? f = fn x -> ... end; f.(x)
- рад был увидеть мой любимый оператор ===
да так и есть, учу чисто для себя - работу на нём вряд ли получится найти
где-то может одна-две вакансии (с упоминанием эликсира) в неделю в моих ебенях, но думаю возможностей намного больше если нетворкаться с другими эликсирщиками
обычно экзотика внедряется залётными рокстар-10х-девелоперами которые быстро напедаливают многие тысячи строк после чего съёбывают (такие люди долго на поддержке не сидят - нужно осваивать новые высоты) и кабан судорожно пытается найти замену с хоть какими-то знаниями
в третей главе было о паттерн матчинге, условных операторах, рекурсии, Enum/Stream модулях, и компрехеншонах
алсо продолжаю блевать от синтаксиса
в четвёртой о модулях и иммутабельности, страктах, протоколах
всё отлично, но синтаксис просто отвратительный. ладно это мелочь, ебашим
в пятой начинается многопоточность - после прочтения начну пилить небольшой пет
узнал про spawn, receive/after и очередь сообщений, send, self()
простые сервера на явной хвостовой рекурсии (без GenServer) и интерфейсы к ним через модули
узнал немного про устройство процессов в ВЕАМ (виртуальная машина эрланга)
- отношение между ОСовскими потоками и процессами ВЕАМ
- последовательность выполнения процесса
- неограниченный размер очередей сообщений и несколько советов как не обосраться с утечками памяти
- алсо сообщения между процессами всегда подлежат глубокому копированию
- ~2000 редукций между переключениями процессов шедулером. саспенды на IO, receive
- нормальное асинхронное IO, и без размазанной по всей репе async/await-дрисни
- отдельные потоки для IO и флажки для неблокирующего IO на ОС уровне
в следующих главах идёт углубление в тему многопоточности, в 6й про GenServer - абстракцию для процессов-серверов
ща пока поставлю чтение на паузу и запилю небольшой пет на элике
потом если будет настроение - продолжим эту книжку или вернусь к сисдизайну
ушла прорва усилий ток чтоб соединить 2 с половиной объекта, кек
начинаю понимать весь этот акцент на сообщения а не на данные, мол эликсир/эрланг единственная тру ООП платформа
писать пиздос как неудобно, но я буду превозмогать как и положену настоящему дырачеру
некст задачи:
- добавить простое файловое хранилище
- запилить хранение вопросов (например софтскилс >>32263) по категориям
- запилить отвечание на вопросы через сонсолечку
- добавил файловое хранилище
- добавил создание категорий вопросов
сегодня не густо, но всё что сделал - всё моё
мне надо ограничить кододроч на час-полтора в день по будням, может до 2-3х часов по выходным
сначала почитал 6-ю главу - там рассказывалось о GenServer - абстракция упрощающая написание эрланг процессов
потом сделал свою простую версию GenServer-a и зарефакторил вчерашний код - стало чуть проще ориентироваться, по сути мы просто перебираем все состояния в которых может пребывать юзер и диспатчим соответствующие сообщения
щас пока не знаю чо делать дальше, или ещё поковырять элик или пойти дочитывать книжку по сисдизайну
задача:
спроектируйте систему агрегации рекламных кликов
в начале главы немного объясняется аукцион цифровой рекламы, заказчики и "паблишеры" делают ставки и система пытается их удовлетворить
нашей задаче весь аукцион не нужен, нам только интересны сами события нажатия на рекламу и последующая их обработка
функциональные требования:
- агрегирование статистики по айдишке рекламы за последние М минут
- возврат топ 100 реклам за каждую минуту
- фильтрация по разным аттрибутам
- гугл скейл
нефункциональные требования:
- корректность данных крайне важна, поскольку они используютя для биллинга заказчиков
- правильно обходиться с дубликатами событий
- задержка несколько минут топ
- 10000 RPS, и 50000 RPS в час пик, 2 миллиона разных реклам
апишка:
GET /v1/ads/{:ad_id}/aggregated_count
аггрегированная статистика рекламы по айдишке
параметры - интервал времени + фильтры
GET /v1/ads/popupar_ads
топ N реклам за последние М минут
параметры - N, M, фильтры
модель данных:
у нас две модели - сырые клики и агрегированная инфа
сырые клики хранятся как есть - айдишка рекламы и юзера, время, айпи, страна, и тд
в агрегации 3 (4) поля - айди рекламы, минута, кол-во кликов за эту минуту, и фильтр
авторами ставится вопрос, хранить ли только сырые данные, или только агрегацию. у каждого подхода свои плюсы/минусы
рекомендуется всё-таки хранить всё сразу, сырые в качестве бекапа (в холодном хранилище) и агрегацию (для скорости запросов)
это применимо и для общего случая в похожих вопросах
сервис агрегации:
авторы рекомендуют MapReduce
клик евентов дохуя, поэтому они шардятся по map-узлам частично агрегируются, полу-обработанные данные потом идут к reduce-узлам для финальной агрегации
агрегации отправляются в базу и готовы для запросов, показаны примеры для сумм и для топ-х рекламок
схема достаточно простая и скучная, поэтому ебаться в пейнте не буду
задача:
спроектируйте систему агрегации рекламных кликов
в начале главы немного объясняется аукцион цифровой рекламы, заказчики и "паблишеры" делают ставки и система пытается их удовлетворить
нашей задаче весь аукцион не нужен, нам только интересны сами события нажатия на рекламу и последующая их обработка
функциональные требования:
- агрегирование статистики по айдишке рекламы за последние М минут
- возврат топ 100 реклам за каждую минуту
- фильтрация по разным аттрибутам
- гугл скейл
нефункциональные требования:
- корректность данных крайне важна, поскольку они используютя для биллинга заказчиков
- правильно обходиться с дубликатами событий
- задержка несколько минут топ
- 10000 RPS, и 50000 RPS в час пик, 2 миллиона разных реклам
апишка:
GET /v1/ads/{:ad_id}/aggregated_count
аггрегированная статистика рекламы по айдишке
параметры - интервал времени + фильтры
GET /v1/ads/popupar_ads
топ N реклам за последние М минут
параметры - N, M, фильтры
модель данных:
у нас две модели - сырые клики и агрегированная инфа
сырые клики хранятся как есть - айдишка рекламы и юзера, время, айпи, страна, и тд
в агрегации 3 (4) поля - айди рекламы, минута, кол-во кликов за эту минуту, и фильтр
авторами ставится вопрос, хранить ли только сырые данные, или только агрегацию. у каждого подхода свои плюсы/минусы
рекомендуется всё-таки хранить всё сразу, сырые в качестве бекапа (в холодном хранилище) и агрегацию (для скорости запросов)
это применимо и для общего случая в похожих вопросах
сервис агрегации:
авторы рекомендуют MapReduce
клик евентов дохуя, поэтому они шардятся по map-узлам частично агрегируются, полу-обработанные данные потом идут к reduce-узлам для финальной агрегации
агрегации отправляются в базу и готовы для запросов, показаны примеры для сумм и для топ-х рекламок
схема достаточно простая и скучная, поэтому ебаться в пейнте не буду
начал отвечать на вопросы, записываю ответы в обычном файлике кек - эликовый вопросник в пролёте
ответил на первые пять, 5/45 значит. заняло 40 минут
оказывается у меня есть довольно много неплохих историй из профессионального опыта с небольшими преувеличениями все врут, мне поебать
обязательно постараюсь ответить на большинство остальных, софт скиллс подготовка всегда недооценена.
соотношение выхлоп/потраченное время тут оче велико, и в будущих интервью эта подготовка оч сильно выстрелит при минимуме усилий
по сисдизайну надо скорее дрочитать 7ю главу, там совсем типовая задача которая часто задаётся
потом ещё последние 3 главы интересны - про платёжки. после 7й сделаю перерыв надоел сисдизайн, и потом прикончу их
алсо, пересмотрев инфу которую мне шлёт Zalupka-App, я решил найти и закрыть свои пробелы в ноде
нода мой основной рабочий инструмент и таки есть смысл проапгрейдить свои знания, чем бросаться в экзотику типа эликсира
пока такие планы
сидишь пыхтишь учишься, строишь планы, пока всякое быдло просто получает подачку и ништяки от правительства за мои налоги, очень припекательно
>>32263
15/45
24/45
Существо продуманное,
До женитьбы обещала,
После передумала...
перечитываю пикрелейтед
наговнякал пример CancellationToken-a для отмены продолжительных асинхронных действий
мне казалось эта залупа уже есть в стандартной либе, но нет - авторами предлагается костылять велосипедный враппер
более интересный пример был бы для нормального хттп-сервиса, это получается мы держим пул токенов, по одному для каждого запроса
клиент тогда должен делать отдельный запрос для отмены с айдишкой токена
сложности возникнут если меняется состояние - тогда ещё придётся реализовывать откат
короче сомнительный паттерн
Ебать ты гостеприимный. Такие ЧСВ-уёбки надолго в IT не задерживаются, удачи, петушила.
на самом деле около 40, несколько вопросов повторялись + пару скипнул
в общем заебись упражнение и мало времени занимает - позже найду ещё другой списочек и так же подзадрочусь
пока листаю >>36021, отдыхаю, не напрягаюсь
потом закину пару экспериментательных залупок на ноде + надо наконец-то прорешать 7ю главу сисдизаня
закончил про память
сегодня посмотрю про асинхронное И/О и может полистаю главу о распределённых системах/сетях
очень чешутся руки начать какой нибудь пет проектик, но интересных мне идей пока никаких
может стоит прошуршать программерские доски тут и на форче для вдохновления используя свой двачепоисковик-тг-бот
может даже об реддит зашкварится
хочу что нибудь более-менее полезное для себя + интересное в реализации
мммммм.....
592x1280, 0:31
дочитал книгу
ничего особого нового в АИО главе небыло, так чисто мелкие детали select/poll
в целом неплохой повтор давно забытого университетского курса по операционным системам, рад что он не занял слишком много времени
на будущее читать надо как можно меньше, книжки скучны, занимают много времени, быстро забываются и редко оправдывают ожидания
на этих выходных вряд-ли будет время на занятия к сожалению
но пока некст планы таковы:
- несколько мини-залупок на ноде, стримы, процес-воркеры, может чо ещё. восполняю пробелы.
- добавить в >>09393 цены на хрючево. буду отслеживать как тают мои валютные накопления
- может наконец домучить 7ю главу сисдиза
- найти интересную идейку для некст пета
читал https://nodejs.org/en/docs/guides/dont-block-the-event-loop/
смотрел https://www.youtube.com/watch?v=P9csgxBgaZ8
детальные объяснения что проиходит внутри libuv
намного лучше понимаю кишки ноды
щас пол часика поколупаю потоки
ребёнок-процесс есть отдельный процесс узла. основной процесс и ребёнок-процесс общаются по специальной межпроцессной трубе
работник-нить и основная нить тоже общаются по трубе. у них нет общей памяти, по сути работник-нить это тоже целый узел со своим личным циклом событий
но тем не менее работник-нить и основная нить существуют в одном процессе
работник-нить - более новый способ распределять заставляющую работу, дети-процессы обходятся слишком дорого
Как происходит процесс термоядерного сгорания углерода в гелии знаешь?
требования вкратце:
- трекинг цен на корзину товаров и услуг
- корзина настраивается юзером - ссылки + хтмл
- история цен сохраняется, можно посмотреть дельту за разные периоды
- оповещения когда цены меняются
- опционально: подрыв срачла из-за тающих от инфляции накоплений
писать будем на тайпскрипте + нода
к сожалению придётся брать поганый puppeteer - оче многие онлайн магазины требуют работающий жс
насчёт деплоя, папитир тащит 300МБ зависимостей, поэтому лямбда в пролёте
может взять ес2 или просто запускать с личного компа БАТНИКОМ/scheduled task
демон-краты то думали, что отменив легализацию аборта голоса женщин будут у них в кармане навсегда
но бабам не до абортов когда нет денег на пожрат. its the economy stupid
больше половины покупателей - женщины и они первыми замечают инфляцию на своей шкуре, и уже внезапно не до фемвойн с "патриархией"
сам редко смотрю на цены, кек. каждый раз охуеваю. поэтму и хочу пет на тему
https://www.zerohedge.com/political/fickle-white-suburban-women-running-back-gops-arms
пилю
к сожалению папитир приходится запускать в хед-фул режиме и смотреть как он запускается, загружает страницы и переключается между вкладками
путешевствовать по конференциям, защищать её от патриархальных хуемразей и обсуждать реализацию MongoDB укутавшись в тёплый пледик
ммммммрмрмрммрррррррррр... 🤤🤤🤤🤤🤤
немного "рефакторил" без тестов
потом добавил файловое лень пердолить бд хранилище - мы же хотим всю историю хранить
пока вижу два основных юзкейса:
- периодическая подгрузка данных из магазинов и хранение в файлике
- подгрузка данных из файлика в любой момент, анализ и красивый вывод в сонсольке/браузере
использую охуенский модуль chalk (https://www.npmjs.com/package/chalk)
к слову, в путихоне такой удобной либы нет, для >>30328 в итоге пришлось самому пердолится с кодами цветов
примитивная одержимость есть чрезмерное использование элементарных типов для моделирования нашей ситуации
примеры:
- использование элементарного типа string для моделирования адресов электронной почты
- использование элементарного типа boolean для моделирования гендера в 2022 тут и вещественных чисел не хватит, кек
- использование элементарного типа number для моделирования денег
код можно улучшить заменив примитивы на специализированные типы/классы содержащие логику работы с этими значениями
сегодня для упражнения отрефакторил деньги - щас всё форматирование, типы валют и вычисления живут в одном месте упростив вызывающий код
охуенно же блядь
>Error("Dengi davai")
Говняк же. Почему было в тексте ошибки не написать, что именно не смогло распарсить?
доделал пет
сегодня заканчивал анализ инфляции + тесты
в заключении у нас 3 действия:
- с папитиром сдираем цены на продукты, добавляем их в конец файла
- анализатор высасывает поток из файла, выплёвывает результат в другой файл
- показываем результат в красивой табличке в консолечке (>>38472)
для теоретической веб версии можно легко генерировать хтмл файл вместо таблицы