«Эд Бёрнет (называющий себя разработчиком-экспертом и не считающий таковым Флориана Мюллера) написал в ZDNet, что изучил все файлы, описанные Мюллером, и пришёл к совершенно иному выводу.
Итак, вопрос заключается в двух группах файлов.»
может я, конечно, придираюсь, но по тексту создается ощущение, что весь текст после «итак...» — это анализ автора поста. А по факту — это перевод заключений Эда Бёрнета.
«Этого достаточно — если Google нарушила GPL изменением лицензии, то и нарушила авторские права Oracle.»
Да, достаточно, чтобы сказать, что Google виновны. Но тут ведь важнее другой вопрос, какой ущерб нанесен, и что может требовать Oracle за нарушения. А вот в споре за размер компенсации весьма важное значение будет иметь ценность этих файлов и то, как они использовались.
Я не юрист, но мне кажется, что если это просто тесты, то _проценты_ от прибыли гугла с андроидов оракл требовать не вправе.
А пару миллионов долларов единовременно гугл отдаст без особых проблем, если именно этим все и закончится.
да ладно.
а вы ДО написания кода на 100% уверены во всех его интерфейсах?
Писать тесты «до» — хорошо, кто ж спорит. но для этого надо сесть и в деталях продумать интерфейсы шагов на 5 вперед. Потому что если тесты уже написаны, а когда дело дошло до кода выясняется, что так «неудобно», а чуть-чуть по-другому и всё уже замечательно, переписывать придется все «уже готовые» тесты.
И приходим к известной дилеме «прототипирование vs проектирование». Что подчас быстрее написать прототип модуля, по ходу столкнувшись с проблемами и получив в итоге хорошие и цельные интерфейсы, и потом уже протестировать эти интерфейсы.
Никто при этом не говорит, конечно, что проектировать — плохо.
Так что я бы на вашем месте удержался от «унижения» тех, кто, с вашей точки зрения, не достиг еще дзена. Потому что у «недостигших» тоже есть свои аргументы.
cyanogen mod.
Имхо, нисколько не сырая, перейдя с 2.1 заметил только повышение в скорости :) Никаких отрицательных моментов, кроме, конечно, переустановки всех приложений, потому что «обнулять» телефон надо полностью с форматированием разделов — для пущего быстродействия.
ну и процессор и спики таки помощнее будет :)
angry birds на отлично, а судя по топику на лыже всё не так хорошо
А еще лучше, если у вас и задача отрисовки графиков, и задача подсчета статистики «логикоёмки», чтобы они друг о друге не знали вообще.
Задача организации взаимодействия в таком случае — это отдельная зона ответственности и лучше, когда её выполняет отдельный объект. Как доп. плюс в этом случае — взаимодействие лучше продумывается, и идёт обмен законченными структурами данных, а не «по кускам». И тестируются обе части замечательно.
Но это, конечно, применимо не в случаях, где и View и контроллер достаточно сложны.
А статья хороша, хотя бы как повод вспомнить о «добром и вечном» :)
Автоматизировал «работу» с игрушкой одной, достаточно популярной. Начинал с AutoIt, но как раз встроенные достаточно бедные возможности OCR и стали преградой.
В итоге написал небольшую обертку над винапи, имитирующие движения мыши/нажатия клавиш, и «универсальную», в рамках моих целей, библиотеку автоматизации процесса автоматизации :) Если кратко — то суть в разбивке всего процесса на шаги, где каждый шаг сводится к нахождению области на экране (простейший OCR) и выполнению действия (мышь/кнопка).
Потратив однажды пару дней, автоматизация шага теперь проходит за пару минут — добавлением класса с параметрами поиска. С#. Поначалу задумывался над выкладыванием в опен-сорс, но в такой специфичной области наврядли кто-то будет использовать чьи-то сторонние поделки, когда нет уверенности что поделка «подойдет» и отсутствует коммьюнити :)
Кстати, у того же AutoIt есть AutoItX — ActiveX библиотека для использования в своих разработках… но неудобство собственно ActiveX (регистрация на пользовательских компах) перевесила изначальное нежелание писать своё :)
было бы очень клёво всё-таки указать их производительность относительно друг друга. Если у вас есть такие данные, поделитесь, пожалуйста :) Критерий производительноти для многих будет очень важен, а ультра-большой набор данных, как в вашем случае, актуален не для всех
Сам галку Enable NTLM отключил и ввожу пароль руками, потому что так хотя бы работает… но неудобно ведь!
Итак, вопрос заключается в двух группах файлов.»
может я, конечно, придираюсь, но по тексту создается ощущение, что весь текст после «итак...» — это анализ автора поста. А по факту — это перевод заключений Эда Бёрнета.
Да, достаточно, чтобы сказать, что Google виновны. Но тут ведь важнее другой вопрос, какой ущерб нанесен, и что может требовать Oracle за нарушения. А вот в споре за размер компенсации весьма важное значение будет иметь ценность этих файлов и то, как они использовались.
Я не юрист, но мне кажется, что если это просто тесты, то _проценты_ от прибыли гугла с андроидов оракл требовать не вправе.
А пару миллионов долларов единовременно гугл отдаст без особых проблем, если именно этим все и закончится.
насколько сильны завязки? хочу попробовать портировать под 2.0 и интересно, достаточно ли переработать linq, или завязано глубже?
а вы ДО написания кода на 100% уверены во всех его интерфейсах?
Писать тесты «до» — хорошо, кто ж спорит. но для этого надо сесть и в деталях продумать интерфейсы шагов на 5 вперед. Потому что если тесты уже написаны, а когда дело дошло до кода выясняется, что так «неудобно», а чуть-чуть по-другому и всё уже замечательно, переписывать придется все «уже готовые» тесты.
И приходим к известной дилеме «прототипирование vs проектирование». Что подчас быстрее написать прототип модуля, по ходу столкнувшись с проблемами и получив в итоге хорошие и цельные интерфейсы, и потом уже протестировать эти интерфейсы.
Никто при этом не говорит, конечно, что проектировать — плохо.
Так что я бы на вашем месте удержался от «унижения» тех, кто, с вашей точки зрения, не достиг еще дзена. Потому что у «недостигших» тоже есть свои аргументы.
Имхо, нисколько не сырая, перейдя с 2.1 заметил только повышение в скорости :) Никаких отрицательных моментов, кроме, конечно, переустановки всех приложений, потому что «обнулять» телефон надо полностью с форматированием разделов — для пущего быстродействия.
ну и процессор и спики таки помощнее будет :)
angry birds на отлично, а судя по топику на лыже всё не так хорошо
Задача организации взаимодействия в таком случае — это отдельная зона ответственности и лучше, когда её выполняет отдельный объект. Как доп. плюс в этом случае — взаимодействие лучше продумывается, и идёт обмен законченными структурами данных, а не «по кускам». И тестируются обе части замечательно.
Но это, конечно, применимо не в случаях, где и View и контроллер достаточно сложны.
А статья хороша, хотя бы как повод вспомнить о «добром и вечном» :)
На опыте некоторых других аппаратов — лично мне «хардварных» кнопок не хватает. Даже в айфоне — на что уж хороший у него тачскрин — и то неудобно.
В итоге написал небольшую обертку над винапи, имитирующие движения мыши/нажатия клавиш, и «универсальную», в рамках моих целей, библиотеку автоматизации процесса автоматизации :) Если кратко — то суть в разбивке всего процесса на шаги, где каждый шаг сводится к нахождению области на экране (простейший OCR) и выполнению действия (мышь/кнопка).
Потратив однажды пару дней, автоматизация шага теперь проходит за пару минут — добавлением класса с параметрами поиска. С#. Поначалу задумывался над выкладыванием в опен-сорс, но в такой специфичной области наврядли кто-то будет использовать чьи-то сторонние поделки, когда нет уверенности что поделка «подойдет» и отсутствует коммьюнити :)
Кстати, у того же AutoIt есть AutoItX — ActiveX библиотека для использования в своих разработках… но неудобство собственно ActiveX (регистрация на пользовательских компах) перевесила изначальное нежелание писать своё :)
я тоже слегка огорчился такому ответу — если это ком.тайна лучше бы так и ответил
Почему при открытом gmail опера начинает стабильно съедать память? :) //наверное, это не по адресу :)
так что ли заголовок писать? :) «аутсорсинг» в русском языке уже вполне прижился, а языковую игру с «краудсорсингом» на русский красиво не переделаешь
О том, что проблему сначала лучше рассматривать в общем — мы вроде знали и до этого