Для финального работодателя ето похер, хоть 30 лет лежал на печи, лишь бы по навыкам подходил и все закрывал что требуется в срок.
Но вот у рекрутеров есть целый карго-культ и в "серьезную компанию" резюме даже не будут рассматривать без определенных "моментов".
Это известная проблема и известное решение (напиздеть). Хотя проблема известна скорее спецам которые долго просидели в одной компании, а потом по какой то причине начали искать работу (не однократно слышал историю от толковых спецов, что выкинул резюме и ноль откликов, а все потому что резюме "не кошерное")
И самое веселое в этом всем что рекрутеры "упрощая" себе жизнь ведут всевозможные базы, потому велика вероятность если ваше "неправильное" резюме проскипали, то когда вы его исправите то его уже будут "скипать" автоматически. (Опять таки известная проблема и известное решение - меняйте контактные данные и ФИО пишите символами разной раскладки что бы визуально было идентично но не по hash-сумме)
Предложить нормальную альтернативу хранения персональных данных? (Аналог локалсторидж но зашифрованое составным ключом браузера и сервера раз уже все давно на https)
Нет! Мы будем ставить палки в колеса всем, что бы покупали у нас "правильные" решения
.
На сейчас безумно бесят эти постоянно вылазящие окна про "мы используем куки" которые нужно подтверждать каждые три месяца.
С этим же нововведением будут еще вылазить что то что позволит следить за пользователем для продолжения таргентиговой рекламы. 150% это будет какое то локальное решение именно на стороне браузера. Никогда не поверю что мегакорпорации зарежут такую корову как таргет, скорее как раз все только для того что бы не давать "чужим коровам" пастись в их браузере
Если не хотите что бы угнали - делайте на ПЛИС блокируемых и то при желании и это скопируют.
Как по мне с железом как раз нужен единый открытый реестр всех решений, что бы не изобретать велосипед, а сначала посмотреть что есть. А то ситуация как с научными работами - абсолютно ничего закрытого но "запрещено"
Понятное дело что есть сегмент безопасности но пять таки там безопасность реализуется комплексно, а "засекречивание" отдельных узлов явный намек на шизофрению
Я на практике сталкивался с краевыми условиями chatGPT так как удобно его использовать для глупых вопросов которые дольше гуглить будешь.
Я потом даже находил форумы на основании которых он свой ответ генерил.
Если данных по вопросу много, то он отвечает "точно". Но если мало (всего два ответа) то он дает компиляцию (хорошо если только из этих двух ответов)
ChatGPT одновременно очень ленив - он как то кеширует ответы что бы много раз один и тот же запрос не делать но при этом как школьник которому дали задачу написать расказ на две страницы о падаюшем листике (если есть данные то нет проблем, но если нет данных...)
То то все "беспроводные" подводные аппараты строят связь вокруг аккустических систем.
Ну тупые! Не знают что можно синим светом сразу передавать данные!
.
За космос вообше без коментариев - давать космонавтам ик-порт ностальгично но не практично (а на большие растояния ты попади да распознай что это четко тебе а не солнце моргнуло)
То что крышки стали меньше и более неудобные - факт
А за саму пластиковую тару - я обычно пластиковые бутылки распускаю на нитку что бы зарядить в принтер (болт с прорезью и норм в ексктрудер плоское лезет) и вот за последние 5 лет бутылка колы становилась тоньше дважды (с принтером это отследить легко)
Маск опять хайп использует как оружие в своих целях. Да, он бизнесмен и может позволить, но все чаще это начинает походить на притчу "волки, волки"
Тут именно что мелкомягкие вложились, им отдельно дали продукт и наработали свой "открытый"
OpenAI дохрелион денег тратит на то что ты любой вася мог сейчас бесплатно спросить за шмот у chatGPT. Открыто? Открыто. Перевернуло ли это мир? Уже перевернуло.
То что у них есть закрытая gpt4 такое себе так как конкуренты дышат в спину (а не глотают пыль)
.
Как писали ниже - все о чем договаривались OpenAI выполнило и продолжает выполнять.
А Маск опять и снова делает громкий вброс что бы на его базе "качать" ситуацию в свою пользу (он такой в белом, а все козлы)
С собесами очень по разному, а вот за работу в команде 1005000 плюсов
Классика с "срочно, срочно, на вчера" с заебами каждый час, а потом настолько срочно что за месяц могут даже не дойти до него посмотреть что сделали
А за собесы - 80% хороших кандидатов отсекаются на этапе рекрутера. Очень редко можно найти адекватного рекрутера который умеет подбирать людей. Зачастую у них там своя атмосфера с очень странными "мыслями". Не раз был опыт когда на работе не могли найти кандидата месяцами, но стоило самому сесть и просто перебрать первый десяток откликов как сразу находились как минимум парспективные
Как незаметно Макс трансформировался с продажника на передовой технического развития, в очередного шизофреника с ресурсами...
Грустно. Хотя может так было всегда, просто незаметно ранее особо.
Понятно что что Макс поймал несколько раз успех на волнах информационного шторма, но строить теперь на этом всю свою программу развития такое себе. Ведь явно 'судебное разбирательство' сдлеано максимально громким. Так же можно и к Максу притеезию кинуть что его автомобили не открытой архитектуры, а его ракеты и вовсе залиценнзированы в край - а ведь может быть каждый школьник хочет собирать старшипы дома в деревне
Поток сознания далек от осмысленности, но что вы имели в виду я понял.
Для того и нужна декомпозиция что бы не работать с большими данными одним куском
Если же вы за то что в go размерность обычно в int возращается а не в uint из за чего можно провафлится с реально большими данными - сушествует uintptr и множество способов работы с большими данными в go
Вы не можете нормально валидировать блок, пока не распарсите его. В общем, если вы захотите сделать валидатор жсона, у вас получится парсер. Впрочем, вы и границы блока не сможете нормально определить по этой же причине.
Неа
Как раз для больших и кривых данных именно так как я написал
Сначала выделяется блок. Логика простая - читаем из файла в буфер, пока буфер не станет определенного размера. Самое главное обрезать буфер там где количество открывающих/закрывающих кавычек и скобок вышло в ноль (например инкремент на [, декримент на ])
Потом мы валидируем этот блок. Еще не парсим, но валидируем так как отсечение по нулевой сумме закрытия хоть и быстрый процесс, но очень не точный. Теперь четко определяем начало json-переменной и проверяем что бы было закрытие. Если закрытие уперлось в конец буфера, то подставляем закрывающий нужный символ
И когда у нас есть фрагмент файла из которого получили валидный json - только тогда уже стандартными средствами заряжаем его в парсер json
.
Если сразу пихать фрагмет в парсер а потом отталкиватся от обработки ексепшенов, то на порядок больше времени и ресурсов потратится потому как парсеры разбирают все дерево и только в случае неудачи выбивают панику или ексепшен
В 90% случаев это простой массив обьектов (логи или отчеты)
И оно спокойно читается построчно
Но даже если все "по красоте" с отступами и переносами и сам документ не просто листинг однотипных обьектов, то все равно читаешь построчно но уже до определенного обьема с расчетом что бы закрылась ветка максимально (простая математика скобочек и кавычек с двоеточиями)
.
Я не знаю задачи где бы понадобилось выгрузить все 300гб данных в память одним обьектом
И как всегда свидетели jqwery любят притягивать крайние случаи
Для первого случая хватит самого обычного js вот так:
<button onclick="setClass(this, 'bg-green')">
Click Me
</button>
Где весь функционал будет в отдельном методе и в случае чего так же с одного места патчатся краевые условия.
.
Второй случай для ситуаций обработки сценариев, зачастую это все собирается конструктором и для кучи разных елементов. В коде выглядит как инициализация метода класса.
И даже если писать ручками - один хрен такой формат записи подходит больше именно для централизованой обработки всех событий
.
А теперь подходим к моему самому "любимому"
Свидетели jqwery - они записи формата $('results-pane').* раскидывают как обезьяна какашки.
Ладно 10+ лнт назад это было проще изяшнее чем то что позволял движок js на тот момент, но на сейчас старые костыли стали фичей говностроения.
Да - любым средсвом нужно уметь пользоватся, но как раз именно поддержка упрощенного синтаиса через $ очень сильо понижает требования к коду
.
Из жизни - если большой проект который лепили и дополняли хотя-бы пару лет при использовании jqwery, то добавление критично нового функционала зачастую вылазит в переписывание всей страницы.
Потому что можно "по быстрому" насыпать $ и не переживать так как внутрение конфликты jqwery разрешает сам. Быстро и удобно - самое то для разработки. А поддержка и расширение - ну это сложная задача, требуюшая много трудозатрат
.
Может мое мнение субьективное - я с фронт-ендерами просто плотно работаю, но я никогда не встречал решений на jqwery в ситуациях с "нормально делай - нормально будет"
А за гугл соглашусь - он уже лет 10 не торт, а его ресурсы не проходят его же тесты что он выкладывает в открытый доступ)
Оо, это парадокс рекрутинга)
Для финального работодателя ето похер, хоть 30 лет лежал на печи, лишь бы по навыкам подходил и все закрывал что требуется в срок.
Но вот у рекрутеров есть целый карго-культ и в "серьезную компанию" резюме даже не будут рассматривать без определенных "моментов".
Это известная проблема и известное решение (напиздеть). Хотя проблема известна скорее спецам которые долго просидели в одной компании, а потом по какой то причине начали искать работу (не однократно слышал историю от толковых спецов, что выкинул резюме и ноль откликов, а все потому что резюме "не кошерное")
И самое веселое в этом всем что рекрутеры "упрощая" себе жизнь ведут всевозможные базы, потому велика вероятность если ваше "неправильное" резюме проскипали, то когда вы его исправите то его уже будут "скипать" автоматически. (Опять таки известная проблема и известное решение - меняйте контактные данные и ФИО пишите символами разной раскладки что бы визуально было идентично но не по hash-сумме)
Предложить нормальную альтернативу хранения персональных данных? (Аналог локалсторидж но зашифрованое составным ключом браузера и сервера раз уже все давно на https)
Нет! Мы будем ставить палки в колеса всем, что бы покупали у нас "правильные" решения
.
На сейчас безумно бесят эти постоянно вылазящие окна про "мы используем куки" которые нужно подтверждать каждые три месяца.
С этим же нововведением будут еще вылазить что то что позволит следить за пользователем для продолжения таргентиговой рекламы. 150% это будет какое то локальное решение именно на стороне браузера. Никогда не поверю что мегакорпорации зарежут такую корову как таргет, скорее как раз все только для того что бы не давать "чужим коровам" пастись в их браузере
Если не хотите что бы угнали - делайте на ПЛИС блокируемых и то при желании и это скопируют.
Как по мне с железом как раз нужен единый открытый реестр всех решений, что бы не изобретать велосипед, а сначала посмотреть что есть. А то ситуация как с научными работами - абсолютно ничего закрытого но "запрещено"
Понятное дело что есть сегмент безопасности но пять таки там безопасность реализуется комплексно, а "засекречивание" отдельных узлов явный намек на шизофрению
Я на практике сталкивался с краевыми условиями chatGPT так как удобно его использовать для глупых вопросов которые дольше гуглить будешь.
Я потом даже находил форумы на основании которых он свой ответ генерил.
Если данных по вопросу много, то он отвечает "точно". Но если мало (всего два ответа) то он дает компиляцию (хорошо если только из этих двух ответов)
ChatGPT одновременно очень ленив - он как то кеширует ответы что бы много раз один и тот же запрос не делать но при этом как школьник которому дали задачу написать расказ на две страницы о падаюшем листике (если есть данные то нет проблем, но если нет данных...)
То то все "беспроводные" подводные аппараты строят связь вокруг аккустических систем.
Ну тупые! Не знают что можно синим светом сразу передавать данные!
.
За космос вообше без коментариев - давать космонавтам ик-порт ностальгично но не практично (а на большие растояния ты попади да распознай что это четко тебе а не солнце моргнуло)
А потом три часа бесплотных попыток найти то что она нафантазировала)
Если узкая тема то chatGPT работает только с тем что знает и как умеет.
То есть если по запрошеному вопросу встречается ответ всего дважды, то он его найдет но отдаст не слово в слово так как это особенность нейронок
Одно дело форм-фактор, а другое дело реальность
То что крышки стали меньше и более неудобные - факт
А за саму пластиковую тару - я обычно пластиковые бутылки распускаю на нитку что бы зарядить в принтер (болт с прорезью и норм в ексктрудер плоское лезет) и вот за последние 5 лет бутылка колы становилась тоньше дважды (с принтером это отследить легко)
Не подсказывайте!
И так уже пришли к тому что пластиковые бутылки скоро будут толшиной с пакет, а горлышко бутялки закрыватся нанокрышкой милиметровой толщины
Вот я про это и написал.
Маск опять хайп использует как оружие в своих целях. Да, он бизнесмен и может позволить, но все чаще это начинает походить на притчу "волки, волки"
Тут именно что мелкомягкие вложились, им отдельно дали продукт и наработали свой "открытый"
OpenAI дохрелион денег тратит на то что ты любой вася мог сейчас бесплатно спросить за шмот у chatGPT. Открыто? Открыто. Перевернуло ли это мир? Уже перевернуло.
То что у них есть закрытая gpt4 такое себе так как конкуренты дышат в спину (а не глотают пыль)
.
Как писали ниже - все о чем договаривались OpenAI выполнило и продолжает выполнять.
А Маск опять и снова делает громкий вброс что бы на его базе "качать" ситуацию в свою пользу (он такой в белом, а все козлы)
С собесами очень по разному, а вот за работу в команде 1005000 плюсов
Классика с "срочно, срочно, на вчера" с заебами каждый час, а потом настолько срочно что за месяц могут даже не дойти до него посмотреть что сделали
А за собесы - 80% хороших кандидатов отсекаются на этапе рекрутера. Очень редко можно найти адекватного рекрутера который умеет подбирать людей. Зачастую у них там своя атмосфера с очень странными "мыслями". Не раз был опыт когда на работе не могли найти кандидата месяцами, но стоило самому сесть и просто перебрать первый десяток откликов как сразу находились как минимум парспективные
Как незаметно Макс трансформировался с продажника на передовой технического развития, в очередного шизофреника с ресурсами...
Грустно. Хотя может так было всегда, просто незаметно ранее особо.
Понятно что что Макс поймал несколько раз успех на волнах информационного шторма, но строить теперь на этом всю свою программу развития такое себе. Ведь явно 'судебное разбирательство' сдлеано максимально громким. Так же можно и к Максу притеезию кинуть что его автомобили не открытой архитектуры, а его ракеты и вовсе залиценнзированы в край - а ведь может быть каждый школьник хочет собирать старшипы дома в деревне
А с нарушением будет ссылка на gitee где то в даркнете?
Кто ты к̶л̶о̶у̶н̶ воин?
Куча коментариев потому отвечу только тут.
Поток сознания далек от осмысленности, но что вы имели в виду я понял.
Для того и нужна декомпозиция что бы не работать с большими данными одним куском
Если же вы за то что в go размерность обычно в int возращается а не в uint из за чего можно провафлится с реально большими данными - сушествует uintptr и множество способов работы с большими данными в go
Вы не можете нормально валидировать блок, пока не распарсите его. В общем, если вы захотите сделать валидатор жсона, у вас получится парсер. Впрочем, вы и границы блока не сможете нормально определить по этой же причине.Неа
Как раз для больших и кривых данных именно так как я написал
Сначала выделяется блок. Логика простая - читаем из файла в буфер, пока буфер не станет определенного размера. Самое главное обрезать буфер там где количество открывающих/закрывающих кавычек и скобок вышло в ноль (например инкремент на [, декримент на ])
Потом мы валидируем этот блок. Еще не парсим, но валидируем так как отсечение по нулевой сумме закрытия хоть и быстрый процесс, но очень не точный. Теперь четко определяем начало json-переменной и проверяем что бы было закрытие. Если закрытие уперлось в конец буфера, то подставляем закрывающий нужный символ
И когда у нас есть фрагмент файла из которого получили валидный json - только тогда уже стандартными средствами заряжаем его в парсер json
.
Если сразу пихать фрагмет в парсер а потом отталкиватся от обработки ексепшенов, то на порядок больше времени и ресурсов потратится потому как парсеры разбирают все дерево и только в случае неудачи выбивают панику или ексепшен
"На лету" json можно поймать коленом
Особенно если данные никак не формализированы и могут прилетать и строки с экранированными символами
Потому и поблочно. Во первых это можно асинхронно, а во вторых сначала разметил блок, валидация и ток потом парсинг.
Json очень человеко-доступный но в плане машинного доступа он только в малых размерах приятен.
Смотря как оно лежит
В 90% случаев это простой массив обьектов (логи или отчеты)
И оно спокойно читается построчно
Но даже если все "по красоте" с отступами и переносами и сам документ не просто листинг однотипных обьектов, то все равно читаешь построчно но уже до определенного обьема с расчетом что бы закрылась ветка максимально (простая математика скобочек и кавычек с двоеточиями)
.
Я не знаю задачи где бы понадобилось выгрузить все 300гб данных в память одним обьектом
А декомпозицией можно терабайтами ворочать
Последнее гребаная магия!
Там на выводную мелкую (0203 и менее) уже нужно извернутся что бы подпаятся, и при пайке не сдвинуть случайно.
А тут ПОД ЧИП!!
Я понимаю что там скорее всего крвйний пятак впаяли но все же
Соглашусь - обычно такие кабеля закладывает тральшик в самом глубоком месте канала.
И кабель расчитан на рывки этого самого тральщика (херобора в сотни тонн)
Там в тех кабелях отношение оптоволокна к защите 1 к 1000 минимум
В теории даже сброс глубинной бомбы максимум их пододвинет чуть чуть (они огромные)
Тут нужно что то с направленым взрывом и уронить четко на кабель (помним про течения)
.
Дрон не катит - под водой все в разы сложнее и чем глубже тем больше сложностей.
Разве что камикадзе заварили что бы на ручном управлении
Спс, не заметил опечатки - jquery
И как всегда свидетели jqwery любят притягивать крайние случаи
Для первого случая хватит самого обычного js вот так:
<button onclick="setClass(this, 'bg-green')">Click Me</button>Где весь функционал будет в отдельном методе и в случае чего так же с одного места патчатся краевые условия.
.
Второй случай для ситуаций обработки сценариев, зачастую это все собирается конструктором и для кучи разных елементов. В коде выглядит как инициализация метода класса.
И даже если писать ручками - один хрен такой формат записи подходит больше именно для централизованой обработки всех событий
.
А теперь подходим к моему самому "любимому"
Свидетели jqwery - они записи формата $('results-pane').* раскидывают как обезьяна какашки.
Ладно 10+ лнт назад это было проще изяшнее чем то что позволял движок js на тот момент, но на сейчас старые костыли стали фичей говностроения.
Да - любым средсвом нужно уметь пользоватся, но как раз именно поддержка упрощенного синтаиса через $ очень сильо понижает требования к коду
.
Из жизни - если большой проект который лепили и дополняли хотя-бы пару лет при использовании jqwery, то добавление критично нового функционала зачастую вылазит в переписывание всей страницы.
Потому что можно "по быстрому" насыпать $ и не переживать так как внутрение конфликты jqwery разрешает сам. Быстро и удобно - самое то для разработки. А поддержка и расширение - ну это сложная задача, требуюшая много трудозатрат
.
Может мое мнение субьективное - я с фронт-ендерами просто плотно работаю, но я никогда не встречал решений на jqwery в ситуациях с "нормально делай - нормально будет"
А за гугл соглашусь - он уже лет 10 не торт, а его ресурсы не проходят его же тесты что он выкладывает в открытый доступ)