Это был лишь один из примеров. Часто можно встретить проекты, где разные кусоки пишутся на разных языках. При этом они тесно связаны какими-то общими соглашениями. Это может быть специфичная структура директорий, соглашения по именованию, конфиги, аннотации, типы, API или даже все вместе. Код может лежать как в одном репозитории, так и в разных. Где-то зависимости прописаны строго (варианты .lock файлов), а где-то результат становится известен лишь после установки. Могут использоваться разные библиотеки или разные версии одной и той же библиотеки, порой несовместимые друг с другом.
Короче, код анализ в общем случае это сложная проблема, решение которой не сводится к одному лишь AST. У вас логичная идея - построить граф зависимостей. Но как добывать для него данные это креативная часть.
Ну не надо со мной, как с ребенком-то разговаривать.
В каждом из нас живёт внутренний ребёнок, который умеет радоваться, огорчаться, а порой даже капризничать)
Что именно не считывается с уровня синтаксиса языка программирования?
Например, для построения графа зависимостей между модулями TypeScript требуется анализ файлов конфигурации компилятора где могут быть определены кастомные пути и алиасы https://www.typescriptlang.org/tsconfig/#paths. Такие конфиги можно раскидать по разным папкам. Это может использоваться и внутри одного проекта (разные конфиги для кода и тестов), и для разных в случае монорепозиториев. Не могу рассказать, как это реализовано у них в LSP, я тут больше юзер.
Вот это я не очень понял: а LSP его откуда возьмет?
Под капотом конкретных реализаций LSP уже наворотили не только синтаксический анализ, но и поддержку различных библиотек, фреймворков, пакетеых менеджеров, систем сборки и т.п. специфики, которая не считывается с уровня лишь синтаксиса языка программирования.
CodeQL для компилируемых языков вообще по умолчанию пытается делать сборку проекта, чтобы получить еще больше данных.
Синтезатор решает кучу вопросов (ну может быть кроме цены). С гитарой проблема в том, что она заставляет первые недели страдать пока не огрубеют пальцы, а потом нужно играть постоянно для поддержания эффекта и вовремя стричь ногти. С фоно все гораздо проще.
Более глубокий анализ можно выдрать из LSP (например https://github.com/axivo/mcp-lsp). Но здесь могут быть сложности с развертыванием и вопросы к перфомансу.
Из взрослого есть CodeQL от GitHub https://codeql.github.com. Он кроме AST поддерживает разные варианты графов: call graph, control flow graph, data flow graph, api graph. Из минусов сложные настройки и никакущая документация, которой много, но она ни чего не объясняет.
Было бы интересно посмотреть насколько резюме матчатся вакансиям - нет ли перекоса когда спрос есть, но совершенно на другие специальности. Так же учесть кейсы, когда один кандидат публикует несколько резюме.
взятие на себя обязанностей следующей должности или грейда. Деньги придут в рамках года. Все хорошие начальники видят такое и по возможности повышают.
У руководителя проекта есть бюджет и штатное расписание. Если там появляются какие-то лишние деньги или люди с кучей свободного времени- чтобы помимо своих прямых обязанностей заниматься чем-то ещё, - то в течении года все это анализируется и оптимизируется.
Прошлые годы была ненормальная ситуация, когда проекты и штат надувались как пузыри. Но сейчас какой смысл портить нормального сотрудника за свой же счёт?
Слова ничто. Код или софтскилы (если рост в сторону управления) все.
Софт-скиллы это и есть слова, в основном. Как в паттерне «слова вместо результата» - работы, денег, должностей - где они в практическом смысле становятся на вес золота.
Чтобы стать лидом, нужна брать на себя проекты и показывать лидерские качества
Факторов, которые влияют на карьерный рост, множество. Начиная со скиллов (способности, знания, опыт) и амбиций, заканчивая набором свободных позиций и межличностными отношениями с руководством. Не ясен смысл формулировок «превосходит ожидания» и «выход за пределы ожидаемых от него компетенций».
Руководители ждут, что обязанности будут выполняться подчиненными, у которых изначально для этого нет необходимых компетенций. А подчинённые, в свою очередь, ждут, что их за это повысят или через год заплатят бонусы. Так это работает?
мидл по тем или иным причинам, взял на себя менторство нового сотрудника, или руководство разработкой новой фичи, вот и получается что он вышел за пределы ожидаемых от него компетенций
О чём думает руководство, давая сотруднику задачу, которая по их мнению выходит за рамки его компетенций. Они вообще рассчитывают на успех или же им все равно?
Ни кто не платит за уже оказанные услуги. Поэтому оплату овертаймов нужно согласовывать заранее. Это не так уж и сложно - работать бесплатно вас в любом случае ни кто заставить не может.
Годовой бонус это не оплата уже сделанной работы, а мотиватор весь следующий период работать лучше. Не в смысле количества часов, а качества, включая пресловутые extra mile. То есть, это не оплата ваших инвестиций, это инвестиция в вас со стороны бизнеса.
Если менеджмент по каким-то своим причинам его занижает или вообще отказывается платить это в общем-то их решение и их проблемы. Скорее всего ваша работа здесь не сильно нужна и всем будет лучше расстаться с миром.
Маркетплейс, наоборот, делает мелкобизнесменов ИЗЛИШНИМ звеном
Товар сам себя не продаст. На продавцах остаются основные риски, связанные с выбором ассортимента, продвижением, ценообразованием и работой с возражениями. Десятки тысяч мелких мотивированных продавцов решают задачу оптимизации лучше любого отдела продаж.
Ну конечно, 7 стадий это что-то само собой разумеющееся. Поэтому не нужно ни чего объяснять, достаточно просто их перечислить. В 2025 же все изучают Маркса со школьной скамьи, в отличие от комплексных чисел.
Если серьёзно, аналогия с миром финансов заинтриговала. Однако в реальности для денежных расчётов не используют комплексные числа. Ну то есть будь у такой философии хоть какой-то практический смысл, мы бы видели эту математику на практике. Уж кто, а бизнес вряд-ли упустил конкурентное преимущество в оценке ценностей, будь оно здесь. Но это просто догадки, вероятно я не понял эту часть статьи.
Тут еще фактически ввожу новую концепцию «отчужденного знания». По аналогии с Марксом.
В математике каждый термин несёт в себе какую-то собственную пользу. Отсылки к марксизму в виде утверждений, которые ниоткуда не следуют, и ни чего не объясняют, выглядят в этой статье как инородное тело. Да и сам он появился явно позже, описываемых здесь событий. Видно, что вам близка эта тема, но было бы лучше вынести в отдельную статью, чтобы можно было проследить всю логику.
Отличная идея. Хотя с тематическим лором вместо стандартных локаций смотрелось бы интереснее. Было бы здорово найти там оружие против демонов, кто публикует сгенерированный LLM слоп под видом авторского контента, меняет дизайн, добавляет баги в редактор комментов или минусит карму.
В условиях песчаной бури вообще что-то летает или она сама по себе уже как пво?
Это был лишь один из примеров. Часто можно встретить проекты, где разные кусоки пишутся на разных языках. При этом они тесно связаны какими-то общими соглашениями. Это может быть специфичная структура директорий, соглашения по именованию, конфиги, аннотации, типы, API или даже все вместе. Код может лежать как в одном репозитории, так и в разных. Где-то зависимости прописаны строго (варианты .lock файлов), а где-то результат становится известен лишь после установки. Могут использоваться разные библиотеки или разные версии одной и той же библиотеки, порой несовместимые друг с другом.
Короче, код анализ в общем случае это сложная проблема, решение которой не сводится к одному лишь AST. У вас логичная идея - построить граф зависимостей. Но как добывать для него данные это креативная часть.
В каждом из нас живёт внутренний ребёнок, который умеет радоваться, огорчаться, а порой даже капризничать)
Например, для построения графа зависимостей между модулями TypeScript требуется анализ файлов конфигурации компилятора где могут быть определены кастомные пути и алиасы https://www.typescriptlang.org/tsconfig/#paths. Такие конфиги можно раскидать по разным папкам. Это может использоваться и внутри одного проекта (разные конфиги для кода и тестов), и для разных в случае монорепозиториев. Не могу рассказать, как это реализовано у них в LSP, я тут больше юзер.
Под капотом конкретных реализаций LSP уже наворотили не только синтаксический анализ, но и поддержку различных библиотек, фреймворков, пакетеых менеджеров, систем сборки и т.п. специфики, которая не считывается с уровня лишь синтаксиса языка программирования.
CodeQL для компилируемых языков вообще по умолчанию пытается делать сборку проекта, чтобы получить еще больше данных.
Синтезатор решает кучу вопросов (ну может быть кроме цены). С гитарой проблема в том, что она заставляет первые недели страдать пока не огрубеют пальцы, а потом нужно играть постоянно для поддержания эффекта и вовремя стричь ногти. С фоно все гораздо проще.
Для синтаксического разбора часто используют tree-sitter (например https://aider.chat/2023/10/22/repomap.html, https://ast-grep.github.io/), который поддерживает кучу языков. Но он больше оптимизирован на скорость, нежели полноту.
Более глубокий анализ можно выдрать из LSP (например https://github.com/axivo/mcp-lsp). Но здесь могут быть сложности с развертыванием и вопросы к перфомансу.
Из взрослого есть CodeQL от GitHub https://codeql.github.com. Он кроме AST поддерживает разные варианты графов: call graph, control flow graph, data flow graph, api graph. Из минусов сложные настройки и никакущая документация, которой много, но она ни чего не объясняет.
Было бы интересно посмотреть насколько резюме матчатся вакансиям - нет ли перекоса когда спрос есть, но совершенно на другие специальности. Так же учесть кейсы, когда один кандидат публикует несколько резюме.
У руководителя проекта есть бюджет и штатное расписание. Если там появляются какие-то лишние деньги или люди с кучей свободного времени- чтобы помимо своих прямых обязанностей заниматься чем-то ещё, - то в течении года все это анализируется и оптимизируется.
Прошлые годы была ненормальная ситуация, когда проекты и штат надувались как пузыри. Но сейчас какой смысл портить нормального сотрудника за свой же счёт?
Софт-скиллы это и есть слова, в основном. Как в паттерне «слова вместо результата» - работы, денег, должностей - где они в практическом смысле становятся на вес золота.
Факторов, которые влияют на карьерный рост, множество. Начиная со скиллов (способности, знания, опыт) и амбиций, заканчивая набором свободных позиций и межличностными отношениями с руководством. Не ясен смысл формулировок «превосходит ожидания» и «выход за пределы ожидаемых от него компетенций».
Руководители ждут, что обязанности будут выполняться подчиненными, у которых изначально для этого нет необходимых компетенций. А подчинённые, в свою очередь, ждут, что их за это повысят или через год заплатят бонусы. Так это работает?
О чём думает руководство, давая сотруднику задачу, которая по их мнению выходит за рамки его компетенций. Они вообще рассчитывают на успех или же им все равно?
Интересно, чем тогда старший с лидом занимались в то время, пока их обязанности выполнял мидл?
Ни кто не платит за уже оказанные услуги. Поэтому оплату овертаймов нужно согласовывать заранее. Это не так уж и сложно - работать бесплатно вас в любом случае ни кто заставить не может.
Годовой бонус это не оплата уже сделанной работы, а мотиватор весь следующий период работать лучше. Не в смысле количества часов, а качества, включая пресловутые extra mile. То есть, это не оплата ваших инвестиций, это инвестиция в вас со стороны бизнеса.
Если менеджмент по каким-то своим причинам его занижает или вообще отказывается платить это в общем-то их решение и их проблемы. Скорее всего ваша работа здесь не сильно нужна и всем будет лучше расстаться с миром.
ИИ не заменит - он креативно предлагает варианты, но не берет на себя ни какие риски.
Товар сам себя не продаст. На продавцах остаются основные риски, связанные с выбором ассортимента, продвижением, ценообразованием и работой с возражениями. Десятки тысяч мелких мотивированных продавцов решают задачу оптимизации лучше любого отдела продаж.
Ну конечно, 7 стадий это что-то само собой разумеющееся. Поэтому не нужно ни чего объяснять, достаточно просто их перечислить. В 2025 же все изучают Маркса со школьной скамьи, в отличие от комплексных чисел.
Если серьёзно, аналогия с миром финансов заинтриговала. Однако в реальности для денежных расчётов не используют комплексные числа. Ну то есть будь у такой философии хоть какой-то практический смысл, мы бы видели эту математику на практике. Уж кто, а бизнес вряд-ли упустил конкурентное преимущество в оценке ценностей, будь оно здесь. Но это просто догадки, вероятно я не понял эту часть статьи.
Неудобства в нужных местах развивают дисциплину. Если на территорию нельзя проносить определённые вещи, то зачем их вообще брать с собой на работу?
В математике каждый термин несёт в себе какую-то собственную пользу. Отсылки к марксизму в виде утверждений, которые ниоткуда не следуют, и ни чего не объясняют, выглядят в этой статье как инородное тело. Да и сам он появился явно позже, описываемых здесь событий. Видно, что вам близка эта тема, но было бы лучше вынести в отдельную статью, чтобы можно было проследить всю логику.
Что такое факты, с позиции нейронки?
Там проще: 1 + 100, 2 + 99, ..., 50 + 51 = 101 × 50
Отличная идея. Хотя с тематическим лором вместо стандартных локаций смотрелось бы интереснее. Было бы здорово найти там оружие против демонов, кто публикует сгенерированный LLM слоп под видом авторского контента, меняет дизайн, добавляет баги в редактор комментов или минусит карму.