Pull to refresh
47
-0.8
Сергей @onegreyonewhite

Специалист

Send message

Именно так. Только надо допилить ручками некоторые вещи, чтобы работало как надо. В интернете полно мануалов. Я хотел статью написать, но руки не доходят. Там очень много нюансов надо объяснять.

Это про конфигурацию или код писать надо?

Да. Там нужно для больших запросов кое-что подправить в конфиге и для автоматического анализа пару-тройку функций написать.

Когда требования постоянно меняются комплексно (т.е. "нам нужен белый автомобиль" поменялось на "нам нужно рыть землю") это смена задачи, а не направления. Здесь скорее gitflow нужен, чтоб спокойно оставить наработки и пойти в другую задачу.

А если в задаче уточнились детали, то тесты вперёд обычно выигрывают, потому что сразу всплывают все места, где нужно внести изменения, при этом не нужно искать что сломалось - оно всё вылазит на поверхность. Более того, при реализации тестов, быстрее возникают вопросы к задаче для уточнения, особенно если задача комплексная. Например, какие заголовки использовать, требования к протоколу передачи данных, формат полей и т.п.

Единственное место, где не нужно и вредно TDD - вёрстка.

Для постгреса есть расширение, которое если немного допилить, то можно собирать даже автоматически запросы и даже explain по ним всем сделать и записать в готовую табличку. Даже эффективнее порой, чем методом пристального взгляда собирать статистику по данным и запросам. Я просто запускал в docker-compose окружение, прогонял тестовые сценарии, потом смотрел табличку с сортировкой по проблемным запросам (время выполнения и наличие seq scan).

TDD в значительной степени подразумевает, что вы должны знать, как ведет себя система, еще до ее реализации. Вы должны знать, что вы делаете.

В большинстве случаев вы этого не знаете. Все разработчики, которых я знаю, не знают этого заранее. Я не знаю этого заранее.

Ужас. Я не хотел бы переходить на личности, но это прям даже звучит дико. Если вы не знаете что пишите, то как пишите? Методом научно-ненаучного тыка? По вдохновению правой пятки? Возможно с таким подходом TDD и правда мешать будет. Возможно проблема не в методологии.

Смысл написания тестов до кода, что тесты проверяют функциональность, которая требуется. Если нет требований, то что конечно тесты не написать. Но говорить о вреде TDD просто потому что у вас процессы... ну мягко скажем не очень, как минимум глупо.

Внуки, видимо, в steam не умеют, раз шугаются. Или привыкли пиратить, откуда и проблемы были.

Когда в семье, кроме жены, трое детей, то, благодаря distcc, можно компилировать почти на сотне потоков. Хотя возмущения ребенка о просадке FPS могут потребовать некоторых компромиссов )

А я думал, что это я псих, когда маму на Kubuntu перетащил. Но есть и попсихованнее.

новичку которому нужен линукс лучше начинать с минта

Нее, ну это скучно. Если глаза не красные от того, что неделю пытаешься собрать ядро так, чтобы запустить какую-нибудь экзотическую звуковуху, а домашние, соседи, коллеги и парочка суперкомпьютеров не написали вам гневное письмо, что не надо использовать их ресурсы для того, чтобы пересобрать "мир" с новымы USE-флагами для 1% оптимизации работы, то не уверен, что это вообще линуксовый опыт. Попса какая-то и виндузятничество.

P.S.: Это лютый сарказм, если что, и океан самоиронии про студенческие годы.

Вы мне анекдот напомнили про студента, который выучил материал только про блох.

Сам анекдот

Студент сдает зоологию. Знает только про блох. На экзамене
достается вопрос про собак. Судент начинает:
- Собаки это млекопитающие, покрыты шерстью. В шерсти водятся блохи...
дальше все про блох....
Препод:
- Ладно молодой человек, расскажите про кошек Студент:
- Кошки это млекопитающие, покрыты шерстью. В шерсти водятся блохи...
дальше все про блох....
Препод:
- Давайте-ка про рыб Студент:
- Рыбы это не млекопитающие. Шерстью не покрыты. Покрыты чешуей, но если
бы они были покрыты шерстью, то в ней бы водились блохи....

