О том я и говорю, что там идет просто соотношение цена/качество. Время когда LCD мониторы были дорогими и была проблема найти за нормальные деньги с хорошей картинкой и временем отклика — давно прошло.
Справедливости ради — у них и довольно средненькие мониторы есть. В офисе стояли широкоформатные на 20+" с крайне паршивыми углами обзора. Так что тут вернее всего будет говорить о соотношении цена/качество ;)
Возможно, я не разделяю мнения большинства по этому вопросу, но железной кнопкой камеры я на Xperia Neo V никогда не пользовался — при нажатии есть вероятность, что телефон слегка дернется. А поскольку эта кнопка довольно тугая, вероятность этого очень даже высока. В отличие железной кнопки — софтовая не имеет такой 'проблемы'.
Я не берусь точно говорить, что именно сыграло роль в данном случае, но аргументы обычно такие:
1) Если я не ошибаюсь — для Git, в отличие от SVN, не предусмотрено готовой библиотеки имеющией 'нормальное' API. Плагин для SVN (Subclipse) к Eclipse как раз использует нативные библиотеки, как основной вариант (но можно переключиться на использование pure java имплементации).
Сценарий интеграции с внешними утилитами через запуск исполняемого файла и считывание его потоков вывода всегда менее удобно и надежно, чем работа через полноценое API. У тому же накладывает ряд органичений. Разработчики всегда избегают данного варианта, если имеется такая возможность.
2) При наличии библиотеки ее лицензия может быть не совместима с лицензией продукта для которой пишется плагин (вроде бы это не наш случай).
3) Как уже отмечали выше — гарантировать, что плагин для Eclipse будет работать на всех платформах, на которых будет работать сам Eclipse.
Таким образом создание JGit дало два значимых плюса:
1) Создание более удобного и главное — надежного способа работы с ним.
2) Избавление пользователя от необходимости ставить Git, так как это может быть не совсем тривиально — как в случае с windows. Ведь в случае ошибки при установке бочку будут катить на плагин и на то, как сложно с ним работать.
Из минусов реимплементации Git — гланым является то, что работает он немного не так как оригинальный. Я наталкивался на небольшие отличия при мерже веток и отслеживании истории переименованых файлов. Но это мелочи, которыми можно пренебречь. Плюсы JGit, в виде удобной и экономящей время библиотеки для java разработчиков, — перевешивают все эти незначительные минусы.
Удобней всего для Java использовать скриптовые языки которые изначально поддерживают Java scripting API. Например Groovy и BeanShell. Мы использовали вполне успешно и тот и другой в проектах. Последнее время предпочтение отдается Groovy. На офсайтах обоих проектов есть довольно подробное описание с примерами использования.
Деньги вырученые за starter лицензии уходят некоммерческой организации Room to Read:
100% of monies raised from Starter licenses will be donated to Room to Read, who help improve education in the developing world by establishing libraries, schools and more. Atlassian will absorb all transaction costs.
Будет выведено «B.f() called».
Насмотря на то, что из конструктора класса B было брошено исключение — конструктора класса A отработал и staticInstance был инициализирован.
Статические члены класса не завязаны на его инстансы.
Поскольку мы создавали объект класса B, то staticInstance указывает именно на него и будет вызван метод, который мы переопределили в B (в java все методы виртуальны). Другая картина бы была, если бы мы объвили метод f, как static (в этом случае мы увидили бы «A.f() called»).
Ежу понятно, что речь идет не о игрушке - не удержался утрировать последствия появления такой вещи :)
Единственный момент, который хочется немного прояснить — где именно будет проявлять себя «Turn Based Management» и какие принципиальные отличия будут получены от того, процесса, который например реализован в MS Project?
Формализация не является большой проблемой. Можно обратиться к уже существующим методологиям управления проектами, коих хватает: RUP, PRINCE2 или Six Sigma основывающейся на мат моделировании. Недостатка в них нет. База, на которой может быть создана «экономическая модель» уже есть. Остается только разобраться с параметрами разработчиков. Тут необходимо обеспечить возможность снятия метрик с задач уже выполненных разработчиком (длительность выполнения определенных типов задач, качество измеренное по каким-то критериям и т.п).
Зато как шикарно будут смотреться объявления в банках вакансий: «Трудоустроим геймеров со стажем! Требования: опыт игры за индусов/зергов». Корейцы будут вне конкуренции, а Blizzard будет рвать волосы на жопе после оттока игроков StarCraft II.
Посмотри Final Fantasy VII Advent Children. Шокировать, в плане сюжета, оно тебя не будет, но графика не слабее. Если тебе понравился Spirits Within, то порцию положительных эмоций получишь :)
О том я и говорю, что там идет просто соотношение цена/качество. Время когда LCD мониторы были дорогими и была проблема найти за нормальные деньги с хорошей картинкой и временем отклика — давно прошло.
1) Если я не ошибаюсь — для Git, в отличие от SVN, не предусмотрено готовой библиотеки имеющией 'нормальное' API. Плагин для SVN (Subclipse) к Eclipse как раз использует нативные библиотеки, как основной вариант (но можно переключиться на использование pure java имплементации).
Сценарий интеграции с внешними утилитами через запуск исполняемого файла и считывание его потоков вывода всегда менее удобно и надежно, чем работа через полноценое API. У тому же накладывает ряд органичений. Разработчики всегда избегают данного варианта, если имеется такая возможность.
2) При наличии библиотеки ее лицензия может быть не совместима с лицензией продукта для которой пишется плагин (вроде бы это не наш случай).
3) Как уже отмечали выше — гарантировать, что плагин для Eclipse будет работать на всех платформах, на которых будет работать сам Eclipse.
Таким образом создание JGit дало два значимых плюса:
1) Создание более удобного и главное — надежного способа работы с ним.
2) Избавление пользователя от необходимости ставить Git, так как это может быть не совсем тривиально — как в случае с windows. Ведь в случае ошибки при установке бочку будут катить на плагин и на то, как сложно с ним работать.
Из минусов реимплементации Git — гланым является то, что работает он немного не так как оригинальный. Я наталкивался на небольшие отличия при мерже веток и отслеживании истории переименованых файлов. Но это мелочи, которыми можно пренебречь. Плюсы JGit, в виде удобной и экономящей время библиотеки для java разработчиков, — перевешивают все эти незначительные минусы.
100% of monies raised from Starter licenses will be donated to Room to Read, who help improve education in the developing world by establishing libraries, schools and more. Atlassian will absorb all transaction costs.
Насмотря на то, что из конструктора класса B было брошено исключение — конструктора класса A отработал и staticInstance был инициализирован.
Статические члены класса не завязаны на его инстансы.
Поскольку мы создавали объект класса B, то staticInstance указывает именно на него и будет вызван метод, который мы переопределили в B (в java все методы виртуальны). Другая картина бы была, если бы мы объвили метод f, как static (в этом случае мы увидили бы «A.f() called»).
Остается, только понять что именно революционного и предложенной идее.
Единственный момент, который хочется немного прояснить — где именно будет проявлять себя «Turn Based Management» и какие принципиальные отличия будут получены от того, процесса, который например реализован в MS Project?
Зато как шикарно будут смотреться объявления в банках вакансий: «Трудоустроим геймеров со стажем! Требования: опыт игры за индусов/зергов». Корейцы будут вне конкуренции, а Blizzard будет рвать волосы на жопе после оттока игроков StarCraft II.