Pull to refresh
122
0
Андрей Неволин @TechThink

User

Send message

А можете привести 1-2 примера ваших удачных запросов к GPT? Интересно посмотреть, в чем именно модель оказалась полезной, а также как именно люди формулируют свои запросы к ней

Спасибо за отклик!

Под "зоной ответственности" я понимаю то, что должна делать компонента. Подробный пример потребовал бы много времени. Однако в одном из запланированных постов, на тему технического долга, будет такой пример.

В документации я прямым текстом пишу, что решение подразумевает создание новых компонент, у каждой из них будет такая-то зона ответственности. Дополнительно отражаю эту ответственность в названиях компонент, чтобы сразу было понятно, чем они должны заниматься, а чем - нет.

По моему опыту, не-архитекторы не очень хорошо справляются с назначением зон ответственности. Тому я вижу несколько причин:
1) у разработчиков и менджеров по разработке меньше кругозор. Они могут не учитывать полной картины. И это вполне понятно, потому что им, в основном, приходится концентрироваться на собственных компонентах либо на ближайших соседях
2) разработчики и менеджеры часто стремятся максимально сосредоточить разработку в подконтрольных им компонентах. Потому что это понятнее и быстрее позволяет прийти к результату
3) сейчас все больше менеджеров и разработчиков (хотя и не все, конечно же) стремятся прийти к результату по кратчайшему пути, чтобы побольше медалей получить на погоны в конце года. Долгосрочное развитие часто не принимается во внимание, потому что народ все меньше работает на одном месте. Одна из частых мыслей во время принятия неоптимальных решений: "Меня через два года уже не будет в этой компании". Впрочем, "кратчайший путь" - это часто иллюзия... Срезая неправильные углы, люди часто огребают по полной. И вместо пары месяцев идут в продакшн полтора года (и у меня есть реальные примеры).

Вспомнил о тех продуктах, над которыми сам работал. Я бы сказал, что ничего, за исключением того, что очевидные лишние пункты уйдут. Но от специфики конректного бизнеса могут меняться акценты, либо исчезать/добавляться новые проблемы. Из своего опыта могу вспомнить проекты, которые предполагали активный вклад в Open Source или программно-аппаратный co-design (или даже и то, и другое сразу). Конкретно для этих случаев мой список был бы немного другим, но по большей части все равно остался бы тем же.

Спасибо за интерес!

Для документирования: Confluence, Microsoft Word. Однако лучшая документация должна жить в самом коде или каким-либо образом автоматически строиться на "живых" системах. Возможно, напишу как-нибудь об этом.

Конкретно для рисования диаграмм предпочитаю Draw.io (это визуальный редактор, очень шустрый) и PlantUML (генерирует sequence-диаграммы по текстовому описанию; очень удобно, если необходимо сравнивать разные ревизии диаграмм между собой, потому что текст сравнивать проще, чем картинки). Еще могу порекомендовать Enterprise Architect. Но это уже не просто рисовалка диаграмм. Это целый фрейморк для проективания систем и решений Enterprise-уровня. Там очень богатый функционал

Подумаю над этим, но обещать такой пост пока не могу. Скажу честно: пока что не знаю, как писать на тему аджайла. Абстрактные принципы там просты, и они уже много где разобраны со всех сторон. Интересно именно разобрать как они реализуются в контексте конкретного бизнеса. Потому что у каждого бизнеса свои собственные препятствия на пути к реализации аджайла. Проблема в том, что анализировать конкретные бизнесы публично обычно нельзя...

Ох... То, как ведется разработка solutions-архитектуры в условиях Agile - это большой и непростой вопрос. Развернутый ответ с примерами потребовал бы отдельного большого поста. Давайте, я отвечу общо: если бизнес большой и сложный, и в продукт/решение вовлечено множество программных компонент, то все перечисленные в посте вопросы придется решать независимо от того, какая методология разработки используется в компании.

Поэтому, если коротко, то да, чек-лист актуален для Agile. И даже не зависит от конкретной методологии разработки. Методология будет влиять только на то, как именно вы идете от идеи к реализации.

Да, к сожалению, наш контроль над нашими же смартфонами далек от полного… И пользовательские соглашения для приложений все больше напоминают историю: «соглашайтесь на всё или никакого сервиса не получите».
Внешних карт памяти у меня нет. Все, что я сделал после покупки нового телефона, — это вошел с него в аккаунт Google и воспользовался функцией восстановления приложений. Контакты и настройки приложений — это единственно, что у меня бэкапится в облако. Все остальные бэкапы (в том числе и на уровне приложений) запрещены.
Думаю, работа «в склад» действительно может случаться на некоторых производствах при определенной конъюнктуре. Там, где остановка производственных мощностей очень дорого обходится. Например, остановка (и обратный запуск) нефтяной скважины — дело очень затратное.
Поэтому если в краткосрочном периоде цена уходит ниже себестоимости, возможно, есть смысл поработать в хранилище.
Но в большинстве случаев такого, конечно, не бывает.
С DRAM как раз ситуация обратная. В этом году цены практически на все компы выросли из-за недостатка памяти на рынке. Производители памяти знали о ситуации, но предпочли не инвестировать в дополнительное производство. Вместо этого взвинтили цены. Отсюда и подорожание всего остального, в чем есть память. Но это длинная история. Там много интересных моментов. Вот для затравочки:
http://www.dramexchange.com/WeeklyResearch/Post/2/4563.html
http://www.dramexchange.com/WeeklyResearch/Post/2/4618.html
О! Кажется, у меня наступило просветление. Мы с вами ужинали в SLC вместе с нашим общим другом Джоном Бентом
Если не секрет, что делали для Люстры? И что за система для exascale?
Кстати, откуда знаете про DAOS?
Вы занимаетесь системами хранения?
По-моему, это мертвая тема.
Хотя, несомненно, заслуженная :)
DAOS использовался в самой первой реализации Burst Buffer'ов совместно с EMC и HDF Group в 2012 году. Эту работу проспонсировал американский Department of Energy.