У вас уже есть одна сеть. Она вполне может заниматься поиском закономерностей. Только хранить варианты решений ей не нужно, она может взять это из долговременной памяти. Понятно, что обработка будет не за один раунд, но это эффективнее, чем содержать сразу две сети. Возможно у вас, конечно же, есть целая система размышлений на этот счёт, которые вы не смогли выразить в статье, но пока что лично для меня вторая сеть выглядит избыточной, просто для того, чтобы хранить какие-то протокольные данные.

Я не перепутал, просто вы не поняли, что я имел ввиду.

Чтобы написать программу, которая умеет отличать гору, нам необходимо запомнить все возможные изображения

Вы в долговременной памяти что хранить-то собрались? Долговременная память хранит набор готовых фактов или... решений. При этом наш мозг устроен так, что мы зачастую имеем свойство брать решения и адаптировать их под слегка изменённые факты. А что вы собрались хранить, я так и не понял ни из статьи, ни из ваших объяснений.

У нас шаблонное мышление, за счёт этого мы не храним петабайты, а только очень короткие данные о фактах и способах решения, а сознание дорисовывает по ним уже всю остальную логику. Т.е. мы не храним абсолютно все ответы на все вопросы. Мы храним принципы, которыми разные задачи решаются. А уже от обстоятельств, мы принимаем решение какой принцип подтянуть и как его натянуть на задачу. Это и делает человека профессионалом или умным, а не "зубрилой".

Собственно, почему я и удивился, что вы так переусложнили. Принцип хранить проще и быстрее, а поиск подходящего принципа может делать и сама сеть (одна единственная). Даже оптимизацию можно применить, сортируя долговременные данные по частоте обращений.

Почему мы используем нейронные сети, а не просто запоминаем огромные выборки?

Так вы задачи перепутали. Процесс поиска в долговременной памяти основан на выборе фактов из памяти, а не на анализе запроса. Поэтому вторая нейронка кажется избыточной. В принципе наша память примерно так же к фактам относиться: мы либо помним, либо нет. А уже сознание выбирает что из памяти вытащить.

На самом деле процесс вспоминания действительно может происходить и за малое количество вопросов, просто длина вектора, содержащий вопрос должна быть большой.

...

Но самым эффективным способом общения, как мне кажется, будет являться передачей неопределенного количества векторов скрытого состояния за одно обращение к сети-памяти - модели обработки последовательностей способны генерировать последовательности такой длины, которая им будет необходима.

Ну вы описали сейчас классический bulk-запрос. По факту это экономит часть ресурсов, но всё равно фактически будет много запросов в одном или двух. Это можно делать и в обычных хранилищах. Там и с разными весами можно работать и много с чем. Так что обучать под это сеть кажется каким-то удалением гланд ректально автогеном.

Выбор дистра конечно впечатляет... Надо было Gentoo, чтоб прям сразу deep dive. Самое то для новичка (нет!).

Ощущение, что в данном случае вторая сеть (память) выглядит оверхедной. С учётом того, что общение будет на собственном языке, то и в качестве хранилища может быть обычный key-value с поправками на поиск и вес. Т.е. условно OpenSearch мог бы вполне быть долговременной памятью, а решение о формате и частоте запоминания может заниматься сеть сознания. Тут самое ключевое это скорость записи и поиска, потому что в процессе воспоминаний будет не условные 3-4 вопроса (вы сильно упростили в статье когнитивный процесс), а сотни 2-3, а на запись и того больше.

При этом уверен, что такой сети нужен будет "сон", чтобы переварить все полученные данные и сделать дамп в долговременную память, потому что процесс обработки и записи явно будет не быстрый. Получается для такой сети потребуется посменная работа двух независимых нейронок.

Постгрес из коробки рассчитан на запуск хоть с утюга. Есть вещи, которые всё равно надо настраивать. Три вещи:

  1. Настройте правильно huge pages для posgres. Без этого он будет очень коряво использовать память. Считайте он вам попугаев выдал при при этом не вставая с дивана. Обычно примерно 20-40% прирост. Бывает гораздо больше.

  2. Стоит задуматься о synchronous_commit. В 99% случаев сервер таких мощностей обложен резервом питания. Эта настройка влияет только на незавершенные транзакции, а на скорость работы влияет существенно. Особенно на ssd это практически безопасно.

  3. Я бы покрутил настройки fsync.

