Следующим шагом после изобретения автором упрощенной версии claude будет изобретение GUI, и окажется что вообще не нужно помнить команды, тратить время на запрос к ЛЛМ и набор текста, просто нажал кнопку и всё
Это новая фича у команды, поэтому как ее обозначать на русском пока не ясно.
Теперь почему обозначил так:
Flutter 3.41 — февраль | Ветка создана 6 января
Flutter 3.44 — май | Ветка на 7 апреля
Flutter 3.47 — август | Ветвление 7 июля
Flutter 3.50 — Ноябрь | Ветвление 6 октября
3.41 - уже ветка, выросла и есть, но, у нее будут патч обновления до 3.44 примерно раз в неделю типа 3.41.1, 3.41.2 и т д на пути к 3.44 (это работа в настоящее время) и (важно!) в этот раз изначально планировался релиз 3.44, т е 3.44 - это уже сформированная ветка.
А вот 3.47 и 3.50 - это еще некое отдаленное будущее (хотя обозначенное), поэтому "ветвление" т е как бы "в процессе".
С одной стороны выпуском не назовешь текущее, с другой - планами не назовешь то, что уже пронумеровано версиями с минорными хвостами.
Но поверьте, машинный перевод не додумался до "ветвление" он перевел как "филиал".
Т е текущее положение вещей - не баг перевода, а попытка поиска подходящей терминологии на русском, которая к следующему разу, думаю, стабилизируется, а пока это такой выход из ситуации, но не думаю что он очень важный в данном случае, т к не важен translate, когда можно сделать flutter upgrade!)
если исходить, что старший разработчик - это кодер, то чем он отличается от мидла или джуна? Скоростью печати?
Если бы вы хоть чучуть шарили в разработке, а не во взгляде со стороны, такой вопрос просто не появился бы в голове.
сам кодинг занимает наверное процентов 25-30 рабочего времени
зависит от того, это RnD проект, где нужно пробовать и смотреть или уже обкатанный бизнес проект, где можно взять хорошо зарекомендовавшую себя архитектуру для данного кейса и просто подпилить при надобности. Кодинг - это не только написание кода пальцами по клавиатуре. Обдумывание кода при написании не меньше чем продумывание решений вне сидения за кодом.
Сеньер нужен там, где полезен его опыт, если же корабль не знает куда ему плыть, то все равно какой ветер дует.
Я согласен, что JS сильно вырос, а TS — удобная надстройка над ним, но в итоге он всё равно транслируется в JS, а там сюрпризы не только на уровне типобезопасности, плюс зависимость от конкретных браузеров.
Dart выигрывает у TS там, где нужны более жёсткие гарантии типов и возможность идти в нативный мир, а не только в “удобный слой над JavaScript”.
Ну смотрите, здесь хорошо было бы выделить что именно мы рассматриваем, JS или TS.
Ну то есть шанс некий словить неочевидное из-за пользовательского кода - определенно есть. Но это не похоже на хаос, лишь тонкие эдж-кейсы в редких случаях.
это про TS, но не про JS.
Я говорил именно про JavaScript-рантайм, где null/undefined-баги до сих пор в топе. TypeScript — это попытка навести там порядок, но он не отменяет проблем JS по умолчанию и далеко не везде используется строго, хотя он значительно лучше в плане предсказуемости результата. (я для себя сравнивал Dart, TS и JS)
+ личный опыт с тех времен когда еще не было TS, а был JS, который еще не был по ES6. Это был поистине ужасный язык.
Flutter/React Native это принципиально не лечит, и не должен лечить, и не маскирует. Это не то, что можно замаскировать высокоуровневой библиотекой, это то, что надо было делать по единному стандарту с корня.
Справедливости ради, пользователи не ищут ваше приложение по имени пакета
Господин, вы считаете что иметь единый идентификатор для всего зоопарка платформ - это не справедливо и неудобно для пользователя? Если будет единый идентификатор - это рай для всех. Да, пользователю обычно всё равно (но я бы хотел только по ид=названию найти приложение во всех сторах), но единообразие идентификаторов важно не только для поиска, но и для управления продуктом. Эти строки живут в ссылках стора, интеграциях и документах, и со временем превращаются в “паспорт” приложения:
юридические/комплаенс-документы, договоры, реестры и просто корпоративная отчётность, где удобнее иметь один канонический идентификатор продукта, а не зоопарк строк.
в ссылке Google Play реально светится package name через параметр id=..., и в B2B-переписке/презентациях это часто видно.
Android App Links требуют assetlinks.json и там завязка на пакет/подпись, поэтому согласованность домена и ID снижает шанс ошибок, а на iOS в apple-app-site-association ключ appID строится как TeamID + bundleID. И да, в CI/CD (тот же fastlane) вы постоянно оперируете bundle identifier как общей переменной проекта, так что единообразие реально экономит время. CI/CD: В скриптах сборки (Fastlane, GitHub Actions) вы оперируете одной переменной APP_ID, а не пишете «лапшу» из условий if ios then ... else ....
Группировка статистики и логика валидации клиентов на сервере упрощается в разы, когда у вас один ключ продукта, а не таблица маппинга разных ID.
И еще полно случаев, где это удобно.
В итоге: даже юзеру не всё равно, от удобного юзер не откажется, но разработчику и бизнесу единый ID экономит часы на настройку, деньги на юристов и нервы на поддержку легаси.
1) музыка изначально создавалась и выкладывалась на платформах ради продажи.
2) украсть и сделать общедоступным не равно опенсорс
Пираты существовали всегда, грабили жёстко и лишь единицы из них делились награбленным с простым народом.
А мне нравится покупать за пару долларов любимые песни, т к и мне приятно, и автору песни спасибо и платформе, которая организовала такой простой, доступный и легальный способ приобрести песню - спасибо.
Терминалов никто не боится, gui используют потому что это и удобно, и красиво, и быстро.
Gui даёт несравненно богатое представление информации в отличие от терминала, ни один 3д проектировщик и ни один видеомонтажер не будет выводить свою работу в терминал, потому что это глупо.
А вот программистам и представлять не надо, в здесь все ровно так и происходит - программу вы можете запустить только целиком.
Совсем нет. Тестирование появилось одновременно с программированием, а сейчас тестирование очень развито, все части программы можно протестировать до запуска целиком.
Главная проблема - у вас нет гарантии, что вы действительно правильно понимаете, как все работает
Это скорее про заказчика, а не про исполнителя в классическом программировании для бизнеса: исполнитель понимает, а заказчик - не факт. А в вайбкодинге исполнитель - ЛЛМ, ЛЛМ - "понимает", а вот вайбкодер - не факт.
а из непонятного - почему вы не поменяете свой арсенал знаний и инструментов, которые держат вас в таких рамках, если видите эти рамки?
Да, верно, это во-первых, одна из лучших статей, во-вторых - самая недооцененная. Автору огромная благодарность и плюс в карму. Пишите, пишите еще, хорошо получилось, именно такое хочется читать!
Я написал "банку с баблом", про доллары писал предыдущий оратор
Ну в том то и суть что банку с баблом обналичивать не прийдется, в отличии от крипты
Отличная статья, отличное приложение, отличный выбор стека, отличный подход к разработке) Редкость на хабре. Давайте ещё!
Следующим шагом после изобретения автором упрощенной версии claude будет изобретение GUI, и окажется что вообще не нужно помнить команды, тратить время на запрос к ЛЛМ и набор текста, просто нажал кнопку и всё
Вы серьезно? Вся эта ваша работа стоит меньше 450$?
Благодарю!
Это новая фича у команды, поэтому как ее обозначать на русском пока не ясно.
Теперь почему обозначил так:
Flutter 3.41 — февраль | Ветка создана 6 января
Flutter 3.44 — май | Ветка на 7 апреля
Flutter 3.47 — август | Ветвление 7 июля
Flutter 3.50 — Ноябрь | Ветвление 6 октября
3.41 - уже ветка, выросла и есть, но, у нее будут патч обновления до 3.44 примерно раз в неделю типа 3.41.1, 3.41.2 и т д на пути к 3.44 (это работа в настоящее время) и (важно!) в этот раз изначально планировался релиз 3.44, т е 3.44 - это уже сформированная ветка.
А вот 3.47 и 3.50 - это еще некое отдаленное будущее (хотя обозначенное), поэтому "ветвление" т е как бы "в процессе".
С одной стороны выпуском не назовешь текущее, с другой - планами не назовешь то, что уже пронумеровано версиями с минорными хвостами.
Но поверьте, машинный перевод не додумался до "ветвление" он перевел как "филиал".
Т е текущее положение вещей - не баг перевода, а попытка поиска подходящей терминологии на русском, которая к следующему разу, думаю, стабилизируется, а пока это такой выход из ситуации, но не думаю что он очень важный в данном случае, т к не важен translate, когда можно сделать flutter upgrade!)
Если бы вы хоть чучуть шарили в разработке, а не во взгляде со стороны, такой вопрос просто не появился бы в голове.
зависит от того, это RnD проект, где нужно пробовать и смотреть или уже обкатанный бизнес проект, где можно взять хорошо зарекомендовавшую себя архитектуру для данного кейса и просто подпилить при надобности. Кодинг - это не только написание кода пальцами по клавиатуре. Обдумывание кода при написании не меньше чем продумывание решений вне сидения за кодом.
Сеньер нужен там, где полезен его опыт, если же корабль не знает куда ему плыть, то все равно какой ветер дует.
Категорически соглашаюсь! Очень зря они эту неудачу не преодолели.
Я согласен, что JS сильно вырос, а TS — удобная надстройка над ним, но в итоге он всё равно транслируется в JS, а там сюрпризы не только на уровне типобезопасности, плюс зависимость от конкретных браузеров.
Dart выигрывает у TS там, где нужны более жёсткие гарантии типов и возможность идти в нативный мир, а не только в “удобный слой над JavaScript”.
import 'package:jaspr/jaspr.dart';void main() => runApp(h1([text('Hello World!')]));
)))
Ну смотрите, здесь хорошо было бы выделить что именно мы рассматриваем, JS или TS.
это про TS, но не про JS.
Я говорил именно про JavaScript-рантайм, где null/undefined-баги до сих пор в топе. TypeScript — это попытка навести там порядок, но он не отменяет проблем JS по умолчанию и далеко не везде используется строго, хотя он значительно лучше в плане предсказуемости результата. (я для себя сравнивал Dart, TS и JS)
+ личный опыт с тех времен когда еще не было TS, а был JS, который еще не был по ES6. Это был поистине ужасный язык.
Я не знаком с $mol, но в выборе фреймворка больше руководствуюсь выбором языка, я люблю Дарт, т к тс, или особенно жс - для меня больший тупик.
Интересно кто смеётся над пользователями ВКонтакте
Flutter/React Native это принципиально не лечит, и не должен лечить, и не маскирует. Это не то, что можно замаскировать высокоуровневой библиотекой, это то, что надо было делать по единному стандарту с корня.
Господин, вы считаете что иметь единый идентификатор для всего зоопарка платформ - это не справедливо и неудобно для пользователя? Если будет единый идентификатор - это рай для всех. Да, пользователю обычно всё равно (но я бы хотел только по ид=названию найти приложение во всех сторах), но единообразие идентификаторов важно не только для поиска, но и для управления продуктом. Эти строки живут в ссылках стора, интеграциях и документах, и со временем превращаются в “паспорт” приложения:
юридические/комплаенс-документы, договоры, реестры и просто корпоративная отчётность, где удобнее иметь один канонический идентификатор продукта, а не зоопарк строк.
в ссылке Google Play реально светится package name через параметр id=..., и в B2B-переписке/презентациях это часто видно.
Android App Links требуют assetlinks.json и там завязка на пакет/подпись, поэтому согласованность домена и ID снижает шанс ошибок, а на iOS в apple-app-site-association ключ appID строится как TeamID + bundleID. И да, в CI/CD (тот же fastlane) вы постоянно оперируете bundle identifier как общей переменной проекта, так что единообразие реально экономит время.
CI/CD: В скриптах сборки (Fastlane, GitHub Actions) вы оперируете одной переменной APP_ID, а не пишете «лапшу» из условий if ios then ... else ....
Группировка статистики и логика валидации клиентов на сервере упрощается в разы, когда у вас один ключ продукта, а не таблица маппинга разных ID.
И еще полно случаев, где это удобно.
В итоге: даже юзеру не всё равно, от удобного юзер не откажется, но разработчику и бизнесу единый ID экономит часы на настройку, деньги на юристов и нервы на поддержку легаси.
Причем здесь капитализм?
1) музыка изначально создавалась и выкладывалась на платформах ради продажи.
2) украсть и сделать общедоступным не равно опенсорс
Пираты существовали всегда, грабили жёстко и лишь единицы из них делились награбленным с простым народом.
А мне нравится покупать за пару долларов любимые песни, т к и мне приятно, и автору песни спасибо и платформе, которая организовала такой простой, доступный и легальный способ приобрести песню - спасибо.
Терминалов никто не боится, gui используют потому что это и удобно, и красиво, и быстро.
Gui даёт несравненно богатое представление информации в отличие от терминала, ни один 3д проектировщик и ни один видеомонтажер не будет выводить свою работу в терминал, потому что это глупо.
Совсем нет. Тестирование появилось одновременно с программированием, а сейчас тестирование очень развито, все части программы можно протестировать до запуска целиком.
Это скорее про заказчика, а не про исполнителя в классическом программировании для бизнеса: исполнитель понимает, а заказчик - не факт. А в вайбкодинге исполнитель - ЛЛМ, ЛЛМ - "понимает", а вот вайбкодер - не факт.
а из непонятного - почему вы не поменяете свой арсенал знаний и инструментов, которые держат вас в таких рамках, если видите эти рамки?
Да, верно, это во-первых, одна из лучших статей, во-вторых - самая недооцененная. Автору огромная благодарность и плюс в карму. Пишите, пишите еще, хорошо получилось, именно такое хочется читать!