Буквально вчера выпустил релиз на сириминговых сервисах своего мини-альбома (4 песни), которые сделал в Suno. Наиграл на гитаре свои старые песни и спел, записав на диктофон, потом запись скормил в Suno, около 50-ти разных манипуляций: вначале подбор основы, потом через экстеншены доработка, некоторые куски через реплейс приходилось изменять, потом небольшой мастеринг в FL (в некоторых случаях трек пришлось сшивать из нескольких кусков из Suno) и трек готов. Очень увлекательный процесс.
Ребята, вот вы доклады всякие делаете, а почему же у вас так плохо организована работа?
Я многое повидал, работая с API разных поставщиков, но API Яндекс Такси, а точнее как с ним работа организована по поддержке корпоративных(!) пользователей — это просто дно какое-то. Я очень редко пишу куда-то, но сейчас уже просто накипело! Ниже кратко о той всей боли, которую мы испытываем на протяжении двух лет внедрения Яндекс Такси!
1) Нет тестового API от слова совсем! Да, Яндекс предлагает 10(!) тестовых бесплатных поездок для того, чтобы отладить программу. Есть среди вас гуру тестинга, которым хватит такого числа поездок, чтобы отладить поиск, бронирование, отмену такси в условиях разных ситуаций, после внесения правок программистами? Сделать автоматические тесты на покрытие функционала API? Можно об этом забыть. Доходит до смешного (и одновременно грустного), что приходится гонять реальных таксистов по городу, чтобы отладить код.
2) Вы вот пишите про то, что стараетесь не сломать ничего и поддерживать обратную совместимость, но это не так. Сломать что-то в боевом API — это излюбленная забава команды разработки Яндекс Такси. У вас задекларирована версионность в API, но что же вы ей не пользуетесь? С 2019 года и до сих пор у вас версия 1.0, но в ней вы спокойно меняете реализации уже существующих методов.
3) А сообщить заранее, что в API грядут изменения — это выше собственного достоинства! Изменения происходят внезапно, без предупреждения. На просьбы информировать об этом и присылать заранее документацию по новому API, указывать время ввода в строй новых изменений — только отписки, что это сделать не возможно(!), а если мы хотим получить новую документацию надо написать самим с просьбой её прислать. А узнать, что что-то изменилось я должен из своего хрустального шара, видимо? В статье вы пишите как классно вы мокаете API сторонних поставщиков. Да, я тоже могу так сделать с вашим, но когда вы в очередной раз втихомолку его поменяете, все мои тесты удачно промолчат о ваших изменениях, работая на старых моках. И узнаю я о том, что API сломалось от клиентов.
4) Нет нормальной службы поддержки. Ладно, мы уже не надеемся на контакты программистов, другие поставщики тоже не очень любят переключать на них. Но вы считаете, что это нормально писать технические вопросы менеджеру по продажам, который потом неделю обрабатывает письмо, а любимая отписка: «я направила запрос в отдел разработки, они очень заняты и ответят через неделю»!
5) И да, сами выделенные менеджеры у вас меняются каждые месяца 3-4. Новый не в курсе о том о чём мы говорили с предыдущим и приходится начинать всё заново.
Я не будут проходить по технической реализации API, мы все не безгрешны и делаем ошибки или странную логику, но организовать элементарнейшую систему поддержки своего API — это обязанность поставщика!
Мне не надо многого:
1) заранее информировать, что в API грядут изменения;
2) оперативно присылать новые версии документации со списком изменений;
3) организовать вменяемую службу поддержки: присвоение тикета моему запросу, оперативные ответы и статусы моего запроса. Общаться по почте через менеджера по продажам — это не серьёзно.
4) А если бы вы смогли организовать тестовый API — это было бы верхом профессионализма.
Кстати, вспомнил одну историю по этому поводу. На нашей кафедре делали оптику для советских спутников, которые фотографировали Землю из космоса. И однажды прислали снимок с просьбой пояснить, как так произошло. На этом снимке была чётко видна граница между Финляндией и СССР. Лес в СССР были более тёмные, а в Финляндии более светлый. Когда разобрались, то выяснили, что фины свои леса «пропалывают» — убирают буреломы, спиливают старые деревья, что даёт значительное кол-во древесины без необходимости рубить деревья. У нас же этим никто не занимается. Поэтому даже из космоса финские леса светлее наших.
Вот я и думаю, что с Гуглом могла приключиться такая же история. Из-за того, что финны чистят лес, программа решила, что идёт массированная вырубка. А при этом в этих же лесах растут себе новые деревья. Поэтому на одном и том же пятачка и отмечена и вырубка, и посадка.
Только выбрал продукт и заполнил анкету, как сайт завис. Попробовал сейчас ещё раз, но сайт теперь не даёт выбрать скидочную цену, только полную. Жаль.
Вообще-то я знаю средние компании, которые используют гугловую почту для своего домена, так что для них, использование google docs в норме.
Так как google docs сейчас интегрирован в google drive, то работать роботу с ним просто — только складывай новые файлы в папку на диске или меняй их.
Мы используем для работы с документацейи Google Docs:
1) Удобный редактор
2) Доступ отовсюду
3) Расшаривание (ридонли и с возможностью редактирования)
4) Командная работа
5) Хранение версий
6) Комментирование участков текста
7) Встроенные схемы (со всеми вышеперечисленными плюшками)
8) Экспорт в doc, pdf или публикация в виде html
Вроде всё что нужно.
P.S. Да и недавно запущенный google drive добавляет плюсов в виде прикрепления файлов и синхронизацией с десктопом.
По моему опыту такой вариант лучше работает, чем капс на ударной букве.
Можно указывать количество секунд, сколько должен идти инструментал. Если в начале после интро поставить, то тогда он не будет про него забывать.
Приветствую коллега! Отличные песни! Я тоже в ноябре выпустил тестовый мини-альбом на Яндекс Музыке (и других). Если интересно, то название Dee Aigen.
Да, можно. Получается неплохо. Наиграл и спел первый припев и куплет на гитаре, а потом Суно добила песню до конца.
Буквально вчера выпустил релиз на сириминговых сервисах своего мини-альбома (4 песни), которые сделал в Suno. Наиграл на гитаре свои старые песни и спел, записав на диктофон, потом запись скормил в Suno, около 50-ти разных манипуляций: вначале подбор основы, потом через экстеншены доработка, некоторые куски через реплейс приходилось изменять, потом небольшой мастеринг в FL (в некоторых случаях трек пришлось сшивать из нескольких кусков из Suno) и трек готов. Очень увлекательный процесс.
Если интересно, то вот тут результат - https://music.yandex.ru/artist/23338384?utm_medium=copy_link (ну или в своём любимом сервисе поискать по Dee Aigen).
Я многое повидал, работая с API разных поставщиков, но API Яндекс Такси, а точнее как с ним работа организована по поддержке корпоративных(!) пользователей — это просто дно какое-то. Я очень редко пишу куда-то, но сейчас уже просто накипело! Ниже кратко о той всей боли, которую мы испытываем на протяжении двух лет внедрения Яндекс Такси!
1) Нет тестового API от слова совсем! Да, Яндекс предлагает 10(!) тестовых бесплатных поездок для того, чтобы отладить программу. Есть среди вас гуру тестинга, которым хватит такого числа поездок, чтобы отладить поиск, бронирование, отмену такси в условиях разных ситуаций, после внесения правок программистами? Сделать автоматические тесты на покрытие функционала API? Можно об этом забыть. Доходит до смешного (и одновременно грустного), что приходится гонять реальных таксистов по городу, чтобы отладить код.
2) Вы вот пишите про то, что стараетесь не сломать ничего и поддерживать обратную совместимость, но это не так. Сломать что-то в боевом API — это излюбленная забава команды разработки Яндекс Такси. У вас задекларирована версионность в API, но что же вы ей не пользуетесь? С 2019 года и до сих пор у вас версия 1.0, но в ней вы спокойно меняете реализации уже существующих методов.
3) А сообщить заранее, что в API грядут изменения — это выше собственного достоинства! Изменения происходят внезапно, без предупреждения. На просьбы информировать об этом и присылать заранее документацию по новому API, указывать время ввода в строй новых изменений — только отписки, что это сделать не возможно(!), а если мы хотим получить новую документацию надо написать самим с просьбой её прислать. А узнать, что что-то изменилось я должен из своего хрустального шара, видимо? В статье вы пишите как классно вы мокаете API сторонних поставщиков. Да, я тоже могу так сделать с вашим, но когда вы в очередной раз втихомолку его поменяете, все мои тесты удачно промолчат о ваших изменениях, работая на старых моках. И узнаю я о том, что API сломалось от клиентов.
4) Нет нормальной службы поддержки. Ладно, мы уже не надеемся на контакты программистов, другие поставщики тоже не очень любят переключать на них. Но вы считаете, что это нормально писать технические вопросы менеджеру по продажам, который потом неделю обрабатывает письмо, а любимая отписка: «я направила запрос в отдел разработки, они очень заняты и ответят через неделю»!
5) И да, сами выделенные менеджеры у вас меняются каждые месяца 3-4. Новый не в курсе о том о чём мы говорили с предыдущим и приходится начинать всё заново.
Я не будут проходить по технической реализации API, мы все не безгрешны и делаем ошибки или странную логику, но организовать элементарнейшую систему поддержки своего API — это обязанность поставщика!
Мне не надо многого:
1) заранее информировать, что в API грядут изменения;
2) оперативно присылать новые версии документации со списком изменений;
3) организовать вменяемую службу поддержки: присвоение тикета моему запросу, оперативные ответы и статусы моего запроса. Общаться по почте через менеджера по продажам — это не серьёзно.
4) А если бы вы смогли организовать тестовый API — это было бы верхом профессионализма.
Странно, что не упомянули самое главное из-за чего используют Xdebug — возможность расстановки break point в IDE. Лично я без этого как без рук.
Вот я и думаю, что с Гуглом могла приключиться такая же история. Из-за того, что финны чистят лес, программа решила, что идёт массированная вырубка. А при этом в этих же лесах растут себе новые деревья. Поэтому на одном и том же пятачка и отмечена и вырубка, и посадка.
webdev-tales.ru/post/45283244511/jetbrains-phpstorm-ide
Так как google docs сейчас интегрирован в google drive, то работать роботу с ним просто — только складывай новые файлы в папку на диске или меняй их.
1) Удобный редактор
2) Доступ отовсюду
3) Расшаривание (ридонли и с возможностью редактирования)
4) Командная работа
5) Хранение версий
6) Комментирование участков текста
7) Встроенные схемы (со всеми вышеперечисленными плюшками)
8) Экспорт в doc, pdf или публикация в виде html
Вроде всё что нужно.
P.S. Да и недавно запущенный google drive добавляет плюсов в виде прикрепления файлов и синхронизацией с десктопом.