Я могу понять зачем OSS нужен сотрудникам компаний, если такую деятельность компании готовы оплачивать. Делов-то — убедить босса в том, что занимаешься очень полезным делом, «делаешь мир лучше» — и готово.
И я не вижу в этом ничего плохого, ведь в целом, выигрывают от подобных вещей все: как компания, которая как было уже упомянуто, это своего «благотворительность», а для нас, разработчиков, это способ показать в свой вклад в разработку отрытого проекта (хоть и задуманного изначально с коммерческими целями). Плюс ко всему для вас это лишняя возможность блеснуть чем-нибудь в резюме. Чем не выгода для вас в том числе? :)
С другой стороны, как правило те кто занимаются OSS (будь то свои проекты или вклад в существующие, даже в виде тикетов) зачастую имеют достаточно широкий кругозор и могут много чего интересного подсказать. Например, у меня на работе частенько спрашивают что было бы интересно использовать для существующих проектов (фреймворки, библиотеки, какие-нибудь инструменты для тестирования и т.п.).
Я могу понять зачем OSS нужен молодым разработчикам — получить промышленный международный опыт, показать себя.
В целом опыт и/или интерес к чему-то новому и являются причиной к появлению проектов с открытым исходным кодом. Либо, что тоже имеет место: отсутствие нужного инструмента, которым было бы желание пользоваться или архитектура существующих может попросту не устраивать в силу каких-то причин и предпочтений. Самое главное только чтобы то, что будет реализовано позднее было доведено хоть до какого-нибудь минимально готового вида, чтобы желающие могли этим воспользоваться, хотя бы.
Сделать же большой и сколько-нибудь известный OSS-проект самому, с нуля, в современных реалиях практически невозможно, как мне кажется.
Любой проект когда-то начинал с малого и не становился с первого же своего релиза популярным, трендовым и молодежным, а проходил ряд этапов развития и испытаний временем, которые проходит любой ныне существующий Open Source проект. Не получилось (или любой другой свой вариант), тогда начинайте следующий и развивайте идею дальше.
За последние 3 года никто этим проектом не интересовался помимо его непосредственных пользователей. Работодатели? Рекрутёры? Пха! Не смешите мои тапки. Ссылка на проект торчит во всех профилях, но не упоминается ни в одном письме с предложением о работе. Как будто его не существует. А отдельные индивиды даже просили меня приложить к резюме пример кода zip-архивом — вот настолько у ссылок на GitHub развит навык мимикрии и невидимости! В общем, приготовьтесь к тому, что в карьерном плане небольшой, но живой OSS-проект вам не особо-то поможет.
Не смотря на то что сам участвую в разработке Open Source проектов (своих и контрибьюция в чужие), наличие подобных проектов дает вам жирный "+" в карму и небольшое преимущество в поиске работы, но никак не гарантирует вам её получение. В моем случае, с этим фактом я уже смирился давно и в CV добавляю всего пару ключевых проектов (самых «жирных» по вкладу/возможностям).
Но, безусловно, существуют и редкие исключения. Некоторые умные рекрутеры, владеющие поиском по GitHub'у, могут наткнутся на ваш профиль с проектами и пригласить к себе на собеседование. Если повезет, то еще и тестовое вам «скипнут» в качестве бонуса за то что вы такой хороший разработчик уже на старте.
У меня был подобный случай (в прошлом году) с проектом который я уже около года делаю в одиночку. Проект этот посвящен реализации matchmaking'а для игр (ссылка) на микросервисной архитектуре, поскольку не нашел открытой реализации в нужном мне виде и которой мог бы поэкспериментировать на досуге. Так вот, сей проект привлек внимание рекрутера, которая вышла на связь со мной через мою основную почту. И хотя я работу не получил, но впечатление в целом было весьма положительное по итогу. По крайней мере после той цепочки собеседований осталось осознание что делаю что-то не зря и двигаюсь в правильном направлении.
Если у вас репа ответственная — то нужно все проверить и перепроверить.
Такие вещи за 3 дня не делаются (и это вместе с принятием принципиального решения и с выбором альтернативы).
Доля правды в этих словах есть. На работе текущей, например, вопрос о переходе решается (AWS CodeCommit vs BitBucket vs GitLab)
Смотря кто будет делать это приобретение. Если это будет опять тот же Microsoft – то да, буду однозначно. В крайнем случае просто разверну тот же GitLab интанс на ресурсах AWS/Google Cloud (кои мне симпатизируют) и буду там сидеть спокойно делать проекты.
Не вижу никакого смысла тянуть до последнего. Чем раньше, тем лучше. А сделать зеркала на активные репозитории не так уж сложно, если честно.
> Зачем устраивать себе дополнительные проблемы по обновлению урлов, эндпойнтов в разных сервисах, если пока ничего, кроме номинального владельца не поменялось?
Проблем никаких тут нету, если все более менее автоматизировано и не захардкожено внутри кода.
Я перенес все свои наиболее ценные репозитории (коих суммарно около двух десятков) в пару кликов в GitLab без какой-либо головной боли и проблем. С этим там действительно все в порядке. Да, надо разве что потратить какое-то время (оценочно около часа суммарно на все), чтобы обновить URLы на активный репозиторий в проектах, и поперезаливать все пакеты в PyPi, Hex.pm и т.п. Но это капля в море, по сравнению с тем временем, кое было уже затрачено на все проекты суммарно.
Процесс перехода не моментальный, я спорить в этом даже буду. Но в любом случае у ребят из GitLab предостаточно времени чтобы успеть все мигрировать до официального перехода GitHub к Microsoft в своем темпе.
Еще ничего не поменялось в terms of service, никаких планов на изменения не озвучено, а кто-то уже бежит.
Мне кажется что ToS не изменится и будет таким же. В противном случае какой был бы смысл переходить на другую платформу, верно? (но это не точно)
P.S. Сам свои проекты уже перенес на днях в GitLab. На GitHub оставлю лишь зеркала на перенесенные.
Я тоже с этим столкнулся вчера. Получилось так что импорты я делал в пиковую нагрузку (судя по графикам в их Graphana), а следовательно и время импорта затянулось. Утром на работе ради теста сделал повторный импорт — все прошло практически моментально.
Исходя из вашей логики получается, что все те люди, которые в свободное время занимаются pet-проектами/open source и подобными вещами тратят свое время просто зря? А что тогда делать в случаях, когда твоя работа (внезапно!) вполне устраивает, загруженность имеется, но просто есть ряд технологий с которыми поработать не предоставят возможности никак, даже если ты общался с соответствующими людьми (допустим перейти на микросервисную архитектуру; попробовать какую-то хорошую и проверенную временем библиотеку, обсудив с архитектором проекта, но не получив его одобрения)?
То что человек, тратит собственное время на что-то вне работы, говорит не о том, что ему здесь плохо и ему надо срочно уходить куда-то еще. Его вполне может устраивать текущее положение вещей на проекте. Это говорит скорее немного о ином: ей/ему интересны несколько областей разработки; просто чтобы всегда быть «в тонусе» и повышать свой профессиональный уровень гораздо быстрее, нежели его коллеги; иметь потенциальное преимущество перед другими кандидатами, при необходимости поиска работы (например, тебе могут закрыть глаза на необходимость тестовое задание и сразу перейти собеседованию).
П.С. А вообще, я не буду удивлен, если вдруг обнаружится, что человеку который тратил свое свободное время и занимался какими-либо проектами (или может даже поучаствовал в разработке существующих как-либо) получает более «вкусное» предложение о работе.
Все просто. Если у тебя стоит задача получать данные в реальном времени, то при использовании HTTP чтобы получать свежие данные вы будете использовать опрос сервера с неким интервалом времени, что не очень удобно. В случае с веб-сокетами достаточно создать соединение с сервером один раз, подписаться на получение каких-то данных, и получать свежие данные от сервера без необходимости выполнять какой-либо long polling.
Выбор был основан в некоторой мере и на личных предпочтениях. С Tornado мне приходилось иметь дело, но предоставляемый API «из коробки» не очень нравится.
Хотя такая библиотека и есть, но нет необходимости её использовать, поскольку нам требуется лишь несколько полей. Быстрее (и проще) будет сделать что-то минималистичное самостоятельно.
Браво! Я просто не могу подобрать слов! Тема WebSockets в Python для меня была просто пыткой, сколько я ни пытался заставить себя погрузиться в неё, всё время какое-то отторжение происходило и я быстро находил на что отвлечься. aiorest-ws (по крайней мере по примерам и описанию) — это огромный шаг в сторону упрощения.
Я бы сказал немного попроще – эксперимент. На текущий момент времени чего-то готового и работающего из коробки с веб-сокетами, в привычном стиле я так и не нашел (да и сейчас, вроде как ситуация не особо поменялась). Да, есть что-то вроде расширений (или плагинов) для того же Django REST, но немного не то, чего я ожидал бы увидеть.
Вполне возможно, что существуют какие-то «закрытые» реализации подобных библиотек, которые имеют что-то схожее с тем, что я постарался описать, но не является open source. А жаль.
Ваша реализация в стиле Flask мне импонирует, как и использование REST подхода. Swagger (OpenAPI) вам не факт, что поможет в плане какой-то готовой реализации (по крайней мере я не слышал о REST WebSockets поддержке ни в Swagger-UI, ни в Swagger-Codegen), но для HTTP RESTful API он просто божесвеннен, на мой взгляд, и я даже собрал демо на Flask-RESTplus (фреймворк для HTTP REST Swagger API) для более-менее жизненного примера, может что-то интересное для себя и в нём найдёте.
Какого-то конкретного решения о структуре проекта (вроде тех, что предлагаются в Django или Flask) я не описывал. Пока просто выбирайте тот стиль что удобнее будет вам.
Спасибо за ссылку, посмотрю на досуге. Вдруг чего-нибудь возьму на вооружение.
Кстати, а ваш роутинг можно на модули разбивать, например, как Blueprint в Flask? Это гораздо удобнее, на мой взгляд, чем один общий router где-то там в корне проекта.
В реализации класса SimpleRouter есть метод include, который принимает другой роутер в качестве параметра. Внутри нее просто копируются роуты из одного в другой. То есть конечный роутер будет иметь пути нескольких роутеров: свой, и те, что мы включили через вызов include.
Я вижу, что ваши сериализаторы очень похожи на Marshmallow, но почему бы просто не взять сам Marshmallow вместо нового велосипеда? Неужели требование к минимальности зависимостей настолько строгое?
Лишние трудности закаляют (надо же было себе какой-то челенж придумать), да и сделать что-то свое всегда интересно. Исходники библиотеки Marshmallow во многом хорошо подсказывали как решать ту или иную задачу при сериализации классов SQLAlchemy.
Зачем Вы указываете кодировку utf8 в заголовке файла? Проект же под третий питон?
Да, проект написан под 3ку. Относительно наличия «utf8» в заголовке каждого файла могу лишь сказать что это банальная привычка. На работе (наверное, как и многие) все также пишу на 2ой ветке.
В целом, согласен с вышесказанными. Этот момент реально стоит мне как-то продумать более детально, поскольку мы упираемся в количество имеющихся воркеров.
Были идеи сделать что-то в связке с aiopg, чтобы появилась возможность работы асинхронно с БД (хоть только и PostgreSQL). Правда возникает вполне простой вопрос: а как мне можно перейти в асинхронный код при работе aiorest-ws с Django, у которого множества различных адаптеров есть под разные базы?
Текущее решение не идеально, на текущий момент, но хоть есть от чего отталкиваться :)
Планируется ли какая-нибудь он-лайн трансляция (даже если она будет платная)? Было бы здорово поучаствовать в подобном мероприятии при невозможности реального посещения.
С другой стороны, как правило те кто занимаются OSS (будь то свои проекты или вклад в существующие, даже в виде тикетов) зачастую имеют достаточно широкий кругозор и могут много чего интересного подсказать. Например, у меня на работе частенько спрашивают что было бы интересно использовать для существующих проектов (фреймворки, библиотеки, какие-нибудь инструменты для тестирования и т.п.).
В целом опыт и/или интерес к чему-то новому и являются причиной к появлению проектов с открытым исходным кодом. Либо, что тоже имеет место: отсутствие нужного инструмента, которым было бы желание пользоваться или архитектура существующих может попросту не устраивать в силу каких-то причин и предпочтений. Самое главное только чтобы то, что будет реализовано позднее было доведено хоть до какого-нибудь минимально готового вида, чтобы желающие могли этим воспользоваться, хотя бы.
Любой проект когда-то начинал с малого и не становился с первого же своего релиза популярным, трендовым и молодежным, а проходил ряд этапов развития и испытаний временем, которые проходит любой ныне существующий Open Source проект. Не получилось (или любой другой свой вариант), тогда начинайте следующий и развивайте идею дальше.
Не смотря на то что сам участвую в разработке Open Source проектов (своих и контрибьюция в чужие), наличие подобных проектов дает вам жирный "+" в карму и небольшое преимущество в поиске работы, но никак не гарантирует вам её получение. В моем случае, с этим фактом я уже смирился давно и в CV добавляю всего пару ключевых проектов (самых «жирных» по вкладу/возможностям).
Но, безусловно, существуют и редкие исключения. Некоторые умные рекрутеры, владеющие поиском по GitHub'у, могут наткнутся на ваш профиль с проектами и пригласить к себе на собеседование. Если повезет, то еще и тестовое вам «скипнут» в качестве бонуса за то что вы такой хороший разработчик уже на старте.
У меня был подобный случай (в прошлом году) с проектом который я уже около года делаю в одиночку. Проект этот посвящен реализации matchmaking'а для игр (ссылка) на микросервисной архитектуре, поскольку не нашел открытой реализации в нужном мне виде и которой мог бы поэкспериментировать на досуге. Так вот, сей проект привлек внимание рекрутера, которая вышла на связь со мной через мою основную почту. И хотя я работу не получил, но впечатление в целом было весьма положительное по итогу. По крайней мере после той цепочки собеседований осталось осознание что делаю что-то не зря и двигаюсь в правильном направлении.
Доля правды в этих словах есть. На работе текущей, например, вопрос о переходе решается (AWS CodeCommit vs BitBucket vs GitLab)
Да, речь идет об этих типах проектах сейчас.
Не вижу никакого смысла тянуть до последнего. Чем раньше, тем лучше. А сделать зеркала на активные репозитории не так уж сложно, если честно.
> Зачем устраивать себе дополнительные проблемы по обновлению урлов, эндпойнтов в разных сервисах, если пока ничего, кроме номинального владельца не поменялось?
Проблем никаких тут нету, если все более менее автоматизировано и не захардкожено внутри кода.
Я перенес все свои наиболее ценные репозитории (коих суммарно около двух десятков) в пару кликов в GitLab без какой-либо головной боли и проблем. С этим там действительно все в порядке. Да, надо разве что потратить какое-то время (оценочно около часа суммарно на все), чтобы обновить URLы на активный репозиторий в проектах, и поперезаливать все пакеты в PyPi, Hex.pm и т.п. Но это капля в море, по сравнению с тем временем, кое было уже затрачено на все проекты суммарно.
Мне кажется что ToS не изменится и будет таким же. В противном случае какой был бы смысл переходить на другую платформу, верно? (но это не точно)
P.S. Сам свои проекты уже перенес на днях в GitLab. На GitHub оставлю лишь зеркала на перенесенные.
То что человек, тратит собственное время на что-то вне работы, говорит не о том, что ему здесь плохо и ему надо срочно уходить куда-то еще. Его вполне может устраивать текущее положение вещей на проекте. Это говорит скорее немного о ином: ей/ему интересны несколько областей разработки; просто чтобы всегда быть «в тонусе» и повышать свой профессиональный уровень гораздо быстрее, нежели его коллеги; иметь потенциальное преимущество перед другими кандидатами, при необходимости поиска работы (например, тебе могут закрыть глаза на необходимость тестовое задание и сразу перейти собеседованию).
П.С. А вообще, я не буду удивлен, если вдруг обнаружится, что человеку который тратил свое свободное время и занимался какими-либо проектами (или может даже поучаствовал в разработке существующих как-либо) получает более «вкусное» предложение о работе.
Я бы сказал немного попроще – эксперимент. На текущий момент времени чего-то готового и работающего из коробки с веб-сокетами, в привычном стиле я так и не нашел (да и сейчас, вроде как ситуация не особо поменялась). Да, есть что-то вроде расширений (или плагинов) для того же Django REST, но немного не то, чего я ожидал бы увидеть.
Вполне возможно, что существуют какие-то «закрытые» реализации подобных библиотек, которые имеют что-то схожее с тем, что я постарался описать, но не является open source. А жаль.
Какого-то конкретного решения о структуре проекта (вроде тех, что предлагаются в Django или Flask) я не описывал. Пока просто выбирайте тот стиль что удобнее будет вам.
Спасибо за ссылку, посмотрю на досуге. Вдруг чего-нибудь возьму на вооружение.
В реализации класса SimpleRouter есть метод include, который принимает другой роутер в качестве параметра. Внутри нее просто копируются роуты из одного в другой. То есть конечный роутер будет иметь пути нескольких роутеров: свой, и те, что мы включили через вызов include.
Лишние трудности закаляют (надо же было себе какой-то челенж придумать), да и сделать что-то свое всегда интересно. Исходники библиотеки Marshmallow во многом хорошо подсказывали как решать ту или иную задачу при сериализации классов SQLAlchemy.
Да, проект написан под 3ку. Относительно наличия «utf8» в заголовке каждого файла могу лишь сказать что это банальная привычка. На работе (наверное, как и многие) все также пишу на 2ой ветке.
Были идеи сделать что-то в связке с aiopg, чтобы появилась возможность работы асинхронно с БД (хоть только и PostgreSQL). Правда возникает вполне простой вопрос: а как мне можно перейти в асинхронный код при работе aiorest-ws с Django, у которого множества различных адаптеров есть под разные базы?
Текущее решение не идеально, на текущий момент, но хоть есть от чего отталкиваться :)