Насколько мне известно, до продуктизации DAOS дело никогда не доходило. Только экспериментальные наработки…

Спасибо, что вспомнили о нем!
Cluster Studio сейчас называется «Parallel Studio XE Cluster Edition»
Верно, этот вопрос я не рассмотрел.
Пока я не вижу широкого использования FPGA или ASIC в HPC. И у меня, к сожалению, нет пока интуиции в этом вопросе.
Хотя, вроде бы, для некоторых направлений HPC FPGA могут быть полезны. Например, в геномике. Вот, например, контора, которая пошла дальше FPGA и предлагает ASIC'и для стандартных геномных алгоритмов: http://www.edicogenome.com/dragen_bioit_platform/
Однако мне неизвестно, насколько хорошо у них идут дела.
Как думаете, какой будет стратегия Интела (и других игроков) в отношении FPGA? И как вся тема будет развиваться?
Тут комментарий по почте прислали. Скопирую-ка я его сюда. Далеко не со всеми моментами согласен. Но это это мнение. И пусть оно будет здесь.

«Майкрософт воспринимает в качестве угрозы именно опен-сорсные операционные системы, а не пиратов. Выходя на российский рынок, компания не сильно заботилась о нарушении своих прав — главным было выдавить с рынка производителей отечественных операционных систем. В то время у нас даже компьютера не было, но существовали российские ОС, лучшие по функциональности, и Майкрософт их выдавил. Компания большая и может пережить небольшую потерю выручки. Главное для них было „подсадить“ пользователя на свой продукт. Когда все дома стали использовать виндоуз, когда предприятия стали использовать виндоуз, когда не осталось конкурентов — тут и начались рейды (в 2000-х). Теперь угроза исходит со стороны свободных ОС, но пользователи крепко „сидят“ на Виндоуз: есть программные пакеты, форматы данных и т.п. В документе, созданном на Либре-офис, например, плывёт форматирование, если его открывать Вордом. Это означает, что ты не можешь обмениваться документами — у большинства ведь Виндоуз. Этот барьер по-научному формулируется как „сетевой эффект“: с каждым новым участников сети возрастает ценность продукты для уже присоединившихся. Так что реальный пример для твоей гипотетической ситуации существует, и бесплатный продукт является в чистом виде агрессией по отношению к конкуренту. Совсем как в заголовке статьи, на которую ты сослался»
А как решается проблема недобросовестной конкуренции?

Вообще говоря, никак. Конкуренция здесь была бы вполне добросовестной. И компания готова на нее пойти.

Во-первых, ее продукт почти не продается. Поэтому борьба идет хоть за какой-то шанс.
Во-вторых, сторонним компаниям не так-то просто будет войти на рынок (если раньше они на нем играли). Потому что для этого нужны ресурсы, каналы продаж и пр.
В-третьих, основная экспертиза относительно продукта все равно остается на стороне той компании, которая его создала. Это дополнительное преимущество.

И еще один момент… Мне пока неизвестно, может ли такая модель приводить к успеху. Я вижу, что ее пытаются использовать, но суперрезультатов еще нет. Хотелось бы узнать какие-то еще примеры, помимо тех, которые мне уже известны. Чтобы расширить круг наблюдения. Надеялся, что публика подскажет :)

Ну и небольшой пример, чтобы проиллюстрировать, как это могло бы работать.
Yahoo! является основным разработчиком Хадупа. Но коммерциализирует его (через отдельно созданный стартап) наравне со многими другими игроками. Здесь надо иметь в виду, что модель здесь все-таки другая, отличная от сценария "освежения тухлого продукта". Хадуп изначально разрабатывался как Open source.
Это уже слишком общО.
Если говорить о сегодняшнем дне, то сейчас у нас экономика не плановая. И «лишний» проект никто душить не будет из-за соображений «денег есть только на один». Нашел деньги — делай, прорывайся на рынок (или даже в оборонку). В этом смысле, никто не мешает создавать в России нормальную конкурентную среду, с нормальными деловыми отношениями. (Если совсем начистоту, то мешают. Но если на этом постоянно зацикливаться, то уж точно ничего не получится).

Information

Rating
Does not participate
Registered
Activity