Почему же. Содержать серверную тоже непростая задача порой. Просто сейчас есть такой пласт технологий, что можно легко и не дорого поднять инфраструктуру для любых задач. И для этого не надо прям какой-то rocket science обладать - за ваши деньги любой каприз.

Я понимаю о чём вы, но это не значит, что это правильно. Именно благодаря потоку, они сливают деньги в трубу, а трудиться над оптимизацией не могут, просто потому что не умеют.

Если вам не интересен офер то непонятно зачем вообще приходить туда на собес

А так я и не хожу и даже не рассматриваю оттуда предложения. На это как бы намекает частичка "бы". Даже если "позязя" от рекрутеров слышу. Это было бы и правда контрпродуктивно.

Он может и сам бы был рад задавать открытые вопросы но их собесы жестко стандартизированы и за шаг влево шаг вправо - расстрел.

Статья говорит, что нет, не рад бы. Его вполне радует, что он придумал решение, под него задачу и может теперь узнать, насколько человек глубоко натренерован писать костыли. Стандарты не зло, как и законы. Зло рождается при применении этого со злым умыслом. В данном случае, сосредоточенность на своём чсв, а не поиске адекватных сотрудников (а задача именно такая).

С таким потоком, появляется всё больше историй, когда на работу устраиваются люди, которые вообще не умеют писать адекватный код и решения. А иногда вообще не умеют писать код, просто память хорошая. В итоге с малюсеньким микросервисом работают 10 разработчиков, вместо 3 (условно). То же касается раздутых процессов, скрамов в команде до с 3 разрабами и 4 менеджерами. Т.е. проблема не в том, что люди не принимают такой подход, а в том что очевидно, что он убогий и не особо эффективный, но менять ничего не будем, потому что "видите, мы успешные, а все лузеры". Только вот эти компании не со скрама начинали свой успех...

глубоко все равно на все эти инженерные "излишки"

Это вам в FAANG руководители разработки сказали, да? Или вы где-то слышали? Просто так, наверное, пачками разгоняли сотрудников недавно, которые зачастую по каким-то показателям не приносят прибыль, а только убытки. Хотя и там эффективные процессы помогли замесить и хороших менеджеров, и хороших разрабов.

Даже при том, что я не питаю хороших чувств к Маску и его подходу, я хорошо знаю как может сложиться бюрократическая машина, когда из 100 сотрудников, нет ни одного, кто хотя бы понимает как работает сеть, но пишут микросервисы.

Поэтому я и выразил свое мнение, насчёт процесса такого странного подхода к найму.

Я сталкивался с подобной магией, когда экспериментировал с Cython. На самом деле, если глубоко не вникать в код, память и т.д., то очень часто переписать на C это хуже. Не поймите неправильно, сам по себе C быстрее Python. Проблема в разработчиках и накладных расходах на разработку.

Поэтому надо быть крайне осторожным при реализации части функциональности на более быстрых языках, проводя тестирование на разных архитектурах, процессорах (с разными кешами и наборами инструкций), разной памятью и версиями ядер, набора библиотек и т.д.

Но у нас как обычно: "давайте перепишем на язык X и сразу ускоримся в N раз!" Кекас два. Потом запускаются в облаке, на каком-то старом Linux ядре 4.4, дешёвых энергоэффективных процессорах и скорость просто пополам ниже.

Просто потому что не умеют с ними работать ещё. Ну и профит можно получить только на ооочень больших объёмах памяти (там на уровне терабайтов).

Я не претендую на полноту ответа, но это на уровне того, что я знаю об Oracle и Postgres.

Проблема таких собесов в том, что люди покажут только как они умеют изобретать велосипеды и подпирать костылями дурные решения. Моё собеседование бы закончилось тем, что я задавал бы вопросы в духе "а нафига вы данные в файлик писали?" или "это вы постоянно так решаете (aka изобретаете) проблемы?"

