Как стать автором
Обновить
0
@Loferread⁠-⁠only

Software Dev .Net, BA, Solutions Architect, MCTS

Отправить сообщение
У вас свой какой-то мир. Откройте вики хотя бы для начала.

А зачем вики, если можно первоисточники глянуть и сравнить?
Intel готовится к релизу первых настольных процессоров с 7-нанометровой топологией. Их выпуск может состояться в 2022 г., и в них ожидается поддержка памяти DDR5 и интерфейса PCI-Express 4.0.

Intel CFO: “10nm isn’t going to be the best node that Intel has ever had”
2019 Investor Meeting: Intel Previews Design Innovation; 10nm CPU Ships in June; 7nm Product in 2021

и новости агуста-сентября 2018 г.
Компания AMD представила серверные 64-ядерные процессоры Epyc Rome на базе новой архитектуры Zen 2 с нормами технологического процесса 7 нм, и с новой многокристальной компоновкой Chiplet Design.
Уже в 2019 г. AMD намерена перевести все свои процессорные линейки на архитектуру Zen 2 с нормами 7 нм. Сейчас, по данным компании, уже начаты поставки первых образцов процессоров Epyc поколения Rome на базе этой архитектуры ключевым заказчикам.
All Of AMD's 7nm Processors To Be Manufactured At TSMC

Может у интел и AMD тоже свой мир? :)

О чем вы вообще говорите. Основное оборудование для литографии всем поставляет одна компания. Не может такого быть, что самсы сделали, а интел не смогли.

Насколько я помню, у AMD\Samsung\TSMC и Intel используются разные изоляторы в полупроводниках. Из-за этого Intel и наступила на «физические грабли» с токами утечки и тепловыделения и технологически уперлась в тупик. Техпроцесс включает не только литографию, но из состав полупроводников из-за присадок разные и это влияет на дизайн чипов.

Не получится обмануть физику и экономику.

Это глупость, ибо ограничения не физические\технические\интелектуальные.
То, что интел кормил мир своим 14нм — не технические трудности.

Это как раз экономические :) Не смогли они осилить следующий техпроцесс для своих процессоров, в то время как Samsung, TSMC, GlobalFoundries вполне смогли.
Полагаю Интел вполне знакомы с тем, что уменьшение размера чипа уменьшает себестоимость? Эти уж точно были бы рады такому пути.
Они просто решили, что раз у них нет конкуренции, то и делать ничего не надо.

А что серверное было предложеннии? неудачный бульдозер для отдельного класса задач которые оказались широко распространенными?
Это как шахматная партия. Они сдали атомы, потому что с армами на одинаковых техпроцессах они не шли ни в какое сравнение.

Когда делались и проектировались Atom вопросы «дешево и достаточно производительности» только появились, а Arm только только начали делать первые шаги на мобильных устройвах и планшетах (не серьезно считать «пошаговые стратегии» при открытии книжек или ICQ на КПК при разрешении 320х240). Не нужно сравнивать 10...5 лет назад и сейчас. Если так уж хочется — надо бы сравнивать Intel XScale с чем-то того-же временного отрезка. У AMD процессоры «AMD Opteron A» серии.
И раз вы затронули физику. То идите дальше и смотрите на фундаментальные физические ограничения. Конкретно, но просто.
Например закон сохранения энергии и прочее.

Спасибо, конечно, за подсказанное направление. Но в общем-то то известные проблемы — разрешение литографического оборудования (физика ?) и его цена (экономика?), цена производства кристалла и брак (экономика?), токи утечки (физика ?), нелинейное возрастание преобразование потребляемой электроэнергии в тепло при возрастании частоты (физика ?), теплоотвод от малой площади кристала (физика ?) ну и всякие побочные спецэффекты вроде подвижности зарядов и длинных линий при высоких частотах (физика?).
Пока никому не удалось этот клубок «распутать». Arm «решает» эти проблемы всякими big.LITTLE\DynamIQ что там насчет последних «ARM Cortex-X1» и «ARM Ethos-N..»? Наверное «Cortex-X Custom (CXC) program» ARM придумала от нечего делать?
Пусть какой-то редкий софт сейчас не запускается,

Это, безусловно, повод радоваться что не сможешь сделать свою работу нормально или результатами мало кто сможет воспользоваться?

но это не повод быть под гнетом монополии.

Да да… будет зоопарк как мобильных приложения. Каждый себе напихает «новый-пупер-модуль-который-делает-ЗБСЪ!» и под него заточат прикрутят пару-тройку приложений. Потом или будут писать приложения под «минимальный набор как у всех» и будут удивляться «А что за хрень ?!» или будут «ноубук для экселя» и «ноутбук для фотошопа» и «ноутбук для поиграться». Проходили уже такие вещи (математические сопроцессоры, GPU, крипто и векторые вычисления и т.д.) — добром это не кончилось, ибо получились «CPU, который может все, но хреновенько и жрет как не в себя» поскольку все хотят «все и сразу» не сильно напрягаясь и бесплатно.
Это как не менять президента какой-то гипотетической страны, ибо первое время будет хуже. И что теперь, всю жизнь страдать со старым маразматиком?

