Проблема в том, что не учитывается человеческая природа. А она такова, что специально научить его невозможно, человек может только сам учиться. Но сам учиться будет только тот, кому интересно и который “горит” темой (я понимаю тут возражение что еще и "кушать хочется", но в данном случае контекст другой). К сожалению, 99% людей спускают все на самотек не замечая, что при этом падает качество жизни. Джун с "горящими глазами", гораздо более интересен, чем senior с "потухшими".
Каждый из них решает свой круг по сложности задачи.
Скорее каждый несет разную ответственность, а сложность задач лишь "возможность" преувеличить свои заслуги. Потоковая помощь никогда не блистала сложностью задач.
Как вариант, но в большинстве случаев человек довольно простое создание. Ему хорошо когда он кормит мозг чем-то новым, когда он испытывает новые эмоции и новые ощущения от оценки своих действий или возможности эти действия совершить - не более.
Обе статьи это с одной стороны всего лишь вариант "как себя занять", с другой это способ "безопасно" получать что-то новое.
Гораздо важнее понять как постоянно поставлять "новое" для себя и, желательно, чтобы это новое тебя не убило. :) Без этого выгорание при любом раскладе и "эффективности и качестве жизни". А этого нет в статьях.
Как раз этот момент судя по статьям понятен, непонятно что для Вас "с достижением желаемого" желаемое. Что Вами движет и для чего Вы все делаете, а в статях нет целей и нет эмоций.
Как то все с середины начато, даже захватывая 1ю часть. Для начала нужно определится что мы хотим получить в итоге, этого нет ни в первой части ни во второй. Есть - следование по течению жизни, нету целей, нет эмоций - тогда зачем? И не учитывается важный момент - мы стареем, один час времени в молодости никогда не будет равен целому дню в старости.
Если хочешь проверить на что способен админ - попроси его установить почтовый сервер "локально", но чтобы мог принимать и отправлять почту на "все" внешние (без SMTP relay). Проблем ... начиная от 25 порта у провайдера, не говоря уже об описанных в статье SPF + DKIM + DMARC, one-click отписка. Вплоть до того, что если твой IP из динамических диапазонов, то письма отклоняются. В целом мороки ... А вообще получилось gmail уговорить?
Наконец-то что-то адекватное. Сочетание максимального перфоманса на Си в месте где он нужен в библиотеках и максимального удобства и простоты в месте где перфоманс не нужен в виде python. Кто нибудь использует сочетание python+Си для разработки?
Вот бы по "индексу Хирша" можно было "проранжировать" языки программирования, чтобы это метрики влияния на отрасль в целом. Количество, к сожалению, не отражает качество.
Хм. Т.е. он «придумал» геометрическую конструкцию. Проще говоря он "в уме" понимает что центр координат (симметричная ситуация) сдвигается и приводит пример где вероятность стала подозрительно маленькой. Круто.
Ну мощностей для симуляции мира понадобится побольше чем для генерации видео. Если брать человека, то за "картину мира" у него отвечает мозжечок. Так вот, мозжечок человека, занимая всего 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
Все бы хорошо, да вот только когда речь идет о перфомансе - примеры есть? Где микросекунды? Верить на слово?
В статье опишу "набор новичка"
Есть упоминание об инструменте - нет примера использования. С одной стороны какие-то уж очень общие знания, с другой - переключение на "углубленные" нюансы С++.
Проблема в том, что не учитывается человеческая природа. А она такова, что специально научить его невозможно, человек может только сам учиться. Но сам учиться будет только тот, кому интересно и который “горит” темой (я понимаю тут возражение что еще и "кушать хочется", но в данном случае контекст другой). К сожалению, 99% людей спускают все на самотек не замечая, что при этом падает качество жизни. Джун с "горящими глазами", гораздо более интересен, чем senior с "потухшими".
Скорее каждый несет разную ответственность, а сложность задач лишь "возможность" преувеличить свои заслуги. Потоковая помощь никогда не блистала сложностью задач.
Ситуация напоминает "ужа на сковородке", полное непринятие ...
Как вариант, но в большинстве случаев человек довольно простое создание. Ему хорошо когда он кормит мозг чем-то новым, когда он испытывает новые эмоции и новые ощущения от оценки своих действий или возможности эти действия совершить - не более.
Обе статьи это с одной стороны всего лишь вариант "как себя занять", с другой это способ "безопасно" получать что-то новое.
Гораздо важнее понять как постоянно поставлять "новое" для себя и, желательно, чтобы это новое тебя не убило. :) Без этого выгорание при любом раскладе и "эффективности и качестве жизни". А этого нет в статьях.
Что-то подсказывает, что нейропроцессор не будет поддерживаться софтом. Интел часто забрасывает поддержку софтом своих NPU https://github.com/intel/intel-npu-acceleration-library
Как раз этот момент судя по статьям понятен, непонятно что для Вас "с достижением желаемого" желаемое. Что Вами движет и для чего Вы все делаете, а в статях нет целей и нет эмоций.
Как то все с середины начато, даже захватывая 1ю часть. Для начала нужно определится что мы хотим получить в итоге, этого нет ни в первой части ни во второй. Есть - следование по течению жизни, нету целей, нет эмоций - тогда зачем? И не учитывается важный момент - мы стареем, один час времени в молодости никогда не будет равен целому дню в старости.
Если хочешь проверить на что способен админ - попроси его установить почтовый сервер "локально", но чтобы мог принимать и отправлять почту на "все" внешние (без SMTP relay). Проблем ... начиная от 25 порта у провайдера, не говоря уже об описанных в статье SPF + DKIM + DMARC, one-click отписка. Вплоть до того, что если твой IP из динамических диапазонов, то письма отклоняются. В целом мороки ... А вообще получилось gmail уговорить?
Наконец-то что-то адекватное. Сочетание максимального перфоманса на Си в месте где он нужен в библиотеках и максимального удобства и простоты в месте где перфоманс не нужен в виде python. Кто нибудь использует сочетание python+Си для разработки?
Если не учитывать, что набор необходимых умений и знаний как и само понятие профессионализма в любой сфере постоянно меняется, то и без ИИ потеряешь.
Вот бы по "индексу Хирша" можно было "проранжировать" языки программирования, чтобы это метрики влияния на отрасль в целом. Количество, к сожалению, не отражает качество.
Хм. Т.е. он «придумал» геометрическую конструкцию. Проще говоря он "в уме" понимает что центр координат (симметричная ситуация) сдвигается и приводит пример где вероятность стала подозрительно маленькой. Круто.
Ну мощностей для симуляции мира понадобится побольше чем для генерации видео. Если брать человека, то за "картину мира" у него отвечает мозжечок. Так вот, мозжечок человека, занимая всего 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 мало ответственности.
Отличная тема для статьи кстати.
"Интеграция функций искусственного интеллекта в сервисы" позволяет тех. директору, тимлиду и команде разработчиков поучиться интегрировать эти сервисы.
Банально - ни один «трюк» не сработает, если сам продукт не решает проблему пользователя, НО привлечение пользователей != удержание пользователей. Для "долгосрочного удержания пользователей" нужно решать долгосрочные проблемы пользователей.
Все бы хорошо, да вот только когда речь идет о перфомансе - примеры есть? Где микросекунды? Верить на слово?
Есть упоминание об инструменте - нет примера использования. С одной стороны какие-то уж очень общие знания, с другой - переключение на "углубленные" нюансы С++.