Обновить
266
Куликов Алексей@clops

Пользователь

50
Подписчики
Отправить сообщение
Чёт мало платять гейм-разработчикам. Простая математика:

«Около 1000 человек работали над игрой в течение 3,5 лет — цена 100 000 000».

Это где-то 28 500 000 в год — это ВСЕГО 28 500$ в год на человека. Таких зарплат в развитом мире давно нет.

Не соглашусь — единоразовая работа должна стоить дорого (особенно если она напрямую влияет на обороты компании).
от 1 до 3 пусть будет ценой непопулярного софта :)

AllOFMp3 кажется как раз и продавали где-то по 10 центов за песню или доллар за альбом — как показала практика все ими очень удачно пользовались несмотря на то, что всю музыку можно было найти вовсе бесплатно!
Одна из основных проблем порождающих пиратство, мне кажется, это чрезмерно завышенная цена на конечный продукт. Не думаю, что студент будет платить 700 баксов за лицензию фотошопа и ему подобных.

Популярный (ключевое слово) софт должен стоить в диапазоне от 10 до 30 долларов — тогда возможность купить его имея при этом минимум геммороя будет превалировать над возможностью скачать имея весь с этим связанный геммор. Согласитесь, купить что-то обычно проще и, главное, быстрее чем найти–скачать–сломать–апгрейдить. На личном примере скажу, что покупаю весь софт, которым пользуюсь, благо в этом списке нет ни одного продукта дороже 29$ (включая операционную систему). Лично мне было проще один раз купить, чем постоянно гнаться за креками для обновлений и тд и тп.

Если говорить о музыке, то модель предложенная iTunes вполне прокатит — только ценники нужно опустить раз в 10 как минимум. Тогда и покупать будут все и всё на полную катушку. Та же фигня с электронными книгами.
Баян — это знают все кто хоть чуть-чуть интересовался поездами.
А что жались? Скажите, зачем оно в базовой установке делает 39 запросов к базе чтобы отрисовать _одну_ базовую страницу?
Поддерживаю. Хороший сервис стоит денег, 10-15-20-25-30 евро в месяц за соот-ее качество. Есть же известная поговорка, что дурак платит дважды, а скупой трижды.
Общеизвестный факт, что WordPress — тупое тормозное говно. Я не знаю что там нужно сделать чтобы 32 метра памяти сожрать, но оно это делает очень успешно и с завидным постоянством.
вот такая херь получается

не помогло :(
Зашибака — теперь я стал меньшим Лохе. А вы случаем не знаете как сделать так, чтобы не косячило шрифты? У меня часть на русском. часть на закорючках… грустняво :(
Я лохе — качаю wineskin, а там только 1 файл и никакого намёка на то, что на скриншоте в посте :( а таааак хочется Марьяж портировать, аж сил нет!

Много лет назад элегантно решил эту задачу следующим способом:

Есть основная «обычная» таблица foo(id, parent_id, label); на которой висит куча триггеров, которые уже «ведут» второстепенную таблицу foo_traversed(id, lft, rgt, level); таким образом никаких проблем с лочкой или непониманием со стороны нет. Запросы стандартных задачь делам либо через функции либо через LEFT JOIN
Готов платить и больше. Пользуемся сайтом всей семьёй почти каждый день.
Первый и достойный ответ по делу. Поддерживаю
отличный материал. на хабре, кстати, не хватает статей именно на тематику теоретического использования систем контроля версий
1) Ситуация исключена на организационном уровне. Клиентов готовят к тому, что их проект будет частью определённого релиза.

2) Релиз ветки, как явление, не содержат изменений вообще, только баг-фиксы. Все изменения в отдельных ветках, которые попадаю в trunk. Из него раз в месяц ответвляется новый релиз. Баг фиксы, соответственно, делаются только в релиз ветках (один раз) и пропагируют оттуда в trunk и другие ветки. Этим занимаются branch managers.

Вообще это стандартная практика. Release Driven Development.
не согласен — у нас в SVN репозитории сейчас 3 активных релиз бранча

0908 — это на продакшн сервере
0909 — в выходные будет go-live
0910 — это на следующий месяц, был ответвлён из trunk в эти выходные

по одному на каждый месяц. release maitainer каждое утро сливает все change setы — конфликтов за несколько лет работы практически не было.

выглядит это просто: утром запускается автоматические merges

0910->trunk->0909,0908
0909->trunk->0910,0908
0908->trunk->0909,0910

притом из-за специфика SVN мы переносим все changesets как одну ревизию кода. все разработки ведутся не в trunk а в отдельных ветках, которые потом вливаниются в trunk перед тем как создаётся новая релиз ветка.
столбы приравниваются к релизам. релиз — это отдельная ветка от транка и он довольно долго обкатывается прежде чем попасть в продакшн

Информация

В рейтинге
Не участвует
Откуда
Австрия
Дата рождения
Зарегистрирован
Активность