Программиста надо проверять в том поле, где будет его покрытие. Если это веб-разработчик или что-то про разработку (микро-)сервисной архитектуры, то лучше спросить про сеть или HTTP, про алгоритмы сжатия, задержки или хорошо по SQL прогнать (там задачек по дискретной математике хватит на полжизни).

Случай из жизни

Был у кореша в офисе, когда он не мог решить одну прикладную задачку с задержками и нужно было переделать архитектуру. Он заодно попросил поучаствовать в собесе нового фронтендера.

Сижу, значит, слушаю их (кореш, их тимлид из фронтендеров, hr'очка). А вопросы, значит, про алгоритмы, про матанализ, про протоколы, про SQL, про Linux... Я тихонько скидываю сообщение другу: "а чё, у вас часто фротендеры этим занимаются? Они же вроде у вас формочки почти всё время клепают. Спроси про вёрстку парня!" Буквально кореш получил сообщение, собеседуемый выдаёт: "Слушайте, а у вас фротендеры часто с этим работают? Чем вообще я буду здесь заниматься?" Мы вдвоём складываемся пополам от громкого хохота в голос, после чего кореш поворачивается к hr'очке и со слезами на глазах: "оформляй!"

Кстати, этот парень там быстро поднялся и оказался очень толковым. Хотя про SQL, линукс и алгоритмы довольно слабо отвечал.

Если человека в команду берут не на позицию разработки движка чего-то там с нуля, то зачастую стоит проверять на знание фреймворков и библиотек. Если хотите проверить сеньористость, то проверьте глубокие знания языка. При этом убедитесь, что сами знаете матчасть (а то такой цирк с конями был в жизни, что даже вспоминать страшно).

Лучший способ дать комплексное творческое тестовое, а потом на встрече его обсудить, если оно в целом стоит обсуждения. Но это задание должно быть:

  • приближенным к актуальным задачам

  • сделано в комфортном для кандидата режиме (но в рамках общего окна)

  • не делать его под присмотром (пусть дома сядет и спокойно сделает)

  • вылажено в портфолио на Github/Gitlab в открытом виде (помощь человеку с портфолио).

При этом уважительно надо общаться с обеих сторон. Дерзкие дегенераты с обеих сторон раздражают и вызывают глубокое отвращение в будущем к компании. После общения обе стороны должны получить профит в виде опыта и приятные воспоминания. Почему? Да потому что это networking, а земля круглая. Если в вакансии ни слова про алгоритмы, то и не проверяйте это. Проверьте именно то, что ищите.

Именно поэтому, сколько помню найм к себе, то люди потом уходили ещё более вдохновлённые, чем приходили. Даже после отказа, многие были мотивированы на рост и уверен нашли хорошее место, где применили свои навыки.

Молодец, что написали с картинками. Я поленился в своё время.

Хочу сразу уточнить:

Далее в пункте «Прокси» выбираем параметр «Вручную».

Такой механиз завернёт не весь трафик через прокси. Я в статье специально уточнял про tun2socks, потому что это реально единственный способ завернуть весь трафик с любого приложения в Android (для iOS тоже работает). Обычно, разработчики приложений достаточно серьёзных приложений, стараются отключать такую возможность на уровне манифеста. Во всяком случае все тестрируемые мной имели такую особенность.

Ещё хочу уточнить про сертификат. Многие приложения под Android начиная с 7.0 могут иметь флаг на недоверие пользовательским сертификатам. В этом случае только через root-доступ можно что-то сделать, чтоб ловить трафик. А если root-есть, то можно вообще любое приложение завернуть в прокси и смотреть.

Если прокси позволяет, то можно смотреть даже неHTTP-трафик. Чарли умеет это дело, хотя с оговорками.

Интересные задачи заканчиваются только в кровавом энтерпрайзе. Что бы ни была за компания, новые вызовы появляются каждый день. Новые и новые технологии появляются, которые можно применять и даже не в ущерб, а с пользой для бизнеса. Поэтому в масштабе 10 лет адекватному сотруднику будет чему учиться. Потом да, уже наступает условная старость, когда хочется денег и лежать у бассейна.

Но за год или два ещё ни один не осеньорился.

Information

Rating
Does not participate
Location
Sacramento, California, США
Date of birth
Registered
Activity