Re: AMMY - XAML с человеческим лицом
От: s22  
Дата: 20.01.17 14:04
Оценка:
Возможно тупая идея (я не пишу на C# годы), но мне бы хотелось иметь абсолютные ссылки

TextBlock {
  viewmodel MyApp.SomeType

  Text Absolute {TextBlockText}: bind PropertyFromViewModel
}


при этом в коде вне зависимости от того куда я перенесу данный фрагмент (в том числе и рантайм, в том числе и пользователь) ссылка на элемент всегда будет TextBlockText
Re[3]: Косяки с точки зрения бизнеса (+)
От: alex_public  
Дата: 20.01.17 14:59
Оценка:
Здравствуйте, VladD2, Вы писали:

B>>С нормальным визуальным редактором,

VD>Не нужен никому этот редактор. Нельзя в нем полноценно отобразить MVVM-ые фичи вроде биндинга. Вот превью нужно. Но быстрое, а не те тормоза, что в Студии есть. И качественное. А то у меня редактор XAML постоянно падает.

Помнится когда-то давно мы с тобой спорили на эту тему. Так вот я сейчас посмотрел видео (из первого сообщения) и только ещё больше убедился в своей правоте. Результат, достигаемый этим инструментом в результате активной 25 минутной работы, я легко повторю другим инструментом (с продвинутым визуальным редактором) где-то за минуту ленивого шевеления мышкой.

P.S. Если что, это не претензия к обсуждаемому продукту. Продукт выглядит отлично, насколько это возможно при построение его вокруг такой сомнительной базы (WPF).
Re[4]: Косяки с точки зрения бизнеса (+)
От: Evgeny.Panasyuk Россия  
Дата: 20.01.17 15:09
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Так вот я сейчас посмотрел видео (из первого сообщения) и только ещё больше убедился в своей правоте. Результат, достигаемый этим инструментом в результате активной 25 минутной работы, я легко повторю другим инструментом (с продвинутым визуальным редактором) где-то за минуту ленивого шевеления мышкой.


О, у меня подобное ощущение возникло — как минимум начальный макет в нормальном визуальном редакторе получился бы быстрее, и из
этого макета можно было бы сгенерировать ту же самую human-friendly декларативную разметку для дальнейших модификаций, а то и вовсе двустороннюю связь.
Отредактировано 20.01.2017 15:13 Evgeny.Panasyuk . Предыдущая версия .
Re[2]: Косяки с точки зрения бизнеса (+)
От: licedey  
Дата: 20.01.17 20:01
Оценка:
Здравствуйте, bazis1, Вы писали:

B>P.S. Лучше бы кто-нибудь запилил XAML для сайтостроения. С нормальным визуальным редактором, strong typed binding-ами безо всяких angular-извращений, интеграцией в IDE и нормальной библиотекой контролов типа всяких TreeView. Вот это взлетит в отличие от.


C# for HTML5
Re[4]: AMMY - XAML с человеческим лицом
От: okon  
Дата: 21.01.17 05:06
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, ionoy, Вы писали:


I>>Циклы в XAML реализуются через ItemsControl и ItemTemplate, так что циклы не нужны.


IT>Сразу чувствуется школа Влада в общении с потенциальными пользователями


IT>Как мне без копипасты определить десять однотипных кнопок?


Написать руками если не хочется Ctrl-C, Ctrl-V использовать

Батон { "Рас"   }
Батон { "Два"   }
Батон { "Три"    }
Батон { "Читыре" }
Батон { "Пять"   }
Батон { "Шесть"  }
Батон { "Семь"   }
Батон { "Восемь" }
Батон { "Девять" }
Батон { "Десять" }



А как предполагалось бы сделать иначе ?
если вам кажется что я зарегистрировался ради именно этого поста то вам надо обратиться сюда http://podskazki.info/mnitelnost/
Re[5]: AMMY - XAML с человеческим лицом
От: _ABC_  
Дата: 21.01.17 06:21
Оценка:
Здравствуйте, okon, Вы писали:

O>Написать руками если не хочется Ctrl-C, Ctrl-V использовать

O>А как предполагалось бы сделать иначе ?

Наверное (чисто догадка), что-то типа такого.
лист = ["Рас", "Два", "Три", "Читыре", "Пять", "Шесть", "Семь", "Восемь", "Девять", "Десять"]
форич айтем ин лист:
    Батон { айтем }
Re[6]: AMMY - XAML с человеческим лицом
От: okon  
Дата: 21.01.17 13:12
Оценка:
Здравствуйте, _ABC_, Вы писали:

_AB>Здравствуйте, okon, Вы писали:


O>>Написать руками если не хочется Ctrl-C, Ctrl-V использовать

O>>А как предполагалось бы сделать иначе ?

_AB>Наверное (чисто догадка), что-то типа такого.

_AB>
_AB>лист = ["Рас", "Два", "Три", "Читыре", "Пять", "Шесть", "Семь", "Восемь", "Девять", "Десять"]
_AB>форич айтем ин лист:
_AB>    Батон { айтем }
_AB>


Про это вроде написали что есть такое и в хамле и соотвественно в аммле


лист = ["Рас", "Два", "Три", "Читыре", "Пять", "Шесть", "Семь", "Восемь", "Девять", "Десять"]

ИтемзЛист{ Соурс=лист, ИтемШоблон=Батон{ Капшен=датакантекст  } }
если вам кажется что я зарегистрировался ради именно этого поста то вам надо обратиться сюда http://podskazki.info/mnitelnost/
Re[7]: AMMY - XAML с человеческим лицом
От: WolfHound  
Дата: 21.01.17 13:59
Оценка:
Здравствуйте, ionoy, Вы писали:

I>
I>ItemsControl { 
I>  ItemsSource: bind Items
I>  ItemTemplate: DataTemplate {
I>    // здесь описываем произвольный шаблон
I>  }
I>}
I>

Вот эта конструкция тоже часто встречается.
ИМХО кандидат на сокращение
repeater Items { 
    // здесь описываем произвольный шаблон
}
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: AMMY - XAML с человеческим лицом
От: ionoy Эстония www.ammyui.com
Дата: 23.01.17 09:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, VladD2, Вы писали:


WH>Нужен специальный синтаксис для стилей.


Для стилей сейчас есть миксин #Setter:

Style {
  #Setter("Width", 100, "TargetName")
}


Плюс есть ключевое слово set, которое превращает все присвоения свойств внутри себя в сеттеры:

Style {
  set [
    Width: 100
    Height: 100
  ]
}


Правда set был убран, чтобы быстрее зарелизиться. Надо будет добавить его обратно.

WH>Тоже самое с триггерами


Триггеры решаются через алиасы:

@Trigger("IsSelected", true) {
  #Setter("Foreground", Green)
}


Ключевое слово set можно будет использовать и здесь.

Я когда начинал делать Ammy тоже везде искал места, где можно заменить кучку кода на микро-DSL. Тоже думал про стили, триггеры, ресурсы, анимации. Но чем дальше, тем больше я верю в то, что если есть возможность решить что-то базовыми средствами языка, то новый синтаксис добавлять не стоит. Да, сейчас миксины и алиасы пока не на том уровне, чтобы быть абсолютно на равне со специализированым синтаксисом, но им ничего не мешает стать таковыми.

Уже сейчас я вижу, что XAML платформ значительно больше, чем я предполагал. Большинство из них следуют основным принципам заложенным ещё при WPF: стили, триггеры, targettype и прочее. Но постепенно появляются отклонения, которые ломают back compatibility. Для того чтобы иметь возможность поддерживать любую XAML платформу надо быть гибким, а это значит по минимум хардкодить разметку с помощью ключевых слов. Те же миксины абсолютно ничего не знают о WPF, UWP и других вещах. Я уверен, что будь желание и можно было бы Ammy прикрутить хоть к HTML. Хочется двигаться в направлении, которое даст наибольшую гибкость, а значит возможность поддерживать любые бэкенды хоть отдалённо напоминающие XAML.

Кстати, одну такую "ошибку" я уже совершил с `bind`, который превращается в `<Binding />`. У UWP, например появился новый механизм биндинга, так что мне придётся выдумывать как их различать. Другое дело что именно биндинг практически нереально упростить используя миксины.

В любом случае, спасибо за предложения. Видно что ты их продумывал, а не просто с бухты барахты фичи реквестируешь.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[2]: AMMY - XAML с человеческим лицом
От: ionoy Эстония www.ammyui.com
Дата: 23.01.17 09:48
Оценка:
Здравствуйте, s22, Вы писали:

s22>Возможно тупая идея (я не пишу на C# годы), но мне бы хотелось иметь абсолютные ссылки


То есть создать ссылку на проперти у определённого контрола? А зачем это может быть нужно?
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[6]: AMMY - XAML с человеческим лицом
От: ionoy Эстония www.ammyui.com
Дата: 23.01.17 09:52
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Например в QML есть Repeater — наверное кому-то было необходимо

EP>
EP>Row {
EP>    Rectangle { width: 10; height: 20; color: "red" }
EP>    Repeater {
EP>        model: 10
EP>        Rectangle { width: 20; height: 20; radius: 10; color: "green" }
EP>    }
EP>    Rectangle { width: 10; height: 20; color: "blue" }
EP>}
EP>


Собственно ItemsControl это почти то же самое, только нельзя биндить число как количество повторений. Можно от него отнаследоваться и завернуть в alias:

alias repeat(times) {
  RepeatItemsControl {
    Times: $times
  }
}

Window "MainWindow" {
  @repeat(4) {
    TextBlock { "Привет." } 
    TextBlock { "Как дела?" } 
  }
}
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[3]: AMMY - XAML с человеческим лицом
От: WolfHound  
Дата: 23.01.17 15:16
Оценка:
Здравствуйте, ionoy, Вы писали:

I>Для стилей сейчас есть миксин #Setter:

Да я как раз после того как на эти миксыны посмотрел и написал это сообщение.
1)Куча визуального шума.
2)Нет интеллисенса.

