• Самая-самая последняя статья о настройке сервера для Rails
    0
    Ну нужен 1) redis 2) скрипты для старта sidekiq при загрузке сервера. Последние постоянно приходится писать вручную, что в общем немного каменный век с учётом того что по факту sidekiq уже давно часть стандартного комплекта Rails.
  • Самая-самая последняя статья о настройке сервера для Rails
    0
    Спасибо, как ни странно простых решений действительно не хватает, а необходимость каждый раз вручную прописывать одни и те же скрипты слегка достаёт.
    Что с воркерами? Типовой конфиг rails по сути давно уже включает в себя воркеры (не помню ни одного проекта за последние года три на котором их бы не было). При этом по сложности разворачивания в продакшне одна из самых нудных задач.
  • Я не представляю, какого черта я делаю
    0
    Главное, адекватно отражает суть mobile-first.
  • Как мы начали работать на Upwork (личный опыт)
    0
    Ну в общем если не секрет, несколько вопросов. Я просто пытаюсь прикинуть насколько рентабельно это всё по сравнению с вариантом тупо продавать собственные услуги при высоком рейте.
    1. Сколько человек занято на полное время и сколько частично?
    2. Какой уровень команды по сравнению с вашим? Примерно один, несколько ниже, сильно ниже?
    3. Какая ваша функция? Просто ищете проекты, ищете и ведёте (контролируете, пишете часть кода и т.д.)? Сколько времени в неделю в итоге уходит на управление командой, если сюда всю эту деятельность суммировать?
    4. Если бы то же самое время вы работали на заказчика, вы бы получали меньше/столько же/больше?
  • Как мы начали работать на Upwork (личный опыт)
    0
    Вот давайте тогда вас ещё помучаю.
    Также создал агенство и очень неплохо идет

    То есть с агентством вы зарабатываете больше чем без него при тех же временных затратах?
  • Как мы начали работать на Upwork (личный опыт)
    0
    Понял. Ну то есть агентство ради денег открывать смысла нет, только если нравится процесс. Ну в принципе как и почти любой мелкий бизнес.
  • Как мы начали работать на Upwork (личный опыт)
    0
    Ну если продать час вчерашнего студента с наценкой в 10 раз, то тут даже не вопрос этики (понятно что нечестно) — клиент-то получает фактически неквалифицированного работника, ну и с соответствующим результатом (плохие отзывы, разрыв контракта и т.д.).
    Ну либо техлид какой-то должен за такого выполнять половину работы, но тогда уже рентабельность несколько сомнительна.
    В общем я не понимаю этой модели. Хотя наверное это потому что давно не занимаюсь типовыми задачами, если уровень задач невысокий наверное можно и так работать.
  • Как мы начали работать на Upwork (личный опыт)
    0
    Но 80-90% — это жесть конечно. Кто туда работать-то идёт? Там индусы одни наверное? Просто сразу не особо интересовался агентствами, так что не в курсе этой ситуации.
  • Как мы начали работать на Upwork (личный опыт)
    0
    А, ну тогда игра стоит свеч конечно.
  • Как мы начали работать на Upwork (личный опыт)
    0
    А какой у вас кстати агентский сбор?
    Я просто тоже какое-то время думал не открыть ли своё агентство. Посчитал, если брать 10% — это чтобы мне зарабатывать те же деньги, которые получаю за свою работу, нужно 10 человек с тем же рейтом что у меня ($60/час, замучаешься искать да и наверняка прекрасно работают сами без всяких агентств), либо 20 человек с половиной моего рейта.
    20 человек — это уже команда, с которой просто так не управишься в одиночку, нужно дополнительно кого-то нанимать на промежуточные руководящие должности. Получается, я снова получаю меньше. Ну и т.д. В общем, я посидел-посчитал и плюнул.
    По вашим прикидкам, вам какой размер команды нужен чтобы это всё оправдывалось?
  • Как мы начали работать на Upwork (личный опыт)
    0
    Ну ок, согласен.
  • Как мы начали работать на Upwork (личный опыт)
    0
    Ну я вот к этому:
    Когда пишут, что не хотят работать с агентствами — сразу понятно, что это скупердяи, к-е хотят сэкономить на руководителе проекта

    Причины часто лежат вообще в другой плоскости. Просто реально не для всех удобно и оправдано аутсорсить полный цикл работы над проектом. Это обычно удобно для разовых и относительно непродолжительных задач.
  • Как мы начали работать на Upwork (личный опыт)
    0
    Во-первых забываете про стартапы, которых, повторю, немало. Там заказчик — это руководитель в 100% случаев.
    Во-вторых заказчик на апворке — часто менеджер соответствующего направления, а не владелец бизнеса. Т.е. он по своим профессиональным обязанностям — руководитель.
    Вообще с моей точки зрения руководящие должности надёжнее держать в штате, а аутсорсить уже непосредственно разработку и только конечным исполнителям. Во всяком случае, я бы делал именно так, хотя я сам — фрилансер а не владелец или заказчик.
    Вы просто исходите из того опыта, который был у вас. Но понятно, что люди которые с агентствами не хотят работать вам просто не попадаются. А их много, и далеко не всегда это продиктовано финансовыми соображениями.
  • Как мы начали работать на Upwork (личный опыт)
    0
    Когда пишут, что не хотят работать с агентствами — сразу понятно, что это скупердяи, к-е хотят сэкономить на руководителе проекта.

    Не соглашусь категорически. Во-первых, нужен ли какой-то отдельный руководитель проекту на 1-2 человек? Таких проектов довольно много. При этом у заказчика очевидно есть какой-нибудь менеджер, который по совместительству может быть и руководителем такого проекта.
    Во-вторых, часто заказчик сам является руководителем (особенно в случае стартапов, которых на апворке приличное количество). Очевидно, такой заказчик хочет напрямую общаться с разработчиком, а не с каким-то дополнительным руководителем, который ему в общем не нужен. Ну и платить соответственно только за разработчика.
    Ну и т.д. Много ситуаций, когда легче и полезнее нанять напрямую разработчика без «пятого колеса» в виде какого-то дополнительного руководителя.
  • Actor Open Messaging Platform от разработчика Telegram
    0
    Ну я примерно понимаю за что вам предыдущий аккаунт забанили.
    Такой поток неадеквата (на уровне неумения читать комментарии так как они написаны, а не как они вам привиделись) в ответ на вполне нейтральные (а вообще-то даже благожелательные изначально) по тону вопросы — это показатель того, что вам явно противопоказано общаться с аудиторией.
    В общем я в этом сеансе публичной психотерапевтии дальше участвовать не готов, так что adieu, далее оставляю тему в ваше полное распоряжение.
  • Actor Open Messaging Platform от разработчика Telegram
    0
    Ну я это предложил именно как относительно простой в реализации способ расширять почти произвольным образом UI, возможности чего я так понимаю сейчас нет.
    Ну то есть это концепция системы плагинов именно для фронтенд-части.
  • Actor Open Messaging Platform от разработчика Telegram
    0
    Ну вот гляньте мой комментарий к ветке ниже, не знаю насколько будет полезно в вашем конкретном случае, но в теории проблем с такой реализацией не вижу.
  • Actor Open Messaging Platform от разработчика Telegram
    0
    3. Много думаем над этим, но пока не очень понятно, как это сделать универсально.

    В теории довольно просто, не знаю насколько это так в применении к вашему конкретному случаю (могут быть какие-то ограничения со стороны реакта или вашей конкретной имплементации и т.д.): перед отрисовкой любого из основных элементов (контакт, сообщение и т.д.) кидаете эвент на который может подписаться внешний обработчик. Эвент синхронный, содержит логическое представление объекта (aka модель) и его html или dom-структуру. Во внешнем обработчике я могу отловить эвент и поменять html/dom по своему усмотрению. После этого происходит собственно отрисовка уже изменённого (ну или неизменённого если никто не менял) объекта.
  • Actor Open Messaging Platform от разработчика Telegram
    0
    Ну то есть модульность планируется всё-таки? Боюсь даже спрашивать когда и в каком объёме, чтобы не перевести снова разговор на вопрос о том насколько я увлечённый разработчик и сколько могу платить.
  • Actor Open Messaging Platform от разработчика Telegram
    +1
    Ну то есть: я могу взять любой опенсурсный проект, форкнуть его и на его базе создать новый. В этом вся суть опенсурса. Но это не делает из любого опенсурсного проекта платформу для создания <нужное подставить>.
    Но ещё раз, это чисто терминологическая претензия, никаких других вопросов у меня не осталось.
  • Actor Open Messaging Platform от разработчика Telegram
    0
    Нет, всё что я хотел выяснить я уже выяснил, в принципе можете дальше не объяснять, концепция понятна.
    Можем разве что поспорить по формулировкам, хотя думаю большой пользы в этом нет. Но: если я могу создать новый продукт на базе вашего только путём форка и изменения его кода — то это не платформа, а классический опенсурсный продукт.
  • Actor Open Messaging Platform от разработчика Telegram
    0
    И да, я не понял в какой момент и на каком основании разговор перешёл на деньги. Я что-то упустил в этом тексте?
    Actor OpenSource edition and Cloud solutions will be always free. We believe that communications can't have any limits.

    Или я уже что-то должен вам заплатить?
    В общем довольно странно вы реагируете на вопросы, которые вытекают из ваших же размытых формулировок.
  • Actor Open Messaging Platform от разработчика Telegram
    +2
    Слушайте, ну это несерьёзный ответ. Речь вообще не о том, полезно это или нет. Речь о том, что вы себя позиционируете как ПЛАТФОРМУ.
    Из ваших ответов я понимаю, что речь идёт не о платформе, а просто об опенсурсном мессенджере. Что тоже неплохо и полезно и т.д., но просто совершенно другая по сути вещь. Не было бы слова «платформа» в заголовке темы, я бы и вопросы эти задавать не стал.
  • Actor Open Messaging Platform от разработчика Telegram
    0
    Ну headless js библиотека — это понятно, она в принципе и не так нужна если есть нормальный API.
    Просто получается, что если нужна какая-то минимальная кастомная функциональность (не на уровне весь UI переписать, а буквально пару элементов добавить), есть всего два варианта:
    1) переписывать существующий код и получить кучу проблем с обновлением и т.д.
    2) вообще выкинуть существующий front-end код и писать его с нуля под себя
    Как-то оба варианта выглядят немного странно.
    Вот виджеты или компоненты или что-то такое — было бы хорошо. Или наоборот, гибкая система плагинов. То есть чтобы или 1) код актора можно было относительно безболезненно встроить в существующее окружение, или 2) наоборот, кастомную функциональность можно было дописать поверх существующего кода. Второй вариант выглядит лучше, т.к. предоставляет больше возможностей, но видимо сложнее в реализации.
  • Actor Open Messaging Platform от разработчика Telegram
    0
    Так это плохо: брать готовый код и переписывать под себя. Выйдет следующее обновление и начнёт конфликтовать с моим кастомным кодом. Это вроде очевидные вещи.
  • Actor Open Messaging Platform от разработчика Telegram
    +1
    Лучше всего сделайте несколько готовых примеров использования.
    Реквестирую вот такой: нужен мессенджер, интегрированный в некоторый абстрактный корпоративный портал.
    Интегрирован — это в плане:
    1. Использует уже существующие аккаунты
    2. Содержит элементы UI этого портала, ну в простейшем случае — главное меню хотя бы
    3. Скажем отображает какую-то кастомную информацию у контактов, вроде: должность, отдел, непосредственный руководитель
    4. Ну и получает какие-то хуки, хотя вот этот пункт я в документации как раз нашёл
    Если что-то из этого сейчас невозможно, планируется ли реализовывать?
  • Actor Open Messaging Platform от разработчика Telegram
    +4
    Вот да. Люди, опишите пожалуйста подробно с самого начала: что это вообще, зачем, что умеет и как с ним работать.
    На всякий случай: нет, сайт и документация на эти вопросы не отвечают.
  • Actor Open Messaging Platform от разработчика Telegram
    0
    Весь фронтенд написан на ReactJS

    В документации написано Angular, кому верить?
    actor.readme.io/docs/apps#section-web
  • Actor Open Messaging Platform от разработчика Telegram
    0
    А насколько это именно платформа? Пока я вижу скорее вполне конкретный готовый продукт, который, да, можно развернуть на своём сервере и т.д.
    А насколько реально создать на этой основе свой проект БЕЗ переписывания собственно кода актора? Ну или скажем встроить в существующую ERP или что-то подобное, желательно не iframe-ом.
  • Перевод документации RivetsJS
    +1
    Использую в качестве байндера в связке с Backbone на своём проекте, что хочу сказать: библиотека довольно сырая и глючная, плюс действительно подзаброшенная (см. предыдущие комментарии — там всё верно). Ну то есть к использованию не рекомендую, если только проект не совсем элементарный.
    Из однозначно хороших альтернатив — Ractive.js, умеет всё то же самое, только лучше, без лишних хаков и с меньшим количеством багов. Из недостатков — к сожалению, намного больший объём.
  • SourceTalk (сервис для обсуждения исходных кодов): релиз
    0
    Хорошо, постараюсь выпустить.
  • Стартап в одиночку: история проекта SourceTalk от хакатона до релиза
    0
    Ну вот по результатам публикаций на Хабре и Мегамозге уже почти 600 регистраций. Пока мне этого достаточно, дальше планирую более серьёзно заняться привлечением людей уже когда введу платные подписки.
    Из каналов — пока планирую попытаться засветиться где-нибудь в прессе плюс более активно займусь ведением блога, может ещё что-то, а там уже буду смотреть по результатам от чего больше пользы будет. Сейчас записался дополнительно на обучающий семинар для стартапов от ФРИИ у нас в Нижнем Новгороде, там в том числе маркетинг будет освещаться, может там что полезного почерпну.
    Такую фишку точно добавлю, считаю отличный ход. Это из гиттера же?
  • SourceTalk (сервис для обсуждения исходных кодов): релиз
    0
    На самом деле при удалённой разработке часто возникает задача просто обсудить какой-то кусок кода с коллегой. Решается обычно эта задача совершенно адскими методами от копирования кода в чат до демонстрации экрана. Вот это и есть основное предназначение.
    Из других вариантов применений — ревью, обучение новичков, собеседования. В меньшей степени парное программирование, тут да, скорее что-то другое нужно, флубитс вот есть.
  • SourceTalk (сервис для обсуждения исходных кодов): релиз
    –2
    > По умолчанию код весь и всегда проприетарный и вообще — чужая интеллектуальная собственность
    А про опенсурс вы ничего не слышали?

    > Показывать его в паблике нельзя никак, за это могут денег стрясти, лишить репутации, а особо неудачливых и свободы
    Я же специально прописал в статье, что закрытые конференции планируются в будущем.
  • SourceTalk (сервис для обсуждения исходных кодов): релиз
    0
    Возможно когда-нибудь будет, но пока нет.
  • SourceTalk (сервис для обсуждения исходных кодов): релиз
    0
    Можете. Точно так же вы можете создать открытый репозиторий на гитхабе и не давать никому на него ссылку. На практике скорее всего сработает, но безопасность вам при этом никто не гарантирует.
  • SourceTalk (сервис для обсуждения исходных кодов): релиз
    0
    Для участия в открытой вам нужна только ссылка. В ней кстати можно участвовать не имея аккаунта. Если кто-то такую ссылку опубликует на странице опенсурсного проекта например, в обсуждении сможет поучаствовать любой желающий.
    Для участия в закрытой нужно, чтобы вам специально выдали к ней доступ.
  • SourceTalk (сервис для обсуждения исходных кодов): релиз
    0
    Пока что все конференции могут быть только открытые, поэтому вы можете просмотреть/поучаствовать в любой, на которую вам дадут ссылку.
    Какого-то общего списка нет, не вижу в нём смысла.
  • SourceTalk (сервис для обсуждения исходных кодов): релиз
    0
    Ну вам наверное не слишком часто приходилось так делать. Крайне неудобно на самом деле.
  • SourceTalk (сервис для обсуждения исходных кодов): релиз
    0
    Возможно, но это не в ближайших планах.