Можно страдать с новым «с расстройствами личности» :) Скучно, как со «старым», точно не будет :))) Так себе альтернатива.

Не получится обмануть физику и экономику.
— или быстро и дешево но нифига не универсально (спец модули\ускорители)
— или универсально дешево, но нифига не быстро — (cpu без наворотов)
— или быстро и универсально но нифига не дешево — (cpu c наворотами, модульные решение (CPU + GPU + ...), облака, суперкомпьютеры и т.д.)
Все оперативно сделают трансляторы-виртуализаторы, будут в процессе развертывания компилировать код под целевую платформу. На этом и закончится все.
врядли кто-то будет делать аппаратную модульную платформу, соединяющуюю достоинства всех — x86\x64 & ARM & GPU. Что-то вроде «мини cloud с разным железом и своим инстансом на каждом железе» в ноутбуке и коммуникациями между ними «по оптике».
«всего пары заварных пирожных» в день, это круто)))

Утром с кофе что-то нужно? обязательно вкусняшка найдется.
Обед? Ну конечно надо
Полдник? Ну как же чай без печеньки.
О! День рождения у кого-то. Всем кусочек тортика! Вот он повод «передохнуть»
Ужин? Ну пицца самое оно, тем более что устал как собака а тут «две по цене одной» сегодня, тем более я же кусочек скушаю всего от каждой.
Поскольку приходится работать головой, мозг потребляет глюкозу в промышленных масштабах, а тело начинет пытаться жрать быстрые углеводы.
Особенно если учесть офисную моду «а у нас бесплатные печеньки в офисе»
Целый день в офиса на митингах или коде без движения — и +3..4 кило в месяц.
… но сам процесс… :)
Резкий сброс веса, это стресс для организма человека.

Вес? скорее резкий дефицит калорий. Смените «сахар» на медленные углеводы и белок — удивитесь результатам через два недели.
А сбросу веса организм в виде системы кровообращения и опорно-двигательного только обрадуется :)

Диетологи рекомендуют сбрасывать 2-3 кг. в месяц.

Не знаю что и какие диетологи советуют для каких условий, но 4..5 кило сбрасывается даже без кардинальной смены питания с помощью упражений и отказа от «всего пары заварных пирожных» в день за месяц. Проблема в том что в магазине фиг найдешь что тебе нужно без всякой фигни ненужной — приходится самому себя готовить (что бы понимать что ты скушал) или искать максимально простые продукты. Например есть йогурт с 3 гр белка и 7..10 гр сахарозы или 8..16 грамм белка без сахарозы. Разница для организма весьма существенная.
Если чуть заморочится с готовкой и смотреть что «жрешь» — 15..20 кило за месяца 3..6 без проблем и без ощущения голода.
А если уже совсем заморочиться — то результаты могут быть более чем показательные.
Но тут крайне полезно будет присмотр, хотя бы на уровне анализов биохимии крови и минерального состава, иначе почки-печень-суставы покажут кто тут «главный» весьма быстро.
Когда вы думаете об автоматизации, облаке, микросервисах, вы думаете о DevOps.

Плакать хочется…
Разработка, тестирование и развертывание ПО происходят как в DevOps, так и в Agile. Тем не менее, чистый Agile подразумевает, что процесс останавливается после этих трех этапов.

В какого перепугу? Это гибкий процесс

Фидбэк от заказчика Фидбэк от себя

Карго культ — просто образец продуманности и глубины понимания.

На такое надо ставить значек «18+»
Вы частное переносите на общее.

Вот я посмотрю как вы в банк, на завод или государственное учереждение (безопастность) или критическую инфраструктуру будете неприрывно пушить код без проверки безопасников, депонирования кода и внутренней проверки или если, по соображениям безопастности, внутренняя инфраструктура клиента изолированна :)
Для себя я не вижу причин, для того, чтобы быстрее и хуже писать код в канбане.

Дело не в коде. Нюанс в стратегии — предсказуемость сроков или предсказуемость функционала.
Для скрама — недоделанную фичу просто исключат из релиза что бы уложиться в delivery. Для канбан — сдвинут срок delivery, но что бы были все запланированные фичи.
Чем дольше я работаю тем глубже убеждаюсь что все эти скрамы с канбанами не пригодны для технически сложных проектов, где месяцы если не годы могут уйти на выработку правильной методологии/архитектуры
А все эти скрамы с канбанами годятся только для типовых проектов