I>Правда set был убран, чтобы быстрее зарелизиться. Надо будет добавить его обратно.

Значительно лучше миксинов. Но немного хуже моего варианта.
Ибо очень часто нужно будет присвоить одно или два свойства.

I>Триггеры решаются через алиасы:

Те же проблемы что с миксинами стеттеров.

I>Я когда начинал делать Ammy тоже везде искал места, где можно заменить кучку кода на микро-DSL. Тоже думал про стили, триггеры, ресурсы, анимации. Но чем дальше, тем больше я верю в то, что если есть возможность решить что-то базовыми средствами языка, то новый синтаксис добавлять не стоит. Да, сейчас миксины и алиасы пока не на том уровне, чтобы быть абсолютно на равне со специализированым синтаксисом, но им ничего не мешает стать таковыми.

Мы говорим про язык на основе нитры.
Нитра способна создавать модульные языки.
Что тебе мешает сделать базовый язык и сахар, который можно включать/выключать?
Собственно, это и есть одна из главных причин создания нитры.

I>Для того чтобы иметь возможность поддерживать любую XAML платформу надо быть гибким, а это значит по минимум хардкодить разметку с помощью ключевых слов.

А вот тут у меня прямо противоположное мнение.
Именно наличие специального синтаксиса позволяет произвольно изменять генерируемый код.
Это позволит использовать один код на разных WPF платформах.

