Олигархия - частный случай. Она не во всех государствах. Это ничего не меняет. В любом случае, правящий класс будет ограничивать и контролировать все технологии, в том числе и ИИ, для использования в своих целях.
Криптография (PGP в том числе), и в нашей стране в частности - ограничивается. Защищенные мессенжеры - ограничиваются. Блокчейн - ограничивается, делаются попытки приспособить ее (технологию) в своих целях, в частности - электронный рубль (можно поразмышлять, с какой целью). Видеостриминг - ограничивался в нашей стране буквально на днях.
Высококачественный автоматический машинный перевод и не достигнут. Переведите пожалуйста Шекспира и мы сравним его с переводом Пастернака, Маршака или Щепкиной-Куперник.
Имеется в виду, что АГИ будет ограничен правящим классом и гарантированно будет использоваться в своих интересах. Правящий класс успешно влияет на технологический ландшафт, технологии и их применение.
И что теперь, когда большой каскад вызовов методов, и каждый возвращает свой тип ошибки, как пробрасывать ошибку из глубины на самый верх, где она будет обработана? Чем это отличается от простого возврата составного класса Result, где одно поле - это нужный результат работы метода, а второе поле - класс ошибки, который должен возвращать этот метод? Теперь вызывающий метод, который вызывает методы трех разных классов, должен парсить все их результаты, смотреть, нет ли там ошибки, и если есть, делать new своего класса ошибки, упаковывать туда возвращенную ошибку и это значение return? А более высокий метод должен делать то-же самое? Спасибо. В свое время, исключения создавались, чтобы этого избежать.
Мы так и в Java делали - с возвращением кодов и сообщений ошибок.
Плохо понятно, чем это лучше exception handling, кроме разве что использования в функциональщине.
Не надо воровать. Надо свое разрабатывать. В свое время во времена Хрущева, вместо того, чтобы разрабатывать свои процессоры, мы начали воровать схемы чужих процессоров. Это привело к уничтожению своей школы со всем вытекающим.
То, что ушли западные вендоры - это шанс развить свою отрасль, и надо этот шанс использовать по максимуму.
Очень пафосная и непонятная статья (к переводчиками без претензий). Очень много слов и крайне мало информации. Интересное мышление все-таки у англоязычных.
Тут когда-то была статья, как американцы во время второй мировой войны клепали эсминцы, для борьбы с подводными лодками. Десятками, если не вру. И требования, чертежи соответственно, менялись каждую неделю. Думается, можно изучить данный опыт и что-то применить и в девелопинге.
А мне вот интересно. Если на рынке наличествует пять тысяч кандидатов, то вы всем пяти тысячам отправляете предложение написать прогу, и все пять тысяч смотрите репы по полчаса? Так конечно, "трата ресурсов на проверку решений".
У меня такое ощущение, что всем айтишникам надо поработать в промышленности. Такую смешную ахинею пишут про нормирование трудоемкости. Желательно бы еще всем айтишникам окончить ВУЗ, простой машиностроительный или строительный (лучше да, строительный) ВУЗ.
В промышленности "оценка" называется "Нормирование трудоемкости".
Нормирование (это в принцице) возможно только:
Для одинаковых операций. Точнее, для тех, которые в принципе известны.
Для тех операций, которые когда-либо делались.
Только для того изделия, которое имеет проект. Имеются чертежи со всеми составляющими. Вплоть до последней детали.
Имеются набор продуманных операций для каждой детали.
Все операции известны, когда-либо делались, записывалась трудоемкость этой операции. А также сложность, размеры, вес детали и так далее, все факторы, влияющие на трудоемкость. Пример - длина сварного шва, размер катета.
Чтобы нормально просчитать трудоемкость, нужно следующее.
Нужен детальный проект. Не "мечта" менеджера, бгг. "Мечта менеджера" в промышленности - это техническое задание на самом-самом начале, текстовка с описанием. Должен быть проект, "чертежи". По которым исполнитель может наваять программу. Вообще любой исполнитель-программист, знающий язык программирования и нужные технологии. Знание бухгалтерии или еще каких предметных областей - совершенно будет не нужно, что требуется сейчас от экспертов-сеньеоров. Кстати, и для контроля такой проект нужен - чтобы по проекту любая девочка-контролер могла протестировать.
Затем нужен отдел нормировщиков - специально обученные люди, которые по проекту, имея справочники, свои тетради и прочие материалы, зная, какие "детали" проекта и какой они сложности, могут по своим таблицам определить, сколько будет трудоемкость изготовления данного компонента/детали. Это "НЕ НОРМА!", когда менеджер или исполнитель, определяет, какая трудоемкость определенного компонента.
В ИТ, в отличии от двухсотлетней системы в промышленности, действует модель стартапа (гаража, узбекской бригады плиточников).
Заказчик хочет сделать продукт. Он имеет "мечту".
Сколачивает брагада стартапа из десятка узбеков программистов. Они читают хотелки и прикидывают, сколько у них займет времени каждый элемент работы.
Озвучивают заказчику.
Заказчик чешет репу, и либо, соглашается, либо бежит дальше по рынку.
Бригада начинает ишачить.
Если ребята выполняют работу в срок - им оплачивают работу, они ищут нового лоха заказчика.
Если не успевают - либо увеличивают сроки, без увеличения оплаты и работают себе в минус. Либо выциганивают увеличение сроков и бюджета. Можно повторить. Проваливают проект, стартап банкротится, разрабы разбегаются. Заказчик терпит убытки.
Перейти к п.1.
Вся нынешняя система "определения трудоемкости" - гадание на кофейной гуще, ваша "система" - тоже самое, и предполагает либо угадывание и получение прибыли, либо неугадывание и банкротство вашей шараги с последующим выкупом команды в следующую шарагу.
Сколько я таких "систем" видел - все чепуха, потому что никто не понимал необходимых условий, которые я привел вверху. Все - разные системы гадания.
Олигархия - частный случай. Она не во всех государствах. Это ничего не меняет. В любом случае, правящий класс будет ограничивать и контролировать все технологии, в том числе и ИИ, для использования в своих целях.
Криптография (PGP в том числе), и в нашей стране в частности - ограничивается. Защищенные мессенжеры - ограничиваются. Блокчейн - ограничивается, делаются попытки приспособить ее (технологию) в своих целях, в частности - электронный рубль (можно поразмышлять, с какой целью). Видеостриминг - ограничивался в нашей стране буквально на днях.
Почему во всем мире? Олигархи, и правящие классы, каждые в своей стране.
Подавление (если не уничтожение) отечественной электроники и процессоростроения во время перестройки и перехода к рынку.
Высококачественный автоматический машинный перевод и не достигнут. Переведите пожалуйста Шекспира и мы сравним его с переводом Пастернака, Маршака или Щепкиной-Куперник.
Имеется в виду, что АГИ будет ограничен правящим классом и гарантированно будет использоваться в своих интересах. Правящий класс успешно влияет на технологический ландшафт, технологии и их применение.
Как справляется с барьером бесконечного выбора люди?
И что теперь, когда большой каскад вызовов методов, и каждый возвращает свой тип ошибки, как пробрасывать ошибку из глубины на самый верх, где она будет обработана? Чем это отличается от простого возврата составного класса Result, где одно поле - это нужный результат работы метода, а второе поле - класс ошибки, который должен возвращать этот метод? Теперь вызывающий метод, который вызывает методы трех разных классов, должен парсить все их результаты, смотреть, нет ли там ошибки, и если есть, делать new своего класса ошибки, упаковывать туда возвращенную ошибку и это значение return? А более высокий метод должен делать то-же самое? Спасибо. В свое время, исключения создавались, чтобы этого избежать.
Мы так и в Java делали - с возвращением кодов и сообщений ошибок.
Плохо понятно, чем это лучше exception handling, кроме разве что использования в функциональщине.
Как я понимаю, реализован механизм, при котором купленная IDE может по желанию левой пятки JB превратиться в тыкву.
Не надо воровать. Надо свое разрабатывать. В свое время во времена Хрущева, вместо того, чтобы разрабатывать свои процессоры, мы начали воровать схемы чужих процессоров. Это привело к уничтожению своей школы со всем вытекающим.
То, что ушли западные вендоры - это шанс развить свою отрасль, и надо этот шанс использовать по максимуму.
Есть мнение, что они не работают там, где живут, а живут там, где работают.
Конструктивно - у дрона шесть лап, шесть винтов и шесть двигателей. Предложите, как это все скомпоновать?
Где они столько генерирующих мощностей взяли? Разве что на бывших заводах есть подсоединения.
Достаточно будет ловить exception и возвращать 500?
Очень пафосная и непонятная статья (к переводчиками без претензий). Очень много слов и крайне мало информации. Интересное мышление все-таки у англоязычных.
А если не ртуть использовать, а какой-то другой жидкий металл, который не дает ядовитых испарений? И вообще не испаряется, чтобы вакуум был поглубже?
Тут когда-то была статья, как американцы во время второй мировой войны клепали эсминцы, для борьбы с подводными лодками. Десятками, если не вру. И требования, чертежи соответственно, менялись каждую неделю. Думается, можно изучить данный опыт и что-то применить и в девелопинге.
А мне вот интересно. Если на рынке наличествует пять тысяч кандидатов, то вы всем пяти тысячам отправляете предложение написать прогу, и все пять тысяч смотрите репы по полчаса? Так конечно, "трата ресурсов на проверку решений".
У меня такое ощущение, что всем айтишникам надо поработать в промышленности. Такую смешную ахинею пишут про нормирование трудоемкости. Желательно бы еще всем айтишникам окончить ВУЗ, простой машиностроительный или строительный (лучше да, строительный) ВУЗ.
В промышленности "оценка" называется "Нормирование трудоемкости".
Нормирование (это в принцице) возможно только:
Для одинаковых операций. Точнее, для тех, которые в принципе известны.
Для тех операций, которые когда-либо делались.
Только для того изделия, которое имеет проект. Имеются чертежи со всеми составляющими. Вплоть до последней детали.
Имеются набор продуманных операций для каждой детали.
Все операции известны, когда-либо делались, записывалась трудоемкость этой операции. А также сложность, размеры, вес детали и так далее, все факторы, влияющие на трудоемкость. Пример - длина сварного шва, размер катета.
Чтобы нормально просчитать трудоемкость, нужно следующее.
Нужен детальный проект. Не "мечта" менеджера, бгг. "Мечта менеджера" в промышленности - это техническое задание на самом-самом начале, текстовка с описанием. Должен быть проект, "чертежи". По которым исполнитель может наваять программу. Вообще любой исполнитель-программист, знающий язык программирования и нужные технологии. Знание бухгалтерии или еще каких предметных областей - совершенно будет не нужно, что требуется сейчас от экспертов-сеньеоров. Кстати, и для контроля такой проект нужен - чтобы по проекту любая девочка-контролер могла протестировать.
Затем нужен отдел нормировщиков - специально обученные люди, которые по проекту, имея справочники, свои тетради и прочие материалы, зная, какие "детали" проекта и какой они сложности, могут по своим таблицам определить, сколько будет трудоемкость изготовления данного компонента/детали. Это "НЕ НОРМА!", когда менеджер или исполнитель, определяет, какая трудоемкость определенного компонента.
В ИТ, в отличии от двухсотлетней системы в промышленности, действует модель стартапа (гаража, узбекской бригады плиточников).
Заказчик хочет сделать продукт. Он имеет "мечту".
Сколачивает брагада стартапа из десятка
узбековпрограммистов. Они читают хотелки и прикидывают, сколько у них займет времени каждый элемент работы.Озвучивают заказчику.
Заказчик чешет репу, и либо, соглашается, либо бежит дальше по рынку.
Бригада начинает ишачить.
Если ребята выполняют работу в срок - им оплачивают работу, они ищут нового
лохазаказчика.Если не успевают - либо увеличивают сроки, без увеличения оплаты и работают себе в минус. Либо выциганивают увеличение сроков и бюджета. Можно повторить. Проваливают проект, стартап банкротится, разрабы разбегаются. Заказчик терпит убытки.
Перейти к п.1.
Вся нынешняя система "определения трудоемкости" - гадание на кофейной гуще, ваша "система" - тоже самое, и предполагает либо угадывание и получение прибыли, либо неугадывание и банкротство вашей шараги с последующим выкупом команды в следующую шарагу.
Сколько я таких "систем" видел - все чепуха, потому что никто не понимал необходимых условий, которые я привел вверху. Все - разные системы гадания.
Текстом бы