Если посмотреть на технические задачи «дизайн» «анализ» и т.д. как на задачи у которых заказчик «команда», то все вполне ложится в «скрамы-канбаны» поскольку «business value» в конце итерации это найденные решения, идентифицированные риски, «физика» базы данных\API\файла и т. д.
Будет не одна команда, а несколько из одного или нескольких человек. не большая проблема
ИМХО, пока заказчик не «потрогает продукт», он в принципе не может сказать, правильно его поняли или нет. :-)

Я Вас, наверное удивлю, но есть такая работа у менеджера проекта называется «управление ожиданиями». Из моего опыт если ты сажешь человека рядом и начинаешь с ним работать, показывая «что будет» и потом начинаешь «сделать как договорились» — таких проблем нет. Понятно что это не в первую неделю доверие (но эт уже психология), но через месяц сравнивая «мы оговорили» и «я могу потрогать» — 8 и 10 впечатляются и довольны (понимают свой профит в виде экономии времени и оправданных ожиданий), а 2 из 10 сначала пытаются «биться в истерике» (по раздолбайски отнеслись к предоставлению данных), но получив по «наглой рыжей морде» резко становятся «смирными» и чудесным образом у них наступает «прояснение в мозгах», пропадает «склероз» и наступают прочие «улучшения»

P.S.Не вижу смысла самому себе создавать трудности, а потом мужественно их преодолевать оправдывая свое раздолбайство.
Я хочу попить пиво, повялаться на пляжике, позниматься в зале и погонять на вело, а не сидеть в офисе с головой «набитой опилками» или устраивать разборки и митинги по телефону по ночам.
Со стороны может эта романтика впечатляет «рвать на груди рубаху бросаясь в жестокий бой», но как по мне — это некомпетентность и безграмотность:)

Прототип и его изменения — это и есть фиксация ожиданий клиента.
Точнее это одна их стадий итеративного процесса разработки.

Вроде бы «процесс» и «результат» это несколько разные вещи.
Дизайн, в процессе может изменяться, да и как вообще цель приложения.
Соответственно должна быть и изменена архитектура.

Значит открываем «бумажку» и вычеркиваем не нужное, «рисуем нужное», сравниваем — получаем вменяемое объективное обоснование для оценки «сколько будет стоить».
Т.к. заказчик может и не знать «чего он хочет».
Точнее он знает, что «хочет зашибись».

И как это противоречит «давайте обсудим и зафиксируем»? Т.е вместо того что бы за минут 10 зарисовать форму редактирвание позиции справочника или записать список полей для отчета, вы будете 8 часов ее ваять, потом разворачивать, потом сажать клиента рядом и тыкая пальцем в экран спрашивать каких полей не хватает, на ходу их добавляя и перезапуская код? Вы серьезно? :) А если нужно мнение 5 человек вы будете каждого сажать рядом с собой, потом бегать за каждым и говорить «А Джон сказал что не надо, а Смит сказал что обязательно нужно!» пытаясь 5-ть мнений привести к согласованному состоянию? Потом ходить и до каждого в команде доводить новинку объясняя «почему так»? А потом кто-то задаст Вопрос «Так это же противоречит тому что было 2 недели назад...»
Если этот процесс оплачивается за счет клиента — это шикарная бизнес модель :)
Тут думаю важно понимать что разрабатываем, если лендинг или интернет магазин — то действительно на кой нам детальная спецификация проекта.

Юристы объяснят, когда когда клиент с серьезным выражением лица скажет «нифига не работет, я не то хотел и меня не так поняли и платить пока не переделаете не буду». А в суде выяснится, что предмета договора нет, как и критериев приемки. Но это не тот случай.
И уже на реально работающем приложении узнать что нравиться заказчику, а что нет.

Оплачивать удовлетворения любопытство заказчика будете из своего кармана?
При этом стоимость абстрактного моделирования и/или «сбора данных» не сильно дешевле, чем написание прототипа. :-)

За чей счет банкет? Если за счет исполнителя — одно дело. Если за счет заказчика с почасовой оплатой (без учета результата) — другое дело :)
Самое забавное, что и после прототипа вы обязаны будете заняться фискацией ожиданий и требований клиента, заняться передачей знаний другим участника проекта, заняться отслеживанием последствий «а вот тут давайте сделаем так...» и т.д. Экономия дизайна выльется в оплату QA, оплату разработчиков, выяснения «а как надо было», только не в начале проекта\итерации а в конце, и задействовано будет не пару человек а десяток другой и все это надо будет еще координировать.
Стоимость дизайна (BA и архитектура) порядка 5.10% бюджета времени проекта. Это не безумные деньги и не дофига времени.
При этом не требуется в начале пол года сбора требований, потом пол года на написание спецификаций, чтобы за пару месяцев программисты в мыле не выкатили коричневую субстанцию, которая никому не нужна. :-)