Ну а если не получится, то как я уже говорил языки, созданные на нитре модульные.
И ничто не мешает сделать разный сахар для разных платформ.

I>Кстати, одну такую "ошибку" я уже совершил с `bind`, который превращается в `<Binding />`. У UWP, например появился новый механизм биндинга, так что мне придётся выдумывать как их различать. Другое дело что именно биндинг практически нереально упростить используя миксины.

Ключом компилятора.

I>В любом случае, спасибо за предложения. Видно что ты их продумывал, а не просто с бухты барахты фичи реквестируешь.

Я просто изучил столько языков что мне достаточно прочитать документацию чтобы выявить проблемы и показать пути их решения.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Косяки с точки зрения бизнеса (+)
От: kekekeks  
Дата: 27.01.17 22:30
Оценка:
VD> Раже авторы Xamarin-а и Avalon . Они просто твоего мнения наверно не успели прочитать.

Я являюсь одним из ключевых разработчиков AvaloniaUI и в некотором роде разделяю мнение вашего оппонента в части неодобрения выпуска этого счастья под закрытой лицензией. К самой технологии интерес у нас есть, да только вот мы как приличные люди всё выпускаем под MIT и не можем сторонние блобы с очень платными лицензиями интегрировать.
Re[4]: Косяки с точки зрения бизнеса (+)
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.01.17 01:16
Оценка:
Здравствуйте, kekekeks, Вы писали:

