Как стать автором
Обновить
65
0
Дмитриев Сергей @antirek

Пользователь

Отправить сообщение

еще одно видео для своих коллег записал, тут про chat API amoCRM https://youtu.be/f31UVtn7EJI - час просмотра экономит неделю самостоятельного погружения

статья в целом и ваши рассуждения про тренировку выдержки когнитивных нагрузок - это следствия.

тут нет ответа - почему это происходит? почему разработчики пишут такой код? причины, из-за которых именно авторы кода создают высокую когнитивную нагрузку?

как по мне, если рассматривать только на уровне конкретного разработчика:

а) разработчики - люди, увлекающиеся в направлении разработки. "о, мы сейчас это отнаследуем, это добавим в интерфейс, обернем в прототип" - усложняют конструкцию из какого-то будущего представления о том, что это наследование пригодится, ибо в коде от класса животного будет множество наследующихся кошек, собачек, тигров, слонов и у каждого буде свое say. Ну и как без фабрики по производству фабрик зоопарков, где будет менеджер, который будет инициализировать любого животного. (это даже не преждевременная оптимизация, а наоборот преждевременная попытка предусмотреть несуществующие сценарии),

из а) идет б)

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

из б) следует в)

в) мы поощряем в нашей культуре сложность. восхищяемся, уважаем, поощряем, награждаем тех, кто решал сложные задачи, сложные проблемы, реализовал сложные алгоритмы, построил сложные системы. все предусмотрел, подготовился, реализовал варианты, подстраховался от "неописанных" случаев в ТЗ. при этом мы должны увидеть, что решено, реализовано именно сложным путем.

далее г)

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

и если разработчик сделал задачу за 15 минут, а не три дня, и рассказывал о ней у кулера полчаса, то что он получит? вероятно, еще одну задачу и звание балабола

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

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

про наследование более развернуто - я бы почитал

что следующее? letsencrypt?

а что вы использовали для создания прокси к docker hub? nginx с конфигами как здесь https://github.com/rpardini/docker-registry-proxy/

"никто не рефакторил весь этот год"

ого! тут вернулся к проекту семилетней давности, и к своему глубокому удивлению, ознакомившись с кодом, я понял, что его никто не рефакторил все эти семь лет

для разработки виджета проще использовать что-то типа

https://github.com/jasper7466/Boilerplate-amoCRM-Widget

https://github.com/max-kut/amocrm-widget-starter-kit

для получения oAuth токена

https://youtu.be/CxQcB5AsyHI

из примера в пример эти curl_setopt кочуют ))

для тех кто хочет начать разрабатывать для амо свои интеграции записал видео как запустить интеграцию на своей машине, получать данные с амо

https://youtu.be/CxQcB5AsyHI

https://youtu.be/zRlO7e41bwg

более того при обмене кода (который получаете при установке) на токен, вы также отправляете и client_id и client_secret, т.е. теоретически если сделать какой-нибудь MitM, то по сути все секретики у тебя будут, чтобы перехватить управление данными от интеграции.

аналогично и при запросе свежего access_token мы передаем client_id, client_secret и refresh_token

логичнее было бы передавать какой-нибудь хеш от refresh_token+cleint_secret, который на своей стороне амо могла также воспроизвести и сравнить воспроизведенный с полученным.

механизм не так плох, единственно, что напрягает, что с машины разработчика пока реализуешь нужную функциональность по десять раз потребуется получать свежий access_token

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

чтобы меньше заморачиваться на это и каждый раз не объяснять тем, кто у нас недавно начал заниматься виджетами под амо, с коллегой записали видео https://www.youtube.com/watch?v=CxQcB5AsyHI может кому сделает жизнь проще и съэкономит время на разборки с пониманием амо

спасибо за статью, помогла

сейчас можно использовать '@webdiscus/pug-loader' на замену оригинальному, поддерживает pug 3

Пользователи linux: ну да, ну да, драйверов на принтеры иногда нет))

>> Open-source невозможно монетизировать

может быть в этом весь кайф? ))

во время встречи или переговоров

интересная мотивация, конечно: ни конфигурировать нормально, ни внимание встрече уделить )))

хотя аналог ctop'а в тг может быть и нужен

и сильно помогает? со временем логика архитектурных решений меняется, особенно в длительных проектах

первая рекомендация: понять на каком этапе ваш проект

если проект на начальной стадии - например, вы работаете один, вы тестируете гипотезы, что-то тестируете, и при этом результаты фиксируете в репозиторий - то никто не будет читать ваши коммиты - забейте и пишите что хотите

если проект растет и вас два-три человека - но вы общаетесь, обсуждаете, все в курсе всего - никто не читает коммиты - забейте и пишите что хотите

если ваш проект подрос, начал использоваться вами в рабочей среде, вы стали реже в него писать - о, да, пора писать суть в коммитах, но если там пару опечаток поправили - забейте и напишите fix

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

как автор проекта я бы не рекомендовал ))

я по прежнему использую проект, но как-то не вижу его перспективы в таком виде

Нашел подобный сервис https://upload.io/ , а filebump - это свой локальный вариант.

Его нет. Это не пользовательское хранилище файлов, а такое общее служебное для сервисов. Сервисы хранят уникальные ссылки. Примерно как ролики на Ютубе с доступом по ссылке. Есть ссылка? можешь скачать. Нет ссылки? Тогда и не знаешь, что качать. И пользовательские списки файлов и доступ к ним контролируют уже сервисы сами, filebump - это некоторая такая замена файловой системы для сервиса.

1
23 ...

Информация

В рейтинге
Не участвует
Откуда
Красноярск, Красноярский край, Россия
Дата рождения
Зарегистрирован
Активность