Pull to refresh
58
0
Олег Калистратов @malroc

User

Send message
1-3: так или иначе поддерживается: прокрутка и выделение в файле синхронизируются между всеми пользователями. То есть выделяете нужный вам участок (это все видят) и пишете в чат что хотите о нём сказать.
4: скорее всего будет в том или ином виде, это разумно, да
Смотрите.
1. Ценовой политики пока нет никакой, т.к. сейчас выпущена только бесплатная версия. Она включает в себя возможность создания только открытых конференций (с доступом к открытым репозиториям на гитхабе) и рассчитана в первую очередь на Open Source-разработку. Эта часть всегда будет бесплатной. Цены для платной подписки (где будут поддерживаться закрытые конференции с доступом к закрытым репозиториям) пока обдумываются, но скорее всего базовый тариф будет на уровне нескольких долларов в месяц.
2. Работает с недочётами, недочёты исправляются :) Большинство из них будет исправлено к моменту введения платной подписки. Это не должно закрыться по той причине которую я указал: содержание всего проекта обходится мне очень дёшево, поэтому мне нет никакого резона его закрывать. Как только наберётся пул из некоторого небольшого количества платных пользователей, проект будет для меня прибыльным.
3. Логических ограничений нет, могут быть только технические связанные с нагрузкой на сервер. От последних тоже постепенно избавимся по мере появления первых платных пользователей и возможности использовать более дорогие варианты хостинга.
Да, сервис рассчитан в первую очередь на обсуждение в реальном времени. То есть предполагается что все участники чата видят обсуждаемый код, поэтому цитирование поддерживается, но по большому счёту и оно не обязательно.
Возможность как-то на более длительное время сохранять привязку кода и обсуждения (например в виде отправки комментариев на GitHub) много раз обсуждалась, но пока однозначно удобного варианта с которым не было бы проблем с точки зрения понятности и удобства для пользователя не просматривается.
Надеюсь вы всё ещё следите за этой публикацией.
Такой вопрос. Нужна возможность получить статический URL для расшаренной картинки которая хранится на диске. Не публичную ссылку, тут всё понятно, а URL самой картинки, чтобы встроить потом тэгом IMG в HTML.
Внятного способа это сделать не нашёл. Из хаков:
1) превью — не подходит потому что требует авторизации
2) ссылка на скачивание — в принципе подходит, но я смотрю они генерируются всё время разные, в связи с чем вопрос: эти ссылки на скачивание постоянные или перестают действовать через какое-то время?
Если ссылки на скачивание вечные, то вопрос закрыт, этот вариант меня в принципе устраивает. Если нет, то нет ли какого-то другого способа?
Или лучше вообще Яндекс.Диск для таких целей не использовать, а использовать Яндекс.Фотки например?
Ну вот да, это вроде по-человечески выглядит. Но насколько я понимаю, перспективы довольно туманные на фоне всеобщей любви к реакту? Ну то есть реакт-то понятно что теперь будут поддерживать, всё-таки это фейсбук, да и сообщество уже приличное набралось. А тут как-то сильно меньше уверенности.
Вроде слышал что начиная с определённого уровня сложности приложения приходится «бороться» с фреймворком. Ну то есть чтобы вот здесь сделать не так, а немного по-другому, а фреймворк не даёт, он лучше знает. Нет такого?
Ну вот пишет-пишет и всё никак ничего приличного не напишет. Серверный рендеринг так вроде и не сделали по-человечески до сих пор. Хотя казалось бы очевидная вещь, если уж код изоморфный. На Дерби это есть чуть ли не с самого начала.
Нет, так понятно что на JavaScript эти вьюхи писать невозможно при сколько-нибудь серьёзном объёме. Почему собственно вот это их «никаких шаблонов, только JavaScript» — полнейшая ерунда, JSX те же шаблоны, только уродливые (со смешиванием JS и HTML ещё и без явных разграничений).
Или я может один такой эстет и остальным это не принципиально?
О, неужто я когда-нибудь доживу до WYSIWYG-редакторов и подсветки синтаксиса без подключения кошмарных библиотек циклопических размеров?
Я всё хочу спросить, как люди которые с React работают уживаются с этим кошмарным синтаксисом (JSX который)? Тем более после Slim.
Я как на него посмотрю, так сразу пропадает желание учить React. Хотя задумка вроде хорошая.
Derby не смотрели? Просто если речь о Метеоре зашла (который сколько я его помню, а этом минимум года два, «многообещающий но сырой»), то вроде Дерби намного приличнее смотрится (менее костыльный и не такой сырой), но сам пока его не пробовал.
Всё так, если работаете только с рублями. С валютой начинается головная боль, потому что в интернет-банке нет большей части документов, необходимых для валютного контроля, их приходится заполнять руками в ворде и довольно легко что-то заполнить не так.
Ну теоретически его можно совместить с логином/паролем пользовательских аккаунтов с соответствующим разграничением по правам доступа.
Это контрпример, который опровергает ваше утверждение. Всё остальное — ваша попытка уйти от признания этого простого факта.
Потом, даже если считать всё кроме Basecamp провалом — извините, а сколько было провальных проектов у Google? До сих пор поиск — их основной продукт.
Для команды из нескольких человек создать многомиллионный бизнес и занять на своём рынке второе место между, на минуточку, Microsoft и Atlassian — это такая степень успеха, о которой большинство компаний могут только мечтать.
RoR — побочный продукт разработки Basecamp. А у Basecamp безусловно были сроки и бюджеты.
Хотя не очень понятно, к чему вообще этот вопрос, если речь об успешности, а RoR более чем успешен — и сам по себе, и в плане оказанного на сообщество влияния.
Эти разработки приносили доход. Этого более чем достаточно, чтобы судить об успешности продукта. Так что нет, не провалились. Тот же Highrise вывели в отдельную компанию например.
А про Ruby on Rails вы как умудрились забыть? Это тоже провал видимо? Программисты-удалёнщики создали фреймворк, фактически определивший архитектуру большинства современных веб-фреймворков.
Давайте я сразу это озвучу, прежде чем вы очередной простынёй разродитесь.
Успешность программного продукта зависит от:
— ситуации на рынке (наличия запроса, актуального или потенциального и ситуации с конкурентами)
— маркетинга (в широком смысле, не буду отдельно по составляющим раскладывать)
— дизайна (тоже в широком смысле)
— и где-то вот на четвёртом месте — архитектуры
Продукт с хорошей архитектурой может не быть популярным, а продукт с плохой архитектурой может быть. Например, если рынок уже прочно поделен, никакая архитектура уже не поможет вывести на него новый продукт.
А то у вас как-то всё в кучу смешалось.
Вы говорите об успешности продукта. Который к собственно архитектуре имеет отношение очень условное. Или маркетинг — это у вас тоже архитектура?
Удел удалёнки — типовые несложные проекты в фирме, которая может себе позволить провал любого из них. Тут — да, она позволяет экономить. За счёт качества, разумеется. Всё.

Вы сейчас свои фантазии озвучиваете. 37 Signals тому доказательство (тем более что критерий у вас один — популярность).
Не будут. К моменту когда вы точно знаете чего из себя человек представляет может быть уже поздно.

Не обязательно знать точно, достаточно с высокой вероятностью. А этого можно добиться быстро.

Information

Rating
Does not participate
Location
Нижний Новгород, Нижегородская обл., Россия
Registered
Activity