K>Я являюсь одним из ключевых разработчиков AvaloniaUI и в некотором роде разделяю мнение вашего оппонента в части неодобрения выпуска этого счастья под закрытой лицензией. К самой технологии интерес у нас есть, да только вот мы как приличные люди всё выпускаем под MIT и не можем сторонние блобы с очень платными лицензиями интегрировать.


Я как бы сам не рад по поводу закрытости. Мне бы тоже было бы приятнее, если бы исходники были открыты.

Но и автора я понимаю. Все же он вложил море времени. Его хочется хоть как-то окупить.

Что касается лицензий, то это как раз вопрос решаемый, я думаю. Тут можно легко договориться с автором.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Косяки с точки зрения бизнеса (+)
От: ionoy Эстония www.ammyui.com
Дата: 28.01.17 10:16
Оценка: 8 (2) +1
Здравствуйте, kekekeks, Вы писали:

K>Я являюсь одним из ключевых разработчиков AvaloniaUI и в некотором роде разделяю мнение вашего оппонента в части неодобрения выпуска этого счастья под закрытой лицензией. К самой технологии интерес у нас есть, да только вот мы как приличные люди всё выпускаем под MIT и не можем сторонние блобы с очень платными лицензиями интегрировать.


Честно говоря, мне надоело бросать проекты незаконченными из-за недостатка времени или мотивации. Поэтому, когда я начинал работу над Ammy, я сразу решил, что это будет моим основным источником дохода, чтобы можно было спокойно работать фулл-тайм и при этом не думать о том как прокормить семью. Последний год я работал в режиме 3 недели на Ammy, 1 неделя на подработки, чтобы заработать прожиточный минимум. Сейчас работаю с утра до вечера почти без выходных, всё для того чтобы максимально быстро исправлять баги и двигать проект вперёд.

По поводу лицензии, то, честно говоря, не вижу большой проблемы. Если ты пишешь что-то чисто для себя, без цели заработка, то пожалуйста, получай все плюшки Ammy забесплатно. Если же ты хочешь свой продукт продавать, то цена Ammy практически не повлияет на общую стоимость разработки. Если учесть налоги, то лицензия Ammy — это около 10% от стоимости одного разработчика, а то и меньше. И это ещё в разрезе зарплат СНГ. Если же ты разработчик одиночка, то за год разработки ты заплатишь чуть больше 200 долларов, что тоже не деньги, если продукт предназначен для получения прибыли.

Честное слово, я всеми руками за опен сорс. Все мои предыдущие проекты разрабатывались в открытом виде и были доступны всем желающим. Но до тех пор, пока я не буду уверен в стабильном будущем, я не могу открыть код Ammy.

Насчёт интеграции с AvaloniaUI. Совсем необязательно делать Ammy единственным возможным языком разметки, достаточно дать людям возможность подключать её по желанию. Собственно со всеми остальными платформами именно такой вариант и будет иметь место. На днях, например, постучался разработчик на NoesisGUI и мы с ним вдвоём довольно быстро сделали поддержку этого фреймворка. Теперь люди, которые пишут на NoesisGUI, могут подключить нугет пакет и пользоваться Ammy в своих приложениях.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[2]: Bazis1 - прав
От: rm822 Россия  
Дата: 28.01.17 22:16
Оценка:
У вас в категории why ammy — написана какая-то хрень неизвестно для кого.
* Free!
* Easy to learn
* XAML compatible
* Syntax meant for people
* Mixins and variables
* Realtime update
* Nuget package
* Visual Studio extension
* Good support


о чем и для кого все это?
какую мысль вы хотели донести?
где value для бизнеса?
детский сад, честное слово

Посмотрите хотя бы на постшарп
* Reduce development costs and deliver faster.
* Build more reliable software.
* Add functionality more easily after the first release.
* Help new team members contribute quicker.
всё бизнес, быстрее, лучше, проще
Re[5]: Косяки с точки зрения бизнеса (+)
От: bazis1 Канада  
Дата: 29.01.17 19:56
Оценка: +1
Здравствуйте, ionoy, Вы писали:

