Я решил завести этот блог, чтобы найти людей со схожими интересами и делится всем тем, что я переживу и чему научусь на своем пути.
А что хотите получить от подобного знакомства?
Я обычный студент, которого сегодня выгнали со стажировки на направлении фронтенд.
Высока вероятность, что за подобные статьи на хабре заминусуют и мотивация упадёт ещё ниже. Другое дело если напишите как так, почему пропала мотивация, что за универ, и почему всётаки выгнали со стажировки.
Как указано в статье, OpenAPI схема позволяет генерировать клиентский код. Это может быть полезно, когда сервис есть, а библиотеки у него нет. Я так например генерировал клиента для Яндекс Музыки. Описал их Open API схему и сгенерировал JS библиотеку. https://github.com/acherkashin/yandex-music-open-api/blob/main/src/yandex-music.yaml
Ну и можно генерировать аналогично библиотеку, чтобы ходить на свой бэк. Генерируешь схему для методов бэка, а из схемы клиентский код на любом языке.
Я думаю этот формат в основном подходит для юнит тестов, и книга, где он рекомендуется тоже именно о юнит тестах. Когда мы называем тест просто "TestLogin" не совсем понятно, что именно мы тестируем, при каких условиях и какой результат ожидаем. Чтобы всё это понять, мне придётся читать тест целиком. Если же я называю тест "TestLogin_InvalidPassword_ThrowsException", все достаточно понятно, я тестирую вход в систему и при это я передаю неправильный пароль, и как результат должен получить ошибку.
Иногда, к сожалению, коллег нужно постоянно пинать и код ревью затягивается очень сильно. Если разбивать на маленькие ПРы, которые зависят друг от друга, работать становится невозможно, потому что, увы, быстрее от этого ПРы не становятся,. Поэтому иногда проще зафигачить один большой ПР)
Классно, но как разработчику не хватило кода. Какие подходы/паттерны вы использовали при разработке компонентов, чтобы сделать их достаточно кастомизируемыми для использования в разных продуктах? Слоты, как материл UI (в реакте просто render-props) или Compound Components? State Reducer Pattern? Было бы очень интересно узнать
С частичным применением всё верно. В моем примере - реализация, которая может принимать любое количество аргументов, и частично примененная функция будет принимать на переданное количество аргументов меньше.
С картированием можно сказать тоже все так как вы описываете, но здесь в реализации можно передавать больше чем один аргумент, потому что JS позволяет это легко реализовать. Но можно сделать реализацию, которая будет всегда принимать лишь один аргумент для каррированной функции.
Спасибо большое за ссылки, нужно будет выкроить время почитать.
Рассказали бы лучше, как так у вас в веб-приложении единоразово аж 8 гигабайт памяти выгружается, что за юз кейс такой.
Тут не могу всё раскрывать. Но если в двух словах - мы позволяем пользователю описывать визуально бизнес процесс визуально, диаграммами. И также позволяем его отлаживать, прямо как в дебагере. Отладчик не очень оптимально работает сейчас, он хранит все значения для каждого шага процесса. У пользователя был огромный бизнес процесс, с множеством циклов. И так как мы храним все значения дебагера, это требовало 8 ГБ оперативки.
В итоге мы перестали хранить все данные, для циклов, храним только значения для 5 операций. И теперь потребляется все 1 ГБ оперативки.
Круто, спасибо!
У Вани должность не тимлид а джобсекьюрити)
Да, но это слишком абстрактно. Возможно есть процессы из собственного опыта
Спасибо за статью!
Наверно не хватило немного контекста и конкретики. Кто вы, почему занимаетесь автоматизацией процессов.
Есть какой-то самый удачный пример подобной автоматизации?
А что хотите получить от подобного знакомства?
Высока вероятность, что за подобные статьи на хабре заминусуют и мотивация упадёт ещё ниже. Другое дело если напишите как так, почему пропала мотивация, что за универ, и почему всётаки выгнали со стажировки.
Как указано в статье, OpenAPI схема позволяет генерировать клиентский код. Это может быть полезно, когда сервис есть, а библиотеки у него нет. Я так например генерировал клиента для Яндекс Музыки. Описал их Open API схему и сгенерировал JS библиотеку. https://github.com/acherkashin/yandex-music-open-api/blob/main/src/yandex-music.yaml
Ну и можно генерировать аналогично библиотеку, чтобы ходить на свой бэк. Генерируешь схему для методов бэка, а из схемы клиентский код на любом языке.
Потому что тогда можно указать одновременно все 4 параметра, а нам нужно либо
responsive, либоwidthиheightА можете подробнее описать, чем в этом плане отличается Grerrit от Gitlab'а, например.
Я думаю этот формат в основном подходит для юнит тестов, и книга, где он рекомендуется тоже именно о юнит тестах. Когда мы называем тест просто "TestLogin" не совсем понятно, что именно мы тестируем, при каких условиях и какой результат ожидаем. Чтобы всё это понять, мне придётся читать тест целиком. Если же я называю тест "TestLogin_InvalidPassword_ThrowsException", все достаточно понятно, я тестирую вход в систему и при это я передаю неправильный пароль, и как результат должен получить ошибку.
Иногда, к сожалению, коллег нужно постоянно пинать и код ревью затягивается очень сильно. Если разбивать на маленькие ПРы, которые зависят друг от друга, работать становится невозможно, потому что, увы, быстрее от этого ПРы не становятся,. Поэтому иногда проще зафигачить один большой ПР)
Сейчас не вспомню уже, но если вам интересно могу проверить
Спасибо, ждём!
А пока мы ждём статью можете подсказать какими паттернами вы пользовались?
Классно, но как разработчику не хватило кода. Какие подходы/паттерны вы использовали при разработке компонентов, чтобы сделать их достаточно кастомизируемыми для использования в разных продуктах? Слоты, как материл UI (в реакте просто render-props) или Compound Components? State Reducer Pattern? Было бы очень интересно узнать
Круто! Можно было бы сделать подобную штуку для анализа пул реквестов, но тут уже нужен токен гилаба/гитхаба, чтобы получить доступ на чтение
А как считается "время ожидания влития" по коммитам, если у нас нет тут доступа к пул/мерж реквестам? ?
К сожалению даже одним глазом не смотрел на Haskell(
С частичным применением всё верно. В моем примере - реализация, которая может принимать любое количество аргументов, и частично примененная функция будет принимать на переданное количество аргументов меньше.
С картированием можно сказать тоже все так как вы описываете, но здесь в реализации можно передавать больше чем один аргумент, потому что JS позволяет это легко реализовать. Но можно сделать реализацию, которая будет всегда принимать лишь один аргумент для каррированной функции.
Осталось только обернуть всё в observable и всё готово ?
Спасибо большое за ссылки, нужно будет выкроить время почитать.
Тут не могу всё раскрывать. Но если в двух словах - мы позволяем пользователю описывать визуально бизнес процесс визуально, диаграммами. И также позволяем его отлаживать, прямо как в дебагере. Отладчик не очень оптимально работает сейчас, он хранит все значения для каждого шага процесса. У пользователя был огромный бизнес процесс, с множеством циклов. И так как мы храним все значения дебагера, это требовало 8 ГБ оперативки.
В итоге мы перестали хранить все данные, для циклов, храним только значения для 5 операций. И теперь потребляется все 1 ГБ оперативки.