Нет, это уже совсем не скрам. Это мини-команда, которая end-to-end отвечает за ввереную часть продукта. Может состоять из одного человека, в реале я думаю более вероятно 1-3.
Да конечно это всё метафора и человеческая организация это не что-то детерминированное что должно всегда выдавать нужные характеристики в нужных условиях. Но процессы усложнять можно по разному — добавлять людей, слои менеджемента, как если мы хотим масштабировать стройку. А можно "уплотнять" компетенции и ответственность, что безусловно более рискованно, но в идеальном мире может отлично работать.
А почему не показательный? Raptor 3 нельзя было сделать без информации от Raptor 1/2 и возможно новых технологических и дизайнерских решений. И то, что первая часть исследовательская и экспериментальная — как раз показательно. На примере — кажется, что лет через 5 использование ИИ на всех этапах SDLC будет гораздо более целостным, чем это сейчас, когда организации двигаются на ощупь, исследуют риски и осваивают рокетджамп находят баланс между повышением производительности и безопасностью деплоев.
Формат поста не позволяет вставить две картинки — вставлю тут ещё одну картинку из статьи. Наглядный пример инженерной эволюции. На фотке — ракетные двигатели Raptor, от первой до третьей (актуальная) версии. С процессами бы так!
Рекомендую почитать оригинал статьи ) traditional enterprise таки тоже внедрял ИИ, просто методом эволюции. И тоже получили кратный прирост. Понятно, что есть эффект наблюдателя и это не значимая статистическая выборка. Но сейчас любые исследования ценны, т.к. практики только формируются.
Про когнитивную емкость (в оригинале "cognitive bandwidth") — на мой взгляд, очевидно верный концепт. Когда ты джун и понимаешь какие-то базовые вещи, ты используешь 100% своих знаний. Когда ты сеньор, понимаешь как устроен CAS, что такое CRDT, можешь спроектировать систему, написать простенький ML алгоритм, оценить UX и сделать ещё бог знает что на нескольких языках, но по какой-то причине пишешь очередной CRUD или event loop — ты используешь 1-5% знанией (в момент решения конкретной задачи). Чтобы использовать больше как раз нужен кто-то/что-то способный быстро следовать за мыслью, чтобы не пришлось тратить время тупо на набивку текста.
Прощу прощения за долгий ответ, но вот только дошли руки. Я думаю, что возможность иметь адаптированное отображения для кода — это прекрасно и мы точно к этому придём. Причём было бы прикольно иметь различные срезы — для SRE, DBA, инженеров по безопасности, продактов и бизнес и системных аналитиков. Это чуть более высокий уровень чем тот, про который вы пишите, но кажется такие представления могли бы решить много проблем. Довольно часто из кода можно восстановить изначальную постановку задачи и то, каким именно образом она была решения. А имея всё это, можно записать решение в более подходящем для восприятия виде. Я уверен, что так и будет.
Но ведь тоже касается и написания. Если мне нужно решить задачу и у меня есть алгоритм, которым я хочу решить эту задачу, то кажется самое простое что я могу сделать — это описать ограничения задачи и сам алгоритм. На русском/английском используя математические термины или термины предметной области — это не важно. Если есть модель, которая хорошо воспринимает естественные и формальные языки, то так ли важно в какой именно код она преобразует написанное мной? Важно чтобы она смогла передать мне все условия и ограничения своего решения, но ведь для этого даже не обязательно показывать сгенерированный код. Достаточно описать это в лаконичной понятной форме, как это делает Wolfram M.
Таким образом, мой тезис про то, что читать важнее чем писать, он скорее про то, что сейчас следует ориентироваться на то, что человек не будет писать код. Точно также как мы сейчас редко пишем на низкоуровневых языках, написание кода на высокоуровневых языках станет нишевой историей. Потому что написание кода на любом языке — это снижение уровня абстракции, приземление на конкретный синтаксис, паттерны и библиотеки. Думаю это функцию вполне по силам делегировать моделям и сконцентрироваться на задаче "что делать", а не "как записать" то, реализацию чего уже придумали.
--
Не знаю, ответил ли я на исходный вопрос, но в любом случае, спасибо за него, навёл на мысли )
Спасибо за развернутый ответ, сейчас мне стало понятнее и я попробую ответить.
Для описанного вами автокомплита я бы предпочел
FROM users
SELECT email, age ;
Но создатели SQL как раз приоритизировали понимание запроса человеком и исходный вариант гораздо ближе к человеческому "select email and age from users where ... " что, я полагаю, явилось причиной появления языка в том виде, в котором мы его знаем теперь. Размышление на эту тему подталкивает меня к тому, что понятность с точки зрения IDE и понятность для человека имеют большую дистанцию чем, скажем, понятность для модели и для человека. Для человека критично важно видеть итоговые структуры, которые возникают на выходе программы и желательно иметь максимально простой способ понять почему именно возникают именно такие структуры. Думаю, это и предопределило декларативность практически всех языков преобразования данных. В той же JSONata в простейших случаях мы сразу описываем ту структуру которую ждем на выходе.
Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания. При этом, конечно, по возможности надо способствовать корректному написанию. В этом смысле, как только в branchline вызреют сложные типы данных (json schema вполне может быть использована для их задания), то программа на нём будет проверять корректность ещё на этапе анализа. И автокомплит по типам будет поддержан в LSP. Но до полноценной поддержки типов надо дожить )
Не совсем понял. А что такое autocomplete friendly для языка? Если рассматривать отдельно от легкой воспринимаемости для моделей, то для меня это что-то типа настроек для монако. Но тогда во-первых, на базовом уровне автокомплит есть и работает в плейграунде, а во-вторых, не понятно как это может стереть грань. И я не уверен, что такую цель нужно ставить именно перед языком, а не перед его редактором, например. Но, возможно, я как-то не так понял что вы имели в виду, буду признателен за уточнение.
Ниша узкая, это правда. Но например, если мы непременно хотим иметь возможность менять скрипт на лету и при этом иметь нечто более специализированное чем python, то у нас не так много опций — JSONiq, JSONata, JOLT, JSLT и ещё что-то редкое. У всего этого есть минусы, а если мы добавим полноценную отладку и экзотику типа вывода контрактов, то я даже не знаю подходящих альтернатив.
Но Branchline — это прежде всего эксперимент в рамках другого эксперимента. По-настоящем, как мне кажется, его можно раскрыть только если будет реализация платформы.
Видимо придирка к «распределение… описывается», я бы сказал «данные распределены вдоль прямой», но я ни разу не переводчик. Ну и в целом «алгоритмы данных предполагают» звучит довольно необычно :-)
Но как быть простому смертному? Простому, нормальному парню, который в гробу видал все эти технологии. Парню, который не торчит от новой операционки, или сраного гаджета.
Как вариант — смириться с недостатком мозгов и найти менее требовательную профессию. В депутаты можно пойти, ограничительные законы писать. Заодно можно с легкостью отыграться на этих мерзких «ботанах».
Размазывать сопли о прокуренную жилетку хабра — не вариант. А то так и будет — «жизнь заставила быть программистом», а хочется «тискать девочек во дворах» и прочее нытье. Следуйте моде: nodejs, mongodb — читать много не надо и девочкам в клубах будет что рассказать.
Как правило, такие туториалы предназначаются для самого начального уровня, чтобы можно было быстро вовлечь человека. Рассматривать здесь вопросы настройки продакшена совершенно не к месту. К тому же из начала статьи понятно, что текст от новичка к совсем новичку.
Про respond_to никто не забывает. Полезная штука. Но, к сожалению, тоже не универсальная.
Презентеры — это уже немного про другое, в любом случае, возникает вопрос о том, как хранить эти самые презентеры, чтобы удержать контроль над кодом.
Раз уж заговорили про презентеры, то вот — blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/
Rails way, Rails wayем, а то что реально решает проблемы, пропускать не стоит.
А разгадка одна — желание сделать код как можно более легким для поддержания. CanCan — норм, когда речь идет о простых вещах. Сложные контроллеры порождают кучу условных фильтров, мусорных спецификаций (типа блоков respond_to) и соотношение неполезного кода к полезному становится не в пользу последнего. Некоторых людей это раздражает.
Использовать такое разделение с самого начала проекта, конечно, спорное решение. Особенно, когда непонятно, появятся такие сущности или нет. Но, например, автор статьи несколько месяцев назад подал идею разнести отдачу html и js по разным контроллерам. А именно, js-ответы вынести в API. Совсем не типично для Rails Way, но результат на практике мне очень нравится.
А в целом — присоединяюсь к комментатору ниже, написавшему про Engines. Особенно с Rails 3.1+
Нет, это уже совсем не скрам. Это мини-команда, которая end-to-end отвечает за ввереную часть продукта. Может состоять из одного человека, в реале я думаю более вероятно 1-3.
Да конечно это всё метафора и человеческая организация это не что-то детерминированное что должно всегда выдавать нужные характеристики в нужных условиях. Но процессы усложнять можно по разному — добавлять людей, слои менеджемента, как если мы хотим масштабировать стройку. А можно "уплотнять" компетенции и ответственность, что безусловно более рискованно, но в идеальном мире может отлично работать.
А почему не показательный? Raptor 3 нельзя было сделать без информации от Raptor 1/2 и возможно новых технологических и дизайнерских решений. И то, что первая часть исследовательская и экспериментальная — как раз показательно. На примере — кажется, что лет через 5 использование ИИ на всех этапах SDLC будет гораздо более целостным, чем это сейчас, когда организации двигаются на ощупь, исследуют риски и
осваивают рокетджампнаходят баланс между повышением производительности и безопасностью деплоев.Формат поста не позволяет вставить две картинки — вставлю тут ещё одну картинку из статьи. Наглядный пример инженерной эволюции. На фотке — ракетные двигатели Raptor, от первой до третьей (актуальная) версии. С процессами бы так!
Рекомендую почитать оригинал статьи ) traditional enterprise таки тоже внедрял ИИ, просто методом эволюции. И тоже получили кратный прирост. Понятно, что есть эффект наблюдателя и это не значимая статистическая выборка. Но сейчас любые исследования ценны, т.к. практики только формируются.
Про когнитивную емкость (в оригинале "cognitive bandwidth") — на мой взгляд, очевидно верный концепт. Когда ты джун и понимаешь какие-то базовые вещи, ты используешь 100% своих знаний. Когда ты сеньор, понимаешь как устроен CAS, что такое CRDT, можешь спроектировать систему, написать простенький ML алгоритм, оценить UX и сделать ещё бог знает что на нескольких языках, но по какой-то причине пишешь очередной CRUD или event loop — ты используешь 1-5% знанией (в момент решения конкретной задачи). Чтобы использовать больше как раз нужен кто-то/что-то способный быстро следовать за мыслью, чтобы не пришлось тратить время тупо на набивку текста.
Прощу прощения за долгий ответ, но вот только дошли руки. Я думаю, что возможность иметь адаптированное отображения для кода — это прекрасно и мы точно к этому придём. Причём было бы прикольно иметь различные срезы — для SRE, DBA, инженеров по безопасности, продактов и бизнес и системных аналитиков. Это чуть более высокий уровень чем тот, про который вы пишите, но кажется такие представления могли бы решить много проблем. Довольно часто из кода можно восстановить изначальную постановку задачи и то, каким именно образом она была решения. А имея всё это, можно записать решение в более подходящем для восприятия виде. Я уверен, что так и будет.
Но ведь тоже касается и написания. Если мне нужно решить задачу и у меня есть алгоритм, которым я хочу решить эту задачу, то кажется самое простое что я могу сделать — это описать ограничения задачи и сам алгоритм. На русском/английском используя математические термины или термины предметной области — это не важно. Если есть модель, которая хорошо воспринимает естественные и формальные языки, то так ли важно в какой именно код она преобразует написанное мной? Важно чтобы она смогла передать мне все условия и ограничения своего решения, но ведь для этого даже не обязательно показывать сгенерированный код. Достаточно описать это в лаконичной понятной форме, как это делает Wolfram M.
Таким образом, мой тезис про то, что читать важнее чем писать, он скорее про то, что сейчас следует ориентироваться на то, что человек не будет писать код. Точно также как мы сейчас редко пишем на низкоуровневых языках, написание кода на высокоуровневых языках станет нишевой историей. Потому что написание кода на любом языке — это снижение уровня абстракции, приземление на конкретный синтаксис, паттерны и библиотеки. Думаю это функцию вполне по силам делегировать моделям и сконцентрироваться на задаче "что делать", а не "как записать" то, реализацию чего уже придумали.
--
Не знаю, ответил ли я на исходный вопрос, но в любом случае, спасибо за него, навёл на мысли )
Спасибо за развернутый ответ, сейчас мне стало понятнее и я попробую ответить.
Для описанного вами автокомплита я бы предпочел
Но создатели SQL как раз приоритизировали понимание запроса человеком и исходный вариант гораздо ближе к человеческому "select email and age from users where ... " что, я полагаю, явилось причиной появления языка в том виде, в котором мы его знаем теперь.
Размышление на эту тему подталкивает меня к тому, что понятность с точки зрения IDE и понятность для человека имеют большую дистанцию чем, скажем, понятность для модели и для человека. Для человека критично важно видеть итоговые структуры, которые возникают на выходе программы и желательно иметь максимально простой способ понять почему именно возникают именно такие структуры. Думаю, это и предопределило декларативность практически всех языков преобразования данных. В той же JSONata в простейших случаях мы сразу описываем ту структуру которую ждем на выходе.
Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания. При этом, конечно, по возможности надо способствовать корректному написанию. В этом смысле, как только в branchline вызреют сложные типы данных (json schema вполне может быть использована для их задания), то программа на нём будет проверять корректность ещё на этапе анализа. И автокомплит по типам будет поддержан в LSP. Но до полноценной поддержки типов надо дожить )
Не совсем понял. А что такое autocomplete friendly для языка? Если рассматривать отдельно от легкой воспринимаемости для моделей, то для меня это что-то типа настроек для монако. Но тогда во-первых, на базовом уровне автокомплит есть и работает в плейграунде, а во-вторых, не понятно как это может стереть грань. И я не уверен, что такую цель нужно ставить именно перед языком, а не перед его редактором, например.
Но, возможно, я как-то не так понял что вы имели в виду, буду признателен за уточнение.
О, не знал о таком проекте, выглядит очень круто, спасибо за наводку!
Спасибо :-)
Ниша узкая, это правда. Но например, если мы непременно хотим иметь возможность менять скрипт на лету и при этом иметь нечто более специализированное чем python, то у нас не так много опций — JSONiq, JSONata, JOLT, JSLT и ещё что-то редкое. У всего этого есть минусы, а если мы добавим полноценную отладку и экзотику типа вывода контрактов, то я даже не знаю подходящих альтернатив.
Но Branchline — это прежде всего эксперимент в рамках другого эксперимента. По-настоящем, как мне кажется, его можно раскрыть только если будет реализация платформы.
В любом случае спасибо за труд!
Как вариант — смириться с недостатком мозгов и найти менее требовательную профессию. В депутаты можно пойти, ограничительные законы писать. Заодно можно с легкостью отыграться на этих мерзких «ботанах».
Размазывать сопли о прокуренную жилетку хабра — не вариант. А то так и будет — «жизнь заставила быть программистом», а хочется «тискать девочек во дворах» и прочее нытье. Следуйте моде: nodejs, mongodb — читать много не надо и девочкам в клубах будет что рассказать.
P.S. Заранее прощу прощения за убитое время.
Презентеры — это уже немного про другое, в любом случае, возникает вопрос о том, как хранить эти самые презентеры, чтобы удержать контроль над кодом.
Раз уж заговорили про презентеры, то вот — blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/
Rails way, Rails wayем, а то что реально решает проблемы, пропускать не стоит.
Использовать такое разделение с самого начала проекта, конечно, спорное решение. Особенно, когда непонятно, появятся такие сущности или нет. Но, например, автор статьи несколько месяцев назад подал идею разнести отдачу html и js по разным контроллерам. А именно, js-ответы вынести в API. Совсем не типично для Rails Way, но результат на практике мне очень нравится.
А в целом — присоединяюсь к комментатору ниже, написавшему про Engines. Особенно с Rails 3.1+