I>Честно говоря, мне надоело бросать проекты незаконченными из-за недостатка времени или мотивации. Поэтому, когда я начинал работу над Ammy, я сразу решил, что это будет моим основным источником дохода, чтобы можно было спокойно работать фулл-тайм и при этом не думать о том как прокормить семью. Последний год я работал в режиме 3 недели на Ammy, 1 неделя на подработки, чтобы заработать прожиточный минимум. Сейчас работаю с утра до вечера почти без выходных, всё для того чтобы максимально быстро исправлять баги и двигать проект вперёд.

Т.е. Вы потратили 9 месяцев фуллтайма на разработку продукта, имеете ноль продаж и вместо того, чтобы с головой погружаться в налаживание и оптимизацию воронки продаж, продолжаете пилить техническую сторону? Пожалуйста, оглянитесь по сторонам и прочитайте что-нибудь вроде классики. ИМХО, Вы наступаете на грабли, стоящие на пути у 100% шароварщиков с программистским прошлым и дальнейший успех вашего продукта практически полностью зависит от того, насколько быстро Вы смените менталитет с программистского на предпринимательский.

Вот у меня второй год подряд чешется шило в заднице сделать web-сервис, в котором можно будет просматривать исходники библиотек, как будто бы в Visual Studio. С go-to-definition, find all references, подсветкой использований переменной, раскрытием макросов, списком полей, function argument hints и переформатированием кода под ваш любимый стиль прямо на ходу. Технологии для этого у меня есть, нужно только месяцев 6 работы. И я второй год бью себя по рукам, ибо понимаю, что при всей крутости идеи, фиг я ее монетизирую, да еще и на хостинг, который потянет наш IntelliSense-движок, вбухаю безвозвратно кучу денег.

I>По поводу лицензии, то, честно говоря, не вижу большой проблемы. Если ты пишешь что-то чисто для себя, без цели заработка, то пожалуйста, получай все плюшки Ammy забесплатно. Если же ты хочешь свой продукт продавать, то цена Ammy практически не повлияет на общую стоимость разработки.

Разработчик-одиночка на стадии выбора инструмента имеет расплывчатую идею и ноль продаж. Не факт, что его шаровара в первый год принесет даже эти несчастные 200 долларов, поэтому уходить в минус ради абстрактного преимущества JSON над XML он не будет.
I> Если учесть налоги, то лицензия Ammy — это около 10% от стоимости одного разработчика, а то и меньше. И это ещё в разрезе зарплат СНГ. Если же ты разработчик одиночка, то за год разработки ты заплатишь чуть больше 200 долларов, что тоже не деньги, если продукт предназначен для получения прибыли.
Во-первых, 299 это чуть меньше, чем 300, а не чуть больше, чем 200. Во-вторых, вы лезете в игру, не понимая ее правил. Люди, которые имеют авторизацию потратить 3.5K в год, мыслят совершенно другими категориями, такими как corporate influence, budget spending, head count и т.п., и ваше сравнение с девелоперской зарплатой будет звучать как в том анекдоте:

- Почем яблоки?
— Штука баксов килограмм.
— А че так дорого?
— Да очень деньги нужны.


I>Честное слово, я всеми руками за опен сорс. Все мои предыдущие проекты разрабатывались в открытом виде и были доступны всем желающим. Но до тех пор, пока я не буду уверен в стабильном будущем, я не могу открыть код Ammy.

Пожалуйста, подумайте над моим советом в предыдущем посте. Сделайте плагин для студии, который сделает прозрачный edit-and-continue для обычного XAML. Баксов за 50 (единоразово + год апдейтов) это принесет вам достаточно пользователей при относительно небольших трудозатратах. Я сам буду одним из ваших первых клиентов, ибо тормоза штатного редактора достали и риска при таком раскладе ноль. А вот переписывать код с XAML на JSON я не буду, ибо ИМХО, это шило на мыло. И думаю, со мной согласится еще куча народа, использующего XAML.
Edit: упс, поздно.
Отредактировано 30.01.2017 7:20 bazis1 . Предыдущая версия . Еще …
Отредактировано 30.01.2017 7:20 bazis1 . Предыдущая версия .
Re[6]: Косяки с точки зрения бизнеса (+)
От: ionoy Эстония www.ammyui.com
Дата: 30.01.17 09:11
Оценка:
B>Т.е. Вы потратили 9 месяцев фуллтайма на разработку продукта, имеете ноль продаж и вместо того, чтобы с головой погружаться в налаживание и оптимизацию воронки продаж, продолжаете пилить техническую сторону? Пожалуйста, оглянитесь по сторонам и прочитайте что-нибудь вроде классики. ИМХО, Вы наступаете на грабли, стоящие на пути у 100% шароварщиков с программистским прошлым и дальнейший успех вашего продукта практически полностью зависит от того, насколько быстро Вы смените менталитет с программистского на предпринимательский.