Что пол года не требуется — согласен.
Что пол года не требуется — не согласен.
На этапе сбора формализация требований(ожиданий ?) позволяет найти проблемы и слабые места без написания кода, что сказывается на ожиданиях «А когда будет MVP и что от него ожидать?» и «А сколько это будет стоить и за чей счет банкет ?»

При этом понятие «релиз» нет. Есть понятие «развитие».

Да да… Все это ровно до первого счета «за работу» и вопроса «Остап Ибрагимович, а когда мы будем делить наши деньги ?» Вы, наверное, никогда не отчитывались инвестору еженедельно «что мы сделали и нафига...»? :)
Грубо говоря, сейчас проще сделать MVP и допилить, до нужного состояния.
Чем построить в начале модель, по которой будет создано ПО.
Все что сложнее простого рисунка на салфетке, будет дичайшим оверхедом.

А давайте посчитаем стоимости? Стоимость дизайна, стоимость имплементации, стоимость тестирования, стоимость передачи знаний. причем давайте распишем отдельно по статьям — сколько ушло на митинги, сколько ушло «объяснить на пальцах», сколько ушло объяснить тестерам, сколько ушло пофиксить «ну это же очевидно». Причем эти расходы растут далеко не пропорционально и чем дальше тем хуже. Были возможности детально сравнить бюджеты весьма сходных проектов длительностью более года сделанные с разными подходами «Че там делать? фигня вопрос» и «А давайте посмотрим внимательно что мы будем делать и как ?».
Сколько раз было: получаешь легаси код — и месяц-другой разгребаешься «а что это такое ?», потом месяца 3..6 отлавливаешь «с какого ^%@!# перестало работать ?!»
Сколько раз было — приходит новый человек и раньше чем через масяц… два его нельзя в код пускать, потому что «объяснять некому, а Вася которых это делал сейчас в отпуске..»
Лично видел системы — забыли договориться о… форматах даты, о кодировке, о генерации ошибок, о мультиязычности и т.д. и это после полутора лет разработки!
Ну а че? MVP работает же, а заказчик в шоке «как все переписать и через пол года релиз, если я уже завершил переговоры с клиентом о покупке?!»
Это все прикольно, если оплачиваешь не из своего кармана, через год планируешь увольняться «с этой галеры» и т.д.
Это прикольно, если хочешь на себя все «завязать» «А кто меня уволит, если никто не знает кроме меня, как ЭТО работает ?!» и т.д.
И сравните с передачей клиенту для приемки после третьего тестового прогона у QA и прохождения с первого раза UAT продукта который разрабатывался порядка 8 месяцев, а вновь нанятые люди, посмотрев «веселы картинки» через неделю в проект добавляли свой код никого не отвлекая вопросами, кроме «А почему именно такое решение и дизайн выбрали ?»
7.7.4 Notation
A Dependency is shown as a dashed arrow between two model Elements. The model Element at the tail of the arrow (the client) depends on the model Element at the arrowhead (the supplier). The arrow may be labeled with an optional keyword or stereotype and an optional name (see Figure 7.18).

A Connector is drawn using similar notation to that for Association (see 11.5.4). The optional name string of the
Connector obeys the following syntax:
::= ( [ ] ’:’ ) | ([ ] ’:’ ) | [ ]
where is the name of the Connector, and or is the name of the Association or AssociationClass, respectively, that is its type. A stereotype keyword within guillemets may be placed above or in front of the Connector name.

A number of UML standard stereotypes exist that apply to Component. For example, «Subsystem» to model large-scale Components, and «Specification» and «Realization» to model Components with distinct specification and realization definitions, where one specification may have multiple realizations (see the Standard Profiles).


К примеру… Лишь бы хватило фантазии.
UML состоит из множества диаграмм. Каждая из которых подчиняется своим правилам, использует элементы и стрелки в своем понимании. И со стороны выглядит это не как унифицированный язык, а как набор из различных представлений, который часто преподносится как возможность посмотреть на предметную область с различных точек зрения.

Не совсем так. UML предлагает «нотации по умолчанию», но так так же сказано «Вы можете определеять свои нотации для UML диаграмм. Только опубликуйте глоссарий, что бы ваши картинки могли понимать другие».
Так что никто не запрещает сделать свои диаграммы UML в нужном представлении.
А если учесть, что инструменты по разному могут разрешать рисовать диграммы, то эта возможность и так используется.
Ну так классика:
Но другая группа ... нашла ... фатальный недостаток – его писали не они!

Ничего не поменялось
Опыт, безусловно, поучительный. Мотивация была «научиться делать» или «сделать продукт»?
Кто все это оплачивал? Если «сделать продукт» то, как планировалось выход на окупаемость?

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность