Вроде как идея и заключается в том, чтобы запустить ракету в полет с помощью центрифуги, а потом уже включить двигатели. По сути идея в замене первой ступени ракеты на центрифугу.
Уже есть такой стартап SpinLaunch, который с помощью центрифуги раскручивает ракету и потом запускает ее в космос. Но пока результатов не сильно много. Но рабочие прототипы есть и ведутся исследования.
"Доступны для пробного использования разработчиками в Chrome и Edge 139", сейчас актуальная версия 137, или ставить экспериментальную сборку или ждать еще месяц-другой.
Тогда Тим Стокли заведет AIFans, где будет создаваться куча контента по сути в прямом эфире с помощью тысяч видеокарт, и тогда он будет платить только налоги и за электричество.
Классно, если есть навык работать в консоли. Так как я фронтендер, то приходится мышкой тыкать в экран, чтобы все проверять и перепроверять по 100 раз, поэтому 100% vim головного мозга не смогу получить. Но в один момент заметил, что VS Code делает кучу лишних вещей при переходе между ветками git. Мне это дело не понравилось, начал пользоваться консолью для гита. А чуть позже открыл для себя мир git alias и теперь популярные команды пишу еще короче. Теперь вместо `git checkout master` пишу `git cm`.
А почему бы не добавить обратную связь на HR-ов и рекрутинг. Много где есть оценка текущего места работы, но почему я не могу дать обратную связь по компании, которая меня хочет нанять. Можно также выработать важные критерии: хорошо ли описана вакансия, дали обратную связь, заспамили, все ли подробно объяснили и т.д.
Возможно, при таком подходе и со стороны нанимателей будут какие-то бест-практис. Потому что есть миллион статей "как написать красивое резюме", но сильно меньше "как граммотно нанять кандидата".
Будет своего рода социальный рейтинг, если компания хочет развиваться, то и свой найм будет дотягивать до оценки 5.0, а если это будет совковая колхозная шарага, то это будет видно заранее.
Сейчас много различных телефонных ассистентов, они должны тогда научиться блокировать разговор по словам и фразам "майор ФСБ", "центробанк", "безопасный счет")
Нейросети хорошо подходят для того, чтобы преобразовывать одну текстовую структуру в другую.
Проверял насколько можно позволить нейронкам документацию на своем профиле в github. Загрузил в deepseek 9 скриншотов таблицы статистики (потому что не было API), он успешно распознал табличные данные, по моей просьбе просуммировал все и построил график в mermaid раз 5-6 (не нравились диапазоны и я просил другие).
Также делал библиотеку из одного компонента, решил "написать" документацию. Поместил код в нейронку, на выходе получил readme.md, минут за 5 почистил от воды и получил счастье.
Так как я разработчик, то в своих проектах я сперва пишу код, потом документацию. Хотя и на работе также. Есть верхнеуровневая документация, которая описывает поведение приложения, а я как разработчик уже сам декомпозирую постановку и создаю внутренние библиотеки с документацией.
Будь я аналитиком, то скорее всего сперва генерировал бы документацию, а потом уже кто-то генерировал код по нему.
На счет дейликов (из урока №3), на которых подсвечивают риски и проблемы. Они для этого и нужны, так как понять в каком статусе задача можно и смотря на доску в Jira или на доске со стикерами. Если там написано inProgress, значит я ее делаю и есть ли смысл спрашивать об этом - не понятно, оно же видно. Там же видно и то, что я делал вчера и то, что буду делать дальше (потому что у задач есть приоритет и надо брать самую приоритетную).
А вот если я оценили задачу в 2 дня, а делаю ее неделю - вот тут стоит спросить, что пошло не так. Или если я вижу затык по проблеме - я должен уточнить у кого-нибудь на дейли, если не сделал этого раньше.
Интересная статья. Недавно начал активно использовать ИИ-асистенотов и mermaid, понял, что они не плохо подходят для генерации документации к коду, а также для перевода одной текстовой структуры в другую.
Решил ради интереса и тренировки оформить свой github-профиль, использовал mermaid и deep-seek. Скинул 10 скриншотов статистики в deep-seek, с помощью него распознал табличные данные, попросил посчитать и построить график. Аналогично другие структуры в профиле заводил в различные графики mermaid.
Также пару раз генерировал код для простых библиотек, закидывал код в ИИ и просил написать readme-файл, получалось неплохо. Потом минут за 5 вычищал лишнюю воду и вуаля.
Почему программисты не пишущие документацию не начали использовать ИИ и mermaid+markdown для быстрого и легкого написания документации - не понятно) Ревью текста займет явно меньше времени, чем написать все с нуля.
Микросервисы могут решить когнитивную нагрузку разработчиков, ценой когнитивной нагрузки других разработчиков (кто будет объединять микросервисы в приложение выполняющее бизнес-фичу) и девопсов.
Я из мира фронтенда, у нас вместо микросервисов есть микрофронты (по факту микросервисы). Часто слышу, а давайте начнем делать микрофронты, но только это потребует кучи времени настроек CI, особого мышления, так как сильно изменится способ взаимодействия с микрофронтом против обычного компонента. За 1,5 года на последнем проекте я смог выделить для себя только один микрофронт, который бы привел к уменьшению кванта развертывания, так как есть два приложения с разным релизным циклом, в которых надо одновременно зарелизить один и тот же компонент.
Я для себя выделил две эвристики того, как различать( Coupling связанность) и (Cohesion связность).
Первое. Отталкиваюсь от слов цена и ценность. Цена (связанность) - что мы платим, за используемые технологии и ограничения, которые накладываем на код. Ценность (связность) - что мы получим для бизнеса.
Второе. Связанность - это объединение кода библиотеками и фреймворками. А связность - это объединение бизнес-логикой.
Оба определения не идеальны, но как минимум толкают в нужном направлении.
Сделаешь много атомарных микросервисов, потом придется строить оркестратор. Сделаешь более жирные сервисы, придется мириться с другими ограничениями или проблемами. Вся архитектура сводится к тому, что у каждого проекта свои задачи и свои ограничения и как лучше написать - черт его знает, потому что нет серебрянной пули.
Если все сводится в итоге к тому, чтобы сделать из бэкендеров фуллстеков, то что мешает сделать наоборот. Берем фронтендера, который поднимает бэкенд на nodeJS и пишет уже на знакомом ему JS/TS. Если речь про простые бэкенды/фронтенды, то в чем проблема? Если декомпозировать приложение, то это будет набор CRUD-контроллеров с парой методов посложнее. И туда еще можно прикрутить SSR)
Соглашусь, что куча паттернов может быть решена особенностями языка, библиотеками или фреймворками. Это не исключает того, что паттерны стоит знать. Поэтому я бы изучил паттерны по какой-то простой попсовой книге или на сайте на том языке, который я использую. А потом дополнительно какие-то моменты смотрел бы уже сразу под свой стек.
Да, она познавательная, но есть один нюанс. Разбирать примеры на C++ сложно, так как язык не самый популярный и какие-нибудь Java/C#/JS подошли бы лучше. А если вы разработчик на Python, то разобрать код еще сложнее.
Также книга написана довольно муторно, можно было ее переписать в более попсовом формате, чтобы легче было читать. В целом, если книга не обновляется в течении 25-30 лет, это не очень хорошо. Можно было даже выпустить несколько разных вариантов с примерами под разные языки, Java Edition или Python Edition.
Вроде как идея и заключается в том, чтобы запустить ракету в полет с помощью центрифуги, а потом уже включить двигатели. По сути идея в замене первой ступени ракеты на центрифугу.
Уже есть такой стартап SpinLaunch, который с помощью центрифуги раскручивает ракету и потом запускает ее в космос. Но пока результатов не сильно много. Но рабочие прототипы есть и ведутся исследования.
"Доступны для пробного использования разработчиками в Chrome и Edge 139", сейчас актуальная версия 137, или ставить экспериментальную сборку или ждать еще месяц-другой.
Тогда Тим Стокли заведет AIFans, где будет создаваться куча контента по сути в прямом эфире с помощью тысяч видеокарт, и тогда он будет платить только налоги и за электричество.
Классно, если есть навык работать в консоли. Так как я фронтендер, то приходится мышкой тыкать в экран, чтобы все проверять и перепроверять по 100 раз, поэтому 100% vim головного мозга не смогу получить. Но в один момент заметил, что VS Code делает кучу лишних вещей при переходе между ветками git. Мне это дело не понравилось, начал пользоваться консолью для гита. А чуть позже открыл для себя мир git alias и теперь популярные команды пишу еще короче. Теперь вместо `git checkout master` пишу `git cm`.
А почему бы не добавить обратную связь на HR-ов и рекрутинг. Много где есть оценка текущего места работы, но почему я не могу дать обратную связь по компании, которая меня хочет нанять. Можно также выработать важные критерии: хорошо ли описана вакансия, дали обратную связь, заспамили, все ли подробно объяснили и т.д.
Возможно, при таком подходе и со стороны нанимателей будут какие-то бест-практис. Потому что есть миллион статей "как написать красивое резюме", но сильно меньше "как граммотно нанять кандидата".
Будет своего рода социальный рейтинг, если компания хочет развиваться, то и свой найм будет дотягивать до оценки 5.0, а если это будет совковая колхозная шарага, то это будет видно заранее.
Сейчас много различных телефонных ассистентов, они должны тогда научиться блокировать разговор по словам и фразам "майор ФСБ", "центробанк", "безопасный счет")
Нейросети хорошо подходят для того, чтобы преобразовывать одну текстовую структуру в другую.
Проверял насколько можно позволить нейронкам документацию на своем профиле в github. Загрузил в deepseek 9 скриншотов таблицы статистики (потому что не было API), он успешно распознал табличные данные, по моей просьбе просуммировал все и построил график в mermaid раз 5-6 (не нравились диапазоны и я просил другие).
Также делал библиотеку из одного компонента, решил "написать" документацию. Поместил код в нейронку, на выходе получил readme.md, минут за 5 почистил от воды и получил счастье.
Возможно, они перешли к TBD, но это не точно
Я бы еще в список добавил Angular, который тоже слез с игры webpack около года назад.
Так как я разработчик, то в своих проектах я сперва пишу код, потом документацию. Хотя и на работе также. Есть верхнеуровневая документация, которая описывает поведение приложения, а я как разработчик уже сам декомпозирую постановку и создаю внутренние библиотеки с документацией.
Будь я аналитиком, то скорее всего сперва генерировал бы документацию, а потом уже кто-то генерировал код по нему.
Не очень уверен, что правильно ответил на вопрос)
На счет дейликов (из урока №3), на которых подсвечивают риски и проблемы. Они для этого и нужны, так как понять в каком статусе задача можно и смотря на доску в Jira или на доске со стикерами. Если там написано inProgress, значит я ее делаю и есть ли смысл спрашивать об этом - не понятно, оно же видно. Там же видно и то, что я делал вчера и то, что буду делать дальше (потому что у задач есть приоритет и надо брать самую приоритетную).
А вот если я оценили задачу в 2 дня, а делаю ее неделю - вот тут стоит спросить, что пошло не так. Или если я вижу затык по проблеме - я должен уточнить у кого-нибудь на дейли, если не сделал этого раньше.
Интересная статья. Недавно начал активно использовать ИИ-асистенотов и mermaid, понял, что они не плохо подходят для генерации документации к коду, а также для перевода одной текстовой структуры в другую.
Решил ради интереса и тренировки оформить свой github-профиль, использовал mermaid и deep-seek. Скинул 10 скриншотов статистики в deep-seek, с помощью него распознал табличные данные, попросил посчитать и построить график. Аналогично другие структуры в профиле заводил в различные графики mermaid.
Также пару раз генерировал код для простых библиотек, закидывал код в ИИ и просил написать readme-файл, получалось неплохо. Потом минут за 5 вычищал лишнюю воду и вуаля.
Почему программисты не пишущие документацию не начали использовать ИИ и mermaid+markdown для быстрого и легкого написания документации - не понятно) Ревью текста займет явно меньше времени, чем написать все с нуля.
Микросервисы могут решить когнитивную нагрузку разработчиков, ценой когнитивной нагрузки других разработчиков (кто будет объединять микросервисы в приложение выполняющее бизнес-фичу) и девопсов.
Я из мира фронтенда, у нас вместо микросервисов есть микрофронты (по факту микросервисы). Часто слышу, а давайте начнем делать микрофронты, но только это потребует кучи времени настроек CI, особого мышления, так как сильно изменится способ взаимодействия с микрофронтом против обычного компонента. За 1,5 года на последнем проекте я смог выделить для себя только один микрофронт, который бы привел к уменьшению кванта развертывания, так как есть два приложения с разным релизным циклом, в которых надо одновременно зарелизить один и тот же компонент.
Я для себя выделил две эвристики того, как различать( Coupling связанность) и (Cohesion связность).
Первое. Отталкиваюсь от слов цена и ценность. Цена (связанность) - что мы платим, за используемые технологии и ограничения, которые накладываем на код. Ценность (связность) - что мы получим для бизнеса.
Второе. Связанность - это объединение кода библиотеками и фреймворками. А связность - это объединение бизнес-логикой.
Оба определения не идеальны, но как минимум толкают в нужном направлении.
Сделаешь много атомарных микросервисов, потом придется строить оркестратор. Сделаешь более жирные сервисы, придется мириться с другими ограничениями или проблемами. Вся архитектура сводится к тому, что у каждого проекта свои задачи и свои ограничения и как лучше написать - черт его знает, потому что нет серебрянной пули.
Если все сводится в итоге к тому, чтобы сделать из бэкендеров фуллстеков, то что мешает сделать наоборот. Берем фронтендера, который поднимает бэкенд на nodeJS и пишет уже на знакомом ему JS/TS. Если речь про простые бэкенды/фронтенды, то в чем проблема? Если декомпозировать приложение, то это будет набор CRUD-контроллеров с парой методов посложнее. И туда еще можно прикрутить SSR)
Соглашусь, что куча паттернов может быть решена особенностями языка, библиотеками или фреймворками. Это не исключает того, что паттерны стоит знать. Поэтому я бы изучил паттерны по какой-то простой попсовой книге или на сайте на том языке, который я использую. А потом дополнительно какие-то моменты смотрел бы уже сразу под свой стек.
Да, она познавательная, но есть один нюанс. Разбирать примеры на C++ сложно, так как язык не самый популярный и какие-нибудь Java/C#/JS подошли бы лучше. А если вы разработчик на Python, то разобрать код еще сложнее.
Также книга написана довольно муторно, можно было ее переписать в более попсовом формате, чтобы легче было читать. В целом, если книга не обновляется в течении 25-30 лет, это не очень хорошо. Можно было даже выпустить несколько разных вариантов с примерами под разные языки, Java Edition или Python Edition.
Спасибо, очень подробный ответ. В таком контексте соглашусь, что есть смысл делать такой инструмент.