Техническая сторона в данном случае — это исправление критических багов и расширение рынка. WPF — это малая часть XAML разработки, поэтому я и стараюсь как можно быстрее выйти на другие платформы. Насчёт смены менталитета, я полностью согласен, основной упор надо будет делать на маркетинг. Но продавать забагованный продукт тоже не хочется, поэтому первый месяц после релиза ушёл исключительно на исправление ошибок.

I>>По поводу лицензии, то, честно говоря, не вижу большой проблемы. Если ты пишешь что-то чисто для себя, без цели заработка, то пожалуйста, получай все плюшки Ammy забесплатно. Если же ты хочешь свой продукт продавать, то цена Ammy практически не повлияет на общую стоимость разработки.

B>Разработчик-одиночка на стадии выбора инструмента имеет расплывчатую идею и ноль продаж. Не факт, что его шаровара в первый год принесет даже эти несчастные 200 долларов, поэтому уходить в минус ради абстрактного преимущества JSON над XML он не будет.

Я бы с тобой согласился, если бы не "ради абстрактного преимущества JSON над XML".

I>> Если учесть налоги, то лицензия Ammy — это около 10% от стоимости одного разработчика, а то и меньше. И это ещё в разрезе зарплат СНГ. Если же ты разработчик одиночка, то за год разработки ты заплатишь чуть больше 200 долларов, что тоже не деньги, если продукт предназначен для получения прибыли.

B>Во-первых, 299 это чуть меньше, чем 300, а не чуть больше, чем 200. Во-вторых, вы лезете в игру, не понимая ее правил. Люди, которые имеют авторизацию потратить 3.5K в год, мыслят совершенно другими категориями, такими как corporate influence, budget spending, head count и т.п.

Уже запланирован ещё один пакет для маленьких компаний + bulk скидки.

Понимаю, что вы хотите помочь, но я тоже достаточно долго продумывал организацию всего этого дела. Поэтому хочу попробовать сделать так как считаю нужным. Если из этого ничего не выйдет, то у вас будет возможность сказать "I told you so", а если всё получится то будет хорошо всем, и мне, и Ammy, и проекту Nitra.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[5]: Косяки с точки зрения бизнеса (+)
От: kekekeks  
Дата: 02.02.17 14:30
Оценка:
>И это ещё в разрезе зарплат СНГ. Если же ты разработчик одиночка, то за год разработки ты заплатишь чуть больше 200 долларов, что тоже не деньги, если продукт предназначен для получения прибыли.

Маленький ньюанс касательно СНГ и ценовой политики. Xamarin в своё время стоил $25/мес с разработчика за целую платформу. Народ повсеместно пиратил. Я за цельный решарпер со всеми его анализаторами, профайлерами поддержкой в год $90 плачу. И когда предлагаю другим перестать его пиратить (хороший продукт же) на меня народ смотрит странно.

Да и для не-СНГ цены выглядят задраными на фоне тех, что приведены выше. Так что присоединяюсь к мнению остальных ораторов и настоятельно рекомендую найти продажника, который проанализирует рынок.
Re[6]: Косяки с точки зрения бизнеса (+)
От: ionoy Эстония www.ammyui.com
Дата: 02.02.17 14:49
Оценка:
K>Да и для не-СНГ цены выглядят задраными на фоне тех, что приведены выше. Так что присоединяюсь к мнению остальных ораторов и настоятельно рекомендую найти продажника, который проанализирует рынок.

Если я не ошибаюсь, то у Xamarin'а не было некоммерческой лицензии, так что там в любом случае надо было платить. За решарпер надо было платить разом, достаточно много, и бесплатной лицензии тоже не было.

Но может вы и правы, на данном этапе это цена несколько высоковата. Может региональные скидки добавить? Всё-таки возможности разработчиков СНГ и северной америки значительно отличаются.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.