Вот бы по "индексу Хирша" можно было "проранжировать" языки программирования, чтобы это метрики влияния на отрасль в целом. Количество, к сожалению, не отражает качество.
Хм. Т.е. он «придумал» геометрическую конструкцию. Проще говоря он "в уме" понимает что центр координат (симметричная ситуация) сдвигается и приводит пример где вероятность стала подозрительно маленькой. Круто.
Ну мощностей для симуляции мира понадобится побольше чем для генерации видео. Если брать человека, то за "картину мира" у него отвечает мозжечок. Так вот, мозжечок человека, занимая всего 10 % (150 гр.) от общей массы мозга, содержит 69 миллиардов нейронов, в то время как кора головного мозга всего 16 миллиардов при весе 1200 гр. Т.е. у нас в 4 раза больше нейронов отвечает за "картину мира", чем за все остальное.
Человек такое существо, если можно что-то не делать - делать не будет. Статья как ностальгический вздох системного программиста - «раньше трава была зеленее, а ассемблер — понятнее». Но соглашусь - иногда стоит "любить" код который пишешь, даже в разрез с задачами бизнеса.
Синхронное версионирование архитектурной модели и кода. Смещение фокуса с оформления на проектирование, в т.ч. непротиворечивой, модели. Автоматическое выполнение нормативных требований (регламентов и практик, принятых в компании).
Ну я именно это имел ввиду "AaC решает проблему с одной стороны устаревания архитектуры" и "автоматическая проверка разработки"
Автоматизированном формировании артефактов, необходимых различным ЗЛ.
Эту фразу не понял - недостаточно контекста
Стек и методика AaC никак не связаны.
Несогласен. Код чаще завязан на стек, вы ограничиваете AaC вебом, но в истории развития он использовался не только для веба. Приведу пример - MS для разработки драйверов ядра использовала prefast в windows 7 и код префаста работал строго на коде на си, причем специфически аннотированного и не работал на c++. В дальнейшем префаст в том виде и в том объеме проверок которые были в 7ке уже не присутствовал в WDK. Даже MS не потянула эту задачу - это, кстати, и пример про оверхед.
Как раз не уследил цепочку до конечного полезного результата (КПР). Вы пытаетесь анализировать архитектуру ради анализа архитектуры. Введение требования Architecture as Code в проект должно иметь критерии проверки, быть однозначным, полным, непротиворечивым, верифицируемым, трассируемым (можно отследить с КПР).
Насколько я понимаю, AaC решает проблему с одной стороны устаревания архитектуры сразу после того, как разработчики пишут первую строчку кода. А с другой стороны вводится автоматическая проверка разработки - архитектор может запретить кодом разработчику нарушить слоистую архитектуру или вызвать неразрешенный API, кроме как через ревью кода или соответствия стилю.
Простыми словами, например, Вы определили, что сервис «Заказы» не должен напрямую обращаться к базе данных сервиса «Платежи», если разработчик напишет такой код - он блокируется. Т.е. AaC по сути это жесткий, автоматизированный стандарт качества, который невозможно нарушить случайно.
Недостаток AaC в том что это "оверхэд" для многих проектов. Вы не сможете использовать "легаси" код (как и код который взаимодействует с не подконтрольными вызовами API и очередями или выполняется в "чужом" коде). Кроме того AaC часто привязывается к стеку и языкам программирования, что не всегда хорошо.
AaC приносит пользу только в зрелых командах, работающих над долгосрочными энтерпрайз-продуктами, где стоимость архитектурной ошибки перевешивает стоимость поддержки системы правил.
Эх, когда-то предлагал все секьюрные компании сделать страховыми, чтобы была ответственность с обеих сторон (размер страховки или даже вообще отказ определяет регламент секьюрной компании). А сейчас - выпустили "антивирус", взяли деньги за него, но ничего не гарантируют и никаких "убытков" за некачественное предоставление услуги не несут. А то по такой аналогии можно перебрасывать на любой вид деятельности - "вот вам самолет - он летает, но если упадет по тех причине - мы не виноваты". Что-то в IT мало ответственности.
"Интеграция функций искусственного интеллекта в сервисы" позволяет тех. директору, тимлиду и команде разработчиков поучиться интегрировать эти сервисы.
Банально - ни один «трюк» не сработает, если сам продукт не решает проблему пользователя, НО привлечение пользователей != удержание пользователей. Для "долгосрочного удержания пользователей" нужно решать долгосрочные проблемы пользователей.
различие между методом at и operator[] у std::vector
изменения порядка циклов с ijk на ikj
Все бы хорошо, да вот только когда речь идет о перфомансе - примеры есть? Где микросекунды? Верить на слово?
В статье опишу "набор новичка"
Есть упоминание об инструменте - нет примера использования. С одной стороны какие-то уж очень общие знания, с другой - переключение на "углубленные" нюансы С++.
Все что есть физически - можно отобрать рэкетом. А вот "рэкет" для телеги в виде макса не пошел - но не унывают - эксперименты во всех направлениях ставят каждый день.
Эволюцию, как и революцию не остановить. Многое в GPL мне не нравится - MIT лучше, но человеческая натура такова, что есть положительные и отрицательные стороны - GPL борется с отрицательными, MIT для альтруистов.
Простота всегда в почете только для того, чьи цели она преследует. Все различие будет в мотивации, если мотивация "повышение", то "простота" теряет свои плюсы. "Адекватность" в подавляющем большинстве компаний не является мотивацией.
В целом согласен - индустрия одурманенна дешевым успехом. Безответственность (слепое доверие машине) в сочетании с мощным инструментом.
С одной стороны: неконтролируемая генерация, как и неконтролируемое написание кода людьми (люди пишут не лучше) - это всегда плохо. Другое дело если говорить о скорости его генерации, которая превышает скорость качественного ревью. ИИ должен писать атомарные функции (ИИ — компилятор), человек — собирать из них систему. Должно действовать правило: «Ты не автор кода, но ты его ответственный».
С другой стороны: люди любят ленится - это заложено в "природой". Даже крутой стартап через две остановки от твоего дома, проиграет стартапу рядом с твоим домом. Не списывайте "природу" человека - он тоже не "белый и пушистый" в данной ситуации.
SSD без raid1 на "продакшн" - путь к простоям и, возможно, к потери данных. Есть небольшое смешивание факторов риска - хранение в плохих условиях (износ + тепло + время + коррозия платы + повреждения контактов или контроллера) vs физика памяти. По физике еще добавлю в TLC/QLC плотность ячеек такова, что заряд одной ячейки может влиять на соседнюю (cell-to-cell interference). Это важный фактор деградации данных, отличный от простого «утекания». Было бы круто иметь формулу расчета риска по годам (месяцам) выхода из строя исходя из условий работы и физики ssd.
Если не учитывать, что набор необходимых умений и знаний как и само понятие профессионализма в любой сфере постоянно меняется, то и без ИИ потеряешь.
Вот бы по "индексу Хирша" можно было "проранжировать" языки программирования, чтобы это метрики влияния на отрасль в целом. Количество, к сожалению, не отражает качество.
Хм. Т.е. он «придумал» геометрическую конструкцию. Проще говоря он "в уме" понимает что центр координат (симметричная ситуация) сдвигается и приводит пример где вероятность стала подозрительно маленькой. Круто.
Ну мощностей для симуляции мира понадобится побольше чем для генерации видео. Если брать человека, то за "картину мира" у него отвечает мозжечок. Так вот, мозжечок человека, занимая всего 10 % (150 гр.) от общей массы мозга, содержит 69 миллиардов нейронов, в то время как кора головного мозга всего 16 миллиардов при весе 1200 гр. Т.е. у нас в 4 раза больше нейронов отвечает за "картину мира", чем за все остальное.
Человек такое существо, если можно что-то не делать - делать не будет. Статья как ностальгический вздох системного программиста - «раньше трава была зеленее, а ассемблер — понятнее». Но соглашусь - иногда стоит "любить" код который пишешь, даже в разрез с задачами бизнеса.
Ну я именно это имел ввиду "AaC решает проблему с одной стороны устаревания архитектуры" и "автоматическая проверка разработки"
Эту фразу не понял - недостаточно контекста
Несогласен. Код чаще завязан на стек, вы ограничиваете AaC вебом, но в истории развития он использовался не только для веба. Приведу пример - MS для разработки драйверов ядра использовала prefast в windows 7 и код префаста работал строго на коде на си, причем специфически аннотированного и не работал на c++. В дальнейшем префаст в том виде и в том объеме проверок которые были в 7ке уже не присутствовал в WDK. Даже MS не потянула эту задачу - это, кстати, и пример про оверхед.
Как раз не уследил цепочку до конечного полезного результата (КПР). Вы пытаетесь анализировать архитектуру ради анализа архитектуры. Введение требования Architecture as Code в проект должно иметь критерии проверки, быть однозначным, полным, непротиворечивым, верифицируемым, трассируемым (можно отследить с КПР).
Насколько я понимаю, AaC решает проблему с одной стороны устаревания архитектуры сразу после того, как разработчики пишут первую строчку кода. А с другой стороны вводится автоматическая проверка разработки - архитектор может запретить кодом разработчику нарушить слоистую архитектуру или вызвать неразрешенный API, кроме как через ревью кода или соответствия стилю.
Простыми словами, например, Вы определили, что сервис «Заказы» не должен напрямую обращаться к базе данных сервиса «Платежи», если разработчик напишет такой код - он блокируется. Т.е. AaC по сути это жесткий, автоматизированный стандарт качества, который невозможно нарушить случайно.
Недостаток AaC в том что это "оверхэд" для многих проектов. Вы не сможете использовать "легаси" код (как и код который взаимодействует с не подконтрольными вызовами API и очередями или выполняется в "чужом" коде). Кроме того AaC часто привязывается к стеку и языкам программирования, что не всегда хорошо.
AaC приносит пользу только в зрелых командах, работающих над долгосрочными энтерпрайз-продуктами, где стоимость архитектурной ошибки перевешивает стоимость поддержки системы правил.
Эх, когда-то предлагал все секьюрные компании сделать страховыми, чтобы была ответственность с обеих сторон (размер страховки или даже вообще отказ определяет регламент секьюрной компании). А сейчас - выпустили "антивирус", взяли деньги за него, но ничего не гарантируют и никаких "убытков" за некачественное предоставление услуги не несут. А то по такой аналогии можно перебрасывать на любой вид деятельности - "вот вам самолет - он летает, но если упадет по тех причине - мы не виноваты". Что-то в IT мало ответственности.
Отличная тема для статьи кстати.
"Интеграция функций искусственного интеллекта в сервисы" позволяет тех. директору, тимлиду и команде разработчиков поучиться интегрировать эти сервисы.
Банально - ни один «трюк» не сработает, если сам продукт не решает проблему пользователя, НО привлечение пользователей != удержание пользователей. Для "долгосрочного удержания пользователей" нужно решать долгосрочные проблемы пользователей.
Все бы хорошо, да вот только когда речь идет о перфомансе - примеры есть? Где микросекунды? Верить на слово?
Есть упоминание об инструменте - нет примера использования. С одной стороны какие-то уж очень общие знания, с другой - переключение на "углубленные" нюансы С++.
Ну не только одним Atlassian живет рынок - когда то использовал https://trac.edgewall.org/ на питоне и очень быстро интегрируются многие вещи.
Давно уже не читал статьи в которых чувствуется "теплота" написавшего ее человека. Читается на одном дыхании. Спасибо.
Если основывать рабочие процессы на архитектуре, а не на конечном полезном результате, то они не смогут ни эффективно масштабироваться, ни обучаться, ни адаптироваться. см. От картинки к системе разработки проектов. Фундамент под ногами
Delicias habet omne suas et gaudia tempus.
Все что есть физически - можно отобрать рэкетом. А вот "рэкет" для телеги в виде макса не пошел - но не унывают - эксперименты во всех направлениях ставят каждый день.
Эволюцию, как и революцию не остановить. Многое в GPL мне не нравится - MIT лучше, но человеческая натура такова, что есть положительные и отрицательные стороны - GPL борется с отрицательными, MIT для альтруистов.
Простота всегда в почете только для того, чьи цели она преследует. Все различие будет в мотивации, если мотивация "повышение", то "простота" теряет свои плюсы. "Адекватность" в подавляющем большинстве компаний не является мотивацией.
В целом согласен - индустрия одурманенна дешевым успехом. Безответственность (слепое доверие машине) в сочетании с мощным инструментом.
С одной стороны: неконтролируемая генерация, как и неконтролируемое написание кода людьми (люди пишут не лучше) - это всегда плохо. Другое дело если говорить о скорости его генерации, которая превышает скорость качественного ревью. ИИ должен писать атомарные функции (ИИ — компилятор), человек — собирать из них систему. Должно действовать правило: «Ты не автор кода, но ты его ответственный».
С другой стороны: люди любят ленится - это заложено в "природой". Даже крутой стартап через две остановки от твоего дома, проиграет стартапу рядом с твоим домом. Не списывайте "природу" человека - он тоже не "белый и пушистый" в данной ситуации.
SSD без raid1 на "продакшн" - путь к простоям и, возможно, к потери данных. Есть небольшое смешивание факторов риска - хранение в плохих условиях (износ + тепло + время + коррозия платы + повреждения контактов или контроллера) vs физика памяти. По физике еще добавлю в TLC/QLC плотность ячеек такова, что заряд одной ячейки может влиять на соседнюю (cell-to-cell interference). Это важный фактор деградации данных, отличный от простого «утекания». Было бы круто иметь формулу расчета риска по годам (месяцам) выхода из строя исходя из условий работы и физики ssd.