Я всё хочу спросить, как люди которые с React работают уживаются с этим кошмарным синтаксисом (JSX который)? Тем более после Slim.
Я как на него посмотрю, так сразу пропадает желание учить React. Хотя задумка вроде хорошая.
Derby не смотрели? Просто если речь о Метеоре зашла (который сколько я его помню, а этом минимум года два, «многообещающий но сырой»), то вроде Дерби намного приличнее смотрится (менее костыльный и не такой сырой), но сам пока его не пробовал.
Всё так, если работаете только с рублями. С валютой начинается головная боль, потому что в интернет-банке нет большей части документов, необходимых для валютного контроля, их приходится заполнять руками в ворде и довольно легко что-то заполнить не так.
Потом, даже если считать всё кроме Basecamp провалом — извините, а сколько было провальных проектов у Google? До сих пор поиск — их основной продукт.
Для команды из нескольких человек создать многомиллионный бизнес и занять на своём рынке второе место между, на минуточку, Microsoft и Atlassian — это такая степень успеха, о которой большинство компаний могут только мечтать.
RoR — побочный продукт разработки Basecamp. А у Basecamp безусловно были сроки и бюджеты.
Хотя не очень понятно, к чему вообще этот вопрос, если речь об успешности, а RoR более чем успешен — и сам по себе, и в плане оказанного на сообщество влияния.
Эти разработки приносили доход. Этого более чем достаточно, чтобы судить об успешности продукта. Так что нет, не провалились. Тот же Highrise вывели в отдельную компанию например.
А про Ruby on Rails вы как умудрились забыть? Это тоже провал видимо? Программисты-удалёнщики создали фреймворк, фактически определивший архитектуру большинства современных веб-фреймворков.
Давайте я сразу это озвучу, прежде чем вы очередной простынёй разродитесь.
Успешность программного продукта зависит от:
— ситуации на рынке (наличия запроса, актуального или потенциального и ситуации с конкурентами)
— маркетинга (в широком смысле, не буду отдельно по составляющим раскладывать)
— дизайна (тоже в широком смысле)
— и где-то вот на четвёртом месте — архитектуры
Продукт с хорошей архитектурой может не быть популярным, а продукт с плохой архитектурой может быть. Например, если рынок уже прочно поделен, никакая архитектура уже не поможет вывести на него новый продукт.
А то у вас как-то всё в кучу смешалось.
Удел удалёнки — типовые несложные проекты в фирме, которая может себе позволить провал любого из них. Тут — да, она позволяет экономить. За счёт качества, разумеется. Всё.
Вы сейчас свои фантазии озвучиваете. 37 Signals тому доказательство (тем более что критерий у вас один — популярность).
Не будут. К моменту когда вы точно знаете чего из себя человек представляет может быть уже поздно.
Не обязательно знать точно, достаточно с высокой вероятностью. А этого можно добиться быстро.
Нет, там не во времени дело. Я читал как-то давно про эту проблему, точно всё не перескажу, но примерно смысл в том, что там архитектурно у UI-слоя средний приоритет заложен, поэтому какое-нибудь качающееся обновление вполне могло оказаться для системы более важным, чем графический интерфейс ответа на звонок.
Потом, у первых iPhone таких проблем не было насколько я помню.
В общем, это именно архитектурная проблема.
Ну конечно они связаны с архитектурой. С чем же ещё?
Ну очевидно с 1) UX (в меньшей степени) 2) временем выхода на рынок (в большей)
Да, я знаю про PocketPC и Windows Mobile, там был целиком пункт 1. А с WP 8 уже 2, то есть когда всё сделали более-менее по уму, было уже поздно.
А люди, которым некомфортно заниматься разработкой строго по бумажке — сделали Android
В смысле, тот самый Android, который во второй версии жутко начинал тормозить при попытке ответить на звонок (в итоге ответить получалось не всегда, без всяких шуток)? Я то есть не знаю, как там с этим сейчас, но несколько лет назад Android у меня был, говорю со своего личного опыта. Проблем явно архитектурного характера там хватало. Между прочим, система года три на рынке была к этому времени.
У Windows Phone проблемы есть, но связаны-то они как раз не с архитектурой. Во всяком случае, на бюджетном виндофоне у жены проблем со звонками никогда не наблюдалось.
Ну так вы определитесь, либо искусство, либо «не умеют».
Где искусство — там и формальные критерии не нужны. Где нужны, их всегда можно ввести (да, они будут неидеальными, но своё дело делать будут).
Вот и весь мой несложный посыл.
Тогда тем более о чём речь? Правильный менеджер вычислит бездельника и без формальных признаков. Я просто привёл схему, которая точно работать будет (да, со сбоями и недостатками, но бездельников она отсеет).
Ещё раз, прочитайте пожалуйста, с чего начиналась эта ветка и о чём в ней речь.
На всякий случай, упрощаю вам задачу, отвечал я вот на эти два тезиса:
пункт про Эффективность — это описание ситуации, когда человек хочет работать.
А я говорю про ситуации, когда человек «ездит по ушам». В офисе сложно ездить по ушам, на удаленке — просто.
Проблема в том, что в офисе нужно очень мало времени, чтобы поймать сотрудника на раздолбайстве.
На удаленке «профессионал» по ушам может ездить очень и очень долго.
Я как на него посмотрю, так сразу пропадает желание учить React. Хотя задумка вроде хорошая.
Для команды из нескольких человек создать многомиллионный бизнес и занять на своём рынке второе место между, на минуточку, Microsoft и Atlassian — это такая степень успеха, о которой большинство компаний могут только мечтать.
Хотя не очень понятно, к чему вообще этот вопрос, если речь об успешности, а RoR более чем успешен — и сам по себе, и в плане оказанного на сообщество влияния.
А про Ruby on Rails вы как умудрились забыть? Это тоже провал видимо? Программисты-удалёнщики создали фреймворк, фактически определивший архитектуру большинства современных веб-фреймворков.
Успешность программного продукта зависит от:
— ситуации на рынке (наличия запроса, актуального или потенциального и ситуации с конкурентами)
— маркетинга (в широком смысле, не буду отдельно по составляющим раскладывать)
— дизайна (тоже в широком смысле)
— и где-то вот на четвёртом месте — архитектуры
Продукт с хорошей архитектурой может не быть популярным, а продукт с плохой архитектурой может быть. Например, если рынок уже прочно поделен, никакая архитектура уже не поможет вывести на него новый продукт.
А то у вас как-то всё в кучу смешалось.
Вы сейчас свои фантазии озвучиваете. 37 Signals тому доказательство (тем более что критерий у вас один — популярность).
Не обязательно знать точно, достаточно с высокой вероятностью. А этого можно добиться быстро.
Потом, у первых iPhone таких проблем не было насколько я помню.
В общем, это именно архитектурная проблема.
Ну очевидно с 1) UX (в меньшей степени) 2) временем выхода на рынок (в большей)
Да, я знаю про PocketPC и Windows Mobile, там был целиком пункт 1. А с WP 8 уже 2, то есть когда всё сделали более-менее по уму, было уже поздно.
В смысле, тот самый Android, который во второй версии жутко начинал тормозить при попытке ответить на звонок (в итоге ответить получалось не всегда, без всяких шуток)? Я то есть не знаю, как там с этим сейчас, но несколько лет назад Android у меня был, говорю со своего личного опыта. Проблем явно архитектурного характера там хватало. Между прочим, система года три на рынке была к этому времени.
У Windows Phone проблемы есть, но связаны-то они как раз не с архитектурой. Во всяком случае, на бюджетном виндофоне у жены проблем со звонками никогда не наблюдалось.
Где искусство — там и формальные критерии не нужны. Где нужны, их всегда можно ввести (да, они будут неидеальными, но своё дело делать будут).
Вот и весь мой несложный посыл.
Тогда тем более о чём речь? Правильный менеджер вычислит бездельника и без формальных признаков. Я просто привёл схему, которая точно работать будет (да, со сбоями и недостатками, но бездельников она отсеет).
На всякий случай, упрощаю вам задачу, отвечал я вот на эти два тезиса: